Redmineにプロジェクト報告を機能追加するLycheeProjectReportプラグインが面白い

アジャイルウェアさんがLycheeProjectReportプラグインを公開されていた。
デモ画面を見て、色々アイデアが浮かんだのでラフなメモ書き。

【参考】
プロジェクトレポート | Lychee Redmine（ライチレッドマイン）でプロジェクトの見える化を。そして管理ももっと楽にしよう。

Kawabata Mitsuyoshiさんのツイート: "＼Lychee Redmine更新のお知らせ／ Lycheeプロジェクトレポートがリリースされました！ https://t.co/cbzZSIF03f... https://t.co/y3sdKxncWj"

akipiiさんのツイート: "興味深いプラグイン。経営層向けにRedmine をアピールできるだろう。RT @agilekawabata: Lycheeプロジェクトレポートがリリースされました！ https://t.co/iK2E6kOTui... https://t.co/yBsSWACS9h"

門屋　浩文さんのツイート: "@akipii @agilekawabata 精度の高いプロジェクトKPIの決め方についてコンサルが必要になりそう"

akipiiさんのツイート: "@MadoWindahead @agilekawabata どこの会社でも、事業部ごとの目標利益率はあるので、それとの整合性が必要でしょうね。また、経営層のマクロの観点とプロジェクトリーダーのミクロの観点は違うので、どう運用すべきか？面白いネタと思います"

【1】下記の宣伝文言がある。

(引用開始)
Redmineを利用している多くのPMOが、「親子プロジェクトの俯瞰的な確認」「マイルストーンの確認」「進捗・品質・コストの管理」に、頭を悩ませています。
Lycheeプロジェクトレポートは、「複数のプロジェクトの営みを統合管理したい」というPMOの悩みを解決します。
(引用終了)

長年経験してみた結果、Redmineというプロジェクト管理ツールは、現場のチーム向けのツールであり、経営者向けのツールではないと思う。
受託開発プロジェクトでタスク管理を行うと、計画していた当初のタスク以外に、予期しなかったバグや突発的な仕様変更がたくさん湧いてくる。
むしろ、そういう「予定していない」障害管理、「外部環境の変化や顧客要望の変化による」課題管理や仕様変更の管理の方がはるかに重要だ。

よって、Redmineのチケット管理では、細かな粒度でチケットを作っては消していくことが多くなる。
なぜなら、そういうバグ、課題とか、仕様の変更管理は、細かな粒度で発生する時が多いからだ。
あるいは、そういう細かな点まで気配りして、変更管理しなければ、すぐにソース管理でデグレが発生したり、マージ漏れが発生したりするからだ。

つまり、プロジェクトリーダーの観点では、Redmineのチケット管理を通じて、ミクロな観点でプロジェクト管理を運用していく。

【2】一方、部長や事業部長など経営層に近い人の観点では、マクロの観点であり、個別案件のマイクロマネジメントには興味はない。
彼らは、事業部全体で、複数のプロジェクトの進捗や採算の動向を把握したいのであり、個別案件の進捗管理や利益責任はプロジェクトリーダーに任せているからだ。
経営層は、事業部の配下にある複数のプロジェクトの採算全ての責任を負っているので、観点が違う。

すると、経営層としては、各プロジェクトの進捗や品質、採算の観点で毎週、毎月の報告が見たくなる。
つまり、経営層はRedmineの各プロジェクトの現状をまとめたサマリが欲しいのだ。

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索

従来は、このサマリがプロジェクト報告書であり、毎月末にプロジェクトリーダーがExcelの報告書を書くのが習わしだった。
この作業に、プロジェクトリーダーのかなりの管理工数が割かれているはずだ。

プロジェクトの現状は、Redmineチケットに全て蓄積されているが、そのままではプロジェクト報告にはならない。
トラッカー別、日別・月別、ステータス別など数多くの観点でチケット集計し、それらチケットを精査しなくてはならない。
経営層向けに報告するために、数値の正確さはもちろん、報告の文章と数値の整合性が取れていなくてはならないから、結構神経を使う。

しかも、PMOからは、各プロジェクトの進捗状況をお天気マークで表示しろ、とか、進捗や品質の閾値を元に進み具合を報告しろ、などと言われる。
いわゆる、プロジェクト報告の標準化を強いられるわけだが、プロジェクトリーダーの工数をさらに増やすだけ。

そして、実際の案件会議では、各プロジェクトの報告時間は限られるので、労力を使った報告書もさほど読まれないという悪循環があるだろう。

そういう実情を考えると、LycheeProjectReportプラグインのように、Redmineにプロジェクト報告の機能があればいいな、と以前から思っていた。

【3】では、プロジェクト報告に必要な機能は何なのか？

個人的にはいくつかあると思う。
1つは、プロジェクトの現状を指標(KPI)で数値化し、事前に決められた閾値で評価すること。
2つ目は、報告内容が記載できて、報告内容のテンプレート機能があること。
3つ目は、報告の履歴が残せて、それらを一覧で見れること。
最後に、プロジェクトの種類でKPIや閾値を分けて管理できること。

【3-1】プロジェクトの定期報告は、従来はExcelの報告書が多かったと思う。
しかし、経営層が欲しいサマリ情報は、Excelの報告書ではなく、Redmineに蓄積されたチケット情報を元に抽出された指標(KPI)が欲しいはずだからだ。

それらの情報はRedmineから即座にチケット集計でメトリクスを抽出できる。

たとえば、進捗は、全チケットのステータスや進捗率から計算できるだろう。
品質は、障害チケットからステータス別に集計すればいいだろう。
コストは、予定・実績工数が入力されている前提として、工数ベースでEVMを計算すればいいだろう。
その前提であれば、進捗もEVMからSPIで進捗度合いを評価できるだろう。

つまり、プロジェクト報告を保存する時点で、チケット集計するバッチを動かせば、その時点のメトリクスを保存できる。
KPIの採取はシステムによって自動化すれば、プロジェクトリーダーはその数値を参照して、報告内容を書くだけで良い。

毎月報告する運用であれば、毎月末にQCDの観点でKPIが保存されるので、報告の履歴から各KPIの時系列の推移も見れるはずだ。
そうすれば、第三者も、プロジェクトがどこで遅延が発生したか、どこで採算が悪化したのか、を把握しやすくなる。

また、進捗や採算の評価は、プロジェクトリーダー個人の判断ではなく、事業部で決めた閾値でもって判断するようにしたい。
なぜなら、事業部には社長から言い渡された目標売上高、目標利益率があるので、それらをブレイクダウンしたら、各案件の最低の利益ラインは分かるはずだから。

【3-2】また、そのKPIに、プロジェクトリーダーがコメントした報告の文章があると良い。
できれば、報告のテキストエリアには、IssueTemplateプラグインのように、報告テンプレートがあるとなお良いと思う。
なぜなら、各プロジェクトリーダーの報告内容は、記載ルールがなければ、バラバラになってしまい、本来書いて欲しい内容が漏れてしまいがちだからだ。

経営層やPMOの立場としては、QCD(進捗・品質・採算)の観点だけでなく、現状のプロジェクトのリスクや課題は何であるか、懸念事項は何であるか、も報告して欲しい。
普通は、どのプロジェクトも進捗遅延になりがちなので、遅延した原因と対策、今後の動向が知りたいのだ。

そして、彼らとしては、報告内容にある懸念事項の内容から、プロジェクトリーダーのリスク管理能力を見たいのだ。
進捗遅延の状況で、今のプロジェクトリーダーにそのまま任せても大丈夫か？
火を吹いた状況で、今のプロジェクトリーダーには、現状を改善できる能力はあるのか？

報告内容から、プロジェクトリーダーの分析能力、リスク対応能力を推量したいのだ。

LycheeProjectReportプラグインには、そういう報告テンプレート機能はあるのかな？

【3-3】実際の運用では、さらに、プロジェクトの種類ごとに、KPIや評価の閾値も分別して管理したい。
なぜなら、受託の新規開発案件ばかりではなく、定額請求の保守案件もあるだろうし、実費請求の要件定義プロジェクトなど多種多様な案件があるからだ。
特に、保守案件に、新規開発案件のKPIをそのまま適用しても上手く評価できないだろう。

保守案件は普通、毎月の定額請求なので、毎月の検収金額は決まっている。
すると、その案件に張り付くメンバーも固定されていて、彼らの人件費や工数は既に大枠は決まっている。
その予算内で回るように、進捗管理すべきだから。

普通のSIerでは、新規の受託開発案件で1次開発は赤字であっても、2次開発以後や保守案件では黒字化するのが普通なので、そういう保守案件のコスト管理の方が重要だったりする。

したがって、受託開発、保守、請負契約、定額請求、実費請求などの種類に応じた指標や閾値を設定できるようにしたい。
特に、大企業や大きな事業部では、PJの数も多いし種類も様々なので、PJの種類別の指標値の設定管理の機能はすごく重要だろうと思う。

LycheeProjectReportプラグインを見ると、進捗・品質・コストごとに、指標を新規登録できて、閾値も区別できる機能がある。
つまり、そういう観点では、よく考えられていると思う。

【4】第三者の観点で好き勝手に言わせてもらえれば、プロジェクト報告プラグインは、EVMやリソース管理、ガントチャート、信頼度成長曲線などと連動しているとなお良い。
なぜなら、経営層が各プロジェクトのサマリを報告機能で見ていた時、もっと詳細な情報を知りたいと思ったら、EVMやガントチャートを見たくなるからだ。
彼らも、サマリ情報からドリルダウンして、詳細な情報を見たくなるだろうから。

但し、彼らはチケット一覧の画面は見たくないだろう。
なぜなら、チケット一覧を見ても、たくさんのチケットが無造作に蓄積されているだけであり、そこから意味ある情報を読み取るのは面倒だから。
むしろ、EVMやガントチャート、信頼度成長曲線を見た方が、進捗状況や採算状況が分かりやすいから。

つまり、プロジェクト報告の機能は、QCDの観点によるチケット集計の画面と連動している方が使いやすいはず。
たとえば、プロジェクト報告の画面で、報告内容の横にあるKPIの数値にリンクがあり、そのリンクから、EVMやリソース管理、ガントチャート、信頼度成長曲線の画面へ遷移できるといいだろう。

実際、そこまで作り込んでいるかどうか知らないが、色んな可能性を秘めていると思う。