話者紹介

GMOペイメントゲートウェイ QM/R&D 室長 駒井
サービスアーキテクト
2009年GMOペイメントゲートウェイ入社
現主力サービス立ち上げ時から設計、プログラミング、システム運用、セールス支援など全方位に携わる
2018年より、新サービスのプロダクト設計、エンジニアリング支援を主に担当
現在は、「こんど払い byGMO」のエンジニアリングマネージメントも兼ねる

ビュフォート 徳田
2015年 ビュフォート入社。決済システムの基幹システムやカード会員システムの開発に従事
「こんど払い byGMO」プロジェクトのマネージャーを担当

ビュフォート 藤岡
2017年ビュフォート入社。クレジットカード会社のシステム開発プロジェクトに従事
「こんど払い byGMO」プロジェクトではサブリーダーとして、メンバーの取りまとめや、GMO-PGとの橋渡しを行いながら、設計、開発などの実作業も行う。

自社技術の新陳代謝は必須

駒井　いきなりですが、皆さんエンジニア足りていますか？というお話です。
多分今、自社エンジニアが潤沢で次々といろんな開発ができているという事業者は、事業がうまくいっている事業者ほど少ないのではないかと思っています。

そのようななかで、自社技術の新陳代謝というのが必須で、例えば当社のように、事業が5年、10年、20年と続いている現場においては、こういったカルチャーの変化ですよね。オンプレミス、データセンターからのクラウドネイティブっていう方とか、モノリスサブシステムっていう分割から、コンテナクラスタでマイクロアーキテクチャであるとか。
そもそもその言語やOS、フレームワーク自体の拡張、転換っていうことも考えていかないといけないことはみんな分かっていますが、おそらく開発リソースの優先度って、こういう感じだと思います。

開発リソースの優先度は

駒井　直接事業拡大がヒットするような、機能面の拡張であるとか、個別のビジネス、セールスにつながるような案件への対応。そんな中でも、エンジニアの採用環境というのはかなり競争が激しいので、採用が次々と進んだとしてもエンジニア力は常にギリギリというジレンマがあります。
当社の1つの決断として、外部の力を借りて、その上で自分たちの足元技術を更新していこうと決めました。
これは外部に頼りきるということではなく、リソースが足りないときに、タイムリーに外の力をお借りして、進めていこうという体験をいたしました。

自社技術の代謝を外部パートナーと協力して進めた体験談

駒井　自社技術の新陳代謝を外部パートナーと協力して進めた体験談を、実際に開発を担っていただいた受託開発者のお2人へのインタビューと、委託した当社側の目線という形でお話ししたいと思います。何か1つでも共感したり、参考になるということがあれば幸いです。

題材：こんど払い byGMO

駒井　題材にするのが、「こんど払い byGMO」というサービスです。
このサービスは、昨年2020年の5月末にローンチされました。GMOペイメントゲートウェイ自社提供の非クレジットカードの決済サービスです。技術的には、当社は長くオンプレミスでやっていますので、クラウドネイティブで構築する、あるいはそのコンテナクラスタで、オーケストレーションにマイクロサービスで提供する、という取り組みをしたかった。
そこで、新規サービスで、システム面、技術面、あるいはチーム編成面でも、既存とのコンフリクトが少ない、こういう新規事業の機会に、新しいことに是非取り組むべきだろう、ということで、このサービスでそういう転換をすることにしました。

ちなみに、先ほど紹介した「PGマルチペイメントサービス」を含む、当社の主力サービスのほとんどが、オンプレミスのDC線、KVMホスト群のゲストホストでこのくらいの事業環境、技術基盤といった形で2012年ごろから続いている当社のコア技術になっています。

それに比較して、「こんど払い byGMO」は、主にこんな感じのアーキテクチャになっています。すべてAWS上で、ECSで、コンピューティングファーゲートでマネージドサービスを利用して、セルフマネージのOSを排除して、その上にspringで書かれたアプリケーションをコンテナオーケストレーションで、マイクロアーキテクチャで提供しているというような感じです。

株式会社ビュフォート

駒井　こういった構成のシステムをビュフォートさんにお願いして、「伴走して一緒につくっていきましょう」という決断をいたしました。
ビュフォートさんはここに書いたように、既存のクレジットカード決済の本当に基幹の部分であったり、我々を含むカードホルダーが見るような会員WEBであったり、あるいはクレジットカードとはずれますが、対面のQR決済のシステムであったり、要するに決済分野のエキスパートチームです。
当社の内部エンジニアは、エンジニアリングマネージメントと、あともう1名プロジェクト管理をするPMの2名でやるという体制で進めました。

受託開発者にインタビュー

駒井　ではここからは、この受託開発をされたお2人にこのような観点で「実際にやってみてどうでしたか」と、良し悪しなどをお聞きしてみたいと思います。

本日は、ビュフォートさんから、徳田さん藤岡さんにお越しいただいています。

マイクロ化されたfintechサービス

駒井　「こんど払い byGMO」はマイクロアーキテクチャによるフィンテックサービスですが、一方で伝統的なクレジットカード決済システムの構築経験が豊富にあるビュフォート社にとって、その過去の「経験が充分に活かせた」「このままでよかった」というところと、経験があるがゆえに発想を変えなければいけなくて「そこに囚われて大変だった」、といった両面があると思もいますが、どちらの面でもいいので、どんなことを感じられましたか?

徳田　最初のほうのスライドにもありましたが、従来のモノリス型のサブシステムというような、いわゆる業務がいくつもあり、それに対して1つのプロセスがありました。それぞれ仕事は決まりきっているというところでずっと開発をしてきましたが、それをマイクロサービスにアップするところや、今までは業務を上から下まで流れで処理をするフロー的な意味で、各役割に分解してそれぞれの役割が口を開けて待っているのに対して、シナリオを頭からかぶせて進めていき業務を実現するという、むしろ従来の考え方からいうと、検討という意味でワンステップ多く感じました。
まずは、業務を登場人物ごとに分解しなきゃいけないというのが、最初に苦労した点で、開発チームの置き方に似ているのですが、それをどういうレベルでどういうふうに分ければいいんだろうというところが、プロジェクトマネージャーもやっている中で一番苦労しました。

駒井　確かにそうですよね。その「サブシステムとは」みたいなところから考えていくと、マイクロアーキテクチャって、チーム編成において、プロセス、ファンクションで考えるサブシステム型と、ドメイン、サブドメイン、APIみたいな考え方ではちょっと苦労する部分ですね。
ありがとうございます。藤岡さんは何かありますか。

藤岡　経験も浅いのでお恥ずかしいのですが、プロジェクト参画当初は、そもそもそのマイクロサービスの考え方をよく知らない状態でした。これまでいたプロジェクトですと、例えば、画面機能でやりたいことはすべて機能の中で、何でもやってしまうようなつくり方をしていたので、責任分解っていう考え方、発想に慣れるのが、最初は大変でした。
以前いたプロジェクトでいうと、例えばクレジットカードの決済金額を計算したいときはこのサービスを呼んでくださいとか、キャンセルしたいときはこの人を呼んでくださいというサービスもつくっていましたので、一応マイクロサービスという考え方のプロジェクトではなかったのですが、理解のきっかけ、とっかかりにはタフな経験があったのだと思います。

駒井　確かに、マイクロサービスとはいえ、当然その上で動いている業務知識は、そりゃあもちろん与信・請求・精算とかもすごく経験豊富であるし、サブシステム型のところと似ている部分もあるので、応用できる部分もあったかなという感じなのですね。

藤岡　そうだと思います。

駒井　分かりました、ありがとうございます。

オンプレミスからクラウドネイティブへ

駒井　では次に、技術インフラ、ビュフォートさんの実績としては、オンプレミスのデータセンターであったり、AWSを使っていて、いわゆるEC2もOSをたてて、その上に自分たちがいろいろやっていく。つまりリソース借りみたいなスタイルが多かったと認識していますが、今回の「こんど払い byGMO」は、コンピューティングリソースを全部クラウドマネージドして、本当に上位のファンクションの部分だけをつくるということでした。
何かそれに対して従来知識の中で「これ応用でいけるな」とか、ちょっとこれは「根本的に変えなきゃいけなかった」なというようなことはありましたか。

藤岡　こちらも、私が今までインフラというところに関わった経験がないので、最初は聞く単語すべてに、「それって何ですか」というところから始まりました。応用というところでは、「こんど払い byGMO」のプロジェクトを開発していく中で、例えば何か不具合があった時に、プログラム起因とは限らなかったりしますし、新しいサービスをつくったので環境に反映したいというときに、実践で少しずつインフラについて知り、そのサービス全体のつくりもだんだん分かる知識がついてきたのではないかなと思っています。

駒井　クラウドに移行することで、オンプレミスであれば、「あとはインフラチームお願いします」とか、「あとオペレーションチームお願いします」みたいなところを自分で理解してやらなければいけないという、学習の必要性は発生しましたが、その分、システムを上から下まで1人でできる範囲が増えた。全体を見通せるプラスの経験ができたという感じでいいんですかね。

藤岡　はい。

駒井　ありがとうございます。徳田さんいかがですか。

徳田　私のほうは、ある程度のインフラの経験もあり、従来のやり方にならって、ただ手段をクラウドフォーメーションに替えたというイメージで今回チャレンジしているわけなのですが、いくつかかゆいところに手が届いているようで届かないというところもあります。
例えば、おっしゃったようにEC2をたててサーバとしてあげるのであれば、オンプレとあんまり変わりません。コンテナをたててというところで何かあったら、私の感覚ではすぐに立ち上げて、ログインをパッパッパッパとすませるような感覚でいるんですが、「入れないのか。じゃあ、調査は何をすればいいんだ」というようなところですごく悩んでも、逆にもうみんなが使えるような便利なツール群やサービスが並んでいるので、ちょっとそこらへんは発想を変えて受け入れて、各々やるという時代は終わってきたのかなというふうに思い、最近は取組んでいます。

駒井　ある意味、インフラでマネージドを使うっていうことは、自分たちで触れる範囲、ブラックボックスが増えてしまうっていうことなので、そこはある意味トレードオフというか、そこがまさに転換をせまられたところだったという感じなのですかね。「いざとなればターミナルログインすればいいじゃん」という経験があったら、その感覚は非常によく分かります。それは伝家の宝刀であって、ログイン負け、みたいな状態になるので、強制的にオペレーションの転換を迫られる話ですよね。

徳田　今までしていたこと、いろんなノウハウのアイテムが全部使えないという悔しさがあります。

駒井　ノウハウといえば、一例でいうと、こういう決済システムって、いわゆる締め処理があって、計算して、請求してみたいな、そういう日回しの試験みたいなことをすると思います。
いわゆるOSにログインできる環境であれば、dateコマンドをいじるんですけれど、コンテナの場合って、それはどうやって実現してそういう試験をされたりするんですか。

徳田　これもツールというか、イメージとしてはLinuxイメージですね。コンテナにライブラリを仕込んで、コンテナ起動時に関係変数によって、引き続き自由に操作できるっていうことを取り入れています。(編注:libfaketimeで実装)

委託/受託の関係下での技術追及

駒井　今までの業務知識を生かしつつ、そのやり方を工夫する、一定の同じレベルを講じると思っています。
では3つ目なのですが、こういった技術的な追及を、委託、受託という関係で行うことについて、やりがい、やりにくさ、それぞれあったと思います。特に受託のプロであれば、技術的な最適解まで考えて提案することに、やっぱり矜持があったでしょう。細かい事をいろいろ指摘されるわけですが、そういう中で、もっと深いところに行くのだっていうやりがいや、あるいはやりにくさ、難しさみたいなことって、どんなこと感じましたか。

藤岡　当社は、いわゆる先ほど言われていた委託・受託の関係っていうので、内部で開発も突き進めてしまって全部つくった状態で、リクエストを投げてから初めての納品です。始めてから「そのコードはちょっと良くないですよ」ということも当初あり、それをだんだんそのやり方を変えていって、GMO-PGさんとの関係も、だんだんでき上がっていき、今は「どういうふうにつくりましょうか」っていうところから、話し合いをできているので、そういう面では、いい変化があったかなあと思っています。

駒井　徳田さんいかがですか。

徳田　うちとしては、GMO-PGさんなのか駒井さんなのか、すごく特殊なお客さまでした。今まで私の経験では、発注頂いたら「もうあとはすべてお任せください」となり、できたものを納品するという流れでやって来たんですが、それをコードレベルで「こういうデザインパターンでいきましょう」とか、「そのフレームワークはこういう感じでいきたいです」というところを、ずっと対応しながら相談して進めていくスタイルは今回初めてでした。ただ、やってみたら、先ほどおっしゃられたように、私たちの矜持はあり、持って行くのですが、「確かにこれはいいね」っていうところや、こういうやり方もあるんですかと私たちが気付かされたりするところもあり新鮮でした。

駒井　そういう感じですね。当初、すごく怒られるのかなと思っていたので安心しました。プロジェクト進行そのものや、受託・委託でも目指すところみたいなゴール設定が今までと違うのですが、それは目線が上がった前向きな変化と捉えてよろしいですかね。

徳田　そうですね。

駒井　分かりました、ありがとうございます。非常に貴重なお話をありがとうございます。

委託目線で振り返り

駒井　では最後に、この件、委託して開発していただいた、当社の目線からの振り返りですけれども、既にお話してきたように、外部パートナーの助力を頂きながら発注することも十分にできます。できないわけないと思っています。
一方で、大事なのは委託する側のリードと、あとは明確な責任分解ですよね。委託する側のリードというのは、先ほども徳田さんが答えてくださりましたが、こちらがこれをやってくださいと、ただ機能を満たせばよいではなくて、それ以上のところにいきましょう、ということをはっきり提示することです。
また明確な責任分解というのは、先ほど藤岡さんのほうから断られるという話がありましたが、それは本当にこのコードではまずい、たとえばスケールに対して致命的なことがあるっていうケースだけで、ちょっと課題あるけど動くよねというところは受け入れます。機能要求、非機能要件を満たしていれば、それはもう受け入れるわけです。
そこを満たしているけれどもコードがね、と言い出すとかえってぐちゃぐちゃになってしまうし、お互いの責任が分からなくなってきて結果、不幸なことになるので、そこはあえて受け入れて、これは次の開発で改善していきましょうと言って、お互い進んでいくという、責任分解だと思っています。

なので、最後3つ目ですけれど、フルの内製チームで、基盤技術を革新するっていうことに比べれば、スピードは出ないです。それは間違いないと思います。なので、当社としては、よりスピードを出すために、株式会社ビュフォートさんを、この4月からGMOペイメントゲートウェイの100%グループ会社にお迎えして、少しでも垣根を低くして、スピードを上げていこうという試みをしています。
けれども、内製エンジニアも足りないぞ、という状況は続いており、先ほどの「GMO掛け払い」も、運用欲しいぞという話もありましたので、当社エンジニアは次々募集しております。もしご興味のある方はコンタクトをして頂けると嬉しいです。ご静聴ありがとうございました。

採用情報はこちら

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。