はじめに

「強い開発チーム」というと、Four Keysの指標が高い、技術力の高い優秀なエンジニアが多い、そんなイメージを持たれることも多いでしょう。

しかし、長年スタートアップでキャリアを積んできた私が思う定義は違います。

スタートアップ文脈で本当に強い開発チームとは、事業や顧客にどれだけの価値を付加できたかに本気でコミットしているチームだと私は考えています。

現在の会社ではEMを拝命してから1年4ヶ月ほどになりますが、私は常に前述の意味での強いチームを作るためにCTOと二人三脚で様々な施策をやってきました。

本記事では、私が思うスタートアップの本当に強い開発チームとはどういう状態なのかの深堀りと、そのチームを作るためにこの1年強、EMとして何をやってきたのかについて振り返ってみたいと思います。

私が考える「強い開発チーム」

大きな会社であれば、役割は細かく分かれ、責任範囲も限定され⋯という状態が一般的であり、それぞれの役割に応じたKPIを設定してそこに向かって業務を行うことになるでしょう。

ただ、スタートアップはほとんどの場合、頭数という意味での人が足りていないだけでなく、役割を分けたところで、その役割を専門性高く十分に処理できる人材というものがいません。

また、「エンジニアは作る人」、「PMは考える人」と分けてしまうことで、誰も事業全体に責任を持たない状態になることもよくあります。

これらのことから、私はスタートアップにとって「強い開発チーム」は事業結果そのものにコミットし、自分たちでやる／やらないを判断できるチームであると考えています。

私がこれまで経験した中で、「強い」と感じたチームには、下記のような特徴があります。

常に売上、KPIなどの事業の数値を頭に入れ、ゴールから逆算してやるべきことを決めている
PdMやPO（プロダクトオーナー）から示されたタスクや仕様について、「この施策はどのKPIに影響するのか？」という質問が出てくる
「そもそも今これをやるべきか」という議論が展開される
他のチームが実施した施策で良い結果が出たものは、躊躇なく盗む
プロダクトへの愛が深い

このようなチームで、エンジニアが単なる「実装者」であるわけがありません。
PMやセールスと同じように、事業を前に進めるための判断に参加する存在である必要があります。

エンジニアが判断、意思決定に参加できるようになることで、スタートアップに必要なスピード感を得られることにもなります。

私が考える「強くない」チーム

続いて、逆に「強くない」チームについて触れます。
一言で言えば、タスク消化のみにフォーカスし、事業への当事者意識が低いチームです。

自社サービスであることを理由に、納期遵守への意識が低い
「なぜこの機能を作るのか」「誰のどんな不満を解消する機能なのか」 を自分の言葉で説明できない
事業の数値に興味を持たないのに、評価だけ求める
自分のプロダクトが 誰にどう使われているか知らないし興味もない

このような状態では、誰も使わない無駄なものが大量に作られ、ユーザーからは見放され、事業的にうまくいかないのにコストだけは増えていき、会社もプロダクトも疲弊していくでしょう。

リソースが限られているスタートアップで、無駄なものを作る余裕はありません。

EMとしてやったこと

「強いチーム」になるか「弱いチーム」になるかを分けるのは、エンジニア個々人の意識だけではありません。

多くの場合、組織内の環境やルールがそうさせています。

私はEMとして、「エンジニアにももっと事業のことに興味を持ってほしい」と言葉で伝えると共に、自然とそうなっていくように、CTOやPMと一緒に環境やルールを変えていくことに注力してきました。

会議への参加ルールを変えた

現在の会社では週に1回、セールスからPMへ、顧客からの声を含む要望が伝達される「要望伝達会議」があります。

セールスからの要望に基づいて、PM（PdM）が開発に回すかどうかの判断をする場ですね。

当初、この会議にはセールスとPM、そしてCEOといったメンバーしか参加しておらず、エンジニアの参加はありませんでした。

そこで経営陣に対して「顧客が本当に望んでいるものが何か、できるだけ生の声に近いセールスの意見を聞いてみたい」とアピールし、まずはEMである私だけがエンジニア代表で参加させてもらうことになりました。

それから約1年、時間はかかってしまいましたが、1on1を通じて各エンジニアメンバーと話し続けた結果、私から促したわけではなく、メンバー本人から「私もセールスとPMの会議に参加してみたい」という声を引き出すことに成功。

今では、経営陣の理解も得られ、エンジニアメンバーもその会議に全員出入り自由という体制を取ることができています。

実際に参加したメンバーからは、「なぜ今これをやるのかがわからない時もあったけど、PMさんがどのように優先度を考えているかわかった」、「顧客がどれくらいの熱量で改善を要望しているのか、PMを通すよりもリアルに伝わった」という声ももらっており、エンジニア個々人の当事者意識を高めることに繋がっているのは間違いなさそうです。

数値の見せ方を変えた

主体的に取り組むには、情報がオープンになっていなければいけません。

必要なときに必要な情報へアクセスできなければ、「自分はここに興味を持たなくていいんだ」となってしまうのは当たり前でしょう。

現在の会社では、月ごとの売上目標とその結果の共有が月1回セールスからされる程度に留まっており、それ以外の事業に関する数値（製品ごとの売上本数や施策に対する効果など）は一切エンジニアには公表されていませんでした。

この問題については早くから経営陣にも共有し、理解も得てきましたが、コンプライアンス、情報漏えいに関する研修をやってからにしよう、ということもあって実現にはかなりの時間がかかってしまいました。

CTOの働きかけのおかげもあり、2ヶ月ほど前から月1回、PMからエンジニアへの事業数値の共有会を実施できています。

この取り組みについても、「自分が関わっているプロダクトが多くの人に使ってもらえていることがわかってモチベーションが上がった」、「そもそも他のチームが何をやっているのか知らなかったが、これをきっかけに興味を持つことができた」など、エンジニアの意識が変わってきていることを実感できる声があがっています。

タスクのアサインを変えた

これが2025年、最も大きく変わったことかもしれません。

これまではPMから各エンジニアメンバーへ直接行っていたタスクのアサインをやめ、PM→エンジニアチーム へのアサインに変更しました。

これにより、

チーム内で進め方を相談する
ペアプロやモブプロを選択できる
属人化を防ぐ動きができる
個々人のキャリアプランを踏まえたアサインが可能

という効果が生まれ、「アサインされたタスクをこなす」状態から、「チームとしてどう取り組むのが最善かを考える」へと少しずつではありますが、変わり始めているように見えます。

というのも、まだこの取り組みを実施し始めてからは2回のスプリント程度しか回せていません。

本領を発揮するのは、もう少しメンバーがこの方式に慣れてからでしょう。

残る課題とメンバーからのメッセージ

ここまで、私が「強い開発チーム」を作るためにやってきたことのうち、代表的なものを3つご紹介してきましたが、まだまだ道半ばです。

変化の兆しが見えている一方で、まだチーム全体に広がっている状態とは言えません。

情報のオープンさにはまだ制約があり、情報漏えい防止の観点から、その場限りの共有に留まっており、あとから振り返ったり、じっくりデータを見ながら考える、といったことはできません。

また、私たちのプロダクトはいわゆるバーティカルSaaSということもあって、業界特有の専門知識が必要であり、会議に参加してもすぐにPMとセールスが話している内容が100%わからず、理解を諦めてしまうエンジニアもいます。

来年、2026年は、こうした問題にも取り組んで、更に段階を上げた「強い開発チーム」を作っていければと思っています。

最後に、今年いっぱいで退職し、次のステージに進んだあるメンバーからのメッセージを紹介してこの記事を終わろうと思います。

Matsudaさんが入ってから開発組織が大きく変わってすごいなと思ってました。

メッセージをくれた彼は、2025年末で退職するまで3年ほど技術面で会社を支えてくれました。（私は入社してまだ2年も経っていないので彼の方がだいぶ先輩です）

そんな彼からもらった「開発組織が大きく変わった」という言葉は、なかなか自分が思う理想の「強い開発チーム」にたどり着くことができずにもがき続けている私にとって、少ししか前進していないように見えて、現場からは「大きい」と見えているんだ、という自信につながりました。

今後も根気強く、「強い開発チーム」を作っていきます。