銀行のプライムベンダーであるということ
プロジェクトストーリー01
ITエンジニアリング事業部
Project Data
プロジェクト概要
銀行員向けの口座管理システムや、口座開設の事務システムの開発技術
技術
Webでのオブジェクト指向言語(※機密保持契約により非公開)
開発体制
プロジェクト参加数(協力会社を含む)
開発メンバー数15名(プロパ5名)
規模感
年100人月以上
ミッションクリティカルなシステム開発の典型例である金融機関のインターネットシステム。オープントーンは銀行のプライムベンダーとして、日々その開発に取り組んでいます。銀行から信頼を勝ち得た要因とオープントーンの強みは?今後の展望は?ITエンジニアリング事業部の部長とプロジェクトマネージャーが語ります。
まず具体的にはどんなプロジェクトに取り組まれているのですか?
菱野:口座に関わる事務系の開発を主に担当しています。他にもプロジェクト次第では「公的くじ」に関わるシステムなど、幅広く開発しています。
コールセンターの方や行員が使われるようなシステムでしょうか?
菱野:両方ですね。エンドユーザーである利用者の方が実際にインターネットから利用されてる機能も開発しています。
このインタビューを読まれる応募者の方も、銀行の開発に関わったことがある方は多いと思います。やはり銀行の開発といえば、古い固まった技術で開発を行っているのでしょうか?
菱野:いえいえ。私も前職でそういった「銀行の開発」というのを見てきました。それらに比べると、かなり当社の顧客行様の取り組みは先進的だと思います。技術的にはもちろんですが、開発やビジネス要件のスピードも、皆さんが想像される「銀行の開発」とは大きくかけ離れているかもしれません。
例えばどんなところに違いがあるのですか?
菱野:「銀行の開発」は、厳しく制約された設計・開発手法の中で、レガシーな技術を用いて、決まった作業をしているように、皆さんは想像されると思います。
しかし、当社の顧客行様の取り組みは全く違います。
例えば、新しい事案であればアーキテクチャから選定・提案を任せていただけます。銀行側からはダイレクトに要件が共有されます。そしてその要件を実現する方法は、銀行側と一緒に取り組み、考えて、提案していくスタイルです。
お客様も常に、無駄なことはせず「要件や品質を満たす最短ルート」を求めてきます。そういう意味で、多くの銀行の開発現場で「ルールだから」という理由で無駄な資料を作成したり、無意味な技術的制約に縛られたりすることは少ないですね。
そういう環境であれば、そのまま開発者のやりがいにも繋がりますね。
菱野:ええ。なので、銀行のシステムに要件から携われるという社会的意義と、エンジニアとして技術への取り組み両方を実現できる環境かと思います。
畑中:ITベンチャーといえば、単に面白いことを追求するように見られがちです。が、特にわれわれITエンジニアリング事業部は、社会に役立つ事と、ITエンジニアとしての技術的な追求すること双方へ取り組むことをに注力しています。
この銀行のプロジェクトを例に見ても、マイナンバー対応など「時事の課題」に銀行と一緒に取り組まないといけません。世の中の法律とか風潮とかを肌で感じ、ビジネスをITで創造してく取り組みに大きなモチベーションを感じられています。
そうした形で銀行との信頼関係が作り上げられたことには、どういう要因があったのでしょうか?
菱野:銀行のプライムベンダーとして、会議の場で顔を並べる他のベンダーさんは殆ど大手、、、それも国内最大手クラスばかりです。そんな中、当社のようないわば無名の会社が、基幹的な業務の一部を担う主要ベンダーとして参画しているのは、外部から見たら奇妙に見えるかもしれないですね。要因としては、これまで積み上げてきた信頼の中で醸成されてきたものが大きいのでしょう。
畑中:当社がプライムベンダーとして、銀行の信頼を頂いている理由は他にもあります。ひとつは、広義の技術力。これまで様々な事案を要件の段階から重ねていく中で、銀行業務そのものへの造詣を深めさせていただきました。
結果、他銀との接続はどうしたらいいか、インフラ周りはどうしたらいいか、監督官庁への説明のためにはどういう設計書がいいか、、、など、様々なノウハウを身につけられました。
それから、マネジメントや品質への改善の取り組み。
他にも小さなベンダーであるがゆえに、より顧客に親身になって取り組んでいるということも大きいと思います。
その上で、開発力のパフォーマンスが名だたる大ベンダーと比較しても遜色ないばかりか、むしろ大きく勝っているという自負があります。
実は実際に計測したこともあるのですが、コード行数やユースケース単位でのパフォーマンスは国内最大手の各社より群を抜いて高かった実績があります。
なるほど。その結果としてプライムベンダーとして信頼を獲得されたのですね。
ちなみにプライムベンダーとしての苦労はありますか?
菱野:やはり工数管理ですね。そう聞くと、エンジニアの中には「管理」という言葉自体を嫌う人もいますが(笑)
畑中:顧客もビジネスで開発を行っていますからね。面白さや楽しさ目的ではなく。多くの預金や送金など社会の仕組みを運営維持するために、利用者から手数料を頂き、そしてその手数料から開発費を捻出してより便利で安全なサービスを提供していく。お客様のサービスを、より良いものにしていくためには、エンジニアとしての取り組みと同じくらい、品質やプロジェクトをしっかり管理する必要があります。
最適な形でサービスの向上に貢献できる開発体制にするのは、プライムベンダーとしての務めでもあります。
そうすると必然的に「高い管理能力」を持つエンジニアに入社してきて欲しいですか?
菱野:そうでもありません。まず、ITエンジニアリングそのもの対するモチベーションが無くては、いい開発ができませんから。
その上で「管理」について前向きに取り組み、改善を重ねていけるのであれば「これからそうなっていきたい方」を歓迎したいですね。
畑中:菱野を見ていても、他のプロパーのメンバーを見ていても感じることがあります。
プロジェクトの中で一度ならず「痛い目」を見た経験から、「管理」に対する取り組みを見直し、成長を重ねてきました。
無論、チームとして組織として助言もするし支援もするのですが「プロジェクトマネジメント」はコードを書くという作業以上に経験が響くスキルでもあるので。
そういった経験を貪欲に積んでいきたいという方であれば大歓迎です。
銀行のマネジメントで「痛い目」を見られる環境があるということ自体、素晴らしいのかもしれませんね。
菱野:私も2次請けのベンダーから転職したのですが、このようなプロジェクトの「管理」に取り組める機会はそうはありません。
大手に入り、何年もあるいは何十年も下積みを重ねて少しづつ昇進して、ようやくそうした立場になるのが一般的です。
あるいは、銀行に入行し情報部門に配属してもらい、やはり同じように何年もかけて・・・。
「痛い目」を見て欲しいわけでも、見るべきだとも思ってはいません。
が、そうした「成長の機会」を得ること自体が実は貴重な場ではないかなと思います。
畑中:菱野はもちろん、部長である私自身何度も「立ち直れないんじゃないか」と思うくらいの失敗もありました。
あのシステム障害を出してしまったときなんかなあ・・・(苦笑)
逆説的ですが、そうした障害にも「めげ」なかったのが顧客の信頼にも繋がっているかもしれませんね。
畑中:正直内心は「めげ」ていましたがね。(苦笑)
5年くらい前に大きな障害出してしまいました。そのときは「取引見直す」といわれたくらいです。
それでも、できることを一つ一つやろう!とチームメンバーを集め、何度も何度も問題点を洗い出しました。
「品質を上げながら開発効率を上げる。」という相反する命題に逃げずに取り組んだことにより、今があるのかと思います。
その取り組みにより、障害を600日間も出さず、顧客から表彰を頂きました。
菱野:実際今では「はあ…。なんで?」と思うような障害は出なくなりましたね。
どちらかというと「このケースの、このパターンがもれていた」とか、障害の出た原因がきちんと追求して改善できるようになったと思います。
同じように「めげ」ずに取り組んでいただける方に応募をしてもらいたいですか?
畑中:その気概はもちろん持っていて欲しいです。あとは一つでも出来ることを常に増やそうとする人。思っているだけじゃなくて、行動をして成果を出せる人。
事業部としてはそういう方に来ていただきたいと思っています。端的に言うと、「明日の自分のために一個一個積み重ねられる人」ですね。
菱野:さらに現場として付け加えるなら、Javaでもデータベースでもそうした技術を身につけ「自分の技術を社会に役立てたい方」にも是非来ていただきたいですね。
我々とお客様との信頼関係をうまく使って、言語やフレームワーク、ツールの特性を生かし、世の中に役立てて行きたい方も歓迎したいですね。
先ほども述べたように、皆さんの思う「銀行の開発」とは大きく違います。
もちろん、好き勝手に何でも試せるわけではないですが、エンジニアとしての技術的な取り組みと社会的に役立てるという観点を非常に近くで両立させてり組める環境だと思います。
畑中:そういう方々と一緒に、現在の顧客行様へ貢献するだけではなく、ミッションクリティカル性と生産性や技術などの両立した柔軟な開発環境を作り出していきたいですね。
そして、その環境をさらに多くの顧客や業界ひいては社会に役立てていきたいですね。