システムとビジネスの確立をリード。世界に向けて“日本取引所グループの差別化”を図ったエンジニア：ITでビジネスを変革。デジタル時代のテクノロジリーダーたち（1）（3/3 ページ）

「運用基準を順守できません」宣言

編集部　要件が決まっていないプロジェクトを進める上で、最も留意したことは何だったのでしょう？

箕輪氏　ユーザーやベンダー、バートナーといった境目を作らないことですね。プロジェクトメンバーは当初、ベンダーとパートナーSI、JPXの開発スタッフで構成する25名程度でしたが、同じ社屋の2つの部屋にメンバーが集まって作業を行いました。これにより、日本証券クリアリング機構のリクエストだけではなく、OTCの既存エンドユーザーの意見をできる限りすぐに開発に反映できるようにしました。また状況に応じた意思決定を素早く行えるよう、ステアリングコミッティを設けて、経営層や業務部門トップに参加してもらい、開発の状況を定期的に共有していました。

編集部　箕輪さんがプロジェクトチームとステークホルダーの橋渡し役となり、開発過程の疑問や課題をすぐに解決できるよう心掛けていたわけですね。ユーザーサイドと意見を交わしながら作るといった辺りは、アジャイル開発に近いですね。

箕輪氏　近いと思います。ローンチしたのは予定通り、プロジェクト開始の1年後、2011年7月でしたが、当初はシステムの機能追加・改善のために1カ月ごとにリリースし、バグフィックスも含めると2週間ごとのリリースになることもありました。システム改善は今も継続しており、大きなものでは半年に1回ほど、パフォーマンス対応や小規模な改善は月1回ほどのペースでリリースしています。

　とはいえ、当初はリリースサイクルが速いが故にデグレードが起こるという課題もありました。そもそもシステムのリリース頻度が高い他、制度も固まっておらずリリース後に要件が変わることが多かったため、新しい変更を反映すると、それまで動いていたシステムが動かなくなってしまうということがよくあったのです。しかし問題が生じたらすぐに対処できる体制を築いていたため、制度とシステムを継続的に改善し続けてこられたのではないかと考えています。

編集部　しかし「システム主導」という、新しい開発スタイルを採用することに、社内で抵抗はなかったのですか？

箕輪氏　新しいビジネスに取り組むことは決まっていたので、そのやり方をどうするかでしたね。特に課題の焦点となったのは、開発から運用への橋渡しです。当時のJPXのシステム運用基準は、株式売買システム「arrowhead」が基準となっていました。arrowheadは、99.999％の可用性を確保するため処理サーバーの3重化やイベントコリレーション（類似メッセージの集約機能）、自動リカバリを備えた障害監視機能を有し、高信頼性を実現するためのしっかりとした運用基準があります。ただ、さすがにそれと同じにすることは、スケジュールや開発手法を考えると難しい。

　そこで「運用基準を順守できません」と開発当初に宣言することにしました。リリース後、完全に運用側に任せるのではなく、何か問題が起きたら電話してもらい、「必ず開発側で解決する」ということにしたのです。具体的には、運用側に依頼するのはシステム監視と週次・月次での定例作業で、監視メッセージの精査や障害対応については開発チームが行う体制としました。今回の開発スタイルでは、そこまで開発側が責任を持たないと運用に乗らないと思ったのです。

編集部　なるほど。一般的な意味でのDevOpsとは異なりますが、開発チームが運用分野の業務も担うという“DevOps的なアプローチ”を採ったわけですね。エンジニア主導のビジネス貢献を考える上で、これは一つのカギといえるのかもしれませんね。

デジタル時代、エンジニアは「ビジネス」にどう向かい合うべきか？

編集部　今回のような、エンジニアがビジネスゴールにコミットするようなスタンスは、今後ますます強く求められてくると思います。箕輪さんはエンジニアとして、ビジネスにどう臨むべきと考えていますか？

箕輪氏　そこにビジネスチャンスがあり、それがテクノロジで獲得できるものなら、決して見逃すべきではないと考えています。その際、重要なのは「これを逃したら会社にとっていかに損か」ということを、関係者にいかに説得していくかです。

　そのためには、業務理解をはじめ、インフラ層、アプリ層を理解することが不可欠です。ただ、それらだけを見るのではなく、意思決定層や関係者に対し、それぞれの立場・役割に応じた言葉で、「そのプロジェクト全体が会社にとって、どのくらいの価値があるか」を示すことが大切です。より具体的に言えば、「ビジネス目標に対する効果、納期、コストのフィジビリティをいかに示せるか」が大きなカギとなります。

編集部　そうしたアーキテクト的な知識、観点はどのように身に付けられたのですか？

「そのプロジェクト全体が会社にとって、どのくらいの価値があるかを、エンジニアの視点から示すことが大切」

箕輪氏　そうですね。私はもともと会計ソフトベンダーにおり、当初はアプリケーション開発のプログラマーとして勤務し、その後はデータベースエンジニアやブロジェクトマネージャーなど幅広く経験してきました。転職後、JPXには業務寄りのIT人材が多かったため、私自身はインフラや運用に関する知識を習得することで、「業務要件からアプリケーションのアーキテクチャを想像し、インフラ構築や運用に落とし込んでいく術」を身に付けようと考えて業務に取り組んできました。そうした前職時代から転職後に至るまでの数々のプロジェクト経験によって、「業務要件からインフラ構築・運用までを見渡す」ことができるようになったのだと思います。今回のプロジェクトでは、そうした経験が「新しいビジネスを作る」ことに対してうまく生きたのではないかと考えています。

編集部　ビジネスからインフラまで、全てを俯瞰できるようになるためには、大変な努力と経験が必要だと思いますが、今後はそうした能力が一層重要になっていくのかもしれませんね。取引所もグローバルでの競争を強いられている中で、今後はどのようなチャレンジをお考えですか？

箕輪氏　方向性としては2つあると思います。一つはarrowheadのような、従来からの取引所ビジネスを拡大するためのアプローチです。ここではユーザーに対して、「いかに迅速かつ安定的にITサービスを提供していくか」というテーマを突き詰めることがポイントとなります。もう一つは、今回のような新しい取引所ビジネスの開拓です。新しい顧客ニーズをいかにキャッチアップしていくか。今後はR&Dとしてシステムを開発するようなスタンス、取り組みが必要になってくると考えています。

編集部　では最後に、エンジニアがビジネスをリードしていく上で大切だと思うことを、あらためて教えていただけますか？

箕輪氏　やはりプロジェクトマネージャーとして、ブロジェクト全体のどこにリスクがあるのか、案件の全体像を理解して、そのリスクをスケジュールとお金に換算できることが重要だと思います。そして、それを執行してくれる者に対して、いかにうまく説明できるかです。

　もちろん説得するのは簡単なことではありません。しかし、周囲の状況や条件を考慮しつつ、それを作ることでどのようなビジネスインパクトがあるのか、ITサービスに対するエンジニアとしての見解を伝えていくことが大切だと思います。それを説明できれば、自社がビジネスチャンスをつかむことに大きく貢献できるのではないでしょうか。

編集部　ありがとうございました。

　「ビジネスとITの連携」の在り方は以前から強く問われ続けてきた。だが議論の的になるのは、省力化やコスト削減といった守りの施策であることが多かった。しかしここにきて、新しいビジネス、新しい顧客を開拓する、収益・ブランド向上につなげるといった攻めの視点に変わりつつある。

　特に市場環境変化が速く先を見通せない今にあって、「R＆Dのような開発スタンスが必要」という箕輪氏の言葉は、ビジネスとITの連携の在り方、またエンジニアとしてのスタンスを考える上で、非常に示唆的といえるのではないだろうか。