はじめに
同じ仕様書でも、読む人によって知りたいことはまるで違います。
開発の人は「この分岐、どういう条件で走るんだっけ」。PMは「どこまで決まっていて、どこが宙に浮いているか」。QAは「この機能の期待値はどこに書いてあるか」。全員が同じページを開いているのに、探しているものが違う。だから結局、それぞれが最初から全文を読み直すことになります。
この読み直しを、役割ごとの聞き方に置き換えました。 ドキュメントを開いて上から追うのをやめて、自分の立場で必要なことをAIに聞く。それだけで、同じ1ページから引き出せるものが変わりました。
思い当たるところ、ありませんか。
- 仕様書は確かにあるのに、自分に関係する部分がどこかを毎回探している
- 書いた人に「あの仕様どうなってましたっけ」と聞いたほうが早い、という状態が常態化している
- 課題の対応中に根拠のドキュメントまでたどり着けず、記憶で判断してしまう
この記事には、ONES.comの製品が3つ出てきます。先に短く紹介します。
- ONES Wiki：仕様書や設計書、議事録などのドキュメントを書いて貯めておける、ナレッジベース管理のツールです。
- ONES Project：課題やスプリントを管理する、プロジェクト管理のツールです。
- ONES Assistant：ONESの画面に組み込まれたAIアシスタントです。今開いているページや課題の内容を読み取って、質問に答えたり、課題を作ったりしてくれます。
大事なのは、この3つが同じ場所にあることです。ドキュメントを読む側と課題を動かす側を、ONES Assistantが1つの会話でまたげます。では、役割ごとに何が変わったのかを順に見ていきます。
開発：仕様の「例外のほう」を先に引き出す
実装に入るとき、いちばん時間を食うのは正常系ではありません。エラー時にどうするか、権限がない人が来たらどうなるか、リトライは何回か。こういう例外の記述は、仕様書のあちこちに散らばっていることが多いんです。読み落とすと、実装が終わったあとのレビューで指摘されて手戻りになります。
今はONES Assistantに、こう聞くところから始めます。
「このページのうち、エラー時・権限なし・タイムアウト時の挙動が書かれている箇所だけを抜き出して、条件と期待される挙動の対応で並べてください。書かれていない条件があれば、それも指摘してください」
返ってくるのは、条件と挙動の一覧です。ここで効いてくるのが最後の一文で、書かれていない条件を指摘してもらえるところが実装前にいちばんありがたい。「タイムアウト時の記述がありません」と返ってきたら、それはそのまま仕様の確認事項になります。
そのまま「この確認事項を課題として起票して」と続ければ、ONES Projectに課題が立ちます。ドキュメントを読んでいた画面から動かずに、確認待ちの状態を残せるわけです。
PM：決まっていることと、宙に浮いていることを分ける
PMが仕様書を読むときに知りたいのは、細部よりも「どこまで固まったか」です。議論の途中経過と決定事項が同じページに同居していると、この判断が一気に難しくなります。
ここでもONES Assistantに聞きます。「このページを、決定事項・未決事項・保留の3つに仕分けして。未決のものは、誰の判断待ちかも書いてあれば添えて」と頼むと、3つのかたまりに分けて返ってきます。
さらに便利なのが、ここから課題側につなげられることです。未決事項の一覧に対して「この未決事項を、担当と期限の欄を空けたまま課題の案として一覧にして」と続けると、起票前の案として確認できます。案の段階で粒度を直せるので、いきなり全部起票させるより結果的に速いです。
決まっていないことの可視化は、本来けっこう手間のかかる作業です。それが読み込みなしで一覧になるので、定例前の準備がかなり軽くなりました。
QA：期待値の根拠を、テスト観点の形で受け取る
QAの立場で読むときに確認したいのは「この機能はどうあるべきか」です。ところが仕様書は実装のために書かれていることが多く、テストの観点で並んでいることはまずありません。そこで、変換してもらいます。
「このページの内容から、テスト観点の候補を出してください。1件ごとに『確認したいこと』『前提条件』『期待される結果』を書き、根拠になった記述がページのどこかも添えてください」
ポイントは根拠の明示を頼むところです。期待される結果が仕様書のどの記述から来ているかが並んで見えるので、そのまま仕様確認の材料として使えます。根拠が曖昧なものが出てきたら、それは仕様書側に書かれていない可能性があるということなので、確認する順番も自然に決まります。
対応中の課題があるなら、その課題を開いたままONES Assistantに「この課題に関係する仕様の記述を探して、確認すべき点を挙げて」と聞くこともできます。課題とナレッジベースの間を、こちらが行き来せずに済みます。
役割ごとに、聞き方はこう変わる
同じ1ページに対して、3つの役割がそれぞれ何を頼んでいるかを並べてみます。
| 役割 | 聞いていること | 受け取りたい形 |
|---|---|---|
| 開発 | 例外・境界条件はどう書かれているか | 条件と挙動の対応、記述の欠けている条件 |
| PM | どこまで決まっていて、何が宙に浮いているか | 決定・未決・保留の仕分け、未決の判断待ち先 |
| QA | 期待される結果はどこに根拠があるか | 確認したいこと・前提・期待結果と、その根拠箇所 |
読み方を変えているのではなく、受け取る形を指定しているだけなんです。ここが分かってから、頼み方がぐっと安定しました。
そのまま自分の仕事に当てはめられる型
3つの役割の頼み方を見比べると、うまくいったものには共通の骨組みがありました。次の4点を指定すると、役割を問わず精度が上がります。
- 拾う範囲：ページ全体ではなく、どういう性質の記述を拾ってほしいかを言う
- 出力の形：一覧なのか、仕分けなのか、対応表なのかを指定する
- 根拠の明示：どの記述から導いたかを添えさせる
- 欠けの指摘：書かれていないものがあれば指摘させる
これを1つの型にすると、こうなります。役割の部分を自分の立場に差し替えれば、そのまま使えます。
このページを、私の立場（〇〇：開発／PM／QAなど）で必要な形に整理してください。
- 拾う範囲：〇〇に関係する記述だけ（それ以外は含めない）
- 出力の形：〇〇（一覧／決定・未決の仕分け／条件と挙動の対応表 など）
- 各項目に、根拠になったページ内の記述を添えてください
- 書かれていない項目があれば「記載なし」として指摘してください
まず一覧で見せてください。確認してから、必要なものだけ課題にします。
最後の1行を入れておくのが効きます。案の段階を1回はさむと、粒度のずれや拾いすぎをその場で直せるので、あとの整理がずいぶん楽になります。チームで使うなら、この型を共有ページに1枚置いておくと、誰が頼んでも似た粒度で返ってくるようになります。
なぜ役割別にうまく回るのか
理由は3つあると思っています。
- ドキュメントと課題が同じ場所にある：ONES Wikiのページを読ませたその会話のまま、ONES Projectの課題を作れます。橋渡しの仕組みを自分で用意しなくていいので、始めるコストがほぼありません。
- セットアップがいらない：ONES Assistantは製品の画面に組み込まれているので、環境構築も鍵の発行も必要ありません。エンジニアでないメンバーにも「この会話パネルに聞いてみて」で渡せます。PMやQAに広がったのは、これが大きかったです。
- 権限の範囲で動く：使う人が見られる範囲で答えが返ります。役割の違う人が同じやり方を使っても、見えないものが混ざる心配をしなくて済みます。
体感として変わったこと
正確に計測したわけではないので体感ベースの話になりますが、いちばん変わったのは「読み直しの回数」でした。以前は、実装前に一度、レビュー前にもう一度、テスト設計でさらにもう一度と、同じ仕様書を役割ごとに読み直していました。今は、それぞれが自分の形で1回受け取れば済むことが増えています。
もう一つ挙げるなら、「聞きに行く回数」も減りました。書いた人に確認しに行く前に、まず自分でONES Assistantに聞いて、それでも分からない部分だけ人に聞く。この順番になっただけで、割り込みがずいぶん減りました。
おわりに
仕様書が読まれない原因は、たいてい書き方ではなく「自分に関係する部分を探すのが面倒」というところにあります。だとすれば、探し方を役割ごとに変えられるようにするのが早い。ONES WikiとONES Projectが同じ場所にあって、ONES Assistantが1つの会話で両方をまたげるからこそ、この形が成り立っています。
あなたのチームで、いちばん読み直されている仕様書はどれでしょうか。まずはその1ページを開いて、自分の立場で必要な形を指定して聞いてみるところから始めてみてください。それだけで、受け取れるものが変わる感覚はつかめると思います。
自分の役割で試してみたい方は、ONES.com から実際の画面で確かめられます。チームの役割構成に合わせた使い方を相談したい場合は、support@ones.com までご連絡ください。