“ひどい”SQLを書いても気づかなかった新人時代
「社会人になり、最初の5年間はアプリケーション開発をしており、ほとんどデータベースには関与していませんでした。多少SQLを書く程度です。今から思えば、ひどいSQLを書いていました」
そう話しながら中西さんは苦笑いする。開発者にとって重要なのは要求された機能を実装すること。サーバーに負荷がかかる処理かどうかはさして重要ではない。一方、サーバーの運用者はサーバーを安定稼働させるのが役割であり、性能を劣化させるような処理はできるだけ食い止めたい。与えられた役割が異なるため、両者の溝は深い。
かつての中西さんはアプリケーション開発しか経験していなかったため、サーバーの性能に悪影響を与えるような“ひどい”SQLを書いていてもそれに気づかなかった。
そんな中西さんに突然の転機がやってきた。それまで短期の開発プロジェクトを転々としていたところ、5年目から金融系の基幹システム刷新のプロジェクトにどっぷり参画することになった。上流の要件定義から関与し、データベースの設計や構築、運用にも関わる。開発中心からアーキテクトや管理側へ。キャリアの大きな転換点となった。
当然、最初は「本当に？私に？いくらなんでも自分では経験がなさすぎる」と困惑した。仮にプロジェクトが失敗したら「（経験の浅い）自分に任せるからではないか」、そんな考えもよぎった。ただ中西さんだけに全てがゆだねられたわけではなかった。プロジェクトにはデータベースの経験を積んだ人もいて、中西さんはその補佐的な役割からスタートした。いずれにしても立場が大きく変わったことは確かだ。
不安でいっぱいだったかというと、実はそうでもなかった。あまりの変化の大きさに逆に開き直ることができたという。またシステム刷新のプロジェクトに最初から関与できたため、経験のなさで周囲から浮くということはなかった。
そうはいっても「どこから考えればいいのか」と全く勝手が分からない。当時携わったのは商用のデータベース製品。まずはモデリングの本を手にした。「『実践的データモデリング入門』などの本を読みました。もちろん、当時はDB Magazineも読みましたよ」と笑う。
いつしかデータベース管理者として開発者と向き合うこともあった。処理の負荷を減らすように開発者に交渉するということだ。開発者はかつての自分なので、相手の状況はよく分かる。
「気持ちはよく分かるんですよ。『その処理はサーバーの性能を劣化させるからよくない』など、正論だけでは相手に通じません。『この処理はだめ』と拒否するのではなく、『こういう処理に変えたらどう？』と修正案を考えたうえで提案するようにしました」
開発者を経験した中西さんだからこそ、開発者と管理者、アプリケーションとインフラのつなぎ役となることができた。
