黒柴的パンセ　#18

黒柴が経験した中小ソフトハウスでの出来事 #8

ここでは、中小ソフトハウスで勤務していく中で、起こったこと、その時何を考え、また今は何を考えているかを述べていく

「不要なところで、建前論を言う人」
これは、自社のセクションマネージャDのことである

発端は、あるプロジェクトで後輩Tに、実装の改善について話していたときだった
JavaEEによるWebアプリの開発だったが、当時はまだ著名なFrameworkが整備されておらず、自社で開発した簡単な共通処理を使用していた

その共通処理が、CSV形式のファイルをDBのテーブルに登録する、loader的な機能を持っていた
ただ、簡易な実装だったため、CSV形式で用意されたファイルをテーブルに登録するだけの機能となっており、細かな制御はできなかった
データを登録する対象のテーブルは、マスタデータ系のテーブルだったが、管理する値の他に登録ユーザ、登録日、更新日などのカラムも用意されていた

勘の良い諸兄なら、オチは読めていると思う
Web画面経由でのデータの登録・更新では、ユーザ、登録日、更新日の情報は、システムが登録するため画面上から入力しない
しかし、loader機能は簡易だったため、本来システムが登録するデータまで、CSVファイル側で設定する必要があった
そのため、CSVファイルの登録日、更新日の設定を誤ると、作業日当日ではなく、過去や未来の日付でデータが登録されてしまった

画面とloaderの登録仕様が異なるので、loaderの機能を画面側に合わせるために、どのような対処ができるか？ということを、後輩Tと話をしていた
ただ、この後輩Tは、早い話がめんどくさがりなのだ
そのため、黒柴と話しているloaderの改修について、とにかく「やりたくない」という態度で会話を続けてくる
そこで、たまたま近くを通りかかったマネージャDに、「画面とloaderの仕様が異なるので、対処が必要と考えるが、どう思うか？」と質問してみた
もちろん、黒柴はプログラムの改修が必要であることを、きちんと説明・指示してくれることを期待していた

しかし、マネージャDは

• 改修実施の可否については、対応工数とスケジュールへの影響を確認する必要がある

• 対応工数が過大になり、スケジュールに著しく影響が出るなら、実施しないという選択肢もある

• 実施しない場合、運用で対処可能か確認する

というような感じで、建前的な回答をしてきた
めんどくさがりで、この改修に着手したくないと思っていた後輩Tは、マネージャDの話に食いついた
改修が過大な工数になること（ただし、対応案の検討すらしていないので、工数の見積もりもしていない）、現状でも運用は問題なく出来ること（登録日、更新日をCSVファイル内に設定する）から、対応は不要とその場で宣言した
なぜか、マネージャDも後輩Tの判断を満足そうに肯定して、この件は対応しないことに決まった
黒柴としてしては、「なぜ、マネージャDは、もっともらしい建前論をここで言うのだろうか？」と、もやっとした
ただ、このマネージャDは、こういう人なのだと、あとあと知ることになる

諸兄らの周りにも、課題の本質を判断せず、いらないところで建前論に終始する人は居ないだろうか？

この件については余談がある
余談１：
マネージャDは、後輩Tの人事考課を行う立場だった
プロジェクト終了後にマネージャDに後輩Tの考課を尋ねたが、「積極的な行動をとらないから評価できない」と、マイナス査定をしたそうだ
考課対象は上記の件だけではないが、逃げる気満々の後輩Tに逃げ道を示して、結果として逃げたから評価できないというのはどうなのか？と、このときももやっとした

余談２：
このプロジェクトは、上記開発以降も1年ごとに改修・機能追加がある長期開発となった
数年後に、この運用回避は「使いづらい」とエンドユーザから正式に指摘され、改修課題とになった
そのとき、参画していた協力会社のエンジニアに、改修案を相談した
その方は優秀なエンジニアで、簡単な設定ファイルによる改修を、設計-実装-テストについて3人日弱で完了させた
ちなみに、後輩Tに指示した時は、5人日程度なら全体スケジュールに影響が出ないことを確認しており、3人日なら十分対応可能だったことになる