黒柴の来歴　その１２

管理職としてのお仕事　その３

前回からの続きになるが、この稼働時間問題の発覚したプロジェクトは、すごいトラブルJOBだった
内容は、大手メーカーが請け負った通信インフラ企業の勘定系基盤開発について、実装を担当するというものだった
当時はIBM互換機系のCOBOLシステムがスペックとしても強く、金融系などで高速、かつ高信頼性が要求されるシステムは、ほとんどIBM互換機＋COBOLで組まれていた
このシステムも、中核はIBM互換機を使用していたが、それに加えてPCサーバ＋ORACLEによる分散システムをとっていた

要求されているのは、通信（電話）ごとに発生する課金情報を、利用者単位で集計するというもので、これを日次で処理する（当日分の課金情報を翌日に集計する）
この集計のアーキテクチャは、当日発生したすべての課金情報を4台のPCサーバ＋ORACLEに分散し、まずORACLEでソートさせる
そして、ソートした結果をIBM互換機に取り込んで、名寄せしながら集計するというものだった

ダミーデータでのテストも終わり、実データを使用してのテストとなった
ところで問題が発生した
1日分の実データを投入して処理したところ、なんと24時間で集計処理が終わらないことが判明した
機器は1セット（IBM互換機1台＋PCサーバ4台）しかないため、当日の集計が翌日中に終了しないと、翌日分の集計を翌々日から開始できない
そのため、集計処理の遅れが蓄積していくことが明らかになった

集計のアーキテクチャは大手メーカー側のアーキテクトが設計したもので、自社はそれに従って実装をおこなったとのことだった
この性能問題以前にも、このプロジェクトはいろいろと問題を抱えていたようだった
「ようだった」というのは、もともとこのプロジェクトの管理をしていたグループのマネージャが退職してしまい、黒柴がこのプロジェクトの管理を押し付けられたからだった
しかも、前任者の退職後にプロジェクトを押し付けられたため、引継ぎなども一切なく、仕方ないので現場でヒアリングに行った

しかし、現場の開発リーダーも、すでに休みがちになっており、当時はそういう考え方もできなかったが、いわゆる「うつ」だったのだと思う
仕方ないので、中堅以上のエンジニアを何名か捉まえてヒアリングを行った
結果として惨憺たるもので、現場としてはすでに2次開発というフェーズに入っていたのだが、1次開発の時点で仕様変更が頻発し、実装側としては仕様変更の対応をやってもやっても終わらないという状態になり、疲弊したエンジニアたちは1次開発終了時点でかなり退職したとのことだった（前任のマネージャのそのうちの1名だった）

自分よりも1～2年先輩のベテランエンジニアも数名いて、その人たちからもプロジェクトの内容のひどさと、このプロジェクトからの早期の撤退を要望されるありさまだった
（長くなったので、その１３へ）