要件合意の翌日、開発チームから「何が変われば完成ですか」と聞かれる──上流SEが業務の変化を一文で残す

顧客との要件確認が終わり、画面名も項目名も決まった。議事録には「合意」と残り、上流SEとしては開発へ渡せるところまで進めたつもりだった。ところが翌日、開発メンバーから聞かれる。

「この要件は、何が変われば完成ですか」

入力欄を追加することか、承認画面に表示することか、それとも後工程の担当者が確認なしで次へ進めることか。顧客と話した内容は思い出せるのに、完成を判定する一文が出てこない。ここで説明が揺れると、後工程の解釈差は要件を渡した自分へ戻ってくる。

僕は、上流SEが残すべきなのは機能名を増やした議事録だけではないと思う。一つの要件につき、「誰の仕事が、何から何へ変わればよいか」という業務のBefore→Afterを一文にする。その一文が、顧客の期待と開発の完成条件をつなぐ記録物になる。

機能に合意しても、仕事の完了には合意していない

要件確認では、画面、項目、ボタン、帳票といった名詞が残りやすい。対象を指しやすく、一覧にも書きやすいからだ。けれど、利用者がその機能を使ったあとに何を終えられるのかは、名詞だけでは分からない。

たとえば「申請画面に取引理由を追加する」という要件があるとする。これは仮想例である。開発側には、項目を表示し、入力値を保存できれば完成に見えるかもしれない。一方、業務側が望んでいるのは、承認者が申請者へ問い合わせずに判断できることかもしれない。実装対象は同じでも、完成の見方が違う。

この差を残さないまま設計へ進むと、テストでは項目の表示と保存が確認される。しかし本番では理由の書き方がばらつき、承認者の確認作業が減らない。機能は完成したのに、仕事は変わっていないという状態になる。

一文は、仕様を短くするためではない

業務変化の一文は、長い要件を要約するキャッチコピーではない。仕様書の代わりでもない。仕様を読む前に、関係者が同じ完成像へ戻るための基準である。

形はシンプルでよい。

「誰が、今は何をしており、導入後は何ができるようになるか」

先ほどの仮想例なら、「承認者が申請者へ理由を聞き返してから判断している状態から、画面上の取引理由を見て判断できる状態へ変える」と置ける。ここまで書くと、次に確かめることも見えてくる。承認に必要な理由は何か。自由記述で足りるか。入力者はその情報を持っているか。例外時は誰へ戻すか。

一文を作る目的は、検討事項を消すことではない。むしろ、機能名の陰に隠れていた未確認事項を早く見つけることにある。一文を読んで顧客と開発が別の場面を思い浮かべるなら、合意はまだ粗い。

顧客と開発に、同じ一文を読み直してもらう

一文を上流SEだけで完成させると、それも別の解釈になり得る。顧客には「この変化が起きれば、今回の要件は目的を満たしたと言えますか」と確認する。開発には「この変化を成立させるために、実装とテストで不足している条件はありますか」と問い直す。

顧客側からは、「問い合わせをゼロにする必要はない」「特定金額以上だけ判断できればよい」と条件が返るかもしれない。開発側からは、「理由だけでなく添付資料が必要」「既存データは対象外」といった境界が出るかもしれない。そこで初めて、業務の期待と実装範囲を同じ場所で調整できる。

大切なのは、一文を受入条件のすべてにしないことだ。性能、権限、データ、例外、非機能要件には別の確認が必要である。ただ、何のための条件かを見失わないために、一文を各資料の先頭へ置く。要件IDと結び、変更時にも同じ文を読み直す。

一文が作れないときは、言葉の工夫より、業務の確認が不足している可能性を疑う。利用者が誰か決まっていない。現在の手順を誰も説明できない。変化後に判断する人が曖昧。そうした状態で無理にきれいな文を作ると、未確認の前提が確定事項に見えてしまう。「現状未確認」「完了像は仮説」と印を付け、確認先と期限を置くほうがよい。

また、一つの要件に複数の業務変化が混ざるなら、文を長くして押し込まない。入力者の作業、承認者の判断、後工程の連携を分け、それぞれが同じ要件に必要なのかを確かめる。一文という制約は、情報を削るためではなく、誰のどの変化を合意しているかを曖昧にしないために使う。

上流SEの成果は、後工程が判断できる形に残る

要件定義の場で多くを聞き、顧客の言葉を理解しても、その理解が担当者の頭の中だけにあると後工程は使えない。開発が聞き返すたびに説明し直せば進められるが、そのやり方では、担当者が不在になった瞬間に完成条件が揺れる。

上流SEの価値は、顧客の言葉をシステム用語へ置き換えることだけではない。利用者の仕事がどう変わるのかを、顧客と開発の双方が確かめられる記録へ変えることにある。

明日の要件確認で、すべての資料を作り直す必要はない。まず一つの要件を選び、「誰の仕事が、何から何へ変わるか」を一文で書く。その文を顧客と開発へ読み返し、同じ完成像が見えるかを確かめる。

あなたが今扱っている要件は、機能名を外しても「誰の仕事が、何から何へ変わるか」を一文で言えるでしょうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！