現行のない新規開発で、要件を仮説から固めていく進め方

新しいサービスやシステムを立ち上げる案件に、上流から参画したときの話です。基幹システムの刷新なら、まず現行の業務と画面があります。要件は、そこから「変えるもの」と「残すもの」を分けていけば形になります。

新規開発には、その足場がありません。まだ使う人がいません。業務の流れも決まっていません。会議で出てくるのは「こういうことができたら便利だと思う」という声です。SIerで現行を踏まえた要件定義を長く担当してきた人ほど、ここで手が止まりやすくなります。

この記事では、現行のない新規開発で、要望を仮説として扱い、確かめながら要件に固めていく進め方を書きます。発注者の側に入るITコンサルやPMOの立場で、次の会議から使える形にしました。

現行がないとき、要件の根拠は「誰かの想定」になる

刷新案件で「この項目は必要です」と言えるのは、現行で使われているからです。根拠は目の前にあります。新規開発では、根拠の多くが企画した人の頭の中にあります。言い換えると、要件の多くが、確かめていない想定の上に立っています。

これ自体は悪いことではありません。新しいものを作る以上、想定から始めるしかないからです。困るのは、その想定がいつのまにか決まったことのように扱われる場面です。

たとえば、構想資料に「担当者は現場からスマートフォンで実績を入力する」と書いてあったとします。誰も異論を言わないまま、画面設計はスマートフォン前提で進みます。ところが、利用者向けの説明会で現場の人から「手袋をしているので、現場では触れません。事務所に戻ってからパソコンで入れます」と言われます。ここで画面も入力の流れも作り直しになります。

この「スマートフォンで入力する」は、要件ではなく想定でした。最初からそう書かれていれば、早い段階で現場に一度聞く、という手が打てたはずです。

気をつけたいのは、想定を見つけたときの言い方です。「それは根拠がありませんね」と返すと、企画した人の構想を否定しているように聞こえます。「ここはまだ確かめていない前提なので、先に現場に聞いておきましょう」と、進めるための話として出すほうが通ります。

要望を、確かめられる形に書き直す

会議で出る要望は、たいてい機能の形をしています。「受注状況を一覧で見たい」「承認をシステムでやりたい」といった言い方です。このままだと、正しいかどうか確かめようがありません。そこで、要望を次の形に書き直します。

• 誰が
• どんな場面で
• 何をすると
• 何が良くなるのか

「受注状況を一覧で見たい」を書き直すと、たとえば「営業のマネージャーが、週次の会議の前に、担当者ごとの受注見込みを一画面で見られると、会議資料を作る手間がなくなる」となります。

こう書くと、聞くべきことが見えてきます。週次の会議は本当に毎週あるのか。今はその資料を何で作っているのか。資料作りにどれくらい手間がかかっていて、マネージャー本人はそれを減らしたいと思っているのか。機能の形のままでは出てこなかった問いです。

書き直した文は、自分の手元に置いておくだけにしないでください。要望を出した人に見せて「この理解で合っていますか」と聞きます。すると「いや、見たいのはマネージャーではなく部長で、月次の報告用です」と返ってくることがあります。こうした食い違いを、作る前に拾えます。

客先によっては、「仮説」という言葉が強く聞こえることもあります。「まだ決まっていないのか」と受け取られる場合です。そのときは「前提」「想定している使い方」と言い換えて構いません。言葉は場に合わせて選び、中身は変えない、と考えておけば十分です。

外れたら困る仮説から、先に確かめる

書き直していくと、確かめていない想定が山ほど出てきます。全部を確かめてから作り始めるのは無理です。順番をつけます。

見るのは二つです。外れたときにどれだけ作り直しが大きいか。そして、今どれくらい確からしいか。作り直しが大きく、しかも確からしさが低いものから手をつけます。

作り直しが大きくなりやすいのは、次のような想定です。

• 誰が使うのか、誰が入力するのか（権限や画面の構成が変わる）
• データはどこから来るのか（他のシステムとの連携があるかどうか）
• 業務の途中に承認や確認が入るのか（処理の流れと状態の持ち方が変わる）
• 同じデータを複数の部署で使うのか（項目の定義やコードの揃え方が変わる）

反対に、画面の並び順や帳票の細かい項目は、外れても後から直しやすい部分です。ここに会議の時間を使いすぎないようにします。

確かめ方は、大がかりでなくて構いません。想定している利用者に紙の画面イメージを見せて、自分の一日の流れの中でどこで使うかを話してもらう。データの持ち主になりそうな部署に、そのデータを今どこで管理しているかを聞く。似た業務で使っている表計算のファイルを見せてもらう。どれも短い時間でできます。

ここで気をつけたいのは、確かめる手段を検証用の開発だけだと思い込まないことです。技術的にできるかどうかは試作しないと分からないこともあります。一方で、誰が使うのか、本当に困っているのかは、人に聞けば分かることがほとんどです。聞けば済むことを、作って確かめようとしないでください。

最初のリリースは「何を確かめたいか」で範囲を切る

新規開発では、小さく始めて育てる進め方がよく選ばれます。ただ、最初の範囲を決める段階でつまずくことが多いです。

よくあるのは、機能の一覧を作り、優先度をつけて下のほうを削るやり方です。各部署に優先度を聞くと、ほとんどの機能に「必須」が付きます。結局ほとんど削れず、最初のリリースが大きくなります。

範囲は、機能の重要さではなく「最初のリリースで何を確かめたいか」で切ると決めやすくなります。進め方は次のとおりです。

1. 最初のリリースで確かめたいことを一文で決める（例：現場の担当者が毎日入力を続けるかどうか）
2. それを確かめるのに要る業務の流れを、入力から結果が使われるところまで書く
3. 流れの中で、手作業や表計算でしばらく代わりがきくところに印をつける
4. 印のついていない部分を、最初に作る範囲にする

先ほどの例なら、入力の画面と、入力した本人が自分の記録を見られる画面があれば、毎日続くかどうかは分かります。集計や帳票は、しばらくはデータを書き出して表計算で作れば足ります。各部署の「必須」は、削るのではなく「次のリリースで、最初の結果を見てから決める」と置き直します。こう伝えると、合意を取りやすくなります。

注意点が二つあります。一つは、小さくしすぎて業務が回らなくなることです。代わりの手作業が重すぎると、使われなかった理由がシステムなのか手作業なのか分からなくなります。確かめたいことが確かめられる大きさかどうかを、最後にもう一度見てください。

もう一つは、削ってはいけないものがあることです。権限の管理、操作の記録、客先の情報セキュリティの基準に関わるところは、最初のリリースから入れます。大手の客先ほど、ここが揃っていないと本番に出せません。後から足すと、作り直しも大きくなります。

前提が変わることを見込んで、決め方を先に決めておく

最初のリリースを出すと、想定のいくつかは外れます。新規開発ではそれが普通です。問題は、外れたことが分かったあとに、誰がどう決めるのかが決まっていない場合です。

たとえば、リリース後に入力があまり続かないと分かったとします。事業部門は「入力項目を減らせばいい」と言い、別の部署は「その項目がないと集計に使えない」と言います。決める場が決まっていないと、この議論が担当者どうしのメールで続き、次の開発が止まります。

これを避けるために、最初のリリースの前に次のことを決めておきます。

何が分かったら、何を変えるのか。「担当者の多くが入力を続けなければ、入力項目を見直す」「マネージャーが一覧を使わなければ、集計の機能は次に回す」といった形で、判断の基準を先に言葉にしておきます。数字で置けるなら数字で置きますが、無理に数字にしなくても構いません。基準が先にあるだけで、結果を見たときの議論が短くなります。

あわせて、その判断をどの会議で、誰が決めるのかも決めます。新しく会議を作らなくても、既にある定例の一部をその場にすれば足ります。

開発を担うベンダーとの関係にも影響します。範囲を固めて一括で発注する形だと、前提が変わるたびに変更の手続きが必要になり、双方の負担が大きくなります。契約の形は、発注者の購買部門や法務と相談して決めることです。参画している立場としては、前提が変わる見込みが高いことを早めに伝えておくのが役目です。契約の細かい扱いは、専門家に確認してもらうよう勧めてください。

事業部門と情シスの温度差を、同じ一覧で埋める

新規開発では、事業部門と情報システム部門の見ているものがずれやすくなります。事業部門は早く動くものを出したいと考えています。情シスは、作ったあと誰が運用するのか、既存のシステムやセキュリティの基準とどう合わせるのかを気にしています。

定例会議で、事業部門の人が「まず動くものを見せてほしい」と言い、情シスの人が「その前に、問い合わせを誰が受けるのか決めてほしい」と返す。こうした場面はよくあります。どちらも正しいことを言っています。ただ、話している順番が合っていません。

ここで役に立つのが、これまで書いてきた仮説の一覧です。業務についての想定だけでなく、運用についての想定も同じ一覧に入れます。問い合わせは誰が受けるのか。マスタの修正は誰がするのか。利用者が増えたら、アカウントは誰が発行するのか。新規開発では、こうした運用の体制もまだありません。運用の体制もまた、確かめていない想定の一つです。

同じ一覧を両方の部門に見せると、話の順番を揃えやすくなります。「入力が続くかどうかは最初のリリースで確かめます。問い合わせの窓口は、それまでに情シスと事業部門で仮に決めておき、結果を見て見直します」と言えば、どちらの心配も置き去りにしていないことが伝わります。

気をつけたいのは、どちらかの部門の代弁者に見えないことです。発注者側に入るITコンサルは、事業部門の会議に出る時間が長くなりがちです。そのぶん、情シスからは「事業部門の側の人」と見られやすくなります。運用の想定を拾うために、情シスの担当者と話す時間を自分から取りにいくと、この見え方は変わります。

最後に：次の会議の前に、一番大きな要望の裏を書き出す

ここまでの進め方を、最初から全部そろえる必要はありません。まずは一つだけ試してみてください。

次の会議の前に、いま出ている要望の中で一番大きなものを選びます。その要望が成り立つために、何が本当でなければならないかを三つ書き出します。誰が使うのか。どんな場面で使うのか。今それをどうやっていて、何に困っているのか。書き出してみて、根拠を答えられないものがあれば、それが最初に確かめる仮説です。

会議では、その一つを「ここはまだ確かめていない前提なので、来週までに現場に聞いてみます」と出してみてください。現行のない新規開発では、要件は最初から正しく書けるものではありません。こうして一つずつ確かめて固めていくものです。その進め方を周りと共有できるかどうかで、上流での動きやすさが大きく変わります。