あの日聞いた業務の要件を出すことの大変さを僕達はまだ知らない

on

これまでずっとプロジェクトでシステムを作る側の役割ばかりしてきたのでシステムを作る側の都合や苦労は実感していたわけです。ところがひょんなことからというか、機会があって要件を出す側になってみたらこれはこれで結構大変でして。


ブログで気にしているからかもしれないけれど、システムを作る側のエンジニアのあれこれは沢山記事がポストされているけれど、要件を出す側の記事はそれほど見かけない気がマンモスするので要件を出す側の気持ちを共有できれば。


それは日々の業務を楽にしたいということからはじまった
今の位置づけは他にある仕事に“アドオン”して追加されてしまった業務でまぁなんで自分の仕事を増やしてまでそれを拾ったかと聞かれれば、「他の人にやらせると碌なことがないゾ。」と神のお告げがあったから、と言いようしかないのですよ。


一緒に仕事をしている人も含め、今やっている仕事に日頃から疑問を持たないと言うかその仕事のやり方が正しいのかを疑ってかからないんですね。例えば前任者から引き継いだものになぜその情報を記録しなければならないのか、とか、そういったことなんですが。そんな人たちに要件、システム化するのだからシステム要件のインプットとなる業務要件を出させれば、「あったらいいかも！」くらいの本当に必要な情報かどうかも分からないで、それを保持することで得られる価値なんて考えずにあれこれと詰め込みそうだったから、ですねぇ。それである意味足を踏み外したかもしれないんですけどねぇ。


で、とある業務があってそれを疑問に思わず延々と手で作業している。その作業には繰り返す作業があるのですよ。そういった繰り返す作業で且つその繰り返す作業から価値を生まない作業をすることがとても嫌なんです。価値を生まない作業なら単価の安い人を雇ってやればいい。単価が高い人たちは、その高い単価を上回る価値のある仕事をしないといけない、そう思っているんで。その上、その繰り返し作業が割と面倒だってこともあって。


で、「ちょっとしたWebシステムを作りませんか。」って言ってしまったんですよ。はいその瞬間が、プロダクトオーナが決定した瞬間でした。


業務要件を出すことのどこが大変かと言えば
システム化要件に落とすためのインプットとなる業務要件を出すにはその業務をやっている人に要件を出してもらわないと要件が落ちることになります。まぁ、当たり前ですね。


で、システム化する側から見ればカウンタになるお客さん、この話の上ではワタシが業務を出さなければならないわけです。システムを作る側から見たワタシが業務のフォーカルポイントになるわけです。システムを作る側から見たらワタシが業務のすべて。業務の代表。「ほら、さっさと業務要件を出せ！」となるわけです。


でも、実際は違うんです。業務はその人(ここではワタシ)だけでやっているわけではないのです。その業務を組織全体でやっているとしても、その配下の組織ごとで好き勝手な家風でアレンジをしていることなんてザラです。たとえ作業標準を決めていたとしてもそのやり方は配下の組織単位ごとにバラバラ。実際にその業務をやる人それぞれに工夫してしまうんだから。


一言で業務と言っても、実は似て非なる業務をしているかもしれないということです。組織vsワタシvsシステム作る人の構図になっているんですよ。


その構図の上で、業務要件を出さないといけないんです。


組織の業務をシステム化することは内から後ろから刺されまくるかもしれない危険と隣り合わせ
組織vsワタシvsシステム作る人の構図の上で、業務要件を本筋を外さない程度に拾ったうえで業務要件を出すことはそれなりのポイントを押さえて“組織vsワタシ”の組織にシステム化の主旨と組織の側から要件をインタビューしておいて十分伺いましたという既成事実を作っておくことがポイントです。その上で、インタビューした組織の偉い人たちに協力をいただけると言質を取っておくことがとても大事なんですねぇ。


言い換えればコンセンサスをとってというか、十分根回しをしておかないとあとから要件を追加されたり、最悪ひっくり返されたりして後ろから横から刺されるかもしれないリスクがあるんですね。


システムを作る側の人には、そこはわからない世界です。だって知らないんだもん。


それは業務を出す側の問題ですけれど。そうした環境の中で業務要件を整理しているということが背景にあるからフォーカルポイントの人がそれをコントロールしきれなかったらバンバン要件が追加になるとか、変わるとかという事象でシステム側に見えるんだ、ということを知っておいてほしいのです。


だからそれを知ってその変わった要件に対応してほしいということではなく、そうなるかもしれないということを知って入ればシステムを作る側の人もそれを予測して対策を立てておくことができるでしょうから、そうした心持でいて業務要件を出す人をうまくコントロールしてあげることが巡り巡ってシステム側の手戻りを最小限にする方向に働くということを知っていてほしいのです。