システムエンジニアは根拠を示さなければならない

最近、常々自分の仕事をしているときに、「根拠が分かるように資料をまとめよう」ということです。その「根拠」とは、自らが情報を整理して、やりたいこと（＝要件）に合わせて変換する作業を成果としてプレゼンスを与える際に

「こういった考えに基づいて処理されているんですよ」

ということが分かるようにしようというものです。

言い方を変えれば、考え方の方針、軸と称しても良いです。単にそれを視覚化しよう、という単純なことです。

なぜ、根拠を示すのかというと、これからなそうとしていることを関係者で議論して意思決定するプロセスを踏む場合、目的は議論から結論を得ることです。その近道を考えるとワタシの資料を理解してもらうところに時間をかけていたら早々に時間切れとなって肝心の議論と意思決定に到達しないからです。

プロジェクトでの資料を見ていると、いや、定常的な資料でも同じですが、資料の理解だけで時間がかかってしまい、肝心の目的に到達する前にリジェクトされているようなでき倍で持ってきたりするケースが割合見受けられます。

これ、定常的な作業の資料でも同じで、なんらかの標準プロセスのための資料なのに、出来映えが悪く、かえって質問が増えて資料の発信者に問い合わせの仕事が増える、なんて見かけることがあります。

戻して、仕事なんて処理するのが目的なわけです。プログラムはそれを機械化しているだけの話です。乱暴に言えば、物理の機械は現物が目の前にあるので処理プロセスをみれば何をしているのかわかります（例えです）。

でも、ソフトウェアは実行モジュールになって実際に動く形式になると外からでは何をしているのかわかりませんし確かめようがないのです。あとはお祈りして待つだけ。

出来てから確かめるのでは困るので、作る前にどう作るかの根拠を示して間違った処理をしないようにしよう、と。そういうことです。