非エンジニアが開発チームをマネジメントする際に大切にしたいこと
武末（@takesue1011）です。
PLG（Product-Led Growth）の盛り上がりもあり、開発チームの重要性が増すばかりですが、一方で、開発チームをマネジメントすることやテックメンバーたちと働くことのお作法については、あまりアップデートがされていないように感じます。
そこで今回は、非エンジニアである自分自身が開発チームを率いる上で大切にしていることをまとめたいと思います。
※ 私自身「非エンジニア」という言葉はあまり好きじゃないのですが、一方でこの言葉が伝わりやすいのも事実なので、本稿ではこの言葉を使用したいと思います。
きっかけ
私が開発チームを率いるようになったきっかけは、戦略コンサルであるアーサー・D・リトルからリブセンスに転職した2013年までさかのぼります。
当時のリブセンスは事業部制で、各事業部にテックメンバーが所属する体制をとっており、私も転職事業領域の事業責任者として、開発チームを率いることになりました。当初は戸惑いもありましたが、テックメンバーと協働し深く議論する中で、その楽しさにのめり込んでいったのを鮮明に覚えています。そこから10年近くが経ちますが、これまでに私が学んできたことや大切にしてきたことをまとめたいと思います。
理解すべきこと
1. コードを書くことは大切だが、商用コードは別物
私もスクールや独学含め、プログラミングに触れていますが、勘違いをしてはいけないことは、趣味でコードを書いてみるということと商用コード（=プロダクションコード）を書くということは全くの別物だということです。
商用コードでなければ、極端ではありますが、可読性も保守性もセキュリティも気にしなくて良い中で、商用コードを書くエンジニアは設計の段階から多くのことを考慮し業務にあたっています。そして、エンジニアに限らずデザイナーやPM、QAといったテックメンバーにも同様のことが言えます。
"Done is better than perfect" がとかく評価されやすいソフトウェアの世界で、人知れず未来やまさかの時のことを考慮し業務にあたっているのがテックメンバーなのです。
2. テックメンバー = 事業に興味がないというバイアス
テックメンバーはプロダクトや技術には興味があるけど、事業には興味がないとおっしゃる人を見かけます。もちろんそういった人もいると思いますし、決して職業人として間違っているわけではないと思いますが、だからといって「事業に興味がない」というバイアスでコミュニケーションをとるのは良くない影響を与えかねません。
事業の状況や何を目指しているのか、プロダクトで何を実現したいのかは、常にクリアな状況を作ることが必要だと思いますし、意図せずとも「どうせ興味ないよね」と相手を揶揄するようなコミュニケーションを取ること自体が、組織内でセクショナリズムの元になる危険性を重く受け止めるべきだと思います。
3. 技術的負債を解消したい理由
新機能開発 vs 技術的負債解消というのは、どの組織でも議論になると思います。技術的負債について知らない人は少なくなっているかと思いますが、なぜそれを解消したいのかを正しく理解することも大切です。
色々な観点がありますが、技術的負債を解消したい理由は、
・ボトルネックを早期に解消し、
・中長期的な開発スピードを上げる
・中長期的な開発困難性を緩和する
・採用など新規メンバーを受け入れやすくする
などといった側面があるかと思います。特に採用への影響は想像以上に大きいと考えるべきで、「3年前からくすぶっている炎上案件がある会社に積極的に入社したいと思う人は少ない」と言われれば納得しやすいと思いますが、類似した認識を持つべきかと思います。また、新機能開発と技術的負債解消を両立しながらできないのか？という疑問を持つ人も多いと思いますが、日常的なリファクタリングの範囲内でできればやってるんだよ！というテックメンバーも多く、見解へのリスペクトを持ちつつ状況を正確に理解することが重要だと思います。
4. テックメンバーの多種多様な悩み
「テックメンバーとどうやって話したら良いか分からない」という人がいますが、共通しているのが、彼らがどういったことに悩みがちなのかインプットしていないことが多いということです。
・現在取り組んでいるプロジェクトの技術基盤
・チームメンバーとの人間関係
・自身のキャリアの方向性等 等など
ビジネスサイド同様に、多種多様な悩みを持っていますが、CSのマネジャーをやるのであれば、CSのキャリアや悩みがちなポイントを理解していて当然だと思いますが、ことビジネスサイドとテックサイドの隔たりは大きく、ここを積極的に学び理解しようとする姿勢と知識が必要不可欠だと思います。
5. 自らのコミュニケーションを疑う
ここまで読んでみて、「よし、もっとテックメンバーと話してみよう！」と思った方は素晴らしいと思いますが、チャットで「1on1を入れていいですか？（1時間で）」とか言っちゃうと、ドン引きする人もたくさんいると思います笑。
コードベースでコミュニケーションすることが日常的なテックメンバーは、1時間も口頭であまり話したことがない方と話すのは、心理的安全性があまり担保されないと感じる人も少なくありません（もちろん人によるとは思いますが）
自身のコミュニケーションが当たり前という前提をなくして、「ちょっと10分くらいダベリません？」とか「（チャットで）時間あれば少し話しません？」といった『コミュニケーションの小口化』も意識しつつ、相手にとって負担のないコミュニケーションを理解したいところです。
大切にしたいこと
1. プロダクトビジョン/ロードマップの明確化
開発チームを率いる際に最も重要になるのが「プロダクトビジョン」と「プロダクトロードマップ」です。逆にこれらを示せない非エンジニアは、開発チームを率いることが難しいのではないかと個人的には思います。
プロダクトビジョンからプロダクトロードマップをブレイクダウンする際に意識したいのは、以下の3つのポイントを必ず論理的に繋げることです。
1. 新規/改善系イシューとその優先順位
2. 技術負債解消系イシューへの投資時間
3. DX（Developer Experience）向上系イシューへの投資時間
プロダクトビジョンやロードマップの考え方は、以下の小城さんのnoteが大変参考になるので、もしまだ読んだことのない方は参考にしてみてください。
2. 商用プロダクトを扱う醍醐味と葛藤に寄り添う
上記の通り、コードを書くことと商用コードを書くことは全く異なります。
商用プロダクトを扱うということは、「プロダクトで社会を変える」「事業だからこそ大規模でプロダクト展開できる」といった醍醐味がある一方で、技術的負債やセキュリティリスクへの対応等不可逆な意思決定の中で、日々葛藤しもがいているのも事実です。
開発チームと向き合う以上は、こうした醍醐味をチームとして共有しつつも、個人個人が感じている多種多様な葛藤に向き合うために、1on1等を活用しないといけません。コードレビュー等のコード上でのコミュニケーションをしない以上は、それ以外のあらゆるコミュニケーションにて、醍醐味と葛藤に寄り添う姿勢を大切にすることが必要だと思います。
少し前の本ですが、テックメンバーのキャリアについての理解を深めるための入り口としては以下の書籍が良いです。（あくまで入り口なので、テックメンバーとたくさん語らい合う中で、自身の考えを構築していけると良いかと思います）
3. ビジネスサイドの強みを徹底的に活かす
非エンジニアは「エンジニアでのキャリアがないこと」ばかりに着目しがちですが、「ビジネスサイドの強みをいかに活かせるか？」という視点が重要だと思います。例えば、開発チームへの一定の理解がある前提だと、以下のような部分はビジネスサイドの強みとなる部分だと思います。
1. 事業-プロダクト-組織の連関性を短期・中期・長期で徹底して高める
2. 属人性を排除し持続可能な仕組みを構築する
特に、事業とプロダクトを繋げる部分については、事業戦略の解像度をあげられるビジネスサイドの方が言語化しやすい部分もあり、短期だけでなく中長期的に開発チームのベクトルを合わせ、まさにPLGを主導することができると思います。
また、自らがエンジニアを兼務しているようなCTOやVPoEやテックリードと異なり、早期から属人性を排除した組織化や仕組み化を主導しやすいという部分も私の場合はあったように思います。
自らの強みを言語化することに困っている人は以下の記事でも取り上げられている「HEX」を意識しながら、強みを言語化→育成していくと良いと思います。
4. 正しく評価できない前提で評価制度を構築する
誤解がないように言うと、ここで言う「正しく評価できない」というのは自分自身がエンジニアでの業務経験がないからということではなく、「人を単独の目線で正しく評価することはできない」ということを指します。
私がテックメンバーと評価面談をする際は、予め期初に「自分だけの目線だとバイアスかかるから、他のメンバーにもフラットな意見もらうねー」と必ず伝えています。360度評価を入れずとも、自らの評価を構築するために、多面的な目線を取り入れることはできますし、ロジクラでは途中から360度評価を取り入れましたが、それまでは、
① 私自身がメンバーと評価コメントをもらうメンバーを合意形成する
② 評価コメントを以下の視点でヒアリングする
・〇〇さんの今期のチーム貢献は5段階で何点か？
・なぜその点数だと考えたか？
・自分では評価できないと思う部分は何かあるか？（→別の人に確認）
③ 評価コメントを整理し、メンバーと評価すり合わせ
といった流れをMBO評価を前提として行っていました。評価制度は色々あると思いますが、前提としての「人を単独の目線で正しく評価することはできない」という視点が、評価制度の納得度をより高める部分もあると思います。
また、とはいえ、評価制度は非常に重要ですので、少し古いですが、他社の評価についてのまとめもご参考までに共有します。
さいごに
このnoteを書いてみようと思った理由は、日本はスタートアップ等のIT企業の数の割に、テックメンバーの人口が明らかに足りないにも関わらず、その限られたテックメンバーが自由闊達に活躍するための組織環境があまりにもアップデートされていないという危機感があります。
未だに開発チームはCTOがなんとかするもの（→ CTOがいないから開発チームが上手くいかない）と思っている経営者も多く、そういったバイアスから脱却し、テックメンバーにとってより気持ちよく力を発揮できる企業が増えると良いなと思います。
また、noteを書く際にレビュワーをしてくれた@tchikubaやテックメンバーのみんな、ご協力ありがとうございます。
個別のお悩みについては、私も勉強させて頂きたいと思いますので、気兼ねなく、Twitter（@takesue1011）のDMなどでご相談ください。
この記事が気に入ったらサポートをしてみませんか？