21.cell+constraint+value+agile+2

変幻する実行可能知識 21

セル, 制約, 価値, アジャイル II

今回は前回のセル生産方式+アジャイルに続いて, 制約理論+アジャイルという枠組みを考えてみる. 参考にしながら読むのは以下の書籍だ. ただし制約理論に関しては (2) は代表的な一冊に過ぎず, さまざまなトピックに関して多くの書籍が出版されている.

  1. アジャイル・ソフトウェア・マネジメント」 David J. Anderson, 日刊工業新聞社, 2006 (残念ながら原著のせいか, 翻訳のせいか, はたまた読者たる筆者の能力不足のせいか, 解読には若干の困難を伴う)
  2. ザ・ゴール - 企業の究極の目的とは何か」エリヤフ・ゴルードブラット, ダイヤモンド社, 2001
  3. 目標を突破する実践プロジェクトマネジメント」岸良裕司, 中経出版, 2005

さて, 制約理論は次のようないくつかの柱から成り立っている.

制約理論としてもっともよく知られているのが, 主にリソースごとのスケジュール上のボトルネック (クリティカル・チェーン) を制約と見て, その制約の解消により全体のスループットを向上させる手法 (クリティカル・チェーン・プロジェクト・マネジメント, 以下では「CCPM」) だろう. より一般的には制約となるのはスケジュールとは限らない. その背景にあるのが, 汎用的な問題解決プロセスとしての「思考プロセス」(すごく一般的な名前だけどここでは固有名詞) と価値を計算するための「スループット会計」(注1) である.

注1: 会計というと会計的な何かを思い浮かべるが, スループット会計は実はもっと一般的な価値計算のシステムでもある. またスループットというと普通は単位時間あたりの量を思い浮かべるが, ここでのスループットは実は投資に対する価値の増加分である. この辺の独特な言葉遣いは制約理論を神秘化:-) している一つの要因のように思われる.

制約理論の中心になるのはアーティファクト (何か人手が加わったモノ) が工程を経るごとにどのように価値を増していくかを表すバリュー・チェーンである. これは素人目にはリーン生産方式の「価値の流れ」とほぼ同じように見える. この価値の流れの滞り (注2) とその理由を見つけ出すのが思考プロセスであり, 価値の流れの滞りを取り除く方法がCCPMであり, 価値の流れを目に見えるように数値化するのがスループット会計であるととりあえずは考えてもよさそうだ.

注2: ここで滞りといっているものには実は2種類あって, 一つは流れの途中でモノがたまってしまうこと. もう一つは流れ全体が必要以上に長くなってしまうことだ. 制約理論ではどちらも良くないと考える.

例えば典型的なソフトウェア開発の工程をバリュー・チェーンとして表すと次のようになる.

最初に与えられたアイデアが分析, 設計, 実装, テストと工程を経るごとに価値を増していくと考える. これらの工程 (前回の用語を使えばセル, 特にアクティビティ・セルになる) は並列に実行可能だが, うまく「同期」しなければならない. つまり各セル間での成果物の受け渡しが各セルに待ちが発生しないようなうまいタイミングで行われなければならない.

次の図は「うまくいっている」例をケペル (株) の相馬純平氏が考案したスループットバランスチャートで表している. 横軸は時間を, 縦軸はセル間で受け渡されるモノの何らかの価値指標 (例えば機能数) を表す. このチャートは価値の流れをとてもよく可視化くれる. うまくいっている (滞留がない, つまりスループットが高い, あるいは制約がない) ということは各セルに対応する線がすべて平行になっているということだ.

うまくいっていない (つまりモノが滞っている, 制約がある) と, 下の図のようになる. つまり線が平行でなくぶつかってしまったり, 開いたりしてしまうのだ. ぶつかってしまうということは, そのセルから先は仕事がなく, 遊んでいるということになるし, 開いてしまうということはその前のセルはいくらがんばっても仕方がないということになる. 下の図でいうと実装はがんばっているのだが, いくらがんばっても全体としては設計とテストが弱いからダメなわけである.

では同じことを例えばScrumで考えてみよう. ここでは一つのチーム (7人前後のメンバ) から成るプロジェクトの一回のスプリントを見てみる. Scrumでは一つのスプリントに一つのセルがあるだけだから (前回参照), 線 (おおよそバーンダウン・チャートの上下をひっくり返したようなものになるはずだ) は一本しかない! つまりScrumでは少なくとも一つのチームの一回のスプリントに関する限り, 制約はないのである!

いやいや本当はそんなことはあり得ないだろう. ではどうなっているかを見るために, Scrumチームの内部を顕微鏡で覗いてみよう. 実はScrumチームの中では制約が発生するたびにメンバが入れ替わり立ち替わり働いて制約を解消してしまうのである. つまり例えば誰かが何かを待つ状態になったら, 待っていないで別のこと (待たせている相手の作業など) をさっさとやり始めるのだ. だから外からは制約はないように見えるのである.

もっとも一つのプロジェクトの中に依存関係のある複数のチームが存在すれば, 前と同じこと (流れの滞り) が起き得るし, 内部で解消できない制約が発生すればスクラム・マスタの出動となる. また開発チームと顧客の間にも流れの滞りは起き得る. ただしこちらは1ヶ月という刻みで強制的に隔離されているのだが.

ここまで考えてきたのは価値の流れの途中でモノがたまってしまうことへの対処だった. では価値の流れ全体が長くなってしまうのはアジャイルではどうなるのだろうか. 制約理論ではその大きな原因の一つは各セルが, リスク・ヘッジのためのバッファを隠し持ってしまうことにあると見る. 例えば各セルがスケジュール上のリスクに対処するために50%ずつ多めの工期見積もりを出したとしよう (注3). するとプロジェクト全体のスケジュールが50%伸びることになるが, 通常隠し持たれたバッファは各セルで消費されてしまうので (さもなければ次回からはバッファを取り上げられてしまうだろうから), 実際の工期も50%伸びてしまう! (注4)

注3: (1) によれば, 工期に関する20%のリスク (不確実性) には50%のバッファが必要であるということだ. だから50%のバッファはたいていの場合, 取りすぎというわけではない.

注4: 本当はすべてのセルでバッファを必要するわけではないので, 同じリスクに対して全体のバッファはもっと減らせことが分かっている.

今度はXPを例にとって考えてみよう. XPではストーリにしろ, タスクにしろ, 見積もりは (少なくともチーム内では) オープンである. だから最終的に見積もりにコミットするのはメンバ個人であったとしても, 見積もりの過程はおおむね公開の場で行われる. だからバッファを隠し持つのは難しい. それでも個人的に「バッファが欲しい」という不安感は必ずあるだろう. XPではメンバ各人の不安感はプロジェクト全体でのプロジェクト速度の調節によって吸収される. したがってこれに関してメンバが不安になる必要はない. ベストを尽くすだけだ. 実は (3) でも同じことが「サバ取り」と「親方バッファ」というキーワードで詳しく述べられている. どちらも肝は情報の透明度を上げることによって, メンバはベストを尽くし, リスクに対する補償を個人に帰すのではなく, プロジェクトが負うようにすることだ.

(1) ではXP, Scrum, FDDなどに対して (本稿とは異なるさまざまな側面から) 制約理論とアジャイル・プロセスの比較対照が行われている. (1) の著者は特にFDDがお好みのようだが, 確かにFDDはXPやScrumに較べて制約理論の使い甲斐のあるプロセスかもしれない. (3) では「サバ取り」「親方バッファ」以外にも多くのキーワードで制約理論のソフトウェア開発プロジェクトへの応用を分かりやすく説いている.

2006.09.17
山田正樹 (メタボリックス)

Comments