戦略階層にエンジニアの役職と読むべき本を当てはめてみる

前回の記事の続きです。 katsuki.hatenablog.com

上記事の内容を一言で表すとエンジニアの成長戦略として自分の階層を把握した上で学習内容を選択することが大事 というものです。

当記事では、戦略階層ごとにエンジニアの職位をプロットし、各階層で具体的に求められる責任範囲と、学習すべき書籍について整理してみました。

戦略の階層	役職	責任範囲	書籍
世界観	創業者	ビジョン, ミッション, コアバリューの策定 どのような会社にしたいか どのような世界をつくりたいか	ザ・ビジョン 進むべき道は見えているか
政策	取締役	会社全体の舵取り、方向性、カルチャーづくり 長期戦略、市場の策定	ビジョナリー・カンパニー ― 時代を超える生存の原則 その他経営戦略の本etc
大戦略	CTO, VPoE, プロダクトマネージャー	サービス全体の技術基盤, アーキテクチャー選定 エンジニア組織構築, 採用、カルチャーづくり 長期的なプロダクトロードマップ	マイクロサービスアーキテクチャ エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION) 組織パターン (Object Oriented SELECTION) なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践 Inspired: 顧客の心を捉える製品の創り方 プロダクトマネジャーの教科書 伽藍とバザール ハッカーと画家 コンピュータ時代の創造者たち
軍事戦略	開発部長, 事業部長	部署の舵取り、リソース管理、部門予算管理 複数のプロジェクトの統括 エンジニアの職場環境づくり	ピープルウエア 第3版 その他事業戦略、予算管理の本
作戦	マネージャー, テックリード, アーキテクト	4〜8人位の中規模プロジェクトのPL 設計に責任を持つ チームの生産性 プロジェクト横断のアーキテクチャ選定 DevOps スクラムマスター, プロダクトオーナー 人材評価	新1分間マネジャー――部下を成長させる３つの秘訣 ヤフーの1on1―――部下を成長させるコミュニケーションの技法 エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド Team Geek ―Googleのギークたちはいかにしてチームを作るのか The DevOps ハンドブック 理論・原則・実践のすべて エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
戦術	チームリーダー, シニアエンジニア	2〜3人の小規模プロジェクトのPL 機能設計に責任を持つ ソースコードレビュー 新人教育	あなたのチームは、機能してますか？ チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ 増補改訂版Java言語で学ぶデザインパターン入門 Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
技術	エンジニア	自分の書いたソースコードに責任を持つ	リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 新装版 達人プログラマー 職人から名匠への道 スーパーエンジニアへの道―技術リーダーシップの人間学

便宜上階層に当てはめる形で役職を入れてみましたが、ここまで細かく階層化されている組織は大企業くらいだと思います。スタートアップのエンジニア組織であれば、CTO, テックリード, エンジニアの3〜4階層くらいが一般的ではないでしょうか。

戦略階層の上位は3W下位は1H

会社経営における各階層における責任範囲を整理するなかで、下位がHow（どうやるか？）なのに対して上位はより抽象度の高いWhy, Where, Whatの問いに相当することに気づきました。

• 世界観はWhy（なぜやるのか？）
  • 創業者の想い、目的。このレベルになると突き詰めると個人の価値観に突き当たる。
• 政策はWhere（どこへいくのか？）
  • 世界観を実現するためにどの市場にいくか、会社の文化をどうするか。
• 大戦略はWhat（何をやるのか？）
  • 事業として何をするのか
• 軍事戦略以下はHow（どうやるのか？）

エンジニアのキャリアパスとしての最上位

エンジニアのキャリアパスとしての最上位は政策レベルの取締役CTOになります。このレベルになると経営者として会社全体の方向性に影響をおよぼす意思決定が求められます。

その下の大戦略レベルは、会社のエンジニア組織全体に影響をおよぼす役割となります。職位的にVPoEはCTOの配下ではないかという意見もあると思いますが、役割が異なるだけであり実質的な責任範囲の抽象度的には同一階層であると考えます。

最後に

整理しといてなんですが、自分が階層の少ないスタートアップにいるせいかこんなに階層化するのは動きづらくてやりにくそうだと思いました。

とはいえ、自分の役割として何を求められているのか、何を学ぶべきかを把握するのに階層に当てはめてみるのはおすすめなので、みなさんもぜひやってみてください。