技術情報 の記事一覧

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は1日目にリアル会場で開催された「データサイエンティスト対談 ～GMOだからできるデータサイエンスとは～」をご紹介します。 登壇者 スピーカー 財津 大夏GMOペパボ株式会社技術部 データ基盤チーム大学で統計や社会調査を専攻して2012年にGMOペパボに入社。ホスティングやECサービスのディレクターとしてデータ駆動マーケティングやサービス運用改善に取り組んだ後、2018 年よりデータサイエンティストとして、ログ活用基盤「Bigfoot」の開発とその利用によるサービス改善を進めている。春田 雅也GMOアドマーケティング株式会社開発本部 開発部 チーフ大学で情報工学を専攻していたが、途中で機械学習について興味を持ち、進学した大学院では機械学習の応用研究を行う。2020年4月にGMOアドマーケティングに新卒入社。GCPをはじめとしたクラウド周りのバックエンドを担当してインプットに励みつつ、主力プロダクトの「AkaNe」の広告配信やアドテクに携わる。一方で、広告最適化の一環として自然言語処理モデルの改修や掲載順位最適化モデル構築など、機械学習エンジニアとしても活躍している。石地 睦GMOペイメントサービス株式会社ビジネスインサイト部 部長コンサルタントなどを務めてテック業界で経験を積んできた。2016年に決済処理サービスを提供するGMOペイメントサービスに入社。所属する決済事業推進統括部 ビジネスインサイト部は、事業の継続的な成長を支えることをミッションに、決済市場のドラスティックな変化や、サービスを提供する上で日々起こるリアルタイムの課題にスピーディーに対応するため、ビジネスサイドにも寄り添い、データ分析を活かして開発を行っている。 モデレーター 佐野 唯一郎GMOインターネットグループ株式会社グループ研究開発本部AI研究開発室データ解析 AI研究グループ マネージャーSlerやコンサルタントなどテック業界で色々な経験を積み、2015年にGMOインターネットグループに入社後、グループ研究開発本部（旧：次世代システム研究室）に配属。一度、グループを離れた後、2020年に再度入社して現職。グループ研究開発本部ではグループ横断プロジェクトにおいて、データサイエンス技術などを用いて技術支援・開発・解析などを行っている。機械学習エンジニアを中心に、サーバーサイドAPIなど多岐で活躍。Androidアプリの公式言語Kotlin（コトリン）にハマっている。 GMOインターネットグループ 佐野、GMOペパボ 財津、GMOアドマーケティング 春田、GMOペイメントサービス 石地 GMOインターネットグループだからできるデータサイエンスとは何か？それを考えるカギとなるのはグループ全体が手掛ける事業領域の広さにあります。 GMOインターネットグループはドメインからセキュリティ、決済までビジネスの基盤となるサービスをご提供するインターネットインフラ事業を主軸に、インターネット広告・メディア事業、インターネット金融事業、暗号資産事業を展開する総合インターネットグループです。お客様に喜ばれるサービスを迅速かつ低価格で提供するために、サービスは機器の選定から設置、構築、開発、運用までを内製化することを基本方針としており、グループ全110社に在籍する7,200名超のパートナーのうち、ITのモノづくりを担う開発者（エンジニア・クリエイター）は49.9%（※数字はいづれも2022年9月末時点）を占めています。 そんなGMOインターネットグループには、データ分析やAIを活用はもちろん、グループ各社が横断的にデータサイエンス技術を提供し合うプロジェクトもあり、さまざまな領域のデータサイエンティストが、日々、お客様へより高い価値を提供すべく活躍しています。今回は、Ｅコマース、広告、決済・金融と、グループ4社から色々な立場のデータサイエンティストが集まりました。MLなど開発の裏側はもちろん、業務を行う上で大切にされていることをお聞きして、データサイエンティストが果たす役割から、今後の展望までを話しました。 いま注目しているデータサイエンス技術とは？ モデレーターを務める佐野が、それぞれ立場が異なる3名に話しを聞く形式でセッションはスタートしました。先ずはそれぞれ自社プロダクトに携わるなかで、いま注目しているデータサイエンス技術について問いました。 XAI（Explainable AI：説明可能なAI）ですね。3年前まで学生という立場では、機械学習モデルをより高精度にしていくアプローチに注力していました。それがAIをビジネスに適用するうえでは、なぜ精度が高くなったのか、お客様に納得できる判定根拠を「説明」できるよう求められます。広告運用ではモデル全体の精度より、特定の媒体様にどのような条件が判定に寄与しているか説明できなければなりません。そうしたことからXAIに着目しています。春田 GMOアドマーケティング 春田 佐野XAIの代表的なものとして「SHAP」（シャップ）というものがあります。各特徴量が結果に対してどのように寄与しているのか、それがプラスかマイナスなのかと特徴量間での利得配分によって説明します。広告だとCTR（クリック率）など予測するのに、最先端なアルゴリズムも出ていますが、説明性といったところをXAIなどで人がサポートしていくことが重要なんですね。XAIはゲーム理論が起源で、経済学部出身の私からすると親近感がありますね。Eコマースの領域に携わっている財津さんはいかがでしょうか？ GMOインターネットグループ 佐野 GMOペパボはクリエイターさんがイラストを登録してオリジナルコップやTシャツなど、オリジナルグッズ・アイテムの作成・販売ができるプラットフォーム「SUZURI」というサービスがあるなど、イラストレーターなどクリエイターさんに使っていただくサービスが多いという点から「生成系」に興味を持っていますね。2010年代からGAN（敵対的生成ネットワーク）などもあり、最近は人が書いたものと遜色なくリアルな画像生成が可能になっていたりします。そのなかで2つパターンがあると思います。ひとつは入力と出力が違うもの。「テキスト」を入力すると「画像」を出力するものです。もうひとつは入力と出力が同じもので、「画像」から「画像」を生成するといったものです。前者は絵を描けない人でも、テキストベースで絵を書けるようになるなど、表現の幅が広がると思います。後者は絵を描ける人が、自身の画風を学習させて、表現の新たな技法や可能性を広げることに繋がります。そうしたことから興味を持って追いかけています。財津 GMOペパボ 財津 佐野いまチャットボット「ChatGPT（チャットジーピーティー）」（※OpenAIが2022年11月に公開）が大きな話題になっていますが、1年以上前に発表されたGPT-3（2020年7月）から、自然な文章が生成できると大きな話題になっていました。私もコードを生成してすごいと衝撃を受けましたね。そのコードがそのまま使えるとは限らないですが、人の思考をサポートしてスニペットを提供するというのは有用だなと感じました。人の活動を後押しするのが生成系AIの意義だという話ですが、一方でデザイナーの方の作品を無断で学習データとして使用することは著作権的な側面はもちろん、倫理的な問題もはらんでいます。その辺り、財津さんはどのように考えられていますか？ GMOペパボとしてやりたいのはクリエイターさんをはじめとした「人の表現活動を支援すること」です。作品を無断で学習データとして使用することが法律的には問題がなかったとしても、サービスに嫌悪感や反感を抱かれてしまうということは多分に起こると想定できます。そうなったら我々は何のために事業を行っているのか分からなくなるので、双方で合意が形成されている学習データを担保していくというのが、生成系AIを導入させる上では、大切なことだと感じます。 財津 佐野私も自分の書いたコードが勝手に使われて「出力」されたら、嫌だなと思うかもしれないですね。我々はお客様第一なので、いくら優れた生成系AIだとしても、お客様が不快になることはしてはいけないと考えます。堅牢性が求められる決済サービスに携わる石地さんはいかがでしょうか？ 石地堅牢性という点では、弊社のような決済サービスではAIが誤った判定をすることは絶対に避けなければいけませんね。いま着目しているのはデータ間の関係から、人が見えないかたちでデータを表現していくことです。我々のサービスをご利用いただいているグループ・集団のデータでの表現力が高いほど精度が高いモデルが作れるのではないかと考えています。そこでグラフニューラルネットワーク（GNN）を用いてグラフ化して、そこから特徴量を創り出していくことで、見た目のデータからは出来ない新たな表現が出てきます。こうした手持ちのデータからポテンシャルを引き出すといったことに、積極的にチャレンジしていきたいと思っています。 GMOペイメントサービス 石地 佐野ータの関係性を表す、グラフニューラルネットワーク（GNN）は、さまざまなシーンで使えますよね。それぞれお3人に注目する技術についてお話しをお聞きしましたが、Developers Dayなので、エンジニア視点で開発面の話も聞けたらと思います。 ML開発時に、それぞれが注意していること 佐野マシンラーニングサービス（MLサービス）や、それに関わるデータ分析基盤の開発時に皆さんはどのような事を注意しているか、エンジニアの一人として、すごく聞きたいです。要件を定義して開発からルールベースで動いてくれるWebアプリ・モバイルアプリと、MLサービスを比べると大きな性質の違いを感じます。MLサービスではプログラム開発時は正しかった概念が、パラダイムシフトしていき、将来的にデータのドリフトや分布が変わっていくことにも適応していかなければいけない。そんなML開発で皆さんが意識していることは何かが気になります。 広告最適化では、ユーザーに広告を掲示するまでの速度が重視されます。新しい機械学習モデルを導入した際、既存のプロダクトに悪影響は出さないのはもちろんですが、最適化から掲載までのスピードは意識されていて、0.1秒単位の世界と言っても過言ではありません。そのため学習コストや予測コストが高すぎるものは性能要件に引っかかって導入できないケースというのも多くあります。春田 石地サービスに悪影響を与えてしまったら本末転倒ですよね。ローカルの環境でモデルつくるとパフォーマンス重視になりがちですが、それが実際の環境下では負荷になったりするので、パラメーターチューニングを何度も行いました。またAIに学習した以上のことを逆にして欲しくないですよね。開発側とAIを活用する分野の範囲を明確化しています。常にフレッシュなデータ、フレッシュなモデルを渡しつづけないといけないので、それらがクイックに出来るよう、開発に着手する時点でシステム側と運用方針も決めました。AIを実装したことで、アプリ側の開発部隊の作業依頼などの負荷の増加も起こしていけないと思うので、そこにも注意しています。 佐野確かにそうですね。皆さんのお話しを聞いて、業種は違えど、割と抱えている問題は一緒だなというのを感じます。開発から運用の話に近い話になりますが、開発したものを継続していくなかで、クリーンに保っている知見をお聞かせいただければと思います。 ペパボの開発体制は事業部制なので、サービスの運用・開発をしている事業部と、私たちのデータ基盤チームがいます。複数人で開発をすることでクリーンに保つことを推進するために、データカタログのようなドキュメンテーションを基盤チームの方で整備して、みんなで勉強していくことで、開発も運用もしやすくなる施策を行っています。Googleの「Vertex AI」は検証中ですが、自分たちが使うワークフローエンジンを使って、ビジネスサイドも含めて、精度を見ながら、どうやってモデル改善しようか議論するところまで運用として回せることを心掛けていますね。 財津 佐野機械学習はデータを得て結果が生まれるので、お客様にタッチする立場のビジネスサイドを巻き込まないといけない。そのためにドキュメントや資料の準備は、非常に重要ですね。 データサイエンスが、日々、大切にしている技術検査 佐野次にデータサイエンティストとして、どのように技術検査をしているか。インプットとアウトプットの方法はいろいろあると思いますが、伺ってみたいと思います。 石地オンライントレーニングを多用して学習しています。いまではさまざまな企業や大学がMLをテーマに講義や学習コースを提供してくれていますね。私は以前、「edX」（ハーバード・MIT主導のMOOC）を受講していました。オープンデータを渡されて、学んだことから分析レポートを提出する課題があるのですが、受講生のなかから、相互レビューをして3人以上からレビューをもらえないと、次に進めないカリキュラムになっています。そこでそれぞれレビューし合うのですが、同じデータでもこういうアプローチの仕方があるのだと発見があり、学びが深まります。レビューで褒められると素直に嬉しいですし、分析アプローチが甘いんじゃないかと辛辣なコメントもありますが実務に近く感じられる。そうしたコミュニティのなかで学習できたことは大きな経験になると思いますね。 佐野「edX」いいですね！エンジニアとして、コードをどうキレイに整えていたか、あらためて考えると同じ仲間のソースコードレビューってめちゃくちゃ大事だと思っています。パーフェクトで提出したものに、いろいろな訂正が入って、それを何十回何百回、何千回と繰り替えてして、いまに至っている実感があるので、データサイエンスでも、そうしたレビューは成長につながると聞いていて感じました。春田さんはどうですか？ 普段はプライベートな勉強会と称して、週1回、人を集めて、勉強会を開催しています。そこで機械学習関連の技術書を選んで、具体的な機械学習の手法や機械学習のモデルを組むときのパターンの習得など、皆で学んでいます。春田 私も機械学習関連の技術書を読むことが多いです。手法的なところだと「Kaggle（カグル）」でスコアが高いレポートを読んだり、機械学習関連のニュースを見て、キャッチアップしています。 財津 佐野レポートを読むだけでも新しい発見につながりますね。「Kaggle（カグル）」は参加の敷居が高いと思われがちですが、まずそういった所から慣れるというのがいいですね。 さいごに 佐野GMOインターネットグループにはさまざまな分野の技術者がいます。データサイエンティストといっても経歴も多様で、私の同僚ではリサーチャーや研究者からデータサイエンティストに転向する方など、色々なバックグラウンドを持っているというのも、特徴のひとつだと思います。さいごに副題にもなっている「GMOだからこそ挑戦できるデータ分析」を伺ってみたいと思います。 GMOインターネットグループ全体もですが、GMOペパボ内でもECをやっていたり、ホスティングをやっていたりと、幅広く事業を展開しています。そうした適用先が違うデータ分析や機械学習モデルを、どんどん組み込んで実装していくことが出来るのが、私は、いちばん楽しいというか、挑戦できるところかなと思っています。 財津 プロダクトも内製化されていることで、データを使って学習ができる幅が広がっています。またGMOアドマーケティングでは、業務時間の一部をインプットの時間に充てており、その時間で知見やスキルを高めているのはもちろん、得たモデルを実際に試すことができる環境があるのは強みだと思っています。春田 石地データの豊富さを活かすことができる環境というのは大きいですね。自社のサービスや事業が成長していくことでお預かりするデータ数も増えていきます。また変化が早いが早く、スピード感を意識して、実行しなければないことも、たくさんあります。その分、アウトプットは速くなるので、そうした経験が積める環境も、魅力のひとつじゃないかと考えています。 佐野データの量もそうですし、決済もあれば広告もあって、ECもあって、バラエティに富んだデータが飛び交っていて、挑戦できるというのはGMOインターネットグループだからこそですね。私の所属するグループ研究開発本部AI研究開発室は、グループ各社のAI開発のお手伝いをさせていただくことが多いですが、組織も違えば、それによって生まれてくるデータの種類も量も違うので、どういったアーキテクトを組もうか、レコメンドアルゴリズム良いか、それぞれの立場に合わせて常に考えています。そうした多様な分析に携わることは大きな魅力だと思えるところなので、ぜひそういうところにチャレンジしたい方がいらっしゃったら、仲間として、一緒に働ければなと思います。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/Sh0a7bx7ThI

弊社は､RPA No.1導入企業を目指しており､先日開催された「GMO Developers Day 2022」という比較的大きなイベントでも Power Apps や Power Automate ､ Microsoft Lists といったツールを駆使して､開発を行いました｡今までのノーコードローコード開発の中で最も大きな案件を終えて､見えてきた課題や学びを紹介いたします｡ ノーコードローコードを本格導入した結果 ノーコードローコードは､開発時間をできる限り抑えたい人向けのツールとなります｡ 複雑な機能､速さを求められる機能､負荷がかかる機能などのシチュエーションでは､使用を控えたほうが良いと思います｡ 今回､ノーコードローコードでほとんど実現できましたが､負荷がかかる部分などは対策が必要だと感じました｡ 実際に､ノーコードローコードで開発したシステムの構成図は以下となります｡ この中で､｢スタンプラリー機能｣が今回負荷が高まっている部分となります｡ では具体的に､このイベントではどのようにノーコードローコードを使ったのか､どのような課題が見えてきたのかについて詳しく見ていきましょう｡ 使用技術と設計 このイベントは大きく分けて4つ､｢登録機能｣､｢リマインド機能｣､｢受付機能｣､｢スタンプラリー機能｣に分けられます｡ またノーコードに適しているもの､ローコードに適しているもので分けられます｡ 登録機能 お客様が登録画面のフォームを入力して送信し､入力された情報をメール経由で Power Automate が取得Power Automate で取得したメール情報を抽出し､今回お客様情報を保存するようのデータベースとして使用している Microsoft Lists に情報を保存 リマインド機能 Microsoft Lists に存在するお客様情報を取得し､リマインドメールを送信 受付機能 入場された方のQRコードを Power Apps で読み取って､Microsoft Lists に存在するかどうかを確認配信ページからアクセスされた方のメールアドレスが､Microsoft Lists に存在するかどうかを確認 スタンプラリー機能 お客様が入力されたキーワードを Microsoft Lists 保存 ノーコードに適しているものは､｢リマインド機能｣､｢受付機能｣となります｡ ローコードに適しているものは､｢登録機能｣､｢スタンプラリー機能｣となります｡ ノーコードで使用した技術は主に以下のとおりです｡ Power AutomateMicrosoft ListsPower AppsPower BI Microsoft Lists は､UIとしての機能を重視して､通常のデータベース設計のような正規化などは行わず､設計しています｡これは､Microsoft Lists は開発者だけが見るものではなく､運営の方も頻繁に確認するためです｡ ローコードで使用した技術は主に以下のとおりです｡ Office Scripts外部のAPI 例えば､登録機能において､Office Scripts はメール本文を抽出するために使用して､外部のAPIなどでは､QRコードを発行したり複雑な処理を行ったりすることに使用しています｡ 課題として見えてきたもの ノーコードローコードは､一定の負荷には対応でき､短時間の大きな負荷には弱いと思います｡ 例えば､スタンプラリー機能は短期間に非常に多いアクセスを頂きました｡ これは､｢GMO Developers Day 2022｣がイベント会場だけではなく､オンラインからアクセスする方が想定以上だったことと､登壇者のセッションが終了するタイミングで､スタンプラリー用のキーワードが公開され､それにより非常に多くの方が短期間にアクセスを行ったことが要因となります｡ 対策 対策は､依頼者の方と非機能要件についてコミュニケーションを取るということです｡もし､負荷がかかる場合やどのくらいアクセスするかわからない場合は､別のアプローチで実装するべきだと思います｡ ローコードの部分を FaaS や PaaS ､ CaaS などで実装したり､ Microsoft Lists で扱えないような大量のデータなどは､サーバレスな SQL や NoSQL のDBなどを使うなどです｡ まとめ ノーコードローコードは開発時間をできるかぎり抑えたい人向けのツールとなります｡複雑な機能､速さを求められる機能､負荷がかかる機能などのシチュエーションでは､使用を控えたほうが良いと思います｡ ノーコードローコードでは､短時間の負荷には弱いと思います｡負荷がかかる部分はマネージドサービスなどを使用して対策しましょう｡

こんにちは。GMOインターネットグループ株式会社の新里です。最近はDALL・E 2、Midjourney、Stable Diffusionなどを使って画像を自動生成するのはよく見かけますね。他にもOpenAIが出したChatGPTでテキストで対話するモデルだったり、機械学習は本当に日進月歩で進んでいるように感じます。ここでは、OpenAIが2022年末に公開したPoint-Eを使って、テキストから3Dモデルを生成してみます。 テキストから3Dを生成～3Dプリンタで印刷 入力としてテキストから3Dモデルを生成するものは色々ありました。Point-E （OpenAI）、Dream Fusion（Google）、Magic3D（NVIDIA）などですね。GoogleはImagen（Text to Image）のモデルは公開していないので、Stable Diffusionを利用したStable Fusionというのも公開されていました。ここではPoint-Eを使って3Dモデルを生成、さらにそのモデルを3Dプリンタで印刷する所までやってみます。 Point-Eのコード お手軽にGoogle Colab上でPoint-Eを動かしてみます。githubにサンプルコードがあるので、そのままGoogle Colabに持ってくれば動きました。テキストから点群を作ってくれるのは text2pointcloud.ipynb ですね。あと、メッシュにする pointcloud2mesh.ipynb を使えばPLYファイルを生成・OBJなどに変換して3Dプリンタで印刷できそうです。どちらのコードも非常にシンプルでマージしてしまえば、サクッと動かせそうです。 !pip install -U scikit-image !pip install git+https://github.com/openai/point-e !nvidia-smi import torch from PIL import Image from tqdm.auto import tqdm import matplotlib.pyplot as plt from point_e.diffusion.configs import DIFFUSION_CONFIGS, diffusion_from_config from point_e.diffusion.sampler import PointCloudSampler from point_e.models.configs import MODEL_CONFIGS, model_from_config from point_e.util.plotting import plot_point_cloud from point_e.models.download import load_checkpoint from point_e.util.pc_to_mesh import marching_cubes_mesh from point_e.util.point_cloud import PointCloud device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') # モデル群をダウンロード base_name = 'base40M-textvec' base_model = model_from_config(MODEL_CONFIGS[base_name], device) base_model.eval() base_diffusion = diffusion_from_config(DIFFUSION_CONFIGS[base_name]) upsampler_model = model_from_config(MODEL_CONFIGS['upsample'], device) upsampler_model.eval() upsampler_diffusion = diffusion_from_config(DIFFUSION_CONFIGS['upsample']) base_model.load_state_dict(load_checkpoint(base_name, device)) upsampler_model.load_state_dict(load_checkpoint('upsample', device)) # 生成する点群の設定 sampler = PointCloudSampler( device=device, models=[base_model, upsampler_model], diffusions=[base_diffusion, upsampler_diffusion], num_points=[1024, 4096 - 1024], aux_channels=['R', 'G', 'B'], guidance_scale=[3.0, 0.0], model_kwargs_key_filter=('texts', ''), ) # "一人がけのソファで、ゆったりとした背もたれ" というプロンプト prompt = 'One-person sofas with spacious backrests.' # 3Dモデルの生成と表示 samples = None for x in tqdm(sampler.sample_batch_progressive(batch_size=1, model_kwargs=dict(texts=[prompt]))): samples = x pc = sampler.output_to_point_clouds(samples)[0] fig = plot_point_cloud(pc, grid_size=3, fixed_bounds=((-0.75, -0.75, -0.75),(0.75, 0.75, 0.75))) # ここから点群をメッシュ化 name = 'sdf' model = model_from_config(MODEL_CONFIGS[name], device) model.eval() model.load_state_dict(load_checkpoint(name, device)) mesh = marching_cubes_mesh( pc=pc, model=model, batch_size=4096, grid_size=128, progress=True, ) # PLYとして保存 with open('model.ply', 'wb') as f: mesh.write_ply(f) 生成された3Dモデル 出来たmodel.plyをダウンロードしてきて、ビューアーで見るとこんな感じになりました。 それっぽいソファーな感じですね。1人用のはずが、2人くらいは座れそうな気はしますが、良い感じです。PLYをOBJ、STLにMeshLabなどで変換して3Dプリンタに与えてスライスします。 出来たもの フィラメントは赤で出力したので、以下のような感じになりました。椅子の方は"2023年に流行るオシャな椅子"というプロンプトで出力したものです。 これからも期待 一応、プロンプトを与えて現物が出来るという所まで出来ましたが、複雑な構造などはまだ少し微妙です。例えば、これは「リンゴの形をした妖精」というプロンプトを与えたときのものです。 うーん、ちょっと何か微妙な感じがしますね。ただ、「こんな物が欲しい・見てみたい」と指示をすると、画面上だけではなく、実際に現物・リアルな物として出力できるという世界線が近づいてきた感じがします。

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ではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は1日目にリアル会場で開催された「クリエイティブリードの実践、クリエイターが活躍する組織とは？」をご紹介します。 登壇者/スピーカー スピーカー 宇都宮 賢二GMOサイバーセキュリティ byイエラエ株式会社プロジェクトマネジメント部 / 執行役員小久保 浩大郎GMOペパボ株式会社執行役員CDO兼デザイン部部長 モデレーター 岡本 くる美GMOメディア株式会社サービスデザイン部部長 （左から）GMOメディア 岡本、GMOサイバーセキュリティ byイエラエ 宇都宮、GMOペパボ 小久保 GMOインターネットグループでクリエイティブ業務を先導する立場にあって、社内でクリエイター活躍の場を考える3人が参加したこのセッション。クリエイティブリードの取り組みや考え方などを紐解いていきます。 本イベントの「GMO Developers Day」は、名前の通りどちらかというとエンジニア向けという色の濃いイベントです。ただ、今回はキーワードとして「クリエイティブ」が掲げられており、クリエイティブにも注力していく姿勢を示しています。そのキーワードに沿ったセッションとして設けられたのが、この「クリエイティブリードセッション」です。 クリエイティブリードとは？　その役割に迫る そもそも、「クリエイティブリード」とはなんでしょうか。小久保は、一口にクリエイティブリードといっても、組織によって役割は変わってくると話します。「一般化して言えるのは、クリエイティブの投資と効果、その方向性をリードしていくことです」（小久保）。 GMOペパボ 小久保 GMOペパボは複数のブランド、複数のサービスを運営しており、そうしたブランドやサービスをまとめる立場にあるのが小久保です。「全社的なリソースを何に、どのように投資して、どういったリターンを導くかという設計、実現のための組織体制の構築、デザインのプロセスの改善」などが小久保の仕事だと言います。 GMOサイバーセキュリティ byイエラエでは、宇都宮の下にデザインだけでなくプロデューサー的な役割を担うチームも存在しているとのことで、クリエイティブリードに加えてプロジェクトリードも兼ねているそうです。 GMOサイバーセキュリティ byイエラエ 宇都宮 小久保が費用対効果について言及したように、宇都宮も「今のクリエイティブは、単純にいいデザインを出すだけでは不十分になっています」と指摘します。そのため、事業に対してどの程度インパクトがあるか、論理的に説明できることがクライアントからも求められています。 「クリエイティブとして大きな指針を出すこと、それは事業に対してどのくらいアラインしているのか、どういう着地になるのか、プロジェクト全体を俯瞰して見る、その両方をしています」と宇都宮は自分の立場を説明。ただ、マネジメントスタイルとしては「放牧タイプ」とのことで、「デザイナーが道に迷ったり、狼に食べられそうになったり、そういうことがなければ丸投げしています」と宇都宮は話します。 2人の回答を受けて岡本は、「クリエイティブ」というのは、見た目が良い、かっこいいデザインのバナーLP（ランディングページ）を作る、などといった華やかなイメージのものではなく、「なぜ作るのか」「費用対効果はどうか」「プロジェクトをどう進めていくのか」といった点まで考慮が必要な、チーム全体に関わる大事なことだと指摘します。 GMOメディア 岡本 とはいえ、人材を配置して必要な設備を揃えるなどといった費用に対する効果をどのように測定するかは難しいポイントです。それを岡本が問いかけると、小久保は「色んな人に分かる形で示すのが本当に難しいと常々感じています」と正直な心情を吐露します。「今年（2022年）の半分ぐらいは、それに頭を悩ませていたら時が過ぎていたような感じがあります」（小久保）。 それだけデザインやクリエイティブの効果を定量化することは難しいのです。「デザインやクリエイティブという分野では、アウトプットの作用する対象が人間や社会である」というのが小久保の考え。一人一人で異なる個人がまとまって社会という形になると、それぞれが色々なものに影響を受けながら受容態度を変えていく。それに対してある形を伴ったアウトプットの影響を、定量的に測定するのは極めて難しい、と小久保は話します。 そのため小久保は「地球エミュレーターが欲しい」と笑います。1つの施策に対して、社会が、個人が、どのようにそれを受け取ってどのように変化するか、ひとつひとつテストができる、そんな架空のエミュレーターが必要になるほど、効果測定の定量化が難しいと小久保は頭を悩ませているようです。 それでも、「施策を要素還元して細分化してそれが何かを明らかにして、そうした要素の関連性を理解していくことで、アウトプットがもたらす結果を推測して、投資と効果がだいたいこんな感じじゃないかと考えて、周りと共有しようとしています」と小久保は説明。 小久保はこうした「大枠の物の見方」を提示するのが自身の役割の1つだとしています。アウトプットに対しては現場により近いデザイナーの肌感や判断を生かしつつ、「現在のユーザーはこういう状態なのではないか」というアドバイスをすることがあると言います。 ユーザーがどんな人か、どんな困難を持っているか、どんな欲望を持っているのか、何を知っていて何を知らないか、どういったコンテキストの中にいるのか。そういった要素を掛け合わせていくと、ユーザーにとってバリューとなるものが立ち上がってくる。こういった考えを提示することでより具体的にデザイナーに考えてもらう、という役割をしているそうです。 宇都宮もそうした考え方に賛同。宇都宮は、クリエイティブリードの役割を「方向性を出していくこと」と表現します。 それは仕事において大局を見ることで、ディテールにこだわるのでなく俯瞰して見るというのは「特に経験が浅いと難しい」（宇都宮）。そのため、自身はあえてディテールにこだわるのではなく大局を見て、デザイナーやチームメンバーがディテールを見るという明確な役割分担をすることで、その下で働くパートナーの仕事のやりやすさも変わってくるというのが、宇都宮の考えです。 過去には、宇都宮も「マイクロマネージメント」だった頃があったそうで、「デザイナーが上げてきたフォントのマージンは自分で調整する、今となっては嫌な上司でした」と笑います。現在はデザイナーに任せて大局を見る、そういった距離感が自分なりに見つけられたと宇都宮は話します。 小久保は、「細かいところも大切にしていてデザイナーと一緒に考える仲間」だということを示すために、あえて細かい点も指摘することがあるそうです。 こうした回答に対して岡本は、デザイナーやクリエイターに問いかけをし続けたり、新しい視点を投げかけたり、といった役割がクリエイティブリードにはあるとまとめました。 クリエイターをどう動かして、どう組織するか 現状の課題や取り組みを尋ねてみると、宇都宮は「いかに違うスキルを持った人たちを、1チームで1プロジェクトのために動かしていくか」という観点で回答します。パートナーを含めたメンバー同士が相互のリスペクトを持っているかどうか、「そういった受容性が求められます」と宇都宮。 1つのプロジェクトはバックエンドを含めたエンジニアも含めて様々なスキルの人で成り立っているので、違うスキルの人とどれだけ1チームを作っていけるかが、デザインに限らず組織上も重要なポイントで、それには相互のリスペクトが必要というのが宇都宮の考えです。 デザイナーのモチベーションという課題もあります。「デザイナーはややもすると、誰もやったことがないような新しいデザインをやりたいという思いが強い」と宇都宮。宇都宮自身もその気持ちは分かるそうですが、ビジネスとしては、クライアントと一緒に淡々とサービスのバージョンアップしていくような、ドラスティックではないけれどビジネス的には大きな事業もあります。 デザイナーも新しいことだけをやっていけるわけではないものの、そうした仕事はデザイナーのモチベーションとしてなかなか繋がらない。そのバランスを取ることが組織上は重要だといいます。 「逆の見方がある」と言うのは小久保です。GMOペパボには40人ぐらいのデザイナーがいるとのことで、4～5つの事業部に分かれてサービスを運営し、それを横断する形でデザイン部が存在していると小久保は説明。 事業部で分かれているため、その中で目標達成していくという考えになり、日々の課題解決や次の達成目標に取り組むことを、事業部のみんなでやるというマインドセットになりがちだといいます。 そうなると「ややもすると大きな新しいこと、パッとしたことを大胆にやろうという発想に行きにくくなってしまう」という状態になることがあると小久保は指摘します。その背景には、GMOペパボが自社サービスメインで、少なくとも年単位のスコープで自社サービスを成長させることにフォーカスしている点があり、クライアントとのビジネスが中心のイエラエ社との違いではないかと小久保は推測。 組織によって属しているデザイナーのマインドセットは変わってくるものの、どちらか一方に偏りすぎないようにバランスを取ることも、クリエイティブリードの役割の1つだと小久保は言います。 「シニアデザイナー」の役割の言語化 小久保は、2019年にGMOペパボ入社した際に取り組んだ施策があるそうです。GMOペパボには人事制度として等級制度があり、各等級には求められる能力があるとのことですが、その中のシニアデザイナーに対する要求を改めて言語化したそうです。 「シニアデザイナー」と聞くと、立ち居振る舞い、言動などのレベルがその会社を表しているといってもいいレベルが期待されるとして、小久保は「GMOペパボのシニアデザイナー」のあり方を定義したいと考えたとのこと。当時のシニアデザイナーが持っていた「シニアデザイナー観」と、小久保の考えている定義との間にギャップがあったのだといいます。 入社間もない小久保の言葉に、当時のシニアデザイナーたちも理解を示して求める姿になろうというアクションをして、短期間でキャッチアップしたそうです。 イエラエ社では、デザイナーのクラス分けはあるものの、体系化された「シニアデザイナー観」のようなものはないそうで、小久保に対して「資料をいただこうと思いました」と笑いました。 生産性を高めて遊びの時間を作ることも大事 続いての岡本の質問は、クリエイティブリードとして大事にしていること、意識していることは何か、というものです。 宇都宮はまず、「GMOの場合、デザインやクリエイティブはデザイン分野がメインになるので、デザインの良し悪しがクリック数や購買など、結構目に見える形で評価されてしまう」と指摘。 そのため、デザインにどれほど魂を込めても、お客様が反応してくれなかったということが、数字で明確に表れてしまいます。デザイナーは、「なぜこのデザインになったのか」ということを言語化できることが必要だというのが宇都宮の考えで、「論理的にきちんと説明できることが今のクリエイターには求められている」として、そういう感覚を持つようにデザイナーやパートナーに話しているそうです。 加えて宇都宮は「虫の目、鳥の目、魚の目」を大事にしていると言います。ディテールはチェックしつつ俯瞰して見て、全体のマーケットの流れ、今後の時代の流れを見る、という意味で、すべてのビジネスで当てはまる言葉だと宇都宮は説明。特にクリエイティブのようなトレンドが早い分野では重要という認識で、宇都宮自身は「特にこの目を意識して仕事をしている」そうです。 小久保は、「納得感」というキーワードを大事にしていると言います。これは、「デザイナーが自分の仕事に対して持つ納得感」と、「デザイナーと一緒に働く他の職種や経営者から見て、そのデザインのアウトプットが、その組織に対して良い働きをするものであるという納得感」という2つの意味があり、「両方向の納得感を作ることを意識している」と話します。 「組織としての成果を出す、そのための取り組みを凄く大事にしています」と小久保。これは、全員でサッカーボールを追いかけるような子供のサッカーではなく、役割や立ち位置を考えた上で全体としての効果を最大化することを意識しているといいます。 加えて、デジタルツールによってデザイナーの生産性も向上していますが、既存のツールをただ使っているだけでいいのか？という問いかけを小久保はします。「求められているアウトプットに対して、どういう道具があったらより生産性を高められるか」という考え方を大事にしていると小久保は強調。 GMOペパボでのデザイン部のような横断組織を作る、デザインのガイドライン作り、共有アセットの作成など、組織だからこそできるような様々な道具を作ることで生産性を上げる、そんなことを大切にしているそうです。 この「生産性を高める」のはなぜかといえば、小久保は「遊ぶ時間を作るため」と告げます。「遊びと仕事」の間にある違いを小久保は、「確たる目的を持つか持たないか」と表現。遊びという無目的の中で取り組むことで得られる知見や発見が大事で、遊ぶ時間を作ることであたらしいものに触れる、トライする、そういったものが必要だという考えです。 その遊びの中から、ビジネスとしての投資につなげるかどうかを判断するのもクリエイティブリードの役割だと小久保。その判断の理由もドライな言葉ではなく、ウェットなコミュニケーションを取る、そうした言語化も大事だと小久保は話します。 クリエイターが活躍する企業グループとは 続いての質問である「クリエイターが活躍する企業グループ」を実現するために必要な考え方として、宇都宮は「リスペクト」を挙げます。今までビジネスサイドが中心だった企業やテック中心の企業などが、クリエイティブを新たに取り入れようとしても、「違う文化を持っている人たちと対等にやるのはハードルが高い」との考えを示します。 その時に「相手に対するリスペクトをどれだけ持てるかどうか」という点が一番重要だと宇都宮。それによって、ユニークなチームを作ることができるのだと話します。自分とは異なるスキルを持つ人に対してリスペクトを持って、受容性を高めていけるか。それが、クリエイターが活躍する企業グループになるためのキーになるというのが宇都宮の回答です。 これを受けて岡本は、「GMOインターネットグループには7,000人ほどのパートナーがいて、各社にクリエイターがいて、それぞれ得意としている分野も異なりますが、そういう中でお互いをリスペクトして（グループで）シナジーを作っていく、それが来年（2023年）に取り組みたいことなのかと感じました」と感想を述べます。 今回のセッションでは「言語化」という言葉が1つのキーワードとなっていましたが、小久保は「クリエイティブリードの役割は言語化が必要だとは思いますが、同時に言語化しきれない、できない、未分化な部分の価値を感じ取って理解して、それを育むことと両立しなければならない」という考えを披露。 ただ言語化をやりきればいいというのは、クリエイティブリードの領域においては役割の半分で、一方で「雑な言葉で言えば"エモい"といったことを肌感としてちゃんと分かること、それを重要視して育んでいくこととの両立が大事」だと小久保は言います。 クリエイターが活躍する企業グループは、こうした未分化な領域や言語化しきれていないものに対しても「勇気を持ってベットできる組織」であり、こうした"ベット"ができるような組織に持っていくことがクリエイティブリードの仕事の1つと言います。 さいごに セッションの終盤では、参加者から寄せられた「シニアデザイナーの役割の言語化」「取得しているスキルセットでは見えないような領域での生産性を向上させる言語化を教えて欲しい」という質問に対しての回答が示されました。 小久保は、シニアデザイナークラスの人に求めるものとしてスキルに加えて「理想が描けること」を挙げます。これは、物事に不満があってこうあるべきだという考えがあって、そのために必要なアクションができる、ということで、「別の言い方で言えば問題定義とか問題設定」と小久保は説明します。 小久保は、こうした設定ができた上でちゃんとアクションに結びつけていくことを担ってくれる人をシニアデザイナーと呼びたいという考えを示します。そして、「我々も言語化を頑張るので、シニアデザイナーであれば一緒に言語化を手伝ってほしい」と小久保は笑い、それを受けた岡本は「"エモい"を言語化するところから始めていきたいと思います」と意気込んでいました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/jG_vrkAentc

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メイクショップ株式会社は、2004年からASP型のECシステム「MakeShop by GMO」を提供しています。サービススタートから18年目を迎え、現在法人で10,000社以上に利用されるなど順調に成長を続けていますが、規模が増大することによっていわゆるレガシーシステムとしての課題が浮き彫りになってきました。「サービスとして成功はしているけど、システムとしてはとても厄介な状態」から、GMOメイクショップはどうやって脱しようとしているのか。GMOインターネットグループが12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」で、GMOメイクショップの大森康充氏と森健太氏は、レガシーシステムの課題、レガシーシステムを安全に移行する方法と感想について紹介しました。 登壇者 GMOメイクショップ株式会社 事業推進部 マネージャー　大森 康充（左）森 健太（右） システムのレガシー化が引き起こす3つの課題 MakeShop by GMOの最重要指標であるGMV（流通取引総額）は、リリース以来18年連続で成長してきました。また、ここ数年ではコロナ禍の影響でEC市場が活性化し、流通総額も倍近く増加しています。しかし、こうした成長の裏では、システムの規模が増大することによるさまざまな課題が発生していました。 1つめは、技術的負債の蓄積です。大森氏は「技術的負債とはジェンガのようなもの。開発初期は順調に進められていたが、開発が進むにつれてシステムの要素が影響しあいバランスをとることが難しくなる。単純にエンジニアの数を増やしても開発のスピードが上がらなくなる」と説明します。 2つめは、パフォーマンスの問題です。フロントエンドとバックエンドが分離されていないモノリシックなアプリケーションが構築されていたため、スケールが困難に。また、当初の設計思想と乖離している、開発スピードを重視し継ぎ足しで作られた機能をはじめデータとロジックが増加するなど、パフォーマンスは悪化の一途をたどっていました。 3つめは、エンジニアのモチベーションの低下です。エンジニアは「レガシーなシステムの保守をしたくない」「技術的に新しいことをしたい」「キラキラしたことをやりたい」「勉強した内容を活用したい」などといった思いを持っているため採用が進まず、システム開発に大きな影響を与えていました。 リプレースは「テセウスの船のように」少しずつ移行 開発スピードが悪化するにつれて経営層をはじめ非エンジニアも課題を認識するようになったことで、経営層自らが強い危機感を持って率先してシステム課題の解決に向けて動き始め、リプレースプロジェクトがスタートしました。リプレースプロジェクトでは、「システムを止めないこと」「ショップ様に注文データや商品データ、会員データなどの移行の手間を発生させないこと」という2つの方針が定められました。 リプレースで目指したのは、複雑なシステムをシンプルで新しい技術スタックにすることです。大森氏は「システムは、アプリケーション、インフラ、データベース、ネットワークなどさまざまな要素で構成されており、複雑な形をしている。それをシンプルな形にして、パフォーマンスを上げ、エンジニアが開発しやすいようにしていくことを考えていた」とリプレースプロジェクトの目的について話します。 そうはいっても、システムのリプレースは簡単ではありません。特に一度にすべてを変えようとすると、リプレースの失敗に備えて切り戻しの手順を考えたり、さまざまなバックアップを取得してデータやリソースを移行し大きなテストを行ったりする必要があります。 そこで、GMOメイクショップでは、「テセウスの船のように」というギリシャ神話から着想を得たキャッチコピーを用いて、少しずつ移行する方法を採用することにしました。大森氏は「ただでさえ難易度の高いリプレースなので、少しずつ形を変えてリリースすることでリプレースの難易度を下げようと考えた。細かくリプレースすることでよりよいシステムをつくっていければ」とその狙いを説明します。 テセウスの船とは、物事を構成するパーツがすべて置き換えられても、それは過去のものとまったく同じものであるかどうかという問題を表現したものです。このプロジェクトでは、老朽化した船を補修するため劣化した部品を少しずつ修理・交換していくと、やがて最初に使われていた部品は1つもなくなり、まったく新しい船へと生まれ変わるテセウスの船を理想とし、インフラやアーキテクチャなど、システムを構成するパーツを1つひとつ入れ替えながら、「気がついたらリニューアルされていた状態」を目指しているといいます。 段階的に既存システムへの依存を減らすシステム構成 こうした方向性で、現在では段階的なリリースが進められています。既存システムは下図のような構成になっています。 アプリケーションはPHPで構成されており、数十台のアプリケーションサーバーとデータベースが稼働しています。図は簡略化されており、実際にはさまざまな外部アプリケーションやシステムと関連しています。 新システムの構成は下図のとおりです。 フロントエンドとバックエンドを分離し、フロントエンドには、Vue.jsを採用しています。バックエンドは、BFFとgRPCという2つのコンテナ群に分かれているのが特長です。BFFはフロントエンドからのリクエストをGraphQLで受付け、その裏のマイクロサービス群のgRPCにリクエストを投げます。これにより、フロントエンドからは柔軟なリクエストを受付けることができ、バックエンドは互いに独立して開発できるため、スケールが容易となります。 データベースは既存システムと共有することで、新システムからもデータの定義を変えることなく利用できる形になっています。また、一部APIや画面についてはiframeで呼び出すなど、既存システムで活用できる資源を極力活用し、リリースまでの期間を短くするよう工夫しています。また今回の構成では、GitHub Actionsを利用してビルト、テスト、デプロイなどの操作を自動化し、開発エンジニアがより開発に専念できる形にしています。 さらに、次の段階の構成としては、iframeおよびAPIの呼出を削除して既存システムへの依存関係を少しずつ減らし、最終的には、既存システムへの依存をゼロにすることを目指しています。データベースは既存システムと分割して、新システムで構築することを考えています。これにより、gRPCがそれぞれ独立したデータベースを持つことになります。さらに、互いのシステムが疎結合になるため、独立して開発できる要素が増えていきます。 技術的負債、パフォーマンスの改善を実現 リプレースプロジェクトによって、実際に技術的負債は改善されつつあります。まずは、フロントエンドとバックエンドを分離することによって、エンジニアはより専門性の高い開発ができるようになりました。また、マイクロサービス構成にしたことで、各サービスを独立して開発でき、開発スピードがスケールできるようになりました。そして、定期的にプロジェクトメンバー全員でリファクタリングを議論したことで、コードの均質化・見通しの良さの向上につながりました。 パフォーマンスも改善しています。バックエンドシステムの言語をPHPからGoに変更することで、アプリケーションサーバーのパフォーマンスが改善できています。また、DDD・クリーンアーキテクチャを採用し、複雑なロジックを極力疎結合で書くことで、余分な処理を減らしています。再利用性を高めることで、開発スピードも向上しました。マイクロサービス構成とすることで、負荷が高いサービスへのリソースの割当も可能となりました。 エンジニアのモチベーションはどう変わったか？ 最後に大森氏は、エンジニアのモチベーション低下というレガシーシステムの課題について、リプレースのフロントエンド開発を担当する新卒2年目の森氏と振り返りました。 大森プロジェクトにアサインされたときの気持ちはいかがでしたか。 一番新しい業務、技術に触れるということで、楽しみという気持ちが大きかったです。それと同時に自分にとっては初めての大型のチーム開発でしたので、ベテランのチームメンバーのなかプレッシャーも大きかったです。森 大森良かったと感じる点はありましたか。 入社当初は主に既存システムの保守や調査を行っており実務経験は皆無でした。メンバー内でエンジニアとしての経験値の差がかなりありましたが、技術自体の知識のスタートラインは皆同じだったので、お互いに勉強しながら教えあっていくことでチームとしてより強くなれたと感じています。森 大森逆に悪かったと思う点はありましたか。 エンジニアにとって自由度が高いということが災いして、全体像が見づらくなってしまっていました。それにより、途中で方向性を修正する必要がありました。森 大森どんなことに苦労しましたか。 レガシーで大規模なシステムとなっていたため、既存システムの仕様を細かく調査していくのに苦労しました。大まかな機能はわかっていても、他の機能との細かな連携を1つひとつ調べるのは大変です。森 大森新しいシステムが、現行のシステムのように苦労しないためにはどういうことが必要でしょうか。 シンプルに1つひとつの機能を分離していくという考え方です。また、この開発のなかできちんと記録を残していくということも大切になっていくと思います。森 大森ドキュメントはまだまだできていないので、そこは進めたいですね。また構成も、依存関係を少なくしてシンプルにしていきたいです。これから頑張りたいことには、どんなことがありますか。 ユーザビリティにより注力していきたいです。リプレース版のリリースが近づいていますが、リリース後お客様が使い始めてからは大きな変更は難しくなると思うので、今がよりよくする最後のチャンスだと思っています。既存システムを踏襲するだけでなくより進化させたものになるよう、ユーザビリティを考えた開発をしていきたいです。森 大森リプレースによって実際にモチベーションはあがりましたか？ 上がりました。新しい技術に触れること自体も楽しいですし、どんな技術を使って何をつくるか提案したり議論したりしながら進められるので、エンジニアにとって良い環境で開発ができていると感じています。森 大森フレームワークやライブラリの選定などもチームメンバーで気軽に話し合って決められているので、私も楽しくやらせていただいていると感じます。 大森氏は「変化を楽しもう。あなたは必ず変化する。人は気持ちで変化する。」というGMOインターネットグループスピリットベンチャー宣言のなかの言葉を紹介し、講演を締めくくりました。ソフトウェアの技術は常に変化を続けています。初期の技術選択が正解である保証はありません。GMOメイクショップでは、新しい技術の導入をカジュアルに検討し、変化を楽しんで開発を進めていこうというカルチャーをまさに造成しているところです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/JfBqE9YiNho

GMOペパボ株式会社のデータ基盤チームは、社内外のデータを収集・統合して意味づけを行い、そこで得た情報を社内に循環させるという機能を担っています。GMOペパボは事業部制を採用し複数サービスを運営していますが、同チームは組織横断部門である技術部の1チームとして、他部門と連携しながら事業に貢献しています。GMOインターネットグループが12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」では、GMOペパボのデータ基盤チームの役割やデータ基盤「Bigfoot」のアップデート内容、データ活用を後押しする仕組みづくりについて、同チームの堤利史氏が紹介しました。 登壇者 堤 利史GMOペパボ株式会社技術部データ基盤チーム シニアエンジニア 組織横断的な取り組みを行うデータ基盤チームのミッション データ基盤チームは、データサイエンティスト1名、データアナリスト1名、データエンジニア3名で構成されており、下記のようなミッションを掲げ、データを切り口とした組織横断的な取り組みを行っています。 「ペパボ内のあらゆるデータに意味をつけ、そのデータによって意思決定の支援を行えるプラットフォームを構築し、ペパボの全パートナーに提供する。」 堤氏は、このミッションの言葉を紐解く形で、同チームの取り組みについて紹介していきました。 まずは「ペパボ内のあらゆるデータ」について。収集対象のデータを主に管理しているのは各事業部とCS室であり、データ基盤チームは必要なデータを収集する作業を担当しています。欲しいデータがない場合には、該当部門とともに新たにつくるという流れで作業を進めます。具体的なデータとしては、各事業用のデータベース、アクセスログや行動ログ、広告やSEOの運用に関わるデータなどといった事業データ、問い合わせデータおよび問い合わせ対応の業務記録といったCSデータがあります。これらのデータは社内のデータ基盤「Bigfoot」に集められます。 ＜参考＞・問い合わせ対応の生産性を計測・可視化するhttps://tech.pepabo.com/2022/06/13/customer-service-productivity/ ・ペパボのログ活用基盤『Bigfoot』を使った Zendesk のデータ可視化https://tech.pepabo.com/2021/02/10/zendesk-data-visualization-with-bigfoot/ 続いて「ペパボの全パートナーに提供」について。GMOペパボでは、自らSQLを書いたりダッシュボードをつくったりするパートナーが多いため、基本的にデータの提供はセルフサービス形式となっています。複雑な集計処理が必要な場合など、個別にやるよりも共通化したほうが効率的な場合にはデータ基盤チームが担当します。アクセス権限はTerraformで管理し、GitHub Enterprise Serverに対するプルリクエストでセキュリティ管理者へ申請する形となっており、3か月間利用していない権限があれば自動的に検知・停止されます。 「プラットフォームを構築」という言葉は、Bigfootを表しています。Bigfootは、主にGoogle Cloud Platform(GCP)を用いて構築されています。堤氏によると、GCPで提供されているサービスだけではニーズを叶えられない場合は、自社でOSSを開発して組み込むというスタンスを取っているといいます。 bigfootの概要図 データ基盤「Bigfoot」のアップデート Bigfootについては2021年のGMO Developers Dayでも紹介されています。そこで堤氏は、この1年間でのアップデート内容を中心に説明しました。 ＜参考＞・GMOペパボのサービスと研究開発を支えるデータ基盤の裏側https://www.youtube.com/watch?v=Kxlchi9fa3I データ基盤チームがまず取り組んだのは、データ抽出に特化した基盤「Yeti」の構築です。GMOペパボでは各事業部でRDBMSを運用していますが、データエンジニアリングに関するノウハウの蓄積と共有、マスキングやポリシータグ管理手法の共通化、事業を横断したデータ活用の推進という主に3つの目的に向けて、その共通基盤をつくりデータ抽出に特化した機能を持たせることにしました。 Yetiの概要図 Yetiは基本的にAWSで構築されています。特長は、各事業のデータベースへアクセスする際にパブリックネットワークを一切利用していない点にあります。Yetiについては、2022年4月にZOZOと共催した「Data Engineering Meetup」で詳しく触れられています。 ＜参考＞・データ抽出基盤Yetiをつくっている話https://speakerdeck.com/tosh2230/yeti-yet-another-extract-transfer-infrastructure データ基盤チームは、生産性指標であるFour Keysの計測にも取り組みました。Four keysとは、Googleが考案したソフトウェア開発チームのパフォーマンスを示す下記4つの指標です。 デプロイの頻度（組織による正常な本番環境へのリリースの頻度）変更のリードタイム（commitから本番環境稼働までの所要時間）変更障害率（デプロイが原因となり本番環境で障害が発生する割合）サービス復元時間（組織が本番環境での障害から回復するのに掛かる時間） Four Keysは事業や期間別にダッシュボード上に可視化され、誰でも閲覧できるようになっているといいます。 ＜参考＞・エンジニアの活動情報からFour Keysを集計、可視化した話https://tech.pepabo.com/2022/01/06/four-keys-dashboard/ また、Four Keysの可視化がきっかけとなり、データ基盤チームは汎用Webアプリケーション基盤「Verne」の構築も行いました。Verneは、Cloud Load Balancing、Cloud Run、IAPをつなぎ合わせたものであり、Four KeysダッシュボードはVerneで稼働している形となります。現在では、GoogleアナリティクスのUTMパラメーターが適切に設定できているかチェックできるツールなど、ダッシュボード以外のアプリケーションもVerne上で働いているといいます。 Verneの構成図 機械学習の活用も進んでいます。ハンドメイド通販サービス「minne」では、作品情報がアップロードされた際に、Apache Beamで説明文の形態素解析を行い、Vertex AIでトピックモデリングを行うという取り組みを行っています。こちらも、2022年4月にZOZOと共催した「Data Engineering Meetup」のなかで紹介されました。 ＜参考＞・BigQueryの日本語データをDataflowとVertexAIでトピックモデリングhttps://speakerdeck.com/zaimy/topic-modeling-of-japanese-data-in-bigquery-with-dataflow-and-vertex-ai また、オリジナルグッズの作成・販売サービス「SUZURI」には、バンディットアルゴリズムが実装されています。バンディットアルゴリズムは、静的A/Bテストで発生しうる機会損失を防ぐもので、minneでもすでに導入済みです。堤氏は、「バンディットアルゴリズムを複数の機能に適用していき、サービスを改善していきたい」と話していました。 データ活用を後押しする仕組み データ活用をするうえでは、データ品質が重要となります。データ基盤チームは、データ品質を向上するための取り組みとして3つのアプローチを取っています。 1つめは、データカタログです。GMOペパボでは、tblsというツールを用い、BigQueryにあるテーブル・列のDescriptionをGitHub Enterprise Serverのリポジトリで管理して誰でも更新できるようにしています。各事業部のRDBMSで利用している場合は、データ収集時にカタログも同期するという使い方ができます。 2つめはデータバリデーションです。データバリデーションは、Load/Transformとテーブルの状態確認の2種類です。前者では、Cloud Composer DAGでBigQueryのASSERT文を実行し、実行したジョブによるデータ操作が期待どおりであるかどうかを検査します。後者は、Querygazerをベースに「Shoegazer」というWebアプリを独自で構築。テーブルに格納されたレコード全体をみて、利用者が期待する状態であるかを定期的にRSpecで検査しています。 3つめはデータリネージです。データリネージでは、堤氏が開発した「Stairlight」というツールを使っています。これは、Cloud Composerにデプロイしているソースコード群からSQLを解析してデータのつながりを見つけるというもので、堤氏によるとVerneやRedashに入っているクエリなどにも展開できるといいます。 また、データ基盤チームでは、データ活用を後押しする取り組みとしてSQLパフォーマンス改善サポートも行っています。具体的には、RedashなどのBIツールにおけるSQL実行履歴から所要時間を確認して、より効率的なクエリになるようデータ基盤チームで支援するというものです。Redashであれば、データが格納されているPostgreSQLからクエリ実行履歴をYetiで抽出し、BigQueryにロード。これをVerneでモニタリングしていきます。 他部門とのさらなる連携とMLOps基盤の構築を目指す 講演の最後に、堤氏は「Bigfootが抱えるデータの量・種類が増えていくと、さらなる組織横断的な動きが求められる。連携をより強化するなかで、収集・付与するデータのバリエーションも増やしていきたい」と今後の展望について語りました。さらに、MLOps基盤の構築を進めていく考えについても次のように話していました。 「現在、機械学習を行いたい場合には各事業部で個別に対応しているが、今後はデータ基盤チームが中心となって基盤という形で共通化して使えるようにしていきたい。具体的には、機械学習パイプラインの整備と展開を進める。また、データリネージとモデルモニタリングを統合して、一気通貫で確認できるようにもしていければ」（堤氏） アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/PWvl-UODTC8

GMOインターネットグループが、12月6日（火）～7日（水）の2日間にわたり開催した「GMO Developers Day 2022」。東京・渋谷フクラスにおけるリアル登壇とオンライン配信のセッションを組み合わせたハイブリッドで開催された今回のイベントでは、Web3、AI、セキュリティ、クリエイティブといった「技術の拡張（Add on）」を、スペシャリストたちが紹介しました。今回はその中から、「プライバシー保護連合学習技術と活用方法について」と題したオンラインセッションをお届けします。登場するのはGMOサイバーセキュリティ byイエラエ株式会社から、AI開発部スペシャリストの伊藤一明です。 登壇者 伊藤 一明GMOサイバーセキュリティ by イエラエ株式会社AI開発部 スペシャリスト 連合学習に暗号技術を「Add on」したDeepProtect インターネット技術の中でもサイバーセキュリティなどに関する事業を展開するGMOサイバーセキュリティ byイエラエ。「誰もが犠牲にならない社会を創る～デジタルネイティブの時代を生きるすべての人が安全に暮らせる社会作りに貢献します～」をミッション＆バリューとして掲げています。 現代の課題の1つとして、伊藤は「複数の組織がデータを持ち寄って分析しないと解決できない課題に対して、データを共有したり開示したりできないという二律背反がある」と指摘します。 これを解決するための技術としてイエラエ社が社会実証・ビジネス化を進めているのが、連合学習と呼ばれる機械学習の手法に、暗号化したまま計算できる特性を持つ準同型暗号を「アドオン」したプライバシー保護連合学習技術である「DeepProtect」です。複数の組織が持つデータセットを互いに秘匿し、プライバシーや機密性を保ったまま共同で機械学習を行える、独自のプライバシー保護連合学習技術となります。 では、そのDeepProtectとはどんな技術でしょうか。 鍵となる技術である「連合学習」は、2017年にGoogleが提唱した機械学習モデルの手法です。Googleでは、キーボードアプリである「Gboard」の予測変換の精度向上に活用しています。 この技術は、機械学習に必要な学習用データを、1つの拠点やサーバに集約せずに作成できるという点が最大の特徴です。散在した学習用データを使っても、作成されたモデルは集約した場合と同等の性能があるとされています。 例えばGboardでは、各スマートフォン上で入力されたテキストデータと入力サジェストのクリック状況等から学習データを生成するのですが、キーボードで入力された文字列やクリック状況は機密性の高いデータになります。この学習データから機械学習を実行し更新モデルを作成するのですが、ここまではGboardをインストールしたスマートフォン内で行われ、学習データはローカルにとどまっています。 その後、更新モデルの差分情報のみがクラウドに送信され、他のユーザーの更新モデルと平均化されて、すべてのユーザーで共有する共有モデルを作成、改善されたモデルを再び共有します。これが個々のスマートフォンにダウンロードされて、再びローカルでの改善、更新モデルの作成に活用されます。これが繰り返されることで、キーボード入力の予測精度が向上する、というのがGboardの連合学習です。学習データ自体はスマートフォン内にとどまり、サーバに集約する必要がありません。 Gboardにおける連合学習の概念図。ローカル内で学習、改善、更新モデルの作成というサイクルを回しつつ、差分情報だけをクラウドに集約して、共有するためのモデルを作成、改善していきます。google資料「Federated Learning: Collaborative Machine Learning without Centralized Training Data」より抜粋 このように、学習モデルを作成する際には個人情報を含むデータの送信が行われず、学習によって得られた差分パラメータ（勾配情報）のみを送信することで、個人情報などの機密データを開示することなく学習モデルを構築できるのが連合学習です。 送信されるのは、プライバシーに関わるような個人情報などではなく、学習モデルの差分パラメータ（勾配情報）のみになります これに「アドオン」する準同型暗号は、その名の通り代数学で知られる「準同型（homomorphic）」の性質を持った暗号方式です。暗号化されたデータに対して加算や乗算といった演算を行った場合、復号した結果が、暗号化しない場合と同じデータ演算結果になる暗号方式です。 例えばEnc(m_1)とEnc(m_2)という暗号化されたデータがあった場合、復号をしない状態でEnc(m_1+m_2)、Enc(m_1×m_2)といった計算が可能で、復号した結果は、もともとの暗号化されていないデータの演算結果と同じとなっています。こうした特性から、暗号化した状態で中身を隠したままデータ処理ができるわけです。 連合学習技術と準同型暗号を組み合わせると、学習モデルの勾配情報を暗号化したまま計算して、その結果を集約して更新するため、データの漏えいを防ぐことができます。送信されるのが勾配情報に限られる上にそのデータは暗号化されているので、中身を見ることができないからです。 勾配情報を暗号化したまま計算する準同型暗号。計算式は図のようになります 厳格なセキュリティ、プライバシー保護によって、組織を横断したデータの利活用が妨げられるという課題に対して、プライバシー保護連合学習技術の「DeepProtect」であれば、個人情報などの機密性の高いデータを開示しなくても、組織を横断したデータ利活用が可能になります。 金融機関における不正取引検知で利用に期待 実例を見てみましょう。JST CRESTでの実証実験として、金融機関における不正取引検知でDeepProtectが活用されました。複数の銀行のデータを使って不正検知の学習モデルを作成するには、これまでは各銀行のデータを集約する必要がありました。口座情報や取引履歴などが含まれるため、通常は外部に出せない情報です。 DeepProtectでは、各銀行内で学習したモデルの勾配情報のみを暗号化し、中央サーバへアップロードします。中央サーバでは集約された勾配情報を、準同型暗号によって暗号化されたまま統合し、集約された勾配情報として更新をします。 各銀行では、この更新された学習モデルをダウンロードして、それぞれの学習モデルをまた更新します。このサイクルを繰り返すことで、精度の高い学習モデルが共同で構築できます。1つの銀行のデータだけではなく、複数の銀行のデータによる連合学習モデルを構築することで、より精度の高い不正取引検知ができるというわけです。 DeepProtectの実例として、金融機関の不正取引検知での概念図。それぞれの銀行の学習モデルの差分パラメータのみを暗号化、中央サーバにアップロードし、集約した差分パラメータを使って学習モデルを更新 実データ自体は外部に送信されず、あくまで差分パラメータという勾配情報のみが、しかも暗号化されたまま処理されるため、データの機密性やプライバシーが確保されているというのがメリットです。 実証実験の結果は、各銀行での被害取引の検知率で比較されています。1つの銀行のデータだけを用いた個別学習モデルと、DeepProtectの連合学習モデルを使った検知精度の比較では、検知率が個別の84％に対して85.3％と、1.3ポイントの向上が見られました。個別学習モデルでは検知できなかった不正取引が検知された事例も確認されました。 実証実験での結果。連合学習モデルの方が高い結果を得られました 銀行における不正取引の被害額は、把握されているものだけで約300億円程度とみられており、1ポイントの向上で3億円程度の不正が防げるということになります。表に出ている被害額は氷山の一角とも言われていますので、実際はもっと被害額を減らせる効果があると考えられます。 実証実験で示されたDeepProtectの高いポテンシャル 不正取得された口座が振り込め詐欺などの金融犯罪に使われる、といった加害取引検知の実証実験では、個別学習モデル単独と、個別学習モデルと連合学習モデルを組み合わせたハイブリッドモデルで検証。加害取引が検知されるとその口座を凍結するのですが、その口座凍結が個別学習モデルと比べて20～50週程度、早く検知できていたそうです。検知率も個別学習モデルで78.9％が、ハイブリッドモデルだと94.7％で15.8ポイントの向上。実証実験によって、DeepProtectの高いポテンシャルが証明されました。 加害取引検知の実験では、ハイブリッドモデルで大幅な性能向上が確認されました 金融機関に対する攻撃は複雑化、巧妙化しています。マネーロンダリングや不正送金、振り込め詐欺などが相次ぐ中、単独のデータだけでは不正対策が間に合わなくなっています。複数の金融機関にまたがってデータの解析を行うことで、不正の検知率が向上すれば、犯罪を未然に防ぐ可能性が高まります。 そのほかにも様々な分野での応用が期待されます。例えば医療・ライフサイエンスの分野では、ウェアラブルデバイスの普及で計測できるバイタルデータが急拡大。電子カルテシステムなどの環境整備も進み、大量のデータが収集されています。こうした極めて機密性の高いデータでも、セキュアに複数の機関やデバイスをまたいだ統合分析が可能になり、医療やライフサイエンスの進歩に貢献できる、と伊藤は話します。 マーケティング分野では、単独企業だけでなくグループ企業や業界内を横断した豊富なデータをベースにした学習モデルを構築。詳細なインサイトやターゲットの発見といった精度の高い分析の実現が期待できる、としています。 製造現場でも貢献できそうです。IoTの導入が進んだ製造現場では、AIを使ったデータ分析も始まっています。これによって、設備などの故障予知、部品の品質管理、製品の異常検知などの分野で活用が期待されています。こうした分析には、1社、1工場のデータだけでは不十分なので、複数企業の工場データを活用できるDeepProtectが「課題解決を支援します」と伊藤は言います。 サービスの分野にも応用できます。電力やガスなどの公益サービスでの需給バランスの最適化、自動翻訳、スパムメールの検出、カスタマーサービスのチャットボット、バーチャルアシスタントサービス、自律走行を制御する車両運行システムなど、伊藤は様々なサービスでの利用を例に挙げ、広く活用が期待できるとアピールします。 さいごに もともと今回の技術「DeepProtect」は、発明した情報通信研究機構（NICT）から技術移転された（ニュースリリース：https://www.nict.go.jp/press/2022/03/17-1.html）もので、サイバーセキュリティや暗号技術、機械学習に関して高い技術力を持つことからイエラエ社が移転先として選ばれました。社会実証やビジネス化を進めていますが、伊藤は、幅広い分野の多くの課題を解決できる可能性がある技術として、「今後に是非とも期待して欲しい」と締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=kx7V6_jNU7U

GMOインターネットグループは、事業の成長を加速させるため、マイクロサービス化の道を選択しました。しかし、そこにはさまざまな困難が待ち受けています。 ただ漫然とシステムを切り刻んだだけでは、思い描いた未来にはたどり着けません。GMOインターネットグループ株式会社 成瀬 允宣は、12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催されたテックカンファレンス「GMO Developers Day 2022」のスピーカーセッションで、開発者がその力を最大限発揮できる環境を目指してソフトウェア設計面から取っているアプローチについて紹介しました。 登壇者 成瀬 允宣　 GMOインターネットグループ株式会社テックリード／デベロッパーエバンジェリスト 開発生産性向上を目指し、マイクロサービス化を決断 事業が成長し、システムが肥大化すればするほど開発生産性は落ちていきます。マイクロサービス化を決断した背景には、開発生産性を150%アップしたいという目標がありました。 生産性向上にあたって課題となっていたのは、まず共通データベースの存在です。データベースを複数のサービスで共有していたため、システムの拡大につれて深刻な依存関係が生じていました。また、複雑怪奇なシステムにより一子相伝になりやすいのも課題で、成瀬によると「当時、自分が所属していたチームのバックエンドチームでも、一人前になるまでに3年掛かるという話をしていた」ほどだったといいます。さらに、各システムで機能が重複しているうえに、それぞれに微妙な違いが生まれているような状況で、統制がとれていないという課題もありました。 マイクロサービス化への道筋は、ソフトウェアから「越境」をデザインすること システムアーキテクチャを考えるにあたっては「システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すよう制約される」というコンウェイの法則が知られています。たとえば、アプリ開発チームとインフラチームのあいだに壁があると、チームごとに個別の設計を反映してしまう弊害が出てきやすくなります。マイクロサービス化にあたっては、この法則を逆手に取り、チームと組織構造を進化させて望ましいアーキテクチャへと導く「逆コンウェイの戦略」が有効となります。 ただし、これはあくまで前提であり、チームを単に分割しただけでは、リファクタリングのための作業時間が捻出できない上に、主導者が不在となり調査・改修のためにチーム横断のコミュニケーションが発生するなど、円滑に開発を進めていくことが困難となってしまいます。そこで、こうした課題を運用でカバーするのではなくエンジニアリングで解決するという方針を取ることにしました。 ソフトウェア開発の現場にある不必要な壁を取り払うことでイメージされやすいのがDevOpsではないでしょうか。しかしマイクロサービス化においてDevOpsのように開発と運用チームを安易に越境させてしまうと、共通データベース問題が起きてしまいます。マイクロサービスアーキテクチャを選んでいながらもサービスが密結合している分散モノリス状態となり「モノリスのデメリットとマイクロサービスのデメリットを併せ持つ最悪のパターンになってしまう」（成瀬）ため注意が必要です。 「“水の低きに就く如し”という言葉があるように、人は楽な方に流れてしまうので、安易な越境を防ぐためには、望ましいやり方が最も安易であるようにすることが求められる」と成瀬。講演タイトルにある「越境のデザイン」とは、これをソフトウェアからアプローチしようという発想に基づいているといいます。 サービス/チーム境界を越境するAPI モノリスで構築している段階では共有データベースは有利となりますが、データベースを共有するとデータストアを経由してサービスを超えた依存関係が生まれてしまうため、中長期的には不利になります。この対策として一般的にはAPIの利用が有効とされています。GMOインターネットグループでは、チーム間の連携のほとんどにHTTP APIを利用していました。ただ、チーム内ではさまざまなデータベースを共有している状況にあるため、複雑な依存関係がありました。そこで、HTTPによるコマンド受付を行いメッセージブローカーを使うようにすることで共有データベースを廃止することを目指しました。 メッセージブローカーを利用することのメリットは、耐障害性の高さです。サービス同士をRPCでつないでしまうと、あるサービスが落ちたときにそれを呼び出しているサービスも落ちるという形で、他のサービスにまで影響が及んでしまいます。一方、メッセージブローカーを用いた場合、障害発生時にメッセージブローカーが稼働していれば、そこにメッセージを貯めて復旧した際にメッセージを消費する流れになり、他サービスへの影響を防ぐことができます。 システムにおける過去・現在・未来の時間軸を越境するイベントソーシング 次に問題となるのは、どのようなメッセージを送るかということです。メッセージは、指示を表す「コマンド」と「クエリ」、そこで起きた事象を表す「イベント」の3種に分けられます。そして、イベントを送る際にポイントとなるのが、イベントソーシングです。イベントソーシングとは、データの現在の状態を格納する代わりに、実行されたアクションを記録するというGitのような考え方です。 イベントは、イベントジャーナルに保存され、Relayでメッセージブローカーに渡されます。これが実現できると、開発面で大きなメリットがあります。既存サービスの情報をもとに新しいサービスを作りたい場合、過去のデータであればすべての履歴がイベントジャーナルに保存されているので、既存サービスを修正しなくてもよい可能性が高まります。また、予測不可能な未来への対策を行うこともできるようになります。 組織上のメリットもあります。多数のサービスが使っているサービスの担当チームに修正・機能追加の要望が集まると、チームが疲弊しリードタイムの低下につながるおそれがありますが、メッセージブローカーにイベントが送出されていれば、他のチームが「勝手に使っている」状況が生まれ、他サービスのための作業を減らすことができるようになります。 個人間・チーム間の知識を越境するイベントストーミング メンバーが退職してしまうと、開発力が低下するだけでなく、ドメイン知識などソフトウェア化対象の周辺知識や属人化した知識が継承されないという問題が発生しがちです。こうした知識を共有する方法として、コードのコメントがありますが、システム横断の知識が記述できないほか、記述箇所を探すのが難しかったり、メンテナンスされなかったりという課題があります。ドキュメントを作成する方法もありますが、ビジネス最前線では仕様が変化しやすく、メンテナンスの難しさが難点となります。そこで有効となる手法が、イベントストーミングです。イベントストーミングは、ワークショップ形式のモデリング手法であり、ブレインストーミングのイベント版のようなものといえます。参加者はイベントを思いつく限り付箋へ記入し時系列に並べ、ルールに従って必要な付箋を追加していきます。そして、出揃ったものに対してチームで納得のいく命名をして、コンテキストで分割していきます。コードを用いないため開発職ではない人も参加できることが特徴で、成瀬は「仕様に詳しいビジネス職の人を招いてワークショップを行うと知識がマージされていく」とそのメリットを語ります。イベントストーミングを行うと、個人の知識がチームの知識として昇華されていくため、メンバーの退職に慌てないで済むほか、新しいメンバーも知識をキャッチアップしやすくなります。さらに、サービス同士の連携箇所が可視化されるので、改修時の影響範囲も明確になります。 成瀬は「イベントソーシングとイベントストーミングの相性は最高」だといいます。イベントソーシングを採用していると、イベントストーミングによって作成された図に従ってそのままコードに落とし込むことができるためです。 サービス運営負荷と責任を越境するコンシューマ駆動契約テスト システムは有益であればあるほどさまざまなサービスに使われるため、何か障害が起こった際には各方面から一手に苦情を受けることになります。さらに、こうしてサービスの供給者（プロバイダ）に責任を持たせてしまうと、依存関係の調査・タスクなどに掛かるコストが増大し、リードタイムの低下につながるおそれがあります。 成瀬によると、コンシューマ駆動契約テストでこうした課題を解決できるといいます。コンシューマ駆動契約テストは、「皆が使っているのなら皆でメンテナンスしよう」という考え方に基づき、サービスの利用者（コンシューマ）がプロバイダに向けてテストを提供するという手法です。 役割・チーム間を越境する組織設計 マイクロサービス化に向けたこうした知見があったとしても、実際のところ開発チームは多忙であり、新たなスキルを獲得するような時間がないという樵のジレンマに陥るケースは多くあります。成瀬も「兼務の技術研究チームで試したところ、本業を優先するために進まなかった。チーム対象にワークショップを実施してみたが、これを継続しようとすると自分と同じ役割の人が何人も必要になる」と苦戦したことを明かします。 ここで必要になるのがチームトポロジーという考え方です。チームトポロジーでは、「ストリームアラインドチーム」「イネイブリングチーム」「プラットフォームチーム」「コンプリケイテッドサブシステムチーム」という4つの基本的なタイプにチームを整理します。そのうえで、各チームは「コラボレーション」（チームとチームが密接に協力して作業すること）、「X as a Service」（最小限のコラボレーションで利用または提供すること）、「ファシリテーション」（障害を取り除くために他チームを支援したりされたりすること）という3つのインタラクションモードを活用します。 これを成瀬が以前行っていた業務に照らし合わせると、下記のように分けられるといいます。 サービス開発 → ストリームアラインドチームマイクロサービス化の支援 → イネイブリングチームクラウド等の利用方法策定 → プラットフォームチームチーム横断のモジュール開発やアーキテクチャ策定 → コンプリケイテッドサブシステムチーム こうしてチームの役割を整理し、チーム同士がどのように関わるかを宣言してインタラクションモードを使い分けることによって、チーム間の諍いを減らすことができるようになります。 GMOインターネットグループは、まさにこの取り組みを進めているところです。成瀬は、「マイクロサービス化をさせるにはファシリテーションを行えるメンバーの増強が不可欠。チームトポロジーの考え方で状況を整理してイネイブリングタイプのチーム組成を上申したところ、上長の後押しもあって実現できた。これにより、組織的なマイクロサービスを推進でき、各チーム内にも手練れが増えてきた」と現状について紹介。そして「ソフトウェア設計は人の心の動きを考えることから始まる。“水の低きに就く如し”を念頭に置いて、越境をデザインしていくことが大切。GMOインターネットグループも、まだ道半ばだが上手くいくようになってきている」と語り、講演を締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/dChUhH9MMm0