ＳＥの経験が与えてくれた能力

家業を嫌ってサラリーマンをしていた頃、私はシステムエンジニアでした。
手前味噌ですが、馬鹿がつくぐらい真面目に働いていましたね。
殆ど休んだ事も有りません。たまの休みも仕事の事ばかり考えていました。

正直なところは必死だったのです。

親に逆らい、大学の教授の推薦で入った会社を勝手に辞めて、ソフトハウスに転職してしまいましたから失敗は許されなかったし、派遣先である三井物産関連の会社には「スキル有り」って事になってましたし、担当した業務は三井物産の本部関連のシステムで尚且つ特殊なシステムだったもので少人数のグループでしたから、一人が背負う責任は非常に重かったのです。

開発部署ではなく、運用がメインの部署でしたが、その分、エンドユーザーと密接な関わりを持ちながら、基幹システムの保守・運用をしながらサブシステムの開発などをしておりました。

そんな部署でしたから、求められる能力はプログラマーとか、エンジニアと言うよりもアナリストだったのです。

残念ながら、胸を張ってアナリストと言える程には自分は成れませんでしたが、随分と勉強しました。

ユーザーからヒヤリングをしてプロポーザル、要求定義書の作成、システム仕様書へのブレイクダウン。そしてプログラム仕様書、フローチャートの作成して部下にプログラムを作らせる。
そんな事を毎日のようにしてました。

ユーザーのヒヤリングやプロポーザルを作るなんて仕事は本来経験豊富な上級エンジニアつまりアナリストの仕事なのですが、派遣先のグループの上司の好意で早いうちから参加させてもらっていたのです。

そんな経験で学んだ事は「仕様書の隙間読み」の重要性です。
この「仕様書の隙間読み」とは、アナリストを目指した人なら必ず知っている言葉です。
文書と文書の隙間、つまり行間にこそ重要な事が隠されているのです。

ユーザーは自分の欲しい結果をすべて伝えきれるものではない。
ヒヤリングをした者がユーザーの要求をすべて汲み取れるとは限らない。

この事から、システム仕様書を作成する者は要求定義書の隙間、プログラム仕様書を作成する者はシステム仕様書の隙間に有る書かれていないものを読み取れる能力を求められるのです。

またまた手前味噌ですが、同じ職場のエンジニアの中でもずば抜けてその能力が有ったと思います。

初めてご葬儀の打ち合わせに行った時、それが「隙間だらけの要求書」である事に気が付きました。

大切な方を亡くして気が動転してる中でお打ち合わせをするのですから当然です。

葬儀担当もこの隙間をどれだけ読み取るかを求められているのだ知りました。

時代の風潮で、翌日にはお通夜、翌々日には告別式などと気忙しく施工しようとしますから尚更です。

もしも、事情が許すなら、せめて１日だけでも日を置くことによって、ユーザーの要求定義書の隙間はかなり埋まると思うのですが、なかなかそうもいかないようで、葬儀担当に求められる能力は非常に高いのです。

もちろん、それだけ真剣に葬儀に取り組んでいればですが・・・

だから、私は「言われてない。」「聞いてない。」と言う言い訳をする人間を許さないし、大嫌いです。

「言われてない。」のでは無く、「言ってもらえなかった」あなたが悪いのです。
「聞いてない。」のでは無く、「聞く能力が無かった」あなたが悪いのです。

葬儀の担当者は、そんな言い訳は絶対に通用しないのです。