プロジェクトに新規参入者するメンバの受け入れ −情報にはたどりやすく−

前回のおさらいは プロジェクトに新規参入者するメンバの受け入れ −誰が当事者か− では、当事者である立ち上げ時からのメンバは当事者としての視点で途中参画者のメンバの「困りそうなこと」を解決する解が必要である、とわかったのでした。


だから、結局どうするの
立ち上げ時のメンバ間には有形無形の情報が横たわり、途中参画者には有形の情報は見えるけれど無形の情報や有形の情報がなぜそう成り立ったかの経緯は一つひとつ追っていくか、聞いて回るかをしなければそれを埋めることはできません。


少なくとも、そうした手がかりがなければ、立ち上げ時からのメンバは途中参画者が疑問を生じる度に応対することが必要になります。それをあえて、認識して、立ち上げ時のメンバと途中参画者のメンバとのコミュニケーションラインを育てる目的でコストを払うなら、それはそれでありだとは思いますがあまりスマートではないように思えます。


ここで表9に対策の列を追加します。

表10

項目 ↓立ち上げ時_____完了↓ 情報の形状 対策
「立ち上げメンバによる関係性」 無→→→→→→→→→→→→大 無形:視覚化できない _
「アウトプットの創出」 無→→→→→→→→→→→→多 有形:文書・プログラムの形態 _
「計画予算の執行分の消費による残り」 上限→→→→→→→→→→下限 有形:コスト管理による予実 _
「経過時間分の消費による残り」 最大→→→→→→→→→→納期 有形:契約期間と参画時点の差異 _
プロジェクトの進行 無→→→→→→→→→→→完了 無形:契約期間と参画時点の差異とWBSの進度に応じた出来高の差異 _


基本的に有形無形に情報へのアプローチは「たどりやすく」しておく、です。それが設計書などの有形のアウトプットであっても「たどりやすく」してあることが必要です。


この「たどりやすく」しておくことは、実は、途中参画者のメンバだけを意識しているものではなく、立ち上げ時からのメンバに対しても、意識をして置かなければならないことなのです。


プロジェクトの生産性を口に出す人に限って、こうした「たどりやすさ」を意識したアプローチのデザインに無頓着なことが多いです。そうしたプロジェクトを見るたびにメンバは大変だなぁ、と思うんですよね。


「たどりやすく」一つとっても、これはプロジェクト内部の業務プロセスのデザインです。これを見えるようにするだけでだいぶ変わってきます。

表11

項目 ↓立ち上げ時_____完了↓ 情報の形状 対策
「立ち上げメンバによる関係性」 無→→→→→→→→→→→→大 無形:視覚化できない ・運用ルールがあれば視覚化する
「アウトプットの創出」 無→→→→→→→→→→→→多 有形:文書・プログラムの形態 ・アウトプットは構成管理ツールで管理・開示する
・検討途中の情報や経緯はチケットなどに記録・開示する
「計画予算の執行分の消費による残り」 上限→→→→→→→→→→下限 有形:コスト管理による予実 ・need to know、管理レベルに応じて提示する
(例:ワークロードの枠だけ提示する/予算情報を共有する)
「経過時間分の消費による残り」 最大→→→→→→→→→→納期 有形:契約期間と参画時点の差異 ・プロジェクト情報として構成管理ツールで管理・開示する
プロジェクトの進行 無→→→→→→→→→→→完了 無形:契約期間と参画時点の差異とWBSの進度に応じた出来高の差異 ???


項目ごとに対策を書いてしまえば、当たり前のコトしかでてきません。結局、有形無形に関わらず情報を共有するには視覚化するほかありません。


ただ、その視覚化も情報ごとにバラバラに入り口を用意するのとワンストップで用意するのどちらがいいかを考えれば実際に対策を実装するときの具体的なイメージは必然と得られると思います。実装は何でもいいですが、情報はワンストップとなるようにポータルチックに用立てることです。


ところで、表11の最後の行の対策は「???」になっていました。これ、このままでいいのでしょうか。すぐに思いつくやり方はPMBOKのEVMです。進捗と掛けた工数に見合う出来高が得られているか、ですから。


ただ、わざわざEVMを持ち出さなくても、作業プロセスを明示的にして、カンバンを用意して、進行と作業の完了条件を作業ごとに制御できれば代替はできます。この簡便な手法をとる場合は、労務状況も意識して把握してコストと関連しておかないとコストだけ棚に上げて計画したとおりに進行させるだけになってしまうので注意が必要です。