はじめに
こんにちは！mentoでエンジニアをしています。tanyです。
本記事では、AIによって開発の“コーディング”が加速した先に、どんな変化や新たな課題が待っていたのか。そして、それに対して私たちがどのように向き合っているのかを率直に共有したいと思います。
特に、「AIによってコーディングがボトルネックでなくなったとき、次にボトルネックはどこへ移動したのか？」という視点で、mentoの開発プロセス全体を見直し、試行錯誤したプロセスを言語化しました。
あくまでmentoという一企業での取り組みではありますが、同じようにAI活用に取り組む開発組織にとって、何らかのヒントになれば幸いです。
背景：AIによる開発環境の急速な進化とそのインパクト
AIコード支援ツールの登場により、私たちの開発スピードはかつてないほど加速しています。Claude Code、Cursor、Devinといったツールを活用することで、数日かかっていた機能実装が数時間で完了するようなケースも増えてきました。
また、ChatGPTのような対話型AIの一般普及により、各社が一斉にAIを自社プロダクトへと組み込み始め、AI中心のサービス提供が加速度的に進んでいます。個人的には、これはスマートフォンの登場以来の市場構造の転換であり、サービス体験の“AIネイティブ化”が一気に進行しているフェーズだと捉えています。
この変化は、特にスタートアップにとって大きな意味を持ちます。プロダクトをいかに早く市場に投入し、既存プレイヤーの顧客基盤を切り崩せるかが勝負の分かれ目になります。すなわち、「AIを中心に設計された新しい体験」を、「AIを活用していかに早く市場に出せるか」が今、mentoの開発組織に求められる最重要テーマの一つとなっています。
mentoでは、2025年3月以降にAIを開発プロセスに導入しました。以降、一人あたりのコミット数やPR作成数といった指標は明らかに増加しています。※
まだツール活用の過渡期であり改善余地がある前提だとしても、AI活用が開発生産性を押し上げていることは間違いありません。
現在私たちは、新規事業としてマネジメントサクセスプラットフォームの立ち上げに取り組んでいます。
そうした背景もあって、当初は「これまでの2〜3倍のスピードでリリースしてやろう」と意気込んでいましたが、ある時ふと気づいたのです。
「あれ？コーディングは確かに速くなったけど、プロダクトのリリース自体は、それほど速くなっていないのでは？」
その違和感の正体を掘り下げると、「狭義の開発」（＝コーディング）だけでなく、「広義の開発」（＝仕様策定、レビュー、QA、ユーザー検証まで含めたプロセス）全体で見たときに、新たなボトルネックが生まれていたことに気づきました。
そこで私は、開発プロセスをシンプルに「企画 → 開発 → レビュー・QA」という3つのフェーズに分け、AI導入によってボトルネックが開発の前後のプロセスのどこに移動したのかを掘り下げてみることにしました。
これは、エリヤフ・ゴールドラット著『ザ・ゴール』で語られるように、プロセス全体のスループットを制約するのは常に“最も弱い部分”であるという考え方にヒントを得たアプローチでもあります。
※ 集計期間は、2月から執筆中の7月半ばまで。新しいリポジトリに移行したのが2月からで、5月は以降の過渡期だったため極端に増えています。
ボトルネック①：企画フェーズにおける停滞とその打開策
なぜ企画が止まるのか？
まずは開発プロセスの前段にあたる「企画フェーズ」に着目してみます。
mentoのプロダクト企画は、これまでのスタートアップにおける定石に従い、構想の言語化 → 顧客ヒアリング → 壁打ち → 仕様定義 → 開発、というプロセスを踏んでいました。
しかし、今回私たちが構想したプロダクトは、次の2点の理由により、MVP（最小実行可能プロダクト）を明確に定義することが困難でした。
1.プロダクトの対象が「チーム」であり、複数ロールを含むこと
本プロダクトは、マネージャーとメンバーという異なるロールを持つユーザー双方に価値を提供する必要があります。そのため、最低限の価値検証に必要な機能群が自然と多くなり、「最小構成」が複雑になりがちでした。
2.支援対象が“マネジメント”という複合的な営みであること
マネージャー業務の支援を行うには、単一機能では不十分で、複数の機能を有機的に組み合わせる必要があります。そのため、「最初にどのスコープから着手するか」の判断自体が難しく、意思決定に必要な情報を集めることから始める必要がありました。
従来であれば、企画や構想が固まり、ある程度販売見込みが立たない限り、機能開発を始めないというのがスタンダードです。私たちもその考え方で進めていました。
しかし、プロダクトのビジョンには一定の共感が得られるものの、具体的な機能イメージが湧かないために、顧客から明確な意思決定や導入サインを得ることができず、企画フェーズが停滞する状況が続きました。
また、初期提供機能の優先順位が定まらず、「どの機能を先にモック化・デモ化するか？」の判断がブレてしまい、開発チームもその間は開発環境の整備などの準備作業を優先する形で、プロダクトとしての前進が止まりかけていました。
どう動いたか：MVP定義よりも“まず作って見せる”
この状況を打開するために私たちが取ったアプローチは、「仮説の正確さ」よりも「とにかく※動くデモを早く出すこと」を優先する方針転換でした。
たとえ仮説が粗くても、ある程度のストーリーが描ける範囲で構成を決め打ちし、CursorやFigmaを活用して、短期間で動くデモを組み立てて顧客に見せたところ、そこからの反応が劇的に変化しました。導入検討に前向きな動きが次々と現れたのです。
ここから私たちが得た大きな学びは次の2点です。
1.イメージできないものは、顧客は評価・判断できない
特に類似サービスのない新規カテゴリにおいては、視覚化・体験化されない構想は、共感されづらく、判断材料として不足する。
2.「AIでできます」は夢物語に見える
「AIで支援できます」と言葉で語るだけでは抽象的すぎるため、顧客からすれば実現性が不明なままに映ります。しかし、具体的な動作例や操作デモを提示することで、初めて「これは現実にできるのかもしれない」という認識に変わります。
しかしAIを組み込んだプロダクトの場合、その特性上、「何ができるか」を言語だけで伝えるのが難しく、実際に動くものを見せないと価値が伝わらない場面が増えます。
だからこそ、完成度にこだわるよりもまず走り出し、顧客に当ててみる——そのサイクルを最速で回すことこそが、結果的に仮説の精度と意思決定の質を高める近道である、という考え方自体は、従来のプロダクト開発でも一定の共通認識だったと思います。
ただし、それを実行するのは簡単ではありませんでした。仕様が固まらないまま作るリスク、捨てることへの心理的負担、そして「やるなら完成度高く」という無意識のブレーキなど。
しかし今はAIによって実装のコストとハードルが大幅に下がったことで、“まず作って捨てる”という選択が現実的かつ健全な戦略になりました。
だからこそ今の開発チームには、「捨てる前提で素早く手を動かすこと」が求められているのだと、私は考えています。
※ この時の開発手法については、@kadoppe によるこちらの記事で詳細に紹介しています：Cursor x Figmaを使って、チームでプロトタイプを高速開発して得た学び
ボトルネック②：レビュー・QAプロセスに潜む構造的な課題
レビュー・QAが新たな律速段階に
AIコーディング支援ツールの利用により、開発者が1日に複数本のPRを出すことも珍しくなくなりました。実装速度の向上は歓迎すべき変化ですが、その分レビューやQAが開発全体のスループットに影響を及ぼす場面が増えてきています。
mentoにおいても、以下のような課題が顕在化（あるいは今後の懸念として潜在）していると感じています。
-
レビュー負荷の急増
実装速度に比例してレビュー対象も増加しており、レビュープロセスが律速段階になりつつあります。特にAIが生成したコードは「なぜこの実装になったのか？」という背景が見えにくいため、実装者が意図や前提を明示しないと、レビュー時間が大幅に膨らむ傾向があります。 -
品質とスピードのトレードオフ
「とりあえず動くコード」がAIによって量産される中で、それが仕様通りなのか、あるいはユーザー価値に本当に繋がっているのかを見極める難易度が上がっています。ライブラリや設計パターンに対する理解が曖昧なままでも“それっぽい”コードが生成されるため、レビュアーとしてどこまで深く立ち入るべきかの判断が曖昧になりやすくなっています。 -
QA視点のズレ
現時点ではまだ開発中のプロダクトは本番環境にリリースしておらず、QAも基本的な動作確認に留まっています。しかし今後運用が始まれば、「仮説に対して正しく使われているか？」という価値検証視点でのQA設計が求められるようになり、現状のままではその役割を果たしきれないリスクがあります。
つまり、開発スピードが上がったからこそ、品質・意図・価値検証のプロセスが追いつかず、結果的にボトルネックとして顕在化しつつあるという構造です。
どう動いたか：ナレッジと文脈を仕組みに組み込む
現時点で私たちが取っているアプローチは限定的ではありますが、いくつか手応えのある取り組みが見え始めています。
1.AIのアウトプットに対するガードレール整備
AIがコーディングする際には、選択肢が無数に存在します。明らかに筋の悪い提案は弾かれるものの、プロジェクトに合わない／意図していないコード※が出てくることは少なくありません。
こうしたナレッジの明文化は、既に実施されている方も多いと思いますが、私たちもこれをチーム運営に組み込むことで、AIとの協調精度を高めようとしています。
このように「暗黙知」を「構造化されたナレッジ」として残すことで、AIが出力するコードの質がチーム全体で一定水準に均一化されるようになります。
私たちのチームでは、モノレポ内に REVIEW_GUIDELINES.md のようなドキュメントを配置し、コードの近くにナレッジを残すことで、開発フローの中で自然に参照・更新できるようにしています。
これにより、レビュアー側の認知負荷が下がり、指摘がブレにくくなるという効果も出始めています。
また、Linterやテストコードといった形式的なチェックに加え、レビューコメントで指摘された箇所を上記ドキュメントに反映することで“再発防止のガードレール”として機能させる運用も進めています。
※補足：今後、モデルの性能向上により「コンテキストを明示しなくても適切な出力が得られる」世界が来る可能性は十分にあると考えています。ただ、現時点では文脈が明文化・構造化されていないと、AIは意図と異なるアウトプットをしやすく、運用上の再現性や品質担保の観点からは、ガードレールの明示は依然として有効なアプローチであると判断しています。
2.PRにも多くのコンテキストを残すように
これもすでに実施している方が多いと思いますが、AIによるレビュー補助も進めています。以前はGitHub Copilotのコードレビュー機能を使っていましたが、現在はClaude Codeを活用し、PR作成時に自動レビューコメントを生成するようにしています。
加えて、レビュイー自身がPRのディスクリプションやインラインコメントで意図や背景を説明することで、レビュアーがコードの全体像を掴みやすくなるよう工夫しています。
これにより、レビューの初動が早くなり、バグの早期検出にもつながる“セルフレビュー”の効果も生まれています。
ただし、これはあくまでPR単位の支援であり、プロジェクト全体への影響まではカバーできないため、レビューは依然として人間の判断に依存している部分が大きいのが現状です。
現時点で、レビュー・QAプロセスにおける対策はまだ途上であり、「克服した」と言える段階には至っていません。特にQA領域はまだ実運用前ということもあり、具体的な仕組みの構築には着手できていないのが実情です。
一部では、PR内容をローカルでAIと一緒に掘り下げて検証するといった個人レベルの工夫も見られますが、これも限定的です。ただし、確実に「負荷を下げながら、判断の質を上げる」ための有効な手段は増えてきており、今後の本番運用フェーズに向けて、さらに試行錯誤を続けていく必要があると感じています。
おわりに
私たちは、AIによって「コーディング」という工程が飛躍的に高速化されたことを素直に歓迎しています。
一方で、それがプロダクト全体の開発スピードやアウトカムの向上に直結するわけではないという現実も痛感しました。
この経験から得た最も大きな学びは、「開発におけるボトルネックは常に変化し続ける」という前提に立ち続ける姿勢の重要性です。
AIの導入によってコーディングが加速すれば、その前後に位置する企画やレビュー・QAといった工程が新たなボトルネックになり得ます。
今回の記事では「企画」「レビュー・QA」の2つに焦点を当て、ボトルネックの移動と、それに対する私たちの取り組みをご紹介しました。
技術や環境が変われば、次のボトルネックもまた別の場所に現れます。
mentoは、そうした変化を捉えながら、コードというミクロな対象に向き合いつつも、プロダクト全体を俯瞰するマクロ視点を持った“プロダクトエンジニア” のチームで開発をしています。
「今、最も解消すべきボトルネックはどこか？」を見極める意識。そして、「自分のアウトプットがプロダクト体験や価値にどう結びつくか？」を捉える視点。
こうした姿勢を持つエンジニアが、これからのAI時代において開発組織を前に進める大きな力になるのではと、私たちは感じています。
本記事が、同じようにAI活用や開発プロセスの変化と向き合うチーム・個人の一助になれば幸いです。
お知らせ
mentoでは、新規プロダクトの立ち上げフェーズに関わってくれるエンジニアを募集しています。
AI時代の開発スタイルに適応しつつ、プロダクト視点で価値を届ける。そんな思考で一緒にものづくりを進めていける方と出会えたら嬉しいです。
少しでもご興味をお持ちいただけた方は、まずはカジュアルにお話しできればと思います。
ご応募はもちろん、各種SNSでのDMも大歓迎です！
Discussion