はじめに
同じツールを使っていても、役割が違えば困っていることは違います。
AIに仕事を任せる話は、いまはコードを書く場面を中心に語られることが多いですよね。ただ、実際にチームの時間を吸っているのは、コードそのものより「その前後」だったりします。仕様を探す、要件を課題に割る、テスト観点を洗い出す。このあたりは、役割ごとにやっていることが違うのに、詰まり方だけがよく似ています。
社内でよく聞くのは、こんな声です。
- 実装中に「この仕様、どこかに書いてあったはず」で手が止まる（開発）
- 要件が固まったのに、課題に落とすまでの転記でまる半日が消える（PM）
- テスト設計のたびに、仕様書を頭から読み直している（QA）
どれも、ドキュメント側と課題側を人間が行ったり来たりして橋渡ししている、という点で同じ構造です。私のチームでは、この往復をAIに肩代わりさせるようにしました。今回は、それを役割ごとに分けて整理してみます。開発・PM・QAで、何をどう頼むと効くのか。ONESを使っていない方でも、頼み方の型としては持ち帰れるように書きました。
この記事には、ONES.comの製品が3つ登場します。先に短く紹介しておきます。
- ONES Wiki：仕様書や設計メモ、運用手順などのドキュメントを書いて貯めておける、ナレッジベース管理のツールです。
- ONES Project：課題やスプリントを管理する、プロジェクト管理のツールです。
- ONES Assistant：ONESの画面に組み込まれたAIアシスタントです。今開いているページやプロジェクトの内容を読み取って、質問に答えたり、課題を作ったりしてくれます。
3職種に共通しているのは「往復」だった
役割ごとの話に入る前に、下敷きを一つだけ。
3つの困りごとを並べてみると、やっていることは全部「ドキュメント側の情報を読んで、課題側に反映する」か、その逆です。開発は仕様を読んで実装に反映する。PMは要件を読んで課題に落とす。QAは仕様を読んでテスト観点に落とす。読む場所と書く場所が別モジュールにある、という点が共通しているわけです。
ONES Assistantで効いているのは、この読む側と書く側が1つの会話の中でつながっているところでした。ナレッジベースを探させてから、その結果を持ったまま課題の話に移れます。画面を切り替えたり、結果をコピーして貼り直したりする工程がありません。
開き方を先に補足しておきます。ONES Assistantは、マイワークのホームからも、ナレッジベースのスペースの上部からも、プロジェクトの画面からも開けます。今どこを見ているかに合わせて、扱う範囲や提案の内容が変わるので、用があるものの近くで開くのがコツです。この記事でも、役割ごとにどこから開いたかを書いていきます。
もうひとつ。開くと、その場面でよく使う操作がボタンとして並びます。よくある用事はそれを押すだけで済むので、これから出てくるような長い依頼文を自分で書くのは、出力の形をこちらで固めたいときだけで大丈夫です。
そのうえで、役割ごとに変わるのは「何を出力させるか」だけなんです。ここを押さえると、3職種ぶんの頼み方が同じ骨格で書けます。
開発：実装の手を止めずに仕様を引く
いちばん頻度が高いのがこれです。コードを書いている途中で「この分岐の想定挙動、仕様書にどう書いてあったっけ」となる場面ですね。
以前は、キーワードでナレッジベースを検索して、それらしいページを何枚か開いて、目で追って確認していました。表記が少しぶれていると引っかからず、探し直しになることもあります。
今は、対応中の課題を開いたまま、その画面からONES Assistantを呼んで聞きます。「この課題に関係する仕様が書かれているページを探して、リトライ時の挙動の部分だけ先に見せてください。どのページから引いたかも教えてください」といった頼み方です。関連するページを探したうえで、必要な箇所の要約と、根拠になったページを返してくれます。詳しく読みたければ、そのまま元のページを開けばいいだけです。
ここでのコツは、参照元も一緒に出させること。要約だけを受け取ると結局あとで裏取りすることになるので、最初から「どのページから引いたか」を含めて頼むほうが早いです。
PM：要件から課題の草案までを一気に出す
PM側でいちばん重いのは、要件が固まってからの転記でした。要件書を開いて、機能ごとに区切って、担当と優先度をあたりで振って、一件ずつ起票していく。読み込みと転記だけで午前が終わる、というのはよくある話だと思います。
ここもONES Assistantに任せています。ONES Wikiで要件ページを開き、そのページからONES Assistantを呼んで、読ませたうえで課題の草案まで出してもらう流れです。粒度と項目を先に指定しておくのがポイントで、これを曖昧にすると、粒度がばらついた課題がずらっと並んでしまいます。
そのまま使える依頼文を置いておきます。
このナレッジベースのページを読んで、実装単位の課題に分解してください。条件は次の7点です。
1. 対象は「機能要件」の一覧とする。非機能要件は分解に含めず、最後に
「別途必要になりそうな作業」として名前だけ挙げる
2. 1課題は1人が2〜3日で終えられる粒度にする。大きい要件は分割し、
小さい要件は無理に分けない
3. 各課題に「目的」「完了条件」「対応する要件番号」「根拠になった
ページ内の見出し」を書く
4. ページに書かれている優先度をそのまま引き継いで、課題ごとに付ける
5. 依存関係がある課題は、どれが先かを明記する
6. このプロジェクトには既に課題が登録されています。提案する課題が
既存の課題と重複していないか確認し、重複するものは「既存あり
（課題名）」と注記して新規から外す
7. 要件に書かれていない前提は勝手に補わない。ページ内で未確定と
されているものも含めて「要確認」として最後にまとめる
まず表形式の一覧で見せてください。起票は私が確認してからお願いします。
長く見えますが、効いているのは後半の3つです。
4番は、優先度をこちらで振り直す手間をなくすためのものです。要件ページには「必須」「高」「中」がもう書かれているので、AIに考えさせるのではなく、書いてあるものを運ぶだけにします。判断させないほうが、結果はぶれません。
6番が今回いちばん試したかった条件でした。要件を分解するだけなら、ドキュメントを読めるAIならどれでもできます。ただ実際の現場では、その要件の一部はもう課題として起票済みなんです。ドキュメント側だけを見て分解すると、既にあるものをもう一度提案してきます。ONES Assistantはナレッジベースと同じ会話の中でプロジェクト側の課題も見られるので、「これは既にある」まで含めて返ってきます。
7番と最後の一行は、確認をはさむためです。いきなり起票させると、あとから直すほうが手間になります。一覧で見て、粒度と抜けを直してから通す。この一往復があるかどうかで、使い勝手がかなり変わりました。
QA：テスト観点を仕様から起こす
QAでは、テスト設計のたびに仕様書を頭から読み直す作業がありました。読むこと自体は必要な工程なんですが、「観点の抜けがないか」を人力の記憶に頼っているのが不安だったんです。
今は、仕様ページを開いたままONES Assistantを呼び、そのページを読ませて観点の草案を出させ、それを叩き台にレビューする形にしています。頼むときは、正常系だけで終わらせないよう明示します。「このページの仕様から、テスト観点を洗い出してください。正常系・異常系・境界値・権限の違いによる差分の4区分に分けて、仕様に書かれていない部分は推測せず『仕様未記載』として分けてください」といった具合です。
面白かったのは、観点そのものより「仕様未記載」の欄が役に立ったことでした。仕様の穴が可視化されるので、テストを書き始める前に確認を投げられます。これは以前なら、テスト実行中にバグらしきものを見つけてから「あれ、これ仕様どうなってるんだろう」と戻っていた工程です。
役割別に変えるのは、この3つだけ
3つ並べてみると、頼み方の骨格は同じでした。変えているのは次の3点だけです。
| 役割 | 読ませるもの | 出力させる形 | 必ず添える条件 |
|---|---|---|---|
| 開発 | 対応中の課題＋関連する仕様ページ | 該当箇所の要約 | 参照元のページを示す |
| PM | 要件ページ＋既存の課題 | 課題の一覧（草案） | 粒度の基準、既存課題との重複チェック、確認してから起票 |
| QA | 仕様ページ | テスト観点の一覧 | 区分を指定し、仕様未記載を分ける |
自分の役割の行を見て、真ん中と右の列を差し替えれば、だいたい形になります。
頼み方の良し悪しも、この3列に対応していました。
❌「この仕様まとめて」
✅「この仕様のうち、エラー時の挙動だけを、どのページから引いたか付きで要約して」
❌「課題に分けておいて」
✅「1人2〜3日の粒度で、目的と完了条件つきの一覧に。既存の課題と重複するものは外して。起票は私の確認後に」
❌「テスト観点出して」
✅「正常系・異常系・境界値・権限差分の4区分で。仕様に書いていないものは別枠に」
左側が通らないのは、AIの性能というより、こちらが出力の形を決めていないからでした。範囲・形式・確認のタイミング。この3つを言葉にするだけで、返ってくるものが安定します。
チームに広げるときにやったこと
個人で使っているだけだと、うまい頼み方が共有されません。私のチームでは、うまくいった依頼文をONES Wikiのページに集めるようにしました。役割ごとに見出しを分けて、そのまま貼れる形で置いておくだけです。
新しく入った人が最初に困るのは、たいてい「どう聞けばいいか」なので、ここが揃っていると立ち上がりが速くなります。ONES Assistantの返しがいまいちだったときも、依頼文のどこが足りなかったかを追記しておけば、次の人が同じところで止まらずに済みます。
体感ベースで言うと、いちばん変わったのは作業時間そのものより、中断の回数でした。仕様を探しに行くために手を止める回数が減ると、一日の終わりの疲れ方が違います。ここは数字で測れていないので、あくまで実感としてですが。
おわりに
役割ごとに困りごとは違って見えても、根っこは「ドキュメントと課題のあいだを人が往復している」という一点でした。その往復を、ONES WikiとONES ProjectをまたげるONES Assistantに任せる。やっていることは、それだけです。
大事なのは、AIに全部を委ねることではなく、出力の形をこちらが決めておくことだと思っています。範囲を切る、形式を指定する、確認をはさむ。この3つさえ守れば、開発でもPMでもQAでも同じように効きました。
あなたのチームでは、どの役割がいちばん往復していますか。まずはそこから、上の表の行を1つ試してみるのが早いと思います。
同じ往復に時間を取られている方は、ONES.com で自分のドキュメントと課題をつないでみるのが手っ取り早いです。30日間は無料で、クレジットカードの登録もいりません。Googleアカウントがあればそのまま始められます。
自社の役割構成でどう組み立てるか話したい場合は、support@ones.com までお気軽にどうぞ。