![見出し画像](https://assets.st-note.com/production/uploads/images/113671157/rectangle_large_type_2_906d227a14962415cbb0df3ca91c2eea.jpeg?width=1200)
実践でたどり着いた「本質」という言葉の意味(2/2)
【ポイント】
表面的なヒアリングや議論では「本質」を見極めることはできない。
「本質」に行きつきたければ全体像の議論(概念化)から入るべき。目の前のものに目を奪われていたのでは本質は遠ざかるばかり。
本質にメスを入れなければ、どんな改善策も上滑りしてしまう。
前回に引き続き、今回も本質について考えましょう。ずいぶん前のことになりますが、こんなことがありました。
あるお客様は、プロジェクトのコスト超過や納期遅延に苦しんでいました。私は改善チームのメンバーと共に原因究明にあたることになりました。
私たちはまずプロジェクトの関係者にヒアリングを実施しました。ヒアリングを進めると、原因はすぐに見つかりました。情報の伝達に問題があったのです。
改善チームは即座に情報伝達ルールの作成に取り掛かりました。しかし、私はそれだけでは問題は解決できないのではないかと懸念していました。
「情報伝達の問題を引き起こした根本原因を究明しないと、ルールを作成したところで定着しないのではないか」
そう考えたのです。
私たちの目的は、プロジェクトのコスト超過や納期遅延を無くすことでした。そのために必要なのは、この問題の「根本原因=本質」をつきとめ、それを解決することでした。ヒアリングの結果に、私は、本質にたどり着いたという実感を持てずにいたのです。
改善チームにそのことを伝えると、彼らも薄々は気付いていたのでしょう、すぐに共感してくれました。
私たちはブレーストーミングでプロジェクトの特徴を列挙し、そこから問題の根本原因を探ることにしました。情報伝達に問題があることはすでに分かっていたので、検討の範囲は絞り込まれました。
改善チームのメンバーたちは、プロジェクトの特徴を以下のように列挙しました。
[ プロジェクトの特徴 ]
お客様の要求に沿った個別開発である。
プロジェクトの規模が大きい。
メンバーの大半は機能開発部門からの兼務者である(プロジェクト軸とライン部門軸のマトリックス型組織となっている)。
これらの特徴を頭において、私たちは、改めて関係者にヒアリングを行いました。そして、以下の実態に着目しました。
たいていの作業には期限があったが、期限を守る責任は、機能開発部門から駆り出されたメンバーたちの個人任せとなっていた。
機能部門をまたいで必要なインプット情報が約束した期日までに引き渡されないことは日常化していた。
機能開発部門を代表してプロジェクトに参加していたメンバーたちは期限順守の強迫観念に駆られ、予定していた着手日が迫ると、入手遅れのインプット情報を関係者に聴きまわっていた。ところが、こうして先出しされた情報の多くは生煮えの状態だった。
生煮え情報が後に変更されることはよくあるが、情報を先出しした側には、先出しした情報を自分がケアしないといけない、つまり、自ら相手に働きかけて情報を訂正しなければならないという意識はなかった。そのため、間違った情報がそこかしこに存在し、悪さをしていた。
結論は出ました。
問題の本質は「マトリックス型のプロジェクト運営」にあったのです。
マトリックス型により引き起こされるメンバー間のコミュニケーションの壁が情報伝達の問題を生んでいたのです。情報伝達の壁はメンバー間に齟齬を生み、これが手戻りを多発させ、結果的にコスト超過や納期遅延へとつながっていたのでした。
カタチだけの情報伝達のルールを作ったところで、そのルールをまわす人たちが変わらなければうまくはいきません。
彼らの縄張り意識や責任の果たし方、日常の人間関係やコミュニケーションはマトリックス型のプロジェクト運営と深く結びついており、そこにメスを入れない限り、根本的な解決には至らない、これが私たちの出した答えでした。
私たちは、堅苦しい情報伝達のルールではなく、プロジェクトの名の下にメンバーが一丸となれる体制の構築を目指すことにしました。この結果、メンバー間のコミュニケーションは日常会話やお互いを思いやる精神に支えられ、もともと存在していた情報伝達ルールの上でも十分に機能するようになりました。
これによって問題がすべて解決したわけではありませんでしたが、こうして生まれたプロジェクトの一体感は、これらの問題をカバーして余りあるものになりました。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
この記事が気に入ったらサポートをしてみませんか?