工程管理とエクセル
新人プロジェクトリーダー『新米太郎』は、新たなプロジェクトのリーダーに任命されたようだ。先日のプロジェクト失敗を教訓に、今度は成功させてやる！とやる気満々の様子。
今日は、プロジェクトの開発工程におけるWBS（Work Breakdown Structure：作業分解構成図）を作成しているようだが、どうも悩んでいる。
太郎：センパーイ！今、開発プロジェクトのWBSを作っているんですけど、少し相談に乗ってもらえないでしょうか？
先輩：ああ、いいよ。開発工程のWBSか、どれどれ？
太郎：ありがとうございます。
太郎：今、基幹システムのマスタ登録機能（15機能）のカスタマイズを請け負うプロジェクトで、開発工程のWBSを作成しています。
先輩：うん、15機能のカスタマイズ開発だね。
太郎：はい。
実は、お客様からの要求で、顧客指定のエクセルフォーマットに開発進捗の状況を記載し、毎週報告を実施してほしいと言われているんです。
先輩：ほぅ、それで？
太郎：うちの会社のルールって、エクセル禁止ですよね？OBPMでスケジュール管理をするルールですから、OBPMのガントチャートにWBSを作ってスケジュール管理しなければいけないのですけど、顧客への進捗報告（顧客指定エクセル）をどうしたらいいのか悩んでいます。OBPMでのスケジュール管理と、顧客エクセルでの進捗管理とを二重でやるべきなんでしょうか？それとも、うちはエクセル管理禁止ルールだから、顧客に断りをする必要があるのでしょうか？他の先輩たちならどうするのだろう？と思いまして。
先輩：なるほどね、顧客指定のエクセルで進捗報告をする約束をしたんだね。
契約内容に、顧客指定エクセルで進捗報告をする条件があるなら、やらないといけないね。
そういう状況で効率的にスケジュール管理をする場合、同じことを2つやるのではなく、それぞれの役割と管理粒度をはじめに決めるといいよ。
工程管理の粒度
太郎：役割と管理粒度ですか？
先輩：そう、役割と管理粒度さ。
そもそも、工程管理の意味や必要性をきちんと理解しているか？
なんとなく機能名を並べて、進捗率を入力すればいいと思ってないよね？
太郎：そ、そんなことはありま．．．．．．あるかもしれません。
先輩：ふー。そんなことじゃないかと思ったよ。
工程管理というのは、ある成果物を完成させるために、作業工程を細分化し、必要なリソース（人、計画工数、原価）を割り当てて、所定の品質、決められた納期、予定原価の範囲内で効率的に構築することを目的とした管理活動だ。
だから、機能名を一覧で並べて、誰が開発するかを決めるだけでは管理粒度として粗すぎるし、1日程度で終わる作業工程まで細かくすると、今度は管理負荷が上がるだけで管理効率が悪くなる。だから、適切な管理粒度を意識することが大切になるんだ。
太郎：はい、管理粒度ですね、無意識にWBS作っていましたけど、きちんと言葉にしてどこまでWBSを分解するべきなのか、キチンと意識することが大切ということですね。
先輩：そうそう、わかっているじゃない。
『アカウントマスタ画面のカスタマイズ』をWBSに落とす場合、色んな方法はあるけれど、例えば第1階層（工程）に記載するのは機能名でいいだろう。これは、「アカウントマスタ画面の開発工程」という意味だよね。ここから、どの粒度までブレイクダウンしていくかを考えるといいよ。カスタマイズ要件が３つあるならば、その一つひとつを工程配下の「タスク」としてブレイクダウンしてみるんだ。そして、それぞれのタスクに対して担当者を割り当てて、完成までの計画工数を振る。
その時点で5日～10日程度のタスクであれば、それ以上ブレイクダウンする必要はあまりないだろう。1つのタスクの期間が10日（2週間）を超えるようであれば、粒度が粗すぎるので、もう一段下のタスクに分解したほうがいい。逆に、5日以下の粒度にする必要があるかどうかは状況によって決めればいいと思うけど、私はこれ以上細かい分解はほとんどしないかな。進捗率を入力することを考えれば丁度いい粒度だと思うからね。仮に、1日で終わるタスクまで細かく分解したならば、進捗率の概念がなくなってしまうからね。1日のうちで、0％⇒100％しかないし。
太郎：なるほど、WBSの粒度はこんな感じの粒度を意識すればいいんですね。
1日 ～ 必要に応じて ～ 5日 ～ 丁度いい粒度 ～ 10日 ～ 粗すぎる
先輩：もう一つの例で言うと、もっと大きなカスタマイズの（1ヵ月以上かかる）場合、担当者も一人とは限らないよね。また、関係する機能（サブ機能や共通モジュール等）も複数あるのであれば、適切な粒度になるように機能を細分化して、それぞれに担当者、期間、計画工数を振るんだ。
そして、機能間の関係性（依存関係）があれば、依存の流れを意識した開発時期を計画することだ。サブモジュールができてないのにメインモジュールは作れない（部品がないのに、本体は組み立てられない）というわけだ。
太郎：なるほど、大きな計画工数であればあるほど、細分化したときのタスクの数は増えるし、それらの依存関係を意識したスケジュールを立てる必要性が出てくるわけですね。よく分かりました。
先輩：そういうこと。
適切な粒度で計画を立て、日々モニタリングすることによって、下記が可能になる。
- 遅延タスクを早期に発見
- その遅延によって他のタスクへどのような影響があるか判断
- 正常に戻すためにはどのようなリスケが必要か
- 担当の振り分け、入れ替えなどの実施
- 増員などのリソース計画を変化させるかの判断
そして、納期遅延することなく規定の品質を保った成果物を作り上げるんだよ。
工程管理の目的と役割
太郎：ところで、先輩この粒度のWBSをOBPMのガントチャートと、顧客指定エクセルの両方でやらないといけないんでしょうか？
先輩：そうだったね、顧客指定のエクセルには、どの粒度でWBSを記載するべきか、利用目的や役割をはっきりさせれば答えは出てこないかい？
太郎：目的、役割ですか？15機能のカスタマイズ開発の進捗状況を、毎週報告するために利用するってことですけど、役割とはどういうことでしょうか？
先輩：顧客への進捗報告を目的とするならば、そのエクセルの役割というのは、顧客が求める粒度で適切な進捗状況が記載されることが大切ということさ。
言い方を変えると、さっき話をした工程管理（遅延なく成果物を完成させるためにモニタリング）をする役割はOBPMのガントチャートであり、それらを機能単位（顧客報告に必要な粒度）でサマリした進捗報告書がエクセルの役割だということさ。
太郎：な、なるほど！
同じ粒度で二重管理をするのではなく、何のために作成するのか、目的や役割を理解したうえで、それぞれの粒度で作成すればいいということですね。
先輩：そういうこと。
自社内部で管理している詳細なWBSをそのまま顧客に報告する必要はないし、そのような細かさで報告されても、顧客側も見にくくて困るんじゃないかな？
もちろん、その細かさを要求されているなら話は別だけど、進捗報告という目的を果たすだけであれば、15機能の進捗状況が簡潔に適切に記載されていればよいはずさ。進捗率を表現するのであれば、OBPMの工程レベルの進捗率を参考にすればいいのさ。
太郎：わかりました！目的を意識して使い分けてみます。
ところで先輩、うちの会社、エクセルでのスケジュール管理はルール違反だと思うんですけど、そこは大丈夫なんでしょうか？
プロジェクト管理とエクセル
先輩：そのことか。
これも大事なことなんだけど、うちの会社では、エクセルの使用を禁止なんかしていないよ。
太郎：え？だって『脱Excel』を掲げてOBPMを利用しているんですよね？
それに、PMOからもOBPMの利用が必須で、エクセルでの管理はダメだって。
先輩：きちんと理解してほしい。
『脱Excel』というのは、プロジェクト管理ツールとしてエクセルを『正』とすることをやめると言う意味だよ。
ルールや基準がバラバラであったり、リアルタイム性に欠けたり、共有しにくいエクセルによるプロジェクト管理はやめて、全てが統合されたOBPMというツールに管理情報を集約することで、プロジェクト管理の正確性、標準化、見える化、高効率化を図るということさ。
だから、『脱Excel』＝効率的なプロジェクト管理をするため、OBPMの利用であってエクセル使用禁止ということではないからね。
太郎：そういうことですか、エクセルを使用することが問題なのではなく、エクセルをプロジェクト管理ツールとして『正』とすることがダメなんですね。
先輩：そうだよ。だから、効率よく計画を立てたり、見積作ったり、分析したり計算したり、今回のように、顧客への進捗報告のための手段に利用したり、プロジェクト管理を効率よく進めるためならば積極的に使っていいと思うよ。
ただし、プロジェクト管理において、エクセルの利用は一時的な範囲で使うこと。エクセルで作った管理情報をそのままエクセルに留めずに、きちんとOBPMへ反映（添付も可能）して、必ず正しい情報がOBPMに集約され、日々の管理がOBPMで実施できていることが大切であり、うちの会社のルールなんだ。
太郎：はい、よく分かりました！
これからは、管理の目的や役割などにも目を向けて、効率よく管理できるよう精進します。
