第7章基礎プラクティス〜つづき

XP2
  • ストーリー、1週間サイクル

顧客の目に見える機能単位で計画する。

そう、顧客。顧客にとっての価値を生む単位で計画され、実現されなければならない。
そして、今顧客が必要としているもののみ。今必要でないものはムダなのだから。いまの時点で将来必要になるだろうモノも今の時点では必要はない。

    • 進行管理

顧客価値の単位でなければ、現物による顧客からのフィードバックの機会を失ってしまう。すなわち、顧客の目的へと向かう進行管理を不可能にしてしまう。

    • 繰り返しをつくる

短いサイクルで何度もチャンスが訪れる。開発者たちは繰り返しのリズムとカイゼンのチャンスを得ることができる。

    • 在庫

実装されていない設計やテストされていないコードなど、動作が顧客によって確認されないこれらは在庫である。完成在庫だけでなく中間生産物や仕掛り作業も在庫として認識する。それら在庫が、在庫自体の管理工数の計上や、不良検出機会の損失などのムダを生んでしまう。

    • 顧客が受け取る価値の総和

中間在庫の増加は、リードタイムすなわち要求実現のための着手から完成までの期間延長につながる。つまり顧客顧客が動くソフトウェアを手にする時間を延長させてしまう。一部の機能であっても顧客価値が発生する単位の機能を顧客が手にすることができれば、その時点から顧客は価値を得ることができる。価値は、
価値の大きさ×価値を生み続けている時間
で、評価されなければならない。よって、段階的であっても、顧客価値を生む単位で、早期にリリース可能な状態にすることが価値の総和の増大につながる。

    • 名前

ストーリーには短い名前をつけるようにする。

『どのようにつくるか』ではなく、『なにをつくるか』が明確になる。『なぜつくるか』をも明確に記述はできないだろうか。より顧客の視点を意識するために。顧客の目的を共有すれば、カイゼンの範囲もチャンスも拡大する。

    • 見積り

この価値を生むためには、工数がこれだけかかるので費用がこれだけかかります。は、TPSではあり得ない。

『はじめに手に入れたい価値が決まる。同時に投入可能なコストが決定される。』
これだけのコストでこの価値を生まなければならない。さてどうするか、どのようにすれば実現できるか。価格見積りではない。

    • テスト

なにをつくるか、どのように動作するのか、目的を達成しうるかという基準をまずつくらないと。ソフトウェア開発で我々がテストとついつい呼んでいるものとは違う。

    • 一列待ち

山積みになったタスクの一番上からタスクをとる。

均一なスキルをもった開発者たちである訳がない。着手を一列になってまっているタスクたちを開発者がとる。そのタスクの実施・消化を最も得意とする開発者がとるとは限らない。いや、タスクに着手すらできないことが多い。その状態、タスクに着手すらできない状態こそが、カイゼンのチャンスなのだ。

一列待ちには、リードタイムの短縮（平均レスポンスの短縮）効果もある。これは待ち行列理論から明らか。

どちらを狙うのか？狙えるのか？