『なぜ作るのか』を全職種で考える顧客志向組織へのアプローチ
2.8K Views
October 23, 25
スライド概要
"顧客価値"に向き合える仕組みづくりを、私たちがどのように進めているかをご紹介します。AIによって実装の効率化が進む今こそ、開発者が上流の意思決定や顧客価値の議論に主体的に関わることが、これまで以上に重要だと考えています。その前提のもと、顧客志向の組織を目指して私たちが行っている具体的な取り組みやアプローチをご紹介。
ツクリンク株式会社でEM2年生🐣 小売・人材業界でソフトウェアエンジニアとしての経験を経て、2022年にツクリンク株式会社へ入社。 2024年中旬よりエンジニアリングマネージャーに役割を変え、現在はサービス成長を担うチームで、エンジニアがより開発に集中し顧客と向き合える環境づくりやプロセス改善に取り組んでいます。
関連スライド
各ページのテキスト
『なぜ作るのか』を全職種で考える 顧客志向組織へのアプローチ 八尾 友基（@Tomoki____Y） ツクリンク株式会社 エンジニアリングマネージャー #開発生産性_findy
自己紹介 八尾 友基 Tomoki Yao ツクリンク株式会社 エンジニアリングマネージャー ツクリンクでエンジニアリングマネージャーをしております。サービス 成長を担う3チームを主に見ており、各チームが顧客に向き合える ような環境・仕組みづくり、そして開発に集中できる環境づくりを推 進しています。
ツクリンクについて
出発点 — ツクリンクの価値観「顧客思考」 「顧客思考」とは 問いを市場から定義 ヒントを顧客からもらう • 問いや課題を市場から定義し、ヒントを顧客からもらい、 解を自分たちで導き出す • そして市場から評価を受ける、というサイクルを回し続け る 市場から評価を受ける 自分たちで解を導く • 解を出すためのヒントは顧客にあり、数多くのトライ＆エ ラーを繰り返しチャレンジする • それぞれの役割における顧客を明確にし、顧客価値の 最大化を追求し続ける このツクリンクの価値観を体現していくという事を出発点に今日お話ししている取り組みを進めました 参考: ツクリンクの Origin
本日お話しする内容 本日は、"顧客価値 "に向き合える仕組みづくりを、私たちがどのように進 めているかをご紹介します。AIによって実装の効率化が進む今こそ、開 発者が上流の意思決定や顧客価値の議論に主体的に関わることが、こ れまで以上に重要だと考えています。その前提のもと、顧客志向の組織 を目指して私たちが行っている具体的な取り組みやアプローチを、良い点 も課題も含めて率直にお話しします。
以前は縦割り構造で開発 当時の私たちは、PdMが要件をまとめてデザイナーに渡し、デザインはPdMとの往復で完成させます。 完成したデザインをエンジニアに共有し実装。実装が終わったらQAに渡し、確認後にリリース、という直列の引き継ぎを行う開発を行っていました。 1 2 3 4 5 PdM 要件定義とプロダクトの方向性を策定し、デザイナーへ引き渡し Designer PdMと連携し、要件に基づいたUI/UXデザインを作成 Engineer デザインと要件に沿ってシステムを実装 QA 実装された機能の品質検証とテストを実施 Release 検証完了後、市場への提供
何が起こるのか 3つはバラバラに起こることではなくつながっている事象です 1 『なぜ作るのか』が希薄化する 直列の受け渡しと工程ごとの部分合意で、背景が細切れに伝わり 『なぜ作るのか』 がぼやけます 『要件どおり作ること』が目的になる 2 3 1に加えやり取りが成果物中心になる為、顧客の事を考え提案する心理的ハードル高い。その為 『要件どおり作ること』がゴール になりアウトカム志向が弱まる 『手戻り』が発生する 『なぜこの様にしているのか』がぼやけている為、前提のズレ や言葉の定義の違いが後で表面化して『手戻り』が発生する この構造が結果として、顧客価値に向き合いづらい状態 を生んでいた。
解決策 — 職能横断チーム One Teamの構造 チームのあり方（ One Team） ・固定メンバーで同席・同時に関与（PdM/Design/Eng/QA） ・背景・目的は “チームの責任”として握る QA PdM 共通目的 ・“指摘”ではなく“共同設計”を前提にスタート 期待する効果 ・“何のため？”が同じ言葉で語られる（会話の土台がそろう） Engineer Designer ・手段の議論が目的に回収される（要件＝ゴール化を防ぐ） ・前提ズレを前段で発見・解消（後工程の驚きを減らす） ・顧客の文脈で語れる時間が増える（顧客像／行動変化が会話の中心）
開発着手までの運用 持ち込み方 新規／改善の要求が上がったら、リファインメントで扱う。必要に応じて臨時のリ ファインメントを追加。事前準備は厳密化しない（「何を・なぜやりたいか」を話せ る状態でOK） 同席でそろえる項目 • 背景／目的 • 要求／要件 • 完了の定義（全員が実装に入れる・理解できる解像度まで） • （必要に応じて）影響範囲・依存 記録 合意した内容と理由、関係者、完了の定義、影響を記録。変更が出たら同じエ ントリを更新（経緯を追える）
一度目は失敗した。だから再定義してやり直した 現場からの声 「職能横断に “形だけ ”変えたけど、やってることは前と同じ。正直、やる意味が感じられない。」 なぜ起きたか 『なぜやるのか（目的）』が伝わらなかった : 始動時の説明が HOW中心で、チーム全体に目的意識が浸透しませんでした。 運用を任せっきりにした : 任せっきりにしてしまったことで目的が形骸化した。 結果として “形だけ横断 ”の状態に陥いった。 再定義してやり直したこと 目的の明文化と共有 : 本日お話ししている様にこの職能横断チームは何の為に実施するのか明文化した HOWの具体化 : 具体的なプロセスを示し、チームが道を見失わないようにサポート（ただし、進めながらの改善は推奨） 全スクラムイベントへの参加と模範行動 : 私が全てのイベントに参加し、必要に応じて目的に沿った模範行動を率先して示す 行動で「本気」を示す :「本気でやり切る」を行動で示し、自分が最初の “良い例”となることを継続しました。 構造を本気で変えるには、時間と体力を投じて、自分が並走して示すことが不可欠です。それがないと、やはり変革は難しいと痛感しました。
アンケートの実施 位置づけ（Why） 目的：チームの手応えを可視化し、継続判断と改善ポイントを抽出する 対象・時期 対象：Featureチームの全職能（PdM／Design／Eng／QA）時期：再始動から約3ヶ月後 設問構成（セクション） 1 協業しやすさ／役割の壁の低減… 2設問 2 情報共有と意見交換のしやすさ… 2設問 3 意思決定のスピード／合意の取りやすさ… 2設問 4 多様な視点／新しい発想の生起… 2設問 5 個人の成長・モチベーション… 2設問 6 価値提供スピード・満足度・継続意思… 5設問 スケール：5段階リッカート（1=まったくそう思わない 〜 5=とてもそう思う）
アンケート結果サマリー 観測された事実（自由記述・抜粋） ● ● ● 「なぜこの施策を実施するのか？」、「ユーザーにとって何が嬉し いのか？」を話せるので、よりプロダクトのことを考えて開発がで きていると感じる 共通認識を持ちやすく、変化への対応（意思決定）が早くなってい る スケジュールに沿って作るだけの感覚は無くなった 見えてきた課題 個人の成長・モチベ（ 3.88）： 手応えはあるが伸びしろが残る 価値提供・満足度・継続意思（ 3.65）： 価値の実感・指標の捉え方にばらつき
"顧客価値 "に向き合うためのユーザーストーリー再設計 狙い：WHY（価値）を主語にし、向き合う度合いを上げる 課題（3ヶ月アンケ）：⑤モチベ（達成感）=3.88／⑥価値の実感=3.65 Before（技術で分割） After（ユーザー価値で分割） • UIコンポーネント作成 ※仮想機能：☆お気に入り • API作成 • DBテーブル作成 → 価値としては未完成。全部そろうまで達成感が得づらい ストーリー A：登録できる ユーザー（Who）は「お気に入りに登録」したい（ What）。それは後から素早く見返すため（ Why）。 完了の定義：任意のアイテムで☆を押すと登録済みになり、再読み込み後も保持される ストーリー B：一覧で見える ユーザー（Who）は登録済みを一覧で確認したい（ What）。それは関連アイテムをまとめて扱うため（ Why）。 完了の定義：マイページの「お気に入り」に登録済みが一覧表示（並び・件数の初期仕様を含む） ストーリー C：解除できる ユーザー（Who）は不要になった登録を外したい（ What）。それは一覧の鮮度を保つため（ Why）。 完了の定義：一覧／詳細で☆を外すと即時反映し、一覧からも消える（再読み込み後も一致） 参考記事： 『タスク分割』から『価値分割』へ。ユーザーストーリー改善に取り組み始めた話
良いユーザーストーリーの基準 INVEST原則に従いチームが迷いなく開発を進められ、価値意識したストーリー構成を目指す 1 2 Independent（独立） Negotiable（交渉可能） 他のストーリーに依存せず、単独で開発・リリースが可能 詳細を固定せず、チームで議論・調整できる 3 4 Valuable（価値） Estimable（見積可能） ユーザー/ビジネスにとって明確な価値がある（機能説明に堕ちない） チームが規模を見積もれる 5 6 Small（小さい） Testable（テスト可能） 1スプリント（数日〜2週間）で完了できるサイズ 完了を客観的に判定できる（受け入れ条件＝完了の定義） アンチパターン（外し所の例） • Who/What/Whyが「UIを…」「APIを…」など技術記述にすり替わっている • 完了の定義が"実装完了"止まりで、観測可能な状態変化がない • 複数の前提や依存がないと成立しない（＝独立していない） テンプレ（各ストーリーの先頭に置く） Who/What/Why：「〈誰が（Who）〉が〈何をしたい（What）〉。それは〈なぜ（Why）〉。」 完了の定義：「○○の操作 → 目に見える状態変化／保持条件。再読み込み後も一致。」
現場で生まれ始めた行動 構造を変えた事で "顧客価値 "に向き合う行動が生まれ始めている！ ディスカバリー活動がチーム主導で実施 チーム主導で顧客価値の探索が必要 と判断し、活動を開始 ユーザーインタビュー と小さな仮説検証を反復して学びを獲得 デュアルトラックアジャイル の実践に挑戦し、運用へ定着させる 施策案がエンジニア側からも出始めた 「この施策で体験がもっと良くなるのでは？」 という提案が増加 「作れる価値」単位 での段階リリース／分割提案が自発的に発生 例:「A→Bの順で価値を立てれば、より早くユーザーに届くのでは？」 データを見る習慣が芽生えた 変更前に「何をもって良しとするか」 をディスカッション（指標／観察ポイント） 利用状況ダッシュボードを日々チェック し、開発の効果に当事者意識を持つ 観測した変化点を次の議題／仮説 として即座に取り上げる
AI時代は、「顧客価値に向き合うための構造」が大事に なる いまの時代との関係 AIで実装が加速 → 上流（Whyの明確化／ディスカバリー）の重要度が相対的に上がる 結果として AIは「何を」加速させるかを問い続けます。私たちが築いた 「顧客価値に向き合うための構造」 こそが、そ の問いに最速で答えを出し続けるための土台となります。 今回の転換 （要点） 土台を支える「 3つの実践」 ［Before］ Whyの合意 : 常に「なぜ/誰のためか」から議論をス ・構造 How中心 : 「どう作るか」が主語だった タートする ［After］ ・Why先行の土台 : 「なぜ作るか」を全員で問え る 構造へ転換 価値の分割 : 「Whyを検証できる最小単位」で素早く 届ける 変化の観測 : 届けた結果（変化点）を観測し、次の 「Why」に活かす
まとめ 『構造を変えれば、行動は変わる。』 本日の学びはシンプルです。 行動は意思ではなく、 構造がつくる ものです。 構造を設計し直せば、会話が変わり、決め方が変わり、やがて習慣が変わり文化になりま す。 構造の更新は楽ではありません。時間も体力も必要です。 それでも、変化を起こしたいときは一度、構造に目を向けてください。 それが文化を変える 最短路 です。
JOIN US 情報発信していますので是⾮ご覧ください 現在転職を考えていなくても構いません まずはカジュアルにお話ししてみませんか？ ご興味をお持ちの⽅は下記からご連絡ください お会いできることを⼼からお待ちしております テックブログ 採⽤情報
ご清聴ありがとうございました！ 八尾 友基（@Tomoki____Y） ツクリンク株式会社 エンジニアリングマネージャー #開発生産性_findy