この記事はトレタ Advent Calendar 2017の25日目の記事です（2日遅れ…）。
これはなに？
トレタで約半年間 VP of Engineering という肩書（実質的な活動はそれより前からやってたので約1年くらい）で活動した結果、選択ミスだったかな？というのをまとめてみる試み。
前置き
トレタ入社以後、自分が今の役割である VP of Engineering をやるまでに以下のような役割、役職の変化があった。
- 2016年4月: サーバーサイドエンジニアとして入社
- 2016年7月: 他部署や他社からの技術に関する問い合わせ窓口担当、採用担当
- 2017年5月: エンジニアリングマネージャー
- 2017年7月: VP of Engineering
そして VP of Engineering という職位は 「人・組織のアウトプットを最大化する」 という役割を担うために作られたもので、そのときに役職名と Job Description をセットで提案したものだった。
VP of Engineering という職位が違う役割をもっている場合には当てはまらない。かもしれない。
アンチパターン 1: Playing VP of Engineering
ここで言う Playing は「業務として特定のプロダクトのコードを書く」の意。
人事を中心にみるといえど、VP of Engineering になる多くの人は現エンジニア、または過去にエンジニアだったという経験を持つはず。個人的にはそうでない人がエンジニアの上長として信頼を得るというのは、よほどの魅力があり、対話力があり、人望がある、いわゆる人間力の塊のような人ではないかと思う。それくらい、エンジニアとの上下関係における信頼構築の基礎となるのは技術理解だと思う。
そのひとが業務として特定のプロダクトに開発メンバーとして参加、コードを書き続けようとするとどうなるか？
答えは、簡単といえば簡単。どちらも中途半端になる。
プロダクトのコードを書くという点については、エンジニアの頭数に（うっかり）カウントしてしまうことでプロジェクトの進捗を滞らせる、という事態に陥る。
加えて本業であるべきはずのピープルマネジメントの部分については、プロダクト開発ほど明確・定量的なゴールが設計しづらいため結果として時間的優先度が下がってしまい、ケアがおろそかになることで問題発見がおくれたり、対応が後手になったりする。
さらに、この役職には部署長としての総務業務（勤怠管理や各種申請の承認）や採用関連の業務なんかも一緒にくっついてくるはずで、思っている以上に業務範囲が広い。ますますコード書いてる時間はない。
こういったことを繰り返せば、メンバーからの信頼はおろか、経営層からの信頼もなくなり、あげくプロジェクトの遅延、予算計画未達みたいな自体にまで発展しかねない。そうなると自身の精神的なダメージはもう取り返しの使いないところまで行くと思われる。
おそらくこれが最悪のパターンのはず。
VP of Engineering になったら業務としてコード書くのは（ひとまず）やめておこう。
アンチパターンを用いてもよい場合
基本的に期限のないものや、いつかやりたいリファクタリング、あったらいいよねというテスト、みたいなところのコーディングについては、ありかもしれない。
が、それも本番にデプロイして問題おきたり CI をとめたりする事態に陥ると即対応が必要なので、やはりできれば避けたい。
アンチパターン 2: Technical Management -> People Management
「テクニカルマネジメント」という用語が適切かどうか、というのはおいておく。役割としてはサービスや開発部に関する新規案件や、技術に関することでだれに聞いたらよいかわからない、そもそもその技術が何なのかよくわからない相談などの担当窓口、みたいな感じ。
この役割の人に寄せられる相談、業務とかは以下のようなものがある（あった）。
- 他部署から
- 連携して行う業務についてのメンバー、手法、進め方についての相談
- 顧客から
- セキュリティチェックシート記載依頼
- 利用規約、プライバシーポリシーに関しての技術的・データ的な観点の問い合わせ、確認、説明依頼
- 他社から
- セキュリティ監査
- サービス連携に向けての技術的なやりとり、打ち合わせ参加
- そのままプロジェクトとして取り組むことになればプロジェクトの立ち上げ
- 開発部として
- サービスの障害、セキュリティインシデントに関する取りまとめ
- 社内の一部署としての振る舞いや意志決定
- 業務委託契約に関する手続きや管理
そもそも上下関係がほぼない小さなフラットな開発組織から一人選抜してこういう業務に取り組むと、他部署との関係からその人がその部を代表する人のようにどうしてもなっていく。結果、最後にあげたような開発部としての対応や開発総務的な業務も結構くっついてくる（きた）。
こういう業務が中心となり社内に既成事実として確立、運用が回り始めたぞ、ってなってからピープルマネジメントにシフトするというのは、しっかり役割を分解・移譲しないと、単に業務が増えるだけになってしまい、パターン1と同じくとにかく業務範囲が拡大して時間に追われるということになる。その結果どうなるか？というのはパターン1と同じ、全部中途半端になってしまう。
可能であればこのパスは避けたほうが良い。
そもそも技術マネジメントとピープルマネジメント、求められるスキルは結構違うはず。マネジメントというところだけでひとくくりにせず、それぞれ別の人を当てれないか考えよう。
アンチパターンを用いてもよい場合
それでももしこのパスを通るなら、緩やかに移行せず、短めの期間（1ヶ月くらい？）でエイヤッと移行すべきである。既存の技術マネジメント業務に関しては、それぞれの担当をエンジニアに移行・移譲しその業務に関してはサポートに周る。そして VPoE はさっさとピープルマネジメントに集中すべきである。
まとめ
まだありそうだが、長くなったのこのあたりでひとまず。
基本的に 「兼務はダメ、絶対」 ということである。マネジメント業はとにかく範囲が曖昧で広くなりがちなので、時間的なバッファはかなり持っておかないと対応しきれない。そして、人・組織のマネジメントについては失敗の影響はとかく大きいし、失敗・成功という結果が見えづらい、見えるのにもエンジニアリングと違って時間がかかる。
ただ、成功すると持続性が高く、1つの成功からの相乗効果みたいなものも結構あると思う。
それが感じれたときの喜びは大きいし、一人のエンジニアとしての技術・行動で解決できる範囲を遥かに超えたものとなるので、人・組織をマネジメントするというのもまた面白いキャリアパスかも知れない。
VP of Engineering という役割、まぁ結構しんどいのだけど、万人がなれるポジションではなく、全く違う視点から物事を見る・捉えるということができるようになるので、機会が訪れたら一度チャレンジしてみると良いと思う。