AI時代の開発を加速する組織づくり「迷わず動けるチーム」の秘密

はじめに

こんにちは、株式会社カナリーで不動産マーケットプレイス事業「CANARY」の PLE（Product Lead Engineer）をしております hiro8ma です。

日頃からチームの開発体制や生産性改善に取り組んでいるのですが、ここ1年で特に大きなテーマになったのがAIの活用と、それを支える組織のあり方です。

生成AIの急速な普及により、開発スピードや意思決定の在り方は大きく変わりつつあります。しかし、AIを導入すればすぐに生産性が上がるわけではありません。組織の仕組みや意思決定プロセスが整っていないと、その効果は限定的です。

私が所属しているマーケットプレイスチーム（以後 MP チーム）も、属人化、認知負荷、非効率なコミュニケーションなど、スタートアップならではの課題に直面してきました。こうした問題を根本から解消するため、局所最適を超えた全体最適を目指し、組織・情報・意思決定の仕組みを再設計しました。

その結果、社内の全社キックオフで「ベストチーム賞」を受賞できる成果を出せたのですが、これはAI活用に先立って、「迷わず、早く、正しく動けるチーム」をつくるための土台を整えたことが大きな要因だと考えています。

本記事では、以下を中心に、私たちの実践と学びを共有します。

• AI時代に適応するための組織づくりの考え方
• 属人化や認知負荷を減らし、生産性を高める具体的な取り組み
• 組織改革を進める際のプロセスと再現性ある工夫

同じような課題に取り組む方にとって、ヒントや参考になれば幸いです。

想定読者

本ブログは、開発をリードする立場の方やスタートアップ・成長フェーズの組織で「仕組みを整える余白がない」と感じている方、エンジニアリングマネージャーの方などを対象としています。

「AI時代に『動けるチーム』をどう作るか」をテーマに、開発組織改革と生産性向上の具体的な取り組みを共有することで、皆さまの現場での挑戦の一助となることを目指しています。

AI導入前に見直すべき「組織の仕組み」と「情報の流れ」

AIの普及により、開発スピードや意思決定の在り方は大きく変わりつつあります。

その一方で、「どうすればチームとして迷わず、早く、正しく動けるか」という課題はこれまで以上に重要になっています。

特にスタートアップの現場では、機能開発や運用対応に追われる一方で、チームの構造や意思決定プロセスを見直す余白が持ちづらいのが実情です。

属人化、非効率なコミュニケーション、判断の停滞が蓄積されると、AIを導入しても思うような効果が出ず、現場が疲弊するケースも少なくありません。

本記事では、実際にチーム賞を受賞した MP チームの事例をベースに、Claude Code や Cursor, Devin といったツールを導入する前に、まず見直すべき「組織の仕組み」や「情報の流れ」「意思決定の型」に焦点を当て、実際の開発現場からの学びと再現性ある工夫をお伝えします。

1. オンボーディングプロセスの刷新 — 自立と安心を両立する仕組みへ

MP チームは、約7割が1年以内に入社した新規メンバーで構成される急成長フェーズにあり、増え続けるメンバーを受け入れる体制が追いつかず、意思決定の遅延や認知負荷の増大、役割の曖昧さなどの構造的な問題に直面していました。

こうした問題を解消するため、まず最初に「オンボーディングプロセスの刷新」に着手しました。

主な課題

• 機能開発リソースの圧迫
  • それまではオンボーディングの対応に多くの工数が必要となり、既存メンバーの負荷が増大していました。コンテキストスイッチも頻発し、開発スピードと生産性が低下する要因になっていました。
• オンボーディングの質とモチベーションの低下
  • リソース不足からオンボーディングの質が一定に保てず、新規メンバーの立ち上がりのモチベーション低下が懸念されていました。
• 知識習得のばらつき
  • ドメイン知識・技術知識の習得に差が出ることで、立ち上がりのスピードや認知負荷に大きな差が生じていました。

解決に向けた取り組み

急速に拡大する組織に対応し、継続的に成長できる体制を支えるため、オンボーディングプロセスを抜本的に見直しました。

この改革では、既存メンバーの負荷を抑えつつ新メンバーが早期に自立できる体制の構築、知識や手順の標準化、認知負荷を中長期的に低減する仕組み作りを目指しました。

主な施策と仕組み

• オンボーディングプロセスの刷新

  • 新メンバーが「開発を阻害する要素を取り除き、関係者と違和感なくコミュニケーションできる状態」を目指し、プロセスを明文化・体系化しました。
    

• オンボーディングバディ制度の導入

  • オンボーディングバディとして円滑に進めるために、まず制度の目的や運用を言語化し、全員で共通理解を持つところから始めました。
    • 言語化することで、在籍期間などの基準を満たしていれば誰でもオンボーディングバディを担当できる仕組みにしています。

  

  • 新入社員ごとに専任のオンボーディングバディをアサインし、入社から1ヶ月間、日々の業務や不明点を一緒に確認しながら伴走します。
  • 毎日30分程度の夕会（チェックインミーティング）を設け、気軽に相談できる環境を整備。
  • 入社初日にはバディを中心にチーム全員とカジュアルに顔を合わせる1onNミーティングを実施し、安心感のある受け入れを徹底しました。
    実際のオンボーディングバディの対応履歴 入社前から入社1ヶ月後までの対応リストを TODO 管理する

• ヘッドカウントの段階的調整

  • 新入社員が安心して学びながら徐々に業務に参加できるよう、稼働比重（ヘッドカウント）を段階的に設定しました。
    • 最初の2週間は0：環境構築やドメイン理解に専念するため
    • 次の2週間は0.5：最初のタスクを開始し、業務に慣れるため
    • 1ヶ月経過後は1：通常稼働に移行する
  • また、オンボーディングバディも期間中はヘッドカウントを0.7とし、フォローや夕会の時間をしっかり確保できる体制にしています。

• 入社後のステップ明文化

  • 1週目：ドメイン理解、開発環境構築、オンボーディングリストのタスク消化を進め、チームや開発本部との顔合わせを実施
  • 2週目：最初の実務タスクをアサインし、段階的に業務へ参加する（アサインは3週目以前から行う）
  • 1ヶ月後：オンボーディングリスト全タスクを完了し、通常稼働に移行。バディの役割も終了する

• オンボーディングリストの自己管理

  • Notion に用意されたオンボーディングリストを個人ページにコピーし、タスクを「In Progress」「Done」などのステータスで管理。進捗がバディや他メンバーからも見える状態をつくり、サポートやフォローがしやすい環境を整えました。
  • 入社から1ヶ月を目安に全タスクを完了することをゴールとし、段階的に自立を促進します。
    Notion 上にある個人ページにてオンボーディングリストを管理する

得られた成果

• 既存メンバーの負荷軽減
  • オンボーディングに必要な情報（手順、FAQ、進捗リストなど）をすべて Notion に集約・整理し、質問対応や案内が属人的にならない「このページを見ればわかる」状態を実現。
  • 新入社員が自己解決できる場面が増えたことで、都度チャットで確認する負担が減り、既存メンバーは開発に集中できる時間が増えました。
• スムーズな立ち上がり
  • 段階的な稼働と毎日の夕会により、安心して業務に取り組める環境を整備し、早期に業務に貢献できる体制を構築。
• 知識共有の標準化
  • オンボーディングリストで進捗を可視化し、周囲からもサポートしやすい仕組みを用意。
  • ドキュメントを「信頼できる唯一の情報源」と位置づけ、暗黙のルールを排除することで、全員が同じ前提で業務に臨める状態をつくりました。

2. 運用負荷・オーバーヘッドの可視化 — 繰り返し作業を仕組みで管理する体制へ

MP チームでは、日々の運用業務やミーティング対応など、いわゆる「トイル（繰り返し発生し、自動化や仕組み化が可能で、本質的な価値を直接生まない作業）」が特定のメンバーに偏りがちで、気づかないうちに稼働可能時間が圧迫される課題がありました。

これらは、機能開発や改善活動の時間を奪うだけでなく、負荷が見えにくいことで改善が進みにくい構造的な問題にもつながっていました。

主な課題

• 運用負荷の偏りと属人化
  • 調査依頼や突発的な対応、定常的な運用業務が、特定のメンバーに集中しがちでした。
  • MP チームでは運用担当をラウンドロビンな当番制にしており、依頼が多い日に当番になると負荷が急増し、計画していた業務が後回しになりやすい状態でした。
  • 運用業務の巻き取りが個々の判断に任され、負荷の偏りがブラックボックス化していました。
• 稼働時間の可視性不足
  • ミーティングや採用面談などの時間が日々の計画に織り込まれにくく、見積もりとの乖離が発生しやすい状況でした。
  • 稼働状況がチーム外の関係者には伝わりにくく、協力や調整が後手に回ることがありました。

解決に向けた取り組み

こうした課題を解消するため、「運用負荷・オーバーヘッドを可視化する仕組みづくり」に取り組みました。

負荷の分布を透明化し、チーム全体で平準化や調整を進められる体制を目指しました。

主な施策と仕組み

• 定常業務の自動集計
  • Notion に運用依頼などの定常業務を記録するデータベースを構築し、依頼内容と件数を一元管理できる仕組みを整えました。
  • Slack で特定のスタンプを押すとオートメーションで自動的にデータベースに記録される運用を導入。
  • これにより、「どの作業がどれだけ発生しているか」をリアルタイムで可視化し、負荷の偏りを早期に発見・調整しやすくしました。
  • Notion のチャート機能で依頼件数や傾向を俯瞰し、定常業務の負荷分散に活用しました。
    チャートを元に調整や負荷分散
• 採用やミーティング時間の定量化
  • チームの稼働に影響する採用面談や定例ミーティングなどの固定予定（オーバーヘッド）を正確に把握するため、GAS スクリプトで Google カレンダーから全メンバーの予定を自動取得する仕組みを構築しました。
  • Notion のデータベースに稼働データを集計し、週ごとの稼働時間をチャートで可視化しました。
  • これにより、どのメンバーがどれだけの時間をミーティングなどに使っているかが一目で把握できるようになり、計画と稼働のギャップを明確にできるようになりました。
• 稼働時間を考慮した計画運用
  • スプリントプランニングの際に、ミーティングや採用の時間などのオーバーヘッドをあらかじめ稼働時間として計上する運用を取り入れました。
  • 稼働の見込みをチームで共有し、突発的な予定やタスクの追加があった場合も、Daily Standup などで随時バックログを調整しやすい仕組みを整えています。

得られた成果

• 運用負荷の属人化解消
  • 定常的な運用業務の時間や件数を可視化し、対応の分担をルール化することで特定メンバーへの負荷集中を防止しました。
  • 定期的に稼働の偏りを見直し、負荷に応じて運用や調査を柔軟に振り分ける運用を実現できました。
• 稼働の透明性向上
  • オーバーヘッドが可視化され、稼働状況をチームや関係者と共有しやすくなっています。
  • その結果、スプリント計画や稼働配分を現実的に調整できるようになり、協力や負荷分散も進むように。
  • 可視化したデータをもとに「どこに負荷が偏っているか」を共通認識として持てるようになり、改善の議論が活性化しました。
• 運用負荷の平準化
  • ミーティングや運用負荷の稼働データをスプリント計画に反映することで、「想定より時間が足りない」というズレを減らし、計画通りに進む割合や進行管理の安心感を向上させています。
• 計画の精度向上
  • 実際の稼働データを反映することで、「このタスクは終わるはずだったのに時間が足りない」というギャップを大幅に低減できました。
• トイル削減と自動化文化の醸成
  • 運用依頼などの定常業務の発生頻度をデータで把握し、「何が一番負担になっているか」をチーム全員で共有可能に。
  • このデータをもとに「どこから自動化に着手するか」の合意形成がしやすくなり、優先度を決めて着手できる体制を整備。
  • AIや各種ツールを活用し、実際に自動化を進めることで、継続的なトイルの削減を実現しています。

MP チームでは、こうしたトイルやオーバーヘッドを「見えないコスト」にせず、継続的に管理すべき重要な業務として捉え、仕組み化による負荷分散と改善を進めています。

3. リチーミング — 継続的改善を支える開発体制への転換

MP チームでは、メンバーの増加や施策の多様化に伴い、意思決定の遅延・認知負荷の増大・役割の不明確さが顕在化していました。

特に、短期プロジェクト単位（エピック制）の体制では、中長期的な改善やチームの成長を持続する仕組みを作るのが難しい状況が続いていたのが実情です。

こうした課題を受け、エピック制から恒常的なサブチーム体制へ移行（リチーミング）し、開発プロセスの標準化に取り組みました。

主な課題

• 短期性が生むナレッジの分断
  • それまでのエピック制では1～3ヶ月単位でエピックが終了し、開発の練度や専門性が都度リセットされていました。
  • 結果として、エピック間で知見が十分に共有されず、積み上げが難しい状況でした。
• 認知負荷と情報の不透明さ
  • PLE や TLE（Technical Lead Engineer）など、全体を俯瞰する立場のメンバーが特定のエピックに張り付いて個別対応に追われており、他のチームの状況が把握しづらい状態でした。
  • このため、組織全体の最適化や横断的な支援が進まず、レビューや意思決定の負荷が増大していました。
• リーダーの負担集中と責務の曖昧さ
  • エピックのリーダーが施策立案・進行管理・実装をすべて兼務し、業務負荷が偏っていました。
  • タスクアサインや意思決定の責任範囲が不明瞭で、進行に遅れが生じることも多くありました。
• 開発フローの不統一と属人化
  • エピックごとに開発の進め方やプロセスが異なり、新規メンバーの立ち上がり負荷が高い状態でした。
  • タスクの優先度や進め方に一貫性がなく、意思決定スピードが低下する原因になっていました。

解決に向けた取り組み

これらの構造的な課題を解消するため、恒常的なサブチーム体制への編成（リチーミング）を実施。

この取り組みでは、Heidi Helfand氏の著書『ダイナミックリチーミング』をチームで輪読し、考え方を全員で共有するところからスタート。理論をなぞるだけでなく、全体最適を目指しメンバー全員で議論を重ねるプロセスを大切にしました。
輪読会の様子

さらに、開発フローの標準化や共通ガイドラインの整備を並行して進め、継続的な改善とナレッジ蓄積を支える体制を目指しました。

主な施策と仕組み

• 4つのサブチーム体制への移行

  • チーム単位で中長期的に特定領域を担当し、専門性と責任を明確化するため、以下の4つのサブチームを設置しました。
    • ToC チーム
      • エンドユーザー向け機能開発・改善を担当
    • ToB チーム
      • 不動産会社向け機能開発・改善を担当
    • 変革型チーム
      • 競合優位を築くため、中長期的視点での革新的な施策の検討・推進を担う
    • Enabling チーム
      • 各チームが本質的な価値創出に集中できるよう、技術・組織両面から認知負荷と障壁を取り除く
  • この体制により、短期プロジェクトの解散で知識や責任がリセットされることを防ぎ、継続的に専門性を深められる仕組みを整えました。
  • Enabling チームは、PLE や TLE を中心に構成されており、他のサブチームに固定で属さず、全体最適を優先して横断的に関わる支援体制を確保しています。この編成により、組織全体の技術戦略の推進やナレッジ共有・育成支援を柔軟に行うことが可能になりました。
    

• スプリントイベントの標準化

  • チーム間の進行を共通化し、進捗共有や振り返りを効率的に行うために、Daily Standup や Planning / Review / Retrospective などのスプリントイベントを標準化しました。
  • 誰が参加しても同じ進行と期待値を共有でき、意思決定やナレッジの蓄積をスムーズにしています。

• 開発フローの整備

  • チケット作成から設計レビュー、実装、QA、リリースまで一連の流れを共通化しました。
  • ADR やリリースノートなどのプロセスを明文化し、新規メンバーも迷わず進める体制を整えています。

• 1on1 を活用した柔軟なリチーミング

  • チーム固定によるスキルの偏りや閉塞感を防ぐため、1on1 を通じてメンバーの志向や得意分野を把握し、希望や適切かを踏まえた上でチーム編成を検討しています。
  • 必要に応じてチームを柔軟に調整し、モチベーションと多様な経験の両立を支えています。

得られた成果

• ナレッジと改善活動の継続性
  • 恒常的なチーム編成により、技術的負債の解消や中長期的な振り返りを積み上げやすい土台が整いました。
  • チーム単位で課題や学びを継続的に共有し、改善サイクルを安定的に回せるようになりました。
• 意思決定のスピードと明確性
  • チームごとに裁量と責任が明確化され、日々の進行管理や意思決定がよりスムーズに。
  • 「誰が決めるのか」が明確になり、迷いや確認のコストが大幅に低減しました。
• コミュニケーションの透明化
  • 開発フローや意思決定プロセスを標準化したことで、情報の行き違いや認知負荷が軽減。
  • 他チームの進捗や取り組みが見えやすくなり、相互理解と協働が進みました。
• 負荷分散と持続可能性の向上
  • リーダーに集中していた施策立案・進行管理・実装の負担を分担し、チーム全体で支え合える体制になりました。
  • 個人依存を減らし、持続的に運営できるバランスが整いました。

MP チームでは、今回のリチーミングを単なる組織変更ではなく、「開発体制・プロセス・役割を標準化し、継続的改善を支える基盤を整える取り組み」と位置づけています。

今後も定期的な振り返りを通じて、さらなる最適化と改善を続けていきます。

4. 意思決定の透明化と責任の明確化 — 権限と情報の整理で迷わず動ける組織へ

リチーミングで開発体制を見直した後も、たとえば「Aさんしか知らない進め方が残っている」「意思決定の相談先が毎回変わる」「古い情報と新しい情報が混在している」といった問題に加え、誰が判断を下し、誰が責任を負うのかが曖昧なまま、認知負荷や調整コストが増大し、業務が遅れやすい状態が続いていました。

こうした課題は、AIを活用しても意思決定が加速しない根本原因となるため、権限と情報を整理し、迷わず動ける体制を整える必要がありました。

主な課題

• 意思決定とコミュニケーションの複雑化
  • 誰が意思決定をリードするのか、誰に判断を仰ぐのかが曖昧でお互いにお見合い状態となり、タスクや意思決定が滞ることがありました。
  • チーム目標設定プロセスでも、誰がどの部分でイニシアティブを取るのかが不明瞭で目標策定に時間がかかり方向性の齟齬が発生。
  • 関係者や相談先が不明確で、相談や進捗確認のたびに「誰に話すべきか」を探す必要があり、調整に多くの時間がかかっていました。
• 情報の散在と不文律の多さ
  • 必要な情報がチャットや口頭に埋もれ、古い解釈と混在することで、何を基準に判断すればよいかが不明瞭になり、意思決定の基盤が曖昧になっていました。
  • 業務の進め方や優先順位が暗黙のルールに頼らざるを得ず、「これで合っているのか」と都度確認が必要で、認知負荷が高まっていました。
• 属人化とボトルネックの発生
  • 判断や責任範囲が不明確な中、進行を止めないために特定メンバーがタスクを抱え込み、負担が偏り続けていました。
• 開発プロセスのばらつき
  • チームごとに開発の進め方が統一されておらず、新しい施策を始めるたびにフローを一から調整する必要があり、立ち上がりの負荷が大きくなっていました。

解決に向けた取り組み

こうした課題を解消するため、MP チームではドキュメントを信頼できる唯一の情報源（Single Source of Truth, SSoT）と位置づけ、情報共有と意思決定の標準化を徹底しました。

あわせて、業務の全体像を可視化し、責務と権限を明確化することで、認知負荷を減らし意思決定を加速することを目指しました。

これらの取り組みは、リチーミング後のサブチーム体制を支える土台であり、AIや仕組みを最大限活用するための前提条件と位置づけています。

主な施策と仕組み

• コミュニケーションガイドラインの策定
  • リモート中心の環境では「伝えたつもり」「わかっているつもり」が原因で、認識のズレや情報の抜け漏れが起こり、意思決定や進行が停滞しやすい課題がありました。
  • これを解消するため、コミュニケーションの基本ルールを明文化し徹底しました。具体的には以下のような取り組みを記載しています。
    • ローコンテクストコミュニケーションを徹底する
    • ミーティング前に目的・ゴール・アジェンダを共有し、全員が同じ前提に立てるようにする
  • これにより、認知負荷や確認コストが減り、誰もが迷わず動ける共通ルールが整いました。
    
• ドキュメンテーションガイドラインの整備
  • メンバーや施策の増加に伴い、情報の属人化や認知負荷の増大が深刻化していました。
  • 「どこに何が書いてあるか分からない」「手順や判断が人によって違う」ことが、業務の停滞や確認コストを生む原因になっていました。
  • こうした課題を解消するため、ドキュメントを信頼できる唯一の情報源（SSoT）と位置づけ、再現性のある知識共有と意思決定を支える仕組みを整備しました。
  • さらに、ドキュメンテーションは単なる負担ではなく、トイルを減らし組織を強くする「再現性のインフラ」と位置づけました。
    
• レポートラインの整備
  • チーム拡大や施策の増加で「誰に相談するべきか分からない」「判断を仰ぐ先が不明瞭」といった課題が発生していました。
  • そこで、「このテーマは誰に相談・報告するのか」を役割ごとに明文化し、開発・運用・方針決定それぞれの相談ルートを共通認識として定めました。
  • これにより、全員が「どこに情報を集約し、誰に相談すればよいか」が明確になり、調整や意思決定がスムーズになりました
    
• 業務整理表の整備
  • メンバーや業務の多様化に伴い、「誰がどの業務にどこまで責任を持つのか」が不明瞭になっていました。
  • そこで全てのロール（PdM・PLE・TLE・Team Lead・SWE・Designer など）を対象に、業務を棚卸しし、「アクション・重要度・関与インパクト・関与方針」の4軸で整理した共通の業務整理表を作成しました。
  • 各業務について「どのロールがどの程度関わるのか」「判断と実行の責任は誰にあるのか」を一目で分かるようにしたことで、進行や調整で迷う場面が減り、意思決定や相談のスピードが大きく向上しました。
• 権限設計表の導入
  • チームの拡大で「誰が最終的に決めるのか分からない」「判断を仰ぐ先が毎回変わる」といった課題が増え、意思決定が遅れがちになっていました。
  • そこで、各業務やテーマごとに最終意思決定者を明示する権限設計表を整備し、提案は誰でも行える一方で決定責任は役割に応じて明確にしました。
  • 一般的な RACI チャートではなく、シンプルで全員が理解しやすいフォーマットを採用したことで、相談・判断の流れが一貫し、判断スピードが向上しました。
• ODR（Organization Decision Records）の導入
  • 前述のような施策も重要な意思決定ですが、その経緯自体も属人化しやすく、「なぜその判断に至ったのか」を後から把握することが困難でした。
  • そこで、主要な判断や議論の過程を ODR としてドキュメントに残し、全メンバーが参照できる仕組みを整備。
  • この運用により、判断の背景や論点が透明化され、振り返りやナレッジ共有がスムーズに行えるようになりました。

得られた成果

• 情報共有と認知負荷の軽減
  • ドキュメントを「信頼できる唯一の情報源（SSoT）」と定義し、ルールやプロセスを明文化しました。
  • 不文律を排除し、全員が同じ前提で意思決定できる体制を構築。
  • 業務の進め方や役割分担を明確化し、迷いや判断の負担を大幅に軽減しました。
• 意思決定のスピードと精度の向上
  • レポートラインと権限設計を整備し、誰が何を決めるかを明確化することで、判断のリードタイムを短縮しました。
  • ミーティングもローコンテクスト・非同期コミュニケーションを徹底し、相談・判断のプロセスが平準化されました。
• 組織のメタ認知と継続的改善
  • ドキュメントやガイドラインを通じて、業務や意思決定を客観的に振り返る基盤が整備されました。
  • 定期的な振り返りが習慣化し、継続的な改善が進む体制ができています。
• 属人化の解消と開発フローの標準化
  • プロセスを標準化したことで、重複作業や属人的な進め方が減り、チーム間で一貫性をもって開発を進められるようになりました。
  • サブチーム体制を基本単位とすることで、中長期的な改善活動やナレッジの蓄積も進んでいます。
• リーダーシップとプロフェッショナリズムの強化
  • ロードマップ策定や進行管理、意思決定の役割を明確にし、各リーダーが高いオーナーシップを発揮できるようになりました。
  • 定期的な振り返りで目標達成の解像度とリーダーシップの質が向上しました。

終わりに — AI時代に「動けるチーム」をつくるために

最後まで読んでいただいてありがとうございます🙏

本記事では、局所最適を超えた全体最適を目指し、組織・意思決定・情報の仕組みを再設計してきた取り組みを紹介しました。

これらは一見、手間も時間もかかる取り組みです。しかし、AIの導入効果を最大化し、属人化に頼らず持続的に成長できる開発組織を築くためには、こうした土台づくりこそが重要な中長期を見据えた投資だと考えています。

同じように「AI活用を進めたいが、その前に組織の基盤が整っていない」と感じている方にとって、本記事が少しでもヒントになれば幸いです。

私たちもまだまだ道半ばで、組織やプロダクトの課題は尽きません。これからもよりよい仕組みを探究し続けていきます。

もし一緒にこうした挑戦を楽しみたい方がいらっしゃいましたら、ぜひお声がけいただければと思います！