PM on Railsで元の資料を更新した時、そこから作った要求に変更が反映されない問題がありました。資料は新しくなっているのに、以前生成した要求は古いままです。
別の機能では、生成AIが顧客に確認すべき質問を作れていました。しかし、確認画面を閉じると質問が消えます。担当者は質問をコピーし、顧客の回答を受け取った後、再び仕様に手作業で反映していました。
生成AIが質問や要求を作れるだけでは、社長や責任者の確認作業は減りません。情報が変わった時に、どこに影響し、誰が確認し、何を実装するかまでつながる必要があります。
そこでPM on Railsでは、判断の結論だけでなく、出所、変更、質問、回答、承認、作業、動作証拠を一つの流れとして残すようにしました。
最初の問題は、古い仕様を検索できてしまうことでした
社内資料を生成AIから探せるようにすると、情報を見つける時間は減ります。ただし、古い情報も検索できれば、以前の判断を正しいものとして返す危険があります。
元の資料と、そこから作った要求の関係が残っていなければ、資料を更新しても、どの要求を見直すべきか分かりません。検索精度だけを上げても、この問題は解けません。
必要なのは、情報を保存する仕組みではなく、情報が変わった時に影響先を知らせる仕組みでした。
元の資料と、そこから作った要求を関係付けました
PM on Railsでは、議事録、仕様書、検討メモなどの元情報と、そこから作った要求をつなぎます。要求からは、利用者の目的、具体的な利用場面、作業、確認結果へたどれます。
元の資料
→ 要求
→ 利用者が実現したいこと
→ 具体的な利用場面
→ 作業
→ 動作確認
→ 証拠
元の資料が変わったら、関係する要求に「出所が変わった」と印を付けます。さらに、その下にある利用場面と作業まで影響候補として示します。
自動で全部を書き換えるのではありません。変更前後と影響候補を示し、人が採用、修正、見送りを決めます。
顧客への質問も、画面上の一時的な文章ではなく記録として残すようにしました
生成AIによる要求確認では、「誰が承認するのか」「上限金額はいくらか」「例外時はどうするか」といった質問を作れます。
以前は、その質問が確認画面に出るだけでした。閉じれば消えるため、顧客に送る文章と、受け取った回答を人が別の場所に転記していました。
そこで、質問を一件ずつ記録し、次の状態を持たせました。
- 未送付
- 送付済み
- 回答済み
- 仕様への反映待ち
- 反映済み
- 確認不要として終了
複数の質問は一つの質問票へまとめ、回答は質問番号で対応させます。顧客に細切れで送らず、どの回答がどの確認事項に対するものかを失わないためです。
この内容について、Beekleに相談してみませんか？ 何を作るべきか、どこまで費用をかけるべきか、発注前の不安を無料で整理します。顧客の回答を、そのまま仕様に上書きしません
顧客の自由記述を、そのまま要求や仕様に入れると、言葉の粒度が合わず、既存の設計と矛盾する場合があります。
PM on Railsでは、回答から変更案を作り、現在の仕様との差を人に見せます。人が承認した後に、既存の要求、利用場面、作業に反映します。
顧客の回答
→ 変更案
→ 現在の仕様との差
→ 人が承認・修正・見送り
→ 既存の仕様に反映
→ 影響する作業と確認を更新
回答をもらっただけの状態と、仕様に反映された状態を分けます。回答が届いても、古い仕様のまま実装が進む事故を見つけるためです。
社長の判断を残す時も、結論だけでは足りません
「この顧客は例外対応する」「この機能は今回作らない」という結論だけを残すと、条件が少し変わった時に再び社長に確認が来ます。
再利用するには、次を一緒に残します。
- 何を守るための判断か
- どの情報を根拠にしたか
- どの条件なら同じ判断を使えるか
- どの条件なら責任者の判断に戻すか
- 判断後に何が起きたか
- いつ見直すべきか
生成AIは、現在の条件と過去の判断を比べ、使えそうな候補と相違点を示します。最終判断と正式な方針更新は、権限を持つ人が行います。
通常の処理と、新しい例外を分けます
社長依存を減らすために、すべての判断を自動化する必要はありません。同じ条件で繰り返す通常処理と、会社として新しく決める例外を分けます。
- 過去の条件と一致する場合は、根拠と出所付きで候補を出す
- 金額、契約、顧客影響、情報管理の基準を超える場合は責任者の判断に戻す
- 前例がない場合は、似た判断と違いを示す
- 正式な基準変更は、人の承認後に反映する
社長が行うのは、過去の資料を探すことではなく、前例では処理できない違いを判断することです。
実装できたことと、効果が確認できたことを分けています
PM on Railsでは、元資料と要求の関係、上流変更の通知、顧客確認事項、回答履歴、変更案、具体的な利用場面、作業、動作確認を実際に管理しています。
一方、この仕組みによって社長への質問時間が何割減ったか、変更漏れが長期的にどれだけ減ったかは、まだ十分な比較期間がありません。
現時点で確認できているのは、以前は消えていた質問と回答、黙って古くなっていた要求、反映待ちの変更を、状態として見つけられるようになったことです。
社長が一度下した判断を、次の仕事でも使える形で残します
判断を文書に保存するだけでは、仕事は進みません。必要な時に探せること、元情報が変わったら気づけること、顧客の回答を確認後に仕様に反映できること、作業と動作証拠までつながることが必要です。
一度答えた判断を、出所と条件付きで残し、変更があれば影響先に伝え、次の作業と確認につなげる。
PM on Railsは、私が毎回全体を見ていた判断の流れを、会社の仕組みに移すために作っています。
社長の時間を作るほかの取り組みは、社長の時間を作る経営DXにまとめています。
Beekleにご相談ください Beekleでは、AI活用や業務システム開発について、作るものの整理、費用感、進め方まで一緒に確認します。まだ曖昧な段階でも、最初に何を決めればよいかから相談できます。参考資料
- PM on Rails
- AIエージェントに「動いた証拠は？」と詰めよう
- 入山章栄『世界標準の経営理論』