技術系バックグラウンドのマネジャーが失敗するひとつの事例
技術系バックグラウンドを持った人材が陥りやすい事例として、「技術にこだわり過ぎるとマネジメントは失敗する」というものがあります。ここでは、私が当事者として失敗した事例についてご紹介します。
三行まとめ
- 技術系バックグラウンドを持った人は良い技術を導入すれば組織は良くなると考えがち。
- 技術者は、ソフトウェアエンジニアリングの世界と同じ確実性を、マネジメントにも求める傾向がある。
- マネジメントは不確実を孕むものである。これを見逃すとマネジメントは失敗する。
背景
私が所属していた企業は従業員数万人規模の比較的大規模な会社で、非常にボトムアップ文化が強い会社でした。それぞれの部門にプロダクト開発のためのソフトウェアエンジニアが所属するような体制を取っており、横断的な取り組みはごく一部で行われていたという状況でした。
社内で複数の大型プロダクトが開発されていく中、プロダクトのライブラリ管理がバラバラに行われており、それはリスクを孕むようになってきました。
- セキュリティ：オープンソースの適切な利用がされているかが把握できない。脆弱性が発見された場合に横断的な検査ができない。
- 効率性：ライブラリ利用に関するベストプラクティスのノウハウが分散し、開発リソースを無駄に消費してしまう。
- コラボレーション：社内エンジニアが学習やコントリビュートのために他のプロジェクトのソースコードを見たり、参画することができず機会損失する。
これらの問題を解消するために「ライブラリ管理共通化プロジェクト」が立ち上がり、エンジニアバックグラウンドであるA氏にプロジェクトリーダーの白羽の矢があがりました。
そして半年経ち、プロジェクトは失敗しました。プロダクトのライブラリ管理はバラバラのまま、リスクは孕んだままです。何がいけなかったのでしょうか？
失敗に至る経緯
「ライブラリ管理共通化プロジェクト」の推進にあたり、A氏は「このプロジェクトを推進すれば、セキュリティの問題が解決し、効率も上がる。開発現場は喜ぶだろう。」と考えていました。ライブラリ管理をするためのSaaSプロダクトを選定し、スケジュールを引いて予算を確保したまでは良かったのですが、これらを導入するにあたって各部署からA氏にとって意外な言葉が飛び出しました。
「このプロジェクトを推進する意義は何か？このプロジェクトに合わせてライブラリ管理を変更すると、プロダクトの開発スケジュールにも影響する。現在もセキュリティ問題は適切に対応しているし、効率がどれだけ上がるかも分からないものに対応できない」
A氏は「全社的に必ず必要になるもので、良いプロダクトだからなんとか対応して欲しい」と各部署と調整しましたが、理解を示した部署はわずかであり、当初のスケジュールやゴールイメージを大幅に見直す必要に迫られ、最終的には「本プロジェクトは適切な効果を得られない」ということで中止となりました。
要因
ここでのA氏とは私のことです。
プロジェクトは失敗に終わった原因の一つは、技術系バックグラウンドを持っていた私は当時「採用する技術」よりも「技術を採用する組織づくり」のほうが重要であることを十分に理解していなかった、ということです。そのためこのプロジェクトに関わる組織のステークホルダーに対して十分な配慮や検討を行わず、結果として選定技術やスケジュールが組織に受け入れられませんでした。
これは「事前配慮すべきだった」ということではなく、これらプロジェクトに関わる全ての部署や人を一つの組織とみなし、それを運営するというイメージを持ってプロジェクト設計していないことが、最大の失敗要因だったと考えています。
総括
プロダクトの導入先（顧客と見立てていいと思います）はソフトウェアにおけるAPIではありません。決まったデータを流し込めば確実に処理して返してくれるわけではありません。技術者は、ソフトウェアエンジニアリングの世界と同じ確実性を、マネジメントにも求める傾向があります。マネジメントには不確実性があることを見逃してしまうとマネジメントにおいて失敗を続けることになり、成長はないものと思います。
