GMOペイメントゲートウェイ の記事一覧

4月24日（水）にオンラインで開催された「GMO Developers Night#40」に、オンライン総合決済サービスを展開するGMOペイメントゲートウェイのエンジニアが登壇。GMOペイメントゲートウェイとその連結会社であるGMOペイメントサービス、三井住友カード様との共同事業であるBNPL（Buy Now Pay Later）サービス「アトカラ」開発の裏側を紹介しました。 登壇者 GMOペイメントゲートウェイ株式会社 システム本部 関連事業サービス統括部統括部長 秋山 弘幸後払いサービス部 後払いサービス第2グループ池田 隆介森 隆之坂口 健太 決済事業者は「ミッションクリティカル」「マイサービス」「フルスタック・フルフェーズ」 冒頭では、秋山がGMOペイメントゲートウェイ株式会社（以下、GMO-PG）、およびシステム本部 関連事業サービス統括部について紹介しました。 GMO-PGは、ECを中心とした加盟店と、カード会社や銀行、キャッシュレス決済事業者といった決済会社とをつなぐゲートウェイ機能を担う会社で、多くの決済手段を提供しています。デジタル化の進展とともに多種多様な決済手段の需要が増えたことで、連結加盟店舗数は現在15万店舗を超えています。また、2023年12月末時点では、連結決済処理件数65億件、連結決済処理金額15.8兆円という実績で、営業利益年平均成長率25%の継続を目標に掲げています。 GMO-PGのような決済事業者で働くことの特徴として秋山は、「ミッションクリティカル」「マイサービス」「フルスタック・フルフェーズ」の3点を挙げます。 ミッションクリティカルという観点では、厳しい非機能要件が特徴です。決済に関わるシステムであることから、24時間365日の高可用性・高信頼性、大量処理と低レイテンシー、高セキュリティなどが求められ、不正取引・アクセスと日々戦わなければなりません。 また、GMO-PGは、マイサービス、フルスタック・フルフェーズで完全内製化を実現。要件定義からリリース・運用までのすべての工程を自社パートナー（社員）で実施しています。秋山は「社会インフラの一部を担っているという意識が、やりがいにつながっている」と語ります。 今回の登壇者が所属するシステム本部には、現在約250名程度のエンジニアが在籍しています。拠点の中心は東京・渋谷ですが、福岡にも開発拠点を有しており、新卒・中途合わせて毎年30名程度のエンジニアが入社しています。 システム本部のなかでも、関連事業サービス統括部では、GMO-PGの連結会社であるGMOイプシロンとGMOペイメントサービスの事業を支えるシステム開発・運用・保守を担当しています。今回のテーマでもある「アトカラ」は、同部配下の後払いサービス第2グループで開発を行ってきました。 対面・非対面問わずさまざまなシーンで利用できる「アトカラ」 池田は、アトカラの特徴について説明しました。池田は、入社7年目のエンジニアで、「銀行Pay基盤システム」、「こんど払い byGMO」の開発を経て、2023年10月からアトカラに参画しています。 アトカラは、「クレジットカード不要！スマホだけですぐにお買い物ができる」をコンセプトに2024年2月にサービスを開始した後払いサービスで、対面・非対面問わずさまざまなケースで利用可能です。 非対面利用時には、電話番号、メールアドレスを入力したうえで、支払回数を選択し、SMS認証コードを入力すると買い物ができます。対面決済の場合は、QRコードを表示して、stera terminalで読み取ることで決済が完了します。なお、アトカラの会員審査では、ユーザーの属性情報に加え、GMO-PGが開発したeKYCサービスを利用しています。 他社の後払い型サービスと比較すると、ECと対面決済の両方に対応しているのがアトカラの特徴です。また、3〜36回までの分割払いが選べるほか、6回までであれば分割手数料が無料となるため、ユーザーにとっては使いやすさが大きなメリットです。 アトカラプロジェクトを実現できた要因 アトカラ開発の裏側を明かしたのは、2022年5月に中途入社後、アトカラプロジェクトへ参画した森です。前職では別業界のシステムを担当しており、当初は決済関連の業務知識がまったくない状態でしたが、、「法令対応を含め、専門的な業務知識が必要なプロジェクトのためキャッチアップに苦労しましたが先輩方のサポートでなんとかやってこれた」と話します。 開発初期（2022年5月頃）は、ビジネス6名・開発7名という体制でしたが、ピーク期（2023年8月頃）には、ビジネス15名・開発50名と大所帯に。リリースの時期（2024年2月）には、ビジネス10名・開発25名という体制に落ち着きます。 森は、プロジェクトを実現できた要因の1つとして、マインドを挙げます。「GMO-PGの業務の心得である『全員社長主義』を自覚し、責任感を持って役割にとらわれず主体的に行動する姿勢がよかった」と振り返ります。 また、人材の豊富さも特徴でした。「GMO後払い」、「GMO掛け払い」、「こんど払い byGMO」などのサービスを経験したメンバーや、問題解決力・技術力のあるメンバーが相互に補完し合い、難しい課題に直面しても乗り越えられたといいます。開発面では、システムメンバーを中心に案件を推進したことにより、スピード感のある開発を実現しました。 アトカラのシステム構成は次のとおりです。 多くの機能を有する基幹システム、スマートフォンアプリとWebポータルの顧客管理システム、加盟店管理システム、eKYC、与信システムからなり、その土台にクラウド基盤としてAWSを採用しています。これが、加盟店のシステムと接続する形です。 アトカラシステムの基幹部分の構成と技術スタック 坂口は、アトカラのシステムの基幹部分について解説しました。 2019年4月に中途入社した坂口は、バックオフィスのシステム開発、「GMO掛け払い」、「GMO後払い」を経験した後、2022年10月より「アトカラ」とeKYCのプロジェクトに入りました。普段は九州オフィスに勤務しています。なお、約20名の九州オフィスエンジニアのうち、坂口を含めて5人のメンバーが「アトカラ」を担当しています。 AWS構成は次のとおりです（WAFやKMSなどのセキュリティに関するサービスは省略）。 基幹システムは、「GMO後払い」の資産をベースに構成しており、ECSを利用した動的アプリ、CloudFrontを利用した静的サイト、EventBridge、Step Functionsを利用したバッチアプリの大きく3つに分類できます。内製システムとしては、AWS上のシステムとオンプレミスのシステムがそれぞれあり、AWS上のシステムとの接続にはPrivateLinkを、オンプレミスのシステムとの接続にはTransitGatewayとDirectConnectを利用して接続しています。 構成図のもととなる技術スタックは次のとおりです。 eKYCのシステムは、身分証とセルフィーの撮影機能を提供するSDK、撮影されたイメージの保存や自動審査の機能を提供するAPI、目視審査等の機能を提供するバックオフィスという大きく3つのシステムに分かれています。 以下は、eKYCのSDKとAPIの構成図です。 SDKは、iOS/Android/JavaScriptの3つがあり、それぞれ「アトカラ」のアプリケーションに組み込んでいます。APIは、API Gatewayをはじめマネージドなサービスを多用した構成となっています。 バックオフィスの構成図は次のとおりです。 バックオフィスは、Single Page ApplicationをホストするCloudFrontと、API Gatewayで構成しています。APIと同様、マネージドなサービスを多く利用しているのが特徴です。アトカラに目視審査結果を連携する際は、PrivateLinkを利用して接続しています。 それぞれ技術スタックは次のとおりです。 eKYCの内製化で苦労した話 坂口は、開発時のエビソードとして、eKYCの内製化で苦労した話を紹介しました。 アトカラのeKYCでは、クライアントであるSDKから撮影された身分証やセルフィーのイメージファイルがAPIに転送これを同期的に処理する際、多くの場合は問題にはなりませんでしたが、坂口によると、顔検出やOCRのサービスの応答が劣化することがあったといいます。平均的には4秒以内にレスポンスを返却できていたものの、最大で23秒かかるケースがあったのです。eKYCのAPIは、Amazon API Gatewayを採用しているため、API Gatewayのハードリミットである29秒以内にレスポンスを返さなければなりませんされます。一方、API側では、暗号化、イメージの保存、顔の検出・分析やOCRを実施しています。 これを同期的に処理する際、多くの場合は問題にはなりませんでしたが、坂口によると、顔検出やOCRのサービスの応答が劣化することがあったといいます。平均的には4秒以内にレスポンスを返却できていたものの、最大で23秒かかるケースがあったのです。eKYCのAPIは、Amazon API Gatewayを採用しているため、API Gatewayのハードリミットである29秒以内にレスポンスを返さなければなりません。 そこで、eKYCのAPIでは、この問題に対して非同期関数を利用することにしました。具体的には、API Gatewayから同期的に呼び出しされるLambda関数内ではイメージの暗号化と保存のみを行い、残りの処理は非同期的にLambda関数を呼び出し、非同期処理内で顔識別・分析やOCRを行うようにしたのです。こうした非同期処理化により、APIのレスポンス時間は平均・最大ともに改善できています。 「アトカラ」の開発で登壇者が一番苦労したポイントは？ 視聴者からのQ&Aのコーナーでは、「『アトカラ』関連の開発で一番苦労したところ」について登壇者が回答しました。 池田は「法令遵守を含め1つひとつの要件が大きい。それぞれの開発に対する成果物のチェックやスケジュール管理が難しかった」と述べます。 森は「通常のプロジェクトでは業務要件が決まってから案件が立ち上がるが、今回は業務要件が未定の状態でスタートして、徐々に決まっていく形だった。こうしたなかで、画面やデータに落とし込むのに苦労した」と振り返ります。 坂口は「法対応に向けて法務とのミーティングを行っていたが、法律の条文を読む経験があまりなく苦労した」といいますが、「システム・人・契約・お金・データなどの流れが明確になり、サービスの理解度が高まった」と自身の成長につながったことを明かしました。 秋山は「割賦販売法に準拠したサービスをつくるのは初めてだったため、三井住友カード様の知見を活かしながら試行錯誤で進めた」と話しました。 また、「決済の知識がなくてもGMO-PGのエンジニアとして活躍できますか」という質問に対して池田は、 「決済サービス開発未経験のエンジニアも多いが、フラットに意見を言い合えたり、教え合えたりするカルチャーがあるため、未経験でも活躍できる土壌はある」と回答しました。 BNPL国内No.1サービスを目指して 最後に、アトカラの今後の展開について、秋山が説明しました。 まずは、加盟店獲得と認知度の向上です。「生まれたばかりのサービスで、使える加盟店様も少なくブランド認知度も低い。まずは、ご利用いただける加盟店を拡大するとともに、対面決済のstera端末などを活用した認知度向上などを進めていたい」と秋山は語ります。 2点目はサービスレベルの向上です。秋山は「トレンドに敏感で、使いやすい・身近なサービスを目指していく。共同事業者である三井住友カード様と協力し、BNPL国内No.1サービスに育てたい」と意気込みました。 エンジニア採用実施中！ GMOペイメントゲートウェイ株式会社ではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用HPをご覧ください。 また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。https://www.gmo-pg.com/blog/feature/feature03/ さいごに 当日、ご参加いただいた方からは、「サービスの全容やGMOペイメントゲートウェイの体制や方針等が分かって良かった」「AWSにおける具体的な設計方法について学ぶことができ、大変参考になった」「使用例と組み合わせて解説いただき、今後の自身の学習や実務に活かせると感じた」など、ありがたいお声をたくさんいただきました。 映像はアーカイブ公開しております。まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=14GfbaBJ3Kw

11月11日に野村コンファレンスプラザ新宿で開催されたJavaコミュニティイベント「JJUG CCC 2023 Fall」のスポンサーセッションに、GMOペイメントゲートウェイ株式会社 システム本部 橋本莉奈が登壇しました。セッションでは従来のレガシーシステムから脱却すべく、OpenAPIをベースとした新システムを構築する過程で遭遇した課題やその解決策、成果について紹介しました。 登壇者 GMOペイメントゲートウェイ株式会社システム本部 決済サービス統括部 マルチペイメントサービス部 決済開発第2グループ橋本 莉奈 オンライン総合決済サービス「PGマルチペイメントサービス」が抱えていた課題 GMOペイメントゲートウェイ（以下、GMO-PG）が2008年より提供するオンライン総合決済サービス「PGマルチペイメントサービス」は、多様な決済手段を一括導入できるプラットフォームです。EC事業者と各決済事業会社との「契約」「決済情報」「お金のやり取り」をつなぐ役割を担っており、加盟店様は同サービスを利用することで、決済手段の一括導入・契約の一本化が可能になります。 サービス開始当時、決済手段は4つのみでしたが、国内オンライン市場の決済手段の多様化により、現在の決済手段は30を超えています。これに伴い、決済APIも複雑になってきています。 PGマルチペイメントサービスの接続方式は、リンク型とWebAPI型の大きく2つに分けられます。リンク型は、加盟店様のECサイト上で決済ボタンを押すとGMO-PGの決済画面に遷移するという方式です。一方で、WebAPI型は、裏側の決済処理のみGMO-PGで行い、決済画面は加盟店様で用意してもらう方式です。 WebAPI型にはもともと、GMO-PG独自の接続仕様であるプロトコルタイプと、GMO-PGで作成した決済処理プログラムを加盟店様のサーバに導入するモジュールタイプの2種類がありましたが、今回、新たにOpenAPIタイプを追加することになりました。 OpenAPIタイプを追加するに至った背景には、2つの課題がありました。橋本は次のように説明します。 「1つめの課題は、既存の接続方式が弊社独自のレガシーな接続仕様となっていたこと。利用者への影響が大きいと考えられるためシステム変更が難しい一方で、現代のWeb標準と比較すると学習コストの高いプロダクトとなっていた。 2つめは、決済手段ごとにコンセプト、フロー、データ、用語のばらつきがあること。サービス提供開始当時はここまで決済手段が増えることを想定しておらず、決済手段が増えるたびに機能を継ぎ足していった結果、フローやデータなどが決済手段ごとにばらばらになった。結果として、APIが複雑化し、それぞれ個別実装しようとするとかなりの開発コストがかかる状況になっていた」（橋本） OpenAPIタイプの新しい接続方式の特徴 こうした既存の接続方式の課題を解消すべく、2023年8月に正式リリースされたのが「OpenAPIタイプ」という新しいWebAPIの接続方式です。その特徴は大きく分けて4つあります。 1つめは、決済手段の追加が簡単である点です。各決済手段を、クレカ払い、Pay払い、現金払いの3つのグループに分類してAPIを集約することにより、加盟店様は1つのグループに対し1度開発を行うことで、同じグループの決済手段を容易に追加できるようになります。 2つ目は、グローバルスタンダードなWebAPIに準拠している点です。今回は世界標準であるOpenAPI Specification（OAS）をベースとした接続仕様となっており、その他のWeb標準技術も積極的に採用しています。 3つ目は、安心安全な決済という点です。PCI DSSの準拠、不正利用対策、冪等性のサポート、暗号化スイートの強化のほか、現在OAUTH2.0認証を準備しています。 そして、4つ目が既存の接続方式との互換性です。既存方式を利用している利用者は、既存の取引情報や登録済みの会員データをそのまま利⽤できます。既存の接続方式を利用しながら、一部の処理を新規接続方式に移行するといった併用も可能です。 採用した技術スタック 今回採用した技術スタックは下記のとおりです。 OASを導入するメリットは多くあります。まず、世界標準のフォーマットであるため、設計者による記述のばらつきが発生しづらい点です。また、この仕様に則ることで、コーディングの一部を自動化でき、便利な公開ツールによってテストも効率化できます。定義がテキストベースであり、バージョン管理ツールとも相性がよいといえます。 さらに、つなぎこみの開発をするなかでよく発生する問題も解決できます。橋本は「たとえば、これまでの接続方式では膨大なAPI仕様書のなかから手に入れたいファイルを探して見つけなければならなかったが、OASを利用することで、最新のAPI仕様書をWebでいつでも確認できるようになる」と説明します。 また、開発の段階においては従来、手動実装によるパラメータ名の記述間違いなどの発生リスクがありましたが、OASを利用しパラメータのコードをツールで自動生成することによりヒューマンエラーが発生しづらくなります。 プロジェクトはスキーマ駆動開発で進行 今回のプロジェクトは、ecbeing社と協力してスキーマ駆動開発で進められました。ecbeing社はECサイト構築で国内最大シェアを誇るトップベンダーです。橋本は「ecbeing社とはAPIリファレンスとOASファイルでやり取りし、実際にGMO-PGのAPIを利用してもらい、フィードバックをもらい、アップデートを加えるというサイクルを繰り返した」と振り返ります。 このような手法を採用することにより、GMO-PGとしてはコードが自動生成できるようになり、仕様変更への心理的障壁が下がり、アップデートを気軽に行えるようになるというメリットがあります。一方でecbeing社としては、コード自動生成によって、仕様変更が生じてもすぐに対応できるというメリットがあります。今回のプロジェクトにおいても、リリース直前にもかかわらず大きなアップデートをかけることができたといいます。 クライアントサイドもサーバサイドも、ツールを利用すれば下記のようなコマンドを実行することでコードを自動生成できます。 APIリファレンスにもさまざまな工夫 今回は、Redoclyを利用してAPIリファレンスも自動生成しています。SwaggerUIやRedoclyなどのツールを利用すると、OpenAPIのYAMLファイルからHTMLを自動生成できます。橋本は「デフォルトのスタイルが整っているため、スタイルを適用しなくても、そのままで公開できるようなクオリティになっている」とツールを利用するメリットを話します。 しかし今回は、オリジナリティを出すため、GMO-PGのデザインチームによるデザインを適用しています。Redoclyは設定ファイルに基づいて自動生成したcssがhtmlに埋め込まれており、設定ファイルはjson形式で記述する必要があるため、今回はjsonファイルを作成しています。ただ、jsonのスキーマとHTMLの要素がどのように紐づいているのかドキュメントに記載がなく、その解析から行いました。 APIリファレンスを作成するにあたっては、API接続のための開発ガイドに関する説明を豊富に盛り込むように意識したともいいます。 「これまで加盟店様から受けてきた問い合わせの傾向を調査し、問い合わせが多かった内容を精査して、GMO-PGの開発エンジニアの経験も踏まえながら、開発者に迷いがないよう設計。海外PSP10社以上のリファレンスを調査・比較し、ドキュメント構成やパラメータ名なども参考にした。また、UXライティングも取り入れ、読み手に余分な負荷をかけず、何が言いたいのか伝わる文章を目指した」（橋本） 既存利用者の使いやすさを確保しながら安心安全な決済を実現する 今回、APIエンドポイントは、Remote Procedure Call（RPC）、いわゆる「手続き型」「アクション型」に基づいた設計にしています。当初はRESTfulなAPIにリニューアルすることで検討を進めていましたが、既存のAPI群が手続き型であるために、RESTfulに変えることで既存の利用者がシームレスに移行することが難しくなる状況を避けた形です。すべてのサーバー間リクエストのHTTPメソッドはPOST、リダイレクト処理はブラウザによってはcookieが抜け落ちる問題があるので、GETで統一しています。 API通信の認証はBasic認証方式を採用しています。これは、ID・パスワードを認証データとして利用している既存のWebAPIからの移行を簡単にするためです。ただし、よりセキュリティ的に強固なOAUTH2.0認証にも2024年より対応していく予定です。 最近の決済手段は、クレジットカードの3Dセキュア認証やPay払いなど、リダイレクトを含む処理が多いため、リダイレクトの方法についても気を使っています。今回、リダイレクト処理とコールバック処理はすべてGETで実現しています。また、安全に遷移ができるよう、csrfトークンをパラメータに含めて、なりすましや改ざん防止につなげています。 意図しない二重処理が発生する可能性を避けるため、冪等性がサポートされていることも重要です。冪等性とは、同じ操作を何度繰り返しても、同じ結果が得られる性質のことです。たとえば、ある取引を100円返金する際に、ネットワークエラー等で意図せず二重送信してしまうと、100円だけ返金したいのに200円返金されることがあります。OpenAPIタイプでは冪等性をサポートしており、二重決済は発生せずに、加盟店様は安全にリトライできます。 APIリクエストに対する処理結果を表すHTTPステータスコードは、OpenAPIタイプでは基本的にREST仕様に則って返却するようになっています。一般的に200系のコードはリクエスト成功を表しますが、今回のOpenAPIタイプでは200系を細かく分割しました。これは、リダイレクトの多い決済処理において、リダイレクトが必要なものを特定のステータスコードで返すようにすることで、加盟店様はコードを最初に見てリダイレクトすべきかどうか判断できるようになるためです。 APIリクエストがエラーになった場合、400系、500系のHTTPステータスコードを返却します。エラー情報はRFCのWeb標準仕様に従って、JSON形式で返却します。HTTPレスポンスヘッダーのContent-Typeは、application/problem+jsonで送信します。 OpenAPIタイプのAPIリファレンス（OASファイル）とAPI仕様はそれぞれバージョンがあります。APIリファレンスのバージョンは、メジャー・マイナー・パッチという3段階の変更基準があります。一方、API仕様のバージョンは、後方互換がない破壊的変更を伴うリリースが発生する際に、新規バージョンとなります。HTTPヘッダーのAPIバージョンを設定することでバージョン変更前の仕様が保証されるようになっているため、仕様変更に対応できていなくても加盟店様はAPIバージョンを指定することで、決済への影響を回避できます。 実は、既存のWebAPIには、リファレンスに載せていない「隠しパラメーター」があります。特定のお客様だけが利用できる裏メニューのようなもので、通常のリファレンスとは別のドキュメントを作って管理しています。しかし、OpenAPIタイプではOASにすべてを記述することもあり、隠すことが難しくなりました。解決策として、すべてのエンドポイントにadditionalOptionsという任意のMap形式のパラメーターを用意し、このMapに隠しパラメーターを設定してもらうようにしています。 おわりに OpenAPIタイプの接続方式のリリースによって、これまで取引実績のなかったお客様からもお声がけいただけるようになったほか、決済手段の追加にハードルを感じていた既存のお客様からも高い評価を得ています。橋本は「OpenAPIタイプが今後より多くのお客様に愛されるプロダクトとなるよう、今後もプロダクトの価値向上に励んでいきたい」と意気込み、講演を締めくくりました。

10月17日（水）に開催された「技育CAMPアカデミア -Vol.04」においてデベロッパーエキスパートの駒井 直が登壇し「あなたのプログラミングを仕事のコードにするためのTips集」というタイトルで勉強会を開催しました。イベント告知：https://developers.gmo.jp/37619/ チームで信頼されるプログラミングの考え方をお見せしたい 技育CAMPアカデミアシリーズ、自分のテーマは学生さんの日常的なプログラミングでは恐らく気にしない（であろう）仕事の現場で気遣いしてくれると嬉しいポイントについて、簡単な問いを投げかけ思考してもらいながら紹介していきました。エンジニアの卵である参加者の皆様が、未来に"頼れるね、助かるね"と言ってもらえる助けになると良いな、という思いでお話ししました。 登壇者 GMOインターネットグループ デベロッパーエキスパートGMOペイメントゲートウェイ株式会社駒井 直（本稿執筆者） セッション「あなたのコードをプロのコードにするtips集」より 誤解を解く（あるいはプロを地続きに感じる） 冒頭5分くらいのスライドから抜粋です。能力や素材の良さとそこから生まれる結果は全く別の出来事で、プロの仕事で問われるのは後者ですよ、という事を前置きしました。参加者は学生さんですから、現時点で分かりやすい指標を持っていない事に不安があるかもしれません。先輩として、それらは"そんなこともできるんだ"という指標であって、作ってほしい価値ではない。価値から逆算していこう、という事をお伝えしたかったのです。 上図における”能力”の部分を伸ばすこと自体は、仕事の結果と何ら矛盾するものではないので、個人が能力を研鑽する事は前提なんだよ、という事もお伝えしました。 具体例を問いかける ここから、いくつか参加者の皆様に問いかけながら、気遣いポイントを示していきました。スライド抜粋します。 プロの仕事はチーム戦 身に覚えあり過ぎるやつ。今でも油断するとやってしまうかも。 はいそうですね、としか言えないコメントはディスクの無駄 コメントは思考のログ。半年後の自分は別人。 プロの現場で仕事をするのはチーム戦。自分以外のチームメイトを意識して作り上げていく事は、参加する学生さんの授業や自宅の開発ではあまり意識しないかなと思います。現場でリアルに助かる事としてお伝えしました。コードの職場見学ですね。 プロの仕事は長期戦 もう1例、スライド抜粋します。 サンプルの力尽き感。もう1つくらいミスリードを仕込めばもっと面白かった。 ここしか指摘箇所ないから、そりゃそうでしょう。反省しています。 経験者から見れば、当たり前ではある 今この瞬間動くことではなくて、将来にわたってなるべく長く動くための配慮をして欲しい。プロの仕事は長期戦。今現在の計算やロジックで未来の姿を表現することがプロのエンジニアの気遣い、違い＝価値なんです、という事を（大分デフォルメした）例でお伝えしました。 この視点。もう一例、検索APIのindex/non-indexによる仕事量の違いをお話ししました。 トラブル発生時や新規事業の立ち上げフェーズなど、技術的な選択基準が瞬発力一択になる場面は存在します。しかしながら、この点を軽く見てしまった結果のリアルも見ているので、インターネットの場を提供する事業の真ん中で働く自分の経験として、将来ある参加者の皆様にはぜひ植え付けたい視点でした。 セッションの締め 本セッションはこう締めました。 伝わったかな 登壇後記 今回の内容は、自分が毎年担当する社内新卒研修のコードレビューにおける、フィードバック頻出事項のまとめが下地です。大仰なタイトルに対して、お話ししたのは地味な内容です。今回出演したのは技育（Geek）campであって、その名の通りdive deepな尖ったテーマにすべきか迷いましたが、参加者の現在地から仕事場でコードを書く姿までをできるだけ地続きにしよう、それが自分が一番実感を持ってお届けできる事と思いこのテーマにしました。（dive deepは歴戦のdeveloper expertsにお任せします！） 結果、多数の学生さんに参加していただき、参加後のコメント率も良好だったので、セッションの終わりまで興味を持っていただけたようで安心しました。ソースコメントのくだりに"やさしさコードですね"と参加者からzoomチャットを頂き、そのフレーズを先に自分が思いつきたかったなぁ。。。そんなやり取りなど、参加者の素直な好奇心に講師側が助けていただきました。"君のコードは実践的で安心できるね"と一度でも言ってもらえたら。参加者の将来にそんな形でお返しできたなら冥利です。

9月26日（火）にオンラインで開催された「GMO Developers Night #38」では、オンライン総合決済サービスを展開するGMOペイメントゲートウェイ株式会社が登壇。決済代行業界初のサポートセンター国際認定を取得したカスタマーサポートの裏側について紹介しました。イベント告知：https://developers.gmo.jp/37658/ 登壇者 GMOペイメントゲートウェイ株式会社 システム本部 カスタマーサポート 部長　田中 弘道テクニカルサポートグループ　佐山 量哉サポート企画グループ　土屋 優希コンタクトグループ 課長　寺村 杏里 笑顔の絶えないハイクオリティなサポートセンター 冒頭では、田中がGMOペイメントゲートウェイ株式会社（以下、GMO-PG）およびカスタマーサポートの概要や特徴について説明しました。 GMO-PGは、オンライン事業者・公的機関等の加盟店に対し総合的な決済関連サービスを提供しており、社名のとおり加盟店と決済をつなぐゲートウェイの役割を果たしている会社です。2023年6月末現在においては、連結加盟店舗数15万5598店、年間連結決済処理件数58.6億件、年間連結決済処理金額14兆円という実績で、毎年営業利益25%成長を目標に増収・増益を続けています。 こうした会社の成長を支えるGMO-PGのサポートセンターは、システム本部の配下に所属しており、コンタクトグループ（G）、テクニカルサポートG、プロセシングサポートG、サポート企画Gの4つのグループから構成されています。 田中によると、GMO-PGのサポートセンターの特徴は大きく分けて5つあるといいます。 1つめは、エンジニア出身者が複数在籍している点。2つめは、ハイレベルな接客業界出身者が多数在籍している点。このような背景もあり、HDI格付けベンチマーク「クオリティ格付け」において、最高評価となる三つ星を6年連続で獲得。また、2023年6月にはセンター認証の最高峰である「HDIサポートセンター国際認定」が決済代行業界で初めて認定されるなど、外部機関からも高い評価を受けています。 3つめは、改善をドライブさせる専任チームがセンターを下支えしている点です。小規模なセンターの場合、改善担当はオペレーションチームが兼務することが多いですが、GMO-PGでは会社や業界のスピードにキャッチアップできるよう改善に向けた専任チームを設けています。 4つめは、メンバーのスキルレベルを見える化することにより、多様なキャリアパスを用意している点です。田中は「エンジニア出身者の多いテクニカルサポートや改善専任チームへの異動など、サポートを1つのサービスとして向上していけるようさまざまな職務がある」と説明します。 5つめは、「とにかく明るいサポートセンター」である点です。センターでは「ありがとう」「笑顔」「素直さ」を行動指針にしており、田中によると「笑顔が絶えないスタッフが揃っており、センター内には常に良い雰囲気が流れている」といいます。 技術的な内容に特化した対応を行う「テクニカルサポートG」 続いて、佐山がテクニカルサポートGの活動について紹介しました。 開発職としてキャリアをスタートした佐山は、顧客の声を聞くことができ、なおかつエンジニアの背景をいかせる職場としてテクニカルサポート職へ転身。現在は、技術的な問い合わせ対応を中心に加盟店やシステム会社のサポートを行っています。 加盟店が抱える悩みや不安、懸念点はさまざまで、問い合わせ内容も多岐に渡ります。たとえば、「決済処理がエラーとなった」「開発を行ううえでどの仕様書を見ればよいのかわからない」「処理フローの想定に問題はないか」など、回答に技術的な知識や経験が求められる問い合わせも多くあります。 エンジニア未経験者がこれに対応しようとすると、開発部門への確認が毎回必要となり回答に時間がかかる、質問の内容がオペレーターに伝わらない、期待どおりの回答が得られず問題が解決しないなどといった問題が生じます。そこで技術的な内容に特化した対応を行うため誕生したのが、テクニカルサポートGです。エンジニア経験者が多く在籍するテクニカルサポートGの強みについて、佐山は次のように話します。 「エンジニアの経験があるからこそわかる悩みや共感できる部分がある。エンジニアと同じ目線に立つことで、加盟店が抱える問題はもちろん、潜在化している問題を発見し、加盟店のシステム運用をより良くしていくことができる」（佐山） サービス導入から安定稼働に向けてアシストすることも、テクニカルサポートGの業務の1つです。そのため、グループのメンバーが営業同行をすることも多いといいます。営業同行では、加盟店システムの担当者も含めて打ち合わせることで、技術的な質問点も含めた不明点を解消していきます。また、それだけでなく、加盟店から改善の要望を受けた際には、開発部門へその声を届けるという役割もテクニカルサポートGが担っています。佐山は「お問い合わせ対応や営業同行を行うなかで、開発側に改善提案をしてシステムに反映させ、それを加盟店にご利用いただくというサイクルが回っている。私たちが加盟店の声を届ける架け橋となることで、複数部署からサポートする仕組みが形成されている」と機能改善に向けた体制について説明します。 たとえば以前、サービスへの接続方式の1つである「リンクタイプPlus」に対して、エラーメッセージがわかりづらいという声が普段のサポートのやり取りのなかからあがっていました。そこで、カード番号の誤りや利用できない支払い方法が指定されているなど、エラーの原因をより具体的に表示されるよう変更しました。 「加盟店からヒアリングした内容をただ開発に伝えるのではなく、具体的にどのようなメッセージがよいのか、システム処理として無理はないかなど、お互いにとってより良い方法を探すことができた。これはエンジニアとして開発や要件定義を行ってきた経験から為せることだと考えている」（佐山） サポート職に転身して良かったと感じる瞬間は、加盟店から感謝の言葉をもらえたときだという佐山。「自分の行った対応が加盟店のためになったと、自己肯定感を感じられる。感謝の言葉は、自分が作ったシステムを活用してもらえていること以上にモチベーションの向上において効果がある」とやりがいを語りました。 サポートの改善活動を専任で担う「サポート企画G」 土屋はサポート企画Gの取り組みを紹介しました。 独立系SIerや社内SEなどを経て2015年にGMO-PGに入社した土屋は、テクニカルサポートに4年従事した後、現在はサポート企画Gにて主にSalesforce関連の利用設計や改善を担当しています。 サポート企画Gは、土屋の入所当時は存在しなかったグループだったといいます。加盟店、決済手段が年々増えることで、問い合わせ対応のための知識習得への負担が大きくなるという状況を打開するため、2019年に改善に特化したグループとして立ち上がったのがサポート企画Gでした。サポート企画Gの設立前は改善活動にかける時間が部門全体で20%しかありませんでしたが、2022年には40%にまで増えています。 現在サポート企画Gでは、サポートにおける各種数値の管理・分析、FAQ・チャットボットといったセルフサポートサービスの運用改善、顧客満足度アンケートの実施、在宅環境の整備など内部の環境整備、社内ナレッジの運用など、さまざまな取り組みを通じて顧客満足度向上を目指しています。 サポート企画Gでは、お客様がなるべく努力をせずに早い段階で問題解決できる「シフトレフト」を目指す取り組みを行っており、そのうち土屋が「一番大きな取り組み」とするのが、FAQサイトの改善です。土屋の入社当時、FAQサイトには専任担当者がおらず、更新も分析もされていない状況でした。そこで有料のFAQシステムを契約し、実際の問い合わせ内容と突き合わせて不足しているFAQは何か分析できるよう、問い合わせを1件ずつカテゴライズしました。また、同じタイミングでPDFマニュアルのオンライン化を行いました。これによりFAQサイトの参照数は増え、加盟店の数が増えているのにもかかわらず問い合わせ数が減少するという効果があったといいます。 現在のFAQサイトは、そこからさらに改善された3代目のバージョンとなります。2代目で利用していたFAQシステムは従量課金制で、参照数が増えるほど費用がかかってしまう状況だったため、社内ナレッジを一元管理でき、他サービスへの展開も可能な別の汎用的なツールへ移行。現在稼働している3代目のサイトへリニューアルすることとなりました。土屋はこの際にエンジニア経験がいきたと振り返ります。 「移行の際にはエンジニア経験をいかし、データの持ち方など今後の発展も視野に入れた構築設計ができた。テクニカルサポート以外でも、カスタマーサポート部では元エンジニアの経験をいかすチャンスがある」（土屋） 2023年4月からは「KCS（ナレッジ・センター・サービス）」を本格スタートしています。KCSは、米マイクロソフトやオラクルといった先進IT企業が参画する非営利団体サービスイノベーションコンソーシアムが発表した方法論です。 KCSの導入以前、問い合わせを受けた担当者は、自身の知識やドキュメント、マニュアルなどを使って回答していました。しかし、KCSではまずはじめに必ずナレッジを検索し、それを利用して回答するという流れになります。既存のナレッジ内に見つからない場合は、ナレッジを新規に作成します。これにより、新人でもベテランメンバー同様の対応ができるようになるメリットがあります。 「KCSは方法論なので、運用方法やシステム設計は示されていない。方法論を理解したうえで運用ルールを作っていく必要があった。私はルール構築に加え、エンジニア経験をいかしてシステム面も担当。お客様対応にSalesforceを利用しているため、ナレッジもSalesforceで検索作成できるように構築設計した」（土屋） サポート企画Gではこれからも、お客様の満足度向上につながる取り組みを続けていきます。 人材教育を担当しセンターの品質を保つ「コンタクトG」 寺村は、コンタクトGの取り組みについて紹介しました。 アパレル会社での接客経験がある寺村。GMO-PGでは電話対応業務からスタートし、現在はコンタクトGのマネージャー職としてチームメンバーの管理、社内各部署との調整等を担当しています。 技術的な内容を扱うテクニカルサポートGに対し、コンタクトGでは、契約に関する手続きや管理画面などの問い合わせに電話・メール・チャットのマルチチャネルで対応しています。 特徴は、ファーストクラスのキャビンアテンダントや大手百貨店の販売員、5つ星ホテルのブライダル担当者など、ハイクオリティな対応が求められる接客経験者が多く集まっている点です。コンタクトGでは、そうした経験者の知見をいかして、品質管理のための対応評価やそれに基づく人材育成も担っています。 特にエンジニア出身者は接客・顧客対応の経験がない場合も多く、知識が豊富にあってもそれをわかりやすく伝えたり、相手の気持ちや状況に適した形で寄り添いを表現したりすることを不得意に感じる人も多いといいます。寺村は「メンバー1人ひとりと会話をしながら、ウィークポイントや成長スピードにあわせて研修を実施していく」と研修の方針について説明します。 初期研修/導入研修では、わかりやすい研修資料を作成・活用するだけでなく、本人からフィードバックの場を設けて研修内容や流れの整合性を見直すことで、カリキュラムのブラッシュアップを重ねています。以前は研修資料が整っておらず、講師の知識レベルによって内容の偏りがあったといいますが、現在では講師向けの研修も実施し、誰が講師になっても情報に偏りなく必要事項が網羅された研修ができるようなカリキュラムとなっています。 導入研修が終わるとOJTに進みます。実際の電話対応において不明点があった場合には、すぐに相談できるよう近くにリーダー以上の先輩メンバーを配置したシフトが作成されているため安心です。1人で顧客対応をするなかで感じる不明点や、導入研修ではカバーできなかった難しい内容については、個別研修やスキル別研修で補っていきます。配属5か月目をすぎると、毎年実施している対応評価、半期に一度受験する全員共通のテストで個々のウィークポイントを洗い出し、それぞれのメンバーにあわせたフォロー研修を実施していきます。 各人のスキルレベルは、受電件数、音源モニタリングのスコア、スキルテストの点数、メールの承認率、KCSナレッジへの貢献などの達成度によって、5段階で評価されます。寺村は「定量的でわかりやすい目標を設定することで、メンバーのモチベーションにつながる。ランクごとのレベル感が明示できるため、サポート全体のバランスを考える際などマネジメントもやりやすくなるメリットがある」と話します。 こうした取り組みの成果もあり、第三者からの高い評価を得ているカスタマーサポート部。寺村は「連続獲得のプレッシャーはある」と明かしながらも、「モチベーションにつながる面もあるうえ、加盟店にもより安心・信頼して使っていただける」と第三者評価の効果を説明します。そして「優しく思いやりのある対応がサポートにとっては大切。これを念頭においてよりご期待に応えられるよう、さらなる顧客満足度向上を目指していきたい」と今後の展望を語りました。 エンジニア採用実施中！ GMO-PGではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用HPをご覧ください。 また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。https://www.gmo-pg.com/blog/feature/feature03/ さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは、御社の取り組みを理解することができました、自らの参考にできる部分があれば取り入れていきたい、教育体制についてとても勉強になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/mcgoDy1M9TA

6月4日（日）に開催されたJavaコミュニティイベント「JJUG CCC 2023 Spring」に、GMOペイメントゲートウェイ株式会社 坂口健太が登壇しました。セッションでは、ヒューマンエラー防止の考え方をもとに、開発者が安全に開発できるようにするためのSpring Bootプロパティの運用について、実装例を用いて解説しました。 登壇者 GMOペイメントゲートウェイ株式会社システム本部 関連事業サービス統括部 後払いサービス部 後払い決済グループ坂口 健太 GMO後払い」ではSpring Bootへのフレームワーク更改を実施 GMOペイメントゲートウェイでは、連結会社であるGMOペイメントサービスが提供するBtoC EC取引向け後払い決済サービス「GMO後払い」の開発を行っており、直近ではSpring Bootへのフレームワーク更改を行っています。 Spring Bootのプロパティ機能・プロファイル機能を活用することによって、環境依存の部分を外部化することができます。しかし、設定を誤ると、テスト用であるはずの設定が本番環境に適用されてしまうといったさまざまなリスクが考えられます。 そこで本セッションでは、「GMO後払い」の開発における実装例を用いて、ヒューマンエラーを防ぐためのSpring Bootのプロパティ運用について坂口が解説しました。 なお、本セッションでは次のソフトウェアとバージョンを使ってコードを紹介しています。 ヒューマンエラー対策の概要 ヒューマンエラーの対策としては、まず、ヒヤリハットも含めたヒューマンエラーをリストアップし、分類します。そして、それぞれの背後要因を洗い出し、対策案を列挙。このうちコストや時間を踏まえ実行可能な対策を選択・実施し、評価するという流れで進めていきます。 ヒューマンエラーを分類すると、「認知」「判断」「記憶」「行動」の4つに分けられます。このうち、「認知」に起因するエラーの背後要因の例としては、マニュアルが読みにくい、モニターが小さすぎて文字が読みづらい、部屋が熱くてボーッとする、二日酔いで頭が痛い、疑問点を上司に聞きづらいなどといった項目が考えられます。それぞれ一般化すると、ソフトウェア、ハードウェア、環境、心身・能力・経験・モチベーション、人間関係・コミュニケーションの問題として分類できます。坂口は「こうして要因を明らかにすることがトラブルを最小限に留めるために重要な手順と考えている」と話します。 ヒューマンエラーの発生確率を下げるには ヒューマンエラーの対策手法は大きく分けて、未然に防ぎ発生確率を下げる「発生防止」、エラーが起きた際に速やかに検出する「波及防止」、被害を最小限に抑える「影響緩和」という3つの対策があります。 ヒューマンエラーの発生確率を低減させるものとしてそれぞれどのような対策があるかをリストアップした表が以下になります。坂口によると、上のものほど効果が大きいため、対策案を検討するには上から順に進めていくことが望ましいといいます。本セッションで坂口は、このうち1〜4について詳細を解説しました。 Spring Bootのプロパティ運用のリスクとは 対策を考える前にまずは、Spring Bootのプロパティ運用のリスクを整理しておきます。 想定される問題の1つめは、ローカル環境でプロパティファイルを変更していたが、下記のようにsrc/main/resources/application.yamlの実行状態がmodifiedになっているケースです。 この場合、いくつかの要因によって、ローカル環境用の設定が本番環境にデプロイされてしまうリスクが考えられます。要因としては、部分コミット（hunk）したつもりが全量コミットしてしまった、期限が迫っていたためあまり確認せずにコミットしてしまった、いつもどおりで大丈夫だろうと思いあまり確認せずにPull Requestをマージしたなどといったことがあげられます。 2つめは、開発者がSpring Profilesを指定する場合、ローカル環境に接続するつもりがステージング環境に接続してしまうといった形で想定とは異なる環境に接続するケースです。 そして3つめは、プロパティに間違った値を設定してしまうケースです。数値の桁や単位の誤り、値の範囲の誤りなどが考えられます。 Spring Bootのプロパティ運用の改善方法 これら3つの問題の発生を防止するため、下記1〜4の対策をそれぞれ適用していくことを考えます。 作業そのものをなくす・減らす人が作業しなくてもいいようにする仕様外の入力・操作をできないようにするUI/UXを改善しわかりやすくする 坂口は「どの対策も工夫レベルのものなので導入の難易度は高くない」と説明します。 以下で順番に見ていきます。 1.作業そのものをなくす・減らす ヒューマンエラーにつながる作業をなくす、または減らすことで発生確率を減らすという考え方です。Spring Bootのプロパティ運用では、src/main/resources/application.yaml を変更しなくてよいようにするということになります。下図のようにgit statusコマンドを実行した際、application.yamlがmodifiedとして出てくる機会を極力減らすことで、ヒューマンエラーを回避します。 1-1. プロパティを環境変数として渡す 1つめの対策としては、プロパティを環境変数で渡すことがあげられます。環境固有の設定をapplication.yamlを変更せずに環境変数経由で渡すようにするということです。dotenvという機能（またはそれに相当する機能）を利用するのが一般的な方法です。 坂口は、Gradleのカスタムプラグインの実装を例に解説していきました。下記が、カスタムプラグインのビルドスクリプトです。 buildSrcディレクトリにbuld.gradle.ktsを作成。pluginsブロックではjava-gradle-pluginを指定。6行目以降のgradlePluginブロックではプラグインの名前や実装クラスを指定 次に、プラグインの実装クラスです。 1つめの赤枠の部分でJavaのプロパティファイルを読み込み、Gradleのタスクで環境変数として渡せるようプロパティクラスをMapに変換している。2つめの赤枠の部分で、1つめの赤枠でロードした環境変数のMapを追加している 1つめの赤枠内で使用していたメソッドはそれぞれ下記のようになっています。 プロパティファイルを読み込む処理と、 java.util.Propertiesクラスのキーと値をストリング型とするMapに変換している 続いて実際のプロジェクトに作成したdotenvプラグインを適用します。 PluginsブロックでプラグインIDを指定している なお、環境変数経由でプロパティを渡す場合、Configuration yamlのプロパティの名前を一定のルールに従って変換します。たとえば、ドット（.）をアンダースコアに置換したり、ダッシュ（-）を削除したり、大文字に変換したりといった具合です。下記は、データベース接続時のドライバークラス名を指定する際のspring.datasource.driver-class-nameというプロパティを環境変数として渡す場合の例です。 実行した結果は下記のとおりです。 env.propertiesファイルでは、先のルールに従ってAPP_MODEを大文字で定義しています。アプリのソースコードでは、app.modeのPropertyを取得してログ出力するコードを書いています。Spring Bootのアプリケーション実行後の標準出力の結果が右上です。Gradleプラグインを用いてenv.propertiesファイルの中身を環境変数として読み込み、それがSpringフレームワークのConfiguration Propertyとして参照されることが確認できます。 1-2. プロパティファイルをクラスパス外に配置する src/main/resourcesディレクトリは、MavenやGradleの標準ディレクトリレイアウトでリソースファイルを配置する場所となっていることが前提です。ここでいうリソースファイルとは、設定ファイルや画像ファイルなどのJavaコード以外の静的なファイルを指します。同ディレクトリはビルド時にターゲットクラスパスにコピーされます。つまり、src/main/resourcesディレクトリ内のファイルはJarにバンドルされるため、クラスパス外に配置するということは、src/main/resourcesディレクトリ以外の場所に配置するということを意味します。これにより、誤ってコミットした場合でもJarにバンドルされず、プロダクション環境には影響しません。 ファイルおよびディレクトリ構造は下記のようになっています。 中央赤枠のsrc下のjavaとresourcesディレクトリがjarにバンドルされる。上と下の赤枠はjarにバンドルされない、かつSpring Bootが標準で読み込む場所となっている 具体的には、プロパティファイルは表に記載の順序で読み込まれます。1番目と2番目はクラスパスにあるプロパティファイル、3番目と4番目はカレントディレクトリまたは作業ディレクトリにあるプロパティファイルで、この順序で読み込まれるため、採用される値は後勝ちとなります。そのためクラスパスに本番環境の値が設定されていたとしても、カレントディレクトリ側に開発環境の値を設定することで、本番環境のクラスパスの中にあるapplication.yamlを設定変更せずに開発環境として実行できます。 上の赤枠がクラスパスの外に配置したプロパティファイル、下の赤枠がクラスパス内に配置したプロパティファイル。これでアプリケーションを実行すると、ログには「モード：開発環境」と出力される 2. 人が作業しなくてもいいようにする これは、手作業をなくしてツールやシステムに置き換えることで、手作業に起因するヒューマンエラーが起きないようにするというものです。Spring Bootのプロパティ運用においては、ビルドツールに任せるという考え方になります。 坂口は、1つの例としてspring.profilesの設定をビルドスクリプトに指定する方法を紹介しました。この方法では手作業で接続環境を設定しないため、誤った環境に接続することを防げます。 ローカル環境でSpring Bootのアプリケーションを開発する場合、bootRunタスクとtestタスクの2つのタスクしか実行せず、これらのタスクに対して、spring.profiles.activeというシステムプロパティをGradleのタスク定義にセットするようにしている 3. 仕様外の入力・操作をできないようにする プロパティに誤った値が設定されていたとしても、そのプロパティが実際に呼び出されるまでは通常問題に気づくことができません。そこで、誤った値ではアプリを起動できないようにすることで、早い段階で問題を検出できるようになります。具体的には、Configuration Properties Validationを活用します。 このメリットとしては、Validationをパスしないとアプリが起動できないため、アプリ起動時という早い段階で問題に気づける点にあります。また、Validationのルールをプロパティクラスに定義するため、仕様が把握しやすいという利点もあります。 左上がValidationの条件。monthというプロパティに対して最小値1、最大値12を設定。右上はプロパティに設定した値。ここでは、エラーになるよう0と設定している。標準出力を見ると、app.monthに設定された値、Validationのエラー理由などが表示され、アプリケーションの起動に失敗している 4. UI/UXを改善し、わかりやすくする 視認性、識別性、操作性を向上することで、作業を容易化・確実化し、読み間違いや判断の誤りなどヒューマンエラーになる確率を低減することができます。 たとえば、数字の区切り文字の活用です。数値リテラルの桁の間のどこにでも任意の数のアンダースコアを含められるため、この仕様を活用することで、大きな数字でも認識しやすくなります。 ※セッションでは、「Java言語の仕様」と説明をしていましたが、正しくは「YAMLの仕様」でした。Java言語の仕様にも数値リテラルにアンダースコアを含められる仕様がありますが、application.yamlの部分においては、YAMLの仕様となります。 Any “_” characters in the number are ignored, allowing a readable representation of large values. https://yaml.org/type/int.html Properties Conversionを活用するという方法もあります。Spring Bootでは標準で、時間、日付、データサイズという3つのプロパティ変換の仕組みがあります。これを活用すると、15分という値を設定したい場合、「15m」と定義できます。仮にロング型で単位をミリ秒で設定しなければならない場合も、暗算したり、インターネット検索したりする必要はありません。このように、数値に加えて単位を指定できるため可読性が高いことと、わざわざ単位変換をする必要がないという点がProperties Conversionを利用するメリットです。 まとめ 本セッションでは以上のように、ヒューマンエラーを防ぐSpring Bootプロパティ運用として、ローカル開発やテストを目的とするsrc/main/resources/application.yamlの変更は割ける、プロファイルの指定はビルドツールに任せる、安全なバインドやバリデーションを活用する、認知しやすい表現や型を使うといった対策が坂口より紹介されました。 坂口は「Spring Bootの仕組みを活用し、ヒューマンエラーを防いでもらいましょう」と呼びかけ、セッションを締めくくりました。 エンジニア採用実施中！ GMO-PGではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用HPをご覧ください。 また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。 https://www.gmo-pg.com/blog/feature/feature03/

5月31日（水）にオンラインで開催された「GMO Developers Night #37」では、オンライン化・キャッシュレス化・DXなどを支援する決済を起点としたサービスを提供しているGMOペイメントゲートウェイ株式会社が登壇。公共料金における決済システムに関して、その概要や裏側など幅広いトピックを紹介しました。イベント告知：https://developers.gmo.jp/33096/ 登壇者 GMOペイメントゲートウェイ株式会社 システム本部 プラットフォームサービス 統括部長　高島 貞裕開発部長　飯島 清孝開発課長　佐藤 猛開発担当　鈴木 貴仁 決済関連の事業者で働くということ イベント冒頭では、高島がGMOペイメントゲートウェイ（以下、GMO-PG）の会社概要を説明しました。 GMO-PGは、ネットショップや公共料金などの加盟店とクレジットカードやコンビニ決済といった決済手段を提供する決済会社とをつなぐサービスを展開しています。現在加盟店舗数は16万を超えており、年間決済処理件数は55億件、年間決済処理金額は13.2兆円という実績を誇ります。営業利益年25%成長を目標に掲げ、現在も取引量は増加しており、これに伴いシステム開発の規模も年々増大しています。 登壇者らが所属するシステム本部には約200名のメンバーが所属しており、毎年、新卒・中途を含め30名程度のエンジニアを採用しています。拠点は東京・渋谷オフィスに加え、福岡にも開発拠点があり、2拠点を連携しながら日々プロジェクトが進められています。 GMO-PGのような決済事業者で働くにあたり重要なポイントとして、高島はまず「ミッションクリティカル」をあげます。システムには、24時間365日の高可用性・高信頼性、不正取引・不正アクセスを防止する高セキュリティといった厳しい非機能要件が求められます。高島は「社会インフラであるという自負のもとサービスやその開発を追求しており、それをやりがいに感じているところがGMO-PGのエンジニアの特長」と語ります。 また高島は「マイサービス」、「フルスタック・フルフェーズ」もポイントだといいます。GMO-PGのサービスは完全内製で、要件定義からリリース、運用までのすべての工程を自社パートナー（社員）で担っています。マネージャーを含めコードを書けるメンバーが揃っており、コードでコミュニケーションできるのが組織の強みです。高島は「ドキュメントやソースについて必要なものを自分たちで考えて残していく文化がある」と説明していました。 「マルチビリングパッケージ」と「GMOデジタル請求サービス」 飯島は、公共料金における決済サービスの全体観について紹介しました。 GMO-PGは、2016年4月からの電力自由化のタイミングに合わせて、様々な決済手段を一括で導入できるオンライン総合決済サービス「PGマルチペイメントサービス」をベースとした電気・ガス・水道等向けパッケージ「マルチビリングパッケージ」をリリースしました。電気・ガス・水道等の公共料金は大きく分けて、払込票払い、クレジットカード決済、口座振替という3つの支払い手段があります。 マルチビリングパッケージを利用すると、電気・ガス・水道を提供している加盟店は統一されたインターフェイスで各支払い方法によってユーザーに請求を行うことができます。現在マルチビリングパッケージは、月間1000万件を処理するほどの規模となっています。 一方、紙での手続きが必要となっていた払込票のDXを目指したサービスが「GMOデジタル請求サービス」です。払込票に変わりSMSを利用して支払い用のURLをユーザーへ送付するというもので、PGマルチペイメントサービスに対応している多くの支払方法が可能となります。結果として、印紙代や郵送費を削減でき、ペーパーレス化を実現できます。SMSを利用するため、支払い忘れ防止のためのリマインド送付、削除してしまった場合の再発行、督促の案内なども可能となっています。月間約400万件、1日約20万件の処理に対応可能です。 また、マルチビリングパッケージとGMOデジタル請求サービスをあわせて利用することで、クレジットカードでの支払いをシームレスに継続払いへと切り替えることもできるようになっています。 マルチビリングパッケージ開発の裏側 佐藤は、マルチリビングパッケージ開発の裏側について紹介しました。 マルチリビングパッケージは、拡張性・安定性の2つを意識したサービスになっており、マイクロサービスの考え方を採用しているのが特長です。具体的には、下図のようにプレゼンテーション部分と共用ビジネスロジック部分を分離。プレゼンテーション部分は、会社ごとの要件に応じてUI・ファイルのインターフェイスを完全に分けています。共用ビジネスロジック部分は、支払方法、業務、会員処理、取引売上処理といった単位で分かれており、クレジットカード会社や外部の収納機関等と接続している部分でもあります。 こうした形でマイクロサービスを採用するメリットは、細かい単位で開発できる点にあり、佐藤は「担当しているお客さまごとにチームを編成しやすく、小さな規模感で開発を進められる」と説明します。また、障害ポイントを特定しやすいというメリットもあります。障害によってどれだけ影響が生じたのか調査範囲も限定しやすく、報告の際にも説明しやすくなります。リスクを取りやすいため新しい技術を積極的に試せる点、1つひとつのシステムのサイズが小さいため、ビルド・テスト・デリバリーといった一連の開発サイクルを高速に回せる点などもマイクロサービスのメリットになります。 一方で、リグレッションテストの強化は課題です。共用ビジネスロジック部分は共通要素を取り持つ部分になるため、万が一サービスの修正や変更時に十分なテストができないと、場合によってはシステム全体に影響が出てしまう可能性があります。佐藤によると、この対策として現在途上段階ではあるものの、特にビジネスロジック部分は、単体テスト、結合テストのレベルまで自動化することを社内標準としているといいます。 佐藤は、マイクロサービスについて「お客さま単位、会社単位で並行して開発を進めるスタイルと相性がよいアーキテクチャ。一方で、レイテンシーの問題やデータの一貫性が保たれないといった負の側面もある。（採用するかどうかは）それらをすべて理解したうえで判断したほうがよい」とコメントしていました。 マイクロサービス化に加え、拡張性・安定性を担保するためのもう1つの取り組みとして、等身大の分散化処理があります。 もっともボリュームがあるクレジットの一括請求処理を例に見ていきます。まずは、Job Controlサーバーで個社などのブロックごとにA、B、C……と分けています。こうして個社単位にしたブロックをマルチスレッドに分割して並列に処理します。データベースは、クエリ生成のオーバーヘッドが発生しないようBULK処理によって一斉に書き出しを行います。 このような構成にするメリットについて佐藤は、「マイクロサービスと同様、障害発生が特定のお客さまに限定される。イレギュラーな事態が起きた際に最小限で済むようにすることを強く意識している」と説明します。 クレジット処理という重要なシステムを扱うにあたって、ブラックボックスを排除するため、慣れ親しんだPure Javaですべて構築しているのも特長です。佐藤は「地味だが、安定的に運用するために重要な点」とします。顧客ごとに異なる性能要件に応じてリソースをチューニングしやすい点もメリットの1つです。佐藤は「お客さまによっては短期間で1000万件を超える処理が必要な場合もあり、ハードごと調達して専用サーバーを構えるといった判断もしやすくなる」と説明します。 マルチビリングパッケージ開発チームは、仕事をするうえで「現場を知る」「挑戦する」という2点を大切にしているといいます。「本当の意味でお客さまが望むデジタル化を果たすには、お客さまの業務やシステムを深く理解することが大事。また、システムの規模が大きくなるにつれ、リスクも増えていく。そうしたなかでユーザビリティ向上、品質確保、コスト削減をどう実現できるか、日々新しいことに挑戦して課題解決していく思考能力が求められている」（佐藤） GMOデジタル請求サービスの裏側 鈴木は、GMOデジタル請求サービス開発の裏側について紹介しました。 GMOデジタル請求サービスのシステムは、AWS基盤をベースに構築しつつ、オンプレミスとも併用する形としています。2018年の開発当時、AWSを使ったサービスはGMO-PG内にはなかったといいますが、なぜAWSを選定したのでしょうか。鈴木は理由の1つとして、性能要件に柔軟に対応できる点を挙げています。「最初の加盟店では、月間400万件の請求依頼・処理が発生。1日あたり20万件となるが、24時間のうち均等にエンドユーザーが決済処理するわけではなく、SMSが送信された瞬間など決済が集中してしまう時間がある。クラウドは基盤性能を柔軟に変更できるので、このムラに対応できるのがメリットだった」（鈴木） また、決済処理の根幹には既存のPGマルチペイメントサービスを利用することによって、AWS上にはカード番号を保持する必要がなくなった点も、AWS導入に踏み切れた理由の1つだったといいます。当サービスの主なアプリは、エンドユーザーがブラウザ上で支払手続きする支払画面、加盟店の管理画面、加盟店のシステムから利用するAPI、業務バッチ群から成り立っており、AWSに構築しています。 一方、加盟店とのファイル連携およびジョブ管理の用途で一部オンプレ環境が利用されています。オンプレ環境でファイル連携する理由としては、既存加盟店に既存ルート・回線を使って当サービスを新たに導入してもらいやすい、加盟店とのファイル授受からジョブ管理までの処理を一気通貫で行える、といった点が挙げられます。ジョブ管理には別サービスのオンプレ環境で使っていたJP1を利用しており、そのノウハウが活かせる点も重要でした。 オンプレ環境のジョブ管理サーバーからAWS上のバッチジョブを実行する際や、ファイルをAWS～オンプレ環境間でやりとりする際にはDirect Connectという専用線を通して行います。 各アプリはDockerコンテナで稼働するようになっており、ECSというAWSのサービスによって全自動で管理されています。コンテナの実行環境であるデータプレーンにはFargateを利用しています。ECSやFargateを利用することでインフラ管理が不要となり、開発者はビジネスロジックの実装に専念することが可能となります。また、Fargateの読み取り専用化機能を有効にすることでアプリケーションの不正改ざん防止につながるなど、セキュリティ強化という面でもコンテナ化のメリットは大きいです。 プログラミング言語はJava、フレームワークとしてはSpring Bootを利用しています。コンテナはタスクという単位で実行されており、アプリケーションの負荷状況によってオートスケーリング機能で自動的に増減させています。この機能は、時間帯によってユーザーからのアクセス数が偏ってしまう当サービスの特性とも相性がよいといえます。また、マルチAZ構成にすることで可用性を高めています。 GMOデジタル請求サービスでは、今回取り上げていないAWSサービスも多く利用しており、鈴木はオンプレとAWSを適材適所で使い分けることで、支払い方法の拡充、SMS以外の通知方法の拡充など、今後もスピーディーに新機能を加盟店に提供していく考えを示しました。 エンジニア採用実施中！ GMO-PGではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用HPをご覧ください。 また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。https://www.gmo-pg.com/blog/feature/feature03/ さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは、どのようなサービスを提供しているのか･システム構成なのか、非常に参考になえいました、決済システムならではの考慮点など非常に勉強になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/yFnHp9KAvhA

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は2日目にリアル会場で開催された「入社2年でリーダーも！次の未来を担う、若手エンジニアたち」をご紹介します。 登壇者 スピーカー 土井 万由子GMOインターネットグループ株式会社システム統括本部アプリケーション開発本部 ホスティング・クラウド開発部 ConoHa/Z.comプロダクトチーム マネージャー2017年に新卒入社後、レンタルサーバー「ConoHa」や「Z.com」チームの開発業務に携わってきました。2022年10月からConoHa/Z.comチームのマネージャーに就任。現在チームメンバーのフォローや案件の調整などを担っています。松窪 昂GMOペイメントゲートウェイ株式会社システム本部 プラットフォームサービス部 ユーティリティ決済グループ 課長土井と同期となる2017年に新卒入社。公共料金決済サービスや基幹システムの開発運用を行ない、こちらも土井と同じタイミングの2022年10月からプラットフォームサービス部 ユーティリティ決済グループの課長に就任。現在、サービス・システムの開発全体はもちろん、チームメンバーの管理も行っています。鬼塚 雅也GMOインターネットグループ株式会社システム統括本部アプリケーション開発本部 アクセス開発部 とくとくBBプロダクトチーム リーダー2019年に新卒で入社後、システム開発本部のアクセス開発部とくとくBBプロダクトチームに配属され、プロバイダーサービス「GMOとくとくBB」のフロント領域を担当後、バックエンドに転向しました。現在はバックエンド業務と並行して開発チームのリーダーを担当しています。 モデレーター 石丸 智輝GMOアドマーケティング株式会社開発部 開発6グループ マネージャー2016年にGMOアドマーケティングに入社後、自社プロダクトの開発に携わりながら、現在はマネージャーとしてチームマネジメントや新卒研修・採用を担当、さらにテックブログ運用といった社外向け広報も担っています。 GMOアドマーケティング 石丸、GMOインターネットグループ 土井、GMOペイメントゲートウェイ 松窪、GMO インターネットグループ 鬼塚 GMOインターネットグループは、ドメインからセキュリティ、決済までビジネスの基盤となるサービスをご提供するインターネットインフラ事業を主軸に、インターネット広告・メディア事業、インターネット金融事業、暗号資産事業を展開する総合インターネットグループです。お客様に喜ばれるサービスを迅速かつ低価格で提供するために、サービスは機器の選定から設置、構築、開発、運用までを内製化することを基本方針としています。 そんな各サービスやプロダクト開発を先導するに辺り、開発現場をそれぞれチームのリーダーがとりまとめて開発の進捗管理に努めます。さらに開発全体の管理をマネージャーが担っています。各開発チームの進捗管理はもちろん、ビジネスサイドのメンバーからヒアリングをして、その結果を反映するといったステークスホルダーとの連携・調整も行っています。 マネージャーは、納期通りに質を担保したシステムを開発するため、適切に状況を把握するのはもちろん、技術周りの仕様変更を策定したり、適切にチーム運営を行い、チームとメンバーの育成にも努めて成長に貢献するなど、プロジェクトが円滑に成し遂げるために重要な立場です。 GMOインターネットグループの全110社に在籍する7,200名超のパートナーのうち、ITのモノづくりを担う開発者（エンジニア・クリエイター）は49.9%（※数字はいづれも2022年9月末時点）を占めています。そのためグループ各社で、リーダー・マネージャーという立場を新卒入社であっても2年目から目指すことができる土壌があり、多くの社員がリーダー・マネージャーとして活躍しています。 本セッションは、GMO インターネットグループに新卒入社後、現在チームを先導する立場にあるリーダー・マネージャーの4人が参加して、これまでの経緯や、就任後にどういった環境の変化があったか、さらに今後の展望までを語りました。 それぞれリードするチームについて システムの開発にはさまざまな人が関わっています。目標とするシステムを開発するため、その都度変化する課題を理解し、適切に処理をしていくことが必要です。そのためには、バランスを見ながらメンバーをプロジェクトに配置するのはもちろん、最適に業務の振り分けを行うといったチーム運営が大切になっていきます。 若手リーダーである4人はどのようなチームを先導しているのでしょうか。まずは、モデレーターを務める石丸が、それぞれ3人に話を聞く形式でセッションを進行しました。 GMOアドマーケティング 石丸 石丸私は「AkaNe」「ReeMo」といった、GMOアドマーケティングが自社開発している広告配信プラットフォームの開発にマネージャーという立場で携わっています。案件の整理と優先度の調整を行ったり、チームマネジメントとして1on1 を実施するなどメンバーとコミュニケーションを取っています。自分も含めて5名と小規模なチームですが、皆さんはどうでしょうか？ 私はレンタルサーバー「ConoHa」や「Z.com」のサービス基盤で、お申込みや決済部分のAPIやバッチの領域の開発運用を行っています。私自身、2022年10月にマネージャーに就任したばかりです。チームは現在12名、なかでも新卒が10名いるフレッシュなチーム体制です。そのため入社2年目のメンバーに新卒の教育を担ってもらうなど、新卒の育成に力を入れています。土井 GMOインターネットグループ 土井 松窪私のチームは自治体・公共機関向けとして払込票に代わりSMS（ショートメッセージ）を活用して決済いただくといったサービスや、当社が持つデータをカード会社様に提供する過程で必要な基盤システムなどを、主に取り扱っています。チーム全体で、システムやサービスを5つ管理しており、大手企業のお客様と接する機会が多いのが特徴です。エンジニアも営業と提案フェーズから同行することも頻繁にあります。メンバーは9名で、新卒入社からのメンバーが私を含めて4名。あとは中途入社のメンバーが5名います。私は年齢的にチーム内では真ん中あたりです。中途入社のメンバーは年齢的には先輩となるため、サポートを頂きながら案件を進めています。 GMOペイメントゲートウェイ 松窪 私は、プロバイダーサービス「GMOとくとくBB」のコントロールパネルや、裏側で走っている課金システム、さらに各種データ連携を担っている領域の開発に携わっています。チーム全体では東京と北九州（GMOインターネットグループ開発拠点「GMO kitaQ」）が混合になっており、40名が在籍している大所帯です。そのなかで私は5名の小規模なチームリーダーを任されています。鬼塚 GMOインターネットグループ 鬼塚 優れた開発チームを目指すべく、重要なコミュニケーション それぞれがリードするチームの紹介後、石丸は「リーダーとして心掛けていること」を聞くと、コミュニケーションに関する話が多くあがりました。メンバー同士の相互理解はもちろん、気軽に相談しやすい環境であることは、開発をスムーズに進みやすくさせて、プロジェクトの成功につながります。 毎日のコミュニケーションからチームメンバーのコンディションを把握することを心掛けています。新卒など若いメンバーが多いので、モチベーションの維持は意識しているところですね。出社しているときは積極的に声をかけて、業務内でも雑談をしたりしています。またGMOインターネットグループならではですが、福利厚生のひとつに従業員が誰でも利用できるコミュニケーションスペース「シナジーカフェ GMO Yours」で、毎週金曜日に「Barタイム」というものが開催されます。Barタイムでは無料で飲食が提供されるのですが、そこにチームメンバーを連れて、ほぼ毎週、参加して気軽にコミュニケーションを取っています。鬼塚さんのチーム同様、私のチームも北九州（GMO kitaQ）オフィスのメンバーがいます。所属するシステム本部は執務フロアに「どこでもドア」という巨大モニターがあって、北九州の執務フロアと常時接続されています。なので「どこでもドア」に向かってメンバーへ手を振ってみたり（笑）お互い気にかけています。土井 松窪私のチームも福岡勤務の方がいます。GMOペイメントゲートウェイは「どこでもドア」のような常時接続されたモニターは持ち合わせていないので、オンラインでの1on1でコミュニケーションを取っています。1on1はチームメンバー全員と定期的に行っていますが、大きく２つのことを聞いています。ひとつは「目標の達成状況」そこで目標への認識を合わせたり、摺り合わせを行っています。もうひとつは「フリートーク」で、最近、ハマっていることなど、ざっくばらんに話を聞いています。そうすることで福岡勤務の方とは、東京と福岡で起こったことについて情報交換できるなど良いコミュニケーションの時間につながっています。 石丸私のチームでも1on1を行っていますが、普段からコミュニケーションをとっていると1on1で改まって話すことが意外となかったりするんですよね。なので、目標の進捗確認をしたあとに、フリートークとして最近面白かったことなどを聞いたりしていたので、松窪さんの話を聞いて、まさに同じだなと思いました。1on1 以外で遠方のパートナーと仕事を円滑に進めるため、意識していることはありますか？ 松窪東京と福岡で垣根が分かれないようにチーム力を上げる工夫をしています。例えば5つあるサービス・システムはそれぞれに品質担当を設けて、品質管理を行っています。そこに福岡のメンバーも1つのシステムの品質担当として入っていただくことで、他システムの品質担当との横連携も出来きるなど、メンバー同士コミュニケーションの機会が生まれるように、タスクやプロジェクトを上手く割り当てています。東京と福岡で、物理的な距離はありますが、近くに感じられるように意識しています。 チーム全員で集まることは開発スピードにも影響すると感じます。私のチームは業務委託のメンバーもいるなど雇用形態もさまざまで、社歴も長い方で1年なので、タスクに着手する前に障害になりそうなところを、私の方でドキュメントにまとめ事前に共有していました。ただ私が分からない所と、業務委託で携わっていただく方が分からない所、その不明点が、異なっていたことを知ったんです。そこで現在はプロジェクトに着手する前に、チーム全員で集まり、不明点の解消や工数の見積もり管理を共に行うように変えていきました。ドキュメントは、オンラインのホワイトボードといわれる「Miro（ミロ）」というツールで管理しています。進捗を可視化できるので、とても便利です。鬼塚 リーダー経験から得られたこと 分からないことを分からないと、きちんと聞けるような環境をつくるため、リーダーとして積極的にコミュニケーションを取り、またコミュニケーションが生まれる環境つくりに努めている若手リーダーの皆さん。次に石丸はリーダーの経験から得られたことについて聞きました。 コミュニケーションツールで「Slack（スラック）」を活用していますが、メンバーや案件担当者同士の会話がかみ合っていない事に気付けずメンバーに苦労をかけさせてしまった経験がありました。私だけじゃなくメンバー間での会話でもコミュニケーションに差異が生まれていないか注意深くみるようになりましたね。土井 石丸私も最初の段階でフォローしておけば、こういう形に進めることが出来たのに、と感じるところはあったりしますね。そのためにもどういった会話がメンバーや関係者の間で進んでいくのか把握しておくというのは大切ですね。 そうですね。Slack内のコミュニケーションもですが、細かい変化も見逃さないようにしています。全員が顔を合わせる朝会を、zoomを活用して1日1回やっています。毎朝、全員の顔を見て、体調が悪そうな人はいないかなとか気にかけています。土井 松窪リーダーの経験から、メンバーに頼ることの大切さも得られました。私はメンバーのリソースが足りなくなった時に、自分で巻き取れるよう常に80％のリソースで稼働するよう意識しています。それでも管理業務と自分の業務のバランスを保つのが難しく、最初の1カ月は、管理業務になれることで精いっぱいで、1日ひたすら「承認」のボタンを押している日もありました。そこで、それぞれのサービスに開発リーダーを置いて、基本的にその方に任せて、自分と開発リーダーの2人体制でサービスを見るという形を取っています。あとはチーム内にマネジメント経験者がいるので、その方から、業務の進め方などアドバイスも貰っています。 石丸マネージャーのどこが大変とか、どのようなフォローがあれば動きやすくなるか、などはマネジメント経験者じゃないと分からない所もあると思うので、チーム内に経験者がいるのは心強いなと聞いていて思いました。具体的にどういったアドバイスをもらいましたか？ 松窪「どんどん人に仕事をフリなさい」と言われましたね。私は80％稼働を意識しつつも、抱え込みがちな所があります。大きな案件が多いチームなので、細かい課題改善を自身がやると巻き取っていくと余裕がなくなっていたりしました。細かい課題が、実は致命的な問題に直結していることが今までにもあったので、定例の時に棚卸をして、関係するメンバーに振るようになりました。そうすることで、メンバーもその業務に対応できるかどうかの意思表示もできるし、認識のズレもなくなるので、いまでは積極的に行っています。 自身のタスクをこなしながら他のメンバーの工数管理をしていると、他のメンバーの作業が気付いたら終わっていて、手が空いていたといったことがありました。進捗の管理にはコミュニケーションを積極的に自分から取りにいく必要性を感じましたね。今は週3日で出社、2日はリモートワークという体制です。出社時は、こちらから積極的に声掛けしたりしていますが、オンラインの際は「discord」というツールを使っています。常にマイクミュートで同じチャンネルに入って、質問がある時に声をかけていただいています。チャットだとどうしてもメッセージを投げてから返ってくるまで時間のラグがありますが、すぐ聞ける状態にしておくことで、レスポンスよく返すことが出来るので良かったです。雑談している内容から、話がどんどん広がっていき、出社の際もその話をして盛り上がるなど、話題も広がっていくので良かったなと思います。鬼塚 石丸チャットだとどうしても１対１になってしまいますよね。誰かが聞いている環境をつくれるというのは、「discord」のようなツールじゃないとできないので、確かにいいですね。 今後の展望について セッションも終盤に差し掛かり、石丸は３人に今後の展望について聞いた。 私は10月からマネージャーになったばかりですので、メンバーに迷惑をかける点はあると思いますが、よりよいチームマネージャーに出来るようにという所と、マネージャーにとどまらず、さらにその上も目指していけるように努力していきたいと思っています。土井 松窪私も10月にマネージャーになったばかりという所で、少しづつ管理業務にも慣れてはきたので、次のステージとしてチームビルディングも、意識して、勉強していきたいと思っています。またマネージャーだけでなくエンジニアでもあるので、プレイングマネージャーとして、自身の技術力も高めていき、案件の技術面もリードできるよう努めていきたいです。 4月にリーダーになって1年が経とうかとしていますが、管理業務や自身のバックエンドの業務もまだ出来ない所が多くあります。バックエンドとフロントの両面で技術力を上げていき、リーダーからマネージャーという所を目指して、頑張っていきたいと思います。鬼塚 さいごに セッションの終わりには、質問タイムが設けられました。鬼塚からも皆へ、日々の進捗管理で工夫されているところを聞きました。 Ｑ：メンバーの進捗管理での工夫 石丸毎朝行っている朝会では、案件の詳細はもちろん、タスク毎に期限を決めていたりするので、期限に遅延が発生していないか？なにかリリース物があるか？困っていることはないか？など、細かく報告してもらうことを意識しています。 私は12名のチームなので、なかなか1回の朝会で全員の進捗を聞くことができなくて、マイクロチームとして、コンパネ担当、バックエンド担当と分けて、別枠で朝会を開催しています。そこで詳しい案件の話や、進捗共有をいただいます。土井 松窪私も同じように、各チーム毎に定例を別で組んで実施しています。全体のグループ定例では、自分たち以外のサービスも把握しましょうと、一段、高い目線を持ってもらうということも意図としてあります。またその定例では各チームの進捗担当者に、それぞれチームの報告をしてもらうということはじめました。 4人は、チャットから寄せられた質問にも答えました。 Ｑ：新卒のときからリーダーになろうとしていましたか？ 石丸入社当時は考えていなかったんですが、GMOアドマーケティングにはバディ制度という仕組みがあります。新入パートナーと先輩が2人一組となり、一人ひとりの特性に合わせて育成計画を考え、一日でも早くひとり立ちできるよう実務を通してサポートする制度です。その制度を通じて新卒の方の成長する姿を見ていて、やりがいを感じました。また学生の頃に塾講師をやっていて、そのときも生徒の方が成長する姿を見るのは楽しかったので、重なる部分はありますね。もちろんエンジニアとしてコードを書くのも大好きなんですが、メンバーやプロダクトが成長する姿を感じられるという所で、リーダー・マネージャーというポジションは合っていると思っていたので、私は入社2年目ぐらいからリーダーというポジションを意識していました。 私は「夢はでっかく」じゃないけど、新卒の時から「上を目指していこう」という気持ちはあったので、自身の努力もありましたが、運よくとんとん拍子できた感じで、新卒の頃から役職が着々と積み上がってきました。土井 松窪入社時にエンジニアのキャリアプランを考えた時に、マネージャーという所もあるのかなと思っていました。私も新卒３年目のときから、石丸さんと同じでアドバイザーとして、新卒の面倒をみるようになり、彼らが成長していく過程をみるのがやりがいに繋がっていたので、徐々にリーダーというポジションを意識するようになりましたね。 私は入社当初はリーダーになろうと思っていませんでした。ただ新卒研修の監督をさせていただいて、約1年間、そのイベント管理をさせていただいたんです。そうした経験から、リーダーというポジションに興味を持つようになりました。鬼塚 Q：リーダー/マネージャーは“楽しい”ですか？ 石丸楽しい所と、ツライところがあると思いますが、楽しいことは間違いなくあるので、“楽しい”という回答になります。メンバーやプロダクトの成長が大きなミッションのひとつだと思うので、そこを常に意識しながら業務を進めて、実際に成長を感じる瞬間は、マネージャーをやって良かった“楽しい”と感じるポイントだと思います。 私も楽しいです。責任感が大きくなってくる分、やりがいがあるお仕事になるので、すごく楽しいと思う反面、上司から怒られたり、日々、色々あるので、喜怒哀楽は激しくなったりしますが（笑）楽しくマネージャーをさせてもらっています。土井 松窪私も皆さんと同じですね。ツライ時もありますが、楽しいと思う時もあります。関わる人がすごく増えたという実感があります。同じシステムのメンバーはもちろん、営業のメンバーなど、サービスのシステムを改善運用していくなかで、早い段階で、相談いただくことが増えました。それだけ自分たちの商材を育てていく所に携われているという充実感があります。あとはとてもいい感じにメンバーが成長していることが、自分にとっても励みになっているので、そういった所も含めて楽しいなと思っています。 私も皆さんと同じく色々ありますが、楽しいです。チームメンバーをどう管理するかで、進捗にも影響が起こります。最初は遅れてしまい調整することも多かったですが、チームメンバーと改善を重ねて、期限までにクオリティも担保されたものを開発できるようになっていき、それがすごく楽しいと感じる瞬間になっています。鬼塚 若手エンジニア、若手リーダーというワードが飛び交っていた本セッション、「これからリーダーを目指そうとする方、またリーダーに就任したばかりの方に、参考になれば幸いです」と石丸が挨拶して、本セッションを締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/qYlHXQDsypI

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は2日目にリアル会場で開催された「クラウドネイティブセッション」をご紹介します。 登壇者 スピーカー 山下和彦GMOペパボ株式会社技術部技術基盤チーム佐藤慎治GMOグローバルサイン・ホールディングス株式会社マネージドサービス事業推進室山崎牧彦GMOペイメントゲートウェイ株式会社ITサービス統括部オペレーション・セキュリティ部サービス運用 モデレーター 長谷川泰斗GMOインターネットグループ株式会社インフラ・運用本部クラウドサービス開発部コンピュートプロダクトチーム （左から）GMOインターネットグループ 長谷川、GMOペパボ 山下、GMOグローバルサイン・ホールディングス 佐藤、GMOペイメントゲートウェイ 山崎 クラウド移行で、気になる「従量課金」 GMOインターネットグループのエンジニア4人が集まったセッション。クラウドだけでなく、オンプレミスのサービスにも精通している4人が、自社のサービスで利用するサーバーやアプリケーションなどについて語り尽くしました。 最初にモデレーターの長谷川が問いかけたのは、「従量課金の計算」について。オンプレミスからクラウドに移行した場合、従量課金で毎月の料金がどの程度変わるのか、という点を尋ねました。 GMOペイメントゲートウェイでは、AWS（Amazon Web Services）を採用していて、請求単位のAWSアカウントがサービスごと、環境ごとで分かれていていると山崎は説明。サービスごとに稟議を出して、それを元に予算が決まっていると話します。「円安で予算の計算が狂わなかったか」と問われ、山崎は「計算は狂っていませんが、それでも円安は大変で、コスト削減策も考えています」とのこと。 GMOペイメントゲートウェイ 山崎 コストに関しては、AWSの機械学習を用いたコストの異常検知アラーム設定を活用。特定のアカウントで急にコストが上がれば通知するという設定にしているといいます。 急激なコスト増だけでなく、「AWSでよくあるのが、ちょっとした作業でインスタンスを起こした際に、後で終了させるのを忘れてしまうこと」と話したのが山下。こうなってしまうと、ずっとコストがかかり続けてしまいます。 こうした状況に対して山崎は「定期的に棚卸しをする」という対策を示しますが、それでもアカウントの数が多いことで、担当者によっては放置されてしまうこともあり、注意が必要と話します。そのため、インスタンスの監視運用のためにLamdaを使って、「定時内しか起動しない」などの設定を実施しています。 佐藤は、 「同社がB2B向けの運用サービスを提供しており、コストの請求ツール提供、コストの監視設定、サーバーのトラフィック、サーバーのパフォーマンスといった監視も可能です」としています。ただ、それでも全てを完全にチェックすることは不可能で、コストなどに大きな変化があった場合に「SNSやSlackに送る」という使い方を紹介します。 どのようにナレッジの共有を行っているか 続いての質問では、長谷川がVM（仮想マシン）からコンテナ、オンプレミスからコンテナといったように、クラウドへの移行に際してのナレッジ共有をどうしているのか、と問いかけました。 GMOペパボは、山下が入社してすぐの7年前頃にはプライベートクラウドのOpenStackでサーバー基盤を開発していましたが、現在はコンテナに移行していると説明しました。OpenStackは、GMOインターネットグループのConoHaで使われており、そのナレッジがあったのでそれを活用して構築したものです。 GMOペパボ 山下 当初はサーバもレンタル契約でConoHaのOpenStackのノウハウをそのまま持ち込んでいたのですが、その後はサーバも自社で調達し、OpenStackのバージョンアップをしたほか、Kubernetesへも移行して、社内でコンテナ技術に関する知見を深めていきました。同社のサービスである「ロリポップ！マネージドクラウド」でコンテナ中心のサービスを提供したことでも知見を深められたといいます。こうして自分たちでナレッジを積み上げたのがGMOペパボです。 ちなみに、GMOペパボは事業部制で、「ハンドメイドサービスのminneでは9割がKubernetesで、AWSとオンプレミスのハイブリッドクラウド」（山下）でサービスを運営しています。。通常はOpenStackで9割のトラフィックを処理していますが、ピーク時にはAWSとオンプレミスの比率を変えることで処理を行っています。当初は手動で比率を変えていましたが、現在はトラフィックに応じて自動で比率を変えるようにしているそうです。 「AWSは移行のためのツールが揃っている」と話すのは佐藤です。「オンプレミスからAWS、クラウドからAWSへの移行など、マイグレーションツールを使うことでどの環境でも移行に対応できるようナレッジを蓄積してきました」と言います。それでも対応できない古いサーバーであれば、どのように対応するかは「お客様に合わせてお手伝いする。結構需要があります」（佐藤）とのこと。 他にも、「マルチクラウドの案件が増えてきている」（佐藤）。Googleの良さ、AWSの良さ、オンプレミスの良さはそれぞれあり、「いいとこ取りをしようと考えています」と佐藤は話します。 GMOグローバルサイン・ホールディングス 佐藤 クラウド利用時のセキュリティについて 次の「クラウド利用時のセキュリティの留意点」という質問には、まず山崎が「AWS Security Hubを使って、なるべく簡潔に運用コストを減らしています」と回答しました。Security Hubで検出された項目に対して、AWSアカウントの担当者に通知して修正してもらい、修正をチェックする、という手順になっているといいます。 GMOグローバルサイン・ホールディングス社のCloudCREWでは、お客様に提供するサービスとしてAWS Security Hubにも対応できるほか、お客様がセキュリティに興味がある、セキュリティを重視しているといった場合には、それ以外のセキュリティサービスも提供できるようにしています。AWSには複数のセキュリティに関するサービスがあるため、お客様にどのようにそのサービスを分かりやすく伝えるか、といった点を考えた結果、「新しいセキュリティサービスの設計をしているので期待して下さい」（佐藤）。 ただ、Security Hubは通知が多いため「ノイジーなところがある」と山下は指摘しました。GMOグローバルサインではSecurity Hubそのままの情報を提供するのではなく、精査をして重要なものだけを通知するようにしていると佐藤は説明。「クリティカルなものを通知するのが一番いい」というのが佐藤の判断です。 山崎もフィルターを設定しており、セキュリティ担当者と精査していると話します。Security Hub上では重要度が低い表示になっていても、環境によってはリスクが高い場合もあるとして、工夫が必要という認識を山崎は示します。 どのようにログを収集して、活用しているか 続いての議題はログ収集について。長谷川は、「Kubernetesでコンテナを立てていますが、コンテナがなくなるとログも消えてしまいます。どう収集していますか？」と問いかけます。 GMOインターネットグループ 長谷川 山下は、ライフサイクルによって変更しているとのことで、「基本的にはコンテナのログを集めて、それをApache Kafkaに出力。さらにそこからAmazon S3に保全する、BigQueryを使って解析に利用する」といった使い方をしているそうです。保存期間が短いログであれば、Grafana Lokiも使っていて、ログの検索もできるようになっているとのこと。 Grafana LokiはURLを使ってログの共有ができる点が便利だと山下。ライフサイクルに関しては、例えばセキュリティ関連のログは3～5年の期間、Amazon S3に保管していると話します。 GMOペイメントゲートウェイでは、オンプレミスのサービスではログ集約サーバーがあるのでそこに保管。AWSを使っているサービスでは、最終的にAmazon S3に集約して、ライフサイクルに応じて処理していると山崎は説明します。同社では、AWSアカウントごとに担当者がおり、それぞれログを調査したいといった場合もあるため、Amazon S3のバケットなどで調査分析をできるようにしているといいます。「集約を忘れないことが重要です」と山崎。 佐藤は、「ログは事件が起きたときに引っ張り出すのが重要」と指摘。「Amazon S3に蓄積して、BigQueryを使って見やすい状態にできるので、クラウドネイティブのサービスでもオンプレミスでも、ログだけは一貫した使い方をします」と説明します。 「実際の事件とまでは行かなくても、ヒヤリハットな事例はありましたか？」と長谷川が問いかけると、山下が「OpenStackのポートの論理情報を全て消してしまったことがありました」と明かしました。OpenStackは構成情報をキャッシュのように保持していて、マスターを消去してしまってもキャッシュが動作している限りは復元できるため、データベースを復旧して事なきを得たそうです。 山崎は、Amazon GuardDutyを設定しておいて良かったと感じているそう。「マネージド型脅威検出サービス」として活用されるGuardDutyですが、これまで一度だけアラートがあり、AWSの権限の設定間違いが検出されていたといいます。これ自体は大きな問題となるものではなかったのですが、通知によって問題に気付くことができたとその効果を指摘。「イベントベースでアラートを発行してくれるというのは、オンプレミスだとなかなか難しいのではと思っていて、それがクラウドの良さだと思う」と山崎は話します。 こうしたセキュリティ系のサービスは「よく分からないことをしているだけで料金が取られる、と感じてオフにしてしまう人もいる」と山崎は注意喚起をして、「地味な足回りですがセキュリティをきちんとやっていくのは大事」と強調します。 セキュリティ面では、スピーカーの山下が他の面々に対して質問もしていました。プログラミング言語のパッケージやコンテナなどの脆弱性の管理をどうしているか、というものでした。 佐藤は、お客様次第としつつ「IPアドレスで制限して入ってこられないようにしてしまう」という方法を紹介。「脆弱性は即時に対応できるものばかりではないので、対応が遅れたら危険なクリティカルなものを選んで対処している。どうしても対応できないものに対しては、アクセスをなるべく遮断しておくことで対応しています」と話します。 山崎は、社内のセキュリティ組織が脆弱性情報を集めて対策を検討し、対応が必要ならば通知が来るようになっていると説明します。AWSのコンテナでもオンプレミス上のアプリでも、どういったものが動作しているかインベントリーを収集して、脆弱性が関連するかどうかを見極めているそうですが、山崎は「まだ完全ではありません」と話します。 GMOペパボも同様の仕組みで対処をしていると山下は説明。危険な脆弱性であれば即日対処するといったように、危険度に応じた対処が重要だという指摘には佐藤も同意していました。 クラウドネイティブと、どう向き合っていくか 最後にコメントを求められた佐藤は、「クラウドネイティブの今後をどう捉えていくか」という質問を投げかけます。これに対して山下は「ひとつのキーワードは可搬性」と言います。これは、AWSでもGoogle Cloudでもどのクラウドでも、そしてKubernetesでもCloud FunctionsでもLambdaでも動作する、といった具合に1バイナリで環境を問わずに動作する世界を想定していました。 山下は、「Wasm（WebAssembly）が流行しかけているが、もうちょっと色んな言語で速く動くようになると、そんな時代になるのではないか」と期待感を表明。WasmがWebアプリケーションでもいろいろなプラットフォームで使われるようになると「アーキテクチャが変わってくるかもしれない」との考えを示します。 山崎はAWSが「一昔前はインフラを提供しているイメージだった」としつつ、例えばシムシティのような大規模3Dシミュレーション演算ができるサービスも提供するなど、幅広い領域に進出していると言及。結果として、AWSやGoogle Cloudなどはインフラエンジニアだけが触れるものだと避けるのではなく、アプリケーションエンジニアもどのように活用するかを考える必要性を指摘します。 こうしたコメントを受けて、長谷川自身もオンプレミスでのKubernetes構築の中で、OSやきょう体によって動作が異なるという点に苦しめられてきた経験を話し、基盤に関係なくアプリケーションがどの環境でも動作するのは重要だと同意していました。 さいごに 「クラウドはいいとこ取りができるので、皆さんもいいとこ取りをして下さい」と長谷川。山崎が「オンプレミスもいいとこありますからね」と笑い、和気あいあいとした雰囲気でセッションはまとめられた。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/c5jhet84uXI

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。初回は、初日KEYNOTEを飾った『CTO対談～技術責任者会議～』の模様をお届けします。 登壇者 スピーカー 三谷 隆GMOペイメントゲートウェイ株式会社 専務執行役員CTO 安藤 健一郎GMOリサーチ株式会社 取締役CTO 栗林 健太郎GMOペパボ株式会社 取締役CTO  モデレーター 稲守 貴久GMOインターネットグループ株式会社　グループ研究開発本部 マネージャー GMOペイメントゲートウェイ 三谷 GMOリサーチ 安藤  GMOペパボ 栗林GMOインターネットグループ 稲守 2022年、グループ各社CTOが集う技術責任者会議が発足  GMOインターネットグループにはインターネットインフラ事業をはじめとして広告・メディア・金融・暗号資産と様々な事業会社・開発組織があります。  これらの技術力を強化し、グループシナジーの最大化を図るため、今春から開発者の最高意思決定機関として「技術責任者会議」が組成され、グループ各社CTOは、毎週1回程度の頻度でミーティングを行っています。  このセッションでは、GMOインターネットグループから、GMOペイメントゲートウェイ株式会社の三谷 隆、GMOリサーチ株式会社の安藤 健一郎、GMOペパボ株式会社の栗林 健太郎と、この技術責任者会議のボードメンバーである3人のCTOが登壇して、GMOインターネットグループの開発体制における現状から、これからの展望について議論を交わしました。  モデレーターはGMOインターネットグループ株式会社（以下GMOインターネットグループとする）で、グループ研究開発本部 マネージャーを務める稲守 貴久が担いました。  それぞれのCTOは技術責任者会議が発足してから、どのように感じているか。参加者が同じCTOという立場のため、「自分一人の悩みが話せるようになった」と言うのは三谷。安藤も「横の繋がりが作りやすくなった」と歓迎します。  栗林は、「GMOインターネットグループは100社ぐらいあって、色んな会社に凄い技術者がいるが、それが知られていない」と話し、横連携ができるようになったことで、そうした社内の「ヤバいエンジニアをもっと広めたい」と言います。  各社それぞれの違いから議論が深まる そんな交流を深めているCTO同士の対談は、「質問1000本ノック」（実際に1000問あったわけではありません）からスタート。「山と海なら海派である」というライトなものから、「現在、開発組織で課題がある」といった会社組織にまつわるもの、「マネジメントよりコードを書いている方が好きだ」というCTOらしい質問に次々と回答していきました。  質問1000本ノックに次々と回答する3人  その中で、「開発組織で課題がある」という質問には3人がいずれも「○」と回答。詳しく話を聞いてみると、実は全員が同じ「人材採用」に課題を感じていました。3人とも「やりたいこととは山ほどある」と異口同音に語りつつ、人が足りなくても採用や評価が難しいという意見で一致しました。  ただ、「CTOの最大の仕事は技術者採用だ」との質問には全員が「×」。栗林は「採用はかなり大きな仕事」としつつ、外部に対して自社の技術的な方向性、能力、サービスの方向付けをすることが重要だと指摘。「テクノロジーによるカルチャーを体現し、それを作り上げていくのが重要な仕事」と話します。  安藤は、「一緒に働いている人が幸せになって欲しいし、楽しく働いて欲しい」と話しつつ、「転職するのもありだし、そういうときにその人の市場価値が高まるような状態になるように、お互い切磋琢磨して向上できるような環境にしていきたい」としています。  採用面の質問では、CTOの面々は「スペシャリスト」よりも「ゼネラリスト」を採用したいと回答していました。三谷は、「決済をずっとやっていたスペシャルの人が欲しいというのはありますが、なかなかそういう人はいない」とスペシャリストの少なさを指摘しますが、そもそもGMO-PGには多くの決済系システムが稼働しており、エンジニアも揃っています。そのため、システムやコードが「先生」となって学ぶことができるので、ある程度のコードを触った経験があって、それが好きで、「チャレンジしたい強い思いがある人であればいい」と言います。  安藤は、特定のシーンでスペシャリストが欲しいという状況はあるといいますが、必要な技術、人物像がその時どきで少しずつ異なるため、「いろいろやりたいという人の方が結果的にいい」と指摘します。  栗林は、「スペシャリストは"どれだけ深掘りできるか"というのに対して、ゼネラリストは"どれだけ横に広げられるか"」と話し、スペシャリストが専門性を深掘りするのと同様に、ゼネラリストは幅を広げることを求めます。「技術を極めたり、影響力を広めたり、できることを増やしたり、そういうマインドを持って欲しい」というのが栗林の考えです。  「Web3はこれからインターネットの主流になる」という問いに対しては、三谷と栗林が「×」と回答。栗林は、「色々なWebが並列するのでは」という意見。Web3のキーワードとして「分権化」があり、それだけでは主流にはならず、Web2的、Web3的と言った形で並列するという考え方です。  3人並んだCTOは、それぞれB2BのGMO-PGとGMOリサーチ、B2CのGMOペパボと立ち位置が異なります。そうした各社の違いについて問われた三谷は、「決済の裏側のB2Bの仕事が多いので、堅い面も半分ぐらいはある」としつつ、全てを「堅く」してしまうとコストがかさんでしまうため、内製化によって「省力化できるところは省力化して、それ以外はきちんとやって、メリハリを付けている」というのがカラーだといいます。  GMOペパボは、コンシューマ、小規模事業者向けですが、レンタルサーバーなどインフラやプラットフォームに近い業務のため、「そんなに派手なところがあるわけではない」と栗林。とはいえ、「僕もインターネットが好きでこの業界に入っていますし、インターネットが好き、プログラミングが好き、自身もクリエーターという人が（社員には）多いので、和気あいあいと好きなことをみんなで楽しみながらやっている」というのがカラーなのだといいます。  各社それぞれの違いから議論を交わす3人  さいごに 最後に参加者への一言を求められた3人。三谷は、エンジニアが成長するための3つコツとして、まず「厳しい非機能要件のプロジェクトなどに携わること」を挙げます。システムのデザインは、非機能要件が厳しいほど難しくなるので、そこにチャレンジすることで成長してほしいといいます。  2つ目のコツとして、「成長している市場や業界、将来性のある会社に身を置いてほしい」と（三谷）。こういったところは変化が激しいので、何をすべきか、将来を見越してどうシステムなどを作るか、といったデザインが非常に重要になるためだそうです。  3つ目はサービスやシステム、プロジェクトを担当する中で、「単に自分の担当領域だけに閉じこもるのではなく、全体に興味を持って知ろうとすることを心がけてほしい」と言います。書籍で学ぶだけでなく、自身が関わっているプロジェクトやサービスなどで担当以外に興味を持てば、周囲にはその道のプロがいるので、聞いて、吸収して次に生かせるようになって成長していってほしい、というのが三谷の考えです。  安藤は、日本CTO協会の理事に栗林が参加していることから、参加者や視聴者にCTOが居れば加入して一緒に話したいとコメント。栗林は、GMOインターネットグループの技術力、事業内容の面白さを「知ってほしい」と強調。100社以上というグループ企業には、「どこかに刺さる企業があるはず」と栗林は話し、エンジニアにとって楽しめたり成長できたりする場がどこかにあるとして、GMOインターネットグループにチャレンジしてほしいとアピールしていました。  アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=dF-GHc-YzLg&t=405s

11/27（日）「JJUG CCC Fall 2022」がハイブリッド形式で開催され、GMOインターネットグループはセッションスポンサーとして協賛・登壇しました！今回はGMOペイメントゲートウェイ株式会社が登壇したスポンサーセッション「カード決済基幹システム　レガシーの克服と無停止更改の挑戦」について、登壇レポートをお届けいたします。イベント告知：https://developers.gmo.jp/26265/本記事はこちらのスポンサーセッションの書き起こしとなります、ぜひご覧ください。 はじめに 登壇者紹介 GMOペイメントゲートウェイ株式会社システム本部IT戦略ビジネス統括部 プロセシング部 羽鳥 樹 羽鳥樹と申します。新卒でインターネット広告の営業としてキャリアをスタートしました。仕事の中で広告配信システムに触る機会があり、当時はまだ珍しかったWebアプリケーションに感動し、こういうものを作れるようになりたいと一念発起し、転職してプログラマーのキャリアをスタートしました。転職先はクレジットカード会社や金融業界を主なお客様としていたので、そこでクレジットカード業界の基本的な知識とシステム開発のノウハウを身につけました。その後、2016年にGMOペイメントゲートウェイに入社しました。前職の経験を生かし、今回お話しするシステムやクレジットカード会社様向けのシステムの開発に従事しております。一方で、これまで主に決済を処理するシステムに携わってきましたが、今後はいわゆるWebプリケーションの開発にも携われるよう、チャンスを探していこうと思っております。 会社概要 弊社は商取引において必ず発生する「決済」のインフラを、幅広い業界のお客様に提供させていただいております。主力事業は決済代行事業で、インターネット上でビジネスをするお客様に向けて様々な決済手段を提供させていただいております。今回お話しするシステムも、決済代行事業のシステムとなります。ほかに、後払い等の金融関連事業や、マーケティング支援サービス等の決済活性化事業も提供しております。 1.システム概要 まずはシステムの概要からお話しさせていただきます。今回お話しするシステムは、弊社システムの中でクレジットカード決済を一手に引き受けているシステムとなります。カード決済基幹システムと呼ぶことにいたします。お客様である加盟店会社は、弊社のサービスを決済フロントシステムのAPIを呼び出すことでご利用されています。決済フロントシステムは、カード決済をはじめ、QRコード決済や電子マネー決済といった、様々な決済手段を提供しております。そのうちカード決済については、カード決済基幹システムのAPIを呼び出すことで実現しています。カード決済と一言で言っても、弊社システムの先にはアクワイアラという加盟店管理を担うカード会社様や、カード会社様との窓口を提供するネットワーク会社様などがあり、それぞれ接続方式や電文フォーマットに差異があります。これらの差異をこのシステムは吸収しております。フロントシステムはこのシステムのAPIを呼び出すだけで、その背後にある複雑さを意識せずに、カード決済を実行することが可能です。カード業界では、FEPなどと呼ばれています。FEPはパッケージ製品を使うケースが多いですが、弊社はすべてJavaでスクラッチで開発しております。2013年頃から稼働しておりますが、当時でも比較的古いとされる実装が多く残っているので、いわゆるレガシーシステムに分類されると思われます。 2.更改プロジェクトについて 更改プロジェクトは、2020年4月より開始しました。当初はサーバーの保守期限切れのため、サーバーの更改のみが範囲でしたが、流通取引総額の拡大に伴い、その次の更改となる5年後の取引量を処理できないということが懸念されました。この表は、当社グループ連結の流通総額となりますが、更改プロジェクト開始前の5年で年平均成長率は27％、更改プロジェクト開始から現在まででは、年平均成長率が35％となっており、取引件数も同様に成長しております。また、クレジットカード決済はその大部分を占めており、カード決済基幹システムに掛かる負荷も上がり続けていました。当初案はサーバーのスケールアウトで対応することを検討しましたが、アプリケーションの保守運用をしている中で、ボトルネックと思われる個所がいくつか見つかっていました。それらを解消することでアプリケーションの処理性能を向上させることができると判断し、サーバーのスケールアウトは後回しにして、まずは改修を実施することにいたしました。 3.処理性能向上について ボトルネックとして挙がったのは3点で、いずれもDBに関するものです。まずはレガシーシステムにありがちな、必要以上に多いDBアクセスです。詳細は後ほど説明いたしますが、生存期間の短いデータをRDBで永続化しているというケースになります。次は、SELECT FOR UPDATEによるレコードロック待ちです。最後は、スケールに比例するSQL実行の長時間化となります。いずれも、性能に大きく影響を及ぼすもので、また取引量の増加に伴い影響も大きくなるものでした。これらは影響が顕著になりシステムへの影響も見過ごせない段階になってから改修しようとしても、いずれも一朝一夕に改修できるものではありません。こうした背景もあり、影響が顕著になる前であり、システム更改をプロジェクトとして行うこのタイミングでアプリケーションも改修を実施することになりました。課題はすべてをRDBで解決するアーキテクチャに起因しているため、解決方法として挙がったのはインメモリDBの使用でした。DBへの負荷を分散し、スループットを向上させるのに適切と考えたからです。インメモリDBとしては定番として名前が挙がり、社内でも使用実績があったRedisが候補として挙がりましたが、私自身がアプリケーションサーバーのPayara Microをほかのプロジェクトで使用した時に、その一部機能として使用した経験があったこと、また改修内容を検討する中でインメモリDB自体に業務処理を乗せて実行させるということが想定されました。このような理由から、Javaで作成したロジックを乗せられるインメモリDBとして、HAZELCASTを使用することに決定しました。 4.HAZELCAST HAZELCASTは、Pure Javaで開発された、In Memory Data Gridの製品となります。IMDGと略したりします。IMDGの他の製品では、Apache GeodeやOracle Coherenceがあります。HAZELCASTはアプリケーションサーバーのPayaraやVert.xなどで使用されています。In Memory Data Gridとは、クラスタリングされた複数のサーバーのメモリに分散してデータを保持することで、高速なデータへのアクセスとスケーラビリティを実現させる技術です。データアクセスするアプリケーションは、複数のサーバーにデータを保持されているにもかかわらず、あたかも1つのDBにアクセスしているように見えます。続いて、こちらは基本的なHAZELCASTの使い方となります。HAZELCASTのAPIを使用して、まずMapを取得します。取得した型はIMapという型で、こちらはConcurrentMapを継承しています。ConcurrentMapはjava.util.Mapを継承しているので、普段使い慣れているMapのput、Get、removeといったメソッドを使って操作することができます。また、Map同様にジェネリクスでKey、Valueの型を指定可能なので、任意のクラスを指定することも可能です。この例では、Customerというクラスを定義して、Valueにしています。普段はネットワーク越しにデータをやりとりするので、独自クラスを定義する場合にはjava.io.Serializableを実装する必要があります。HAZELCASTのクラスタ内の各ノードのIPアドレスやポート、そのほかMapに関する各種設定は、hazelcast.xmlというファイルで定義します。 5.処理性能向上のための改修 ▸ 処理性能向上のための改修① まず、多過ぎるDBアクセスの解消を目指しました。現行システムは加盟店単位の流量制御と、カード会社単位の流量制御をいずれもRDBで実現していました。取引処理中に流量の集計用テーブルにレコードをインサート、加盟店単位の流量をCOUNT()で集計し、流量のチェックを実施、さらに送信するカード会社を決定してレコードをアップデート、カード会社単位の流量を再びCOUNT()で集計し、チェック、処理の終わりにレコードの削除と、流量制御のために3回コミットが発生していました。取引量×3回コミットが発生するので、取引量とともに増加していくコミット回数はDBの負荷を上げ、処理遅延に繋がっていました。一方で処理におけるデータの生存期間は非常に短いため、そもそもRDBで処理するのは適当ではないと判断し、DBへの負荷軽減を目的にHAZELCASTに移行することに決定しました。改修は、処理をすべてそのままHAZELCASTに移行しました。HAZELCASTではSQLを使用できることがわかったので、現行と同様の処理にできると判断しました。具体的には、加盟店IDとカード会社コードでそれぞれ独自のクラスのフィールドに定義し、現行と同様に取引処理時にMapに登録、加盟店IDで集計してチェック、カード会社コードを決定したら反映、カード会社コードで集計してチェック、最後にMapから削除というふうに改修しました。処理を移行するにあたり、カウンタを使うことも検討しました。HAZELCASTにはIAtomicLongというクラスも用意されていて、カウンタとして使用することもできますが、カウンタだとインクリメントしたあとにプロセスが停止するなどの理由でデクリメントされず、件数が戻らないというケースが懸念されました。HAZELCASTではMapにTime To Live値、いわゆる生存期間を指定できます。このため、Mapであれば万一そのようなことが起きても時間が経過すれば件数が戻るので、この方法がベターと判断しました。通常、許容限度の流量はある程度余裕を持つので、カウントが戻らないことで大きな障害に繋がるというケースはまれだと思いますが、カウンタが戻らないということはあるべき形ではないと考え、このような修正としました。 こちらはコードの例です。左側が独自に定義したクラスです。フィールドに加盟店IDとカード会社コードを定義しています。右側は集計するSQLの例です。ちょうどSQLのWHERE句を書いています。valuesの引数にPredicates.sqlで指定した条件を与えると、条件に合致する値のコレクションを取得できます。このコレクションのサイズを件数として取得するようにしました。 ▸ 処理性能向上のための改修② 次に、SELECT FOR UPDATEによるロック待ちの解消です。カード決済基幹システムに接続するシステムごとに最大流量が決まっており、これを制御するための仕組みでSELECT FOR UPDATEを使用していました。先ほどカウンタについて少し触れましたが、この処理ではまさにRDBを使用してカウンタのインクリメント、デクリメントをしていました。テーブルには接続システムごとのレコードが登録されており、カウンタがあります。このカウンタを複数スレッドがシーケンシャルに更新できるように、SELECT FOR UPDATEでレコードをロックしてからインクリメントして更新、チェックが終わったらSELECT FOR UPDATEで再びレコードロックしてからデクリメントして更新、というふうに処理をしていました。システム単位で1レコードを使用するので、取引が集中すると複数のスレッドが同時にロックを試みるため、ロック待ちが発生していました。また負荷が上がるほどロック待ち時間が長くなるため、改修が必要と判断しました。改修内容としては、前ページの改修と同じく、接続システム単位で現在の件数を集計して流量をチェックするようにしました。 ▸ 処理性能向上のための改修③ 最後に長時間SQLの解消です。カード決済基幹システムには期限切れ取引の取消処理というものがあります。これは取引の処理後に一定の有効期限内に確定要求を送信元システムから受けないと、カード会社に取消要求を送信して取引自体なかったことにする機能です。送信元システムとの取引の整合性を明確に保つために、確定要求を受けない限りは取引を成立させないというものです。DBのトランザクションにおけるコミットのようなものと考えていただければと思います。この処理は、取引発生時に取引期限管理用テーブルにレコードを登録し、確定要求を受けると確定の状態に更新。その後、取引期限完了テーブルから定期的に確定に更新されていないレコードを期限切れ取引として抽出して、カード会社に取消要求を送信していました。この抽出時に発行していたSQLは、テーブル内のレコード全件を対象に検索していました。テーブルのレコードは1日以上は保持せずに削除していたため、検索対象は限られていたものの、1日の取引量が増えるにつれ、SQLが遅延することは目に見えていました。取引の抽出はバッチ処理でやっておらず、決済処理用のプロセスの内部で、定期的にスレッドを起動、具体的にはScheduledExecutorServiceを使用していました。このため、決済処理と同じコネクションプールを使用していたので、SQLの長時間化はコネクションを長時間保持してしまうので、コネクションプールの枯渇に繋がり、決済ができなくなるという事態に繋がることが懸念されました。このため、この処理もHAZELCASTに移行することにしました。HAZELCASTでは、RDBのテーブルに相当するMapの追加や削除といったイベントに対してイベントリスナを登録、任意の処理を実行させることが可能です。この機能と、MapのTime To Live値を使用して改修を実現しました。まず、取引発生時にHAZELCASTのMapに取引を登録、その後確定要求を受信したらMapから登録した取引を削除するように改修しました。MapにはTTLが設定されているので、一定の時間が過ぎたらエントリが期限切れとして削除されます。確定要求を受けない取引はリストに残り続け、期限切れとして削除されるので、このイベントに対してリスナを起動し、取引情報を使用してカード会社に取消要求を送信することにしました。この改修により、SQLの発行自体をなくせたので、取引量の増加によりSQLが遅延するという懸念をなくすことができました。こちらは具体的なコードの例です。左側がEntryExpiredListener、つまりエントリの有効期限切れに対するリスナです。引数のエントリイベントから削除されたエントリを取得することができます。ほかにも、追加時のリスナや削除時のリスナのインターフェースも定義されています。作成したイベントリスナはhazelcast.xmlでどのMapに対するリスナなのかを定義することができます。なおhazelcast.xmlで設定する内容はプログラムでも設定することが可能です。イベントリスナのインターフェースはFunctionalInterface(関数型インターフェース)なので、ラムダで書いて登録することも可能です。 6.システム移行時の課題 ▸ 新旧システムの並行稼働 ここまで改修してきて問題となったのは、新システムのリリースでした。サービスへの影響を最小限にするために、カナリアリリースでリリースすることになりました。サービス停止はなしでリリースするので、ロードバランサに新システムを繋げて、新旧システムで取引を処理するのですが、旧システムはRDB、新システムはHAZELCASTを使用することになります。この時、別々のDBを見ているので、例えば新システムで取引を処理し、旧システムで確定要求を処理した場合はRDBには取引が存在せずエラーとなり、HAZELCASTに登録された取引は削除されずに残り続け、取消要求の送信対象となってしまいます。つまり、確定要求を受けているにもかかわらず取消をされてしまうので、加盟店様とカード会社様との間で取引の齟齬が発生する可能性があります。これは非常に問題なので、確実に影響を出さないようにリリースする方法を見つける必要がありました。最終的に、並行稼働期間中、新システムはRDBとHAZELCASTの両方に処理を行うように改修し、その上でHAZELCASTから取消要求を送信する際にRDB側に同じ取引が存在するかを確認するようにしました。この図の例だと、新システムで取引を処理した際に、RDBとHAZELCASTの両方に登録、確定要求を旧システムで受けたら、RDBの取引の状態を更新します。その後HAZELCASTに登録された取引は期限切れとなり取消要求送信の対象となりますが、送信前にRDBを参照し、レコードが存在する場合は処理を中断することで取消要求を発生させないようにしました。これで、取消要求の送信処理自体を旧システムに寄せることが可能となりました。なお、HAZELCASTからRDBへの接続は、特にHAZELCASTでサポートされているわけではないので、独自に実装する必要がありました。当初発生したタイミングでDbConnectionを生成して接続することも考えましたが、同時に大量に取消要求が発生した場合、コネクション生成のオーバーヘッドが処理性能に影響を及ぼすことなどが懸念されたので、コネクションプールを使用することにしました。HAZELCASTには、起動時や停止時といったイベントに対してリスナを作成することができます。これを使用し、起動時にコネクションプールを生成、停止時に破棄するようにしました。なお、コネクションプールにはSpring Bootでも使用されているHikariCPを使用しました。 ▸ 本番移行でヒヤリ 本番移行でヒヤリとした話ですが、こちらはちょっとした小話程度に聞いていただければと思います。本番移行にあたってはリハーサルも実施して想定外の取消要求が発生しないことを確認した上で当日を迎えました。ですが、いざ新システムを稼働させ取引を処理させたら、新システムで大量の「対象の取引が存在しません」というログが発生し、即座に新システムをロードバランサから切り離すことになりました。これは、旧システムで取引を処理し、新システムで確定要求を処理した場合は、HAZELCASTに削除対象が存在しないというのが原因でした。移行期間中、新システムはRDBとHAZELCASTの両方に処理をするよう改修したので、確定要求を処理する時は、RDBの取引の状態を更新していました。このため、取消要求は発生せず、業務影響はありませんでした。ただ、移行リハーサル中は想定外の取消要求が発生しない、エラーログが発生しないという点に集中していたので、WARNログが出るところまでは把握しておらず、本番で初めて知ることになりました。結果として問題はなかったものの、移行当日はものすごく緊張していたのでほんとに肝を冷やしたのを覚えております。 7.まとめ 最後に、システム更改の成果と今後の課題です。システム更改からは1年経過しましたが、既に最大秒間取引件数の7割程度まで処理しています。かなり想定より早いペースですが、現状特に処理遅延などを起こしたり、障害に繋がるといった問題は発生しておりません。更改前よりもずっと安定して稼働しているという印象です。また、DB側のモニタリングで、更改前後で同程度の取引が発生した1日のDBの総アクセス時間を比較しましたが、更改前の約2/3程度まで低減させることができました。DBへの負荷は相当程度低減できたと思います。これが安定稼働に繋がっていると考えられます。また、旧システムと比較し、新システムではシステム内部の処理時間を200ms程度削減することができました。今後の課題ですが、運用に関する改修が必要と考えています。ひとつは、システムの異常をプロアクティブに検知するための仕組み、具体的にはAPMやElasticsearchなどを使ったログ分析といったことが考えられます。そのための足場作りとして、システム更改のタイミングでログ集約の仕組みを導入しています。また、CI/CD対応としてリリースの自動化とテスト自動化を予定しています。いずれも既に着手していますが、今後本格的に導入していく予定です。それから開発効率化のために、フレームワークの導入を検討しています。実は、決済基幹システムはフレームワークを使用しておらず、JDKに含まれるクラスのみでほぼ作られています。このため開発効率に問題があると考えられているので、大胆なアプリケーションの改修となりますが、フレームワークの導入を考えております。今回の更改でも検討はしたのですが、ほかに優先させることが多かったので見送りとなりました。一部の機能で導入し始めていますが、いずれ大胆にアプリケーションを改修して導入したいと考えております。 おわりに GMOペイメントゲートウェイではエンジニアを絶賛採用中です。今日ご紹介したシステムも含め、当社にて構築運用をしている様々なサービスをより発展させていくために、様々なバックボーンをお持ちのエンジニアの皆様のお力をお貸しいただければ幸いです。本日のイベントを聞いて興味が沸いた方はぜひ採用特設サイト（https://www.gmo-pg.com/corp/recruit/）をご覧ください。 Q&A 質問1．Hazelcastの運用で困ったことはありますか？ 主催機能性能は非常に良く、要件に合致してらっしゃると思うのですが、困ったこと、困っていることなどございますか？ 運用して1年程度経ちましたが、今時点で大きく困っているところはないです。ただ、複数台サーバーをクラスタリングしているのですが、間にロードバランサを挟んだりする訳ではなくてクラスタリングされているノードが勝手にクラスタリングをしてくれるというのがHazelcast機能なんですね。なのでいきなり稼働しているもののプロセスを落としてアプリケーションの切り替え等をやるので、その辺が結構、ドキドキするというか、メンバー含めて大丈夫か毎回確認するようなところが、通常のアプリとはちょっと違うなという風に感じています。羽鳥 主催ロードバランサ毎にサーバーを立ててというのではなくて、各ノードのうちどれかがプライマリとして起動して、っていう形になりますのでそうですね。確かに知らないとちょっとドキドキするっていうのはあるかもしれませんね。 質問2．Hazelcastをputする度にネットワークI/Oのブロッキングは発生するのでしょうか？測定などされていましたか？ ブロッキングは発生しているかと思います。実際ネットワークテストの中で、ノードを全部落として実行すると接続できなくて、その間ずっとリトライするのでブロッキングされるはずです。ただ非同期で書くこともできたかと思います。羽鳥 主催そこは作り方次第ではあるけれども、製品としては担保しているということですね。 そうですね。羽鳥 質問3．RDBとHazelcast両方に登録するとデュアルライトが発生すると思いますが、それはどうやって解消されたのですか？ 2つ書き込んでデータが重複して不具合が発生するかということですかね。Hazelcast側でデータベースを参照しながら、移行期間中は業務処理的に不具合が起きないよう工夫をしながら解消していました。Hazelcastからデータベースに接続する所は独自に作らなければいけなかったので、そこはちょっと頭をひねった部分だと思います。羽鳥 主催いわゆるデータグリッドのようなHazelcastの製品だと、キャッシュに書いてからライトスルー同期型でデータベースに書き込みしたりだとか、ライトビハインドで非同期するようなことがあるかと思うのですが、今回の場合はライトビハインドではなくライトスルーという形になったんですね。 はい、そうですね。羽鳥 質問4．Hazelcastを使っているならPayara Micro使うのがいいのでしょうか？ 主催フレームワークを採用する上で、何か意図してHazelcastだからこのフレームワークなのか、そうではなくて今までこれを使っていたから、単純にHazelcastを使うようにしたというのか、両パターンあるのかなと思うんですけど、御社の場合は去年お話ししていたSpringとか、プラスJDKでガリガリ作ってらっしゃった話を聞いたことがあるんですけども、何か指針がありましたら教えてください。 指針というより経緯という感じになってしまうのですが、以前プロジェクトでPayara Microを使用した経験があって、その中で若干Hazelcastを使ったことがあったというところから、採用しました。今回の更改では、特にフレームワークを導入することはなくてPayara Microを使っていないのですが、知識が若干あったことと、且つユースケースも嵌まるということが分かったので使うことになりました。羽鳥 主催select for updateのお話ですね。NOWAITとかSKIP LOKEDとか併用で制限付きリトライを実装する、もしくは例えばロックタイムアウトをある程度制限しておかないとコネクションを埋めつくすよねっていうとこでしみじみコメントされている方もいらっしゃいますね。 本当に仰る通りですね。今回ご紹介していない機能で、select for updateが原因でロック待ちが発生してしまっていたケースがあって、こちらも改修する際にかなり悩まされた部分ではあります。羽鳥 主催あとはデータベースのロックが悪というって言い方はちょっと表現が強いかなっていう感じはするんですけど、どうしてもロックしてしまうよね。っていうところで、今回はインメモリデータグリッドの製品であるHazelcastをお使いになったのかなと思ってはいるんですけれども。 質問5．お話いただいた以外でハマったところなどあれば教えてください。 主催今回お話頂いた以外で、この辺はハマりどころだから、ちょっと気をつけてくださいというようなガイドというかチップスみたいなのをオーディエンスにお伝えいただければなと思います。 よく覚えているのが、Hazelcastの設定ファイルはhazelcast.xmlで定義するのですが、公式のドキュメントを見ていてYAMLでもかけると思ったのでせっかくなのでYAMLでやったら、一部の機能でYAMLではダメですとなって結局xmlに戻したという経緯があります。なのでやるならhazelcast.xmlでやった方が無難です、というところですかね。あとは日本語のドキュメントがなかったので、公式の英語のドキュメントを見る必要があって、そこがちょっと大変でしたね。一方で、公式ドキュメントは結構充実しているので、ちゃんと読めば理解が深まるようになっているとは思います。羽鳥 主催マニュアルを読むうえで英語がメインのドキュメントになってしまっていたので、ややハードルがあったという感じですね。ありがとうございます。 質問6．プロジェクトはどれぐらいの期間かかったのですか？ 期間的には約1年半ぐらいですかね。羽鳥 主催GMOさんは既に色々プラットフォームをお持ちだったりするので調達はそれほど難しくはないかと思うのですが、実際に要求開発及び設計で恐らくテストの期間が1年半という感じですかね。 そうですね。羽鳥 質問7．開発は何人ぐらいでされていましたか？ 主催決済システムはお金が関わるシステムなので、非常にヒヤヒヤドキドキするのであるとかっていう開発も結構ヒヤヒヤものだと思うんですけれども、結構プレッシャーが高いかと思います。何人くらいで開発されていたのでしょうか？ 大体、10人ぐらいですかね。羽鳥 主催じゃあ、アーキテクトがいてあとはプロジェクトオーナーとかちょっと置いておいたとしても、実際に手を動かす人々がそれぞれという感じですかね。 はい、そうですね。羽鳥 質問8．テスト中にHazelcastの特性上困ったことなどありましたか？ 主催素朴な質問なのですが、データベース直だとロックとかそういうパフォーマンス的な部分ばかりで、あとはHazelcastをお使いになったことであるっていうことなので、ある程度特性をご存じで、テストの時にHazelcastの特性や知らなかった部分が理由でうまくいかないとか、そういうことってあったのですか。 テストの中で想定してないっていうのは、あまり記憶にないですかね。逆にいうと、そこまで複雑な機能を使わずシンプルな使い方をしていたので、テスト中にはまったというのはなかったですね。羽鳥 主催開発時に何かちょっと思っていたのと違ったとか、設計に入る段階で既に基礎調査みたいなことはされていたと思うので、そこで解決していたのでしょうか。 基礎調査で結構時間をとって、簡単なプログラムを作って動作確認するというのはかなりやったので、実際テストのタイミングでは想定外というのは起きなかったのかなと思います。逆に言うと、そのタイミングで思ったよりパフォーマンスが出ないとか、IAtomicLongいわゆるカウンターみたいなものがHazelcastの中にはあるんですが、これを複数のスレッドで同時にカウントアップとカウントダウンを行った場合に処理性能的にRDBを使った場合と、どの程度違うのかっていうのをやってみたら、あんまり速くなかったことがありました。羽鳥 主催ロック競合というか取り合いになるからということですかね。 はい、そうですね。羽鳥 質問9．開発の効率化にあたってフレームワークの導入を進めているとのことですが、どんなものが候補に上がっていますか？ Spring Boot、Vert.xやQuarkusが候補にあがっています。羽鳥 主催開発者も多いっていうのがありますよねSpring Bootは。 はい、弊社内でも経験者が多いので、Spring Bootは進めやすいです。羽鳥 質問10．新システムと旧システムを並行稼動中に新システムが問題なく稼動してるのを確認する方法として、エラーが出てないこと以外に、データ整合性など見てらっしゃったポイントなどありますか？ 色々見ていたような記憶があるのですが、やはりそのデータベースとHazelcastを使った中でのそのデータの整合性もちゃんと行っているかというところの確認ですね。特にその意図してない取り消しが発生してないか。発生するとその加盟店的様との決済の不整合が起きてしまうので、そういったところはかなり注力して見ていたところです。あとはエラーだとか、ワーニングといったところのログは全て拾って、何かしら異常が出ていないかっていうところはかなり注意して見ていたかなと。とにかくログの種類というか条件を絞らずに、抽出すべきログを全部見るみたいな、形でやっていたところはあります。あとは新旧処理の遅延、処理が遅くなってないかというようなところも、かなりモニタリングしました。羽鳥 質問11．最後に何かメッセージはありますか？ はい。弊社の新しいメンバーを募集していまして、特に決済に携わってきたキャリアをお持ちの方でぜひご興味を持っていただければと思っております。カード決済の仕事で培った知識といったものが結構限られた業界というか、専門的なものなので、そういったものを弊社で非常に取り扱うので、決済の知識を持った方に是非ご興味持っていただければと考えております、よろしくお願い致します。採用特設サイト（https://www.gmo-pg.com/corp/recruit/） 羽鳥 主催羽鳥さん、どうもありがとうございました。 ありがとうございました。羽鳥 アーカイブ動画 ご視聴・ご参加いただき、誠にありがとうございました。たくさんのご質問もいただき、重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://youtu.be/SGy0UDwZpB4