アプリ開発はコードを書く前に勝負がつく｜修正コスト100倍を防ぐ3つの準備

Claude CodeやCodexのようなAIエージェントのおかげで、プログラミングの知識がなくてもアプリや業務ツールを作れるようになりました。

ただ、アプリ開発の勝負は、実はコードを書く前についています。リリース後にバグを直すコストは、コードを書く前の100倍にもなるからです。

この記事では、その修正コストを防ぐためにコードを書く前にやっておく3つの準備を、AIへの依頼文つきで解説します。

動画で見たい方はこちら。

リリース後のバグ修正コストは、コードを書く前の100倍

ソフトウェア開発の実証データをまとめた2001年の論文によると、リリース後に問題を見つけて直すコストは、要件定義・設計段階で直す場合の100倍にもなることが多いと報告されています。

この100倍は大規模なシステムでの値です。小規模で重要度の低いシステムなら5倍程度ですが、それでも同じ修正に5倍のコストを払うのは大きな差です。

AIでアプリ開発が高速になった今も、この前提は変わりません。むしろ、AIでコードを大量に書けるようになった分、リリース後のバグ修正コストも増大しています。

ここからは、ITエンジニア歴10年の私が、コードを書き始める前に必ずやっている3つの準備を紹介します。

準備1：要件定義書をMVPで必要最低限に絞る

最初に作るのは要件定義書、つまりこのアプリで何をやるのかを明確に書いたドキュメントです。

例えば予約管理アプリなら、予約さえできればよいのか。それとも、後から予約の変更やキャンセル、直前のリマインドまでやりたいのか。こうしたやりたいことを、要件定義書で明確にします。

全部盛りの要件は「本当に必要か」を確かめられない

要件定義書を作るときに重要なのが、アプリでやることを必要最低限に絞ることです。やりたいことを大量に盛り込んでも、ユーザーがその機能を本当に必要としているかは分からないからです。

それよりも、必要最低限の機能で素早くリリースし、ユーザーの要望に応じて機能追加や改善を重ねる方が、早く実際に役立つアプリを作れます。

AIには「MVPとしての要件定義書を作成して」と頼む

この必要最低限の機能だけを備えた製品を、MVP（Minimum Viable Product、実用最小限の製品）と言います。

AIに要件定義書を頼むときも、このMVPという言葉が効きます。次のように依頼してみてください。

〇〇するアプリのMVPとしての要件定義書を作成して

「MVPとして」と伝えるだけで、AIは要件定義書に入れる機能を必要最低限に絞り込んでくれます。

準備2：要件定義書をもとに技術選定する

MVPの要件定義ができたら、次は技術選定です。アプリでやりたいことに応じて、例えば次のようなことを決めていきます。

• プログラミング言語
• ライブラリ（よく使う機能をまとめた部品集）
• データベース（データを保管・整理する仕組み）
• 本番リリース先（完成したアプリを公開する場所）

技術選定も、AIに任せられます。準備1で作った要件定義書がある前提で、次のように頼みましょう。

要件定義書をもとに技術選定をして

要件定義書をもとに技術選定をさせれば、AIが適切なものを選んでくれます。

準備3：Hello Worldの1画面で、本番公開までの流れを作り切る

使う技術が決まったら、その技術でHello Worldという一文だけを表示する画面を作り、本番公開までやってしまいます。

Hello Worldとは、アプリを一番最初に動かすときに使われるひな形のようなものです。正直、最初の画面に表示する文言は「お試し」でも「テスト」でも何でもかまいません。

大事なのは、機能を作り込む前に、本番公開までの流れを作り切ってしまうことです。

リンター・フォーマッター・自動テスト・本番自動公開を最初に整える

流れ作りでは、画面だけでなく、アプリの品質を守る次の仕組みもあわせて整えます。

• コードの品質や書き方を自動で検査するリンター・フォーマッター
• GitHub Actionsで、アプリを変更するたびに自動テストが走る仕組み
• 修正内容をGitの本番ブランチへ反映すると、自動で本番公開されるパイプライン

土台作りも、まとめてAIに任せられます。技術選定まで終えたら、次のように頼んでください。

Hello Worldを表示する1画面だけのアプリを作り、本番公開まで整えて。リンター・フォーマッターと、GitHub Actionsでの自動テスト・本番自動公開も設定して

後回しにすると「手元では動くのに本番で動かない」が起きる

土台作りを後回しにすると、機能を追加するたびにコードが複雑化して、メンテナンスしづらくなります。

そして、手元では全ての機能が動いていたのに、いざ本番公開したら全く動かない。こうした問題が起きてから直そうとすると、膨大なコストがかかります。

使い捨てのツールなら、この準備は省いていい

この3つの準備は、これから使い続けるアプリのためのものです。一度きりの使い捨てスクリプトや、動くかどうかを確かめるだけの試作なら、準備を省いて素早く作ってかまいません。

逆に、業務で使い続けるアプリなら、小規模でも修正コストは5倍ほどに膨らみます。長く使うものほど、コードを書く前の準備が運用コストを下げます。

まとめ：次のアプリは「MVPとしての要件定義書」から始める

この記事の要点は次の4つです。

• リリース後にバグを直すコストは、コードを書く前の100倍にもなる（小規模でも5倍程度）
• 準備1：要件定義書をMVP（実用最小限の製品）として、必要最低限の機能に絞って作る
• 準備2：要件定義書をもとに、プログラミング言語や本番リリース先などの技術選定をする
• 準備3：Hello Worldの1画面を作り、リンター・フォーマッターや自動テスト・本番自動公開まで流れを作り切る

あなたが次にアプリを作り始めるときは、まずAIへこう伝えてみてください。

〇〇するアプリのMVPとしての要件定義書を作成して

そのうえで技術選定と土台作りまで整えれば、リリース後に大量の問題へ追われることなく、効率的に開発を進められます。

ながら聞きでAI活用・業務改善に役立つポッドキャストをSpotifyでも配信中です。

現場のAI・業務改善ラジオSpotifyopen.spotify.com