#11 - 協力会社の見積もりに対する挑戦

　IBMがOS/2というOSを懸命にプロモーションしている時、マイクロソフトは、Windows NTというサーバーに力を入れていました。今思えば、OS/2自体もマイクロソフトがIBMとともに開発していたOSでしたが、当時のMachineの能力は低く、高い理想を持ったOS/2を心地よく稼働させるには至っていなかったのではないでしょうか。少なくとも私はそう感じていました。当初マイクロソフトは、OS/2の開発推進の途中でWindowsを開発し、IBMと決別し世の中にOS/2より軽い、Windowsをリリースしました。結果的には、Server OSとしてのWindowsがDefact Standardの地位を築いていくことになります。クライアントOSも同様にWindowsが標準となりましたね。

　そのような背景の中、アメリカで標準的なパッケージとなっていたPower Builderという開発用ソフトウェアがありました。もちろん、Windows NT上で稼働するソフトウェアであり、クライアント・サーバー型のアプリケーション作成に特化したものでした。私が担当するお客様ではこのPower Builderを利用した部品の受け入れシステムを開発することになりました。受け入れた部品に対し、印刷したバーコードをシールにして貼り付けるという業務も付随していました。

　当初、私の所属する部門内にはPower BuilderのコーディングができるSEがいなかったため、協力会社に依頼することになりました。ちょっと高いなと思いましたが、選択肢はないのでそのまま発注し、無事開発も終了し、最初のサービスインとなりお客様内で運用が始まりました。運用後も保守があるため、協力会社の方にも残っていただき、対応依頼などを実施していました。非常にいい関係で協業していたと思います。保守料金もちょっと高いかなと思ったこと以外は。

　サービスインして数ヶ月が経過した時、お客様からシステム拡張の追加の発注が出ることになりました。最初と同様に協力会社に見積もりを依頼したところ、最初の新規開発より高い見積もり回答をもらってしまいました。当時PMとしてプロジェクトを担当していた私は見積もり根拠があるわけではありませんでしたが、追加機能開発に対して直感的に高すぎると感じたため、再見積もり依頼をすることにしました。

　もし、自分にスキルがあったらと仮定して見積もってみたところ、協力会社の見積もりの半分程度になりました。もちろん、確固たる根拠を示せないので、協力会社の担当者に再見積もりを依頼しましたが「修正は新規より難しいので料金は高くなります」と回答をもらいました。そこで思ったのは、「担当が代わるならまだしも、最初の開発を担当した人が実施するのになぜ?」という素朴な疑問が脳裏をかすめました。その後は、本来SEとしてやるべきでない行動をとってしまいました。

　まず、協力会社に対し、見積もりが見直せないなら今回の案件はなかったことにしてくださいと通知し、お客様に対しては、見積もり回答を後一週間待ってくださいとお願いし、了承していただきました。その直後、かなり焦って大きな本屋に行き、Power Builderによる開発の参考書を入手し、対応できるように最低限のスキル習得と見積もりを実施しました。本来であれば、正しい行動ではありませんが、どうしても納得が行かなかったのです。SEとしての変な正義感があったのかもしれません。

　若干の知識を得た後、協力会社のSEが作成してくれたソースにアクセスしてみたのですが、画面は真っ白で何も見えません。どうやら、複数の画面を重ねてコーディングしていたようで、開いた瞬間には何も表示しないように設定されていたようです。つまりはレイヤー構造を採用していて実行時にはそれらが重ね合わせられて画面に表示されるようになっており、利用者にはなんの問題もありませんでした。本来、この方法は、共通部品の作成を容易にしてくれるので非常に有用なのですが、開発画面において一番手前に表示される画面をブランクにしておくと開発ツールで画面を開いた瞬間は真っ白な画面が表示されることになるわけです。

　少し焦ったあと、なんとか解読することができましたが、コード自体が利用するものとバックアップ用が混在しており、保守しづらい状況になっていました。これは、Power Builderの特徴として、古いコードの後に別の名前で新しいコードを記述しておくと新しいコードの方が適用されるという機能を利用した結果でした。開発途中であればいいのですが、一旦本番として稼働するときには、旧バージョンのコードは全く別に記述しておくべきでしょう。混在していると保守性がかなり悪くなりますね。

これを紐解き、整理し、解りやすくした後、依頼された改善内容を反映し、お客様の要求を満たすシステムへと変更できました。振り返ってみると、私が見積もった金額以内で収まっていました。同時に、本番として定義したコードは、整理した成果もあり、元の半分以下になっていました。最初のシステムを作成する際に、複数のSEで作っていたので、その分、複雑化していたということと、自分の担当する開発コードを把握しやすいようにしていたのではないかと思います。

　この時は、信頼すべき内容と交渉すべき内容をしっかりと理解することの重要性を学びましたが、思い出せば、あまりにリスクが大きすぎる対応だったと反省しています。結果的に成功したので問題にはなりませんでしたが、一つ間違えればお客様に大きな迷惑をかけるところでしたので、リリースして一段落した後にほっとした事案でした。ただ、その後の保守はお客様でもなんとかできるようになったことは、挑戦してよかったと思ったことの一つです。

　お客様からリピートオーダーをいただいてビジネスを継続することは大変重要ですが、それ以前にお客様で担当できるのであれば、そのお手伝いを優先し、新しい分野への挑戦を率先して我々SEが先陣を切って開発していく方が、スキルも利益も得られることになります。またそれ以上に「信頼」も得られることになるので、目先の売り上げに囚われない対応は重要だと考えます。

　この時のもう一つの反省は、協力会社との間で本当の信頼関係を築くことができなかったということです。もし、もう少し議論してお互いが理解を深めていたら、結果は変わっていたのかもしれません。この経験の後は、初めて付き合うことになる協力会社のSEさんとは慎重に対応するようになりました。