マネジメント の記事一覧

この記事は GMOインターネットグループ Advent Calendar 2024 18日目の記事です。 1. はじめに GMO ReTechの永橋です。サービスをローンチしてから4年が経ちましたが、4年間のほとんどがオフショア開発とともにありました。記事のタイトルには「支える技術」とありますが、ここでは技術（テクノロジー）面ではなく、オフショア開発におけるチームマネジメントの工夫（スキル）に焦点を当てたいと思います。 2. 開発チームの現状 2.1 チーム体制 現在のチーム体制は以下の通りです。 日本：3名 ・プロダクトマネージャー：1名・プロダクトアーキテクト：1名・デザイナー：1名 オフショア：23名 ・プロジェクトマネージャー：1名・BrSE（ブリッジSE）：3名・フロントエンドエンジニア：7名・バックエンドエンジニア：3名・アプリエンジニア：3名・品質管理：6名 GMO ReTechに所属し、賃貸DXの開発に携わるメンバーは私を含め3名で、開発の多くはGMOインターネットグループのオフショア開発チームの協力のもと行っています。現在はベトナムから23名がプロジェクトに参画しています。つまり、チーム全体では26名で賃貸DXの開発を行っています。 2.2 プロダクトアーキテクトの役割 私の立ち位置はプロダクトアーキテクトで、普段は賃貸DXの設計、開発、運用を担当しているエンジニアです。オフショア開発に関しては、技術的な仕様や課題に関するサポートを行っています。また、プロダクトマネージャーはオフショア開発を管理しており、日本とベトナムのコミュニケーションを円滑にする役割を担っています。 2.3 ブリッジSEの存在 オフショアチームにはブリッジSEというポジションのメンバーがおり、このメンバーが日本語で伝えた要件や仕様をベトナム語に翻訳し、開発工程に落とし込みます。このブリッジSEのメンバーはとても日本語が堪能でスラングもバリバリ使いこなします。非常にありがたい存在で、私たち日本のメンバーは言語の壁を感じることなくコミュニケーションが取れています。 3. オフショア開発で直面した課題と解決のための取り組み ここでは、オフショア開発で直面した課題を大きく3つご紹介します。 3.1 スケジュール管理の難しさ 3.1.1 祝日のズレと稼働日の可視化 まずは祝日による休みのズレです。例えば正月で言うと、ベトナムは旧正月なので、年末年始はベトナムが稼働している代わりに日本がお休み、旧暦1月1日の旧正月はベトナムがお休みで日本が稼働している…というように、休みのズレが生じます。そのため、リリースを終えてから次のリリースまで実質10日程しかない、ということもあります。 スプレッドシートで管理されているWBSに日本とベトナムの休日・祝日も記載し、休みをスケジュールに可視化しました。こちらが実際のスケジュール管理シートです 実際に2024年の1月リリースから2月のリリースまでの間は、フル稼働しているのは10日しかありませんでした…。濃い赤は祝日、薄い赤は祝日に合わせて休暇を取るメンバーが多く、稼働率が低い日であることを表しています。 とても初歩的ですが、WBSを見た瞬間に営業日がどれほどあるかわかるのは、期日を確認するうえでとても重要です。 3.2 UI・UXに対する認識の違い 3.2.1 感性・文化の壁と伝わらない例示 次に、感性や文化の壁です。オフショアチームのブリッジSEメンバーは非常に日本語が堪能なのですが、細かい部分でニュアンスが伝わらないことは避けられません。また、良かれと思って出した例が伝わらないことも多々あります。例えば日本で使われているメッセージングやSNSアプリに実装されている機能を参考に伝えても、ベトナムで使われているとは限りません。ゲームや娯楽も共通のものがなかなか無いため、うまく伝えるためには言葉だけでも画像だけでもなく、動画での動作イメージ共有が非常に大切です。（例えば、ボタンを押したときのアニメーションを◯◯のアプリのようにしたい、とした場合、スクリーンショットだけだと不十分ですよね） ここで重要になるのが「ノンバーバルコミュニケーション」の活用です。言語情報だけでなく、画面共有や動画、アニメーションを用いて非言語的な情報を伝えることで、細かいニュアンスまで共有しやすくなります。 3.2.2 具体的な要件伝達の重要性 コーディングやデザインについても同じことが言えます。具体的にどこまで伝えるかは難易度や規模によって変わりますが、・テーブル構成・ビジネスロジック・利用するメソッドやライブラリの選定・画面イメージはできる限り具体的に伝えたほうが、結果的に相違を抑えて進められます。 3.2.3 コミュニケーション頻度・密度の向上 これらの認識の違いの差は、コミュニケーションの頻度と密度を高めることで埋めることにしました。まず、毎日ブリッジSEのメンバーとZoomでの朝会を実施し、疑問や課題の共有の場を作ることで迅速に問題を察知できるようにしました。 Zoomで定例を実施するにあたって注意すべきは会議時間です。最近までは1時間実施していましたが、時間オーバーしてしまうことが多いので30分に減らし、会議時間を意識するようにしました。結果として、議題が選別されたり会話の応答速度が上がり、8割以上時間内に終わるようになりました。また、Zoomによる朝会を実施することにより、テキストによるコミュニケーションでは伝わりにくい事柄は画面共有を交えて伝わるようになり、細かいニュアンスが伝わりやすくなりました。不具合が生じた際は、朝会とは別にすぐにZoomで会話をします。ときにはオフショアのエンジニアもZoomに参加することで、リアルタイムに通訳してもらいながら解決を図ります。 デザイナーはFigmaを利用することで画面イメージを明確に伝えています。 スケジュールの都合上デザイン無しで開発を依頼することもありますが、やはりアウトプットに明確な違いが出ます。細かく伝えることはオフショアに限らず手戻りを増やさないために重要です。さらに言えば伝えるための手法も工夫しないと結局意図していたものと違う成果物があがってくる、ということです。 3.3 コード品質の担保 3.3.1 言語の壁とレビューラグ 成果物を確認する際はもちろんコードレビューを行いますが、言語による壁が発生します。日本語でレビューコメントを書き込んだ場合、それをブリッジSEのメンバーが翻訳したうえでオフショアのエンジニアに伝えるわけなので、当然伝達までにラグが発生します。また、ブリッジSEを介することで、エンジニア間では伝わる会話が正しく伝わらないことも多々あります。 3.3.2 AIコードレビューの活用 解決方法として、CodeRabbitというAIコードレビューツールを使用しています。 https://www.coderabbit.ai 製品仕様に関わるロジックの齟齬などはなかなか検出できませんが、細かいtypoやコードの改善提案などは十分に機能します。ベトナム語を指定することでコメントを直接ベトナム語にしたり、中間言語として英語を利用することも可能です。 4. その他ツールを利用した取り組み 4.1 CircleCIによる自動化 前述のZoom、スプレッドシート、CodeRabbitといったツールのほか、CircleCIを利用しています。 CircleCIでは通常のテストに加え、アプリのビルドを自動化しています。TestFlightやFirebase App Distributionへ自動で展開するため、開発内のテストやリリース前テストにおいてスムーズなテストを実現しています。 4.2 タスク管理ツールの試行錯誤 また、過去にはタスク管理としてTrelloを利用してKPT管理を行っていましたが、これについては失敗でした。Zoomでカンバンの整理をしながら話していると会議の時間が2時間と長時間になってしまったのが原因です。自前でスプレッドシートにまとめて簡易的に課題管理することで落ち着きました。 5. コード品質と設計思想 5.1 製品仕様に関わる指摘の難しさ コード品質の担保にAIコードレビューを使用していることは書きましたが、これでは製品仕様に関わる指摘はできません。そのため、別の方法で担保する必要があります。 5.2 設計段階での詳細化の重要性 オフショア開発に限らず、外部に開発を依頼する場合はどの程度自社で設計を行うかによって、最終的なアウトプットの品質が大きく変わってきます。つまり、機能の設計を細かくやればやるほど、成果物が想定したものから乖離することを抑えられるということです。 前述しましたが、オフショア開発の場合感性や文化の違いもあります。「こんな機能を作りたいんだ、よろしく」と丸投げすると、私たちの想像した機能とは似ても似つかないものが出来上がるのです。絶対にイメージしたものは出来上がらない、と断言できます。 5.3 将来連携や拡張性を考慮した設計 例えば機能Aに対して、将来的に機能Bと連携できるようにしたいと考えていたとしても、将来の連携を見越してを機能設計に正しく落とし込めなければ負債となり、機能Bとの連携を実装する際には大改修が必要になります。まさに、オフショアチームに設計の多くを丸投げしていた状況が2年ほど前の賃貸DXであり、現在は機能アップデートのたびに既存機能の設計変更を余儀なくされています。 現在では新規機能などテーブル変更や大きな仕様変更を伴う改修には、プロダクトアーキテクトを交えて日本側の設計思想を細かく伝えるようにしました。特に意識しなければならないのはパフォーマンスに対する考慮と機能に対する将来予測です。100レコード程度なら軽快に動く機能も、設計が悪ければ100万件、1億件のデータが入ったら目も当てられません。 また、将来的に機能をどのように発展させていきたいか、という展望はオフショア開発チームは持っておらず、あくまでも依頼されたものを作っています。将来的なことも踏まえた設計というのは自社で設計するからこそできることなので、その点も盛り込んで設計する必要があります。 簡単にまとめると、外出しするべきは「開発」であって、サービスの形を担う「設計」は自社で全て行うべき、ということです。当社のように自社のエンジニアが少ないとどうしてもオフショアチームに頼ってしまいがちですが、良いものを作るためには自社での設計を死守しなければなりません。開発を外部に委託する場合であっても、フレームワークの選定や既存機能の仕様、テーブル設計など、サービス全体を把握している人間が成果物を監督できれば品質が格段に向上します。 6. チームと個人のマインドセット 6.1 チームとしての優先順位 設計の重要性について書きましたが、チームとしては「期限＞品質」が重視されています。品質は後から改善できますが、期限は戻ってきません。まずは完成させ、機能を確実にお客様に提供することを第一に開発をしています。もちろん品質は重要ですが、いつまでに提供すると言った期限は必ず守るように動いています。 6.2 個人レベルでのスケジュール管理工夫 また、個人としては、 ・オフショアチームに伝える期限を実際の期限よりも短く設定し、・重要なタスクを優先的に渡し、・作業量が多くなりそうな場合は、タスクを細分化して調整する を徹底することで、スケジュール管理にある程度の柔軟性を持たせることができます。 7. 課題と今後の展望 7.1 感性・文化の違いとコミュニケーション課題の現状 オフショア開発においては、大きく感性や文化の違いによる課題と依頼・被依頼の立場による設計の課題があります感性や文化の違いはコミュニケーション頻度やツールの工夫によりそれほど意識することなく進めることができるようになっています。 7.2 設計上の課題と依存度低減への展望 設計に関してはサービスに精通しているプロダクトアーキテクトを交えることで、以前よりも細かく開発のハンドリングを行うことができるようになっています。 日本チームは現在少人数で開発にあたっており、スケジュール管理や設計は様々な工夫をすることで成り立っています。しかし、まだまだ改善しなければならないことは山ほどあり、理想を言えば細かい改修についてもすべて日本チームで設計を行った上で開発を依頼するのが望ましいです。しかし、程度はどうあれ、まだまだオフショアチームへの依存度が高いというのが実情です。今後更に品質の高いサービスにしていくことを目指し、この依存度を下げていくよう更に工夫をしていきたいと思います。

本記事が対象としているのは、これからエンジニアになろうとしている方、エンジニア経験の浅い方、エンジニアとしてキャリアパスに悩んでいる方です。主に若手のエンジニアを想定しています。「プログラミングが好きだけど、仕事にしたらどうなるのだろう？」「エンジニアになったけど、キャリアパスってどう考えればいいの？」「自分の評価は正しいのだろうか……モヤモヤする」そんな疑問や不安に、趣味プログラマー45年、職業エンジニア30年、マネジメント歴20年、採用・教育歴10年以上の私の考えをお伝えします。 職業エンジニアの「役割」と「当面の目標」を知るメソッド エンジニアの領域 結論、「技術力」と「ビジネス力」の2軸で自分の立ち位置をマッピングし、そこから自分の「役割」「当面の目標」を判断しましょう。 使うのは、以下の図です。 スタート地点は人によって異なりますが、目指すのは右上の領域「花形エンジニア」です。 それぞれの軸の判断基準を説明していきます。 「どっかで見たことある」と思った方……そうです。プロダクトポートフォリオマネジメント（PPM）のエンジニア版です。PPMについては以下の記事で詳しく解説されているので、ぜひご一読ください。プロダクトポートフォリオマネジメントとは？メリットや企業の分析事例を解説 - GMOリサーチ&AIhttps://gmo-research.ai/research-column/product-portfolio-management 技術力（縦軸） プログラミングやサーバー構築など、純粋にエンジニアスキルのことです。それが仕事になっているかどうか、社会に貢献しているかどうかは関係ありません。シンプルに技術力で判断してください。 レベル判断基準一人前一人でWebサービスやアプリケーションを開発・提供できるレベルです。オープンソースへのコミットや、ちょっとしたライブラリを公開するレベルもここに含まれます。一人前～ハイレベルOSやプログラミング言語そのものを一人で開発できるようなレベルです。 「サービスやアプリは当たり前のようにつくることができる」「それ以外にも自分は○○のようなすごいことができる」 そう言える方は、このレベルに属していると思います。 ビジネス力（横軸） 「ビジネス力」と一言でくくりましたが、いろいろなスキルが含まれます。会計の知識・商品企画力・コミュニケーション力・マネジメント力などなど……「サービスを考えて」「実現し」「社会と会社に貢献する」ために必要な、技術力「以外」のスキルすべてと思ってください。 レベル判断基準一人前ビジネスの仕組みを理解しているレベルです。 社会がどうやって回っており、どうやって会社にお金が入ってきていて、それがどうやって自分の給料になっているのか、その仕組みを理解しているレベルです。会社の組織と役割についても理解できている状態かと思います。一人前～ハイレベル自らビジネスの拡大もしくは拡大の提案ができるレベルです。 そのためにはマネジメントや課題解決・企画提案など、様々なスキルが必要になってくるでしょう。   自分の属する領域を把握する この2軸にそってマッピングした場合、皆さんはどの領域のどの辺りにいるでしょうか？ 新卒・若手エンジニアの多くの方は、以下の辺りにいるのではないかと思います。 ご自身がどこにいるかで、会社や社会に対する「役割」、花形エンジニアになるための「当面の目標」が異なります。いずれにせよ、「花形エンジニア」以外の方は「花形エンジニア」になることが当面のゴールとなります。 領域ごとの「役割」と「当面の目標」 見習いエンジニア 技術力もビジネス力も、一人前以下の状態です。この領域にいる人は、だいたい「まだ一人前じゃない」という自覚があります。 あなたの役割は、先輩やリーダーからの指示に対して100%以上の成果を返すことです。仕事を進めながら、ビジネスの仕組みを勉強、未知の技術スキル習得を進め、いずれかの軸で一人前を目指してください。 「知らない」「やったことがない」仕事があればラッキーです。先輩やリーダーを質問攻めにしながら、どんどん取り組んでいきましょう。 「成長を感じない」のは危険信号です。すぐに先輩・リーダーに相談してください。 ギークエンジニア 技術力はあるけれど、ビジネス力が足りていない状態です。趣味プログラマーの人は、ここからスタートもしくはあっという間にこの領域に達することが多いです。 役割は、手持ちの技術力で会社に貢献することです。先輩やリーダーからの指示に対して100%以上の成果を返してください。もし自分より技術力が低い先輩やリーダー・仲間がいたら、彼らの技術面をサポートしてください。 技術力で会社に貢献しながら、ビジネスの仕組みを理解していくことが「当面の目標」です。ビジネス力が成長していけば、自然と先輩やリーダーから仕事を任せられるようになってくると思います。 社会人エンジニア 「見習い」状態から、ビジネス力が先に一人前になった方です。もしくは、すでに社会人として活動されている方が、エンジニアに転職されたパターンです。 あなたの役割は、「ビジネスがわかる」点を活かして、「要件の伝わりやすいエンジニア」（＝要件を伝えるのに手間がかからないエンジニア）として活動することです。チーム内に要件を理解していない人がいればサポートする、要件が曖昧だったら「こうですよね？」と確認する。 ビジネスを企画する人から出てくる要件は、エンジニアから見たら曖昧・矛盾していることがしばしばあります。そんなときに企画者を質問攻めにするのではなく、「こういうことですよね？」と企画者とエンジニアの隙間を埋めるようにしましょう。徐々に企画者やチームの仲間から信頼を得られるでしょう。 技術力が見習いレベルであることを忘れないようにしてください。花形エンジニアになるためには技術力は欠かせません。技術力の向上にも積極的に取り組んでください。 花形エンジニア 当面のゴールです。この領域まで来て、エンジニアとして初めて「一人前」と呼べると思っています。経験では、エンジニア歴5～10年ぐらいでこの領域に達する人が多いようです。 役割は、自身の「技術力」と「ビジネス力」で会社に貢献することです。指示待ちはダメです。自ら提案することで、組織に貢献しましょう。他の領域にいる人たちのサポートも、あなたの役割です。 花形エンジニアになってから先が、本当のキャリアパスなのですが、それはまた別の記事で語らせてください。以下の図のように「花形エンジニア」になってからのほうが、ずっとずっと広い世界です。 「半人前」に要注意 半人前とは？ 私の経験から、最も注意しなければならないのが「半人前」の方々です。ここをうまく導けるかどうかで、その人が花形エンジニアになるか、脱落（退職）していくかが決まります。 「半人前」とはギークエンジニア・社会人エンジニアの領域に属する方です。技術力とビジネス力、いずれかの軸が一人前ですが、もう一方の軸が見習いレベルです。 ひとつの軸が一人前なので、ご自身を一人前と勘違いする危険があります。例えば、以下のような疑問を抱いたことはないでしょうか？ 「自分は○○さんと同じスキルがあるのに、何で○○さんがリーダーなのか」「自分はこのサービスについてよく理解している。なのに何でリーダーをやらせてもらえないのか」 それは、ひとつの軸で他者と比較しているからです。「エンジニア」という仕事には、技術力とビジネス力、いずれも欠かせません。リーダーを、ふたつの軸で眺めてみてください。おそらく、いずれも一人前以上ではないかと思います。 ひとつの軸のみで他者と比較し、そこに疑問を持ち続けると、いずれは「自分は評価されていない」という不満になってしまいます。 他者と自分を比較する際は、必ず「技術力」「ビジネス力」のふたつの軸で比較するようにしてください。 ギークエンジニアが注意すること 「自分は技術力で勝負する（だからビジネス力はいらない）」という考えはとても危険です。 ビジネスの仕組みがわかっていない状態で「技術力」にこだわると、組織から浮いた存在になりがちです。「仲間にわからないコードを書く」「運営を意識しない実装をする」「つくるものの優先順位がおかしい」「職場環境への要求が多い」……仲間から「あの人、実力はあるけどチーム適応力がなくて困る」と思われてしまいます。結果、組織は扱いに困り、あなたも評価に不満を持つという、悪い状態になります。 「技術力で勝負する」という目標を実現するためには、ビジネス力を一人前にする必要があります。 社会人エンジニアが注意すること ビジネスがわかるからこそ、「○○のサービスを担当したい」「こうすればもっとよくなる」と思うことが多いでしょう。「エンジニアだからできる」とも思うでしょう。上流工程にシフトしたがる方もいらっしゃるのではないでしょうか？ でも、落ち着いてください。あなたにはまだ技術力が足りません。あなたはあくまでも「エンジニア」です。いま上流工程に注力してしまうと、「技術のわかる企画者」になるチャンスを失うことになります。 「技術のわかる企画者」になるためには、技術力を一人前にする必要があります。 規格外の人に「なろうとする」のはやめよう 規格外の人とは 何事にも例外があるように、このメソッドにも例外があります。いるんです。とんでもない人が。表現すると以下の通り。図の遙か外にいるような人です。 ウィザード 魔法みたいな技術力を持った人です。Excelマクロと同じレベルのマクロ言語を、スクラッチから3日でつくっちゃうとか、分散型ファイルストレージが一週間でできちゃうとか……そんな人です。2千人以上のエンジニアと仕事をしてきましたが、2名ほど出会ったことがあります。 CTO 新卒で入社した瞬間からCTOみたいな人です。決して技術力は高くないのだけれど、人を巻き込んで、一年目からプロジェクトリーダーをやったりします。なぜか経営陣まで巻き込んでいたりします。たいていの人は、2年目には独立して起業します。こちらも、過去に2名ほど出会ったことがあります。 目標にするのは危険 いずれも0.1%レベルのレアキャラクターです。有名になりがちなので、「目標にしよう」「あんな人になりたい」と思ってしまうかもしれません。 やめておきましょう。 おそらく彼らは、何らかの天賦の才を持って生まれています。「なろう」と思ってなることができるレベルではありません。「目標にしない」「なろうとしない」のが賢明です。 まとめ 職業エンジニアには「技術力」と「ビジネス力」が必要技術力とビジネス力で自分の立ち位置を把握しよう。立ち位置によって「役割」「当面の目標」は異なる。どんな人も、技術力とビジネス力の一人前以上（花形エンジニア）を目指そう。キャリアパスは、花形エンジニアになってから考えよう。

SREにおけるポストモーテムとは 近年、システムの複雑化と規模拡大に伴い、システム障害やインシデントの発生リスクが高まっています。こうした問題を未然に防ぎ、システムの信頼性を向上させるために、SRE（Site Reliability Engineering）では、ポストモーテムと呼ばれる取り組みが重要視されています。ポストモーテムとは、システム障害やインシデントが発生した後に、その原因を徹底的に調査し、再発防止策を立案することで、システムの信頼性を向上させるための活動です。失敗を非難するのではなく、失敗から学び、組織全体の学習と成長を促進することを目的としています。 リリース管理でポストモーテムを行う理由 ポストモーテムは、サービスインパクトのあったシステム障害について実施することが一般的です。私たちはこれに加えて、リリース時に発生した問題についてもポストモーテムを行うことにしました。その理由は以下のとおりです。 1. 問題の特定と可視化 リリースに起因したシステム障害が僅かながら発生していたことから、その裏側にはシステム障害に至らない小さなヒヤリハットが潜んでいるのではないかという推測がありました。見過ごされていた問題点や潜在的なリスクを明確化することで、リリースプロセスの各段階で発生する可能性のある問題を事前に特定し、対策を講じることができます。 2. 継続的な改善 ポストモーテムの結果をもとに、継続的にプロセスや手順を見直し、改善策を実施することでリリース品質が向上します。また、リリース失敗を減らすことで、再リリースに伴うリリース担当者の負荷軽減と作業効率化を図ることができます。 3. 組織全体の学習 失敗から得た教訓を共有することで、失敗から学ぶ文化を醸成し、組織全体の学習と成長を促進します。これにより、同じミスの繰り返しを防ぎ、組織全体の知識とスキルを向上させることができます。 どのようにリリース管理のポストモーテムを実施しているか 具体的には、リリース時に発生した問題を「一部未完了」「切り戻し」「障害発生」に分類し、「一部未完了」「切り戻し」についてポストモーテムを実施しています。 一部未完了: 予定していたリリースの一部が未完了。切り戻し: リリースを中断して切り戻した。障害発生: リリースでシステム障害が発生した。障害管理で対策する 参加者の負荷という点でポストモーテムの範囲や規模は悩ましい点ではありますが、サービスインパクトは無い前提のため、障害管理と比較してコンパクトな体制としています。リリースを担当したチーム、SREチーム、有識者で「なぜなぜ分析」を行い、真因分析と再発防止策を検討します。ポストモーテムの結果については運用定例会議で報告を行い、対策妥当性についてチェックを受けます。報告書は社内ポータルに保管していつでも参照できる形にしています。 リリースポストモーテムの一例（架空の事例です） まとめ リリース管理にポストモーテムを導入することで、これまで顕在化していなかった以下のような問題点を可視化することができました。 構築時期が古い一部のサービスにおけるドキュメントや構成管理の不備本番環境と検証環境に差異が生じているケース リソース配分やスケジュール管理に問題のあるリリース計画 問題の解消には中長期的な対策が必要な事が多く、現時点ではリリース問題発生率の減少には至っていません。今後もポストモーテムを継続することで、持続的な改善プロセスを根付かせ、リリース品質の向上を目指していきます。

こんにちは。GMOインターネットグループ株式会社の矢野です。今年度からチームマネージャーとなり、「チームの存在意義」について改めて考えることがあったのでアウトプットとしてこの場をお借りします。 1. マネージャーを半年間やってみて はじめまして。運用監視・OPEチームの矢野です。 2023年4月にチームマネージャーとなって約半年が経ちました。次々に襲い掛かってくる課題に悪戦苦闘の日々は続いておりますが、少しづつ発見なんかもありやりがいを感じております。 DALL・E作「次々に襲い掛かってくる課題に悪戦苦闘の日々は続いておりますが、少しづつ発見なんかもありやりがいを感じております。」 これまで当たり前に行っていたことも、マネージャーとしての視点で捉えたときに「何でこれやってるんだっけ」「もっとこうした方がよくないか」といったものもちらほらあり今回はその中の1つ、「チームの存在意義」について綴らせてください。 「チームの存在意義」について考えるようになったきっかけは2つあります。 学生向けの採用イベントに携わる中で、より高い解像度のチーム説明が必要だと感じたことチームの指針を考える上で、立ち返るべき場所を明確にする必要があると感じたこと の2つです。 2. オペレーションエンジニアとは 運用監視・OPEチームは監視チームとOPEチームが1つになっている状態でして内部的にはOPEチーム部分を私がマネジメントしています。 このOPEチームというものですが、世間一般的には「オペレーションエンジニア」というものに属すると捉えています。では一体どのような業務を？というところはChatGPT君に聞いてみましょう。 おおむね認識は合っています。さすがっ! 「1. システムの監視と維持」のところは、弊社の場合監視チームや保守チームが主に担っています。 ただしオペレーションエンジニアという言葉だけでは、OPEチームがどのような業務を行っているかを想像するのがなかなか難しいです。 採用活動の中でも直面することが増えており、これをきっかけにチームについて改めて考えることが増えました。 ピンとこないよね(^^; 3. 業務を通して何に貢献するのか 基本の基ではありますが、チームの業務やミッションについて一から考えるようになりました。 チームに与えられているミッションは何なのか業務を通してチームが何に貢献するのか 上記を言語化していくことで、定常化していた業務にやりがいや変化の余地がまだまだ埋まっていることに気付き始めています。 目的に対して余分な工程がないか他チームと協力することで解決しないかツールを導入することで効率化できないかフローを再編することで品質改善できないか 何より昨今のAI発展によって今まで難しかったことが容易に出来るようになりました。新たな手段が生まれたことで、よりチームの存在意義に対して立ち返る価値を感じています。 マネージャーとしてチームメンバーへチームの存在意義、そして目指すビジョンを常日頃から伝え続ける必要がありその上で一緒にステップを上がっていけるようになることが今の私の課題です。 4. まとめ 今回はチームの存在意義に立ち返った経験について記させていただきました。 チームの存在意義に立ち返った結果か、採用活動においてOPEチームに興味を抱いてくれる方が増えてきており最近のうれしいトピックとなっています。 マネジメント業務に携わる人に限らず、今の業務にやりがいを感じられない方や業務に対して受け身になっているなと感じる方はぜひ立ち返ってみることをおすすめします。私自身もこの記事を残すことによって、ふとした時に立ち戻るきっかけにしたいです。 実際のOPEチーム業務やミッションについて、ここでは割愛させていただきましたがもし興味が湧いた方はインターンなども実施しておりますので、ぜひご参加ください。

こんにちは。儀部です。弊社はグループ会社であるGMO-Z.com RUNSYSTEM(ベトナム)と協業でスクラム開発を取り入れており、その中で私はスクラムマスターを担当しております。本記事では私たちスクラムチームのふりかえりを紹介いたします。 ふりかえり（スプリントレトロスペクティブ）とは スクラム開発のイベントの1つで、スプリントの最後にスクラムチームが行うふりかえり会です。スプリント中に起こったことを振り返ることで、改善点を見つけるためのフィードバックの場として機能します。 ふりかえりの目的 チームメンバーからフィードバックを得て、スプリント中にうまくいったことや、問題が発生した原因を特定すること。問題を解決するために、改善策を話し合うこと。 実施方法 私たちのスクラムチームは渋谷、北九州、ベトナムの3拠点にメンバーがいるため、Zoomを利用し、オンラインホワイトボードツール（MiroやMicrosoft Whiteboardなど）を使用しています。KPTなどの手法に沿って、メンバーそれぞれが意見を付箋に記載します。 ふりかえりで試した手法 私たちのスクラムチームで試した手法として下記の5つを紹介いたします。 KPT 意見を出す手法として、Keep(続けること)、Problem(問題・課題)、Try(試したいこと)の3つの質問に回答する手法です。 KPT シンプルかつポピュラーなので取り組みやすいです。継続的に実施していると、Problem(問題・課題)の意見がだんだんと出なくなることがあります。Keep→Try(強化)よりもProblem→Try(改善)に向かうことがあります。 Continue、Stop、Invent、Act 意見を出す手法として、Continue(続けたいこと)、Stop(やめたいこと)、Invent(提案)、Act(行動)の4つの質問に回答する手法です。 Continue、Stop、Invent、Act KPTと類似しているため、KPTから始めて手法を変更する際に取り入れやすいです。Invent(提案)から改善につながる意見が出やすいです。Stop(やめたいこと)の意見が出にくいことがあります。 Fun Done Learn 意見を出す手法として、楽しかったこと（Fun）、完了したこと（Done）、学んだことや気づいたこと（Learn）の3つの質問に回答する手法です。 Fun Done Learn 楽しく振り返りができます。ポジティブな内容のため、全体的に意見が出やすいです。次のアクションにつなげるのが難しいという課題があります。 Good & New 意見を出す手法として、良かったこと（Good）、新しい発見（New）の2つの質問に回答する手法です。 Good & New 短時間で実施できます。ポジティブな内容であるためアイスブレイクに適しています。単独では継続的に実施するには物足りない場合があります。 YWT 意見を出す手法として、やったこと（Y）、わかったこと（W）、次にやること（T）の3つの質問に回答する手法です。 YWT 実際の出来事を起点に考えるため、意見が出しやすいです。「わかったこと」の共有を通じて、チーム内にノウハウが蓄積しやすいです。 ふりかえりで得た気付き 質問が抽象的で意見が出しづらい 例えば、今回やったことの中で、「新しく取り組んだこと」や「工夫したこと」といった特定の項目に絞ってから意見を出すようにしました。 同じ手法ばかりでマンネリ化することがあった 慣れてきたタイミングで、別の手法に切り替えるようにしました。 静寂に包まれていると意見が出づらい 参加者に付箋を記載する間、BGMを流し、明るい雰囲気をつくるようにしました。 まとめ 以上、私たちのスクラムチームのふりかえりについて紹介させて頂きました。ふりかえりの手法について、最初に取り組むなら、ポピュラーな手法で経験者も多いためKPTがオススメだと思いました。また、角度を変えたい場合は感情という観点でふりかえれるためFun Don Learnが新鮮で良かったです。どの手法も一長一短ありますので、メリット・デメリットを踏まえ、現状のチームに最適なものは何かを考えて都度採用していくのが良いと思います。アクションアイテムの評価など、ふりかえり自体に課題は残っていますが、より効果的に実施していくために、チームで改善を進めていく予定です。

こんにちは。デベロッパーリレーションズチームの村上です。今回はエンジニアがマネジメント業務を行うことについて書いていきたいと思います。私もマネージャーとして、サービスのプロジェクトのマネジメントやチームのマネジメントを行っているので、実体験を踏まえて書いていければと思います。 はじめに マネジメントというのは色々一括りにしたものであって、その分野はいくつか分かれてます。よく聞くのがプロジェクトマネジメントなんじゃないかなと思いますが、それ以外にもエンジニアに求められるマネジメント業務は他にもあります。 今回はエンジニアに求められるマネジメントに関して解説していきます。 チームマネジメント 会社で開発を行う際は基本的に複数人でチームを構成して行います。チームマネジメントとはチームに所属するメンバーのタスク状況やコンディション、モチベーションを管理しチームの開発生産性を向上させるためのマネジメントのことです。 エンジニアとして経験や年数を増えてくると、気がついたら部下や新卒メンバーが増えてきます。チームを率いていく立場として全員をまとめ上げ、自分の成果のみでなく一緒にチームの成果を上げることが求められると思います。この際に必要なのがチームマネジメントになります。 チームマネジメントの難しいところが、自分の仕事だけやって成果を上げれば良いというわけじゃありません。コミュニケーションに関しても、業務に関する部分だけ最低限取れていれば大丈夫という考えではうまくいきません。チームメンバーと信頼関係を築き、チームとして成果を上げたり、開発効率を最大化していくには以下のポイントに気をつけましょう。 メンバーとのコミュニケーション 心理的安全性を高める為の自己開示メンバーのことをよく知る（1on1や面談を行う） 目標やモチベーション 目標に向かって走る為の脳内同期と情報共有メンバーが成長を実感できるような目標設定メンバーの成果に対して適切な評価を行う プロジェクトマネジメント マネジメントと言われるとプロジェクトマネジメントが頭に浮かぶ人が多いと思います。 例えばサービスに新しい機能を追加する、大きな仕様変更で既存の機能を大幅に改修する等々の開発案件が発生したときに、リリースのスケジュールを計画したり、メンバーアサイン・タスクの進捗管理を行い、プロジェクトを成功に導くためのマネジメントがプロジェクトマネジメントになります。 また要件定義から詳細仕様を作成したり、細かなタスク作成をするのもプロジェクトマネジメントの仕事になることが多いです。プロジェクトマネジメントもチームマネジメントと同様、プロジェクトのメンバーと情報共有を行い、コミュニケーションを取ることが重要です。プロジェクトを成功させるために必要なことがなんなのか、スケジュールの調整やタスクの優先度をしっかりと考えてマネジメントしていきましょう。 実際の現場 GMOインターネットグループではエンジニアに個別のミッションが設定されており、私はマネージャーとしてのミッションを設定されています。マネージャーのミッションを設定されたエンジニアは、主にチームマネジメントを中心にマネジメント業務を行っていきます。プロジェクトマネジメントはまた別にミッションが設定されたエンジニアが行うことになるのですが、そこに該当するエンジニアがまだいなかったり育ってなかったりすると、プロジェクトマネジメントも兼任して行います。 私のチームは東京・福岡の2拠点に在籍しており、新卒2年～4年目のメンバーで構成されている為、一部のプロジェクトマネジメントにも携わってます。徐々にプロジェクトマネジメントをチームの他のメンバーに渡していき、チームマネジメントとプロジェクトマネジメントを分離していきます。やはり可能であれば一つに集中してマネジメントを行うほうが成果も上げやすいですし、マネジメントの負担も軽減されます。ここの分担ができていないのが、一般的に「マネジメント業務が嫌だ」と言われる原因の一つになってるのかなと考えてます。 まとめ マネジメント業務にも色々あって、特にプロジェクトマネジメントは自身も開発しながらプロジェクトの全体を管理するという面では割りと嫌がられることもあるかなと思います。 ただ、どのマネジメント業務であってもチーム一丸となって目標を達成する、という経験は非常に貴重なものとなります。エンジニアとしてのキャリアも最近は多岐に渡ってきているので、将来の選択肢を増やすといった面でも挑戦してみるのはどうでしょうか。チームやプロジェクトにもよる部分は大きいですが、マネジメントはメンバーに支えられて成立する部分も大きいので、非常にやりがいのある業務です。これを読んで今マネジメント業務をお願いされて悩んでる人に助けになれば幸いです。

弊社のグループ会社であるGMO-Z.com RUNSYSTEM(ベトナム)と協業で開発を進める上でスクラム開発を取り入れており、その中で私はスクラムマスターを担当しております。本記事ではスクラムでのメリットや今後の改善点などを紹介いたします。 スクラム開発の導入 生産性の向上を目指してスクラム開発が導入されました。 他にも事業部門との連携強化などの効果も見込んで取り組んでおります。 スクラムチームの体制 チーム構成は下記の通りで所属はバラバラですが、スクラムチームとして活動しております。ステークホルダーは弊社事業部門のマネージャーの方にご担当頂いております。 プロダクトオーナー：弊社事業部門のメンバー開発チーム　　　　：GMO-Z.com RUNSYSTEMのメンバースクラムマスター　：弊社システム部門のメンバー スクラムの実際の運用 前提 タスク管理ツールはJiraを使用してタスクをチケットとして管理しております。スプリントの期間は2週間で実施しております。開発チーム6名のうち日本語でコミュニケーションを取れるのはブリッジSE1名で、スクラムイベントへの参加者も開発チームからはブリッジSE1名のみになります。（ブリッジSEが開発チームの状況を把握した上での参加）見積と実績は時間で運用しております。スクラムイベントはカスタマイズして実施しております。（ご了承くださいませ） デイリースクラム 参加者　：開発チーム、スクラムマスター開催頻度：毎日開催時間：15分 アイスブレイクの一環として日本とベトナムの違いについて雑談。ブリッジSEからチケットごとに「昨日の進捗」「本日の予定」「問題点や相談事項」に沿ってヒアリング。 スプリントプランニング 参加者　：プロダクトオーナー、開発チーム、スクラムマスター開催頻度：2週間に1回開催時間：30分 下記①、②は事前にご対応頂き、スプリントプランニングでは③に注力しております。①プロダクトオーナーがチケットを優先度順で登録する②開発チームが登録された各チケットの対応にかかる時間を見積もる③スクラムチームがこれまでの実績と見積もりを比較の上、どのチケットまで対応完了できるか計画を話し合って合意を取る スプリントレビュー 参加者　：ステークホルダー、プロダクトオーナー、開発チーム、スクラムマスター開催頻度：2週間に1回開催時間：30分 ステークホルダー向けにスプリントでのインクリメントのレビューを実施して、頂いたご意見をもとにプロダクトの改善を図るきっかけとなっております。チケットごとに対応内容の説明はプロダクトオーナー、デモはブリッジSEが担当してレビューを進めております。 スプリントレトロスペクティブ 参加者　：プロダクトオーナー、開発チーム、スクラムマスター開催頻度：2週間に1回開催時間：30分 KPT（Keep：続けたいこと／Problem：問題点・課題／Try：挑戦したいこと）に沿って出た意見の中で1番賛が多かった意見を次のスプリントで実施するようしています。他のフレームワークも試してみて、合うものを模索したいと考えております。 導入したメリット スクラムチーム内で確認したところ、下記4点挙がりました。 タスクボードの活用によって各チケットのステータスや担当者などの情報が可視化されたため状況が把握しやすくなったチケットの相対的な優先順位を認識することができるようになったゴール（どのチケットまで完了する見込みか）の共通認識をチームで持つことができた導入前と比較してMTGにかかる工数を削減することができた 今後の改善点 直近の改善点として下記を考えております。 スクラムイベントの最適化 ブリッジSE以外の開発チームメンバーもスクラムイベントに関われるように運用を変更する チケット対応方法 1チケット1開発者での対応でなく、優先順位をもとにチームでチケットを対応してもらうようチケットの中でさらにタスクを分割する まとめ 私自身、前任者がスクラム開発を導入した状態から昨年12月に引き継いで当PJに参画いたしました。まだ試行錯誤している状態ですが、改善を重ねてより良いスクラムでの運用をできればと考えております。 ここで出たメリットはスクラムチームのみなさまにご理解・ご協力頂いた賜物だと思っていますので、今後も生産性の向上を目指して、チーム一丸で挑戦していきたいと考えております。

こんにちは。デベロッパーリレーションズチームの村上です。今年1回目の記事はオンボーディングについて書いていきます。オンボーディングとは？やチームにジョインした方があまり馴染めてないかなと感じてる人の参考になれば幸いです。 オンボーディングとは オンボーディングとは「会社やチームに新たにジョインする人材を教育・育成する為の施策」のことを言います。これは新卒や中途で新しく入ってきた人だけでなく、例えば管理職になったばかりの人も含まれています。業務の内容を教えるOJTとは異なり、会社やチームの思想、ミッションを理解してもらったり人間関係の構築等を行う為に行います。※余談ですが、オンボーディングの元の意味は乗り物に乗り込んでいる状態であり、パートナーが組織に含まれた様子を表しています。 オンボーディングの重要性 オンボーディングの重要性は、以下3点だとわたしは考えています。 ジョインしたパートナーを早期に戦力化できるチームとしての一体感を高められる心理的安全性を確保できる OJTで業務を教えるだけでは即戦力で働ける人はそう多くないです。オンボーディングを行うことで組織体制や業務をより早く理解してもらえるため早期の活躍が期待できるのです。 また新しい環境で業務に取り組むにあたり重要なのは心理的安全性です。どんなによいチームでも、お互いを理解し溶け込むまでには時間がかかったり、人によっては孤独感が出てしまうかもしれません。そういった状況もオンボーディングで解決できることが多いと感じています。 私が在籍しているGMOインターネットの北九州オフィスではオンボーディングを積極的に行っていることもあり、去年1年間の離職率も2%と非常に低い数値となりました。 またチームマネジメントの観点から、パートナーのコンディションを見るためにWevoxというツールを利用しています。支援や人間関係・承認といった数値は全社平均より更に高い数値となっており、チームのパートナーたちも納得感を持って業務に取り組めていることも離職率を下げた要因の1つといえると思います。 オンボーディングのメリット・デメリット オンボーディングを行うメリットとしては以下3点をあげます。 パートナーのモチベーションアップやコンディションを良好にすることができるジョインしたチームの雰囲気を知ってもらい、早い段階で馴染んでもらうことができる開発してもらう業務に対して、納得感をもって取り組んでもらえる デメリットは、既存パートナーにも大なり小なり工数が発生してしまうところです。マネージャー1人が頑張ってオンボーディングしても、チームとして受け入れる体制でなければオンボーディングを成功に導くことはできません。既存パートナーのモチベーションやコンディション維持を含めてマネージャーの腕の見せ所だと考えます。 チームでのオンボーディング施策 対応するサービスの歴史やパートナーの説明 私のチームが担当しているとくとくBBというプロバイダーのサービスは、かなり歴史の長いサービスとなっており、これまでにたくさんの商品が追加されてきました。その商品の仕様だったり、外部との連携部分の設計がどうなっているかを勉強会という形でパートナーに共有しています。元々は属人化を解消する為の施策ではあるのですが、新しいパートナーにも自分がやるサービスの歴史を知ってもらうことで納得感を持って開発に取り組んでもらうことができています。 とくとくBBの開発自体は東京・北九州・ベトナムと多拠点に渡って開発している為、各拠点の人とコミュニケーションを取る機会を設け、開発をする際の心理的安全性を高めています。 海外を含む複数拠点に点在するエンジニア同士なので、直接顔を合わせることはありません。だからこそ、お互いを知る機会というのはとても重要だと実感しています。積極的にコミュニケーション機会を設けることで開発効率のアップにもつながっています。 過去執筆した以下記事でも詳細ご紹介していますので機会があればご覧ください。 https://developers.gmo.jp/technology/10325/ 定期的な声掛け・1on1 現在はオフィス出社と在宅のハイブリッド運用をしていますが、オフィス出社時は定期的にこちらから声をかけるようにしています。個人的にですが「わからないことがあったら聞いてください」が一番まずいコミュニケーションだと思っています。こちらから声をかけることで、小さな困りごとを相談できたり、雑談でコミュニケーションを取れたりするので、必ず自分から声をかけるようにします。 また、週毎や月毎に1on1によるヒアリング、チームのパートナーを交えたランチコミュニケーション、（時期は選びますが）飲み会だったりに積極的に誘ってます。この辺のお誘いはパートナーの性格にもよるので、徐々に深めていきましょう。 チームでやるコミュニケーションタイム 以前のブログにも書きましたが、私のチームでは、コミュニケーションを円滑にするための企画を各クォーターごとにパートナーに1つやってもらっています。 この企画に新しくジョインしたパートナーも参加してもらうことでチームに馴染んでいただくきっかけになっています。ドラッカー風エクササイズなんかは既存のパートナーのことを知ってもらうのに非常に有効なので、この企画をきっかけに仲良くしてもらってるケースは多いです。 https://developers.gmo.jp/technology/11838/ 業務上の付き合いだけだと、中々深く話したり相手を知るきっかけを見つけにくいので、コミュニケーションをとる為の時間は別で確保したほうが良いです。 リモートワークにおけるオンボーディングのあり方 オンボーディングで難しいのはリモートワークのときです。相談したい相手が何をしてるか見えにくい状況が生まれるため、相談できず孤立してしまう可能性が高いです。なので私は以下を実践しています。 DiscordやZoomを常時接続した状態にしておいて、声をかけやすい状況を作っておく業務MTGの際にも、時事ネタや最近あった話をネタにして雑談をする時間を作るリモートワーク中は1on1で話しやすいので、込み入った話はリモートワークの日にやる これはオンボーディングに関わらず、そもそもリモートワーク中に気をつけてることでもありますが、組織やいっしょに働く仲間への信頼や安心感につながるようなコミュニケーションを意識しています。 まとめ チームをマネジメントする上でオンボーディングは非常に大事です。コロナ渦でマネージャーとして積極的にオンボーディングを実践してきたことで離職率やパートナーのモチベーションに影響があったことを受けて実感しています。 とはいえ、オンボーディングはマネージャーだけが頑張ってできるものでもなく、チームの協力が必要不可欠です。早期にチームが一体感をもって開発に取り組める環境をつくることは、結果的に生産性に直結していきます。 マネージャーや管理職のみなさんは、既存のパートナーも新しいパートナーも一緒になって、目標を達成できるように工夫していきたいですね。

こんにちは。デベロッパーリレーションズチームの村上です。今回はチームの目標達成のために効果が高いと言われているマンダラチャートをやってみた話を書いていきます。興味のある方はぜひ読んでみてください。 はじめに 私のチームでは、コミュニケーションを円滑にする施策を各クォーターごとにメンバーに1つやってもらっています。それはゲームだったりワークショップだったりするのですが、そこでマンダラチャートという施策が出ました。通常マンダラチャートは個人の目標達成のためのものかなと思っていましたが、チームビルディングにも活用できるんじゃないかなと考え、チームのマンダラチャートを作成しようという考えに至りました。 マンダラチャートとは そもそもマンダラチャートとは目標達成するのためのフレームワークになります。9×9のマス目で構成され中心のマスに目標を記載し、それに関連する要素を周囲のマスにメモしていきます。野球の大谷選手の話が有名じゃないでしょうか。 出典：スポーツニッポン 目的・効果 必要な要素やアイデアを書き出すことで、目標を達成するための思考を整理することができます。またチームビルディングにおいてはみんなで考えながらやることで、コミュニケーションを取るきっかけにも繋がります。 実施タイミング チームビルディングにおいては、チームのコンディションを見ながら適切なタイミングで実施する必要があります。今回のマンダラチャートはタックマンモデルで言うところの「統一期」に実施するのが望ましいです。チームのメンバーの強みや役割が明確化されて、共通言語や同じ価値観が生まれてくるこの時期に、目標達成の為のフレームワークを用いることでタックマンモデルの次のステージに移行することができるようになります。※タックマンモデルとは、チームは4つの成長段階を経て成果が出せる状態になることを示したフレームワークです。 チームビルディングでマンダラチャートを使うメリット マンダラチャートを活用することで、様々なメリットを得ることができます。 目標達成のプロセスが明確になる 仕事をする上で目標を設定することは当然だと思いますが、目標達成までのプロセスが明確になっていないことが結構多いです。目標に対してどういう行動をすべきか、何を優先して取り組むかという点を考えるのは中々難しいです。マンダラチャートは最初に目標を中心のマスに書き、それを達成するために連想される言葉を書いていくので、目標に対してどういう行動を取ればいいかを適切に把握することができます。 チームメンバーのアイデア・考えを発見できる メインのマスから関連する言葉を記載していく過程で、メンバーから新しいアイデアや考えが出てくることがあります。周辺のマスを埋める際に、特に制約のようなものは作らないので、自分では思いつかないような考えやアイデアがメンバーから出てくることが期待できる点はメリットと言えるのではないでしょうか。 可視化することで後で見直すことが容易にできる マンダラチャートを作成しておけば適宜必要なタイミングで見直し、目標達成のためのアイデアや必要なアクションを取ることができます。また目先の業務に追われて、目標に対しての適切な行動や優先順位を忘れてしまうことがあると思いますが、可視化しておくことで立ち返ることや、行動を見直すきっかけになるので、継続して追いやすくなります。作成する際はシェアポイントや共有ドキュメントとして、いつでも確認しやすく管理しておくことをおすすめします。 マンダラチャートの作成方法 それではマンダラチャートの作成の基本的な流れを説明していきます。 3×3のマス目を作成して中心のマスに目標を記載する 中心マスに達成した目標を記載します。ここが重要な要素になるので、よく考えて設定してください。 目標に関連する言葉を周辺のマスに書き出す 中心マスの目標が決定したら、周辺マスに目標に対して関係しそうな言葉・アクションを書き出していきます。この部分は抽象的なものでも構わないので、しっかりとマスを埋めていきましょう。 周囲の3×3のマス目の中心に記載した言葉を写す 中心の周辺マスに書いた言葉・アクションを、周囲の3×3のマスの中心に書き写し、中心と同じように関係しそうな言葉・アクションを書き出していきます。ただしここに書く内容は達成する為に必要な具体的なものを書くようにしていきましょう。 チームでマンダラチャート では、実際に私のチームでマンダラチャートを作成した時の話です。なぜ今回のタイミングでマンダラチャートを行ったかというと、1年間かけてしっかりとコミュニケーションを取り、メンバーとの心理的安全性を高め、チームとして目指していく目標を立てるタイミングであったので、まさに今やるのに効果的だからと考えたからです。 実施した感想 ちょうど私を含め8人で書いてたので一人1マスずつ埋めていきました。本来であればもう少し悩みながら書くものだとは思いますが、今回は閃いたものを記載してもらうようにしました。真ん中の目標に関しては個人的にはちょっと抽象的かなと思いましたが、初めてやるのでこんな目標にしてみました。参加したメンバーからは以下のような感想・意見をもらいました。 目標達成に対して自分がどのように動けばいいか明確にできた目標に関連する単語は思い浮かぶけど、具体的にどうすればいいかを認識合わせできて良かった考える時間が短かったので、もう少し考える時間がほしかった 私自身もやってみた感じ、想定より効果がありそうな取り組みだと感じたので、この目標に対する言葉・アクションを見返すタイミングを作り、目標達成ができるチームビルディングを行っていきたいと思います。 メインの目標に関しては、複数持っても良いかなと思うので、事業に対しての取り組みのマンダラチャートや、もう少し細かい目標設定に対してもマンダラチャートを活用していければと考えています。 まとめ チームで作るマンダラチャートはタイミングを選ぶかとは思いますが、チーム全員が目標に向かって進んでいく為のフレームワークとしては非常に優れていると感じました。目標は立てるけど中々達成できないなという方は、ぜひチームでマンダラチャート作成してみてはいかがでしょうか？

2021年9月16日（木）～17日（金）の2日間、グループ横断テックカンファレンス「GMO Developers Day 2021」がオンラインで開催されました。「GMO Developers Day」はGMOインターネットグループのサービス開発における技術や取り組みを伝える大規模テックカンファレンスです。今年はNFTやブロックチェーン、5G、DXなど業界の最先端情報を中心に全30のセッションが展開され、最新技術を活用した新しい挑戦や課題解決事例を交えたトークが繰り広げられました。開催レポートについてはこちらをご覧ください。本エントリーでは、大盛況を収めた同イベントのCTOクロストーク対談についてレポートいたします。 イベント概要 開催日時：2021年9月16日（木）～17日（金）アーカイブ動画：https://youtube.com/playlist?list=PL-nSubl7UrR4GYfl4mbwdX7iuY_d-BOV7 KEYNOTE：CTO対談 本セッションでは、ホスティング・ドメイン・決済・銀行・ECと多岐に渡る事業を展開している各社からCTOが登壇し、エンジニア組織の文化や取り組み、技術についてクロストークいたしました。 スピーカー 矢上 聡洋　GMOあおぞらネット銀行株式会社　CTO三谷 隆　GMOペイメントゲートウェイ株式会社　常務執行役員 CTO安藤 雄飛　GMOインターネット株式会社　システム本部UXデザイン開発部 部長 モデレーター 栗林 健太郎　GMOペパボ株式会社　取締役CTO インターネットを意識しなくても使えるように 栗林GMOインターネットグループは様々な事業をやっていますよね。GMOインターネットはホスティング事業、アクセス事業、マイニングもやっていて、グループとしては決済事業や銀行もあって、外から見た時「このグループは何をやっているんだろう？」というくらい幅広いところが僕らの特徴だと思います。一方で各社ごとに専門性があり、強い面や特色を持っています。そういう観点で、もっと深く、どういうサービスをやっているのか、どういう事業、どういうビジネスモデルでやっているのか、それぞれ簡単にご説明いただけますか？ 僕たちは創業から一貫してインフラ事業で「場を作る」ことに取り組んでいます。皆さんにインターネットを楽しく使っていただくのもそうですが、その上でいろんなビジネスを展開したり、インターネットに関係のない会社にもDXや業務効率改善でインターネットを役立てていただいたり、電気・ガス・水道のような生活インフラの1つであるインターネットに重点を置いて事業を展開してきました。コーポレートキャッチで「すべての人にインターネット」と言っていますが、インターネットを意識しなくても使えるようにしたいと思っています。安藤 栗林GMOインターネットグループは外から見たらいろいろなことをしていると先ほど言いましたが、その軸にはインターネットインフラを作っていくんだという一貫したミッションがあって、そこに沿って事業を展開しているんですね。続いて矢上さんお願いします。 一般的に銀行はお金を預けたり企業に融資したりしますが、我々はGMOインターネットグループらしく、インターネットの世界に銀行を出すことに重点を置いています。その手段として銀行システムにアクセスできるAPIを公開しており、現在約160社のお客さまにご契約いただいています。2017年に、各金融機関はAPIを公開してデータにアクセスできるようにしなさいという銀行法改正が行われましたが、それを上手く使ってAPIの公開に力を入れている日本のトップランナーだと自負しています。最近はこのAPIを軸に、バンキング・アズ・ア・サービス（Banking as a Service、BaaS：銀行・金融機能をサービス化したもの）への取り組み、さらにそれを発展させた組込型金融サービス（Embedded Finance：非金融企業の事業サービスに銀行・金融機能を組み込んだもの）への取り組みも始まっており、エンドユーザーから見ると金融機関がどこにあるかわからないような世界にチャレンジしています。矢上 栗林銀行業はインターネットインフラを作るというグループミッションから少し外れているように見えていましたが、銀行が1つのインターネットインフラとして必要不可欠なものになってきていて、APIやBaaSによってインターネット自体をより強化しようとしているんですね。では三谷さんお願いします。 我々は「ペイメントゲートウェイ」という名前が示している通り、クレジットカード等による支払いを可能にするテクノロジーを提供しています。決済手段はこの2～3年で急増していますが、ECサイト側としてはユーザーニーズに合わせて全種類揃えたいけれど、それを自分たちで準備するのは非常に難しいです。ですから我々がその決済手段を束ね、ワンストップで決済できるようにしており、QRコード決済のプラットフォームを提供したり、BNPL(Buy Now Pay Later：後払い)を提供したり、決済を便利にする仕組みを日々考えてお客さまに提供しています。決済は売買の根幹ですが、みんな決済がしたいわけではなく、ものやサービスが欲しいんですよね。ですから購入時に決済そのものにストレスを感じさせないシームレスなものを目指しています。三谷 栗林インターネットインフラの中で「ペイメントゲートウェイ」は欠かせないものですが、ユーザーが当たり前に決済できる仕組みづくりに注力されているんですね。知らないふりをしてあえて質問しますが、銀行と決済はお金の流れという意味では似ていると思うので、GMOあおぞらネット銀行とGMOペイメントゲートウェイの違いを教えてください。 決済機能やデータを提供しているのは金融機関側にあって、それらをつなぐ決済ネットワークの仕組みをGMOペイメントゲートウェイが担っているという感じですね。矢上 三谷実際、我々の関係は密接で、様々な事柄を一緒に手を組んでやっています。 お金の流れを作るという、いわゆる金融という部分では重なるものの、アプローチや担当領域が少し違うということですね。ここでGMOペパボのこともちょっとだけ紹介すると、GMOペパボはホスティングサービスやECサービス、ハンドメイドプラットホームなどいろいろやっていますが、一貫して「クリエイターの支援をする」という、表現者がインターネットで何かを出してそれが皆に知れ渡って広がっていき、その人の可能性を広げてあげるようなビジネスをずっとやってきた会社です。インターネットインフラというところで、人々にとってなくてはならない、自然に存在して自然とそこで活動できる世界を目指しています。栗林 コロナで加速したDX 栗林説明の中でDXという言葉が出てきましたが、それぞれの領域で取り組んでいることは一言でいうとDXにつながると思うので、ここを掘り下げたいと思います。DXといえば、2020年1月くらいからコロナ禍が始まり、もう1年半以上続いている中で、DXは災い転じて一気に浸透しました。そんなコロナ禍における各社の違いや力を入れたポイントを教えてください。 決済業界は、現金自体に触りたくないとか、買い物に行くのをためらってECに人が集まったりして、キャッシュレスが非常に進んだ2年間だったと思います。会社の中でも、強制的に脱ハンコになったり、在宅勤務制度ができたり、採用がリモート面談になったり、当たり前のように非対面が受け入れてもらえるものになったので、すごくやりやすくなったと良い方に捉えています。しかし、やはりFace to Faceの大事さやオン・ボーディング（on-boarding）、仕事以外の接点についてはかなり制約を感じているため、逆にFace to Faceの重要性を痛感しています。三谷 矢上決済に関わるビジネスはあまり落ち込んでおらず、むしろ伸びているので、事業スピードやシステムアプリ開発のスピードを緩めることができません。結果、やってみたら意外とうまくいった、ということも多かったですね。例えば半年以上かかる大きめのプロジェクトで、他社の関係者の皆さんと一度も対面でお会いすることなく完了まで持っていったり、やればできるじゃん、という気づきは大きかったと思います。あと、GMOインターネットグループ全体で感染リスクのレベルに応じて出社するしないを細かに設定しているように、我々も細かくリスクコントロールをしながらもコミュニケーションを重視し、業務効率の最大化に取り組んできたため、業績に大きな影響は出なかったのだと思います。 銀行ってリモートで仕事できるんですね。栗林 矢上そうですね。個人情報を取り扱う部分でどうしても制約が出てしまうため、もちろん100％というわけにはいきませんが、それ以外のところはリモートで回しました。銀行の場合はコロナに限らず地震などの自然災害も含めたリスクに対する体制、業務継続性というのが常に課題としてあるため、それがこの2年で一気に進んだという感じですね。以前から備えはしていたので、うまくリモートにシフトできましたし、この状況はこれからも継続していくのではないでしょうか。 コロナでDXが10年進んだ、なんて言われますが、我々にとってもそういう面があったんですね。栗林 安藤リモートワークだけでなく学校や塾のオンライン授業も浸透したので、トラフィックがかなり増えましたし、その運用を継続するためのネットインフラのお申し込みも増えています。他にもバーチャルデスクトップの需要も増えていますし、意外なところだと巣ごもり需要でマインクラフト関連のサービスが好調でしたね。当社はもともと福岡県北九州市にエンジニア拠点を持っていて、そことのコミュニケーションでリモート接続を以前から行っていたため、エンジニア部門としてはコロナ禍にスムーズに対応できました。でも、その裏でカスタマーサービスのメンバーが毎日出社していたり、データセンターで作業するメンバーは現地に行かなければならなかったり、リモートできないパートナーとのバランスはすごく重視しました。コミュニケーションに関してもいろいろ試していて、朝みんなでZoomをつないで一緒にラジオ体操をやる、なんてこともやりました。 インターネット上でのビジネスを支える屋台骨 栗林ここまでGMOインターネットグループの多種多様な事業について紹介してきましたが、どの会社もエンジニアにどんどん来てほしいと思っているはずなので、採用という観点での話に移りましょう。このセッションを見ている人は、「じゃあどの会社に入ればいいの？」「どの会社が自分に合っているの？」と疑問に感じていると思うので、各社のアピールポイントを聞いてみたいと思います。 どの企業もインターネットインフラの上でビジネスを展開していますが、インターネットインフラそのものを作っている企業は世の中に多くありません。膨大な量のサーバーやネットワーク、データセンターなどは、当社の中でも触れるメンバーが限られているのでかなりレアですし、そういう珍しい業務に携われるという部分におもしろさを感じてもらえるのではないでしょうか。私が担当しているのはその上のアプリケーション部分で、インターネットインフラに付加価値をつけていくことをミッションとしていますから、ITやエンジニアと関係のない一般の方にも広く使っていただくにはどうしたらいいかを考えながらサービスを開発するのもとてもおもしろいですよ。安藤 栗林GMOインターネットグループが提供するドメインやホスティングの提供数は、日本のインターネットの大部分を占めているため、インターネットインフラの屋台骨を支えるという役割に興味がある人に向いているということですね。 採用という観点になると、やはりいわゆる「銀行」というイメージが先行することが多いんですよね。大抵の銀行は内部にエンジニアはいなくて、ユーザー部門の意見を取りまとめて外部に発注するケースが一般的です。そのため、そんなところのエンジニアって何が楽しいの？ と思われがちですが、GMOあおぞらネット銀行はまったくの真逆を行っているので、そこをこの場でお伝えしたいと思います。私は2年ほど前まで別のITベンダーにいましたが、当時より今の方が断然エンジニア色の強い仕事をしています。既存の金融機関では大体外部に委託しているものを、我々は基本的にすべて内製していますので、APIの提供もすべて自前ですし、スピード感を持って開発することができています。内製に徹底的にこだわっている部分が当社の1番の強みですので、スピード感において当社のAPI開発は日本一じゃないかと思っています。銀行ではあるものの、日本の金融を銀行の立場から破壊していこう、という人が集まっているので、エンジニアの力で世の中を変えたいと思っている方々に来ていただけたらと思っています。矢上 栗林エンジニアがチームの一員として銀行そのものを作ることができる、作る側として働ける、というのが他行にはないGMOあおぞらネット銀行の魅力で、銀行の中の人として企画もデザインもエンジニアリングも一緒にできるというのはかなり貴重な体験、ということですね。 しかも、APIを提供する先がやはりエンジニアなんですよね。APIを利用する側のエンジニアと協業することもあり、APIを活用した設計の部分まで一緒に考えることもあるので、もうエンジニアがいないと回らない銀行です。矢上 栗林ソリューションにもエンジニアリングが関わっているんですね。ちなみに内製率はどれくらいなんですか？ 今のエンジニア比率は約40％で、これを50％まで引き上げようとしています。矢上 三谷GMOペイメントゲートウェイからは2つ。1つは、FinTech（フィンテック：金融×技術）やキャッシュレスという伸びしろしかない世界で毎年25％以上成長を続けていて、経済活動・社会活動そのものを支えるミッションクリティカル（業務遂行に必要不可欠）な決済事業という難しさはあるものの、社会的に重要な開発業務に携われるという点。もう1つは、我々も内製開発に力を入れていて、内製による品質やスピードにこだわっている決済プロ集団を自負していますので、ベンチャー的に最先端技術に取り組んだり、ミッションクリティカルな決済事業を安定した技術で支えたりと、良いとこ取りをしながらバランスよくスピードと品質を追求しています。根っからの技術好きでテクノロジーにずっと触れていたい、という人が現場で手を動かしていて、それを突き詰めることで社内で評価されてどんどん上に上がっていけるような会社なので、マネジメントやベンダーコントロールをやりたいという方よりは、大好きなテクノロジーを追求し続けたいと思っている人にとってエキサイティングな会社だと思っています。 ミッションクリティカルですし、トラフィックもすごそうですね。栗林 三谷そうですね。ECサイトでセールがあるだけで、秒で数千件入ってくることもあるので、そのあたりのノウハウやナレッジはかなり溜まっています。そういう裏側が知れるという点では、ある意味学べる世界かなと思います。 楽しみながら新しいことにチャレンジできる環境がある 三谷エンジニア自身が日々ワクワクしながらそれぞれ成長していってほしいという想いが強いので、事業会社でユーザーの声を直接聞きながら開発していきたいとか、フルスタックエンジニアを目指したいとか、難しい機能要件のシステムにチャレンジして腕を磨きたいとか、そんな人たちに来てほしいと思っています。 我々はベンチャーみたいな銀行なので、新しいことになんでもチャレンジしていきますし、日本初・世界初といった目立つこともやっていますので、そういう環境に挑戦してみたいという方や、日本だけでなく世界の金融を我々銀行の立場から破壊しようというミッションに共感していただける方にぜひお越しいただければと思います。ちなみに来月から銀行振込手数料が業界最安値の86円になります。振込でお困りの方がいらっしゃいましたら、最短即日で口座をお作りいただけますので、ぜひ！矢上 安藤やはりGMOインターネットも内製にこだわっていて、そこにはサービスに対する愛着があるので、ただ単に自分ができるテクノロジーや言語だけを使うのではなく、サービスに対してどうやってそのテクノロジーを活かせばいいのかを考え、それを楽しめる方が1番いいと思っています。各社それぞれ、いろいろなサービスを展開しているので、まずはそのサービスに愛着を持っていただきたいですし、変化の激しい業界なので、そうした動きにいち早く反応して敏感にキャッチして、変化そのものを楽しめるような方がいいですね。楽しく開発できる環境ですので、この業界でぜひ一緒に戦っていきましょう。 さいごに 全編セッションにつきましては以下よりご視聴ください。 https://www.youtube.com/embed/VL0-ogv0_ys