「おんなじにして！」に見るリスク管理

上司「機能Ａを元に機能Ｂを作って。おんなじでいいから。すぐ済むでしょ。」

頭を悩ませるざっくり指示の一つだ。

「おんなじでいい」なら「同じものを使えば良い」

と言いたい所だが、

「同じような別のもの」。

まぁ、「同じもの」と言いたくなる気持ちは分かる。

今回問題に挙げたのは、

「コピーして修正」なんてレヴェルのものではなく、

「蓋を開ければ再構築」レヴェルだったから。

知っているからの「おんなじもの」扱い

上司から見る機能Ａと機能Ｂは

「同じようなデータをもってきて」

「同じように加工して」

「同じような印刷を行う」

ものだ。

あくまで「同じような」であって「同じ」ではない。

「同じではない」部分が少ないのだから

頭の中ではほぼ同じ。

確かに「同じようなもの」

知らないから「別のもの」扱い

担当者からすれば、

「あるデータを持ってきて」

「どの様に加工して」

「どんな風に印刷を行う」

だ。

あたりまえだが、

元があろうがなかろうが

作る以上「どの様に動く」を確定させないといけない。

「修正部分だけしかテストしません。」

なんて客に許可を取らない限り通用しない。

「知ってる」と「知らない」を近づける

上司と担当者の一番の違いは「手間」だ。

上司にあって担当者に無い作業。

「おんなじような部分の確認作業」

この手間をなくせば、担当者も上司と同様に

「おんなじではない部分」を中心に考えられる。

解決策は？

多少いまさら感はあるものの

やはりテストの手間を減らすのが一番だ。

今や自動テストのツールは悩むほどある。

Windowsシステムで簡単にプロジェクト構成が変えられないなら、

PowerShellでやってもいい。

「おんなじように」が出た時に、

「自動テストの恩恵」と言うプラスのリスクを取るか、

「次回同じコストが出る」と言うマイナスのリスクを取るか、

マネージメントの腕の見せ所だと思う。

まぁ、自動テストを導入しようとして苦虫扱い受けてるからこそ出した話。

ごめんね上司。

だっておんなじこと何回もやるの嫌でしょ。