プロジェクト成功に必要な気持ちの割合
背景
年末だしということで同業他社で働く友人と忘年会をしていて「オンプレITインフラ構築プロジェクトの成功と失敗」という話になった。
これまで多くのプロジェクトを経験してきたけど、初期の体制構築に問題があったとか、顧客の中でゴール設定があいまいだったとか色々な理由でプロジェクトが失敗に終わったりする。
プロジェクトを失敗しないための社内ガイドラインに従って、事前レビューとか中間レビューとかも実施しているのに、こういう外的要因によって失敗するのはなぜ？みたいな話。
上記についてコメダで会話した内容を書き留めておきたいと思った。
前提
ITインフラプロジェクトが失敗する要因として、ITの複雑化も大いにあるけど、今回は比較的シンプルな案件においても失敗するケースを考えてみる。
失敗しないためには仕組みに追加で「気持ち」が必要
オンプレのITインフラ構築はゴールが明確になっていて、かつ物理的な手配を伴うのでアプリケーション開発に比較して難易度が低い。
そのため、習慣的に実施する「失敗しない仕組み」に習って業務を遂行することで結果的に失敗しない実績が積み重なり、それがエンジニアの実感となっている。
難しいは上記の範囲を超えて、「失敗しない仕組み」ではカバーすることができない一定難易度の案件。
一定難易度の案件を失敗しないためには、事前レビューや中間レビュー等の「失敗しない仕組み」に追加して「成功させる気持ち」が必要。
気持ちが入っていると防げること
「気持ちが大事だ」みたいな精神論っぽいことを言っていても伝わらないと思うので実例を。
プロジェクトを進めていくと、当初想定しなかった事象が発生してプロマネや担当者は対処を迫られる。
その時、判断１に示したようなダメな所を明確に伝えやすい事象はエンドユーザーの理解も得やすく対処は簡単。ここは「失敗しない仕組み」によって守られる部分。
続いて判断２。ここは判断１のようにすぐに失敗する所が関係者全員に見えておらず、エンドユーザーに理解してもらうのも苦労する所。ここで気持ちが入っていないと「おれはちゃんと説明したし、エンドユーザー/PJ責任者が対処しないと判断するなら俺は決定に従うまでだ」となり、結果失敗する。
この判断２で成功に進む道を突き進むことができるかが、気持ちが入っているか否かにかかっていて、結果として成功するか否かに繋がっている。
判断３はいい事例が思いつかないので後で。
結論
当初は設計書通りに基盤を作るとかテストを不具合ゼロで終わるとか、納品日までに納品して検収されるとかが自分の中でゴールや成功としていた事が、エンジニア自身が成長し、もう少し広い視野で成功と失敗を判断しはじめた時。
その成功を掴み取るためには、一歩踏み出すための気持ちが必要。
余談：ITインフラが及ぼす影響範囲の変化
ITと名前はついているけど「インフラ」であるので、人の気持ちによって品質が左右されては困るという前提がある。担当した職員のやる気が無かったので高速道路崩れましたじゃ困るよね。
その考え方は正しくて、見た感じ動いているだけではなく、構築手順や正常異常を含めたテスト、第三者レビューによって品質を担保するのは良いと思う。
だけど、これまで利用範囲やビジネスに及ぼす影響が限定的であったITインフラが、上記図の通り最終的にはビジネスのコアにまで到達するようになった昨今。
これまで通りの品質を第一とした考え方にプラスして各担当者がゴールや成功を意識した思考や行動が必要とされている。
これはエンドユーザー側も同じくで、これまで上司や利用部署からあがってきた要望をSIerに流してただけの情シス担当はSIerから明確なゴールや価値を問われるので、それに答えられるようにしておかないといけない。
参考資料
Discussion