業務システムの要件定義で先に決める5つのこと
業務システムの開発で、いちばん高くつくのは実装ではありません。作り始めたあとに前提が変わることです。
私は、紙とExcelで回っていた業務を管理画面に置き換える仕事を担当してきました。お客様へのヒアリングから要件定義、設計、開発まで一通りやります。そのなかで「これは着手前に決めておくべきだった」と思ったことが、5つあります。
一般論ではありません。決めていなかったせいで、実際に手戻りしたものです。
1. 誰に、いつ、要件定義へ入ってもらうか
まず決めるべきなのは機能ではなく、人です。
要件定義の最初の会議に、各部署で業務の全体を知っている人に入ってもらってください。一部の工程しか見ていない人だけで進めると、あとから抜けが出ます。
よくあるのは、システムができてから別の担当者が出てきて「この項目が足りない」と言われるケースです。ただ、そこで言われても設計は簡単には変えられません。画面を1つ足すだけに見えても、裏側のデータの持ち方から見直しになることがあります。開発が終わってからの指摘は、たいてい一番高いです。
あわせて、決定権を持つ人を必ず決めてもらいます。部署ごとに要望が食い違ったとき、決める人がいないと会議が止まります。実際、部署によってやりたいことが違い、仕様をまとめるだけでかなりの時間を使いました。
設計書だけを渡しても、確認してもらえない
もうひとつ、エンジニア側の準備の話をします。
要件を確認してもらうとき、設計書だけを渡しても、たいていうまくいきません。エンジニアでなければ、設計書からできあがりを想像するのは難しいからです。「はい、大丈夫です」と言われても、実際には読めていないことがあります。
そこで、見ればわかるものを用意します。以前は画面イメージや簡単なモックを作っていましたが、いまは生成AIを使って実際に触れる画面を短時間で作ってしまうほうが早くなりました。
この差は思ったより大きいです。静止画のモックだと「だいたいこんな感じですね」で終わってしまうのですが、クリックできる画面を触ってもらうと、その場で具体的な指摘が出てきます。「この順番だと入力しづらい」「ここは前の画面に戻れないと困る」。設計書を眺めていても出てこなかった話です。
作ったものはそのまま本番に使うわけではなく、確認のために捨てる前提で作ります。捨てる前提だから、速く作れるほうがいい。ここは近年でいちばんやり方が変わったところだと思います。
「この機能がほしい」の前に、目的と背景を聞く
要望は機能の形で出てきます。「一覧にこの項目を追加してほしい」「この画面にボタンがほしい」。
そのまま受けずに、なぜそれが必要なのか、いま何に困っているのかを先に聞きます。目的から聞くと、別のもっと簡単な方法で解決することが少なくありません。機能から入ると、要望の数だけ機能が増えていきます。
2. 同じものの呼び方が、部署ごとに違う
これは、どの会社でも起きることだと思っています。
会社ごとに独自の呼び方があり、部署によって同じ相手を別の言葉で呼んでいることがあります。悪いことではなく、それぞれの部署が自分の業務に必要な形で言葉を使ってきた結果です。ただ、ここの定義を最初に決めておかないと、あとから定義漏れが出ます。
あるお客様では、打ち合わせのなかで一貫して「顧客」と呼ばれていた相手が、実際には5種類に分かれていました。部署によって呼び方が違うため、話を聞いている限りでは同じものに聞こえていたのです。
問題は、呼び方が違うだけではなかったことです。種類によって、そのあとの工程が違い、見積の出し方も、請求先も変わります。名前が違うのではなく、業務フローそのものが別物でした。
「顧客」という1つの区分で作り始めていたので、種類が増えた時点でデータの持ち方から見直しになりました。画面を足すだけでは済まない類の手戻りです。
同じことは、数字を扱う場面でも起きます。以前、同じ名前の指標を部署ごとに集計していたのに、数字がどうしても合わないということがありました。原因は、除外する条件をどこから取るかが部署ごとに違っていたことでした。指標の名前は同じでも、中身が別物だったわけです。
最初のヒアリングで、業務に出てくる言葉をすべて書き出して、意味が同じか違うかを1つずつ確認してください。地味な作業ですが、ここを飛ばすと後で必ず返ってきます。
3. 権限は「できること」ではなく「見せたくないもの」から決める
権限設計は、「誰が何をできるか」から入ると際限なく複雑になります。組み合わせが無限に作れてしまうからです。「誰に何を見せたくないか」から入ると、必要な粒度が先に決まります。
そして実際にやってみると、権限の軸は1つではないことに気づきます。
最初に思い浮かぶのは役割による権限です。管理者は編集できて、一般ユーザーは閲覧だけ。ここまではよく設計されます。
ところが業務システムでは、これだけでは足りないことがよくあります。同じ役割の人でも、自分の部署のデータしか見せたくない、という要件が出てくるからです。特に金額に関わる情報では珍しくありません。
最初に考えがちな形 — 軸が1つ
- 管理者 ── 編集できる
- 一般ユーザー ── 閲覧だけ
役割で分けるところまでは、たいてい設計される。
実際に必要になる形 — 軸が2つ
| 閲覧 | 編集 | |
|---|---|---|
| 自分の部署のデータ | できる | できる |
| 他部署のデータ | できる／できない | できない |
同じ役割の人でも、どの部署のデータかで見せ方が変わる。
この2つは別の軸です。 掛け合わせて考える必要があります。閲覧・編集だけを想定して設計していると、あとから所属の軸が出てきた時点で作り直しになります。権限まわりは、あとから足すのがいちばん大変なところでした。
4. 一覧に「載せない項目」を決める
5つのなかで、いちばん軽く扱われがちなのがこれです。
一覧画面の項目を決めようとすると、ほぼ必ずこうなります。全員が、自分の欲しい数字や情報を一覧の中で完結させようとする。その結果、表示項目も検索項目も、ほとんど全部が候補に挙がります。
そうしてできた一覧は、実際には使いにくくなります。項目が多すぎて横に長くなり、目的の情報を探すのに時間がかかる。情報を増やしたのに、探せなくなるという逆転が起きます。
ここで持っておくとよい前提があります。
一覧は、見るための画面ではありません。探すための画面です。
見るのは詳細画面の役割です。一覧は目的のレコードにたどり着くためのもので、必要なのは絞り込みに使う項目と、見分けがつく最低限の項目だけです。
これは1社だけの話ではなく、これまで関わった複数の現場で同じことが起きています。載せる項目を決めるより、「この項目は一覧に載せない」と決めるほうが大事です。
5. いまのフローを、そのまま作らない
紙やExcelで回っている業務をシステムに置き換えるとき、いちばん自然に思えるのは、いまのフローをそのまま画面にすることです。使う人にとっても見慣れた形なので、抵抗が少ない。
ただ、ここで一度立ち止まったほうがいいです。そのフロー自体に問題があるかもしれないからです。
現場でよく聞くのは、こういう答えです。
昔からこのやり方でやってきたので。
そういうものだと思っていました。
なぜその手順を踏んでいるのかが、やっている本人にも分からなくなっている状態です。誰かが決めた理由があったはずですが、その人はもういない。手順だけが残っている。
この状態のフローをそのままシステムにすると、理由の分からない手間まで、そのまま固定してしまいます。 しかも一度システムになると、紙のときより変えにくくなります。
なので、ここでも聞くのは目的と背景です。この工程は何のためにあるのか、この確認は誰のためのものなのか。それが分かると、整理できるところが見えてきます。「この工程は不要になります」「この2つは1つにまとめられます」と提案できるのは、背景を聞けたときだけです。
逆に、背景が分からないままだと、こちらからは何も言えません。言われたとおりに作るしかなくなります。
おわりに
5つ書いてきて、あらためて見ると、1つ目と5つ目は同じことを言っています。目的と背景を先に聞く。機能の単位でも、業務フローの単位でも、結局やることは同じでした。
どれも、決めなかったせいで手戻りしたものです。逆に言えば、着手前の打ち合わせで潰せるものばかりでもあります。業務システムは、作り始める前にかなりの部分が決まってしまいます。要件定義に時間をかけるのは遠回りに見えて、いちばん短い道でした。
紙やExcelで回している業務をシステムに置き換えたい、けれど何から手をつければいいか分からない。そういう段階のご相談も承っています。要件が固まっていない状態で問題ありません。まずはお話を聞かせてください。