開発組織の責任者に求められる役割とは？

株式会社メタップスホールディングスの釣りバカVPoE、阿夛（@ataboy86）です。

現在は、「re:shine」というフリーランスのマッチングプラットフォームの事業責任者をやりつつ、VPoEとして開発部門の統括をしています。

今回は、「開発組織の責任者に求められる役割とは？」というテーマで、VPoEとして開発組織をまとめている経験談も踏まえて自分の考えをまとめました。

まず、開発組織の責任者ってどんな人達？というところに触れておきます。

CTO：経営層に近い役割を持つ開発の責任者
VPoE：複数のEMを取りまとめつつ、経営意思反映と現場EMの橋渡し役
EM（エンジニアリングマネージャー）：チームを取りまとめるエンジニアリングマネージャー

こういった人たちが開発組織における主な責任者と呼ばれる人たちですが、今回はこの役割を持った方や、目指す方にとって少しでも参考になればと思います。

先に結論から申し上げますと、開発組織の責任者に必要な役割としては、主に下記の4つだと考えています。

1.会社の意思の伝達
2.持続的な成長
3.業務環境の整備
4.事業貢献に対するモチベート

１、会社の意思の伝達

会社にとって開発組織の最優先事項が何かを自分自身が深く理解し現場に落とし込むこと（伝達）が、求められるリーダーシップとして、つまりはVPoEとしての最大の任務だと思っています。

☝️例えば・・・

「アプリケーションパフォーマンスが低く、サーバーコストが上がってしまっている」
→言語課題であれば技術選定、インフラ課題であればアーキテクチャ選定などを見直す。

「離職率が高い、満足度が低い」
→リモートワークや1on1など、業務時間内の制度の整備など。
逆に、コミュニケーション課題があるのであれば出社頻度を上げるなど。ただし、逆効果の可能性もあるので理解促進が重要。

「いま、この会社においての開発組織の課題がなにか」を考え、短期的な課題と中長期的な課題を洗い出し、会社に対して改善策の提示、そして改善の実行をしていきます。

組織のリーダーとして、会社（経営層）と開発組織の橋渡し役となり会社全体の方向性を定めていくことは欠かせません。

２、持続的な成長

責任者は、組織をまとめるだけではいけません。
組織としての成長も同時に考え、持続的に成長できる環境を用意していきます。

開発組織を持続的に成長させていくために、今の組織に足りていない部分や効率化できる部分を見つけ、改善を行っていくことが必要です。

今回は、持続的な成長の観点において重要な2つの要素をお伝えします。

（１）技術レベルの底上げ

技術レベルの底上げに関しては、現行の技術を深掘りしてさらに知識をつけていく。また、新しいチャレンジ（インプット）を行う仕組みを整えます。

💡弊社の取り組み・・・
・社内LT会の開催
・技術本の輪読会   etc…

弊社では上記のような取り組みを継続的に行い、インプット・アウトプットを習慣化する取り組みを行っていたりもします。

成長と挑戦の機会を提供することで、技術レベルを底上げし、技術レベルが向上することによって組織としての能力も向上します。

（２）組織への定着

会社にとって、「エンジニアの定着」は開発組織の持続的な成長にとって重要な使命です。
私は、一緒に働くメンバーに、「良い会社」「良い組織」と思ってもらえるように日々取り組んでいます。

特に、経験が少ない若いエンジニアほど、他の会社に目移りしやすいものです。
他の会社の良いところを「良くない」と伝えても、本人にとっては納得感の無いものです。
他社にない自社の良さを感じてもらうことや、成功体験を定期的に積ませて成長を感じる機会を増やすことで、自社の魅力に気づかせることが大切です。

３、業務環境の整備

組織の責任者は、業務環境の整備も行います。
前章（２）であげた「組織への定着」にも寄与する部分です。

（１）現行事業の技術選定は適正か

今ある事業で使っている技術は適正なのか、再確認しましょう。
適正でないのであればコストも踏まえて、再考する必要があります。

例えば、サービスにおけるピークタイムに合わせてサーバーを固定していて、常にピークタイムのリクエストが捌ける台数を用意しているという状況はスケーリングを調整するような仕組みを用意する必要がありますし、技術的に解決できるコストは直接事業インパクトもある部分なので、重点的に整備すべき部分です。

（２）出社が当たり前なのか、リモートワークが主軸なのか

新型コロナウイルスの影響もあって、リモートワークが普及しましたが出社頻度を増やした会社もあると思います。

現在の会社において開発組織が出社するメリットはなにかを再度考えて、「何のために出社しているのか」をメンバーに伝えることも重要です。
また、リモートワークで業務をする際の注意点やルールはどういったものかの取り決めも必要になります。

弊社では、リモートワークが当たり前でなかった頃から一部リモートワークを取り入れており、「水曜リモートDay」などを設けていました。
そういった取り組みを事前に取り組んでいた中でも、いざフルリモート、という環境ではなかなかパフォーマンスが上がらず苦労しましたし、今でも完全に解決したと言える状況ではありません。

スタートアップやベンチャーでリモートワークが一気に広がりましたが、事業がマニュアル化されていたり、仕組みで売れる形になっていない組織でフルリモートというのは、個人的に正直厳しいと考えています。

仕組みになっていないからこそコミュニケーションがすぐに取れる環境の用意は必要です。それを解決するためにバーチャルオフィスの仕組みを上手く活用したり、出社義務を一定用意し、チームが即座にコミュニケーションを取れる形は用意してあげる方が結果的に満足度は高いかもしれません。

４、事業貢献（や組織貢献）に対するモチベート

エンジニアにとっても事業貢献や組織貢献は重要です。
そのモチベートには開発組織をまとめる立場として向き合わなければいけません。

スペシャリティーを活かして開発業務だけで信頼される状態を作ることも重要ですが、スタートアップなどでは他の業務で貢献できるポイントも多いので、「誰かのため」の業務で組織内の信頼される人にもなりやすいです。

1つのことだけでなく、複数の信頼ポイントを積むことで、会社の仕組みや必要なパーツなども見えてくるというメリットもあるし、仕事においては「情報量」は強みになります。

「開発すること」はもちろん重要ですが、事業の数字が伸びなければ評価もしづらくなってしまいます。

「自分自身がその事業に対して何ができるのか」
「どんな行動をするとプラスに働くか」

つまり、事業の数字を伸ばすということに繋がる行動が結果として自分の評価に繋がりやすく、事業体として、協力要請があったら協力できることはやる精神は必須です。

これを意識させ、推進するために評価項目に用意し、1on1などで定着させていくことも効果的です。

５、改めて念頭に入れておかないといけないこと

冒頭で触れましたが、「会社の意思」が最優先になるということは念頭に置かなければなりません。

「会社の意思や最大課題を解決するために何をしなければならないのか」
「その課題が解決できることで会社にとって開発組織にとってどんな未来が待っているか」
を組織にしっかりと落とし込むことが重要です。

☝️例えば・・・

今の事業に対して、技術選定に失敗していて、スケジュール感が合わない状態と仮定すると、技術を置き換えが必要になるが、置き換えるとなると少なからず人的コストも金銭的コストも掛かる。

コストを掛けたときに、ビジネスサイドからすると「結果が何も変わらないのに時間だけ過ぎた」という印象にならないように、ビジネスサイドに対し明確に効果がわかるように伝えることが重要。伝わっていないと「無駄」と言われてしまい、結果として開発陣のモチベーションも下がってしまう。

一方、メンバーにもこの取り組みが終われば今後の開発も負担が軽くなり、開発効率が上がるという意識付けが必須。

６、【おまけ】開発組織によくある課題とその解決策

（１）慢性的なエンジニア不足

年々エンジニアの採用倍率は上がり、市場にはエンジニアが不足しているのが現状です。
エンジニア不足は、多くの企業が頭を悩ませている課題ではないでしょうか？

エンジニア不足という現状は明白ですが、それでもやれることはあります。
採用担当ではなくとも、「エンジニア採用」については、課題をブレイクダウンして、採用活動にしっかりと向き合うことが重要です。

（２）離職率が高い

エンジニア不足が慢性化している中で、今一緒に働いているメンバーをいかに離職させないかが重要です。
エンジニアにとって働きやすい環境は整っているのかどうかを見直すことは重要です。

☝️例えば・・・

・ツール選定（業務効率化）は適切か
・チーム環境（人間関係や開発体制）は健全か
・評価は明確で納得感があるか

弊社が離職率を下げるための取り組みを、「エンジニア採用市場がぶっ壊れている今、離職率を下げるためにやったこと」で詳しくまとめているので、合わせてお読みいただけると幸いです！

（３）周辺部門からの評価向上

開発組織が誰にどのように評価されるかを理解し、評価されやすい状態を作り出すことが重要です。

評価が下がりやすい例
・開発スケジュールの遅れ
・不適切なアイデアの阻害
・協力体制の低さ

まとめ

あくまで役割の話がメインでしたが、具体的にどんな取り組みをするべきか、その結果が会社の期待とズレていると、組織に取っては良い方向になりません。

ちなみに私の組織では、CxOというポジションが存在しないため、いくつか存在する開発組織が分断されてしまうことを危惧し、VPoEとして開発組織全体を見れるポジションを作ってもらい、私自身がその役割を担っているという形です。

会社としての開発組織に期待される役割はフェーズによって大きく変わってくるものです。
事業推進以外をやる必要性が無いフェーズもあるでしょうし、組織としての成長を求められるフェーズもあると思います。

そのなかで開発組織の責任者としてはメンバーのモチベートから開発パフォーマンスの最大化というのは常に意識をしておく必要があるため、プレイングでやりながらだとなかなかヘビーな時間の使い方になっていくものです。
少しづつ役割を分けたりと、最注力すべきところに割ける時間を作るということを意識するのが良いでしょう。

ごく一般的な内容になってしまった気もしますが、開発組織の責任者になった方や、これから目指そうと考えている方に、少しでも気づきになればと思います。