AIと会員サイトをつくり始めたら、１２３件のテスト仕様書ができた件
――何人もの専門家が行うレビューを、AIとの対話で繰り返した「Power Pagesへの挑戦」
この記事の要点
私はいま、Digital Supporters Clubという会員制クラブサイトをつくっています。
最初の挑戦として、 Microsoft Power Pages、Dataverse、Power Automateを使った 会員サイトの設計に取り組みました。
そこで最も驚いたのは、 AIがコードを書けることではありませんでした。
本来なら、要件、データベース、画面、セキュリティ、運用、テストなど、 それぞれの専門家が行うレビューを、 AIとの対話の中で何度も繰り返せたことです。
一つの問題が見つかる。 前の設計へ戻る。 修正すると別の設計との矛盾が見つかる。 また戻る。
そんな往復を何十回も繰り返した結果、 要件定義書から始まった設計は、 最終的に１２３件のテストケースを持つMVPテスト仕様書まで育ちました。
そして現在は、Power Pagesにこだわらず、 SharePointを中心に、もっと小さなクラブサイトから始める方向へ進んでいます。
この記事は完成したサイトの紹介ではありません。 AIと一緒にクラブサイトをつくっていく、その第１章の記録です。
- AIは「作る人」だけでなく、「レビューする人」にもなれる
- 後工程から前工程へ何度でも戻れることが、仕様を強くする
- 仕様書は「作るため」だけでなく、「作るべきか」を判断するためにも役立つ
- Power Pagesへの挑戦は終わりではなく、SharePointで始めるための第１章だった
今回の経験を通して感じたのは、 AIが変えるのは単なる「作業時間」ではなく、 考え直し、レビューし、設計をやり直すコストそのものなのかもしれない ということです。
１．いちばん驚いたのは、AIがコードを書いたことではなかった
今回、AIを使って会員サイトの設計をしていて、 いちばん驚いたことがあります。
AIが文章を書けることでもありません。
プログラムを書けることでもありません。
システム開発では、さまざまな役割の人が関わります。
- ビジネスの要件を整理する人
- データベースを設計する人
- 画面や操作の流れを考える人
- セキュリティや権限を考える人
- 自動処理を設計する人
- 運用ルールを考える人
- 最後にテストする人
それぞれが、自分の専門分野から設計を見ます。
「この場合はどうなるのか」
「この設計は、前に決めた要件と矛盾していないか」
「他の会員のデータが見えてしまうことはないか」
「途中で処理に失敗したらどうするのか」
そうやってレビューしながら、一つのシステムをつくっていきます。
今回、それに近いことが、 私一人とAIとの対話の中で起きました。
もちろん、AIがすべてを決めてくれたわけではありません。
↓
私が考える
↓
方針を決める
↓
設計書へ反映する
↓
別の設計との矛盾が見つかる
↓
また考える
この往復を、何十回も繰り返しました。
そして、そこから今回のクラブサイト開発が始まりました。
２．つくりたいのは、「また書きたくなる場所」
私はいま、 Digital Supporters Club という会員制クラブサイトをつくろうとしています。
目指しているのは、 SNSのように人気を競う場所ではありません。
小説。
エッセイ。
自分史。
思い出。
体験。
空想の物語。
「自分も何か書いてみたい」
そう思った人が、 自分のペースで少しずつ言葉を形にしていく場所です。
↓
保存する
↓
また続きを書く
↓
希望すればクラブの仲間に読んでもらう
↓
短い感想が届く
↓
また書く
誰かに評価してもらうためではありません。
「誰かが読んでくれた」
「言葉を届けてくれた」
という小さな体験が、また書く力になる。
そんな場所をつくりたいと思いました。
最初の技術基盤として選んだのが、 Microsoft Power Platformでした。
- Power Pagesで会員サイトをつくる
- Dataverseに会員や作品のデータを保存する
- Power Automateで公開処理などを動かす
企業システムにも使われる仕組みなら、 会員ごとのアクセス権や非公開作品の保護もしっかり設計できるだろう。
そう考えました。
３．最初にAIへ伝えたのは、たった一つのイメージだった
最初から細かな仕様があったわけではありません。
AIエージェントに伝えたのは、 おおよそ次のようなことでした。
そこから、要件定義を始めました。
ところが対話を始めてみると、 一見簡単そうな言葉の中に、 たくさんの決め事が隠れていることに気づきました。
たとえば、 「公開する」 という言葉です。
４．「公開する」とは、どういうことなのか
「作品を公開できるようにしたい」
最初は、それだけでした。
でも設計するためには、それだけでは足りません。
公開とは、インターネット全体への公開なのか。
クラブ会員だけへの公開なのか。
作品を書いて「保存する」を押したら公開されるのか。
作者が明示的に 「クラブ会員に公開する」 と押した場合だけなのか。
一度公開した作品を作者が書き直している途中で、 その書きかけまで他の会員に見えるのか。
公開をやめたら、 それまでに届いた感想はどうなるのか。
削除するのか。
残すのか。
残すなら、誰が読めるのか。
一つ答えると、次の問いが出てきます。
そこで、 保存することと、公開することは完全に分けよう と決めました。
↓
保存する
↓
ここまでは本人だけ
本人が「クラブ会員に公開する」を選ぶ
↓
初めて公開処理を行う
書いて保存しただけでは、他の人には見えない。
初期状態は必ず「自分だけ」。
さらに、本人が執筆している原稿そのものを 他の会員へ直接開放するのではなく、 公開用の別データへコピーすることにしました。
そうすれば、公開後に作者が原稿を書き直している途中でも、 その書きかけが勝手に公開されることはありません。
５．完成したのは、サイトではなかった
こうして設計を進めているうちに、 当初は意識していなかった別の成果が、少しずつ形になっていきました。
まだPower Pagesの会員サイトは完成していません。
ところが、設計書は次々と出来上がっていきました。
- 要件定義書
- Dataverse データ設計書
- Power Pages MVP 画面設計書
- Power Pages テーブル権限設計書
- Power Automate 公開処理設計書
- Phase 1 運用ルール
- MVP テスト仕様書
しかも、これらは一度書いて終わりではありません。
v1.0。
v1.1。
v1.2。
Dataverseのデータ設計は、 さらにv1.5まで進みました。
後工程で問題を見つけるたびに、 前の設計へ戻って直していったからです。
６．画面を考えたら、要件の穴が見つかった
特に印象に残っているのが、 「感想」 の扱いです。
作品を読んだクラブ会員は、 作者へ短い感想を届けることができます。
ただし、誹謗中傷や個人情報の書き込みなど、 不適切な感想については、 運営が非表示にできるようにする。
ここまでは簡単でした。
ところが実際の画面の流れを一つずつ考えていたとき、 妙なことに気づきました。
感想が非表示になると、 その感想を書いた本人が、 通常の画面から自分の投稿へたどり着けなくなる可能性があります。
では後から、
「自分が書いた感想を削除したい」
と思ったら、どうするのでしょう。
最初の要件定義には、答えがありませんでした。
画面の小さな問題に見えました。
しかし実際には、
↓
どの状態の
↓
どのデータを
↓
読めるのか
という、アクセス権そのものの問題でした。
公開中の感想。
作品の公開をやめた後の感想。
運営によって非表示にされた感想。
それらを同じ権限で扱ってよいのか。
ここから、
- 要件
- Dataverseのデータ構造
- Power Pagesのアクセス権
- Power Automateの処理
- 運用ルール
まで見直すことになりました。
最終的には、公開中の感想と、 作者だけが読める状態になった感想とで、 アクセス経路そのものを分ける設計へ進みました。
しかし、すべてをシステム化したわけではありません。
非表示後など、 投稿者本人が通常画面から感想に到達できない場合の削除については、 Phase 1では専用機能をつくらず、 運営への個別依頼で対応することにしました。
システムで解決するもの。
人が運用で受けるもの。
その境界を決めることも、 設計なのだと思います。
７．たった一つの項目が、セキュリティの問題になった
もう一つ印象に残っているのが、 作品の「公開状態」でした。
作品には、
- 自分だけ
- クラブ会員に公開
という状態があります。
一見すると、会員が画面からこの二つを選択できればよさそうです。
ところが、自動処理の設計を進めている途中で疑問が出ました。
もし会員が、この公開状態を直接変更できたらどうなるのか。
本来は、
↓
公開する本文を取得する
↓
公開用データを作成する
↓
処理が成功したことを確認する
↓
公開中にする
という順番です。
ところが「公開中」という管理項目だけを直接書き換えられれば、 この処理を飛び越えられる可能性があります。
そこで公開状態は、 会員が自由に変更する項目ではなく、 システムが管理する項目 に変わりました。
さらに、 「画面から項目を隠せばいい」 という話でもありませんでした。
URLを直接指定したらどうなるのか。
他人の作品のIDが分かったらどうなるのか。
内部の管理項目を書き換えようとしたらどうなるのか。
この小さな疑問も、 最後には正式なセキュリティテストになっていきました。
８．１２３件のテストケースまでつながった
最終的に作成したMVPテスト仕様書には、 １２３件のテストケース が並びました。
たとえば、
- １８歳の誕生日当日なら申し込めるか
- １８歳の誕生日前日なら拒否されるか
- 他人の非公開作品を取得できないか
- 保存しただけでは公開されないか
- 公開中の原稿を書き直しても公開版が勝手に変わらないか
- 公開を停止した作品が「みんなの作品」から消えるか
- 公開停止後の感想を他の会員が取得できないか
- 非表示にした感想をGUIDやURLの直接指定で取得できないか
- 利用停止になった会員のアクセス権が外れるか
といった項目です。
そして最後には、 Digital Supporters Clubで本当に実現したかった体験そのものを 確認するテストまで入っています。
↓
保存する
↓
続きを書く
↓
公開する
↓
誰かが読む
↓
感想が届く
↓
また書く
最初は、
「作品を書いて、公開して、感想をもらえるサイトをつくりたい」
という一文でした。
９．AIが変えたのは、「考え直すコスト」だった
今回の経験で、 私が最も大きいと感じたのはここです。
人間のチームで、
「やっぱり要件定義まで戻りましょう」
と言うのは、簡単ではありません。
- 担当者に説明する
- 会議を設定する
- 設計書を修正する
- 別の担当者がレビューする
- 影響範囲を調べる
- 場合によっては、すでにつくったものまで変更する
つまり、設計の手直しには、それなりのコストがかかります。
ところがAIとの対話では、
「待って。この場合はどうなる？」
と思ったところから、 すぐに前の工程へ戻ることができます。
↓
データ設計を直す
↓
権限設計を直す
↓
自動処理を直す
↓
画面を直す
↓
運用を直す
↓
テスト項目へ落とす
これを何度でも繰り返せます。
もちろん、AIが常に正しいわけではありません。
複数のAIモデルをつかうと、AI同士の提案が違うこともあります。
最終的に、
「このサービスでは、どうするのか」
を決めるのは人間です。
レビューする。
前へ戻る。
もう一度確かめる。
このコストが大きく下がった。
私はここに、 AIによって変わるシステム開発の大きな可能性を感じました。
１０．そして、ライセンス費用という現実がやってきた
かなり設計が進み、 「いよいよ実装へ」 という段階まで来ました。
そこで、別の問題が見えてきました。
ライセンス費用です。
Power Platformを使って、 外部の会員向けサービスを本格運用する場合、 当初考えていた以上の費用が必要になることが分かりました。
技術的には、つくれそうです。
設計も、かなり進みました。
まだ始まったばかりのクラブです。
最初から大きな仕組みを持つ必要はありません。
そこで、Power Pagesでそのまま実装することにはこだわらず、 いったん方向を変えることにしました。
現在は、手元で利用できる SharePointを中心に、もっと小さなクラブサイトから始める 方向へ進んでいます。
１１．Power Pagesへの挑戦は、無駄だったのか
では、ここまで作った設計書は無駄だったのでしょうか。
私は、まったく逆だと思っています。
もし最初から画面をつくり始めていたら、
- 非公開とは何か
- 公開とは何か
- 誰が、何を見ることができるのか
- 公開を停止した後の感想をどうするのか
- どこまでシステムで行い、どこから人が運用するのか
といった問題を、 実装しながら考えることになっていたでしょう。
今回はPower Pagesへの挑戦を通して、 それらを先に考えることができました。
そして費用まで含めて、
「この仕組みを今、本当に採用するべきか」
を判断できました。
そのシステムを、本当につくるべきなのかを 考えるためのものでもある。
Power Pagesで作った設計書は、 Power Pagesだけのためのものではありません。
Digital Supporters Clubで、
- 何を大切にするのか
- 何を守るのか
- 何を会員本人に決めてもらうのか
- どこまで自動化するのか
その考え方の土台になりました。
だから、Power Pagesへの挑戦は、
「作れなかったサイトの記録」
ではありません。
今は、そう考えています。
１２．第２章は、SharePointから始まる
クラブサイトは、まだ完成していません。
だから、この開発記録もまだ終わりません。
次はSharePointを中心に、 まずはもっと小さく動くものをつくります。
↓
使う
↓
気づく
↓
改善する
最初から１００点のシステムをつくるのではなく、 まず動くものをつくり、 実際に使ってみる。
そこで、本当に必要なものを見つけていく。
Power Pagesで考えたことのすべてを、 そのままSharePointへ持っていく必要はありません。
むしろ、
「これは本当にMVPに必要なのか」
と、もう一度考えられます。
ただし、
- 会員本人の作品を守る
- 公開は本人の意思で行う
- 保存と公開を混同しない
- 人とのつながりを競争にしない
- コミュニティは「また書く」ために使う
といった基本的な考え方は変わりません。
１３．AIと人間の役割は、少しずつ変わっていく
今回のPower Pagesへの挑戦を振り返ると、 AIとの関係についても、 一つ見えてきたことがあります。
AIに、
「仕様書を書いてください」
と頼めば、 それらしい文書をつくることはできます。
でも、それだけでは今回のような設計にはなりませんでした。
実際に起きていたのは、
↓
AIが設計案を出す
↓
別の視点からレビューする
↓
問題が見つかる
↓
人間が判断する
↓
仕様を更新する
↓
別の設計との整合性を確認する
↓
また問題が見つかる
という繰り返しでした。
AIは、先生でもありません。
最終決定者でもありません。
これまで仕様書を書く仕事は、 複数の専門性を持つ人たちの協働によって成り立ってきました。
もちろん、 大規模なシステム開発で専門家が必要なくなるとは思いません。
セキュリティ、法務、インフラ、運用など、 人間の専門家による確認が重要な領域は残ります。
それでも、小さなプロジェクトの最初の段階で、
一人の人間がアイデアを持ち、 AIと何度も対話し、 要件を考え、 データを考え、 画面を考え、 権限を考え、 運用を考え、 最後にはテストまで考える。
そこまで進めることができる。
これは、少し前なら考えにくかったことだと思います。
AIが安くしたのは、 単にプログラムを書くコストではありませんでした。
と言えるコストが、 大きく下がった。
Digital Supporters Clubのクラブサイトづくりは、 まだ途中です。
Power Pagesへの挑戦が第１章。
次はSharePointで、 実際に動く小さなクラブサイトをつくります。
そこで何ができるのか。
何につまずくのか。
そして、AIとの開発が次にどう変わっていくのか。
その過程も、 引き続き書き残していこうと思っています。