Mike Cohn / アジャイルな見積りと計画づくり

最近関わっているプロジェクトは、本質的に機能の不確実性が高いということが多いプロジェクトです。ですので、不確実性、あるいは計測/制御でいうところの誤差、をコントロールするという視点で、プロジェクト管理できないかなぁと考えている今日この頃。

「アジャイルな見積りと計画づくり」を、誤差のコントロールの視点から読みました。実験的にやっていることや、今後、やっていきたいなと思うことのメモです。

従来からある計画手法の多くが犯している誤りは、フィーチャをプロジェクト開始時に固定 できると信じていることだ。そのため、いったん計画を立てたら、その後は変更を認めなかっ たり、複雑で手間のかかる変更管理プロセスを強制して計画の変更を阻害したりしている。 (p.261)

前提が間違っている、と。もちろん開始時に固定すべき/固定できるプロジェクトは存在する。けど、そうじゃないなら、そうじゃないなりのプロセスが必要で、ほかができなくて自分たちができるなら付加価値になる。

「2週間後には、今日よりも多くのことが明らかになっています。イテレーションでなにをすべきか決まっていないのに計画を立てる理由があ りますか?必要ないんです。大規模なプロジェクト、特に複数のチームから構成されている プロジェクトでは、作業の連携のために2イテレーションか3イテレーション先まで計画することがあります。ですが、いまの私たちには必要ありません」 (p.303)

ある程度の、おおざっぱに見積もりは、もちろん必要。でも、細かい見積もりは不要。「精度」という語彙は曖昧なので、確度と分解能と言えばいいかな。確度が高いことは大事だけれど、分解能は低くてよい。

1ポイントのストーリーよりも短い時間で完了できる2ポイントのストーリーがあるというのは、まったく理にかなったことであり、予想の範囲内でもある。(p.179)

誤差は含む。見積もりは期待値分布の代表値にすぎない。ひとつのタスク、ひとつのストーリーの誤差で一喜一憂していはいけない。もちろん傾向として、全体的に20%オーバーするとかであれば、見直しがひつようだけど。

スパイクとはイテレーション計画に含める タスクの一種で、何らかの知見を得たり、疑問を解消することを日的に取り組む作業のことだ。[...] スパイクを実施すれば2つ目のタスクヘの見通しが得られるので、 このタスクをより正確に見積もれるようになるのだ。 p. 170

まず、おおざっぱな見積もりをして、そのあとで実際のタスクを見積もり直す。もちろん誤差はある。でも、コントロール下に置くことができる。

大きなストーリーはストーリーでおこなう操作に沿って分割すること。 p.140

例として CRUD する場合には、Create でひとつのストーリーにする、というもの。Django の場合は、管理画面でDBテーブルの内容を見るのがカンタンなので、これはありだと思いす。実は今のプロジェクトで、この区切りを使っている。

大きなストーリーの機能要求と非機能要求とをそれぞれ個別のストーリーに分割すること を検討せよ。 (p.142)

今のプロジェクトで実験中。まして、パフォーマンスがどの程度かやってみないと分からないので、まずは正しく動く機能を実装しています。

岡島幸男/受託開発の極意

要件定義について最近よく考えたり、実験したり、実践したりしています。そんなわけで「受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 」から要件定義関連で気になったことをメモします。

手段の話が先行すると視野が狭くなり、お客さまが本当に実現したいことからかえって遠ざかることもあります。たとえば 「ユーザが入力したデータを保持する」という目的を実現するにはいくつもの手段がありますが、「SQL Server にデータを保管する」という手段に限定してしまうと、ほかの手段を検討する機会を失うことになります。 (p.56)

つい実装よりのことを考えてしまうのですが、そこはぐっとこらえるようにしています。なんだったら、DB に格納する、というコンセプト自体を疑えるようにしたいです。だから、要件は明確にしつつも、レイヤーの高いところで話をしないといけない。オブジェクト指向分析っていうのは、本来そういうためのものじゃないかなぁと思っています。オブジェクトが最終的なクラスになる必要はないですが、分析段階で認識出来る抽象的な「モノ」があると何かと便利です。

特に重要なのは業務フローです。システムの提供する機能だ けではなく、手作業やほかのシステムも含めた「お客さまの業務そのもの」を表現します。(p.59)

要件定義の結果、最終的には「システムは何をすればいいの？」ってことが分かればいいのだけれど、その途中で、外部で何が起こっているか、すくなくともシステムから何が知覚できるのかは書いておかないとシステムは作れないと思います。顧客の立場では逆もしかり。業務フローもちゃんとまとめておくというのは共感です。


それから丸投げ対策なんかも書かれていました。丸投げの発生はしょうがないと考えています。これまでシステムのことを考えもしなかった人たちが、システムを新たに使ったり発注したりするでしょう。そのときに、丸投げすんなって言ってもいいけど、逆にそういうセグメントをターゲットにすることだってできると思います。クリステンセン「イノベーションへの解」にならうなら、最も供給が不足するところに利益が集まるわけです。


さてさて、別な話とみせかけて、スケジュールの話も。

要件定義フェーズで怖いのは「いつになっても終わらないこ と」です。このままでは時間切れで開発に突入してしまいます。 お客さまに進捗を示すことは重要です。ヒアリングも回数を重ねると堂々巡りになることがあります。前回の課題を継続検討していたり、「そもそも論」に立ち戻っていたりしてはスケジ ュールどおりの完了は見込めません。(p.56)

仮に仕様変更があることを前提にした開発であったとしても、前提条件としての仕様は明確にしておいたほうがいいですね。自戒も込めて。でないと、変更が発生したときに、どのくらいの規模での変更があるかさえわからなくなります。規模に影響する要件定義はできるだけ早く決めていくようにしよう、と改めて思いましたとさ。

トム・デマルコほか / アドレナリン・ジャンキー その3

アドレナリン・ジャンキーの続きです。

20 一人一役

仕事の一部（コンポーネント、任務、目標、アクションアイテムなど）について単独で責任を引き受けるとき、その人が役割を理解して引き受けるのは、作業と期待される結果が明確に対応しているからである。[...] ひとりで責任を引き受けたからといって、同僚やその他の関係者に協力を求めたり、必要な意見を得たりしてはいけないということではない。肝心なのは、任務を受けた人がその部分について引き続き責任を負うことである。(p.64)

単純には役割分担だけれど、実際には、役割の境界がプロジェクト開始時には不明瞭な場合だってあります。そういうときでも、任務をまっとうする責任を負えるカルチャーがいいなぁと言う話です。一方で、知識がひとりに集中してしまうといけないので、情報の共有やレビューは大事だと思います。XP ではペアプロをすることで共有するわけで。

別に特定の責任を負うからといって、他のことを知らなくていいわけでもないし、知らせてはいけないわけでもないと思います。そういう次元ではなくて、アサインされたタスクをちゃんとやろうぜ、と。そのためには、期待される結果が明確になってないといけないわけです。耳が痛い話です。

21 ソビエト式

どうすればソビエト式 [要求した機能は備えているが使う気にならないような] の製品をつくらずにすむだろうか。それには、プロジェクト計画に、明確に機能面以外の要求を対象とする作業を組み込むことだ。こう言うと簡単なようだが、ソビエト式のシステムのほとんどは、機能面以外の品質があっさり無視されたためにソビエト式になったことを考えてみるといい。 (p.70)

このあたりは、37 Signals のどっかの文章に書いてあった、インタフェースから考えるだとか、ストーリードリブンな考え方とかが合うのかも知れない。このところ、内部の機能よりも、ユーザの眼に触れるところから考えるようになっています。ほとんどのばあい、ユーザに見えるのはUIなわけですから。あるいは、APIとか。いずれにしても、外側での振る舞いの期待と実際のギャップを埋めるようにしています。難しいですけどね。

トム・デマルコ ほか / アドレナリンジャンキー -- その2

アドレナリンジャンキー感想文の続きです。

14 フェイスタイム

何かを言ったとき、普段顔を合わせているかどうかによって、把握できることが違うであろう、というのが根本的な考え方です。講義の暗黙知の共有だと思います。「やべぇ」の一言が、どのくらいのやばさを意味しているのか、みたいな。

サイト間の作業の調整を担当する人は、最も頻繁に会う必要がある。そのような人は、通常、プログラムマネジャー、プロジェクトマネジャー、リリースマネジャーといった肩書きをもつ。リリースサイクルごとに何度か会う必要がある。 (p.44)

忙しくなるとおろそかにしがちというか、むしろ作業時間確保のために避けようとしてしまうけど、そういう状況でこそコミュニケーションを取らねば。

16 ダッシュボード

プロジェクトの日々の状態を可視化したものが、ダッシュボードです。有効なダッシュボードに以下のような、意思決定を容易にするような特徴がある、と書かれています。(p.50)

1. ダッシュボードを使ってもデータを圧倒されない。

2. ダッシュボードを抜粋・編集できる。

3. 情報を示すだけでなく判断をうながす。

4. 現状を反映するだけでなく未来を予測する。

5. 長期的なトレンドを示す。

6. チームが主観的な評価を報告しなければならいときに、比較をするための枠組みがある。

1と 2 はある程度できてるけど、3以降ができていません。まず3からやっていこうと思います。簡単でいいですし、ツールに凝る必要もないわけですから。

17 永遠の議論

永遠の議論は、議論が収束なく続くというアンチパターンです。

決定に従うことと決定に賛成することは別のことだと認めているのだ。人びとに賛成しろと命じるのは意味のないことだ。異なる意見を持っている場合、誰かが命令したからといって、意見が変わるわけではない。決定に従うということは、決められた行動をとり、賛成しようとしまいと、決定に逆らうことに余計なエネルギーを使わないということだ。 (p.54)

賛成ではないが決定されたらコミットする、というのは、いつからか私の習慣になっています。いつからだったのかなぁ、not agree but commit みたいな言い回しを見てからのような気がする。昔の上司に「嫌そうな顔を隠しきれていないけれど、決定事項はやる（しくじることはあるけど、決定から外れようとはしない）ところ」を明示的に評価されて、そうじゃない人がいるんだ、と気づいた。

永遠の議論が起きるのは、人びとが、賛成のときだけ決定に従えばいいと考えているためだ。ひとたび決定が下ったらそれに従い、受け入れるという倫理を確立するのは、マネジャーの責務である。 (p.55)

マネジャー責任重大ですね。そして、これ私にはかなり大きな挑戦です。人にものを頼むのも躊躇するのに、どうやって倫理の確立みたいな強い要求をすればよいんだろう。

トム・デマルコほか /「アドレナリンジャンキー」その1

デマルコの「アドレナリンジャンキー」、読んだあとに付箋はりまくりなので、ちょっとずつ記録に残していきます。自戒ばっかり。

この種の [アドレナリンジャンキーな] 企業文化では、死に物狂いに急ぐことと効率良く成果をあげることが同一視される。このような組織にいたら、中毒にならずにいるのは難しい。切迫感があることがよしとされる。 (p.2)

これ気を付けないとなぁ。短納期なときには、適切にプロジェクトを進めていかないと、これに陥りがち。イベント系の単発システムとか。本来はそれを防止するためのタイムボックス化したイテレーションなのだと思います。

進捗だけでは不十分である。「５月末までに仕様書を50%セント仕上げよう」といった目標では、満足のいく結果は得られない。小さな声がささやく。「50%パーセント、つまり5月末までには終わらないということだ。それまでにほんとうに終えなくてはいけない仕事はどれだったかな。」 (p.7)

つい目先のタスクに「だけ」目がいってしまうんですよねぇ。

プロジェクトに信者がいると、身動きがとれなくなることがある。コンテンツに集中せず、手法戦争を始めるのだ。 (p.33)

これも気をつけなければ。議論がずれていくのは気持ち悪いんだけど、それはコンテンツに集中する、という方向に持っていけてないからなのですね。状況によって修正の方法は違うのだろうけれど、何がコンテンツなのというのを常に覚えておかねば。in-person でやっているときには、ホワイトボードや付箋で、議題を可視化するんだけど、チャットのときが自分にとっての課題です。