どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
CCPMのおはなし3-10(実践編10):番外編◆Ш邏氾喘罎らCCPMに切り替える方法
CCPMのおはなしシリーズです。
実践編紹介中です。具体的な実践手順を1つずつ紹介しておりましたが、一旦CCPMでの計画方法に対する補足情報を番外編として紹介しておきます。
2つ目として、既にプロジェクトが動いている作業途中からCCPMに切り替える方法について紹介してみます。
※紹介する実践手法は、一部特殊な部分があることから”シングルCCPM”と名前付けしています。

-----------------------------
<参考情報>
本内容は連載的に紹介しております。本記事の前提や全体的な構成についてはこちら(リンク)を参照ください。
現在記載の内容は実践編です。こちらの前提や構成に関してはこちら(リンク)を確認ください。
-----------------------------

CCPMでの計画方法を紹介してみましたが、「全体の計画は手が出せない」「チームではプロジェクトの一部を担当している」といった状況が多いと思われます。そのため、本記事で紹介するシリーズでは、計画途中の段階で一部をCCPMにする方法にも対応できるよう考えております。


■CCPMの導入における2パターン

CCPMの導入方法として、前回までには「CCPMの計画を作成する」方法を紹介しておりした。
しかし、実際には計画から作業が入ることが出来ない場合も有りますし、プロジェクトの活動途中で困った状況に陥り、CCPMが適用できないか?と考えることもあるはずです。

そのため、この記事のシリーズでは「作業途中からCCPMに切り替える方法」についても紹介します。

既に、以下の記事でも一部については触れております。
一般的なCCPM実践手順と、紹介する方法の実践手順の違いと制限事項
「■”シングルCCPM”のメリット」が対象。

全体的な手順の流れとして示してみると、2パターンの流れは以下のようになります。
全体の流れ2つ
※クリックで拡大。

今まで紹介していた内容は、上側の赤い矢印の流れになります。
今回紹介する内容は、計画は既に存在している状況で、CCPMの管理対象を捉えてクリティカルチェーンを決めることで一部CCPM的に実施するという下側の青い矢印の流れになります。

なお、実体験的には最初からCCPMの計画を立てるよりも、こちらの手法の方が使用することが多いイメージです。


■既に計画がある場合のCCPM導入手順

一部状況を限定して紹介させて頂きます。
小さなチームが全体の計画の一部を実行するにあたってCCPMを導入するという想定にしておきます。
ここでは、とある5人くらいのチームが大きな計画の中で作業しているとしておきましょう。

★ODSCを決める方が良い?
ODSCは出来る限り確認しておいた方が良いです。
ただ、限定的なクリティカルチェーンを決める場合には、対象となる成果物のODSCが確認できたほうが達成のための手段を調整する際に役立ちます。


★既存の計画からクリティカルチェーン範囲を決める
本記事のシリーズで紹介している”シングルCCPM”のExcelひな型を使う前提であれば、(存在している前提の)大きな計画から2〜4か月程度の範囲の作業を切り出してクリティカルチェーン範囲として定義して活動しましょう。

ソフトウェア開発であれば、1回のイテレーションや詳細設計、結合テストといったプロセスの1つ2つに焦点をあてることで、範囲は決めやすいのと思います。
既存計画から範囲決め
※クリックで拡大。

例として、コーディングから結合テストにおけるクラスAに関わるタスクのみをクリティカルチェーンの範囲とするケースを上記図に示しています。
なお、既存の計画がある場合には「リソース制約」を考慮しているか確認をしておいた方が良いです。
※「リソース制約」を考慮する点に関しては、次回の番外編で紹介します。


★クリティカルチェーンを決める
この部分は紹介した内容と変わりませんので、以下をご確認ください。
計画を作成する:クリティカルチェーンを決める


■計画は何となくあるけど、抽象的だったり見積りが無い場合

「要求分析」や「単体テスト」などの抽象的な項目で「計画はあるんだ!」と言っている場合もあります。
まあ、この辺はCCPMをやる以前の問題がありますね…。

このような場合には、個々の「単体テスト」を実施するために必要なタスクを分解して、そのタスクからクリティカルチェーンを導き出して管理することになります。
いい加減な計画からの対策
※クリックで拡大。

上記まで出来れば、クリティカルチェーンは特定できそうです。

抽象的な項目で期間を決めている場合、タスクを分解してみると思った以上に作業が多くって、元の予定工期が短すぎたりすることが多いんですよね…

なお、このような抽象的な項目で計画したつもりになっている組織の場合には、タスク分解後に「分解したタスクを見積ってください」とお願いしても「やったことないので出来ない!」といったことを言われてしまう可能性も有ります。
この場合には、”「半日・1日・3日・4日以上」から選択してください”、といった選択式で依頼することで見積りを行うことも可能となります。


■計画が無い組織の場合

まあ、そもそも「作業中だけど計画なんてありません!」といった状況では、おとなしく計画を作り直す作業を優先した方が良いでしょう。CCPM以前にプロジェクトマネジメントが崩壊してます。
このような場合には、あらためてCCPMの計画を作成する手順を最初から進めて行く方が良いと思います。


以上、計画途中から一部でもCCPMにする方法について紹介してみました。
現場で活動をしていると最初からCCPMの計画を作るよりも、こちらで紹介したような内容を実施する場合の方が多いかもしれません。

次回は、クリティカルチェーンの決定と同時に行っておくと役立つ、「制約」を明確にする方法について紹介します。
| TOC/TOCfE/CCPM | 17:23 | comments(0) | - |









    123
45678910
11121314151617
18192021222324
252627282930 
<< November 2018 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ