このところかかりきりになっている測定装置の動作試験だが、今日は必要な機材を別の案件に貸し出すのでひとまず中断。かわりに気になるソフトウェアの不具合をデバッグ。
気になる箇所は、優先度の高いスレッド上で走るのでC++Builderでステップ実行させることができず、OutputDebugStringでデバック。何度もＯＳごと固まりながらもどうにか原因は突き止めた。データフローを制御するクラスでデータを渡す相手を指す配列インデックスの値が正しく更新されていない。このデータフロー制御クラスは、配列の要素を分配する役割を持つ。分配の方法が複数あり、それらを測定に合わせて切替える必要があるので、アダプターパターンを使って設計してある。
問題の原因は、微妙に異なる２通りの分配方法をひとつの具象クラスに分担させた事にある。新たに具象クラスを追加して、分配方法をクラスごとに分離やれば解決しそうな気がする。
受注も仕様も知らされないのにいつのまにやら責任者
と、こんなことを考えていたら、上長からお呼びがかかった。今期の査定と昇給＆ボーナスについての社長面談である。抜き打ちである。これまでは、いつも不意打ちをくらって言いたい事を言えなかったのだが、今年はこちらも心の準備をしてある。
結論から言うと、昇給は平均値(\2000)でボーナスは1.9ヶ月分(去年より0.1減)だそうだ。利益自体は去年と比べてそれほど変化していない*1らしいので、実質評価が下がったということになる。どうやら社長は、製品第３号が海外でトラぶったのがに食わなかったらしい。実はそのトラブルはソフトウェアとはあまり関係が無く、私が責められる言われはほとんど無い。
この案件がスムーズに行っていないのは、責任者が、装置の要求性能を甘く見た事と、まともなスケジューリングをしなかった事に大きな原因がある。責任者というのは今社長の横に座っている部長殿である。
まず、この装置の検収条件には、これまで見たこともないほど細かい項目がずらりと並んでいる*2。このような難しい案件の場合、実績のある設計で製造し、出荷前の手直しのための期間を長く取るのが当り前である。また、海外への輸送や出張の費用を抑えるために、社内での試験期間を十分に確保するのが当然である。
にもかかわらずこの部長殿は、全く実績の無い設計のまま製造し、時間が無いからと動作試験を一度もしないで出荷した。これで問題が起こらなければ奇跡に近い。
部長殿が強引に新しい設計を押し進めたのは、彼自身がその設計を主導したからだ。おそらく功を焦ったのだろう。その結果、納品の時に「ネジにぶつかってアームが動かせない」「輸送管が注入口に入らない」などという幼稚な設計ミスを晒してして、顧客を呆れさせることになった。
出荷前に動作試験の時間が無かった理由は、部長殿に管理能力が無いからとしか言いようが無い。製造担当者が本当に間に合うのかどうか心配して、彼に質問していたにも関わらず何の手も打たなかったのだから恐れ入る。どうやら彼には常に都合の良い幻を見ているようだ。その証拠に、唐突に「アレは出来てるよな？」などと質問する。言われた方はたいてい初耳である。この案件の時にも、出荷の数日前になって、「制御回路とコンピュータの手配はできてるか？」と私に聞いてきやがった。そもそもこの案件について私は、受注の連絡も仕様も知らされてさえいないのだ*3。
このようにして部長の無能の結実として、この案件は赤字となった。装置の手直しはいつまでも続き、それでも追いつかずに装置の中身をまるごと作り直すはめになった(多分一千万円ほどのロス))。装置の輸送（航空運賃、関税）。現地での手直し作業のために、数人の技術者が1〜2週間出張すること５、６回。
などなど。
会社としてこのような案件が初めてであるかと言うとそうでは無く。２年ほど前にも似たような海外向け案件があったが、当時の責任者の配慮のおかげでスムーズに納品を終えることができた。
