WHIの7つの「Value」に沿ったエピソードを語ってください！ by Works Human Intelligenceカレンダー、6日目の記事になります。
Valueのひとつに挙げられている 「Solve：本質を追求し問題を解決する」 について、個人的に思い出す経験があったので振り返ってみる、自分語りの記事になります。
ある炎上プロジェクトの話
比較的大規模なシステム刷新を複数ベンダーで受注しているプロジェクトがあり、そのうちの1社のベンダーから、燃えに燃えたプロジェクトの後半になって私にヘルプとしてお声がかかりました。
機能開発は遅れに遅れ、いざ他部門と結合してみたらまるで動かず、他社のテストを待たせてしまう、といった状況で、とにかくプロジェクトの軌道を修正することが私の役目でした。
そのベンダーのプロパー社員であり、同じくプロジェクトの途中からてこ入れ要員として加わったAさんは、パワフルでありながら客観的な視点をもっており、プロジェクトの無駄や機能していないフィードバックループをバッサバッサと切り崩していきました。
そのAさんが度々口にしていたのが「本質」という言葉だったのを思い出します。
それって本質じゃなくない？（問題の本質）
プロジェクトの体制はウォーターフォールに近く、要件定義～外部設計を担当する上流チームとコーディングのチームが分かれていました。
あるとき、上流チームから渡された外部設計に従ってコーディングを進めていた途中で、コーディングチームが仕様の矛盾に気づき、仕様修正となって実装作業に大きく手戻りが生じました。
上流チームの担当者は平謝りで、「今後は気をつけます」「チーム内での二重チェックを徹底します」という趣旨の謝罪をしていましたが、それに対してAさんが指摘したのが、それは問題の本質じゃないでしょ？ということでした。
「気をつける」というのは対策としては何もしないというのと同義であること、上流チーム内でのチェックを徹底したところで、仕様作成時点では気がつけない問題はあるだろうということを指摘し、それよりは、 仕様作成の段階からコーディングするメンバーを交えて意思決定するように変えたほうが問題の解決になるんじゃないの？ という提案に繋げていました。
個人でもチームでも、申し訳ないという気持ちが先行する場合、それを他人のせいにしたくないばかりに、自分たちの中だけで解決策を見つけようとしがちですが、全員ゴールは同じなのだから、他のチームも巻き込んで一番いい方法を見つければいいのだということに気づかされました。
○○さんは手一杯で他の作業には回せない？（役割の本質）
炎上しているプロジェクトでは、「とにかく終始何かに追われていて手一杯な人」というのが何人も現われがちです。
炎上がひどくなるほど、経営会議や全体会議で状況報告と立て直しプランを説明するという嫌な手間が大きくなりますし、間に合わせで作業要員を増やせば、その指示・管理にも追われることになります。
コーディングチームでリードとなるような人は、ある程度オールマイティな役割をこなせることも多く、コーディングチーム代表として種々の打ち合わせに参加するうち、いつしか上流の役割を巻き取って、顧客への説明に駆り出されたり、テスト計画と設計、進捗管理まで担当したりと、コーディングから離れた作業に終始することになってしまう、というのもあるあるだと思います。
他社との外部結合テスト中にある機能の実装を大きく見直す必要に迫られた際、そういったとあるリードエンジニアに頼むのが最速であるという判断となったときに、「リードエンジニアの○○さんは今手一杯で、とてもそんな作業をする余裕がありません！」と現場から反発がありました。
そこで、そのリードエンジニアが何に時間を取られているのかヒアリングしたところ、結合テストの現場にいると他社の人からインターフェースについての質問があったり、顧客から直接技術的な説明を求められたり、テスターからの質問を受けたりしていて自分の作業時間がまるで確保できない状況だということがわかりました。
そこでAさんが言ったのが 「それは○○さんの役割の本質じゃないでしょ」 ということで、とにかくそのリードエンジニアを現場から引きはがし、同じチームの人間しかいない環境で実装に専念される判断をしました。
その結果、現場は回らなくなったかというと、別にそんなことはなく、その人がいなければ別の人に質問するか、あるいは居ないならいいやということで単に質問がなくなっただけでした。
他社との権限共有は本当にできないか（目的の本質）
複数のベンダーが絡むようなプロジェクトでは特に、会社間での情報共有が作業上のネックになることがあります。
たとえば社内は社内で問題管理表やチケットトラッカーを管理していて、それとは別にプロジェクト全体での問題管理表などがある場合、チケットを転記して二重管理にするような不要な手間が生じることもあると思います。
このプロジェクトにおいても、ある部分の機能について、他ベンダーと共同作業でテストを実施することになりましたが、その際に私の所属ベンダーは自社内のツールでテスト項目を管理していたため、他ベンダーとリアルタイムでテスト結果とその修正の進捗を共有するためには、都度手作業で転帰する必要がありそうでした。
どうしましょうかとAさんに相談したところ、「他ベンダーの人も一時的に自社ツールのアカウント作れないか上に聞いてみましょうか」と言って（前例はなかったようですが）すぐに上を説得し、他ベンダー用のアカウントを作成してくれました。
もちろんセキュリティ上の制約などで必ずしも同じ解決策がとれるとは限りませんが、 本来の目的（プロダクトを完成させること）と関係のない障害は、本当に取り払えないのかを一度疑ってみる ものだという気づきになりました。
前提を一度取り払って考えること
以上、問題の本質・役割の本質・目的の本質という3つの観点で、「本質」について考えることとなったエピソードを紹介しました。
いずれについても共通していえるのは、 一度「○○だからできない」と思い込んでいる前提を取り払って考えてみる ことなのかなと思います。
実は過去の慣習がなんとなくルールになっているだけで、それを制約と思い込んでいるケースが少なくないのかもしれません。