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

◆ SEあるある「やり方が揃ってない」

必要な文書が用意されていないだけでなく

他にも揃っていないものがあります。

それは、「やり方・作り方」です。

 

たとえば、

説明文書の書き方

プログラムコードの書き方

テスト（検証）作業のやり方

 

人によって、

文章の書きぶり等が多少異なるのは

どうしようもない事ですが、

 

同じ事を説明しているのに、

違う名称で表現されていたり

とても詳細に記述されているところもあれば

とてもあっさりした簡潔なものまで

本当に様々です。

 

プログラムも長い間、保守され続けているものは

担当した人が異なるため、

書きぶりが全然違うロジックが継ぎ足されて

読みづらさ抜群のものもあります。

 

テスト（検証）作業にも

同じような事があります。

同じ目的のテストをしているはずなのに、

前回はここまで詳細にやっているのに

前々回は簡単なテストしかやっていない

 

その時のもろもろの背景まで

しっかりと記録されていないので、

今回はどのレベルまでテストすればわからない

なんて事もよくあります。

 

「これとこれは同じ意味？」

「どっちを参考にすればいいの？」

「今回はどこまでやるの？」

 

◆ 最善と最適は別物であると考える

その時々で、やり方や考え方が

変わってしまう事は、どうしようもありません。

 

顧客側の予算の都合

緊急度の高いスケジュール

エンジニアのスキルレベル

 

いろいろな条件や制約があって

その時のやり方が決まっています。

 

過去のやり方で

「これはないだろう～？」という

ものがあっても、

その時の制約からすれば、その方法が

最適な選択だったことも十分にありえます。

 

過去のやリ方について、

その判断の是非を考えてもしょうがない

でも、ここで気に留めておきたい事

それは、

「最善」と「最適」は違う

ということです。

 

そのやり方が、

条件や制約があってのものであれば、

それはその時の「最適」な方法ではありますが、

「最善」とは限りません。

 

ここを理解しておかないと、

この次に同じようなケースがあった時に

今度は制約が無いにも関わらず

「最善」を考えないまま、

また同じやり方を選択してしまいます。

 

このシチュエーションが一番多くあるのが

作業見積もりの時です。

その時は、前回対応時の状況などを

あまりよく考えずに判断してしまいます。

でも、後になってから、

他に「最善」の方法がある事に気がつきます。

 

顧客やリーダーの判断に従いつつ、

過去の情報なども探り、

それをつなぎ合わせながら、

完成 形をイメージし、

作業を完遂させなければならないＳＥは

本当に大変です。

 

過去の「やり方が揃っていない」ことで、

いろいろと苦労させられますが、

「最善」と「最適」を混同せずに

周りに振り回されないように

やっていきましょう。