製造業のユーザー様から「TimeTracker NXで予実管理はできますか？どの機能を使えばできますか？」とご質問を頂くことが多いので、今回は予実管理のやり方に関して書いていきます。
市販ツールのため、できること と できないこと があります。その点を整理しながら紹介します。
「予実管理」といっても、色々な定義があります。TimeTracker NXで行える予実管理は2つです。
A：【計画期間と実績工数入力期間との比較】
B：【計画工数と実績工数との比較】
Aは、ガントチャート上に、実績線を表示することで、比較することができます。
※参考サイト：実績線を表示する
よくお問い合わせ頂くのはBのほうです。
今回はB【計画工数と実績工数との比較】。そのなかでも「リソースごと計画工数と実績工数の比較する」というテーマで解説をします。
単体プロジェクト内であれば、ワークアイテムごとの計画工数と実績工数は簡単にできます。
入力条件は
・計画工数をプロジェクト画面上で入力すること
・実績工数をリソース(メンバー)がタイムシートで入力すること
上記を満たせば表示することができます。
プロジェクト横断でプロジェクト単位、工程単位で集計も可能です。
入力条件は下記です。
・集計対象の末端のアイテム（タスク）の期間（開始日・終了日）が入っているか
・集計対象の末端のアイテム（タスク）にリーダーが割り当てられているか
・集計対象のフィールド（計画工数・実績工数など）に値が設定されている。
このようにプロジェクト横断して、予実管理が可能です。
今回ご質問を頂いたユーザーからは「リソースごと、各タスクごとの予実管理を行いたい」と要望を頂いています。
「入力」「出力」２つの観点でお伝えいたします。
■結論
・リソース(メンバー)ごとの実績工数の入力はできる(タイムシートで30秒で実績入力可能)
・リソース(メンバー)ごとに対しての計画工数入力はできるが
管理者の入力負荷と計画工数が期間案分させることを受容できかるかによる。WBS上のタスク数が爆発する可能性もある
■入力
①リソース(メンバー)ごと各タスクごと入力することはできます。
ただし、入力にかかる手間は受容していただく必要があります。
※参考サイト：リソースの計画工数を編集する
②短期間のタスクとしてアイテムを作成する
計画工数を実態に合わせて設定するためには各タスクに期間を入力する必要あります。
この入力を行うことで、管理が複雑になるリスクがあります。
あるユーザー様は「タスク爆発」を起こしていますが、各日・週ごとのタスクの予実を計るためには必要ということで、実施をしています。
※下記はあるユーザー様の「会議タスクの予実管理」のWBS例です。
※タスクを詳細化し、かつリソースごとの計画工数の入力を行うことは負荷がかかります。
■出力
NX5.5ではリソースごとタスクごとの表示はできません(プロジェクト、工程レベルは可能)。
しかし、次期バージョンでは、リソース(メンバー)ごとの予実表示は可能となります。
・表示期間を指定し
・プロジェクト横断して
・リソース(メンバー)ごと
・タスクごと
・年、月、週、日ごと
表示ができるようになります。
タスクに期間が入っていることが、条件です。
プロジェクトの工数の中には、「ゴースト工数」「イービル工数」が潜んでいることはご存じでしょうか。
「ゴースト工数」とは、実際のプロジェクト予算や想定工程には入ってない対応や作業によって発生する工数です。
メンバーが善意や無料対応で行っている作業のため、工数管理上に出てこない、隠された工数のことです。その名のとおり、亡霊(ghost)です。
ゴースト工数がかさむと、計画工数通りプロジェクトを終了させているのにメンバーが疲弊している状態が見られます。
もう一つは、「イービル工数」です。evilは「悪い」、「よこしまな」という意味です。人の心の弱さが、この工数を生み出します。
『このままいくと、計画コストオーバーするから工数入力しないでおこう』『手戻りが起こったけどタイムシートに入力はしないでおこう』『見なかったことにしよう』など都合悪い事実を入力しないと、実績工数は歪められます。
ユーザーにヒアリングすると「ゴースト工数」「イービル工数」が発生する背景には、プロジェクトの計画工数は最初から実現無理な計画として設定されている可能性があります。
昔からのどんぶり勘定で受注し、どんなに能力が高いメンバーがアサインされても採算を割ってしまう状況にある。そんな状態では予実管理自体が無意味になります。メンバーに負荷をかけるためマイナスかもしれません。
計画工数をいきなり入力しKPIにするのではなく、まずは各プロジェクトの実績工数の数値をフラットに計測することをおすすめします。
CAPDoを実際に業務に適用してみると、計画が起点となるPDCAよりも、先に現状把握をして見込みを立てた上で改善案を検討するCAPDoの方が敷居が低く、やりやすいと感じるはずです。
また、 CAPDoは最初に計画を必要としないので気軽に始めやすく、より素早く改善が開始できるようにもなります。
「急がば回れ」無理な計画値で、現場が疲弊する前に正確な実績工数を測定することおすすめします。
予実管理はその後からでも遅くはないと考えています。
参考サイト：CAPDoで改善サイクルを回す
実績工数をフラットに測定した結果、すでにスタートしているプロジェクトは採算割れの可能性が高い場合は、他のプロジェクトの工数を調整し、トータルで黒字にする努力が必要です。
採算割れの可能性が高い新規プロジェクトの場合は、受注前に顧客に事情を説明し、妥当な金額での受注を交渉するなど、計画倒れにしない方法を模索することが大切です。
参考サイト：「工数管理なんて意味ないよ」とは言わせない ～QCDを用いたソフト設計現場の仕事術～
簡単ではありますが、予実管理に関して事例を踏まえて書きました。
製品担当としては、入力の負荷がかかること、予実管理の目的を現場理解できず、工数管理の仕組みが瓦解することは避けたいです。
まずは、どんな入力があればプロジェクトの健全性をはかれるのか、チーム内で議論してみることをおすすめします。
私の経験上、マイクロマネジメントが成功した事例は少ないです。
「なぜ、やらなければならないのか？」「PMは管理しきれるのか？」「メンバーはやりきれるか？」納得感の醸成が、成功のカギになります。
本稿が皆さんの工数管理の一助になれれば幸いです。