0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ソロでも大型案件を回せる時代が来た。AI駆動開発は「コードを書く前」で差がつく

0
Posted at

アップロード容量が月の制限(100MB)を超えました。設定 -> アップロードしたファイル から、当月にアップロードされた不要なファイルの削除を行ってください。

正直、AI駆動開発の本質って、コード生成そのものではないと思っています。

本当に効くのは、提案書、要件定義、設計、実装手順、進捗管理みたいな「書く前」「作る前」の工程です。

ここをAIで回せるようになると、開発スピードが上がるだけじゃなく、ソロでもかなり大きい案件に挑みやすくなります。

最近よくある「AIで爆速開発」という話も、実際にはこの前工程をどう作るかで勝負が決まる、というのが個人的な実感です。


まず何が変わったのか

従来の大きな開発案件は、提案書、計画書、要件定義書、設計書、レビュー対応、進捗管理と、コードを書く前にやることが多すぎました。

しかも会社員エンジニアだと、外部サービスの規約だけでなく、社内規定や標準プロセスまで守る必要がある。ここが一番重い。

個人開発だと勢いで作れても、会社案件はそうはいきません。

だからこそ今は、社内ドキュメントにアクセスできるAIを前提にして、最初から工程を設計したほうがいいです。

たとえばGoogle Workspace中心ならGemini、Microsoft 365中心ならCopilot。

重要なのは、社内の資料・規定・過去資産を見にいけるAIアシスタントを使うことです。


提案書づくりは「語る」ところから始めたほうが早い

ここ、かなり大事です。

最初から綺麗な文章を書こうとすると止まります。なので、まず10〜15分くらい、音声でひとり語りしたほうがいい。

何を作るのか、なぜ作るのか、できたら何が変わるのか。

ちぐはぐでもいいので話し切る。これだけで、頭の中に散らばっていた論点が一気に材料になります。

そのあとにやるべきなのは、要約ではなく全文文字起こしです。

ここを雑にすると、後で設計に入ったときに「あれ、最初に言ってたこと消えてるな」が起きやすい。

文字起こしした原稿をもとに、まずはClaude系で提案書の初稿を作る。

その後で、CopilotやGeminiに社内規定を踏まえて修正させる。この二段構えがかなり強いです。

いきなり社内向け完成版を作ろうとするより、まず「規定なしの生原稿」をAIに整えてもらい、その後で社内ルールに合わせるほうが精度が高いです。

個人的には、最初のAIと、社内資料を読めるAIは役割を分けたほうがいいと思っています。

一つのモデルに全部背負わせるより、草稿担当と制度対応担当に分けたほうが、結果的に迷いが減ります。


要件定義と設計は、ソロなら分けすぎないほうがいい

本来は「何を作るか」と「どう作るか」は別です。

でも、実装者が実質ひとりなら、そこを厳密に分けすぎると逆に遅くなります。

だから要件定義書兼設計書として、並行で育てる進め方がかなり現実的です。

提案書をベースに追加で語る。全文文字起こしする。AIで初稿化する。そこから社内規定対応版に寄せる。この流れを繰り返すだけです。

ここで効くのは、AIが文章を書いてくれること以上に、論点の抜け漏れを拾ってくれることです。

インフラ設計、利用クラウド、申請の流れ、レビューの通し方、成果物チェック。人間だと地味に漏れるところを拾いやすい。

しかも今は、5年くらいの実務経験でも、AIを併用しながら爆速でキャッチアップできるケースが出てきています。

もちろん基礎力は要ります。でも「経験年数が足りないから無理」と決めつける時代でもなくなってきました。


実装手順書やCI/CD方針こそ、先に言語化しておいたほうがラク

実装に入る前に、実装手順書、テスト方針、CI/CD方針まで作る。

これを聞くと面倒に見えますが、正直ここを先に作ったほうが後がラクです。

なぜかというと、AIエージェントに開発させるなら、人間が読むための設計書だけでは足りないからです。

AIが迷わず動けるように、手順、ルール、禁止事項、レビュー観点まで先に固定しておく必要がある。

つまり今の開発は、コードを書く前に「AIが走れるレール」を引く仕事が増えています。

このレールがあると、 Code、Cursor、Codexのようなツールをかなり安定して使えるようになります。

AI駆動開発は、単なる自動コーディングではなく、AIが迷わないように工程そのものを構造化する作業だと思ったほうがしっくりきます。


進捗管理までAI前提で設計すると、一人開発の景色が変わる

もう一つ大きいのが進捗管理です。

progress.md で頑張る方法もありますが、レビューや見える化まで考えると、Jira、Backlog、Linearみたいな専用ツールを使ったほうがいいです。

最低限持たせる項目は、タスク名、エピック、優先度、期限、フェーズ、ステータス、詳細。

ここまで揃っていれば、AIにタスク洗い出しをさせてCSVやMDで出させ、そのままAPIやCLIで流し込めます。

これ、地味に見えてかなり効きます。

要件定義書と設計書からタスクを起こし、実装と連動させ、GitHub ActionsやJira連携で状態を動かす。ここまで繋がると、ひとりでも100〜300人月級の案件を分割統治しやすくなる

もちろん本当に一人で全部やるのは大変です。

でも昔の「大型案件は人数がいないと無理」という前提は、かなり崩れてきたと思います。


AI駆動開発で一番大事なのは、魔法を信じすぎないこと

AIがすごいのは事実です。

でも、何もない状態から突然うまくいくわけではありません。

必要なのは、語る、文字起こしする、叩き台を作る、規定に合わせる、レビューで直す、タスクに落とす、進捗を回す。

この地味な流れを、AIが扱いやすい形に整えることです。

個人的には、ここができる人ほど、今後のAI駆動開発で強いです。

逆に、いきなりコード生成だけに飛びつくと、後から設計や運用で苦しくなる。

AI駆動開発は、エンジニアを不要にする話ではありません。

むしろ、設計力、言語化力、レビュー力、進め方のうまさが、前よりずっと露骨に効くようになった感じがあります。

ソロでも大型案件を攻略できる時代は、たしかに近づいています。

ただし条件は一つで、AIに丸投げすることではなく、AIが走れる開発工程を人間が先に作ること。ここが分かれ目だと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?