要件定義は技術者だけがするものじゃない

落差激しいかもしれないけど、要件定義というものの話をしたい。

システムエンジニアだとかプログラマーだとか、そういう人達はよく聞くだろうし、要件定義という言葉を聞いて『システム系の話？』みたいになる人もいるだろうけど、違います。

これはどちらかというと『目標設定』の話であり、求める結果に至るプロセスの特定の話であり、プロセス特定の為に何をどう詰めていくのか、という話になる。

前に別記事を書いた時に使わせてもらった『数値化』の具体的手段としてプロセスを仕分けていく話があったけど、感覚的にはアレの延長線上にあるものと言える。

まぁ長々書くと面倒なので、私の考える要件定義とは下記の流れにそって定義付けされてます。
①目標の設定（大概が乱暴に言って問題解消と結び付けられる）
②目標達成に必要なプロセスを仮定
③プロセスを仕分ける（自分の力だけでなし得る部分と他者の力が必要な部分を分けるとか、そういう事をする部分）
④プロセスを構成する要素を網羅する（何が必須なのか、何があった方が良いのかを判定する前段階）

やる事って、大分端折ってるけどこんな感じで仮定されます。

……で、うっすらと（どころか割とあからさまに）予感出来てる人もいそうですが、本来この要件定義というのは戦略側、経営サイドで詰められるべき話になります。
個人事業主出ない限り、戦術単位よりも更に小さい単位、私のような一兵単位には本来は縁のない話になります（社員も経営者視点が必要だ！　と無思考に説く人には理解されなさそうですね）。

理由はごくシンプルに、『裁量権』の問題です。

大概の組織にある事ですが、末端の一兵の持つ裁量権など高が知れてます。
事によれば最終決定権者が組織の上流に昇って行ってしまうので、どうしても時間かかるし、間に多くの人（いわゆる上長）が入ると伝言ゲーム形式になって元々の意図が伝わりづらくなる事が問題になります。
あとはどうなるかは想像に硬くないかと……故にトップダウンが良いものとは言いませんが、本来要件定義は最低でも戦術単位（部門管理職）以上、組織によっては戦略単位（複数部門統括管理職）で策定されるのが、スピード感的には望ましくあります。
ボトムアップ式がキチンと体を成している組織はこの限りじゃないですよ、勿論。

では何でこの話をしているかというと、この要件定義は『それでも誰しもに必要な考え』になるからです。
便宜上『要件定義』と言ってますが、これって結局『目標』を決めて、『逆説的に分解して』、『どう進めるか』を決める行為。

はい、普通に働いてたら誰しもがする事なんです。
※自分は十全に出来てます、なんて大きな事は言えませんが。

出来はどうあれ誰しもやる、それを何で書いたかというと、この要件定義が必要な話を（建前上）偉い人とした時に言われたんですよ。
ちなみに割と重大な内容についてであり、下手すると組織の拡大の仕方に大ダメージ入れかねない話たったんですが。

〇〇さん（責任を負わされない非正規雇用の人）と業者依頼する場合の要件定義詰めて、見積とか業者選定やっておいてと。

いやまぁ、何処の会社でも起きてる事さって言われたらそうかもしれないですけど、
こういう事平気で言われるとやっぱり思う訳ですよ。

戦略サイドが組織のあちこちに深刻な影響をもたらす要件定義を、軽々しく裁量の無い末端に放り投げる辺りで、組織の未来が暗いなぁって。

あ、ちなみに今回の件はとあるトラブルシューティングが深刻な展開になったが故にやってるんですけど……現場を理解しない人には多分『大した事無い』ように見えてるんですかね。

愚痴っぽくなりましたが、要件定義って別にシステム絡みの人じゃなくても、すげー大事なんだって言いたかっただけの記事です。

やっぱりスマホで打つとやり辛いな、キーボード欲しくなる。