制約理論を読みほどく：ソフトウェア開発をちゃんと考える（9）

今回は前回「セル生産方式＋アジャイルという枠組み」のセル生産方式＋アジャイルに続いて、制約理論＋アジャイルという枠組みを考えてみる。参考にしながら読むのは以下の書籍だ。ただし制約理論に関してはこれ（「ザ・ゴール」）は代表的な1冊にすぎず、さまざまなトピックに関して多くの書籍が出版されている。

» 2006年11月08日 12時00分 公開
[山田正樹，メタボリックス]

　今回参考にするのは以下の3冊である。

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

　筆者は制約理論の専門家ではないので、記述の中でもしかしたら大きな間違いを犯しているかもしれない。もし間違いがあればご指摘を賜りたい。

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

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

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

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

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

ALT 図1 ソフトウェア開発の工程をバリュー・チェーンとして表す

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

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

ALT 図2 「うまくいっている」例

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

ALT 図3 うまくいっていない（つまりモノが滞っている、制約がある）

　では、同じことを例えばScrum（開発方法論の1つ。詳しくは「SCRUM：超生産的ソフトウェア開発のための拡張パターン言語」を参照）で考えてみよう。ここでは1つのチーム（7人前後のメンバ）からなるプロジェクトの1回のスプリントを見てみる。Scrumでは1つのスプリントに1つのセルがあるだけだから（前回参照）、線（おおよそバーンダウン・チャートの上下をひっくり返したようなものになるはずだ）は1本しかない！ つまりScrumでは少なくとも1つのチームの1回のスプリントに関する限り、制約はないのである！

ALT 図4 Scrumでは少なくとも1つのチームの1回のスプリントに関する限り、制約はない

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

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

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

<注3> （1）によれば、工期に関する20％のリスク（不確実性）には50％のバッファが必要であるということだ。だから 50％のバッファはたいていの場合、取り過ぎというわけではない。
<注4> 本当はすべてのセルでバッファを必要とするわけではないので、同じリスクに対して全体のバッファはもっと減らせることが分かっている。

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

　（1）ではXP、Scrum、FDD（フィーチャ駆動開発。アジャイル開発プロセスの1つ）などに対して（本稿とは異なるさまざまな側面から）制約理論とアジャイル・プロセスの比較対照が行われている。（1）の著者は特にFDDがお好みのようだが、確かにFDDはXPやScrumに比べて制約理論の使いがいのあるプロセスかもしれない。（3）では「サバ取り」「親方バッファ」以外にも多くのキーワードで制約理論のソフトウェア開発プロジェクトへの応用を分かりやすく説いている。またアジャイルプロセス協議会のアジャイルTOCワーキング・グループでもアジャイル＋制約理論の学習、研究を行っている。

「ソフトウェア開発をちゃんと考える」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

あなたにおすすめの記事PR