定量的な報告 補足（進捗の数値化）

先日のエントリで、進捗の数値化について少し質問があったので補足を書きます。
＃ちなみに、これらはホントにごく一般的なプロジェクト管理の手法ですので、色々なキーワードをググれば直ぐに説明や例が出てきます。

1.進捗の数値化について
タスクレベルまで目標をブレイクダウン（分解）したという前提で、各タスクの進捗の数値化について、やり方を考えたいと思います。
タスクの性質によって、報告の仕方は異なると思いますが、以下に例を示します。

A、検討・調査など、タスクが完了しないと意味がないもの。　0%もしくは100%として報告
B、取り掛かることが大事なもの。テスト項目表の作成など。　作業が開始したら20%の進捗、完了したら100%の進捗として報告
C、仕様書・報告書の作成など、分量に成果が比例するもの。　報告書であれば、予定ページ数に対する現在ページ数の割合で報告

数値化するのが容易なCについては、問題ないと思います。
A/Bの違いは余りないと思いますが、「どうしてその進捗評価基準なのか」を自信をもって説明すればOKです。

進捗の数値化については、いろいろな考え方がありますので、プロジェクトを通じて同じ基準で評価していれば問題ないでしょう。

2.計画に対する進捗の報告の仕方
肝心のこれを書いていませんでしたが、計画はいわゆるガントチャートに書けばよいと思います。
縦方向に分解したタスク項目をツリー構造で示し、横方向に時間軸を示して、各タスクをスケジュールして配置します。

そして、各タスクの進捗状況を、タスクの棒の中に点を打つことで表現し、それらをすべてのタスクについて線でつないだのが、「イナズマチャート」です。
例はググると出てきます。

これでプロジェクト全体として現在遅れているのかどうかが一目で見渡せます。
計画に対して順調に進んでいれば、安心感が生まれます。
また、一つのタスクがネックになって、プロジェクト全体が進まない、ということも良く起こります。あるタスクが終わらないと、次のタスクが始められない、という「タスクの依存関係」が原因です。
この場合は、問題のタスクに対して、何らかのアクションをする必要があります。指導教員や上司に相談するなり、一人で抱え込まないことが重要です。

計画を立てたり、イナズマチャートで進捗報告することの良い点は、こうしたプロジェクトの問題点を明らかにすることが出来る事です。担当者しかプロジェクトの進み具合を把握していない、という状況は、その担当者が倒れたらそこでプロジェクトがおしまいです。なので、会社においては常に誰か他の人が仕事を継続できるようにプロジェクトの可視化・進捗報告というのをしてチームとして仕事を進めるわけです。

＃なお、タスクの依存関係については、計画を立てる段階で「ワークフロー図」を作成することで、明らかにする方法があります。これについては、いずれ機会があったら書きたいと思います。

＊＊＊

大学の研究に対して、会社みたいなことを持ち込んでも上手くいかないのでは、という考えは自問自答しています。特に学生にやらせることについては。ただ、会社に入ってチームでの技術開発をやるようになると、成果報告を定量的に、というのは上司からよく言われることなので、身につけておいて損はないスキルだと思います。

進捗報告の数値化には誤差がつきものですので、必ずしも実態を上手く表せているかどうかについては疑問が残ります。それが高じて「進捗報告の数値化など意味がない」とか「上司を納得させるためだけに進捗報告するのは無駄」といった考えに陥りがちです。特に上司との感情的な行き違いがある場合など、そのようなブラックな考えに染まりがちです。

進捗管理は時間も手間暇もかかりますので、私自身、一時そんな考えに支配されていました。なので、如何に時間と手間暇をかけずにやるかが重要だと思っています。
その為、「他人に見せるため」ではなくて、「自分のために」進捗管理するのが良いのではないか、と思っています。自分のためだけであれば、無駄なことはしませんので、時間もあまりかけなくて済むと思います。そうしておいて、もし説明を求められたら、ちょっと手間をかけて進捗報告する、というバランスが良いでしょう。

（会社で火のついたプロジェクトだと、進捗が良くないプロジェクトほど、頻繁に進捗報告を求められて、かえって進まない、ということが良くあります。これは精神を病む大きな原因になります）