包括的なエンジニアリング戦略を持たない組織で働き続けていた感想
この記事は、『エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ』の第3章「エンジニア戦略を立てる」を読んだ感想です。
書籍で紹介されていた「包括的なエンジニアリング戦略」とは何か。詳しくは書籍を参照いただきたいが、まず「エンジニア戦略」ではなく「エンジニアリング戦略」です。つまり、対象はエンジニア個人やエンジニア組織に限らず、より広く開発活動全体をカバーする戦略です。
「包括的な」という言葉について、書籍では「エンジニアリング組織を運営するための憲法のようなもの」と表現されています。これは、人材ポリシーや採用戦略、コーディング規約、開発ルールといった個別の施策やルールではないということです。全社戦略から落とし込まれるかたちで、事業戦略・プロダクト戦略と並列の位置づけで語られるべきものです。
また、単にメンバーの頭の中にある考えではなく、明文化されていることが重要であり、それこそが「憲法」としての意味を持つのだと理解しました。
僕自身の経験としては、現職で8年、前職で3年弱を過ごしてきましたが、「包括的なエンジニアリング戦略」というものに出会ったことはありませんでした。現職では0→1のフェーズにあるチームに関わることが多く、部署を横断するような戦略の必要性を感じにくかったという事情もあります。
また、VPoEとしてエンジニア組織全体を統括するようになってからも、「エンジニア組織の課題を明らかにし、それを解決するための戦術を立てる」ことはあっても、「エンジニアリング」というスコープで俯瞰的に戦略を描くという視点は持てていませんでした。
さて、このエンジニアリング戦略を持たずに働き続けてきた中で、振り返ると以下のようなことが少なからず起こりやすかったと感じています。
- 事業戦略やプロダクト戦略との整合性が取りづらくなる
- 全社的なエンジニアリング組織としての意思決定が希薄になり、部署ごとの個別最適で動いてしまう
- 結果として、採用・評価・育成の方針が不明確になり、一貫性が失われる
- 経営層やエンジニアリング統括層と、現場との間に溝が生まれやすくなる
一見、戦略がなくても組織は“回っている”ように見えるかもしれません。しかし、組織規模の拡大や、事業環境の変化、キーパーソンの離脱といったタイミングで、こうした問題が表面化する場面をこれまでにも多く見てきました。
次に、「では、どうやって戦略を作るのか？」という点についてですが、まずは全社戦略や各事業のロードマップ、競合動向、KBF/KSFや何で競争優位を保とうとしているか、といった点を踏まえ、P/Lの理解から始める必要があると感じています（このあたりは書籍でも類似の記述がありました）。
また、自分の課題として、エンジニアやQA以外のエンジニアリング関連職種への理解がまだ浅いため、まずはこの解像度を上げるところから始め、戦略の叩き台を作る必要があります。
戦略を作成し、それをさまざまな関係者とレビューしながら磨き上げていくには、一定の時間がかかると思います。それでも、「やらない理由」はなく、むしろ今こそ取り組むべきだと考えています。まずは手を動かし始め、完成した暁には、会社のブログなどで公開できればと思っています。
最後に、『エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ』、かなりいい本だと感じています。ただ、まだ3章までしか読めてないですが、エンジニアリング統括責任者を目指す・そのポジションが見える方くらいでないと、読んでも解像度が低いかもしれません。あくまで個人の感想です。興味が湧いたら買ってみるといいと思います。
Discussion