# 大事なのは、計画を立てることではなく、立てた計画を学びに合わせて変化させていくこと こんばんは、マナビのデバッグログのんちゃんです。 私が日々奮闘する中で見つけたマナビ焼き付きを 来世しながら皆さんとシェアしていきます。 今日は、アジャイルな見積もりと計画作りという本について話していこうと思います。 この本は、会社の有志のエンジニア何名かでやっている 輪読会の課題書籍で、去年の11月ぐらいから毎週2、3章分ぐらいを課題として読んでいって、 気づいたこととか、大事だと思ったこととか、議論したいこととか、質問とかを付箋に書いていって、 みんなで議論していくような感じで読んできました。 本もそろそろ終盤に差し掛かってまして、せっかくなので感想を話していきたいと思います。 この本で繰り返し言われていて、私も確かにそれってすごく大事だなと思ったことが、 今回この書籍のタイトルにもあるみたいに、アジャイルな見積もりと計画作り、計画ではなく計画作りが大事だというふうに 繰り返し言われていました。計画だけだと作って終わりのイメージなんですけど、 大事なのって計画を立てることではなくて、その立てた計画をプロジェクトの進捗とか、 プロジェクトで得られた学びとかに合わせて変化させていくことだというふうに書かれていましたし、 本当にそうだなというふうに思いました。 ポイントは変化させていっても構いませんではなくて、 チームのみんなが積極的に変化をさせるのが当たり前だよねという文化を作っていくことだと思います。 例えばどういう変化が必要なのかというと、プロダクトオーナーからもらったフィードバックによって、 ユーザーの要望がちょっと違いました、想定したものと異なってましたって気付いたとか、 このフィーチャーいらなかったよねって気付いたりとか、 そういう変化をこの状況だったりに合わせて適応させていくっていうのが一番大事で、 プロジェクトの初期に完璧な計画を立てることって不可能なので、 その計画を変更することをどんどん推進というか促進していきましょうっていうのが、 この本の伝えたいことかなと思いました。 本の中でなるほどなぁと思ったのが、目に見える範囲を超えて計画を立てているのに、 計画を見直す時間を組み込んでないっていう、そんなプロジェクトは危険だっていうふうに言われていて、 計画作りとしてどんどん適応させていくことを、仕組みとしても取り入れるっていう必要性も感じられました。 あとは、作業ではなくてフィーチャー単位で考えましょうっていうのも、この本で繰り返し言われていました。 フィーチャーという言葉は、この本でも注釈みたいな形で説明されているので、ちょっと読みますね。 フィーチャーという言葉を本書では、ソフトウェアの機能や特性、特徴、性能、目標、見た目や使い勝手など、いわゆる売り文句などを総称する言葉として使っています。 フィーチャーは要求仕様、機能要件、大機能、ユースケースといった言葉で指すものとよく似ている。 しかしこれらとフィーチャーとの決定的な違いは、フィーチャーはユーザーにとってソフトウェアの価値を表現したものであり、ユーザーに直接価値を提供するものだということだ。 というような言葉で説明されていました。 つまり、届けたい価値がフィーチャーなのかなと思っています。 この本でもタスクだったり、作業の単位で開発を考えるのではなくて、顧客に対して届ける価値としてのフィーチャー、単位で考えましょうと言われています。 すみません、ちょっと私音読が苦手でマゴマゴしてしまいました。 14章がイテーション計画作りという章なんですけど、ここの4節っていうのかな、チームにコミットできるか尋ねるっていう部分があって、ここが面白いなと思ったので取り上げます。 まず、ある研究によると、チームが成功する秘訣はチームメンバー全員が同意したコミットメントだというふうに書いてあって、まず全員でコミットメントしましょうというふうに書かれています。 そこではこの作者の方は、このイテレーションプランニングでチームメンバーにある質問を投げかけています。 それが、今話し合ったこのフィーチャーをリリースすると確約しますか?というふうに問いかけているんですね。 ここで注意するのが、今出したタスクの完了を確約しますか?ではないというのが大事だと言われています。 一つ一つのタスクではなくて、あなたはこのフィーチャーをリリースすることを約束しますか?というふうに聞いているんですね。 つまり、このタスクが終わることではなくて、このイテレーションの途中で見つかったタスクだったりも含めて、フィーチャーに含めて、このフィーチャーごと、追加されたタスクごと含めてフィーチャーを提供できますか?というふうに、ちょっと責任範囲が広がっているようなイメージです。 新しく発見したタスクが大きすぎて、イテレーションの期間内に完了できなくなることもあるので、そういった場合は、チームとしては、プロダクトオーナーと相談をして、イテレーションのゴールを達成する方法を考えるというふうに書いてあります。 例えば、フィーチャーを縮小するとか、ストーリーをどれか一つ諦めるとか、そういった形で、今回のコミットメントを調整するというやり方もあるみたいです。 自分の言葉でコミットする、やりますと宣言するってすごく大事だなと思ったので、今、私が入っている開発チームでも取り入れていきたいなと思いました。 あと、それ以外でもう一ついいなと思った部分は、一つのチームとして動くという考え方です。 イテレーションプランニングでは、タスクの担当者を決めないというのが面白いなと思っていて、サインアップという考え方を取り入れているんですけど、 サインアップというのは、自分の担当するタスクを自分で選んで、担当者として自分で名前を書くという仕組みになるんですけど、 ここも先ほどと一緒で、本人が自分の意思で名前を書くというのも大事みたいですね。 なぜこれをやるかというと、担当者を事前に決めてしまったりとか、人が決めてしまったりすると、一つのチームとして動くことが難しくなるというふうに書かれていました。 自分事がしにくくなるという感じなのかな。 チーム一丸となるという意欲に影響があるので、チームの中でやるべきタスクに対して自分で選んで、自分でサインアップするという動きはとてもいいなと思いました。 どうしても組織の人数が少なかったりすると、ある程度このタスクはこの人がやるよねって決まってしまったりすると思うんですけど、 しかもそういう時って勝手に私が名前を書いてしまったりとか、今までしてしまってたなと思うんですけど、 自分で選んで自分で名前を書くというサインアップという取り組みはやってみたいなと思いました。 今日はアジャイルな見積もりと計画作りという本を読んで感想を話してみました。 お聞きいただきありがとうございました。 このチャンネルは週2回更新予定です。 フォローやコメントお待ちしています。 それではおやすみなさい。