「開発は問題解決の手段のひとつ」という言葉がある。自分はこの言葉が言い訳のように感じてあまり好きではないのだが、開発業務を始めた頃に強烈に意識させられる出来事があった。思い出話として雑に書いてみることにする。
新卒で部署に配属されて半年くらい経った頃、とあるバッチ処理に時間がかかって顧客の業務に影響が出そうということで自分が取り組むことになった。背景としては、「導入顧客の従業員数が来年度に5倍になる予定で、日次で回しているバッチが翌日までに終わらないことが見えている」とのことだった。
当時バッチの並列化基盤を開発している部署が立ち上がっていたこともあって、上司とともに連携してパフォーマンス改善に取り組むことにした。開発業務を始めて間もない頃だったが、そもそも処理時間がかかりすぎで改善の余地が大きいのが素人目に見ても感じられたのである。
マルチスレッドで処理するように作り変えて、処理時間は 1/6 くらいになることが見えてきた。Javaで書かれたそのバッチはグローバル変数に状態を書き込みながら処理しているようなコードもあって、マルチスレッドで並列処理できるように作り変えるのはなかなか大変だったのを覚えている。今思い出してもがんばったと思う。
自分としては顧客の課題は解決できそうで安心していたが、部署の中間レビューではボロボロの結果だった。 「これはなんで速くしたの？」 と言われたのがとても印象に残っている。
「そのバッチはなぜ毎日回しているのか」、「5倍になる従業員すべてに必要な処理なのか」、「顧客のどういう業務のために毎日午前中に終わっている必要があるのか」、「その業務には代替手段はないのか」といった業務の深堀りがメインで、バッチの速度改善のことにはほとんど触れられなかった。自分は「どういうやり方で速度改善をしたか」、「これまでの動きと変わってしまうところがないか」といった開発関連の質問には答えられるよう準備していたが、全然違う方向に話が進んでぐぬぬぬ...となった。その場で議論しながら業務を深ぼっていった結果、「それならコンサルと同行して業務フローを見直す提案をしたら開発せずに解決できるかもしれないけど、その選択肢はなぜ取らなかったのか」というコメントをもらって葬式みたいな雰囲気のままKOって感じだった。
今考えると「もうちょっと早いタイミングでそのレビューやってくれよ」とも思うが、当時の自分はとにかく素直だったので「そういう考え方が大事なのか」と目から鱗だった。「要望をそのまま聞かない」、「裏のニーズを理解する」、「開発は問題解決の手段のひとつ」といった話を聞くと、自分はこの 「なんで速くしたの？」 と言われたレビューを思い出す。
この件は結局速度改善の方向で進めることになったのだが、開発のレビューで顧客の業務理解と課題解決にフォーカスした議論になるのはすごい組織だったと今になって強く思う。10年以上経った今でも思い出すような経験をさせてもらって感謝している。
