黒柴的パンセ　#39

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

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

「そういう性格だから、謝れない」
これは、自社の後輩社員M（女性）からの言葉である。
この話しは、パンセ#38でも取り上げたプロジェクトに関連したころである。

パンセ＃38でも述べたように、このシステムは1'stリリースのころから関わっており、このときはハード更改と合わせて、大きくシステムを見直したいと複数の追加要件があがっていた。
このシステムは、全国規模の支店を持つ企業のカスタマーサポートセンター（CSC）のシステムで、支店が受け付ける問い合わせを全て一旦CSCで受け付け、全社資料を確認して回答できるものは回答し、支店個別の対応が必要な場合は支店側に問い合わせをエスカレーションするというシステムだった。

黒柴は主に問い合わせ管理の機能を担当していたが、MはCSCが受け付けた問い合わせを集計する運用レポートを担当していた。
システム更改前までは、このシステムはテスト的な運用を行っており、一部支店のみを対象としていたが、テストの結果が良かったということで、全国展開し、企業が抱えるすべての支店を収容することになった。
このとき、運用レポートも各支店の責任者、および支店を地域ごとに管理する統轄マネージャにも閲覧できるようにして欲しいという要望が上がっていた。
ちなみにこの企業は、かなり支店の多い企業で、統轄も東日本、西日本の下に、各地方（東北地方、北関東など）があり、その下に都道府県、さらに支店という感じで4階層になっていた。

1'stリリース時は、この運用レポートは要件に上がっておらず、2'nd以降の機能追加で実装されていた。
また、上記したようにテスト的な運用を続けていたため、運用レポートはCSC側で一括して出力し、収容している各支店、統轄マネージャに配布することを行っていた。（それくらい更改前までは配布対象が少なかった）
そんなこともあり、このレポートは各支店のデータを入力された条件（階層）によって都度プログラム内で集計するという、暫定的な仕様で実装されていた。
さほど支店数は多くないといったが、当時はまだOS、JVMともに32bitであったため、最上位階層の集計を行うと使用メモリ量がかなり増加してしまい、結果として同時に3接続以上で運用レポートの出力を行うと、JVMがダウンした。同時に複数端末でレポートを表示しないというのは、運用上の制限としていたが、CSCの担当者のみが運用レポートを使用するため、これは容認されていた。

このような実装をされていた運用レポートを全国展開し、かつ多数の支店、統轄マネージャから閲覧できるようにするためには、大幅な設計変更が必要なはずである。しかし、Mは実装方式は現行踏襲とし、増加した運用レポート種別を製造するという体で見積もりを作成し、この見積もりが発注元で承認されて自社に発注された。

結果として、設計を始めた際にこの不備は課題として指摘され、設計の大幅な見直しを迫られた。
しかし、見積もりを提示し承認され発注をもらっている以上、「設計変更しますから、開発費を増額してください」と発注元には言えなかった。
対策として、黒柴が担当してた問い合わせ管理機能側で持っていたリスク対応分の費用を吐き出し、かつ問い合わせ管理機能の見直しで実装しようと思っていた技術的な取り組みも諦めざるを得なかった。
最終的には、大きなトラブルになることを回避し、リリースにはこぎつけたのだが、見積もり作成時に社内で承認された目標粗利を大きく下回ることになり、黒柴のプロジェクトリーダーとしての評価もマイナスになった。

振り返りのミーティングで、見積もりの件にも触れたのだが、Mは冒頭のように「確かに見積もりには問題があった。でも自分は性格だから、謝れない。」と言い切った。
まあ、彼女は確かに社内では「気が強い女性」ということで認識されていた。
でも、結果として多くの人に迷惑をかけ、黒柴の評価を下げることにつながった要因について、性格を理由に謝罪したくないというのは、どうなんだろうなと思う。

パンセ＃38で取り上げた別件は、上記のような次第である。
黒柴は今でも「性格」を理由にする人は大嫌いである。