00:00
AIで作るアプリが思い通りにならないのは、要件定義をしていないことが原因です。
PRを13本に分けて開発していく流れになっています。
AIはアプリを実装するタイミングで、提案機能も含めてしまうかもしれません。
こんにちは、超実践AI論のたいちです。
今回は、AIで作ったアプリが、「思ってたのと違う」を防ぐ要件定義実演というテーマでお話しします。
AIでアプリを作ったときに、何か思ってたのと違う、使いづらい、見た目がいまいち、といったことはないでしょうか?
AIで作るアプリが思い通りにならないのは、要件定義をしていないことが原因です。
要件定義とは、誰のどんな課題をどう解決するアプリかを決めることです。
例えば、タスク管理アプリを作るとき、そのアプリを使うのが会社員なのか、主婦なのか、学生なのかによって、
アプリで必要な機能も見た目もかなり異なるはずです。
会社員だったら、Googleカレンダーとの連携機能が必要だったり、
学生だったら、学生ポータルからのデータ取得機能が便利かもしれません。
このように、アプリは誰が使うのか、そしてどんな課題を解決するのかによって、
求められる機能が大幅に変わります。
アプリで、誰が何をどうしたいのかを決めるのが要件定義です。
要件には、機能要件と非機能要件があります。
機能要件では、その名の通り、利用者の課題をどんな機能で解決するかを決めます。
例えば、タスク管理アプリだったら、タスクの一覧表示、検索、編集、削除はできた方が良さそうです。
こういったアプリに必要な機能を定義するのが機能要件です。
一方で、非機能要件とは、アプリの機能とは直接関係ない品質に関する要件です。
具体的には、アプリは同時にどれくらいのアクセスに頼る必要があるのか、
タスクの検索結果は何秒以内に表示する必要があるのか、
アプリは24時間365日使える必要があるのか、といったことが非機能要件にあたります。
アプリを作るときは、まず最初に、今話した機能要件と非機能要件をまとめた要件定義書という資料を作ります。
要件定義書でAIと認識を合わせておけば、いざAIがアプリを完成させたときに、
思っていたのと全然違うとなることはありません。
今回は、現役エンジニアの僕が、実際にこれから実務で使うアプリの要件定義をクロードコードでやるところをお見せします。
では早速、アプリのGitHubリポジトリから作成します。
僕はGitリポジトリを作成するスクリプトを組んでいるので、それを使います。
Gitリポジトリの名前はContentsDBにします。
Gitリポジトリにはアプリ名を表すシンプルな命名をします。
このリポジトリ名はアプリをリリースするプロジェクト名やフォルダの名前など、いろんなところで使うので適切なものを設定しましょう。
僕は今回、YouTubeやSNS、ウェブサイトなどの各分析データを一元管理するアプリを作りたいので、ContentsDBと名付けました。
やっぱりContentsDBだと微妙なので、Contents Analytics DBにします。
03:05
Gitリポジトリができたので、早速クロードコードでアプリの要件定義を進めます。
まずはクロードコードで先ほど作ったGitリポジトリのフォルダを開きます。
そしてモデルはFable 5.1にして、趣向レベルはこうにします。
要件定義はアプリの完成度を決めるかなり重要で難しい作業なので、使うAIモデルはなるべく賢いものがいいです。
僕は利用枠がかなり余っているのでFable 5.1を使いますが、Opus 5.5でも十分だと思います。
そして要件定義にはGrillWithDocsというスキルを使います。
GrillWithDocsはアプリの要件定義など、まだ内容が明確になっていない作業でやりたいことを伝えると、
AIが必要な情報をすべて一問一答で質問してきて、やることを明確化してくれるスキルです。
GrillWithDocsは海外の有名エンジニアのMatt Poxさんが公開しているスキルで、エンジニアの実務でもよく使われています。
インストール方法は簡単で、このMatt PoxさんのスキルのGitHubページで、
AIエージェントに応じたインストール方法が記載されています。
例えばクロードコードなら、このコマンドをコピーしてターミナルに貼り付けるだけです。
CodeXやGitHubコパイロットへの入れ方も書いてあります。
早速、GrillWithDocsに続いて、僕が作りたいアプリの内容を追記します。
最近のAIは賢いので、内容が整理されていなくても、情報が足りなくても向こうから必要なことは聞いてきてくれます。
ですが、今時点で決まっていることは、なるべく伝えておく方が、
AIとのやり取りの手間が減るので、なるべく最初に書くようにしています。
今回作るアプリの要件は、YouTubeとクラウドフレアのウェブサイトのデータを一元管理するアプリです。
そのデータを、人が見やすいUIやAIエージェントも使いやすい形で保管して、
AIからのアドバイスやコンテンツの改善にも役立てたいと思っています。
そして、各媒体の分析データは、1日1回自動取得することを想定しています。
アプリを置く場所はクラウドフレアの予定です。
クラウドフレアはコストが安く、かつAIエージェントも使いやすいからです。
そしてここに出てくるMVPとは、ミニマムビアブルプロダクト、実用最小限の製品という意味です。
つまりMVPとは、課題を解決するために最も重要な機能だけを備えたアプリを意味します。
アプリを作るときに最初からたくさんの機能を盛り込んでも、
作るのが大変になったり、ほとんど使わない機能が出てきたりと、無駄が多いです。
それよりもMVPとして本当に必要な機能だけを作り、使いながら改善を繰り返していく方がより良いアプリを作ることができます。
なので、AIにアプリの要件定義書を作らせるときは、必ずこのMVPという言葉を入れて、本当に必要な機能だけに絞り込むようにしています。
指示は決まったので、早速この内容でクラウドに投げてみます。
1分ほど経って、早速クラウドが最初の質問群を出してきました。
質問にはこのように選択肢が用意されていて、AIがどの答えを推奨しているのかも書いてあります。
06:05
なので、質問に回答するときはこのように、推奨回答と自分の答えが違うものだけそれを書き、上記以外は推奨でOKと回答するのが楽です。
グリルイズドックスでは質問の答えに応じてAIが次の質問を考えてきます。
そうやってAI側の疑問点がなくなるまでひたすら質問に答えると、最後に明確化された内容をまとめてくれます。
僕の場合は最初に要件定義書を作成してという指示をしているので、AIの疑問がなくなったらドキュメントを自動で作成してくれます。
それではAIからの質問がなくなるまでひたすら答えていきます。
要件定義書が完了しました。
全部で33問の質問に15分ぐらいかけて答え続けました。
さっそく完成した要件定義書を見てみましょう。
要件定義書はRequirementsMDというドキュメントで作成されています。
このように要件定義書にはどういう目的で作るアプリなのか、利用者は誰なのか、
そしてアプリには何を含んで何を含まないのか、具体的にどんな時に使うのか、データをどこからどのように取得するのか、
ドメインモデルはどうなるのか。
ドメインモデルというのはアプリの中で概念をどのように構造化して整理するかというお話です。
例えばYouTubeチャンネルというモデルの中にビデオというモデルがあって、
そのビデオにはYouTube本編とショート動画という概念がある。
そしてその動画と記事が1対1でつながっていて、それらを日時で分析するといった感じです。
このようなドメインモデル図もGrill with Docsでは質問に答えていくだけで作ってくれます。
そして要件定義書にはテーブル定義も含まれます。
テーブル定義というのはデータベースでデータをどのように整理して保管するかというお話です。
例えばチャンネルズテーブルにはYouTubeのデータが入ったり、エピソードズテーブルには記事のデータが入ったりします。
そして各テーブルの中にはカラムという値の列が入っていて、
例えばチャンネルズテーブルにはYouTubeのタイトルや説明欄の文言などが想定されます。
そしてエピソードズテーブルにも記事のタイトルや記事の公開日、記事の内容などがカラムとして登録されると思います。
続いてどのくらいのデータ量になりそうなのか。
また先ほど話した機能要件でどんな機能を実現するかといった内容。
そして非機能要件でどのようなプログラミング言語やフレームワークを使うのか。
どこにデプロイするのか。
開発ツールはどんなものを使うのかといった内容が記載されます。
要件定義書以外にもグリルウィズドックスが作ってくれるドキュメントがあり、
一つはコンテキスト.mdです。
コンテキスト.mdではアプリ内で使われる用語を明確に定義します。
例えばこのアプリではYouTube本編から切り出した縦長の動画のことをショート動画と定義しています。
ショート動画ではなく縦動画や切り抜き動画といった表現も考えられますが、
このアプリではショート動画と明記しています。
09:01
このように、ある概念にはこの言葉を使うと明確に定義することで、
AIも人も迷いづらくなります。
もし用語を決めておかなかったら、あっちではショート動画と書かれ、
こっちでは切り抜き動画になり、また別の場所では縦動画と書かれていたりして、
だんだん使う用語がブレ、
最後には何がどれを指しているのかもわからなくなってしまいます。
用語がブレていると、プログラムは勘違いからバグを生みやすくなり、
ドキュメントも理解しづらくなります。
だからこそ、グリルウィズドックスでは、
このcontext.mdというドキュメントで、議論の中で決まった言葉は明確に定義されます。
そして、グリルウィズドックスが作ってくれるもう一つのドキュメント群がADRです。
ADRとはアーキテクチャーディシジョンレコード、
つまりアーキテクチャーの決定記録という意味です。
つまり、アプリの機能をなぜこうしたのかを決定する記録です。
例えば、このADRには、
今回のアプリは読み取り専用のデータ基盤だけに絞って、
データを基にどのような改善をするかの施策提案は、
外部AIエージェントに任せると書いてあります。
これはつまり、アプリはデータの管理だけを主になって、
データを見て改善提案をするのは、
クロードコードやコードXなどの外部のAIエージェントを使うという意味です。
提案機能もアプリの中に含めてしまうと、
その分実装量は多くなって、
しかもクロードコードやコードXなどが進化するたびに、
アプリ側も直さなければいけません。
このような面倒を避けるために、
提案機能は外部に任せるという意思決定をしています。
ADRにはこのように、
実装内容となぜその実装内容を選択したのかの理由を記載します。
ADRを残す理由は、ソースコードだけが残っていても、
なぜそのソースコードになっているのかは分からないためです。
もし仮にこのADRがなければ、
AIはアプリを実装するタイミングで提案機能も含めてしまうかもしれません。
ですが、このように提案機能を含めない理由まで書いてあれば、
AIがそれを無視してまで実装してくることはないと思います。
このようにアプリ開発では、
将来、なぜここがこうなっているんだという疑問に答えるために、
ADRを残しておくと便利です。
Grill with DocsではこのADR作成も自動でやってくれます。
これで要件定義関連のドキュメントは一通りできたので、
コミットしてプッシュしておきます。
そして次は、要件定義書にのっとって、
アプリを実装と行きたいところですが、
この分量を一気に実装させるとバグも起こりそうですし、
確認も大変です。
そこで、クロードコードに追加の作業を指示します。
作業内容は、今後の作業を
AIエージェントが対応しやすいPR単位でドキュメントにまとめて、です。
こうすることで、AIが作業しやすい適切な流度で
作業計画を分割してくれます。
計画が完了したようです。
PR分割のドキュメントがプラン.mdにまとまったようです。
ざっと見てみると、PRを13本に分けて開発していく流れになっています。
12:00
あとは、このドキュメントに沿って、
クロードコードにPR1番を対応してと言って対応してもらい、確認する。
次にPR2番を対応して確認する。
といった感じでアプリを作り上げていくことができます。
ここで一つお知らせです。
無料メルマガで、今回話したような実践的なAI活用法を配信しています。
1分ほどで登録できるので、概要欄のリンクから見てみてください。
ただ、実際のアプリ開発では、ブランチをどのように運用するのかや、
ソースコードのレビュー、セキュリティ周りの確認、
ソースコードの品質を担保するリンターやフォーマッター、CI、CDといった仕組みなどを整備していく必要があります。
なので、次回以降の動画では、エンジニアである僕が、
このアプリを作りながら、今話したようなアプリ開発周りの基盤を
どんな順番でどのように整えていくかも解説していきます。
まずはあなたも、今回の動画を参考に、
グリルウィズドックスを使って、自分が作りたいアプリの要件定義書を作成してみてください。
概要欄にも今回の内容を解説した記事を貼っておきます。
それでは今日はこの辺で。
