うまいことソフトウェア開発やっていく感じ（前編: チームが集まってから見積もりと計画づくりまで）

最近、だいぶチームでのソフトウェア開発がうまくなってきたなという感覚があって、どうやっているのか書き下してみる。

前提として、主にB2BのSaaSを作っているので、B2Cだったり、SaaSではなかったりすれば、異なってくる部分ももちろんあると思う。

チーム

4〜5人くらいのチームがある。
チームはマネージャーによって集められる。*1

チームの人はそれぞれ得意・不得意もバラバラだし、キャリアも知識もバラバラなので、それをうまく活かしつつ、得意分野も不得意分野もさらに伸ばしていけるように取り組む。

お互いのことを知っているとうまくやりやすいので、ちょっとしたチームビルディングのワークを行う。
最近のお気に入りはValues Cardだ。ドラッカー風エクササイズもいい。
どちらも1時間もあればやれる。

チームビルディングは一度行って終わりではなく、最初の会話をきっかけに、日々の会話や、ふりかえりのような機会で、深め続けていく。

目的

目的がある。
目的はステークホルダーによって定められる。*2

新機能を作ることかもしれないし、既存のシステムを刷新することかもしれない。その中間（両方）ということもあるだろう。
目的をさまざまな側面から捉える。ユーザは誰なのか。ビジネスにとってどういうインパクトがあるのか。時期やアーキテクチャなど、制約条件はあるのか。
はじめからすべてがわかることはない。というよりも、永遠にすべてはわからない、と言った方がいいだろう。重要なことから、少しずつ、噛み砕いていく。

ステークホルダーと話したりしつつ、目的を掴むのにはチームで1日くらいはかかる。

ある程度の目的が掴めたら、計画を立てる。
目標は、長くても3ヶ月以内で達成できる大きさにする。機能としてはごく一部でもよいので、「作りかけ」ではなく、「本当にユーザが使い始められる」状態にこだわる。

既存業務のあるものなら、実際にその業務を行っている人と何度も話しながら、ユーザーストーリーマッピングのような手法で業務フローを分析していく。これから作るソフトウェアではフローが変わる部分もあるかもしれない。そこも含めて、新しいフローの仮説を立てる。

既存業務の置き換え・最適化というよりは新しい業務フローを提案するようなものなら、ユーザと話して、ユーザが今行なっている業務の理解を進めつつ、どうすればそれをよりよく革新できるかチームで考えながら、最初の仮説を立てる。

最初の仮説を立てるのにかかる時間は、短い場合はチームで1〜2日くらいだ。
革新の程度によっては、もっとかかる場合もある。どの段階から始めているかにもよる。僕がいる環境では、ある程度の仮説がある状態でチームが始まることが多いので、長くても1〜2週間もかければ次のステップに進めることが多い。

なお、チームが継続している場合は、前の取り組みの後半から次の取り組み（目的）を考え始めておく。そうすることでスムーズにつながる。

見積もりと計画づくり

大まかな一連のフローの仮説ができたら、小さなストーリー（※タスクではなく、ユーザに届く価値の単位）に分割していく。平均的には、1ペアで1日に1つのストーリーが終わる（着手から本番リリースまで1日）くらいのサイズにまで小さくする。これは平均なので、実際には数時間で終わるものもあれば、数日かかるものもある。*3
このサイズ感は、厳密に考えなくても、経験からだいたいこれくらいだとわかるが、後ほど見積もることで、より正確に検証できる。

ストーリーの分割にかかる時間自体は、1ヶ月分のストーリーで1〜2時間くらいだ。2ヶ月なら2〜3時間、3ヶ月なら4〜5時間といったところだろうか。
ここまでチームで2〜3日くらいかけて理解を深めてきていて、ある程度目的と仮説の解像度があるので、ストーリーの分割そのものは比較的スムーズに進むイメージだ。

分割ができたら見積もりを行う。ストーリーポイントの相対見積もりがとてもよく機能する。ストーリーをチームで砕いてきて、おおむね理解が揃っているので、見積もりはかなり早い。1ヶ月分で1時間程度、3ヶ月分でも2〜3時間程度ではないだろうか。それでも、見積もりの過程で理解が深まる部分もある。
経験的に数日で終わる程度のサイズよりも大きいポイントがついたものは、さらに分割して、すべてのストーリーが一定以下のポイントに収まるようにする。（明らかに情報が不足しているものについては、例外的に保留にし、かわりに情報を得るためのスパイクのストーリーを出すこともある）

見積もりができたらバーンダウンチャートを引いてみる。たいていの場合、3ヶ月やそれ未満の「最初のターゲット日」には収まらないので、スコープを狭める。
最初のリリースに本当になくてはならないものを見極め、ターゲットに収まるようにする。

「本当になくてはならない」とは言ったが、ここで決めたものが必ずしもターゲット日にすべてリリースされるとは限らない。あくまで現時点でそう考えているというだけだ。
頻繁にあることではないが、法的要件等から、文字通り「なくては・ならない」ものであれば、余裕を大きめに持っておく必要がある。

満足のいくバーンダウンチャート（計画の初期仮説）が引けたら、開発を始める。
ここまですべてで、順調なら1週間かからないくらいだ。

デリバリーインフラの整備

新たにサービス（ユーザにとってのサービスというよりは、コンポーネントとしてのサービス）を作る場合、E2Eテストを含むデリバリーインフラ（いわゆるCI/CD）の整備が必要になる。

ここまで1週間かからないくらいと書いたが、実際にはユーザやステークホルダーと話せる時間が限られたりして、すべての時間を効率よく使えるとは限らない。というより、大抵の場合はすべてを1週間の中に詰め込むことはできないので、その間（「空き時間」に近いイメージ）にデリバリーインフラの整備を進めることが多い。
結果的に、チームが集まってから2週間後くらいに、ある程度の自信が持てる計画も立ちつつ、デリバリーインフラもある程度は整備が進んでいる、という状態になることが多い。

なお、前の取り組みからチームが継続している場合は、インフラの整備がそれほどない場合もあるが、その場合は前の取り組みの中で先を見通しながら進めているので、「手隙になってしまう」ようなことは基本的には起こらない。

つづく

ここまで、僕（たち）が普段やっていることを思い出しながら、チームが集まってから見積もりと計画づくりを行い、本格的に開発を始めるまでの流れをまとめた。

普段やっていることなのだから当たり前だが、普通だな、と思う。もっとよくできそうなところもあるな、とも思った。
この「普通」を支えている環境も大きいな、とも思う。ありがたいことだし、環境を維持し、発展させていくこともしないとな、と改めて思う。

後編はこちら。↓

enk.hatenablog.com

*1:と言うとわかりやすいと思うのでこう書いているが、実際はもっと自己組織的な感じだ。記事にとってノイズになると思ったので、そこは省略した

*2:と言うとわかりやすいと思うのでこう書いているが、実際はチームによって見出されていく部分もある。ステークホルダーによって与えられているのは「コンテキスト」と言う方が正確かもしれないが、テンポが悪くなるので、そのへんのニュアンスは省略した

*3:すべてが数時間以内に終わるのが理想だと考えているが、現状はこうだ。すべてが数時間以内に終わるようにするには、ストーリー分割だけの問題ではなく、チームやアーキテクチャ等、色々なものを洗練させ続ける必要がある