オルタナティブ・ブログ > そろそろ脳内ビジネスの話をしようか >

「脳内ビジネス」の話はまたにします!

誰でもAIで開発ができる時代にプロならどう作るべきなのか

»

この記事は、フルで自分でキーボードを叩いて書いています。

もう、すっかり業務がAIに浸食されてしまってこういう機会もかなり減りましたね。

Slackなどの会話はともかく、お客さんへの提案書やらLPの文面やらメルマガ記事やらAmazonへのクレーム文書やら(例の件(AWSによる前代未聞の理不尽な対応)はまだ解決してません。ふざけてます。)は、たいていAIに書いてもらってます。

この先いったいどうなってしまうんでしょうかね。

もうこちらもAI先方もAIで、AI同士で商談を進めるような感じになってしまうのでしょうか。それは楽ですが、では人間の存在価値とは?という気もします。

若干の不安は感じつつも、とはいえ、鉄砲で戦争をする時代が始まっているというのに剣や弓で戦うわけにも行きません。。

私もAIを使って日々開発をしていますよ。

AIで誰でもアプリを作れる時代

昨今では、Claude Codeを使ったらアプリが簡単に作れた!みたいな投稿がXなどでもよく目にするようになりましたね。

はいはい、わかりますよ。できるでしょう。

しかし、なんて言うんですかね。そういうのは「3Dプリンターで拳銃が作れた!」みたいな話で実際に業務で使えるレベルではないと思います。

私もこの1年で4件くらいのシステム(ゲームを含む)を作ってきましたが、こと業務システムをAIで作ろうと思ったら、やはりDB設計やセキュリティ、インフラや決済などさまざまなバックグラウンドの知識やノウハウが必要です。

そうでなければAIが「どっちにしますか?」と聞いてきたところで決められません。というか、そもそもAIからその質問を引き出せません。

私が思うに、ちゃんと業務レベルで通用するシステムをAIで作ろうと思ったら、大事なのは開発の再現性挙動の担保性です。

つまり「AIにやらせてみたらこうなった」ではなく「こういう設計だから必然的にこうなった」であり、「どうしてこういう動きをしてるのかわからない」ではダメで「こういう仕様だからこうなっている」と説明できることが重要です。

それがないと安心して長期にわたって使用できるシステムとは言えないでしょう。

それを実現するにはどうしたらいいか。

プロンプトを工夫する?コードレビューをしっかりする?複数のAIで評価し合わせる?

どれも違うと思うのです。

AIで開発する上で大事なこと

大事なのは仕様書(ドキュメント)をAIにしっかり書かせるということです。

実はこれまでプラムザは仕様書というのは最低限度にすべきという方針でやってきました。

しかし、AI駆動開発ではそうではありません。これはもう1年やってきて確信した絶対的な結論ですね。

少々面倒でもAIに仕様書を書かせることが重要です。システム開発会社ならこの開発フローの転換ができるかどうかだと思います。

(従来の開発手法)

1.要件定義を行う

2.必要な仕様書(画面設計書やDB定義書)を書く

3.仕様書に沿って画面を作る

4.仕様書に沿って実装する

5.仕様書に沿ってテストする

こんな感じでした。そしてこの仕様書がかなり緩かったです。間違いも更新漏れもあって、人間が行間を埋めないといけませんでした。

それが

(AI駆動の開発手法)

1.AIに要件を伝える

2.AIに必要な仕様書を書いてもらう

3.人間(PMやSEや顧客担当者)が確認する

4.仕様書に沿って画面生成を行う

5.それを人間が確認する

6.微修正が入れば仕様書に戻す

7,仕様書に沿って実装を行う

8.それを人間が確認する

9.微修正が入れば仕様書に戻す

10.仕様書に沿ってテストする

11.結果を仕様書に戻す

12.それを人間が確認する

こんな感じでやるべきと思います。すべての業務を仕様書起点にします。

本来人間が開発していた時もこうやればよかったのですが、こんなことをやっていたら工数が10倍くらいかかるので現実的ではありませんでした。

しかし、今。AI駆動で開発できるようになって、コーディングも劇的に早くなりましたが、同時に仕様書を書くのも早くなりました。

何十もある仕様書について「今やった仕様変更で影響する仕様書をすべて洗い出して修正して」と言うとすべて直してくれます。コーディングもさることながら私的にはこれが革命的でしたね。

こうやって開発中に行った実装をすべて残しておけば、このシステムで考慮されていること、考慮されていないことが明確になりますし、不具合が発覚した時、それが考慮漏れによるものなのか、コーディングの誤りなのかがはっきりします。

そうでなければ、システムの運用開始後に「こういう不具合が出てるから直して」と言ったら、AIは意図的にそうしてある部分も直してしまうでしょう。これは本当に恐ろしいことです。(AI開発を始めた初期に、何度もやられて痛い目に遭いました)

仕様書に意図も含めてすべて残してあるから人間もAIも安心してソースを触れるのです。

こういう考え方を最近「(AIによる)仕様駆動開発」と言うようですね。これは昔のウォーターフォール時代の「仕様書ファーストな開発(コーディングファーストの逆)」とはまったく異なる次元の話です。

AIに書かせたたらかえって開発が遅くなった?

あと、もう一つ言いたいのは、AIによって開発をするなら「コードレビューは行わない」ということです。

開発中にAIがどこを触っているかというのは見ますよ。指示した内容とまったく関係ないところを触っていたら「待て待てーい!」と言いますが、そうでなければ、基本的にスルーです。

世の中には「AI開発をしたら実装は早くなったがコードレビューは倍の時間がかかって結局効率化にならなかった」みたいな記事が散見されますが、コードレビューなんかしてるからダメなんですよ。

人間がチェックするのは先に述べた仕様書だけです。その先はAIの責任範囲です。

そうしないと、鉄砲の戦さにならず、鉄砲で相手を殴るような戦いになりますよ、という話です。

=====
さて能書きばかりをつらつらと書いてきましたが、以下が私がお正月休みから空き時間を使って開発してきたシステムです。

サービスの概要

Backlog Effort Tree -Backlogに、コスト判断をプラスする-
https://service.effort-tree.com/

デモ用アカウントも作りました。

データの書き込みはできませんが、プロジェクト分析やレポートの雰囲気はわかっていただけると思います。
https://app.effort-tree.com/login
(sample@example.com/demo2026)

私は、もう何十年もコードを書いていないのですがAIだけでここまでできるのは正直自分でやっててかなりの衝撃でした。

このシステムの詳細については、また別の記事にします。

Comment(0)