SaaS ERPのプロジェクトダッシュボード
以前の投稿「ERPを初めて導入される方でも安心のプロジェクト運営をWrikeで実現」では、Wrikeでプロジェクトを可視化して、誰もがプロジェクトを高次元で運営できることをお伝えしました。今回はその内のプロジェクトダッシュボードに触れたいと思います。それは、プロジェクトダッシュボードが、プロジェクトマネージャーだけのものではなく、プロジェクトに関わる全ての方が、このボードを見て自分の領域だけではなく、他のチームやメンバーの状況を把握して、助け合いの精神に基づいて、相互補完するためのものだからです。
ダッシュボードの種類には、プロジェクト全体進捗管理、課題管理、拡張機能管理、障害管理の4ボードがあります。一つづつ説明していきますが、その前に全てのダッシュボードの共通点について説明します。
プロジェクトの全ての活動はタスクとしてWBSに登録します。もちろん、クライアントのタスクも登録します。タスクの種類は、製品トレーニング、会議、CRPセッション（実機検証）、課題、障害、テスト、MoSCoW（要求管理）、データ移行マッピング、データ移行実施、ビジネスプロセス評価、帳票、メンバー習熟度、プロジェクトリスクです。細かく分類していますが、その理由は、これらのタスクは全てステータスが異なるからです。例えば、会議タスクであればステータスは、「新規」、「調整中」、「計画済」、「完了」、「キャンセル」とシンプルです。これが課題管理だと「新規」、「担当者割当済」、「差し戻し」、「処理中」、「完了承認待ち」、「完了」、「保留」、「キャンセル」といったように承認プロセスが加わります。タスクを活動分類に分けてステータスをそのタスクに基づいたものにすることで、プロジェクト管理が実態に則してわかりやすくなるのです。そして、各ダッシュボードの分類から個々のタスクにたどれる様にします。ちなみに、管理を細かくしてもWrikeであれば何も手間なことはありません。
次の共通点は担当者です。タスクには担当者が割り当てられます。担当者の属性には、クライアントとベンダーなどの所属会社。販売や生産などの業務チーム。マネージメント、プロジェクトメンバー、エンドユーザーなどの役割があります。チームは、Three in a boxといって、クライアントとベンダー、そしてパートナー（現行システムのベンダーなど）を同じチーム（ボックス）とすることで、会社間の垣根を払い、３つの会社が一つになって目標を達成するのに役立ちます。しばしばプロジェクトでは、「クライアントとベンダーのどっちがボールを持っているか？」といった議論が交わされますが、これは会社間の垣根を作ってしまう原因になるので、よくありません。状況をチーム単位で測ることで、プロジェクトが会社の垣根を超えて、まさにチーム一丸となれるのです。これから説明するダッシュボードの全てにおいて、このチームを軸とした管理が行われます。
それでは、プロジェクト全体進捗ボードから見ていきましょう。このボードの目的は、プロジェクトの健全性を確認することです。全タスク数とその完了数および遅延数。タスクの完了推移。タスク種類ごとの比率。作業予定と作業実績の総時間および完了したタスクの予定時間と実績時間。チームごとの作業時間比率および担当者ごとの作業時間です。この全体進捗ボードで読み取れることは、例えば、リソースが適切に割り当てられているかや、タスク種類がフェーズに沿った比率になっているかなどです。プロジェクトの初期段階では、課題の比率は5%以下ですが、後半では20%に達します。フェーズごとにおおよそのタスク数が決まっているので、例えば開発構築フェーズのタスク数が想定より少ない場合は、まだ拡張機能開発などのタスクがブレイクダウンされていないのだとわかります。
次は課題管理ボードです。これには少し時間をかけて説明します。ダッシュボードの一段目には課題総数と完了数および遅延数を表示して、課題状況を瞬時に把握できるようにします。次の段では、課題発生日と完了日との関係を示し、課題が発散しているのか収束段階に入っているのかを確認します。プロジェクトの後半でもまだ課題が発散段階であるならば、どの課題分類が増加傾向にあるのかを確認して手を打ちます。例えば、プロジェクトが後半に差し掛かっているにも関わらず、「ビジネスプロセス課題」が増加傾向にあるならば、実機検証に立ち戻る必要があります。課題分類については、「課題状況から読み解く、プロジェクトの健康状態」で詳しく説明しています。
次の段では、チームごとの課題状況を確認します。課題がチームで偏りがあるならば、そのチームの他のタスク状況と見比べて全体の進捗に課題の負担が影響しているのかを判断します。
次にアラートです。例えば、「要チーム横断」のアラートが検出されたら、それはチーム内で完結できないことを意味していますので、部門を横断した横串会議の議題とします。アラートが「要ステコミ」ならば、プロジェクトを超えた課題なので、会社全体の取り組みとした対応が必要です。この様に、アラートは課題を個人に留めない仕組みであり、そのためには、課題アラートとコミュニケーションプランにおける会議体を関連付けることが肝心です。
次に課題の承認待ち状況を上げます。課題は起票者が対応結果を承認するのが基本フローです。ですが、プロジェクトでは課題が起票されたものの、そのまま放置されることが起こります。これを防ぐ手段として、課題では承認者にも期日を設けて、承認を促すためにボードで可視化します。こうすることで、例えば、リードタイムの定義が決まらないとMRPの実機検証ができない、といった後続タスクの遅延を回避できる様になります。
次に課題対応時間です。課題はプロジェクト全体の20%ほどの時間を必要とします。これを目安に作業時間を評価します。プロジェクト全体の作業実績時間と課題に要した時間の関係を示すのです。
課題管理ボードの最後は期日管理です。これはヒートマップで表します。プロジェクトでは、突如として数十件もの遅延が発生することがあります。これはいわゆる「夏休みの宿題症候群」からくるものです。期日を取り敢えず週末や月末にしてしまうために起こる事象です。この対策にはヒートマップを用います。表では気付きにくいことが、ヒートマップにすると瞬時に気付けます。期日は遅延だけではなく、週末や月末に偏っていないかも確認するのです。
次は拡張機能管理ボードです。ERPプロジェクト失敗の原因は、その多くが想定以上のアドオン開発が発生したことによるものです。従いまして、このダッシュボードでは、拡張機能開発の抑制効果も求められます。
拡張機能管理ボードの一段目は、他のボードと同じ様に、拡張機能開発の要求数と承認数（開発着手が決定した数）、開発中、完了数および遅延数を表示します。
二段目には、起票日と完了日を表示します。適切なタイミングで起票されているのかが重要です。
次に承認状況を表します。開発要求を着手して良いかを承認するのはクライアントのビジネスプロセスオーナー（業務責任者、以下BPO）です。従ってBPOは拡張機能要求が正当性を持ち、前後のプロセスと整合性がとれているのかを業務の観点で確認しなければなりません。また、この時に費用も確認するので費用対効果とプロジェクト予算の消化状況も鑑みなければならないのです。以前のプロジェクトで、起票の8割がBPOによって否決されたことがありました。コストカットで有名な会社なのですが、その理念はプロジェクトでも生かされたのです。正当な理由がないもの（例えば、今やっているから）は全て否決されていました。当時、プロジェクトマネージャーだった私は、否決された拡張機能要求のビジネスインパクトを調べるようにクライアントに依頼したほどです。これは行き過ぎた例かもしれませんが、拡張機能要求は適切な承認者を通じて行われるべきであり、ダッシュボードは、それを可視化するツールとして有益に作用しなければならないのです。
最後は障害管理です。障害管理の分類には、「障害発見工程」、「障害理由」、「障害分類」があります。
先ずは、「障害発見工程」から見ていきましょう。「障害発見工程」は、発見工程とテストレベルのマトリックスで表します。例えば、システム統合テストで発見された障害が単体テストで発見されるべきレベルであるならば、他のテストが単体テストのレベルをクリアしているのかを再度確認する必要が出てきます。状況によっては、同様のことが起きない様に横展開のチェックをし、縦展開による分析で類似性障害の確認が必要になります。
次に「障害理由」について説明します。「障害理由」は、「仕様漏れ」、「設計ミス」、「プログラミングミス」、「テスト不足」、「データ量不足」などです。例えば、システム統合テストで、「データ量不足」の障害理由が発見されたら、データ移行がビジネスデータのパターンを網羅できていなかった可能性があります。この様なこともダッシュボードで判断できる様にすると良いでしょう。
「障害分類」については、三つの分類で管理します。「標準機能障害」、「拡張機能障害」、「オペレーションミス（障害ではない」があります。SaaSタイプのERPは、FTS （標準機能活用）アプローチを取っているので、面白い事象となります。オンプレミスのERPプロジェクトであれば、拡張機能開発の障害分類が、標準機能障害よりも圧倒的に多いでしょう。しかし、FTSアプローチの場合、それが逆転して、標準機能障害が多くなるのです。これは、標準機能の品質が悪いというのではなく、拡張機能開発が圧倒的に少ないので、その結果として、標準機能障害の比率が高くなるのです。ゆえに、プロジェクト全体における障害対応時間は10%を超えることはないでしょう。ちなみに、この様に作業時間を計測することで、プロジェクト状況がわかるのはもちろんのこと、プロジェクトの工数見積にも絶大な効果を発揮します。
まとめますと、個々のタスクの状況を適切に分類してダッシュボードで可視化することで、プロジェクト状況を把握でき、問題への対応と今後発生するリスクを特定できる様になります。そして、それらに気付くためには、プロジェクトで発生するタスクごとの作業時間を取り、その統計データを分析して、誰もが統計に基づいてプロジェクトの良し悪しを定量的に判別できる様にする必要があるのです。
