プロセスを分割してリリースポイントを作る - アドベントキャンドル2本目 -
前回に続き、クリスマス(注参照)に向けてのアドベントキャンドル2本目です。
プロセスと言うと管理対象のように思われるかも知れませんが、戦略的に実行するものです。プロセスをどのように構成・再構成するかによってプロジェクトの成否が変わります。今回は納期にリリースが間に合わなくなった際に、戦略的にプロセスを分割してリリースポイントを作る方法を説明します。
納期とリリースを分けて考える
プロジェクトの制御要素には、品質・リソース・納期・スコープがあります。このうちの納期だけを固定的に考えず、リリースを分けて考えます。
いわゆるSystem of systemsとよばれる複数のシステムから構成されるシステムでは、システムの結合開始がボトルネックになリ易く、リリース時期を守る事が全体の効率を高めます。
また、会計や学校のシステムなど年度に関わる業務においてもリリースの遅れは許されません。業務が滞ってしまうからです。
そこで、納期、つまり開発の完了は遅れても、システム間の結合や業務の開始であるリリースだけは守らないといけなくなります。
プロセスの分割
ここでいうプロセスの分割はWBSを書く場合とは異なります。WBSでは上位のプロセスや成果物がもれなく計画・見積もりできるように詳細化しますが、リリース時期を守る場合は無理やり分割することでリリースポイントを作ります。
上にあげたプロジェクトの制御要素のうち、納期を除いた品質・リソース・スコープを基準にプロセスを分割できます。それぞれにメリットとデメリットがあります。
品質
方法:テストレベルを詳細化して分割する。
例:正常系テストの完了時点でリリースする。長期ランニングテストの前にリリースする。など。
メリット:システム間結合の実施が可能になる。
デメリット:障害対応によってリリース後のテストが進まなくなる可能性がある。
TIPS:既知の障害を伝えておくと対応の負担が減る。
リソース
方法:リソースそのものは増やさざるを得ないので、リソースを割り当てるタスクを分割します。
例:対象の業務知識を必要とするタスクとあまり必要としない作業に分割して増員を容易にします。
メリット:対外的な全体計画をあまり変更せずに実施できる。客先へのアピールになる。
デメリット:最も生産性が低くなる方法。単純作業がうまく切り出せなければ、増員によるコミュニケーションや管理の負担によって逆効果になる事も少なくありません。
TIPS:ファイル共有によるコミュニケーションは破綻し易いので、予めチケットシステム等を導入しておくと連絡、質疑応答、進捗管理、などの破綻を少しは押さえる事ができるでしょう。
スコープ
方法:リリースする機能や成果物を分割する。
例: リリース時点で実行できるものとできないものを分ける。成果物のうち、完成しているものと完成していないものを分ける。
メリット:リリース内容が明確。体制を大きく変えなくて良い現実的な解決法。
デメリット:必要なものを限定できなければ実施できない。
TIPS:全ての機能が必要な場合は、機能ごとに品質レベルを変えることで全体スケジュールに影響を与えずにすむ場合がある。
おわりに
プロセスの分割は新しい方法ではなく、多くの管理者が工夫しながら実践されているでしょう。しかし、毎回、再発明するのではなく、整理する事で、伝達可能になり、様々なノウハウが集まり、より良く改善できるようになると思います。
今回説明した方法のうち、リソースによる方法は増員を前提とした一般的な方法でしたが、必ずしも成功しません。これは品質や機能によりプロセスを分割した場合も同じです。プロジャクトの状況に応じて、分割方法を選択し組み合わせる必要があります。
また、プロセスを分割した場合は通常の管理だけではうまくいきません。他チームを含むステークホルダーとの調整が必要になるほか、開発者と意見が食い違わないように開発作業の理解が必要でしょう。
プロセスと言うと管理の対象の様に思われる方が多いかもしれません。しかし、ここに挙げたように実践方法を整理して支援をすれば、経験の少ない管理者でもピークの人数を減らして効率を向上できる可能性があります。それは、プロセスモデリングの効果です。
次回は、プロセスのガードとドライブについて説明する予定です。
参考:CCPM
CCPMではリソースを固定して時間軸(リリース)を変化させると言われます。しかしその意味は、全体のリソースではなく単位時間あたりのリソース、つまり、体制(人数)を変化させないという事です。
CCPMは各プロセスにある理想見積もりの工数とバッファの工数を切り分けて、バッファの利用を変化させますので、体制を固定してリソースの配分とリリースを変化させる方法と考える事ができます。これもリソースの分割と考える事ができるでしょう。
注:クリスマスとクリスマスイブ
クリスマスというのは「Christ(キリスト)のmass(ミサ)」という意味で、キリストの誕生を祝う日の事です。誕生日ではありません(さすがにベツレヘムでも12月25日に馬小屋で生まれると命の危険があるでしょう)。
クリスマスイブというのは12月24日の夜の事ですが、教会歴では12月24日の日没からがクリスマスなので前日ではありません。祇園祭に宵々山はあっても、クリスマスイブイブは誤用です。
ちなみに、12月25日はキリスト教がローマ帝国の国教となり、ミトラ教の太陽神のお祭りができなくなったので、その日をクリスマスにあてはめたそうです。意外と政治的な背景があるものですね。
« 管理強化はプロセス問題を解決しない(こともある)- アドベントキャンドル1本目 - | トップページ | トップダウンのWF、ボトムアップのスクラム、その成功の鍵 - アドベントキャンドル3本目 - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« 管理強化はプロセス問題を解決しない(こともある)- アドベントキャンドル1本目 - | トップページ | トップダウンのWF、ボトムアップのスクラム、その成功の鍵 - アドベントキャンドル3本目 - »
コメント