はじめに：生成AIと仕様書の役割
こんにちは、Zero Topicです。久しぶりの更新になります。 今日は日々、私が
Claude Codeを使って、いろんなものを書いたり作ったりしているんですけども、その中で新規事業とか新規のプロダクトを作るときに、
改めて仕様書みたいなものを書いたり、それをチームと共有して、実際に開発するものを決定していったりするプロセスを、
また直近、数多くやってまして、その中で仕様書の今、生成AIを使った開発プロセスの中で、どういうふうに仕上げていくかとか、
どういう役割で仕様書に価値を持たせていくかみたいなところを少し考えたり整理したので、そんな内容を話せればなというふうに思っています。
プロダクトマネジメントみたいなことを久しぶりにしたりしているので、これはこれでやっぱり楽しい仕事だなと思って、
その中に新しい生成AIを使った技術が入り込んでいくことで、今まで自分が慣れ親しんでたものとか使ってたものが、
さらに加速するような感覚はあって、すごく新鮮な気持ちで、今そういう業務に取り組んでいたりします。
まずそういった前置きを置いた上で、ちょっといきなり話の本筋に入るんですけども、
仕様書の3つの役割
仕様書の役割ってなんだっけみたいなところを、改めて自分の中でこう思ってますってところを話せればなと思っています。
仕様書って多分いろんな会社とかいろんなチームで作ったり運用されたりしているものだと思うんですけど、
結構その一義的にこれが仕様書であるっていう定義とか、こういうものだよねっていう認識ってないんじゃないかなっていうふうに思っています。
というのも、我々10Xっていう会社の中で事業をする中でいうと、自分たちのシステムともう一つ顧客の中に入っているシステムとの間で、
どういったインターフェースで連携するかっていうことを協議したり、そのインターフェースを開発したりする機会っていうのはすごく多いんですよね。
その中ですと、自分たちの用意した要件とか仕様みたいなものだけではなくて、当然その顧客の中にあるシステムを作ったり運用している会社、
多くの場合は大手のSIERのケースが多いんですが、そういった方々が出してこられる要件の定義書とか仕様書っていうものが、
結構全く別のもの、別の役割、別の視点で書かれていることが多くて、それが故にこういった気づきを得ています。
自分たち、あるいはまだ会社全体というよりは、自分の中ではこういうものだよなっていう役割の落としどころが3つぐらい整理できています。
一つは、明確にこの製品とか機能とかを開発するっていうときに、その開発に携わる人たちの作るものがどんな最終着地なのかっていうイメージを揃えるっていうのが
大きな役割の1個だと思っています。
2つ目が、実際に作られたものと、あるいは元々持っていたイメージ。
ここに返りが生まれたときに、この返りを埋めるもの、それは作るものを変えるのか、あるいは作ったものを変えるのか、
もしくは元々イメージしていたものの姿を変えるのかって2パターンあるんですけど、
その返りを埋めるっていうときの基準線というか、ここが元々いた場所ですよ、
次はこの場所に行きますよっていう、そのための基準になるものっていうのが2つ目の役割かなというふうに思っています。
3つ目は、実際に製品が運用されて使われ始めたときに、
使う人にとっての疑問として、このときってどうなるのっていう、そういう質問が来ることってあると思うんですよね。
これらに対して、ここはこういう挙動が正しいんですよっていう、
使う人にとっての正しい挙動は何かっていう、そのよりどこになるものが3つ目の役割という形です。
ちょっと1つ1つもう少し深掘りできればと思うんですが、
役割1：作るもののイメージを揃える
1つ目の作るものをイメージを揃えるっていうところなんですけど、
当然何かの製品とか機能とかを開発するときって、いろんな人が今は関わりますよね。
それこそソロプレーナーとか、自分も1人でいろんな自分用のツールとか、
最近は少年野球で使うシステム作ったりとか、
あとモバイルアプリで自分がトレーニング中に使うものを作ったりとか、
いろいろ楽しんでるんですけど、大きい製品とか機能を作ろうと思ったら、
やっぱり1人でできることって限界があって、
いかにチームでそれも役割とか得意なことの違う人たちが関わるかっていうのが、
結局すごい大事なポイントだと思っていますと。
そうすると違う人だし、得意なことも違うんで、視点が違うんですよね。
視点が違う人に、例えば1つの機能、ユーザーは何々ができるみたいな機能があったときに、
これを何で視点を揃えるかっていうのがめっちゃ重要だと思っています。
視点を揃える技術の仕方っていくらでもあって、
例えば一番原始的なのはコード上にこうやって書くっていう認識の揃え方もあるだろうし、
あるいは画面があって、画面上こういう振る舞いをするっていうイメージの揃え方もある。
何でもいいんですけど、一番大事なのって結局誰にとって振る舞いかっていうと、
利用者、ユーザーにとってどうこの仕組み、機能は振る舞うのか。
利用者はそれを使って何を解決したいんだっていう、
これが分かることが何より一番大事だと思うんですね。
なので、そういったことがちゃんと作るもののイメージとして記述されているってことが、
役割の一つ目にとってはすごく重要な要件なのかなって思っています。
システムとしてのさっきの振る舞いとか、コードのあり方とか、あるいはUIのあり方とか、
こういったものはユーザーにとっての振る舞いを定義する一部の情報ではあるので、
それが記述されていることも全然良いんですけれども、
こういったものって専門性のある領域なので、
思い切って預けちゃってもいいのかなっていうふうには個人的に思っています。
一人で全部自分でやるっていう人は、
使用者の中にそういったものも全部含めてってもいいかもしれないけれど、
それがチームの作るもののイメージを揃えるときに、
全員の共通認識を作るのに役立つわけではないんだったら、
思い切って外してしまうほうが、その先の専門家に任せられるって意味も込めて、
良いケースは多数あるのかなって思っています。
これが一つ目の話でした。
役割2：イメージとの乖離を埋める
二つ目なんですけど、
実際に作られたものとイメージの改良を埋めるっていうところで、
実際に仕様が書かれた後にものを作り出すと、
イメージと違う着地になることって絶対多いと思っています。
例えば、これ技術的にはこういうやり方ではなくて、
多少のトレードオフがある。
ユーザーの達成したいことに対して、
例えば毎時間情報が更新されるってのを諦めて、
3時間に1回にしたら、
もうちょっとこういう実装の方法でコストが抑えられるんで、
こうしませんかってこととか、すごくあると思うんですよね。
こういったトレードオフの結果、
違う着地になることって多いと思っています。
この返りって返りのまま放置すると、
めちゃくちゃ危険なんですよね。
それは次に話す、
ユーザーにとっての正しい挙動を示さなくなってしまうから。
なので、この返りを返りとして放置せずに、
ちゃんと埋めるってのが必要で、
今の場合ですと、
仕様を変えるっていうことが重要になります。
なので、そのときはその仕様書をちゃんとメンテナンスして
変わっていくっていうことを、
担保する必要があるかなと思っています。
役割3：正しい挙動の拠り所
3つ目、ユーザーにとっての正しい挙動の
よりどこになっていくってところなんですけど、
CIが入ってきたおかげで、
ソースコードの中からこの内容を読んで、
こういう挙動をするはずですって記述するっていう
ハードルってめちゃくちゃ下がっていて、
例えばDevinっていうツールを使うと、
スラック上で誰でも、
例えば我々のStaylerっていう製品だったら、
このStaylerのこの仕様の挙動を教えてって聞くと、
Devinがソースコードを読んで、
回答を返してくれたりするんですよね。
なんですけど、
CCIって所詮やっぱ推論機なので、
どれだけ正しい情報を読んだとしても、
そこから出てくるアウトプットって、
確率論的にやっぱ間違いが含まれる。
あくまで推論の結果になるっていう形になってますと。
だからこれを使って、
例えばユーザー、顧客にいただいた質問に対する回答は、
Xっぽいですっていう回答ができたとしても、
Xですとは言い切れないんですよね。
それが結構注意が必要なポイントだと思っていて、
このXですって言い切るためには、
結局何が必要かっていうと、
使用書、あるいは使用を正しく記述されたもの、
っていうものが、
このコストを埋める役割を担い続けるかなと思っています。
ので、トータルこの3つ、
作る前の話と、
作ってる最中に起きる話と、
作ったものを使うフェーズで起きる話、
この3つのユースケースを満たすものが、
使用書の役割というか、
価値なんかなっていうふうに思っています。
生成AIによる仕様書作成の活用法
もう1つ、クロードコードとか、
いろんな生成AIを使うようになって、
この使用書を作ったり運用したりする中で、
どこに使えるかなっていうのを、
自分も模索しているんですけど、
結構使えます。
結論結構使えるなと思っていて、
例えばイメージを揃えるっていう1つ目のフェーズだと、
視点を増やすのに使えるなっていうふうに思っています。
新しい機能とかプロダクトを作るときに、
結局どうやって共通のイメージを湧かせられるかっていうのが、
1個のキーポイントなんですけども、
自分と違う立場の人たちがどういう記述が欲しいかとか、
何が書かれているとこういうイメージを湧きやすいかって、
やっぱり人それぞれだと思うんですよね。
そういうときに、
生成AIって仮想の開発チームのような振る舞いをしてくれる、
そういう使い方ができる。
例えばクロードですと、
エージェントチームっていうのを立ち上げて、
君はデザイナー、君はバックエンドのエンジニア、
君はフロントエンドのエンジニアですと、
この仕様書を読んで、
君たちの視点で見たときに、
ユーザーの振る舞いってどう記述していたらうれしいの、
みたいなものを投げかけて、
その観点を組み込むと、
少し仕様書が実際のチームにレビューしてもらう前に、
叩けるっていうのが、
1個自分は重要なポイントかなと思ってます。
そうすると例えばですけど、
ただ自然言語のテキストで書かれていた仕様書の中に、
1つ例えばイベントストリームの図が入れれたりとか、
そうすると確かにイメージ湧きやすいねとか、
情報の付加価値を上げていくときに、
この視点っていうのが使いやすいかなって思っています。
良いプロダクトマネージャーとか、
良い製品の責任者って、
やっぱり視点が複数あったりと深い。
例えばこういうケースのときは、
こうなるってことを事前にカバーしておいたり、
することができるのが、
経験とかシニアさのなせる技かなと思っていて、
そういうところも生成AIは結構サポートしてくれるかなと思っています。
一方で生成AIが書いた文章は、
さっきどこかで話した通り、
企業推論の話とか一般の平均論が出てくるんで、
それをそのまま使っちゃうと、
AI臭くて読めないわとか、
読んでいる最中にこれAIで書いて、
思考を経てないなみたいなものを感じちゃうケースはあるんで、
使い方とか記述の使い方は、
結構注意が必要なんじゃないかなというふうに思っています。
っていうのが1点目。
生成AIによる乖離の発見と情報源特定
2つ目、
乖離を埋めるためのものだって話があったんですけど、
この乖離を探すってところにも、
それなりに使えるかなというふうに思っています。
普段、例えばこういうふうに作ってるんだけどってのと、
もともと想定していたイメージである仕様との差分って、
どこで見つかるかっていうと、
実装の最中のさっきみたいな議論の中、
あるいはテストの中で見つかるってことが多いですと。
ただ、それだけではなくて、
もっと最終的に網羅的に乖離がないかっていうのを探そう、
とか思ったときに、
普通にやろうと思ったらコードの全検査なんかしなきゃいけない。
大変なんで人はやっぱりそれできないんですけど、
SAI、乖離があるポイントってないか、
探させるってのは一つ仕事の振り方として有用かなって思ってます。
ただ、何度も同じ注意を話してるんですけど、
嘘を言ったり、ハルシネーションしたり、
あるいはちょっとその乖離は別にどうでもよくないみたいなものが出てきたりするんで、
そこのSAIどうやって縛いて仕事させるんだっけみたいなポイントは、
割とコツだったり使い方だったり、
あるいはより良いモデルに課金するだったりが必要かなっていうふうには、
自分も感じています。
最後、仕様を聞くみたいなユースケースのときに、
仕様に直接アクセスするんじゃなくて、
その仕様書を読んだものをSAIに一言まず喋らせて、
だいたい把握した後に、
本当に確定的な回答をしなきゃいけないときには、
自分の目で見に行くみたいな、
場所を探すみたいなときに結構使えるかなっていうふうには思っています。
これはここのポイントに書いてあって、
こういう仕様、こういう挙動ですよみたいな言われたときに、
それそのまま鵜呑みにしても、
さっきの生成AIのXっぽいですみたいな回答と差分がないので、
確定的な答えってしづらいんですけど、
ちゃんと自分で見に行くみたいなことをしたら、
そこは確定的に答えられる。
自分で見に行く場所がどこなんだっけっていうのを探すのには、
それなりに使えるかなと思っていて、
自分はこういう3つのシーンで、
まとめと今後の展望
この仕様書っていうアングルだと生成AI、
ほとんどの場合はクロードコードを使っています。
というところで、
何か今日Howよりの話であまりしない話だったんですけど、
最近単純にこういう生成AI使いながら、
自分で物を作ったり、チームで物を作るときの支援業務を
してもらうみたいなのは楽しいなというふうに思っているので、
自分が感じていることを話してみました。
同じ内容はブログの記事にも出そうと思っているので、
もしよろしければそちらもご覧ください。
最近はブログのほうにニュースレター機能っていうのをつけて、
メールアドレスご登録いただくと、
新しい記事とか新しいポッドキャスト出たときに、
通知を受け取れるような機能も作ったりしたので、
もしよければそちらもご利用ください。
それでは今回以上になります。ありがとうございました。
