組織を見るエンジニアのための『四象限』
みなさんこんにちは。
チャットボット開発のスタートアップでエンジニアをやっている福本です。
3月から晴れてVPoE(エンジニア組織マネジメント責任者)になりました。
毎月のように役割が変わっていますが、スタートアップとはこんなものなので気にしないでください。
今回も例によって、VPoEになるにあたり考えたことをアウトプットできればと思います。最後までお付き合い頂けますと幸いです。
前提 ~VPoEとは？~
話を進める前に、VPoEという職種について軽く認識を合わせておきましょう。
僕の考えとしては、「四大リソースの中で”ヒト”に全振りするエンジニア」というのがVPoEに関する見解です。
エンジニアリング組織におけるマネジメントおよび経営層の役割を、リソースによって分けるとすると以下のようなイメージで考えています。
・情報(技術)：CTO
・ヒト：VPoE(EM)
・モノ(プロダクト)/カネ：VPoP（PM, PO）
現実にはここまでキレイに分かれることはあまりなく、カニバリが起きる部分を適切に権限委譲あるいは相互に持ち合うことで、組織の運営が行われるものと思います。
例：スクラムチームの構成
・VPoP：リソースの算出、エンジニアのアサイン、ベロシティ向上etc…
・VPoE：モチベーションの向上、メンバーの成長計画とのマージetc…
エンジニアリングに関することには常にヒトが関わるため、VPoEが携わる領域は極めて広いです。
さらに、プログラムやコードよりも人間の方がはるかに複雑で扱いづらいため、既存のエンジニアリングの手法を用いた改善がソリューションに当てはまらないケースが多くなります。
ここまでをまとめると、VPoEは「曖昧で不可分な領域が多い」＆「複雑な”ヒト”を扱う」という２つの要素があり、それゆえに役割を遂行することが非常に難しい職種であると言えます。
「四象限」で分けて考える”ヒト”
さて、独特な難しさのあるVPoEですが、まだ経験が浅く社内にロールモデルも存在しないエンジニアにとって役割の遂行は（少なくとも僕にとって）至難の業です。
そこで、少し整理をして状況をシンプルに考えてみました。
以下の図は、エンジニアリングにおける”ヒト”を分類したマトリクスです。
「どこの部分の”ヒト”にアプローチするのか」によって、必要となる業務が変わっていくイメージです。
”ヒトに関わる業務や領域”について、それなりにMECEに分類できているのではないでしょうか。
シンプルにこの4つの領域を見て、現状のエンジニアリング組織に最も足りておらず、重要（or緊急）である部分に力を入れることで、ある程度良い結果が出るのではないかと考えています。
さらに…”時間”の軸
先ほど説明した四象限ですが、少し説明できていない部分があります。
それは「時間」という軸です。
これら４つの領域は、お互いに影響し合っています。
詳しく説明するために、影響の大きさや流れを図に追加しました。
詳しくは以下のように考えています。
（影響度合いは肌感）
まずは影響の大きい部分から。
こちらは理解しやすい部分が多いかと思います。
<影響（大）>
・広報→採用：広報活動がうまくいけば認知が拡大し採用がうまくいく
・組織設計→ピープル：役割が明確になり、制度が整い働きやすくなる
・ピープル→採用：人材流出リスク低下、リファラル採用の活発化
続いては影響の小さい（起きにくい）部分です。
この辺りは、結果の大きさによって当てはまらないケースもあります。
<影響（小）>
・採用→広報：採用戦略の共有、採用したハイクラス人材のアピール
・採用→ピープル：採用したハイクラス人材との協働や受ける影響
・ピープル→組織設計：個人の希望やモチベーションによる配置転換
・組織設計→広報：組織戦略やユニークな制度の社外共有
チームの現状を踏まえた上で、各領域の相互の影響度やその順序を考慮すれば、戦略の優先度を決めやすくなるかと思います。
さいごに
最後までお付き合い頂きありがとうございました。
これは以前から何度か書いていることなのですが、マネジメントやディレクションは頼むからやりたくない、というエンジニアの方が多いと感じています。
確かにコードを書くのはとても楽しいです。自分がどんどんコードを書けるようになっていく感覚や、プロダクトがみるみる改善されることは本当に面白いことです。
しかし、それだけが会社やプロダクト、チームのスピードを上げる手段ではありません。
結局プロダクトを作るのも技術を扱うのも、そしてプロダクトを使うのもそれを喜ぶのもヒトなので、もう少しそこに向き合うエンジニアが増えても良いんじゃないかなと考えています。
良く考えて頂きたいのだが、ソフトウェアは結局人の手によって生み出されるものであり、その開発者の仕事に対する満足度は非常に重要なメトリクスの１つと言うことができるはずである。-Larry Maccherone『the impact of Agile』
