ソフトウェア開発は、今まで作ったことのないソフトウェアを作る仕事なんだね。要望が変わらなければ同じソフトウェアをコピーして渡せばいい。ソフトウェアはコピーしても劣化しないからね。そこが普通の工業生産品と違うところ。コピーしてちょっと改造して渡すのはカスタマイズといって開発とはいわない。
今まで作ったことのないソフトウェア、つまり未知を相手にするのがソフトウェア開発の特徴の1つというわけ。
未知なものを作るわけだから「作ったほうが早い」じゃ上手くいかないことが多い。未知だからこそ計画を立てておかないとすぐに迷走してしまう。つまり、計画を立てるのは自分の現在位置を把握するためなんだね。
というわけでプランニングの話に入るんだけど。プランニングという活動は主に2つに分けられる。見積もりとスケジューリングだ。
見積もりというのはやること(タスク)を洗い出すことだよね。このときのポイントは2つある。大数の法則と不確実性のコーンといわれるもの。
大数の法則というのは単純で、タスクを細かくたくさん洗い出すほどタスク間の誤差が小さくなるということ。実際にタスクに取りかかってみると、予想よりも時間がかかったり、早く終わったりする。タスクを細かくして大量にそろえると、タスク間の誤差が均されて全体として十分な精度になる、というのが大数の法則。
次に不確実性のコーン。これは「1つのプロジェクトを通じて、はじめのほうにやる見積もりより、終わりのほうにやる見積もりのほうが精度が上がる」ということ。コーンというのは工事現場で置かれる三角コーンを思い浮かべればいい。最初のうちは誤差はプラスもマイナスも大きい。けれども、プロジェクトを続けて経験を積むと、誤差はプラスもマイナスも小さくなる。
https://ssaits.jp/promapedia/concepts/cone-of-uncertainty.html
大数の法則と不確実性のコーンから何がいえるか。そこが重要。まず、タスクは細かく洗い出したほうがいいということ。次に見積もりは頻繁に見直したほうがいいということ。
ここで自分たちの普段の仕事のやり方を思い出してほしいんだけど。やることをチケットに分けてる。さらにそのチケットの中でToDoリストを作っている。これが大数の法則に沿ったもの。で、毎日朝会を開いてチケットごとのポイントを確認している。これが不確実性のコーンに沿ったもの。自分たちが原則に沿った活動を実践しているということを理解してほしい。
プランニングの次の活動はスケジューリング。スケジューリングというのは基本的には見積もりで洗い出したタスクを時系列に並べることなんだけど。ここでも未知が影響してくる。
未知なものを開発してるんだから見落としが生まれやすい。そうすると新しいタスクが生まれる。ここでどう対応するかが大切なんだ。スケジュールを立て直す、つまりリスケするんだね。
リスケする場合でも、それまでに立ててあった計画が基になる。計画されたタスクがなくなったわけじゃないからね。突然見つかった新しいタスクとこれまでのタスクを合わせて全体のスケジュールを見直す。あるいは、これまでのタスクも見直すことになるかもしれない。
タスクはゴール、つまり終了条件を見つけることが大切なんだね。そのタスクは何をもって終わったといえるのか。テストが通るようになったら終わりなのか、パッチを作ったら終わりなのか、パッチを送ったら終わりなのか、あるいはそういうチェックポイントをいくつか通過しないといけないのか。
タスクのゴールをはっきりさせて、スケジューリングを常に新鮮に保つ。いつまでもやり残したタスクは残さない。やり残しが残っていること自体、スケジューリングが上手くいっていない証拠だ。「キリがいいところまで」じゃなく、積極的に「ケリをつける」。どうやったらタスクをクローズできるか、そこも柔軟に考える。
ここでも普段の自分たちの仕事のやり方を思い出してほしい。見落としていたものがあればそれをチケットにしてスケジュールを見直しているし、チケットのタイトルも実態に合ったものに変えることもしょっちゅうある。さらにはお客さんからの要望でタスクの優先順位も変わることがある。スケジューリングは柔軟に、スケジュールは新鮮に。
見積もりもスケジューリングも繰り返し見直すことが肝心だとわかってもらえたと思う。これは朝会だけでなく、1人1人の作業の中でも行われるものだし、こういう「やりくり」を延々続けるのがソフトウェア開発というものなんだね。
やりくりは１人でやるばかりじゃなく、何人かでやることもある。たくさんタスクを抱えている人がいたとして、他の人にタスクを分けてあげられれば、全体として速く進むことができる。そういうやりくりができるためにも、タスクを整理できていることが大切なんだね。
チケットやToDoを分けたあと、それを並べていくわけだけど。この並べる作業を自分は作戦と呼んでいる。
作戦にはいくつかポイントがある：
- 顧客に価値を提供する
- スモールスタート
- 使えるシステム
- YAGNI
- 深さ優先
まず原則として、顧客にとって価値のあるものから手をつける。ソフトウェア開発は失敗しやすい。プロジェクトが途中でキャンセルされたときでも、それまでに作ってきたものが価値あるものなら成果がムダにならない。
ソフトウェア開発は失敗しやすい。なので、小さくはじめて顧客の意見を聞きながら大きく育てる。
顧客の意見を聞くには実際に使えるシステムが必要。
「価値を提供する」、「スモールスタート」、「使えるシステム」の３つから導かれるのが「今必要ないことはやらない」。ソフトウェア開発は失敗しやすい。だから「いずれ必要になるから」という理由で作りこんでも、プロジェクトがキャンセルされたらムダになる。
使えるシステムであるためには、システムを層ごとに作っていくのではなく、機能ごとに作る必要がある。
左が幅優先の開発の進め方で、右が深さ優先の開発の進め方。幅優先で進めた場合、顧客が実際に操作できるようになるまでには、データベースとロジックがすべて終わってさらにフロントエンドの１ポイントを加えた７ポイントが必要となる。一方、深さ優先で進めると、３ポイントあれば、一部の機能とはいえ、顧客は使い始めることができる。
「スモールスタート」と「使えるシステム」の２つから必要十分なシステムしか作らないわけだけど、ここで重要になるのがバージョンアップという考え方。使えるシステムのまま機能を充実させていく。
見積もりからチケットを分けるのは当然なんだけど、見積もりの時点からバージョンアップのルートを見ておく。そのためには機能の価値を分解して、一番高い価値ををどうやったら逸早く提供できるかを考える。
アルファ版やベータ版という言葉を聞いたことがあると思うけど、それを個々の機能にも当てはめてみようということ。
バージョンアップというのは、言い換えれば、顧客の意見を聞くタイミングを作るということ。そうすることで開発側と顧客の認識のズレをなくす。ミスコミュニケーションがソフトウェア開発の失敗の大きな原因ということも覚えておこう。
ソフトウェア開発は未知なものを作るので遭難(迷走)しやすい。集団遭難となるとデスマーチと呼ばれる事態に陥ることになる。
遭難対策は３つのフェーズに分けて考える：
- 備える
- 気づく
- 抜け出す
遭難の備えとしては計画と装備があげられる。計画については先に述べたとおり。装備についてはイシュートラッカーなどで現在地を把握しリスケジューリングしやすい環境を整えておく。
ほとんど場合、突然遭難に陥ることはない。少しずつ静かに遭難していく。なので、逸早く遭難に気づくことが大切。
遭難に気づいても、遭難だと認めたくない心理が働くことがある。正常性バイアスと呼ばれる「自分は間違っていない」という心理だ。
他にも、本来の目的を忘れて、リファクタリングを延々続けたり、凝った実装を追及したり、