システムエンジニア悩み相談の専門家～目標設定コーチング、フレームワーク勉強会、交流会の企画開催

きっちりやろうとする事が仇となる

 

今回のコラムは

まったくもって当たり前の話から始まります。

 

SEの仕事は、ほぼ全ての案件で予算も納期も

作業開始前に予め決まっています。

PGMの作り方やテストの際のルール（標準）も

それにあたる作業員数も決まっています。

 

とにかく、ありとあらゆる事が

事前に決められていて、

SEはその事前の決定事項に従いながら

作業を進めていきます。

 

（これだけ、やり方や前提がガチガチに

決められているのに、肝心な

ユーザーの要件ははっきりしない・・・

という話は別の機会でするとして）

 

当たり前といえば、本当に当たり前の話です。

趣味でやっているわけではないし、

その作業の対価としてお金を貰っている

のだから、とりあえずやってみて、計画は

その後からという訳にはいきません。

 

しかし、この何でもきっちり決めて、

それに従うというやり方が、逆に仇となり

SEの成長はおろか、案件の成功確率すらも

下げてしまう事があります。

 

許されない「試しにやってみる」という感覚

 

１０年以上も前の話ですが、

昔は今のように、事前の「計画作り」が

ここまで重要視されていませんでした。

 

とりあえず、余裕を持ってスケジュールも

予算も決めて、ざっくりと段取りも決めていく

途中で予想外のことは起きるが、

多少余裕のあるスケジュールでやっているので

なんとかその中で対応が完了する。

これはうまくいった案件の例です。

 

一方でうまくいかない案件もありました。

予想外の事が起きたので対処した。

今度はまた違う問題が発覚したので対処した。

今度はその対処が原因で違う問題が発生した。

もぐら叩きとか、泥沼にはまったなんて

言われる案件のパターンがこれでした。

 

こういった案件があったせいで

より綿密な計画が必要という話が

日に日に強くなっていきました。

 

CMMIとかPMBOKとか、

新しい言葉も登場し、

昔のノリであった「試しにやってみよう」

なんて言葉を不用意に出そうものなら

めちゃめちゃ怒られる空気が生まれていました。

 

間違った事を言ってしまうくらいなら・・・

 

何にも考えずに、いきあたりばったりで対処して

ただ無為に時間、お金、労力を使うことは

褒められた事ではありません。

 

でも、そうは言っても、やっぱり、

「やってみないとわからない」

「やってみないと想像すらつかない」

なんて事態に遭遇する事は実際にあります。

 

ちゃんと調査してみないとわからない

実際に動かしてみないとわからない

 

限られた時間内に相手に返答しないと

いけないのは重々わかっているけれど

全てが即答できるはずもありません。

 

より大きな案件になればなるほど

間違った回答をして顧客をミスリード

してしまう事はあってはなりません。

 

そんな時、担当者からすれば、

やっぱり、「とりあえずやってみたい」

「答えはそれまで待って欲しい」と

思ってしまうのです。

 

次回につづきます。