「本質」とは何か、簡単そうで超難題なこの質問に答える2
前回に引き続き、今回も本質について考えましょう。ずいぶん前のことになりますが、こんなことがありました。
あるお客様が、プロジェクトのコスト超過や納期遅れに悩んでいました。私は改善チームのメンバーと共に原因究明にあたることになったのです。
私たちはまずプロジェクトの関係者にヒアリングを実施しました。ヒアリングを進めると、原因はすぐに見つかりました。情報の伝達に問題があったのです。
改善チームは即座に情報伝達ルールの作成に取り掛かりました。しかし、私はそれだけで問題が解決するか自信が持てませんでした。
「情報伝達に問題を引き起こした原因を究明しないと、ルールを作成したところで定着しないのではないか」と考えたのです。
私たちの目的は、プロジェクトのコスト超過や納期遅れを無くすことでした。そのために必要なのは、この問題の「根本的な原因＝本質」をつきとめ、それを解決することでした。私は、ヒアリングの結果、本質にたどり着いたという実感が持てていなかったのです。
改善チームにそのことを伝えると、すぐに共感してくれました。
私たちは、プロジェクトの特徴を列挙し、そこから問題の根本原因を探ることにしました。情報伝達に問題があることはすでに分かっていたので、検討の範囲は絞り込まれていました。
改善チームのメンバーたちは、プロジェクトの特徴を以下のように列挙しました。
［ プロジェクトの特徴 ］
お客様の要求に沿った個別開発である
プロジェクトの規模が大きい
メンバーの大半は機能担当部門からの兼務者である（プロジェクト軸とライン部門軸のマトリックス型）
これらの特徴を頭において、私たちは、改めて関係者にヒアリングを行いました。そして、以下の実態に着目しました。
プロジェクトではメンバーに期日付きで仕事が渡され、メンバーは自分の責任でこの期日を守っていた。
メンバーが担当する仕事に着手するには他のメンバーからのインプット情報が必要であったが、それらの情報は約束した期日までに引き渡されないことがあった。
メンバーは「この日までに着手しないと期日に間に合わない」という強迫観念に駆られ、着手日が迫ると、作業に必要なインプット情報を関係者に聴きまわっていた。ところがそれらの多くは生煮えの情報だった。
このような生煮え情報は後に変更されることがあるが、情報を渡した側には「渡した」という意識が希薄だった。そのため、変更されたとしても、そのことは聴き回ったメンバーには伝えられていなかった。
結論は出ました。問題の本質は「マトリックス型のプロジェクト運営」にあったのです。
マトリックス型により引き起こされるプロジェクトメンバー間のコミュニケーションの壁が、情報伝達の問題を生んでいたのです。
私たちは情報伝達のプロセス設計に加え、メンバー間のコミュニケーションの在り方を改善しました。
★★★ 概念化.com を立ち上げました ★★★
https://www.gainenka.com/
★★★ ぜひ、お立ち寄りください ★★★