Skip to content

Instantly share code, notes, and snippets.

@tkojitu
Last active August 24, 2022 03:14
Show Gist options
  • Save tkojitu/43837a68fd14464eedc3d0b3cbde28b3 to your computer and use it in GitHub Desktop.
Save tkojitu/43837a68fd14464eedc3d0b3cbde28b3 to your computer and use it in GitHub Desktop.
プランニングについて

ソフトウェア開発の特徴(未知なものを作る)

ソフトウェア開発は、今まで作ったことのないソフトウェアを作る仕事なんだね。要望が変わらなければ同じソフトウェアをコピーして渡せばいい。ソフトウェアはコピーしても劣化しないからね。そこが普通の工業生産品と違うところ。コピーしてちょっと改造して渡すのはカスタマイズといって開発とはいわない。

今まで作ったことのないソフトウェア、つまり未知を相手にするのがソフトウェア開発の特徴の1つというわけ。

プランニング

未知なものを作るわけだから「作ったほうが早い」じゃ上手くいかないことが多い。未知だからこそ計画を立てておかないとすぐに迷走してしまう。つまり、計画を立てるのは自分の現在位置を把握するためなんだね。

というわけでプランニングの話に入るんだけど。プランニングという活動は主に2つに分けられる。見積もりとスケジューリングだ。

見積もり

見積もりというのはやること(タスク)を洗い出すことだよね。このときのポイントは2つある。大数の法則と不確実性のコーンといわれるもの。

大数の法則

大数の法則というのは単純で、タスクを細かくたくさん洗い出すほどタスク間の誤差が小さくなるということ。実際にタスクに取りかかってみると、予想よりも時間がかかったり、早く終わったりする。タスクを細かくして大量にそろえると、タスク間の誤差が均されて全体として十分な精度になる、というのが大数の法則。

不確実性のコーン

次に不確実性のコーン。これは「1つのプロジェクトを通じて、はじめのほうにやる見積もりより、終わりのほうにやる見積もりのほうが精度が上がる」ということ。コーンというのは工事現場で置かれる三角コーンを思い浮かべればいい。最初のうちは誤差はプラスもマイナスも大きい。けれども、プロジェクトを続けて経験を積むと、誤差はプラスもマイナスも小さくなる。

https://ssaits.jp/promapedia/concepts/cone-of-uncertainty.html

見積もりの実践

大数の法則と不確実性のコーンから何がいえるか。そこが重要。まず、タスクは細かく洗い出したほうがいいということ。次に見積もりは頻繁に見直したほうがいいということ。

ここで自分たちの普段の仕事のやり方を思い出してほしいんだけど。やることをチケットに分けてる。さらにそのチケットの中でToDoリストを作っている。これが大数の法則に沿ったもの。で、毎日朝会を開いてチケットごとのポイントを確認している。これが不確実性のコーンに沿ったもの。自分たちが原則に沿った活動を実践しているということを理解してほしい。

スケジューリング

プランニングの次の活動はスケジューリング。スケジューリングというのは基本的には見積もりで洗い出したタスクを時系列に並べることなんだけど。ここでも未知が影響してくる。

リスケージュリング

未知なものを開発してるんだから見落としが生まれやすい。そうすると新しいタスクが生まれる。ここでどう対応するかが大切なんだ。スケジュールを立て直す、つまりリスケするんだね。

リスケする場合でも、それまでに立ててあった計画が基になる。計画されたタスクがなくなったわけじゃないからね。突然見つかった新しいタスクとこれまでのタスクを合わせて全体のスケジュールを見直す。あるいは、これまでのタスクも見直すことになるかもしれない。

ケリをつける

タスクはゴール、つまり終了条件を見つけることが大切なんだね。そのタスクは何をもって終わったといえるのか。テストが通るようになったら終わりなのか、パッチを作ったら終わりなのか、パッチを送ったら終わりなのか、あるいはそういうチェックポイントをいくつか通過しないといけないのか。

タスクのゴールをはっきりさせて、スケジューリングを常に新鮮に保つ。いつまでもやり残したタスクは残さない。やり残しが残っていること自体、スケジューリングが上手くいっていない証拠だ。「キリがいいところまで」じゃなく、積極的に「ケリをつける」。どうやったらタスクをクローズできるか、そこも柔軟に考える。

スケジューリングの実際

ここでも普段の自分たちの仕事のやり方を思い出してほしい。見落としていたものがあればそれをチケットにしてスケジュールを見直しているし、チケットのタイトルも実態に合ったものに変えることもしょっちゅうある。さらにはお客さんからの要望でタスクの優先順位も変わることがある。スケジューリングは柔軟に、スケジュールは新鮮に。

やりくり

見積もりもスケジューリングも繰り返し見直すことが肝心だとわかってもらえたと思う。これは朝会だけでなく、1人1人の作業の中でも行われるものだし、こういう「やりくり」を延々続けるのがソフトウェア開発というものなんだね。

やりくりは1人でやるばかりじゃなく、何人かでやることもある。たくさんタスクを抱えている人がいたとして、他の人にタスクを分けてあげられれば、全体として速く進むことができる。そういうやりくりができるためにも、タスクを整理できていることが大切なんだね。

作戦

チケットやToDoを分けたあと、それを並べていくわけだけど。この並べる作業を自分は作戦と呼んでいる。

作戦にはいくつかポイントがある:

  • 顧客に価値を提供する
  • スモールスタート
  • 使えるシステム
  • YAGNI
  • 深さ優先

顧客に価値を提供する

まず原則として、顧客にとって価値のあるものから手をつける。ソフトウェア開発は失敗しやすい。プロジェクトが途中でキャンセルされたときでも、それまでに作ってきたものが価値あるものなら成果がムダにならない。

スモールスタート

ソフトウェア開発は失敗しやすい。なので、小さくはじめて顧客の意見を聞きながら大きく育てる。

使えるシステム

顧客の意見を聞くには実際に使えるシステムが必要。

YAGNI

「価値を提供する」、「スモールスタート」、「使えるシステム」の3つから導かれるのが「今必要ないことはやらない」。ソフトウェア開発は失敗しやすい。だから「いずれ必要になるから」という理由で作りこんでも、プロジェクトがキャンセルされたらムダになる。

深さ優先

使えるシステムであるためには、システムを層ごとに作っていくのではなく、機能ごとに作る必要がある。

image

左が幅優先の開発の進め方で、右が深さ優先の開発の進め方。幅優先で進めた場合、顧客が実際に操作できるようになるまでには、データベースとロジックがすべて終わってさらにフロントエンドの1ポイントを加えた7ポイントが必要となる。一方、深さ優先で進めると、3ポイントあれば、一部の機能とはいえ、顧客は使い始めることができる。

バージョンアップ

「スモールスタート」と「使えるシステム」の2つから必要十分なシステムしか作らないわけだけど、ここで重要になるのがバージョンアップという考え方。使えるシステムのまま機能を充実させていく。

見積もりからチケットを分けるのは当然なんだけど、見積もりの時点からバージョンアップのルートを見ておく。そのためには機能の価値を分解して、一番高い価値ををどうやったら逸早く提供できるかを考える。

アルファ版やベータ版という言葉を聞いたことがあると思うけど、それを個々の機能にも当てはめてみようということ。

バージョンアップというのは、言い換えれば、顧客の意見を聞くタイミングを作るということ。そうすることで開発側と顧客の認識のズレをなくす。ミスコミュニケーションがソフトウェア開発の失敗の大きな原因ということも覚えておこう。

遭難

ソフトウェア開発は未知なものを作るので遭難(迷走)しやすい。集団遭難となるとデスマーチと呼ばれる事態に陥ることになる。

遭難対策の3段階

遭難対策は3つのフェーズに分けて考える:

  • 備える
  • 気づく
  • 抜け出す

遭難に備える

遭難の備えとしては計画と装備があげられる。計画については先に述べたとおり。装備についてはイシュートラッカーなどで現在地を把握しリスケジューリングしやすい環境を整えておく。

遭難に気づく

ほとんど場合、突然遭難に陥ることはない。少しずつ静かに遭難していく。なので、逸早く遭難に気づくことが大切。

遭難に気づいても、遭難だと認めたくない心理が働くことがある。正常性バイアスと呼ばれる「自分は間違っていない」という心理だ。

他にも、本来の目的を忘れて、リファクタリングを延々続けたり、凝った実装を追及したり、

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment