上流工程を担当するSEには行動基準を作れるスキルが必要なんですよ

上流工程、要件定義では業務フローがインプットの一つになるので確認することがありますが、なかなか顧客から出てこないケースがありますよね。終いにはデリバリーチームに作ってなんていい始める顧客もないわけでもない。まあ、こんな顧客は早々に切るか骨の髄までパックンっといただくつもりでないとお付き合いしきれませんが。

業務フローは誰の仕事か

どちらにしても業務があってそれを要件に沿って機械化するのがデリバリーチームのお仕事ですし、業務の主体は顧客ですから業務フローに可視化できるのは顧客です。

＃まあー現場の仕事もあってそこまでリソースが割けないからその可視化の部分を切り出してよ、という背景もあるのですけどね。コストが費用として貰えて、リソースも用意できるならやればいいですけど。

それ、現状の機械化でしかないのでは

で、誰が作るかは差し置くとして、業務を可視化（業務フロー図）して、それをシステム化するじゃないですか。で、プログラム作ってテストしてリリース、と。

でも、それって現状の業務を機械化しただけなんですよ。

一つ抜けているんですね。それはプロジェクトの目的の業務の課題です。その課題が生産性（作業スピードをあげてたくさん処理する）や正確性（正しいルールで繰り返すことでミスをしない）であれば、そうですね、機械化でオーケーなんですがそんなの昭和の時代に終わっていますよね。別のプロジェクト化した目的を考慮することが抜け亭rんですね。

ToBeをシステム化するのがプロジェクトの目的でしょ

そうすると現状の業務を可視化した業務フローから、目指す業務に変えなければならないことになります。その目指す業務を可視化してそれを検証し、システム化しなければプロジェクトの目的に到達できないんですよ。

新しい判断基準の必要性

そこで必要になるのが新しい業務、目指す業務での振る舞いの判断基準です。code of bookというかismというか。目指す業務を可視化して作業者が振る舞い、インプットする、操作するときの判定基準が必要になるんですね。

プログラムはルールですから、元となるルールがないとコード化できないです。書いたようにしか動かないし、書けなければコードにできない。

新しい判断基準を検証する必要性

目指す業務を誰が作るにしても、その目指す業務を理解して、コードに変換するのはシステムエンジニアなんですよ。で、目指す業務の業務フローを見たときに何に基づいているのかを理解し、システム的（データと処理）に合理性を持っているか検証できないと作っても使えない、間違った機械化をしてしまうお手伝いをしかねないんですね。

それはお互いに不幸だし、顧客としてはシステム化のプロフェッショナルに業務委託しているのですし、システムエンジニアとしてもプロとしての責務もあるのですよ。
＃イズム、ですね

結局、システムエンジニアも顧客が示す目指す業務の判断基準が正しいかを見抜ける技量、スキルが必要なるんですね。だって、そのスキルがなければシステム要件や方式、実現仕様として検証できませんから。