, ,

プロジェクト立て直しシリーズ　-ドラムバッファロープ-

開発品質が一向に改善されないプロジェクトがありました。必要な人数は揃っています。スケジュール上も作業工数と人員の割り当てには無理がないように見えます。それにもかかわらず、なぜ開発品質が改善しないのでしょうか。

私がこのプロジェクトの立て直しに招かれた時、お客様との関係は破綻寸前でした。納品した開発物が、お客様の検証で次々にエラーを起こしていたからです。お客様は落胆を隠せず、ベンダー側のメンバーは皆自信を失っていました。

先ず、開発現場であるプロジェクトルームでメンバーの仕事の進め方を観察しました。すると、一人のメンバーが他の全員から質問を受けていることに気づきました。しかも、メンバーの全員がその一人に集中して質問をしているのです。その結果、そのメンバー自身のタスクはほとんど進まず、他のメンバーは回答待ちの時間が多く、手待ちの状態が頻発していました。

そこで、プロジェクトオーナーも交え、お客様に立て直し計画を提案しました。要点は非常にシンプルで、「設計書を全て見直す」というものでした。お客様からは「そんな当たり前のことで、この状況が改善されるのか？」と言う疑問の声が上がりましたが、プロジェクトオーナーが「それで立て直しにコミットできるのか？」との問いがあり、そのコミットを持って立て直し計画が承認されました。ちなみに、お客様にこの提案をしたのは、スケジュールを見直ししたかったことと、設計書の重要性を再認識していただきたかったからです。

人員はそのまま、誰も入れ替えませんでした。よく、プロジェクトの立て直しに有識者を追加したり、海外リソースを投入するなど、スキルと人数で立て直しを図るケースを目にします。しかし、私はこの方法を取りません。問題の本質を見極めずに人に手をつけると、コミュニケーションロスなどの副次的な問題が生じ、さらなる混迷を招くことを知っているからです。

最初に、プロジェクトルームの座席配置を変更しました。要件を最も理解しているメンバーをプロジェクトルームの中央に配置し、他のメンバーには、その周りをコの字を描くように座らせました。これにより、全員が座ったまま質問できるようにしたのです。また、他のメンバーは質疑応答を聞けるので同じ質問の繰り返しを防いだり、自身のタスクのヒントになる効果があります。併せて、中央に配置したメンバーのタスクは全てゼロにしました。そのメンバーは生産性が高いので、これまでは多くの設計書や開発を担当していましたが、このメンバーがボトルネックになって、他のメンバーのタスクが停滞していたため、その役割から解放したのです。

プロジェクトルームの壁一面に模造紙を張り、横軸に期日を表す日程、縦軸に「To-Do」、「WIP（作業中）」、「完成」といったステータスを書き、開発要件と担当者の名前を書いたポストイットを貼りました。これにより、遅延が予想されるタスクが一目でわかります。アナログな管理手法ですが、全員が同じ場所に集まるプロジェクトではこの方法が効果的で、納期意識の向上にも役立ちます。また、ベンダー側のプロジェクト責任者がプロジェクトルームに様子を見にくれば、即座に状況を把握できるでしょう。

この対策を始めて3ヶ月ほどで、プロジェクトは計画通り立て直りました。多くの方がお気づきになったと思いますが、この解決策は小説「ザ・ゴール」で紹介されたDBR（ドラムバッファーロープ）の手法を活用したものです。以前の記事「ERPの習熟度管理「ILUO」」でも触れましたが、製造現場の改善手法は、システム導入プロジェクトにも非常に有効です。

今回の根本原因の構図（RCA：Root Cause Analysis）は、設計書の不備が品質問題を引き起こし、その影響が不安定なスケジュールやお客様の信用失墜につながりました。この設計書の不備は、プロジェクト全体を踏まえて開発要件を理解している人物が一人しかいなかったために起きていました。もし、有識者を追加でアサインすると、その有識者に説明するのは、結局プロジェクト全体を理解して開発要件を整理できるそのメンバーです。これでは、ボトルネックの負担が増すばかりです。従って、今回のケースでは追加リソースを投入するのは得策ではありませんでした。そもそも、一人に依存しない役割分担が必要であったのですが、立て直しに至っては取り組みべきはDBRだったのです。

事実確認のためメンバー全員にアンケートを取ったり、ヒアリングを行うこともありますが、これは時間がかかる上に誤った方向に進む恐れがあるため、私はあまり推奨しません。メンバーにはそれぞれの立場や意見がありますから、「このプロジェクトは管理ができていない。だからこういうことになったのです。」と言う人もいれば、プロジェクト管理者の中には「メンバーのスキル不足が問題だ」と指摘する人もいるでしょう。お客様は「ベンダーのレベルが低い」と言うかもしれません。ヒアリングでは、”事実”だけを知れば良いのですが、意見を聞きすぎると、結果的に「体制の見直し」といった間違った方向に進むことが多いのです。

最近ではSaaSタイプのERP導入が主流となり、今回のように多くの開発要件が発生することはほとんどなくなりました。しかし、似たような問題は、ERPの実機検証やデータ移行でも発生します。ですから、DBRによる対策は今後も有効なスキルだと考えています。