概要

シリーズAのスタートアップである現職に2024/03に入社し、2024/06ごろからPdMとEMを実質的に兼任してきました。
組織への投資を十分にできない組織状況の中で、組織マネジメントを進めるために

Learning Outcome

対象の聴衆

• EMとPdMを兼任している方
• 組織への投資を十分にできないが、プロダクト組織を形成していきたい方
• 事業の成長速度が早い中での組織開発と事業開発のバランスに困っている方

その人たちが得られるもの

• PdMとEMの役割を兼任する時の頭の切り替え方
• 十分にEMとしての工数を割けない中での割り切り方

概要

直近、組織的な課題を解決するためにイネイブリングチームを組成し、そのチームが自走するまでを手掛けました。
本トークではその際に行った施策やアプローチについてお話します。

私自身はテックリードの役割を担うプログラマですが、技術的な革新を行うために組織に手を入れる施策をする必要がありました。
そのひとつがイネイブリングチームの組成です。

しかしながら、テックリード業務がある関係上、マネジメントに集中することはできません。
そこで試みたのは「いかにチームを自走させ、手離れするか」です。

行った施策はさまざまです。
たとえばグループからチームに進化するために必要なコミュニケーション基盤づくり。
技術的知見の相互共有の仕組みづくり。
相互サポートの雰囲気つくり。
それらを具体的にどのような予測から実施し、いかに浸透させたかについてお話いたします。

なお、私自身はマネジメントするのもされるのも嫌いな典型的なさきがけタイプのプログラマです。
組織の先頭をひた走るようなプログラマが何を好み、何を嫌うのか、それを自ら知っているからこそできるノウハウについてお話しいたします。

Learning Outcome

• チームが目指す姿とその背景にある理論
• 学び合いを促すコミュニケーションルール
• 主体性を発揮させるための状況作り
• メンバーのアラートを察知するためテクニック

概要

製品の開発・運用を通じて価値を提供し、事業を成長させる企業にとって、エンジニアリングマネージャー（EM）は極めて重要な役割を担っています。これまで、以下のような環境でマネジメント経験を積んできました。

• 会社規模：大企業、ベンチャー、GAFA
• 製品属性：SIer、toB、toC
• マネジメント規模：5名～40名
• マネージャーの役割：エンジニアリング、プロダクト、プロジェクト、技術サポート、バックオフィス、役員

この経験を通じて学んだ以下の点についてお話できればと思います。

• マネージャーが果たすべき4つの仕事
  ・これを怠るとどうなるのか、どのような経験からこの重要性に気づいたのか

• それに必要な4つの力
  ・「言語・資料化」「共感力」「推進力」「知識」はどういった内容で、どうマネージャーの仕事に紐づくか

株式会社ラクスでは、「思考力」「行動力」「人間関係力」「組織推進力」の「コンピテンシー」を大切にしています。
また、開発本部では製品づくりをするエンジニアが顧客に成り代わり課題を認識し、「顧客志向」で製品開発をしています。

これらをふまえEMに求められる「コンピテンシー」の具体的な中身とこれを実際にどのように実践しているかについてもご説明します。

Learning Outcome

• マネージャーにおいての大切な仕事の理解
• そのために必要な能力の理解
• EMとしてその能力を身に着ける・発揮するためのコンピテンシーの理解
• どう実践すると成果につなげられるか

目次

　１．マネージャーの仕事とは？
　２．自分の経歴の変遷の紹介
　３．マネージャーでの成功/失敗体験
　４．マネージャーの仕事に必要な力とは？
　５．EMに必要なコンピテンシーとは？
　６．現在、実践していること

概要

EngineeringManager（以下、EM）とTechRecruiterがどのように協力し、理想的な協力体制を作ることで、事業の最大の差別化要因となるプロダクト組織を構築できるかについて、現役TechRecruiterの視点でお話します。

これまでの成功体験に基づく紹介ではなく、「理想とする協力体制」をテーマに据え、これまで多くのEMと協業した経験から、モメンタムを産むEMとTech Recruiterの協業体制、採用にまつわる課題をどのように捉え、どのような体制が望ましいかを提案します。

採用とエンジニアリングの双方がシナジーを生むことで、さらなるプロダクト組織のスケールを加速する協力体制を考察します。

このセッションのターゲット

・プロダクト組織の拡大（採用）に責務を持っているEM
・これからプロダクト職種の採用にアクセルを踏みたいと考えているEM
・プロダクト職種の採用担当をこれから採用したいと考えているEM
・プロダクト職種の採用担当がいるものの、協業が上手くいっていないEM

なぜこのセッションを話そうと思ったか？

20名規模のスタートアップ、老舗IT企業、2000名規模のメガベンチャーでのリクルーティングの経験を経て、EMのプロダクト組織構築における役割の重要、またTechRecruiter視点から採用起点に組織を瞬く間にスケールさせ、事業の貢献力を高めていくEMの方を見てきました。

マインド面や、実際の協業体制を踏まえ、環境変化の早い業界においてますます重要となり、昨今明確に事業の差別化要因となっているプロダクト職種の採用において、整理しお話ししたいと考えています。

Learning Outcome

1. 採用とマネジメントの協力関係がもたらすプロダクト組織の成長理解
   採用担当とエンジニアリングマネージャーがどう協力し、組織の強化につなげられるかを理解できる。

2. 採用活動と組織文化の関連性とその重要性の認識
   採用が組織の成長とカルチャー形成にどのように貢献するかを学び、具体的なアプローチに活かせる。

3. 採用担当目線の理想的な体制づくりの方向性
   理想の採用体制やエンジニア組織との連携モデルを把握し、自組織での体制強化に向けたヒントを得られる。

（※ 二重投稿になってしまったので削除したいです。）

概要

新卒エンジニアとしてキャリアをスタートした際、多くの人が「マネジメント」に対して抱く恐怖心や抵抗感を抱いたことがあると思います。（全く恐怖がなかったという人を僕は尊敬してます）
これは「マネジメント」というテーマは意味が広く・重要度もあり・ 難易度も高いがゆえに発生するプレッシャーから来てるのだと考えてます。

僕自身もその一人であり、「マネジメント」を避けてきました。
しかし、転職をきっかけに EMをしている人、テックリード + EMっぽいことをしてる人などの動きを見て、
改めて「マネジメント」ってなんだろ？そんなに恐怖を抱くべきテーマなのだろうか？と冷静に見つめ直すことができました。
そして、恐怖心や抵抗の感情の背景にあった原因を深掘りし理解することでEMを目指す決心ができました。

このセッションでは、新卒エンジニアが「マネジメント」に対して抱く悩みや恐怖心、そこに至るまでのフローを具体的に共有し、それを克服するためのステップや考え方を提案します。

Learning Outcome

対象の聴衆： これからEMを目指す人、EM の教育やキャリア支援に携わる人
話したいテーマは以下です。

• 「マネジメント」というテーマへの恐怖心がどのように形成されるかについての具体的なエピソード。
  • 歴代リーダー・EMからフォローをもらっていたのに、フォローを活用できなかった愚かなエンジニアのエピソード。
• 今だからこそわかる、感情とどう向き合うべきだったかの考察。
• 今のEMの人が、これからのエンジニアやEMを志す人に言って欲しいこと。

概要

人事評価制度は組織や個人の成長に大きな影響を与えるものであり、ピープルマネジメントを担当するマネージャーにとっては真っ向から向き合うべき重要な制度になります。一方で、現場に合わない制度や複雑な制度、メンバーへのフィードバックや周辺組織とのキャリブレーションなど悩みも絶えません。
私はEMとして、これまでに以下のような会社規模や組織の歴史が異なる2社で人事評価制度の設計(改定)・導入・運用に関わる経験を積む機会がありました。

• 1社目： プライム上場企業のグループ事業会社内に創設されて間もない内製開発組織
  • 1社目ではエンジニア向けの目標管理と評価制度を新規に策定しました
• 2社目： 10年来のWebサービスを運営するベンチャー企業のプロダクト開発組織
  • 2社目では複雑化していたプロダクト開発組織の人事評価制度を全社の人事評価制度と接続できるようにスリム化させました

2社に共通することはチームでプロダクト開発を行い、組織として成果の最大化と成長を目指していることです。一方で制度変更の方向性は対照的で1社目では制度への足し算を行い、2社目では引き算を行っています。

本セッションでは上記経験を振り返り、以下のような内容について話すことで、人事評価制度の在り方や運用に悩む方々に未来へのきっかけを提供できればと考えています。

• 各組織で人事評価制度の Before/After
• 期待した効果　〜誰のための／何のための制度なのか〜
• 導入までの工夫　〜関係各位との付き合い方〜
• 運用時の工夫と反省　〜結局は運用〜
• 今後取り組みたいこと

Learning Outcome

• 人事評価制度の在り方と運用を考えるヒント
• 影響範囲の大きな制度を変える際の導入ノウハウ

概要

株式会社プレックスのエンジニア組織は2021年8月に私が1人目のフルタイムのエンジニアとして入社した時からスタートしました。
そこから3年が経った現在では、フルタイムのエンジニアが16名、業務委託・アルバイトのエンジニアが6名と合計20名を超える規模へと成長しました。
本セッションではプレックスのエンジニア組織の成長の変遷を、事業やプロダクトといった周辺状況も踏まえつつ、採用と組織デザインの観点からご紹介します。

Learning Outcome

対象聴者

• シード期〜シリーズAのスタートアップで働かれている方
• エンジニア組織を成長させていきたいと思っているCTOやEM
• 採用に課題感を持つ採用担当者

得られるもの

• 実際に事業、プロダクト、組織が成長する中で表出化した課題とその対応の事例
• 採用や組織デザインについての具体的な事例
• リソースがない状況下からエンジニア組織を拡大していった戦略
• 組織デザインにおける考え方

概要

エンジニアリングマネージャーとして成果を上げている方の中には、異動や転職で新しいチームにEMとして参加する機会がある方も多いのではないでしょうか。しかし、一つの開発チームでSWEからEMへとキャリアを積んだあと、別チームにEMとして異動するというのは大きなチャレンジです

昨年、私は別グループ会社のプロダクトチームにEMとして異動しました。コードベースも知らなければメンバーもほとんど接点がないという、これまでとは異なる文化やプロダクトに飛び込む大きなチャレンジでした。新しい環境で、どのようにアクションをとりリーダーシップを発揮しながらチームと信頼関係を築くか、試行錯誤の連続でした。

本セッションでは、EMが新しいチームに異動した際の戦略と具体的なアクションプランについて私の経験を踏まえてお話しします。

このセッションを通して、新しい環境でいち早く順応し、チームをリードしていくためのヒントを掴んでいただければ幸いです。

Learning Outcome

対象者:

• これから異動や転職を控えているEM
• 新しい環境で課題を感じているEM
• 将来の異動に備えて準備したい方

得られること:

• 異動後にスムーズに成果を出すためのアクションプラン
• 新しいチームとの信頼関係を迅速に築く方法
• 効果的なリーダーシップを発揮するタイミングとアプローチ

概要

株式会社スタンバイで VPoE（など）をさせていただいている高原です。
この場に集まられたみなさんですので、なにかしら現場で「もっとこうしたい」「もっとできるんじゃ？」と考えられているのではと思います。
もちろん私（私たち）もそうで、メンバー1人1人の個性に向き合って業務とキャリアを接続するとか、チームの開発プロセスに障害を見つけて取り除くとか、具体を見て→考えて→取り組むを繰り返しています。
そんななか、チームを横断して「開発組織全体」を見て→考え→取り組んでいることがあるのでご紹介したいと思いました。

具体も大切だが、抽象へのアプローチも必要かもしれない、という問いや議論の種にできればと思います。

我らがプロダクト部門のマネージャー全員で、今年度の上半期に「マネジメントポリシー」を作成し、部門内に宣言しました。
その背景には、事業のアジリティを高めたいという渇望と危機感から逆説的に得た「チーム横断で組織運営に取り組む必要性」への気づきがあり、あらためて組織ビジョンを見直し、リストーリーを行い、各マネージャーが実現したい組織状態を表す言葉を示し合い、それらを結集したマネジメントポリシーを作り上げました。
そして「作っただけ」で終わらないよう、このポリシーをちゃんと実践して、実際に良くなった！変わった！（そもそもの目的である）アジリティが高まった！という状態を実現するために、マネジメントポリシーの実行や効果を評価する仕組みを定めて、自分たちに課すことにしました。
（もちろん、その仕組みも経験学習によってカイゼンするという宣言込みで）
Pace Layering モデルの深いところにある「カルチャー」を動かそうとする挑戦の経緯とエピソードを共有させていただければと思います。

Learning Outcome

• マネジメントポリシーの具体的な内容や作成手順を知れる
• マネージャー達がこういうことを一丸となって行った背景や経緯を知れる
• マネジメントポリシーのようなものにちゃんと実効性を伴わせるべく、評価する仕掛けを考えた議論の経緯をリアルに追体験できる
• 議論を突き詰められた理由が、アジャイルな“Go See”の姿勢であることを知れる
• 今後の展開について共に議論させていただくベースの話題を共有できる（発表者のアウトカム??）

概要

ICとして運用エンジニア、SREをやっていた前職時代、EMから「マネジメントキャリアパス」を読む薦められたことがありましたが、興味をもって読むことができませんでした。

そんな私は今、さくらインターネットでチームをつくり、EMとして仲間と学び、多くのエンジニアと共にガバメントクラウド認定という大規模開発に立ち向かっています。
2025年度末までにデジタル庁から出されている300件超の技術要件を満たすため開発を進めており、2024年10月時点で大きな遅延は発生はしていません。
本トークではどのようなきっかけでICからEMとなり、EMとして開発チームととも変化し、開発を行って来ているのか紹介します。

・さくらインターネットでもう一度SREチームをつくるきっかけ
・SREチームの取り組みの中で感じた組織課題
・大規模開発への挑戦と、私と開発チームの変化と成長、あるいは変わらないこと

Learning Outcome

【対象者】
・大規模プロジェクトに挑戦し、組織作りに悩むエンジニア、エンジニアリングマネージャ

【得られること】
・難易度の高いプロジェクトへの挑戦や、開発チーム作り悩む皆様のヒントに少しでもなればと思います

概要

マシンに向き合うエンジニアリングとヒトに向き合うエンジニアリングマネジメントについて、その違いをエンジニアとしてのキャリアをベースに話します。
具体的には、マシンとヒトのコミュニケーションはマシン側の絶対的な正となる期待値が用意されているが、ヒトとヒトのコミュニケーションは相対的な期待値から落とし所を見つけ出す必要があり、そのような状況における対応方法を紹介します。
対応方法の内容は、自分の期待値、相手の期待値、事実(結果)の 3 要素から互いの期待値のズレを伝え合い、そのズレに対する解釈を相互に理解し、理想的な結果に近づけていくフィードバックコミュニケーションです。

Learning Outcome

メインターゲット: エンジニアをバックグラウンドに持つエンジニアリングマネジャー
サブターゲット: エンジニアリングマネジャーを目指すエンジニア
ターゲットが得られるもの: 漠然としたマネジメントの難しさや擬かしさの言語化／明日から実践できるフィードバックノウハウ

概要

現在私は「テックリード」という肩書でプロダクト開発に関わっています。ここでいう「テックリード」とは、テクノロジーに関するリーダーとして、技術的な意思決定や方向性の舵取り、チームメンバーの技術力向上支援など、多岐にわたる役割を担うポジションです。
言い換えると、プロジェクトマネジメントとテクノロジーマネジメントを司っているロールであり、両者のバランスを取りながら日々のアジャイル開発を進めることを求められています。

近年、アジャイル開発の現場では、変化への対応力、自律性、そして高い生産性を持つ「クロスファンクショナルチーム」の構築が重要視されているかと思われます。

そこで本セッションでは、アジャイル開発におけるクロスファンクショナルチームの構築と、それに必要なチームケイパビリティの獲得戦略について、ケーススタディを交えながら解説します。

Learning Outcome

• チームケイパビリティ向上のためのアイディア
• 従来の役割分担を超えたチーム作りを実現するための方法

概要

マネジメントにおいて、具体的な目標とは別に、やや抽象的に定義された「期待値」を使っているチームや組織は一定数あるかと思います。このトークでは、「期待値」とはどのようなものであり、どう使うとうまくいくのか、またうまく行かないのかなどを、登壇者の経験とその他公開されている情報などをベースにお話します。

良い期待値を設計するには、マネージャーとして組織の上位の戦略（事業戦略、技術戦略、組織戦略）を理解して自分のチームやメンバーへの期待値に落とし込むことが必要です。しかし、これだけでは一方的な期待値であり、期待値の設計・設定が完了したとは言えません。メンバーの現在地や特徴をよく加味して調整した上で、その内容をメンバー自身が100%腹落ちするまできちんと伝える必要があります。期待値が100%腹落ちしているメンバーは、場面場面における期待される行動を自分で解釈して自分の判断によって行動を選択し、成果を生み出すことができるようになります。これが良い期待値設定の理想状態です。
このような状態に向けて考えるべきポイントなどをお話します。

Learning Outcome

対象聴衆

• 期待値または目標を設定する役割を持つマネージャーの方
• 期待値や目標とうまく付き合えるようになりたいメンバーの方

得られること

• 効果的な期待値を設定するためのポイント
  • 良い期待値と悪い期待値の違い
  • 個人ごとに異なる期待値の効果
  • 期待値を実際に成果に変えるために必要なこと

概要

「エンジニアマネージャー」と言われるロールになって、はや数年が経過しました。
マネジメントスタイル・手法は関係するメンバーに対して、アジャストする必要があるので十人十色といっても過言ではありません。

マネジメントの1つの要素として、「メンバーのキャリアパス構築」があると思います。
エンジニアマネージャーはそれに対して伴走していきますが、どうしても自身のキャリアパスについて、考える時間をなかなか取ることができず、悩むことも多いのではないでしょうか。私も以下のことで悩んでいました。
・複数チームを率いていることで一点突破できるなにかがない
・実務では技術から離れてしまって、キャッチアップがやりにくい
・今の延長線で数年後も成長していないのではないか

それらの悩みに対して、こういう取り組みをしてキャリアパスを描ければよいのではないか？を考えましたので、それを共有します。

■取り組みの一例
・視点を切り替えて、キャリアの広さ・深さを出す / キャリアの希少性を突き詰める
・100点のキャリアパスは青写真なので盲信せずに適宜見直す
・技術は総論を確実に捉え、各論はメンバーからも学びを得る

エンジニアマネージャーを担っている方の「次の一手」についても言及し、エンジニアマネージャーをこれから目指す方へはエールを送る話をします。

後者については以下のドラフト資料を拡充して発表します。
https://speakerdeck.com/yutakawasaki0911/duo-yang-narorujing-yan-gadao-itaenziniakiyarianonabigesiyon

Learning Outcome

■エンジニアマネージャー向け
・キャリア形成での悩みやあるある
・特に「器用貧乏」になりがちな方の悩みに対するアプローチ
・特に「広く浅く」な経験をお持ちの方のキャリパスに対する考察

■エンジニアマネージャーを目指そうとしている方向け
・キャリアパス実現の課題とそれに対するアプローチ
・エンジニアマネージャーを目指すメリットと勘所
・実例をふまえた道しるべ

概要

副業が一般化し、スタートアップを中心に多くの企業で、受け入れてきました。
個人にフォーカスすると、新しい技術や知見の獲得、次のキャリアの選択肢が増える、収入が増えるなどを通じて市場価値を高めることに成功し、転職市場でも優秀な人材が増えている良い兆しが見られます。
一方で受け入れる企業側は外部の優秀な人材の時間や知見を獲得するメリットがある反面、非同期を前提とした一体感の欠如、本体側の目まぐるしい方針転換による作業の手戻りなどデメリットも目立ってきました。

私もスタートアップCTOとして事業やプロダクトに資するため副業エンジニアとのコラボレーションする中で、うまくいったこと、つまづいたことがあります。
これらの知見をシェアすることで、企業側の受け入れ体制がより整う（増幅）->エンジニアの多様な働き方が促進される（増幅）->そのような事例（触媒）が広がる、のようなポジティブな循環を作るきっかけにしたいと思います。

構成

• セッションの背景
• 私たちの取り組み
  • 見える化とワークデザイン
• 私たちが大事にしていること
• 結果何が起きたか

Learning Outcome

▼対象聴衆

• 雇用形態（正社員・副業・業務委託）の垣根なくマネジメントされている方（エンジニアリングマネージャー）

▼得られること

• 副業や業務委託の方と上手にコラボレーションして、プロダクトや事業に接続するための方法論

▼話さないこと

• オフショア開発
• グローバルにまたいだ組織

概要

1人目のエンジニアとして現職にジョインし、5年間で全社員7名から60名強、エンジニアは20名の組織に成長しました。
また、入社以前から開発・運用されていたプロダクトのリニューアルを平行して実施し、現在は新プロダクトが旧プロダクトの全機能をプラスアルファの価値を加えた形でカバーするところまで拡充しました。

プロダクト、組織の成長とともに自分のロールがどのように変遷したかを技術・組織両面からふり返り、そのときどきでどのような課題があり、それらにどのような背景でどう対応してきたか、将来構想についてもお話したいと思います。

Learning Outcome

• プロダクト・組織戦略の事例として
• エンジニアが今後のキャリアを考える参考として

概要

私はこの2年間で、「プレイングマネージャー」「スクラムマスター」「複数チームのEM」としての役割を担う中で、成長支援について考えてきました。タックマンモデルに示されるように、機能するチームを作るには多くの時間と努力が必要であり、特に次の2つの難しさがあると考えます。

1.自分自身の成長ですら簡単ではない中で、他人やチーム全体をより良い方向へ導くことの難しさ。
2.チームは放置すればエントロピーの影響を受け、環境変化によって機能する状態から遠ざかる。

私はこの状況に対して、チームの状態をよく観察し、小さな成功を積み重ねることで、持続的な成長を目指すアプローチを意識したことをお伝えします。

Learning Outcome

• チームの成長支援の難しさを知ることで、支援の打ち手が増える
• 新しくチームにジョインしたEMの考え・行動の引き出しが増えることで、メンバーからの印象が変わる
• 「小さく」「成功を積み重ねる」ような支援方法を知ることで、チームメンバーが成功体験を得やすくなる

アウトライン

• 序章：チームjoin初日にスクラムマスターに任命された

チームの成長が難しい要因

• 他人やチーム全体をよい状態に導く難しさ
• チームの状況移ろいゆく

他人やチームへの向き合いかた

• 他人へアプローチする難しさ
  • 価値観が異なる、自分の関心ごととして捉えられるか
• チームで話すことの重要性
  • メンバーを理解する、関係性がつくれる
  • 腑に落ちて取り組みやすくなる
• 1つ1つ取り組む
  • ハードルを下げる
  • スコープを狭める
  • 短い期間でも「良くなった」を体感する

チーム状況を見立てる

「形成期」に考え行動したこと  

• 信頼獲得と関係構築
• やってみせ  
• フィードバックからチームの文化を形成

「混乱期」に考え行動したこと  

•  感謝を伝えあう  
• メンバーの衝突に向き合う  
• スコープも期日も達成困難な状況から、チームの意識を統一

「統一期」に考え行動したこと  

• 向き直り  
• プロダクト・ユーザーを知る

概要

2024年にはじめて 「エンジニアリングマネージャー」 になりました。

右も左もわからない中でチームがうまく回るようにと、
いくつかの 「ルール」 を作ったり、 「アクション」 を起こしました。

例えば

• エンジニアリングマネージャーとはなんなのか？を言語して共有する
• 部署独自の評価制度を作る
• 15%ルール (勤務時間の15％は普段と異なる業務をしても良いとする制度)の導入
• 採用のチームごと化（皆で採用活動をやっていこう）
• 定例のファシリテーションはみんなで分担する　などなど

これらの試作は一般的には良い効果を生むとされていますが 「実際やったらどうなのか？」 が気になり導入しました。 発表時には導入から 約半年 経ちますので、その結果を皆さんに共有します。

※他にもこんな施策を試してもらいたいというものがあれば、X(@riddle_tec) にご連絡いただければチームと相談して試してみます

Learning Outcome

対象聴衆：

• エンジニアリングマネージャーを志す方
• エンジニアリングマネージャーをやることになった方

得られること：

1. 新人エンジニアリングマネージャーの抱えるリアルな問題や、そのアプローチの知見が得られます
2. 様々な試作を実施した結果、「何がうまくいったか」、「どこが課題だったか？」がわかります
3. 「もし、半年前に戻れるとしたらどうするか？」もわかります

概要

テクノロジーマネジメントの重要性

どれだけエンジニアを採用しようと、どれだけ評価制度を整備しようと、事業が伸びなければ意味がありません。
エンジニアリングマネジメントの4領域の1つであるテクノロジーマネジメントは、その事業成長を技術面から支える重要な領域です。
技術戦略というものは、事業やプロダクトの戦略に基づき、それらの実現を支える形で策定する必要があります。

スニダンのグローバル展開と課題

私がCTOを務めるSODAでは、月間600万人以上が利用するスニーカー・トレカフリマアプリ「スニダン」の開発・運営を行なっています。
そんなスニダンはUS/APACを中心にグローバル展開を進めていますが、技術組織として様々な課題に直面しています。

• 日本向けのシステムと海外向けのシステムが分離されていること
• 分離されている中でも連携が必要なデータを無理に連携していること
• それぞれのシステムを開発するチームが別々であること

などなど、様々な課題によって最速でグローバル展開が出来ていないと感じています。

学びと実践のイテレーションを最速に

様々な課題があり、すべての課題をすぐに解決することは出来ないため、ときにはプロに頼りながら戦略的に技術と向き合っていく必要があります。
SODAでは、AWSの方々にも多大なサポートをいただきながらイベントストーミングを実施したり、その結果を用いてシステムをモジュラモノリスの形にリアーキテクチャしていくプロジェクトなどを進めています。
そして、それらの取り組みすべてにおいて、学びと実践のイテレーションをどれだけ早く回せるかが重要だと考えています。
本セッションでは、そのようなSODAでの取り組みをご紹介し、技術戦略と日々向き合う皆さんの参考になることが1つでもお話しできればと思っています。

Learning Outcome

• 事業戦略を実現するための技術戦略とどう向き合うべきか
• 学びと実践のイテレーションを最速にすることの重要性および具体例