業務を作るのに仔細なレベルまで詰めてはいけない

いきなり仔細を出されても
顧客の業務をシステム化を担当することになったり、所属する組織の業務を改革する担当になったとき、システムエンジニアをアサインすると、とても細かな、仔細なところまで検討し、パワポを作っていることが往々にして見受けられる。
実際、ここ数ヶ月見ているのでアレだ、どうしたものかと、手をこまねいている。
その資料を見る度に、プリミティブなところまで書き込んでいるので、イメージあわせで違和感ばかりが先走る。

ステークホルダはちゃぶ台をひっくり返す
ものごと、特に日常の人の行動を制する業務を決めるのだから、ステークホルダは多くなるのだ。それを踏まえて、いればいきなり仔細なことまで書き始めると、最後になってちゃぶ台をひっくり返されるのは明白なのです。
はい、経験的にも。

DFDやユースケースが3段階くらいのレベルで書くのは、人とシステムが遣り取りするデータを明らかにするのは勿論だけれど、そこに関わる人を炙り出すことも目的のひとつなのではないか。
＃そう思っているけれど、どんなもんです？

業務は人、人の所属する組織を明らかにする必要があるのは、所掌があるからであって、分担する役割で責を負うからで。

仔細に、プリミティブなことをはじめからやってしまうと、その観点がスッポリ抜けて進んでしまうので、後から出てくる上役のロールの人に簡単にひっくり返されてしまうのだ。

で、やり直し、と。

作った人は、仔細を書き込んでいるから、その資料に思い込みはあるし、思い込みがあるから未練タラタラですね。それは捨てられないだろうから、時間が余計に掛かるし、もともとブレークダウンしていこう、と思っていれば、そんなアプローチはしないんだけれど。

要求を見抜けない
物事の決めていくやり方を経験していると、そのあたりは経験から自然とわかるものだと思うのだけれど、そうでもないんだ。なぜだろうと考えてみた。
多分、仔細に、プリミティブに考えるのは、とても具体的で、そう、プログラム仕様を書くような体験に近いから、楽しいのではないかな。そんなことを思いあたる。ああそうか、やはり自分が戦えるフィールドで戦いたいんだな。求められているところではなくて。それは、期待にこたえられていないのに。
それって、

「顧客が要求すること、やりたいことを見抜けない」

、ということではないのか。そうか、そういうことなのだ。