AEP読書会 第一章「計画の目的」に参加しました

2013/4/12(金) AEP読書会 第一章「計画の目的」に参加してきました。

DoorKeepr
http://aepreading.doorkeeper.jp/events/3452

以下の書籍をターゲットとした読書会なのです。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ (2009/01/29) Mike Cohn、マイク コーン 他 商品詳細を見る

場所はアジャイルサムライ横浜道場と同じく、アットウェアさんです。
参加者は12名くらいでしょうか。

去年の4月（ちょうど今頃くらいですね）、会社からの辞令で部署異動がありました。
配属された部署は「アジャイル開発を全社に適用推進していこう」というのがミッションの１つだったんですが、
そんなわけで会社からアジャイルに関する1冊の本が手渡されました。
それがこの書籍だったのです。

んでこの本を読み始めたのですが、とても良い本だなー、と気に入っちゃって、会社から借りた書籍は返し、
自分で買いなおしました。会社から借りた本だと、書き込んだり折り込みいれたりできないですからねぇ。

今回、この読書会が新たに始まることを道場主さんのツイートで知り、良い機会ということで参加することにしたのです。
ディスカッションできる場があるのも良いですねー。

---

今回の読書会は、いきなり最初からピザとビールを飲み食いしながらの進行です。
データベースリファクタリング勉強会もこんなカンジでやってますね。

以下、ディスカッション時に書き殴った個人的メモ。
---

■P.28に「計画づくりとは価値の探求なのだ」とあるが、「価値の探求」とは何を指すか？
　→　読書会の中で結論でず。もやもや感があるが先に進む。

■プロジェクトが始まる前にコストは計れるが、価値は計れるのか？
　→　コストも始まる前にホントに計れるのか？
　→　両方とも大体の概算なら計れるのでは。

■信頼できる見積りとは？
・計画作りの話だから、継続的に計画をつくる、ということでは。
・見積りを作成する人が信頼できるから、その見積もりも信頼できる。という理解もできるのでは。
・計画は、ある時点のスナップショットにすぎない。
・当初立てた計画が今となっては危ういと分かっているのに、それを守ろうとする行為は信頼できない。
　→　ちゃんと計画変更の必要性をステークホルダーに知ってもらうことによって、信頼性が上がる。

■スケジュールとトレードオフになる品質について
・お客さんには外部品質は求められるが、内部品質は求められない。
・でも内部品質を疎かにしていると、外部品質もそのうちダメになる。

■「計画」と「計画づくり」は何が違うのか？
・「計画」は、ある時点の「スナップショット」。不確実なものでしかない。
・「計画づくり」は、それをつくる過程。
・開発に例えると、「計画づくり」は「プログラミング」で、「計画」はある特定の「リビジジョン」。
　→　ある特定のリビジョン（計画）に拘るよりは、プログラミング（計画づくり）を繰り返して改善していく。
・「計画づくり」は行為であり、そのアウトプットが「計画」。
・「計画づくり」をするための「計画」を作れ、とか上司から言われそう。。。 orz

■計画しすぎるとよくない理由
・時間がかかる
・時間をかけて作った計画は、信頼できる計画だと誤解される
・見積もりは計画の構成要素である。
・アジャイルサムライでも、計画は「あてずっぽう」と言っている。また不確実性コーンの左端は不確実。
　→　その段階で計画しすぎても、どうせ状況が変化し、当初の計画はムダになる。

■計画へのバッファの積み方について
・プロジェクト全体にバッファを積むのはいいが、タスク１個１個にバッファを積むのはダメ。
　→　パーキンソンの法則が当てはまる状況になってしまう。
・バッファは50%～90%の範囲で積むのが良いらしい。
・プランニングポーカーで5か8のカードばっかり出す人は、「こいつバッファ積んでるな」と勘ぐるかも。

■どれくらい計画すれば適切か？
・みんなが合意できるくらい計画できればいいのでは。
・みんなとは？

■良い計画と無駄な計画とは？
・計画では、仮説と検証が大事。でも最初の仮説を間違えると、あとのモチベーションがすごく落ちる。
・計画しすぎると、間違えたときに戻れない。リソースを人に結びつけちゃうので。
　→　失敗とわかったら止められる計画が良いのでは。
・計画は、後で直せるコンテキストと直せないコンテキストがある。特に後者はハード開発で多い。
・計画に失敗して作業が無駄になると分かった時は、その仕事が無駄かどうかより「仕事があると人は成長する」という発想をする。失敗を価値と捉える。
・本当の無駄とは、「無駄に気づいても、それを続けること」では。
・上から提示された計画に沿って嫌々やるのと、自分達で作った計画に基づいて作業するのでは、モチベーションは全然違う。
　→　計画は自分達で作るのが良い。
　→　最初の計画は上の人が立てたとしても、その計画を変えていける状況ならば、それでいいのでは。

■これまで参加したプロジェクトで上手くいったものについて
・自分一人で計画を作るのではなく、みんなで計画を立てて発言率が上がる状況にしたら、上手くいった。
・反復開発の1週目で、すごい失敗した。それで2週目は不確実性コーンを考慮したら上手くいった。
・顕在化したリスクを計画に組み入れた。
・とりあえず計画があると、議論する場が生まれた。それでいろいろ見直しをかけることができた。
・実装チームと検討チームを分けたらうまくいった。
　→　デザイン担当とアプリ担当を一人ずつ呼んで、２ヶ月で作ってみる。
　→　リリースのスピードはすごく遅くなったが、全体としては上手くいった。

■WBSについて
・「ソフトウェア職人気質」という書籍によると、「炭鉱を掘る」という作業の見積りがWBSに関係があるらしい。

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series) (2002/03) ピート マクブリーン 商品詳細を見る

・炭鉱を掘る作業だと、一人の作業量が大体ブレなく見積もれる状況にある。ソフト開発はそうじゃない。
・炭鉱採掘は必ずやらないといけない作業は見えるが、ソフト開発は見えない作業がある。
・WBSの破綻をカバーできる予算があるのが、良いWBSでは。
・自分の作業をWBS化すると正確性は高い。チームでも、長く一緒にやってるメンバだとWBS上手く書けたりする。
・WBSはお客さんに見せるために作らざるを得ないことが多い。
　→　「適当WBS Creator」みたいなツールがあるといいかも。バックログを入力するとそれらしいWBSを吐いてくれるとか(笑
・一人作業に対してWBSを作るのは無駄では。バックログとかToDoリストで十分。
　→　それは作業をやる時期によるかもしれないのでは？
・WBSで、タスクに作業者の名前を最初から入れずに、後でで決めるという方法もある。

---

★感想：
本を独りで読むだけでなく、参加者とのディスカッションを通じて理解を深められるのがよいですねー。
昨日も「SQLアンチパターン」という書籍の読書会に参加してブログにも書きましたが、理解度が全然違う。
疑問点とかもぶつけてみて解決できますし。

あと、ピザとビールもおいしかったなぁ。量も十分で、これで1000円とは驚き。
酒代を負担してくださったスタッフ様、ありがとうございます！

。。。でも、ディスカッションしてるとピザが冷めちゃうのが難点でもある。

最後に道場主様スタッフ様はじめ、参加者の皆様、ありがとうございました。