プロセスを分割してリリースポイントを作る - アドベントキャンドル2本目 -

前回に続き、クリスマス（注参照）に向けてのアドベントキャンドル2本目です。

プロセスと言うと管理対象のように思われるかも知れませんが、戦略的に実行するものです。プロセスをどのように構成・再構成するかによってプロジェクトの成否が変わります。今回は納期にリリースが間に合わなくなった際に、戦略的にプロセスを分割してリリースポイントを作る方法を説明します。

納期とリリースを分けて考える

プロジェクトの制御要素には、品質・リソース・納期・スコープがあります。このうちの納期だけを固定的に考えず、リリースを分けて考えます。

いわゆるSystem of systemsとよばれる複数のシステムから構成されるシステムでは、システムの結合開始がボトルネックになリ易く、リリース時期を守る事が全体の効率を高めます。

また、会計や学校のシステムなど年度に関わる業務においてもリリースの遅れは許されません。業務が滞ってしまうからです。

そこで、納期、つまり開発の完了は遅れても、システム間の結合や業務の開始であるリリースだけは守らないといけなくなります。

プロセスの分割

ここでいうプロセスの分割はWBSを書く場合とは異なります。WBSでは上位のプロセスや成果物がもれなく計画・見積もりできるように詳細化しますが、リリース時期を守る場合は無理やり分割することでリリースポイントを作ります。

上にあげたプロジェクトの制御要素のうち、納期を除いた品質・リソース・スコープを基準にプロセスを分割できます。それぞれにメリットとデメリットがあります。

品質

方法：テストレベルを詳細化して分割する。

例：正常系テストの完了時点でリリースする。長期ランニングテストの前にリリースする。など。

メリット：システム間結合の実施が可能になる。

デメリット：障害対応によってリリース後のテストが進まなくなる可能性がある。

TIPS：既知の障害を伝えておくと対応の負担が減る。

リソース

方法：リソースそのものは増やさざるを得ないので、リソースを割り当てるタスクを分割します。

例：対象の業務知識を必要とするタスクとあまり必要としない作業に分割して増員を容易にします。

メリット：対外的な全体計画をあまり変更せずに実施できる。客先へのアピールになる。

デメリット：最も生産性が低くなる方法。単純作業がうまく切り出せなければ、増員によるコミュニケーションや管理の負担によって逆効果になる事も少なくありません。

TIPS：ファイル共有によるコミュニケーションは破綻し易いので、予めチケットシステム等を導入しておくと連絡、質疑応答、進捗管理、などの破綻を少しは押さえる事ができるでしょう。

スコープ

方法：リリースする機能や成果物を分割する。

例： リリース時点で実行できるものとできないものを分ける。成果物のうち、完成しているものと完成していないものを分ける。

メリット：リリース内容が明確。体制を大きく変えなくて良い現実的な解決法。

デメリット：必要なものを限定できなければ実施できない。

TIPS：全ての機能が必要な場合は、機能ごとに品質レベルを変えることで全体スケジュールに影響を与えずにすむ場合がある。

おわりに

プロセスの分割は新しい方法ではなく、多くの管理者が工夫しながら実践されているでしょう。しかし、毎回、再発明するのではなく、整理する事で、伝達可能になり、様々なノウハウが集まり、より良く改善できるようになると思います。

今回説明した方法のうち、リソースによる方法は増員を前提とした一般的な方法でしたが、必ずしも成功しません。これは品質や機能によりプロセスを分割した場合も同じです。プロジャクトの状況に応じて、分割方法を選択し組み合わせる必要があります。

また、プロセスを分割した場合は通常の管理だけではうまくいきません。他チームを含むステークホルダーとの調整が必要になるほか、開発者と意見が食い違わないように開発作業の理解が必要でしょう。

プロセスと言うと管理の対象の様に思われる方が多いかもしれません。しかし、ここに挙げたように実践方法を整理して支援をすれば、経験の少ない管理者でもピークの人数を減らして効率を向上できる可能性があります。それは、プロセスモデリングの効果です。

次回は、プロセスのガードとドライブについて説明する予定です。

---

参考：CCPM

CCPMではリソースを固定して時間軸（リリース）を変化させると言われます。しかしその意味は、全体のリソースではなく単位時間あたりのリソース、つまり、体制（人数）を変化させないという事です。

CCPMは各プロセスにある理想見積もりの工数とバッファの工数を切り分けて、バッファの利用を変化させますので、体制を固定してリソースの配分とリリースを変化させる方法と考える事ができます。これもリソースの分割と考える事ができるでしょう。

---

注：クリスマスとクリスマスイブ

クリスマスというのは「Christ（キリスト）のmass（ミサ）」という意味で、キリストの誕生を祝う日の事です。誕生日ではありません（さすがにベツレヘムでも12月25日に馬小屋で生まれると命の危険があるでしょう）。

クリスマスイブというのは12月24日の夜の事ですが、教会歴では12月24日の日没からがクリスマスなので前日ではありません。祇園祭に宵々山はあっても、クリスマスイブイブは誤用です。

ちなみに、12月25日はキリスト教がローマ帝国の国教となり、ミトラ教の太陽神のお祭りができなくなったので、その日をクリスマスにあてはめたそうです。意外と政治的な背景があるものですね。