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

この記事は GMOインターネットグループ Advent Calendar 2024 23日目の記事です。 はじめに こんにちは！GMOペイメントゲートウェイ株式会社の小池と申します。 サポートセンター国際認定(SCC)と三つ星格付け調査で7回連続最高評価を獲得している私たちカスタマーサポートの取り組み「満足度を向上させる本気のシフトレフト」について紹介します。 シフトレフトってなに？ カスタマーサポートにおけるシフトレフトとは、お客様が問題なくサービスを利用できる状態に近いほど満足度が高くなる、という考え方です。従来、お客様の問題解決はサポートの後半（サポート担当者への問合せ）に行われがちです。しかしながら、問題が発生してから有人サポートに至るまでに、お客様は様々な労力を費やします。それでは問題解決までに時間と手間がかかり満足度が下がります。そのため、問題が起きる前や初期段階で解決策を提供し、可能なかぎり有人サポートを必要とする前に解決を促すことが重要です。 シフトレフトへの挑戦～私たちがシフトレフトを掲げる理由～ 私たちがシフトレフトを掲げるに至ったのは、弊社が経営指標として重視している「年平均25%の営業利益成長」に寄与するカスタマーサポートであり続けるためです。 コスト部門であるカスタマーサポートは、コストを抑えつつ顧客満足度を向上させることが使命です。契約店舗数の増加に伴い、問合せ件数を増加させていてはコストが肥大化します。契約店舗数が増加しても、問合せ件数を増加させずに増員を抑え、問合せ対応以外の改善時間を確保しています。 そのために、私たちカスタマーサポートでは３つの点に力を入れてシフトレフトに取り組んでいます。 問題なく快適にサービスを利用できる状態にするためのVOC（お客様の声）からのサービス改善不明点が出てきた場合でも、セルフヘルプで解決いただくためのFAQとBOTの充実セルフヘルプで解決できずに、有人サポートが必要となった場合でも一発逆転で満足度を向上させる高品質な有人対応 この3つの点について、詳しくご紹介します。 シフトレフトの取り組みで注力している３つの点 ①VOC（お客様の声）からのサービス改善 解決のための努力度合いが最も少なく、顧客バリューが最大になる「問題なく快適にサービスを利用できる状態」に近づけるためお客様のお声をもとにしたサービスの改善に力を入れています。年1回のお客様満足度調査ではアンケート結果の他に、各部門のメンバーが集まり実際にお客様を訪問してお話を伺い、具体的なご意見に基づいて改善アクションを策定するなど、全社的に満足度向上に取り組んでいます。また、カスタマーサポートでは日々のお客様対応でいただくご意見や自身で気づいた点からも、改善提案を行っています。実際のお客様のご意見を日々直接伺うことができるカスタマーサポートだからこそできる、「お客様のお声を反映したサービスへの改善」に力を入れて取り組み、メンバーの評価項目の1つとしても取り入れたことで、改善提案件数は3年前と比較して約3倍に増加しました。 ②FAQとBOTの拡充 サービスを利用して不明点が出てきた場合でも、解決のための努力度合いを少なくして顧客バリューを向上させるためオペレーターへ問合せることなくセルフサポートで解決できることを目指し日々FAQやBOTの改善を行っています。 【説明1】日次でのコンテンツ改善　セルフサポートに関して毎日取得している30項目近くの数値とともに、　コンテンツ評価（Goodボタン、Badボタン）や、検索しても1件もヒットしない　0件ヒットの単語から内容を分析し、改善の対応を行っています。 【説明2】KCSから外部公開FAQへの転用　弊社カスタマーサポートではKCS運用を行っており、お客様の言葉で社内ナレッジを　作成しています。問合せ対応でよく利用される社内ナレッジを　外部公開していくことでセルフサポートでの解決率向上に取り組んでいます。　※KCS（ナレッジ センター サービス）とは：　　ナレッジの一連の実践プロセスと方法論。　　お問合せを受けたら、必ずお客様の言葉でナレッジを検索し、　　その内容に沿って回答したり、必要があれば更新、　　該当ナレッジがない場合は新しく作成することで、　　ナレッジの鮮度を保ち組織内の知識共有と問題解決率を向上させます。 　また、KCS運用により「お客様の言葉」でセルフサポートのコンテンツを　作成できるようになったことで、分かりやすくなり　閲覧数が4倍以上に増加したコンテンツもありました。【説明3】動画コンテンツの公開　ご契約間もないお客様向けにサービスの概要や操作方法など、　動画コンテンツを公開しています。　動画コンテンツは、画像や文章だけでは分かりづらい操作方法等も　直感的に理解しやすく、メールに動画のリンクを張るなど　活用していった結果、ご契約間もないお客様からのお問合せが　減少したという結果も出ています。 【説明4】チャットボット出し分け機能の利用　弊社のチャットボットは複数の画面に設置しておりますが、　以前は1つの箱に入った回答から各画面の回答を表示していて、　内容を制限できていませんでした。その状態だと画面に合わせた回答ができず、　またお客様が条件を選択して深い階層まで辿っていく操作が　必要となってしまいましたが画面ごとに回答するカードを出し分け設定したことで、　画面に合わせた回答ができるようになりました。 これによって満足度が30％向上、参照数も向上しお問合せが年間で1000件削減できた画面もあります。 ③高品質な有人サポートの提供 有人サポートが必要となった場合でも、一発逆転で満足度を向上させるため、社内視点、お客様視点、外部視点3つの視点から多角的に対応を評価・管理し、高品質なサポートサービスを提供しています。 【社内視点】　電話、チャット、メールの対応をPGサポートの信念である　「＋αの対応」と「お客様への思いやり」に基づいた評価基準で評価し、　メンバーへフィードバックを行っています。 【お客様視点】　対応都度のアンケート調査を実施し５段階の満足度と併せて　その要因やフリーコメントを収集しています。　アンケート結果から、さらに高品質な対応のための改善を行っています。 【外部視点】　外部機関による三つ星格付け調査を毎年実施し、2024年12月現在、　7年連続で最高評価三つ星を獲得しています。 シフトレフトに取り組み、得られた効果 企業成長とともに契約店舗数が増加していくと、比例してお問合せ件数も増加すると考えられます。グラフの★の部分が契約店舗数に比例して増加したと想定した場合のお問合せ件数です。 しかし、シフトレフトに取り組み様々な改善を行った結果、お問合せの増加を抑止することができています。シフトレフトの取り組み前と比べてセルフサポートのご利用数は2倍以上に増加し、想定増加分のお問合せを抑止したことで生産性を2.6倍、向上させたといえます。また、生産性の向上によってカスタマーサポートの離職率、ESも改善されています。 このように、シフトレフトに本気で取り組みはじめた結果、ESとCSともに向上させることができ、これにより弊社のサービス品質と顧客満足度が向上し持続可能な成長を実現していると言えます。 まとめ 私たちはシフトレフトに真剣に取り組み、効果を上げてきました。しかし、更なる進化をしていくために、生成AIの活用などまだまだやりたいこと、課題や改善するべき点がたくさんあります。 これからも、日々改善を行い、No.1サポートを目指していきますので今後も進化するGMOペイメントゲートウェイのカスタマーサポートにご期待ください！

この記事は GMOインターネットグループ Advent Calendar 2024 20日目の記事です。 はじめに プレゼン資料や新聞、ニュースなど至る所で目にするグラフ。データを整理し、一目で情報を伝えるために欠かせないツールです。しかし、グラフの種類や使い方を意識して選んでいる人はどれくらいいるでしょうか？適切なグラフを用いデータを可視化することで、データの本質を分かりやすく伝えることができます。本記事では、グラフの種類と使い分けを解説するとともに、実際に障害調査でグラフを活用した事例を交えながら、可視化の重要性について掘り下げていきます。 グラフの使い分け ばらつきを見る ヒストグラムストリップチャート箱ひげ図 値を比較する 棒グラフ 割合を見る 円グラフ積み上げ棒グラフ 時間変化を見る 折れ線グラフ積み上げ棒グラフ積み上げ面グラフ 値の関係を見る 散布図バブルチャート複合グラフ 主なグラフ ヒストグラム 用途：ばらつきを見る 次のグラフは、総務省の家計調査による「貯蓄現在高 階級別世帯分布（二人以上の世帯）2021年」です。ヒストグラムは棒グラフと似ていますが、棒（ヒストグラムではビンと言います）の幅で横軸の数値の範囲（階級数と言います）を表すことができます。 例えば、100～1000は100刻みですが、1000～2000は200刻みのため、1000～2000のビンは横幅が2倍に伸びています。2000～2500は横幅が5倍です。棒グラフでは見落としがち階級数も、グラフで表現することができます。 https://www.stat.go.jp/data/sav/sokuhou/nen/pdf/2021_yoyaku.pdf ストリップチャート 用途：ばらつきを見る 次のグラフは、47都道府県の2022年の平均気温です。ストリップチャートは1次元散布図とも言います。データの重なりが多いと解釈が困難なため、少量のデータをコンパクトに表示したい時に使います。 https://www.e-stat.go.jp/ 箱ひげ図 用途：ばらつきを見る 昔は数学Ⅰで習うものでしたが、2021年度の学習指導要領から中学2年生の数学で習うようになったようです。ストリップチャートよりシンプルな表現でばらつきが確認できます。 値の大きさではなく値の個数に着目し、昇順に並べ替えたデータに対し、先頭から数えて全体のx％目に位置するデータをxパーセンタイルと呼びます。また、25%ごとのパーセンタイルを四分位数（しぶんいすう）と呼びます。 25パーセンタイルの値：第一四分位数50パーセンタイルの値：第二四分位数（中央値）75パーセンタイルの値：第三四分位数 さらに、25～75パーセンタイルの値の範囲を四分位範囲（IQR：Interquartile Range）と呼びます。 そして、第三四分位数からIQR×1.5を上限に最も大きい値を最大値、第一四分位数からIQR×1.5を下限に最も小さい値を最小値、最大値・最小値の範囲外の値を外れ値として表現します。平均値を補記する場合もあります。 https://www.e-stat.go.jp/ 棒グラフ 用途：値を比較する 説明不要のおなじみの棒グラフですが、1つ注意点です。棒グラフは原点０を表略することができないものです。原点０を省略した場合、差異を過大に感じさせることに繋がります。テレビや広告などで原点０を省略した棒グラフを時々見かけることがありますが、印象に惑わされないよう注意が必要です。 https://www.e-stat.go.jp/ 円グラフ 用途：割合を見る 次のグラフは、2024年の日本におけるデスクトップ版ブラウザシェアです。円グラフは1/2、1/3のように割合が一目で分かりやすいです。 https://gs.statcounter.com/ 積み上げ棒グラフ 用途：割合を見る 割合は積み上げ棒グラフでも表現することができます。円グラフより省スペースに記載できる特徴があります。 折れ線グラフ 用途：時間変化を見る 次のグラフは、2023年の札幌市における月別平均気温です。気温のグラフは折れ線グラフがよく使われます。時間変化に棒グラフを使うことも可能ですが、気温は棒グラフに必要な原点０が存在しないため、棒グラフが使えません。 https://www.data.jma.go.jp/stats/etrn/index.php 折れ線グラフですが1つ注意点です。次の左側のグラフは3月から4月に掛けて"急激に減少"と表現されていますが、グラフを縦横に引き延ばすと右側のグラフは変化が緩やかに感じます。折れ線グラフは傾きで増減を表現する手法のため、増減の傾向の把握に留め、値の評価には注意が必要です。 積み上げ棒グラフ 用途：時間変化を見る 次のグラフは、当社のIR資料のうち、ビジネスモデル別の連結売上高です。全体と内訳両方の時間変化を確認することができます。 https://www.gmo-pg.com/news/pdf/20241113_gmo-pg_kessan.pdf 積み上げ面グラフ 用途：時間変化を見る 再び、日本におけるデスクトップ版ブラウザシェアです。割合の時間経過も積み上げ棒グラフで表現できますが、詳細なパーセンテージを示す必要がない場合は、積み上げ面グラフで省スペースに表現が可能です。 散布図 用途：値の関係を見る 47都道府県の年平均気温と最高気温（日最高気温の月平均の最高値）の関係性を表したグラフです。2値が相関していることが一目で分かります。 https://www.e-stat.go.jp/ バブルチャート 用途：値の関係を見る 先ほどの散布図に、最低気温（日最低気温の月平均の最低値）を円の大きさとして追加したものになります。3値を可視化することが可能です。 複合グラフ 用途：値の関係を見る 関連する棒グラフや折れ線グラフなどを1つの図に集約することで、複数の値の関係を表現します。 障害調査でデータを可視化した例 弊社は決済サービスをビジネスとしている会社で、日々オーソリ処理（クレジットカード決済の際に、カード会社に顧客の与信情報を照会して決済の可否を確認する手続き）を行っています。ある日、特定のカード会社起因で、本来オーソリNGにしてはならないカードが数百件レベルでNGと誤判定される障害が発生しました。事態はお客様からの連絡により数日後に知ることになったのですが、今後は我々で予め検知できるように、一定の閾値（NG率）を超えたらアラート通知することにしました。 問題は、アラート通知する閾値をどうするかです。まず、半年分のオーソリ件数とNG率をデータベースから抽出し、表に整理しました。数値は非公開となるため、下表は次の加工をしています。（実際の表は実数） 障害日（黄色）のNG率をｘ％とおく。NG率が障害日より高い日をオレンジ色、僅差で低い日を青色、その他は空白で記載オーソリ件数は障害日を「100,000」とした場合の比率を記載 障害日のNG率は確かに高めではあったものの、障害日より高い日や、僅差で低い日もあることから、障害日のNG率が突出して高いとは言えず、NG率のみで閾値を決めることができません。 二次元の表を眺めてても糸口が掴めないため、オーソリ件数とNG率の関係を見るために散布図に変換します。 散布図に変換することで、オーソリ件数が少ない日はNG率にバラツキがありますが、件数が増えるにつれてNG率がある程度収束していくことが一目で分かるようになりました。また、障害日が明らかに外れ値であることも散布図から分かります。 この分析結果を元に、ｘｘｘ件以上の時にα％以上のNG率（非公開）でアラート通知するように実装しました。 まとめ データの可視化は、膨大な数値データを直感的に理解しやすくするために重要です。グラフを用いることで、データ間のパターン、傾向、相関関係を迅速に把握でき、意思決定をサポートします。また、視覚化は複雑な情報を簡潔に伝える手段として、他者との効果的なコミュニケーションにも寄与します。さらに、異常値や潜在的な問題を発見する助けにもなり、問題解決や戦略策定において必要不可欠なものです。

この記事は GMOインターネットグループ Advent Calendar 2024 13日目の記事です。 はじめに 皆様はじめまして！GMOペイメントゲートウェイの川原と申します。 普段はWebアプリケーションエンジニアとして決済代行サービスであるPGマルチペイメントサービス（以下「マルペイ」と記載）の開発・運用に従事しており、その中でも主に加盟店様にて取引の確認や設定変更を行っていただくための管理画面（以下「マルペイ管理画面」と記載）を担当しています。 私は数年前からマルペイ管理画面のPHPバージョンアップ対応を行っており、今年その一連の対応を完了させることができました。本記事では、このPHPバージョンアップ対応について共有したいと思います。 バージョンアップの概要 担当しているマルペイ管理画面は言語としてPHP、フレームワークはSymfonyを採用しており、オンプレミスの仮想サーバー上で稼働しています。今回PHPをこれまで使用してきた5.6から8.1へアップグレードし、同時にフレームワークとして使用しているSymfonyについても2.6から5.4へのアップグレードを行いました。 これまでWAFの設置による防御や第三者による定期的な脆弱性診断など、様々な措置によりセキュリティを担保しながらサービス提供を行ってきました。平行して言語のアップグレードも課題として検討してきましたが、各種案件との調整により今回約10年ぶりのバージョンアップ対応となりました。 そのため、PHPやフレームワーク、ライブラリ周りが全て変わっています。型システムの厳格化・大幅拡充などPHPerとしては大変喜ばしい変更点も多いのですが、変更点の多さから対応を進めて行くにあたり困難が予想されました。ライブラリについてはすでに開発終了となっているものもあり、それらの移行も課題となりました。 マルペイ管理画面のシステム概略図 また、クレジットカード業界の規制や社内の事情から、用途別に複数の管理画面が存在している状態となっており、それぞれが画面数の多い大きなシステムとなっています。これらが全て1つのサーバーで稼働していることにより、管理画面単位での段階的なPHPバージョンアップが実施できない状態でした。 そのため、今回は困難が伴いますが全システム一斉にバージョンアップを行う方針で進めました。 具体的な作業 上記の変更を踏まえ、マルペイ管理画面のバージョンアップ対応を進行していきました。全体的なスケジュールとしては、2022年の8月から開発を開始し、2023年7月に単体試験まで完了させました。 システムテストを実施後、同年9月に本番正系へのリリースを行いました。本番リリース後は新旧バージョンの並行稼働期間を設け、発見した不具合については順次修正作業を実施しました。 その後、並行稼働期間に発見した不具合の修正が落ち着いたため、2024年4月に本番副系にもリリースを実施し、PHP 8.1への移行を完了させることができました。 全体スケジュール バージョンアップ 当初はPHP・Symfonyそれぞれのリリースノートから変更点を洗い出し、階段状にバージョンアップを行っていく方針で対応を進めていました。これは、5.6から8.1にいきなりバージョンを上げようとすると、変更点が多すぎて収集がつかなくなることを懸念してのことでした。 しかし、この方針では対応工数が膨大になることが判明したため、途中から最終的に目標しているバージョンに向けて一気にバージョンアップを行う方針へ変更しました。 バージョンアップ戦略のイメージ 実際のソースコードの修正については以下の方針で進行しました。人数・工数としては、単体試験で検知した不具合修正も含め、最大6人・約11ヶ月で実施しています。 PHPは静的解析ツールのPHPCompatibilityを使用し、改修が必須な箇所を洗い出し修正Symfonyについてはリリースノートから大項目単位で修正箇所を洗い出し修正ライブラリについては以下の3分類で対応を実施　1. 開発継続中　　→バージョンアップ作業時点での最新安定版へバージョンアップ　2. 後継ライブラリあり　　→後継ライブラリの最新安定版へ移行　3. 開発終了　　→直接コードを改修して対応 また、PHPの設定値について、バージョンアップにより設定項目の追加や削除があるのはもちろん、既存の設定項目についてもデフォルト値が変更されているものが多いため、全項目について棚卸を実施しています。 設定ファイル内の各項目について、設定値の確認設定ファイル内に定義が無く、デフォルト値が適用されている項目について、デフォルト値の確認新規追加された項目について、設定値の検討削除された項目について、代替項目があるかの確認 PHPの設定値はphp.ini上で定義する以外にも、Apacheやソースコード上から動的に設定値の書き換えができてしまうため、Apacheの設定ファイルやソースコード上から設定を行っている箇所についても、設定値の棚卸を実施しています。 テスト 今回はバージョンアップによりPHPやフレームワークなどの基盤が大きく変更されるため、デグレ確認のため全画面テストを行うことを前提としました。 ただし、ユニットテストやE2Eテストといったテスト自動化はこれまでこれまで行われていなかったため、全画面手動での打鍵テストを行うこととし以下の方針で進めることとしました。 まず全画面で実装担当者による単体試験を実施→実装担当者最大7人で約4ヶ月間実施（残部分の実装・単体試験の不具合修正と並行して実施）利用率の高い決済手段など重要度の高い画面のみレビュワーによるシステムテストを実施→レビュワー3人で約1ヶ月間実施その他の画面についてはモンキーテストの期間を設け全員で打鍵テストを実施→最大6人で約1.5ヶ月間実施 リリース手順・フォールバックの検討 加盟店影響のあるバグはテスト段階で全て検出・修正されるのが理想ではあります。しかし、システムがかなり大きいことと、複数バージョン分の変更が一度に反映されることから、本番リリース後に不具合が発覚することも十分想定されました。 そのためリリースはBlue/Greenデプロイで行い、不具合が発見された際はフォールバックを行うことができるよう進めました。先述の通りマルペイ管理画面はオンプレミス上で稼働しているため、正系に新バージョン・副系に旧バージョンを配置することで、Blue/Greenデプロイを行えるよう工夫しています。 並行稼働期間中は正系にPHP 8.1対応済みのソースコード副系にPHP 5.6のソースコードをリリースする 検証・本番環境正系のみPHP 8.1へバージョンアップ検証・本番環境副系はバージョンを上げず並行稼働稼働に問題ないことを確認後、副系をPHP 8.1にバージョンアップし、全環境PHP 8系へ移行する 新旧バージョンを並行稼働させるにあたり、新規に開発した機能や改修を行った機能については、新旧両方のリポジトリにマージされている必要があります。そのため、バージョンアップ作業が完了後は原則として新バージョンのリポジトリにて各開発を行い、リリース前に旧バージョンリポジトリに対してマージし、旧バージョンで再度動作確認を行ってからリリースする流れとしました。 バージョンアップ起因の不具合が出てきた場合旧バージョンの副系環境へ切り戻しを実施 新旧並行稼働させることによって、新バージョンの管理画面で何らかの不具合が発生した場合、旧バージョンが動いている副系へ切り戻しを行うことで、振る舞いをバージョンアップ前に戻し加盟店様への影響を最小限にとどめることができます。その後落ち着いて修正を進めていけるため、精神衛生上余裕を持って移行作業を進めていくことができました。 リリース 検証・本番環境でのリリースについては、事前に開発環境でリハーサルを行いながら手順を作成していたこともあり、特に問題なく当日のリリース作業については完了しました。しかし、かなり念入りに準備をして移行作業を行ったものの、それでも大小合わせて不具合を9件発生させてしまいました。 発生した不具合例としては、環境依存文字の含まれたCSVファイルをアップロードしようとすると、バリデーションで弾かれエラーとなってしまった件がありました。調査した結果mbstringの内部処理変更により発生したものであったため、それに合わせて処理を改修することで解決することができました。 マルチバイト処理の変更により、文字コードの変換を行った際に意図しない文字化けが発生し、バリデーションを通らないようになるPHP 5.6下の挙動では、文字コード変換時に環境依存文字は「?」（半角クエスチョンマーク）に置換されていたため、その挙動に合うよう環境依存文字を直接「?」に置換する処理を追加し、文字コード変換時に文字化けが発生しないようにして力業で解決 この不具合は環境依存文字を含んだCSVをアップロードするテストを行っていれば事前に検知できた不具合であったため、リリース後に検知されたことが悔やまれる不具合でした。 プロジェクトを振り返って 成果 EOLによるリスクへの対応 マルペイ管理画面で使用していたPHP 5.6は2019年にEOLを迎えています。WAFなどの緩和策でセキュリティは担保していましたが、より本質的な形で解決することができました。 パフォーマンスの向上 開発環境での結果にはなりますが、バージョンアップ前後で比較してレスポンスタイムが2.5倍に向上しています。 開発環境にて実施した負荷試験の結果Apache Benchを使用して同時接続数20・合計リクエスト数1万回のベンチマークを実施 このパフォーマンス向上はマルペイ管理画面として実装している処理のチューニングでは無く、PHPコアの改善によってもたらされたものになります。PHPはバージョンアップのたび性能が改善しており、5.6と比較して8.0はベンチマーク性能が2倍以上となっています。今回8.1にバージョンアップを実施したことにより、ベンチマーク通りに性能が上がっています。 PHPのベンチマーク結果の推移についてPHPの今とこれから2022 p.8より引用 開発者体験の向上 型システムの改善やシンタックスシュガーの追加など、言語レベルでの改善が進んでいます。定性的ではありますが私自身はかなり快適にコーディングができるようになったと感じています。 成功したポイント 静的解析ツールの活用 PHPCompatibilityを活用することで、PHPのバージョンアップにあたりソースコードの中で最低限修正すべき箇所を抽出することができ、ソースコードの修正を効率化することができました。 ソースコード全体で約150件程度が修正しないといけない箇所として上がってきましたが、そのうち修正が必須となる箇所は1/3の50件程度でした。要修正箇所と今回は修正しなくてもまだ大丈夫な箇所が分かることで、PHPの仕様変更に伴うコード修正を最小限に抑えることができました。 Blue/Greenデプロイによるフォールバックの計画 Blue/Greenデプロイによるフォールバックを取り入れたことで、不具合発見時の加盟店様影響を最小限に抑えることができました。 今回のバージョンアップ対応でも大小合わせて10件程度リリース後に不具合が出てきた中で、フォールバックですぐに旧環境へ戻せたことで、私自身も精神的にかなり助けられました。 反省点 リファクタリングの自動化 PHPの仕様変更部分についてはPHPCompatibilityを使用して作業の効率化ができましたが、Symfonyのアップグレード対応については人力での作業になってしまいました。 今回対応を行う過程で、バージョンアップに伴うリファクタリングを自動化できるRectorという静的解析ツールを知りました。このツールではPHPやフレームワークのアップグレードに伴うリファクタリングを自動化できるため、今後のバージョンアップではRectorの活用を検討していきたいと考えています。 テスト不足による不具合の発生 事前のテストで概ね不具合を潰せていたのですが、テスト観点が一部漏れていたことにより、リリース後に発覚した不具合が複数ありました。 特に先述したCSVアップロードでの不具合について、mbstringに変更が加えられていることは事前にリリースノートから把握していました。そのため、通常の打鍵テストに加え機種依存文字周りのエッジケースがテストできていれば、処理系への依存度が高い不具合をより細かく潰すことができたと感じています。 また、今回は手動テストで進めることとなりましたが、普段からテスト自動化が行われていれば漏れなくテストができ、普段の開発においても品質が向上するため、今後はテスト自動化についても進めていくことが重要と感じました。 終わりに このバージョンアップは終わりでは無く、今後も継続的にバージョンアップが必要となります。今後は反省点としても述べたリファクタリングやテストの自動化を取り入れることで、継続的なバージョンアップを行う下地を整え、より安全・便利なサービスを加盟店の皆様にご提供できるよう努めていきたいと思います。 今回はかなり泥臭く対応を行っており、一見真新しいことは見当たらないかもしれませんが、何か皆さんの参考になれば幸いです。

この記事は GMOインターネットグループ Advent Calendar 2024 12日目の記事です。 GMOペイメントゲートウェイの羽鳥です。主にクレジットカード決済システムや、カード会社様向けシステムの開発にプログラマーとして携わっています。 今回お話しするのは、今携わっているプロジェクトで、システム間連携のロジックをApache Camelを使用して一か所に集約したときのお話です。 プロジェクトについて 現在携わっているプロジェクトは、クレジットカードの発行を行うお客様向けのシステムです。システムの内部は、 入会審査を行うシステム売上情報を処理するシステム債権を扱うシステム に分かれています。これらのシステムは互いにファイルでデータをやり取りします。 課題について 全てのシステムが同じファイル送受信の方式を採用していれば簡単なのですが、実際はそれぞれHULFT、SFTPといった具合にそれぞれ異なっていました。 このため、以下の課題がありました。 各システムの中にファイル送受信をするサーバは複数存在するため、相手方のサーバの接続するためのロジックの重複が発生 接続方式が変更になると、全てのサーバに変更が必要 これでは非効率なため、代理でファイル送受信を行うサーバを構築する必要がありました。ここで、代理でファイル送受信を行うアプリケーションを構築するのに最適だったのがApache Camelです。 Apache Camelとは Apache Camelは、統合パターン (Enterprise Integration Patterns: EIP) を実装するためのオープンソースフレームワークです。分散システム間のデータ連携やプロトコル変換を効率的に行うためのツールであり、多数のコンポーネントを使用して、ファイル、メッセージング、HTTPなど、さまざまなシステム間での通信を簡単に構築できます。 Camelの主要な特徴は次の通りです。 EIPに基づく柔軟なルーティングと処理：シンプルなDSL（Domain Specific Language）を使用し、データ処理の流れをルートとして記述可能。豊富なコンポーネント：FTP、SFTP、JMS、HTTPなどのプロトコル、さらにAWS、Azureといった外部サービスの連携用コンポーネントを提供。Producer、Consumer、Processorの概念：データの送信、受信、加工をシンプルにモデル化。 サンプルコード from("sftp://[email protected]:22/source?password=sourceSecret") // Consumer: SFTPからデータを取得 .process(exchange -> { // Processor: データ内容を加工 String body = exchange.getIn().getBody(String.class); body = body.replace("oldValue", "newValue"); // 例: 文字列を置換 exchange.getMessage().setBody(body); }) .to("sftp://[email protected]:22/target?password=targetSecret"); // Producer: SFTPにデータを送信 上記はDSLを使用したApache Camelのルート定義の例です。分解して説明します。 Consumer：ファイルを取得 from("sftp://[email protected]:22/source?password=sourceSecret") Consumerはデータの入力元を定義します。RouteBuilder.fromメソッドの引数にコンポーネント（sftp）とそのパラメータを指定することで、ファイルの取得方法を定義できます。 Processor：ファイルの内容を加工 .process(exchange -> { // Processor: データ内容を加工 String body = exchange.getIn().getBody(String.class); body = body.replace("oldValue", "newValue"); // 例: 文字列を置換 exchange.getMessage().setBody(body); }) ProcessorはConsumerが取得したデータを加工します。データの内容や、取得したファイル名といった情報を格納するのがExchangeクラスですが、このクラスを引数に受け取るラムダ式として定義します。処理した結果は、再びExchangeに設定することで、続く処理で受け取ることが可能となります。 Producer：ファイルを送信 .to("sftp://[email protected]:22/target?password=targetSecret"); Producerはファイルの出力先を定義します。ProcessorDefinition.toメソッドの引数にコンポーネント（sftp）とそのパラメータを指定することで定義します。 なお、Consumer、Producerはコンポーネントを変更することで、容易にプロトコルの変更が可能です。こうした柔軟性もCamelの大きな特徴と言えます。 適用例 あるシステム内のサーバが、他のシステムにファイルを送信するときは、同一の方式で受け取り、送信先に応じてそれぞれの方式に応じて送信できるようにしました。ポイントは以下となります。 HTTPリクエストで送信要求を受ける代理サーバから送信するファイルを取得する送信先に応じて方式を変えて送信 これにより、 サーバ接続ロジックの集約を実現接続方式の変更があっても、一か所の修正で完結 とすることができました。さらに、 代理サーバからファイルを取得することで、ログインするための認証情報を代理サーバ側で一元管理HTTPリクエストで送信要求を受け取ることで、送信側はシンプルなHTTPリクエストの送信処理だけで実装が完結 とすることで、サーバ間を疎結合にできました。以下は送信要求を受信する箇所のコードです。 from("jetty:http://0.0.0.0:8080/transfer/{routeType}") // Jettyのリスナーアドレスを指定 .process( exchange -> { String path = exchange.getIn().getHeader(Exchange.HTTP_PATH, String.class); String[] paths = path.split("/"); // CamelHttpPathは"/transfer/hulft"のようになるため、splitすると{"","transfer",hulft"}になる exchange.getIn().setHeader(HeaderKeys.TRANS_ROUTE, paths[1]); exchange.getIn().setHeader(HeaderKeys.ROUTE_TYPE, paths[2]); }) .toD( "direct:${header." + HeaderKeys.TRANS_ROUTE + "}-${header." + HeaderKeys.ROUTE_TYPE + "}") .end(); また、リクエストパラメータとして送信先の情報を受け取り、それぞれのファイル送信用ルートに転送するように定義しました。これにより、ファイル受信用ルート１つに対して複数の送信用ルートを定義でき、コードの重複を避けることを実現しました。以下は送信処理のコードです。directコンポーネントを使用することで、指定したIDのルートに転送することが出来ます。 from("direct:transfer-" + this.routeId) .process( exchange -> { // SFTPでアクセスするユーザをプロパティから取得 String srcHost = exchange.getIn().getHeader(HeaderKeys.SRC_HOST, String.class); String accessUserKey = String.format(PropertyKeys.SSH_ACCESS_USER_KEY_FORMAT, srcHost); exchange.getIn() .setHeader( HeaderKeys.ACCESS_USER, exchange.getContext() .resolvePropertyPlaceholders(accessUserKey)); exchange.getIn().setHeader(HeaderKeys.SEND_DIR, this.sendDir); }) .process(new SftpRetrieveProcessor()) //ファイルを取得するためのSFTPコマンドを設定 .to("exec:command?useStderrOnEmptyStdout=true&exitValues=0") //ExecモジュールでSFTP実行 .to("direct:" + this.sendRouteName) //送信用ルートへ転送 .end(); まとめ システム間連携を代理するサーバは、ファイル送受信、HTTPリクエストの送受信等の似たような処理の、微妙な違いを吸収するために構築します。このため処理が重複しがちなのですが、Apache Camelを使うことで重複を省きつつ、異なる箇所だけ実装をすることができました。また、ルートの追加にもアドホックに対応できるため、今後の拡張性にも期待できます。私たちが扱うシステムは様々なシステムと連携することが多いので、今後は必ずApache Camelを導入するように啓蒙していきたいなと思いました。

この記事は GMOインターネットグループ Advent Calendar 2024 7日目の記事です。 はじめに レビューは、ソフトウェア開発やあらゆるフェーズにおいて欠かせないプロセスです。しかし、適切に行わなければ逆効果にもなり得るため、注意すべき点は多岐にわたります。本記事では、「絶対に避けるべきこと」をテーマに、特にソースコードレビューに焦点を当てつつ、その他の成果物レビューにおいても共通する失敗例とその影響、そして回避方法を詳しく解説します。 特に若手社員へのフィードバックでは、指導的な立場を保ちつつ、どのようにして建設的な意見を提供するかが重要です。この記事を通じて、効率的で効果的なレビューの実践方法の参考にいただければ幸いです。 言葉選びの極意！レビューで使ってはいけないフレーズ この章では、レビュー中の「言葉遣い」に焦点を当て、どのようなフレーズが受け手に悪影響を与えるか、そしてその代替となる表現を具体的に解説します。レビューはコミュニケーションの場であり、言葉選び一つで相手のモチベーションや受け止め方が大きく変わります。以下に、不適切なフレーズとその改善例を挙げます。 こんなの基本的なことです このフレーズは、相手の知識やスキルを軽視している印象を与え、成長意欲を削ぐ可能性があります。代わりに、「この点については、ベストプラクティスとして○○という手法もあります。参考にしてみてください。」といった表現を使うことで、指摘を学びの機会として提供でき、相手も提案を素直に受け入れやすくなります。 これって意味がありますか？ この言い回しでは、相手の努力を否定していると捉えられる危険性があります。相手の意図を確認し、建設的なフィードバックを行うためにも、より配慮した表現を用いましょう。例えば、「この部分の意図をもう少し詳しく説明してもらえますか？ もしかすると、もっと効果的な方法が見つかるかもしれません」と提案することで、互いの理解を深めながら、最適な解決策を探求することができます。 前にも同じミスをしています 何度も同じミスをすることは、レビュアーとしては見逃せません。ただし、単にミスを指摘するのではなく、「以前も同じ指摘をしたかと思いますが、まだ課題が残っているようです。この部分の改善を定着させるために、例えばチェックリストを作るなど、具体的な行動計画を立ててみませんか？」と、過去の間違いを指摘すると共に、改善のための協力を促すことで、前向きな改善活動へと導きます。 このコードを書いたのは誰ですか？ 複数人での会議中に「犯人捜し」のような発言は、チームの信頼関係や安心感を損ねることがあります。問題が発生した場合は、責任を個人に求めるのではなく、根本的な解決に向けてチーム全体でのアプローチが重要です。ミスは個人の責任だけでなく、チームのプロセスやリーダーシップの問題が原因であることも考慮に入れ、チーム全体でのプロセスの見直しを促すことが、将来的により健全なチーム運営につながります。また、個別指導が必要な場合は、プライベートな1on1の場を設けることで適切に対応しましょう。 他の誰かにやってもらった方が早いです 単に効率性を追求するだけのコメントは、相手の才能や努力を軽視していると受け取られ、モチベーションを低下させることがあります。このような状況で有効なアプローチは、チームの協力とスキルの共有を促すことです。例えば、「このタスクは特定のスキルセットを必要とします。チーム内で適切なサポートとスキルシェアが必要ですので、協力を仰いで効率的に進めていきましょう。」と表現することで、チーム全体の連帯感を高め、効果的なタスク遂行を促進できます。 それはタブー！レビューで触れてはいけないトピック この章では、「レビューに不適切な話題」に焦点を当て、その理解を深めます。レビューの本来の目的は成果物の品質向上であり、個人に対する非難や、コーディング規約に違反しない個人的なスタイルの押し付けは避けるべきです。以下に、レビューの際に避けるべきトピックの具体例を示します。 個人的な好みの押し付け 個人的な好みを押し付ける指摘は、客観性に欠け、レビュアーの自己満足で終わる場合が多いです。このような指摘を受けたレビューイは、具体的な改善点が見えず、「どうすればいいのか？」と戸惑い、作業の進行が滞ってしまうことがあります。より建設的なアプローチとしては、個人の感覚ではなく、チームが定めたコーディング規約や一般的な業界標準（ベストプラクティス）を参照し、それに基づいた客観的な理由を示しましょう。 個人攻撃 個人を批判する言葉、特に性格や人格、能力に対する否定的な発言は、相手のモチベーションを著しく損なうだけでなく、心理的な不安感を与える可能性があります。例えば、「どうしてそんなに遅いんだ」や「君はいつもミスばかりだ」といった性格や行動パターンを非難する言動は、相手の自己肯定感を傷つけるだけでなく、チーム全体の信頼関係をも崩す要因となります。パワハラを伴う言動は以ての外です。 問題点を指摘する際は、個人の特性や性格ではなく、具体的な事実や成果物そのものに焦点を当てて、建設的な指摘や対話を心がけることが重要です。 曖昧な指摘 曖昧な指摘は、受け手にとって具体性がなく、どの部分をどう修正すれば良いのか分かりません。この結果、確認作業が増え、レビュープロセス全体の効率が下がります。レビュアーは詳細なリンクや説明を提供し、どのように改善できるか明確なガイドラインを与えましょう。これにより、レビューのプロセスがスムーズに進み、時間の節約にも繋がります。 根拠のない否定 根拠のない否定は議論を停滞させ、相手に無力感を与えることがあります。これにより、何をどう改善すればよいのかが不明瞭となり、レビューの効果が低下します。レビューでは、具体的な問題点を明らかにし、それを改善するための明確な理由と具体的な提案を伴うことが重要です。改善することで、有意義なフィードバックが行われ、解決策に向けた建設的な議論が促進されます。 ちょっと待って！それだと時間無駄にしてるかも レビューは、効率よく、建設的に進めることが求められます。しかし、いくつかの習慣や方法が、知らず知らずのうちに時間の無駄を生み出しているかもしれません。この章では、レビューにおける「時間を無駄にする原因」と「その解決方法」を具体的に解説します。 レビューの確認観点を用意しない ソースコードレビューを行う際、コーディング規約や設計書が用意されていることは多いですが、レビューの確認観点が整備されていないケースも少なくありません。この場合、レビュアーが指摘する内容に一貫性がなくなり、場当たり的なコメントが増えてしまいます。結果として、必要な指摘が漏れたり、レビューイが曖昧な指摘に混乱して時間を浪費したりする可能性があります。 特に、業務特有の実装ルールがある場合には注意が必要です。例えば、ポリモーフィズムの使用方法や継承のルールといった抽象的な要件は、明文化されていないと漏れがちです。これを防ぐためには、レビューのチェックリストを事前に用意し、全員が共有することが有効です。こうしたリストは、NotionやConfluenceなどのツールを活用して管理することで、誰でも簡単に確認できる状態を整えられます。確認観点を明確にすることで、指摘の質を向上させるだけでなく、レビュープロセス全体の効率化にも繋がります。 「指摘したので修正お願いします。」とチャットでやりとり レビューにおいて、コミットIDやプルリクエストのリンクをチャットでやり取りするのは一見手軽に思えます。しかし、相手がすぐに返信や対応をしない場合、非同期のやり取りが何度も発生し、結果として時間を浪費してしまうことがあります。さらに、レビュアー側にも「自分の依頼が伝わったのか確認する手間」が生まれ、双方の生産性が低下します。 このような問題を解決するために、プロジェクトで使用しているバージョン管理システムやレビューツールの通知機能を活用するのがおすすめです。例えば、GitHubやGitLabにはレビュー依頼やコメントを自動通知する仕組みがあります。これにより、レビュアーが個別に連絡を取る必要がなくなり、レビューの進捗を確認する手間も大幅に削減されます。さらに、GitHubのプルリクエストタブを利用すれば、リポジトリをまたいでレビュー待ちのタスクを一覧で確認できるため、レビュアー自身のタスク管理も効率化されます。 このように、ツールを活用してレビューのやり取りをツール内で完結させることで、チャットによるやり取りの煩雑さから解放され、レビュー効率を飛躍的に向上させることが可能です。 ここの45行目を修正よろしく。画像ペタ。 レビューの中で、行番号やスクリーンショットを添付して修正箇所を指摘する場面があるかもしれません。しかし、この方法は受け手が該当箇所を正確に特定するのに余計な時間を要する場合があります。また、コードが更新された際に行番号が変わることで、コメントが無意味になるリスクもあります。その結果、レビューイが必要以上に修正箇所を探し回る時間を生むことになります。 この問題を解決するためには、コードレビューシステムの機能を最大限に活用することが大切です。GitHubやGitLabでは、特定の行に直接コメントを追加することが可能であり、レビューイはその箇所に即座にアクセスできます。また、該当部分に関連するリンクを共有することで、コード全体の流れを理解した上で指摘を確認してもらうことができます。例えば、「このメソッドの非同期処理化でパフォーマンスが向上する可能性があります。具体的にはこの箇所です。」といった具体的な説明を加えれば、レビューイはより効率的に修正作業を進められるでしょう。 適切な指摘方法を用いることで、受け手が最小限の手間で修正箇所を把握でき、コミュニケーションの齟齬を防ぐことができます。レビュアーにとっても、正確かつ建設的な指摘を行う習慣がつくため、全体的なレビュー効率が向上します。 ちょっと待って！そのリファクタリング指摘大丈夫？ リファクタリングは、コードをより良くするための重要な取り組みですが、慎重に行わなければ、かえって保守性やプロジェクト全体の効率を損ねることがあります。この章では、リファクタリング指摘における注意点を詳しく解説します。 冗長的なロジックだ！リファクタリング！ 冗長なロジックを見つけると、すぐに「共通化」や「簡潔化」を提案したくなるかもしれません。しかし、業務要件や設計意図に基づき、あえて冗長性を残しているケースもあります。このような設計上の冗長性を無視して指摘を行うと、後々の保守や拡張が困難になることがあります。たとえば、似たような処理でも、異なるモジュールや機能で将来的に分岐が生じることを見越している場合があります。 冗長なロジックのリファクタリングを提案する際は、将来的な利用方法を考慮し、共通化が新たな問題を生むリスクがないか慎重に検討する必要があります。 ここも念のためリファクタリングしてください。あとここも念のため。。。 リファクタリングが重要であることは間違いありませんが、すべてのコードに対してリファクタリングを行うのは現実的ではありません。特に、変更頻度が低いコードや影響範囲が限定的なコードに対して過剰なリファクタリングを行うと、プロジェクト全体の進捗に悪影響を与えることがあります。 リファクタリング指摘を行う際には、そのコードの変更頻度や今後のメンテナンス性を考慮する必要があります。もしリファクタリングが必要だとしても、「この変更がどのくらいの価値を生むのか」「その効果がプロジェクト全体に対して適切なコストで実現できるか」を評価することが大切です。むやみに「念のため」という理由でリファクタリングを提案するのではなく、具体的な改善効果がある箇所に絞り込むべきです。 テストコードは正常に通ってるし問題ないですね。多分。 テストコードが正常に動作していることはもちろん重要ですが、それだけで十分とは言えません。テストコードはプロダクトコードと同じように、チームにとっての資産です。特に大規模なシステムでは、テストコードの質がプロジェクト全体の信頼性に直結します。 テストコードをレビューする際は、単に「通ればよい」と考えず、次の点を確認してください。テストケースが十分に網羅されているか、意図が明確か、保守性が高いかどうかです。レビューの機会は貴重であり、プロダクトコードとテストコードを分けて考えるのではなく、一貫して高い品質を目指すべきです。 このリファクタリングは全クラスに横展開をお願いします。 リファクタリングの範囲が広すぎると、影響範囲が大きくなり、予期せぬ問題が発生するリスクが高まります。また、もし影響が発生した場合に、それを元に戻す作業が非常に複雑になる可能性があります。全クラスへの横展開を提案する場合には、実施する前に、影響範囲の特定やリスク評価を行うことが不可欠です。 特に大規模なリファクタリングの場合は、別のタスクやブランチとして分けて進めることを推奨します。これにより、問題が発生した際にも、迅速に元の状態に戻すことが可能になります。また、横展開する前に、限定的な範囲でリファクタリングを試し、結果を評価してから進めることで、プロジェクト全体への影響を最小限に抑えられます。 レビュアー３つの心得 ここまでお読みいただきありがとうございます。この記事では、レビュアーとして注意すべき言動や、より良いレビューのためのポイントを解説してきました。次に、レビュー現場で役立つ『レビュアー3つの心得』をお伝えします。これらを実践することで、建設的で価値あるレビューが実現できるはずです。 具体性を重視する 曖昧な指摘や「良くない」「修正が必要」の一言だけでは、指摘を受けた人にとって次に何をすべきかが分からず、フラストレーションを生む原因となります。具体的な改善案や参考コードを提示することで、相手が行動に移しやすくなります。例えば、次のような比較を考えてみてください。 NG：「この表現は良くないと思います。」OK：「○○という表現は広すぎて意図が伝わりにくいので、△△のように具体的にすると良いと思います。」 レビューは問題を指摘するだけではなく、解決への道筋を示すガイドであるべきです。具体的な例を挙げることで、レビューの価値を何倍にも高められます。 ポジティブな表現を心がける レビューは建設的な議論の場であるべきです。攻撃的な言葉や否定的なトーンは避け、提案型の表現でレビューすることを努めましょう。どんな指摘でも、受け手が「次はもっと良いコードを書こう」「もっと良い設計書を書こう」と前向きに感じられるかが重要です。 たとえば、次のような改善が考えられます。 NG：「こんな内容じゃダメです。」OK：「この部分が少し複雑になっているので、こう分けるとシンプルになるかもしれません。」 「ここは面白いアプローチですね」「こうするとさらに良くなりそうです」といった肯定的なコメントを織り交ぜると、相手のモチベーションが維持されるだけでなく、チーム全体の雰囲気も良くなります。 相手の意図を尊重する レビューでは、自分の視点だけでなく、相手の背景や意図を理解しようとする姿勢が不可欠です。自分の考えを押し付けるのではなく、質問形式で改善案を提示することで、議論を建設的に進められます。 NG：「こうするのが正しい。直してください。」 OK：「こちらは、○○という意図でしょうか？もしそうなら、この方法も検討できるかもしれません。」 また、時には意図を深掘りすることで、新たな視点が生まれることもあります。「なぜこの方法を選んだのか？」と問うことで、指摘を受ける人の工夫や前提条件を尊重しつつ、最適なアプローチを一緒に探ることができます。 レビュー改革のステップ！チーム全体で質を高める方法 この記事では、「レビュアーが絶対にやってはいけないこと」を中心に解説してきましたが、最後に、レビューをチーム全体で質を高めるための具体的なステップを紹介します。禁断リストを反面教師とするだけでなく、実際の改善につながるヒントを通じて、レビューがチームの品質向上に貢献する取り組みとなるよう、プロセスやルールの明確化と一貫性の重要性を解説します。 Gitのコミットの粒度はコミットコメント一言で伝わる範囲 コミットには、作業内容が明確に分かる粒度でまとめることが重要です。複数の修正や変更をひとつのコミットにまとめてしまうと、後にコードを追跡する際に困難が生じます。たとえば、ひとつのコミットに「バグ修正」「機能追加」「リファクタリング」が混在していると、どの変更がどの影響を与えたのかを判断するのに余計な時間がかかってしまいます。 この問題を防ぐには、コミットの粒度を「コミットコメント一言で説明できる範囲」に収めることを徹底しましょう。さらに、コミットメッセージには、関連するタスクやissue IDを明記するルールを設けると良いでしょう。たとえば、「fix[#123]:○○に関するバグを修正」や「feat[#456]:○○の新機能追加」といった形式で記述することで、作業の目的と内容がすぐに把握できるようになります。コミットの粒度を適切に保つことは、レビュー効率の向上だけでなく、将来的なコードの保守性にも寄与します。 レビューの粒度はタスク単位 レビューの対象範囲が広すぎると、レビュアーが見逃しを起こしやすくなり、指摘の質が低下します。一方、タスクをまたぐようなレビューは、何をどこまで確認すべきか曖昧になりがちです。その結果、細かな問題が見落とされるだけでなく、レビュアーの負担が増し、全体的な効率が下がってしまいます。 理想的なレビューの単位は、タスクやチケットごとに収めることです。バグ修正や機能追加といった具体的なタスク単位でレビューを行うことで、レビュアーが集中して内容を確認でき、フィードバックの質が向上します。さらに、タスク外の修正（「ついでにこれも直した」など）を避けることで、レビュープロセスがシンプルで明確になります。このルールを徹底することが、レビュー全体の透明性を高める第一歩です。 定期的なプロセス評価 コードレビューは、一律に決まったものではなく、チームやプロジェクトの状況に応じて柔軟に見直す必要があります。定期的にレビューの現状を振り返り、問題点や改善点を明らかにすることで、より効果的な方法へと進化させることができます。 見直しの際は、レビュー観点やレビュアー体制の再構築を含む議論を行うと良いでしょう。たとえば、レビュー観点が適切か、無駄な指摘が多すぎないか、あるいはレビュアーの負担が偏り過ぎていないかといった具体的な課題を洗い出します。また、ツールの活用状況や通知機能の効果を定期的に確認し、効率化の可能性を模索することも重要です。 このプロセスでは、単にレビュアーや開発者の意見を聞くだけでなく、レビュー時間、指摘件数、修正回数といった定量的なデータを活用することで、客観性と信頼性を高めることができます。定期的な改善を重ねることで、レビューはチームの成長を支える仕組みとなります。 こうした取り組みを継続することで、レビューは単なるフィードバックの場にとどまらず、チームのスキル向上やプロジェクトの品質向上に直結する重要なプロセスへと発展していくでしょう。 おわりに この記事を通じて、レビューにおいて避けるべき具体的な行動や、その背後にある理由についてご理解いただけたことと思います。コードレビューは、AIを活用することで一部のプロセスを自動化し効率化することも可能です。しかし、業務要件の深い理解やプロジェクト固有の実装ルールへの適応は、依然として人間のレビュアーが担うべき重要な役割です。 特に、細部における判断や提案は、技術的な洞察と人間ならではの視点が不可欠です。そのため、AIの力を活用しつつも、人間のレビューによる補完と相互作用が求められます。本記事を通じて、皆さまのレビューがより効果的かつ建設的なものとなり、プロジェクト全体の品質向上に寄与する一助となれば幸いです。

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/