要件定義の会議に呼ばれて、2時間かけて何も決まらずに終わったことがあります。全員が真面目に発言していました。それでも決まらなかった。
あとで議事録を読み返して、理由が分かりました。質問の形が悪かったんです。
要件定義は、これから作るものの中身を決める最初の工程です。ここで決めきれないと、あとの工程が全部その上に乗ることになります。
決まらなかった会議のやりとり
再現します。経費精算のシステムを入れ替える案件で、私は開発側にいました。
「経費精算はどういう流れですか」と聞きました。返ってきたのが「申請して、上長が承認して、経理が確認します」。
そこで「承認は何段階ですか」と聞くと「基本は1段階です」。基本、という言葉に引っかかったので「例外はありますか」と聞くと「金額が大きいと部長決裁になります」。
ここで「いくらからですか」と聞いたところ、その場の全員が黙りました。3万円だと思っている人と、5万円だと思っている人がいたからです。
この時点でようやく議題が生まれました。 それまでの1時間は、全員が「知っていること」を話していただけです。
抽象的に聞くと抽象的にしか返ってこない
このとき自分がやっていたのは、大きい枠から順に聞くという当たり前の進め方でした。流れを聞いて、段階を聞いて、条件を聞く。
問題は、大きい枠の質問には誰でも答えられてしまうことです。「どういう流れですか」と聞けば、その場の全員が同じ答えを言えます。話が進んでいる感触があるので、1時間気づかない。
答えが割れる質問に当たった瞬間に、初めて決めるべきことが見えます。だから要件定義の会議で本当にやりたいのは、答えが割れる質問を早く見つけることです。
いまは順番を変えています。流れを聞いたら、次は真ん中を飛ばして端から聞く。金額の境目、時間の境目、権限の境目。境目は必ずどこかにあって、そして高い確率で人によって認識が違います。
数字と例外から聞く
具体的に、いま最初に聞いている質問を挙げます。
数字が入るところ。 何円から、何日以内、何件まで、何人まで。この形の質問は、答えが一意に決まるか、割れるかのどちらかです。どちらでも収穫があります。
例外の扱い。 「例外はありますか」ではなく「例外が起きたとき、いまは誰がどうしていますか」と聞きます。前者は「特にないです」で終わりますが、後者だと具体的な作業が出てきます。だいたい誰かが手作業で埋めています。
やめられるかどうか。 これは業務そのものを削る質問です。「この承認、無くしたらどう困りますか」。答えられないなら、たぶん惰性で残っている工程です。システムに写す前に消せます。
3つめは嫌がられることもあります。ただ、いまある業務をそのまま写すと、いまある無駄もそのまま写ります。
書いた要件は確認方法とセットにする
会議で決まったことを文書にする段階でも、ひとつ決めごとを置いています。要件を1つ書いたら、その隣に確認方法を1行書くというものです。
「経費申請を分かりやすくする」は確認方法が書けません。何をもって分かりやすいと言うのかが決まっていないからです。
「入力項目を12個から5個に減らす」なら書けます。数えれば終わります。
この判定はかなり機械的に効きます。確認方法が書けない要件は、まだ要件になっていない。私はこれを、設計とテストの対応を表すV字モデルから借りました。
要件定義には国際規格もある
自己流でやっている感覚があったので、あとから標準側の解説を読みました。要件に関する国際規格として ISO/IEC/IEEE 29148 があり(初版が2011年、現行は2018年版)、日本で参照される共通フレーム2013にも、この規格のエッセンスが取り込まれています。共通フレームは、工程の中身を国内向けに細かく書いた解説書のようなものです。
なお規格の世界では「要件」ではなく要求という言い方をします。同じものを指していると思って読んで差し支えありません。
知って安心したのが、規格が求める要求の性質のひとつに検証できることが入っていた点です。確認方法とセットにするというやり方は、我流ではなく標準側にもある発想でした。
規格そのものは有償なので、買って読む必要はないと思います。ただ「確認できない要件は、まだ要件になっていない」という一点だけ持っておくと、判断が速くなります。
工程全体の中での要件定義の位置は、こちらにまとめました。
実装が速くなった分、ここが効くようになった
最近この工程の重さが変わったと感じています。
実装(コードを書く工程)をAIに任せられるようになって、作る時間が縮みました。私が測ったときは4日から1日半になっています。一方で要件定義は縮まず、むしろ増えました。
理由は単純で、あいまいなまま実装すると作り直しになるからです。以前は実装に数日かかったので、その間に気づけた。いまは半日で出てくるので、気づく前に完成します。
面白いのは、要件を詰める作業そのものはAIに手伝わせられることです。聞き漏らしを指摘させたり、書いた要件から確認方法を出させたり。決めるのは人ですが、詰め切れているかの点検は任せられます。
会議の前に1枚だけ書く
いま私は、要件定義の会議に入る前に1枚だけ紙を用意します。
そこに書くのは、答えが割れそうな質問を5つだけ。金額の境目、時間の境目、権限の境目、例外の扱い、やめられるかどうか。会議はそこから始めます。
流れの説明は、資料を読めば分かります。集まってやるべきなのは、認識が割れている場所を見つけることのほうでした。冒頭の2時間は、それに気づくための授業料だったと思っています。
この記事は聞く側の目線で書きましたが、聞かれる側で読んでいる方にも同じ5つが使えます。会議の前に自部署で答えを揃えておけば、そのまま提出資料になります。情シスの立場で間に立つ場合も、割れているのが現場の中なのか現場と経営の間なのかで、持っていく先が変わります。
