変化するクリティカルチェーン
プロジェクトを進めていく中で、ボトルネックが変化するのと同じメカニズムで、クリティカルチェーンも変化するので、その長さも変動していく。
変化前の優先度の高いタスクが、クリティカルチェーンが変化後は優先度が低くなっているなんてことはざらに発生する。
この時にずっと過去のボトルネックと向き合っていると、
あまり全体最適に結びつかないタスクをこなしていることになり、
コストの無駄遣いになってしまうので、
バッファ傾向グラフをモニタリングしながら最新の優先度のものに向き合う。
クリティカルチェーンの長さが長くなるとバッファ傾向グラフ上では、
プロジェクト進捗率が減少し、バッファを増やしたわけではないので、
バッファ消費率は増加してしまう。
よって、新しいタスクが積まれたりした際には、
再度クリティカルチェーンはどこなのか？ということと、
バッファ傾向グラフをモニタリングして、正しい制約の位置を特定することに励む。
似たような現象
ソフトウェア開発でも同じようなメカニズムの現象がある。
過去のリファクタリング個所をずっとやり続けていたら、それは負債の解消活動として貢献になっていない。
優先度の高い箇所(コンポーネントXと呼ぶ)、負債を最も生み出しているような箇所に対する
リファクタリングを行う。
すると今度は別のボトルネック箇所(コンポーネントYと呼ぶ)が発生する。
この時に、ボトルネックの位置が変わっていないと妄信して、
その部分のリファクタリングを行い続けても、
負債はたいして解消されず、逆にコストだけがかかっている状況を作り出す。
CCPMはプロジェクト進捗上のリファクタリングといっても過言ではないかもしれない。
タスクの分割理由
ボトルネックの解消以外にも、タスクの構造を見直す活動もある。
たとえばその1つとして、タスクの分割などだ。
分割する理由として、以下の例を列挙する。
依存していない部分は分ける
初期段階で、以下の図のようにタスクA←タスクBという依存関係があったとする。
プロジェクトを進めていく中で、実はタスクAの一部分にしか依存していない、ということが判明したとする。
その場合には、依存していない部分は下図のように分割してあげる。
これらの改善活動は、必ず新しいタスクを積み上げる前に行うことが推奨。
設計原則と照らし合わせると
参照していない機能群は分割せよという、インターフェイス分離などの原則に近いものがある。
もしもタスクA1とA2とに分けなかったら次のような脅威が起こりうる。
分割していなかったとしたら、
タスクAの中のタスクA2部分に変更が入った際や、
タスクA2部分に遅延が発生した際にまで、
後続のタスクBがその影響を受けてしまう。
図程度の簡単な場合ならまだいいが、
もしもタスクBに依存した他のタスクが後続にあれば、
その影響リスクはどんどん跳ね上がる。
依存していないはずのものの影響を受けてしまうのは、設計原則的にも問題ありである。
分割しないままであった際のリスクなどをソフトウェア設計の時と同様にして考察し、メリットが上回ると考えられたら分割する。
粒度が大きいから分ける
稼働している中で、タスク粒度が大きいことが判明したら、
タスクの高凝集疎結合を意識しながら分割する。
タスクの削る作業
ODSCに貢献しないようなタスクは振り返りの中で削ってしまうこともある。
上記の説明のように、分割することはあっても、
統合したりすることは実際にはあまりない。
もともと1つのタスクの粒度感を2～10日程度で設計しているので、
変に統合したりすると、タスクの粒度を見誤る可能性が高いからだと思われる。
個人の考察
BPRのECRS原則をこのタスクの再設計の考え方に適用できるのでは？
と考えている。
その仮説では、まずはタスクの追加や分割などを考える前に、
いったん振り返りの段階で、削れる無駄なタスクはあっただろうか？
という分析を行って、削れそうなタスクを明らかにし、
ネットワーク図から削ってしまう。
複雑になればメンテコストが跳ね上がるので、この削る作業は各振り返りで行った方がいいと思われる。
そのうえで分割できるような箇所を探し、
次にRの段階で、タスクの割当先を変えた方がスムーズではないか？
を考察する。
次にタスク内容を簡素化できないか？とECRSの順番に沿って考えた上で、
タスクの追加積み上げを行う という手順を踏む。
統合が求められるであろうケース
以下は完全に単なる予想です。
実際にプロジェクトを進めていく中で、あるタスクの一部が
別のコンテキストのタスクの方に分類された方がいいと判明したとする。
その場合には、いったん分割したうえで、適切なコンテキストの方に
配置しなおす必要がある。
分割された単位が短い期間のものであれば、移動した先の関係性が密な別タスクと統合してもいい可能性がある。
たとえば上手でいうと、分割したタスクA1が、実は別のコンテキストbの方に配置した方がいいと判明した際に、たとえばタスクCと密結合していて、
かつタスク期間が短い場合には、タスクA1とタスクCを統合してしまうということ。
これはソフトウェアでいうところのクラスなどのモジュールを
別のパッケージに配置しなおすリファクタリング作業と非常に似ている。