皆さん、こんばんわ。Sierおじさんです。
今日はとてつもない台風が関東を直撃するということで
家から出られないため、こうしてブログを書こうと思います。
今回のお題は
「要件定義、どうしたらええねん？」
です。
SierやITコンサルのように、システム開発の上流工程に関わる機会の多い方なら
ある程度は経験があるだろう要件定義。
一方で、いまいちやり方が確立されておらず、先人の秘伝のタレみたいな
経験則から学んだりする要件定義。
かくいう私も体系的に要件定義を学んだか？と言われると
そんなこともなく、経験から得たノウハウが圧倒的なわけですが
その中でも比較的シンプルで、分かりやすいポイント3点を
紹介してみようかなと思います。
①理由を問う！
物事には本来はなんでも理由があります。
要件定義をしていても、あらゆる局面で理由を聞くことはあるでしょう。
「XXXだから、この作業が必要」
「YYYだから、この順序で作業しなきゃいけない」
などなど。
にも関わらず、意外と忘れがちになっていませんか？
「ユーザーが言ったから正しい」
「ユーザーの要件通りになっている」
こんなこと、言っていたりしませんか？
これでも別に悪いことではありません。要望通りだし。
ただ、ユーザーだって人間なので
自分の考えや意見の間違いに気づいたり、もっといい案が浮かんだり・・・
いろんな迷いが生まれます。
そんなとき、私たちが理由を把握していれば
「この業務はXXXのために実施していると伺っているので、
必ずシステム化しなきゃいけないはずですよ」
「この業務は後続作業のYYYのために実施していると伺っているので、
システム化した後でもこのタイミングでの実行が必要ですよ」
みたいな、ユーザーの迷いを断ち切れるコメントができるわけです。
もっと言うと、そもそも理由がよく分からないような業務なら
「そもそもシステム化することも、今の業務も、やめちゃいません？」
なんてことも言えるわけです。
結果として、確度の高い要件定義になるわけですね、はい。
理由、ちゃんと聞いていきましょう。
②現場とマネジメントの両方に問う！
要件定義をしてみると、いろんな立場の方と接すると思います。
一大組織の上層部みたいな方もいれば、現場で業務を遂行する方もいたり。
話してみると、立ち位置によって考えることって結構違うんですよね。
例えば、
＜現場＞
・自分の作業が効率的にできるようにしたい
・自分の作業が間違いなくできるようにしたい
等
＜マネジメント＞
・なるべく業務をなくしたい（＝人件費を削減したい）
・組織を越えて横展開できるようなシステムにしたい
等
みたいな感じです。
これはどちらも間違っているわけではなくて、
それぞれの立場で抱えているミッションが違うんだから
当然なんですよね。
この前提を知らぬまま、どちらかの立場に完全に振り切った要件定義を
してしまうと、後になって
「システム使いやすいけど、これそもそも無くせなかったのか？」
「横展開できるくらいシンプルだけど、使い勝手いまいちじゃない？」
みたいな、なんとも微妙な評価をされたりするわけです。
後でこんなことを言われることの無いよう、
要件定義はそれぞれの立場の意見をまず聞きましょう。
そのうえで、相反する意見については、どちらにどこまで歩み寄るか？を
関係者間でしっかりと合意しましょう。
「部長さん、この業務はXXXなので廃止にはできないけど、
現場の作業工数ができるだけ削減できるようYYYにしますよ」
「現場のZZZさん、この業務で使うシステムは他部署の利用も想定して
こんなイメージで考えているけど、できることは今と原則変えないよ」
などなど。
現場とマネジメントそれぞれの意見、ちゃんと聞いていきましょう。
③効果を問う！
これはですね、開発する側からすると直接的には影響しない話なので
気にしたこと無い人もいるかもしれません。
ただですね、ユーザーがシステム開発を発注するということは
必ず前提として何らかの効果が期待されているはずです。
（法改正みたいな、対応Mustのシステム化は別ですが）
「この業務が早く終了するようにしたい！」
「この業務が効率的に実施できるようにしたい！」
「この業務で間違いが起きないようにしたい！」
などなど。
先ほども書きましたが、ユーザーはいろんなところで迷うし、
いろんな意見がでてきます。
そんなときでも、期待効果を把握したうえで要件定義に挑めば、
「今回はXXXという効果を期待しているなら、
ここは完全にシステム化するべきですよ」
「今回はYYYという効果を期待しているなら、
ここは最低限の開発にとどめるべきですよ」
なんてコメントができるわけです。
先ほどと同様、ユーザーの迷いを断ち切れるわけですね。
期待効果、ちゃんと聞いていきましょう。
いかがでしたでしょうか。
細かいノウハウを言い出すともっといろいろありますが、
今回は比較的すぐに取り入れることのできる
シンプルな3点を紹介させていただきました。
（もっと作業的なノウハウはまた別に紹介します）
総じて言えるのは、要件定義とは
いかにユーザーの迷いをなくせるか？
に尽きると思います。
「あー、また要件変わったよ。。。なんなんだよ。。。」
「あー、全然要件決めてくれないよ。。。なんなんだよ。。。」
なんて悩みを抱えた方が、少しでも楽になれば幸いです。
以上、Sierおじさんでした。
