ワイヤレス Bluetooth マウス 【極薄型モデル Bluetooth 5.3&2.4GHz】 マウス 静音 3段階DPI調整(800/1200/1600) 超軽量 Type-C充電 スリープモード 高精度 小型まうす 左右対称 節電 7色LED 人間工学設計 コンパクト オフィス ゲーム Mac/Windows/Surface/PC/Macbookに対応 (ブラック)
￥1,599 (2025年5月4日 13:08 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
USB C ケーブル 純正 1M 2本セット PD対応 60W急速充電 USBタイプc ケーブル USB-C & USBC データ転送 高耐久性 断線防止 映像出力不可 Type-c to Type-c コード for iPhone 16/15 Pro/Plus/Pro Max、for MacBook Pro/Air/IPad Pro/AirなどTypec機種対応
￥799 (2025年5月4日 13:17 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
こんにちは。主に XにてAI駆動開発について発信している熊井悠 です！
さて今回の記事ではAI駆動開発の組織を1年ほど運営してきた経験を踏まえて失敗や学びを共有したいと思います。
補足：AI駆動開発
AI駆動開発とは AIソリューション（CursorやWindsurfなど）を利用したシステム開発の通称です。最近は書籍も増えており一般化しつつある用語ではあります。
主に2024年の春頃からAI駆動開発組織として受託開発プロジェクトを中心にシステム開発に取り組んできました。1人での開発ではなくAIコードエディタ(Cursor)を開発の中心に据えた複数名の組織の場合に起こる失敗や対策などをお伝えします。
前提：なぜAI駆動開発に取り組んだか？
元々システムインテグレータに勤務しておりエンジニアやプロジェクトマネージャーを経験したのちに自身で会社を創業しました。 主にベンチャーSIerのような事業で約5年ほど会社経営をして参りました。
ベンチャーになって気づいたのは人月商売の難しさ、優秀なエンジニア人材を確保する難しさです。SIer時代はどれほど恵まれていたのかを痛感しました。
そうした経緯もあり2023年にChatGPTを少しずつシステム開発現場へ落とし込みを行い、2023年夏～秋頃にAIコードエディタのCursorを初めて触ってみて、可能性を感じたのです。これを組織化したら今までの悩みがすべて解決するかもしれない。
そう確信した僕は2024年初めから、まずはChatGPTから始まり、そのあとCursorを社内展開するなどしてAI駆動開発組織を作り上げてきました。
今では社内ではAI駆動開発は当たり前となったのですが、紆余曲折と失敗や成功があったので、五月雨にはなりますが、得た学びを紹介したいと思います。
1. AIはエンジニアとしての技量ありき。だが対策はできる
最初にぶつかった壁です。
エンジニアメンバーがAIの生成したコードの内容の妥当性が判断できない。
AIが記載している説明を読むと何となく正しそうに感じるが、果たして本当に正しいか？
当時はAIの出力内容がリアルタイムな検索ではないこともあり「どのような情報源を元に提案しているか？」が全く分からない状態でした。
そのため CursorでClaudeモデルで生成した内容をChatGPTにレビューしてもらうといった組み合わせ技を取るなりで妥当性を反対するなりをしていました。
しかしながら想定外の実装方針を採用するリスクは付き纏うため、エンジニア自身の技量に左右されました。
では、エンジニアの技量がなければAIは扱えないのでしょうか？
僕の答えは “No” です。
AIは等身大の鏡のようなものです。
自分自身の仮説ありきで生成することができれば確かなコード生成をすることができます。
つまり「全く未知の生成はせず、きちんと下調べしてから」と言うことです。
また、組織の力を借りればシニアエンジニアの方がアーキテクチャ設計を行うことで技術を確定し、AIによる「よくわからないコード生成」を回避することが可能となります。
これが組織の強みであり、得意に応じたチーム設計をすることでAIの力を最大限に引き出すことができます。
2. 要件定義と設計が従来以上に重要になる
Cursorを使ったAI駆動開発を取り組んでいたところ、要件と異なる生成が散見されるようになりました。
なぜか？それはその箇所の要件定義・設計が抽象的すぎたため、AIに判断の余地を与えてしまったからです。
具体例をみてみます：
会員管理システムにおける「会員登録時のフォーム内容」を考えます。
- 要件定義では「電話番号」の形式が曖昧のまま経過した
- クライアントの頭の中では「09012345678」形式を想定した
- 実際の生成では「090-1234-5678」となってしまった
エンジニアなら「これは聞いたほうがいいな」とクライアント企業へ確認したかもしれませんが、AIはプロンプトの指示を完遂することが前提なので、自己判断で生成してしまったのです。
レビュー経験のある方はわかると思うのですがコードレイヤで細かな要件レベルのポイントを検知するのが意外と難しいのです。
非常にシンプルな例ですが、AIはインプットありきなのでより厳格な要件定義・設計がないと想像からかけ離れた実装になってしまう のです。
3. 1番バリューを発揮したのは実はプリセールス活動だった
厳格さを求めなくても問題のない工程があります。
それは プリセールス（提案営業） です。
クライアント企業の要件が定まっていない状況下において、議論のたたき台となる モックアップやドキュメントが一瞬で生成できるAIは非常に強力な存在でした。
他の会社の提案が文字ベースなところを実際に動いて触れるモックアップによる実現性を見せれることは競争力の簡単でも効果的でした。
また、システム開発経験がないセールスチームでもAIの力を借りることでエンジニアに聞かなくても営業活動の幅が広がり、効果絶大でした。
プリセールス活動ではAIで要件定義や設計のドキュメント生成が行えるGEAR.indigo にかなり助けられました。（↓画像）
4. 従来型PMの役割からプレイングマネージャーが推奨されるように
AI駆動開発組織にした結果、PMに求められる能力は管理だけではなく実装などの実務まですべて見渡してAIにタスクを渡すスタイルになってきました。いわゆるプレイングマネージャーです。
AIに対する指示出しとアウトプットのチェックはマネジメント＋技術経験が必要です。
なぜなら、AIを活用する上では
- 適切なサイズ感でメンバーに対してのようにタスクを切り出す
- 成果物を盲目的に信じず、技術的な観点含めてチェックする
この2つが重要だからです。
そのため技術力ありきでPMを担当する場合にAIに任せる範囲の特定やフィードバックがしやすいためプレイングマネージャーな方法論が非常にしっくりきました。
5. 要件定義が早すぎてスピード感が合わなくなった
AIによる要件定義・設計により、成果物生成は 従来の1/10のスピード になりました。
下記のポストの内容はまさにそれを表しています。
しかし、クライアント企業の担当者との議論のスピードが合わないという問題が生じてしまいました。こちらの提示が早くても議論のスピードまで早くはならないからです。
請負型の人月モデルでは、待ち時間が増えると 工数が無駄に消化される のです。
そこで直近では「プリセールスの段階でAIで生成したモックアップでの議論のすり合わせ」や要件定義・開発工程は準委任契約に切り替えるなど行うことで、AIのスピード感を活かすようなモデルに切り替えています。
6. 生成対象のサイズ感（コンテキスト/Codebase）が重要
以前Qiitaにて下記のような投稿をしました。
全てをコード化することでAIに展開しやすくなるというトピックなのですが、1点注意が必要です。それはプロンプトに投じるコンテキストやCodebaseのサイズ感が大きすぎると、生成結果がブレやすくなるということです。
実際に、情報量が多いとAIは要約しようとします。そのため結果として 品質の低下や見落としが発生 してしまうのです。
対策としては下記のようなものを考えるべきなのです。(Cursor前提での話)
-
.cursorignoreやRulesを活用 - コンテキスト情報の参照範囲を厳密に管理
7. メンバーにRulesやコンテキスト管理までお願いするのは難しい
当社ではメンバーに対してRulesやコンテキスト管理までお願いしていましたが結論としては「なかなか難しいな…」という感触でした。
なぜか？僕は好きがゆえにAI駆動開発の方法論の探求を日々続けているので、Cursorの利用方法や最新のアップデートの内容、LLMモデルの性能などは何となく頭に入っています。
しかしながらメンバーに常にそのあたりをキャッチアップしてもらいながら日々開発を続けてもらうのは時間的な観点でも難しいのは当然でした。
そのため下記のような体制・役割にすることで解決するように直近では努めています。
- コンテキストやRules管理はマネージャーやリーダーが担当
- メンバーは 生成とコード実装に集中 できる体制にする
実際の体制イメージは下記のポスト参照ください。
8. AIエージェント型ツールは負の遺産の解消に利用するのが良い
当社ではDevinを導入して幾つかのタスクを切り出して取り組んでいます。
結果としてわかったのは実装までの過程や流れがわりとブラックボックスになることが多く、妥当性の判断が難しいということでした。
Slackでの指示からGitHubのPRまで一気通貫で進めてくれる近未来感は非常に好きなのですが、限られた時間で判断を下すのがかなり難しいとわかりました。
最近ではリファクタリングやドキュメント更新漏れへの対応など未来において負の遺産になりそうなタスクを取り組んでもらうことが最適なのではと考えており、そうしたタスクを渡すようにしています。
今後もwikiや品質担保系（テストなど）を中心にプロジェクト品質の底上げに対して利用する形で取り組もうと思っています。そのため現在では下記のようなチーム体制を目論んでいます。
9. 組織の規模のスケールが難しすぎる
2024年から構築したAI駆動開発の組織ですが、案件の受注も伸びていたこともあり体制を増強していったのですが、困ったことに体制が大きくなればなるほどAI駆動開発の良さが失われていきました。
なぜかというと、AI駆動開発の方法論が一般化していないこともあり、スケールする際にジョインしてもらう業務委託のメンバーの方にまでAI駆動開発のノウハウをキャッチアップしてもらう時間的な余裕すらなかったからです。
そのため組織規模が大きくなった結果、AI駆動開発組織から従来型の開発組織に近づいていきました。
僕にとってこの壁は途轍もなく高い壁として立ちはだっていたのですが、最近やっと打破する方法を思いついて取り組んでいる最中です。ここはまた記事にして出せればと思っています。
とはいえAI駆動開発のパワーのおかげでここまで楽しく走ってくることができたので挑戦し続けたいと思います。
思いつくままに 9つの学び を列挙してみました。
AI駆動開発は非常に未来の可能性を感じさせる素晴らしいものです。
しかしいざ組織導入しようと思うと想像以上の壁や難しさも訪れます。
大事なのは「学ぶことや変えることを厭わず、愚直に進み続けること」です。
ぜひ皆さんの参考になると嬉しいです！
普段はXでAI駆動開発の組織論などについて語っているのでぜひ未フォローの方はフォローしてもらえると嬉しいです！また『クマイ総研』というAI駆動開発のコミュニティ運営もしています。月に2～3日しか募集していないのですが気になる方がいればぜひチェックを！
ではでは、皆さんの貴重なお時間でお付き合い頂きありがとうございました！
クマイでした～
Views: 0
