2023XP祭り_Pair Production

２つの開発チームが同じプロダクトを別々に作成し、 ステークホルダーやPOの帽子もかぶりながら成長した話 小泉 岳人、奥田 真史、竹原 武志、市橋 祐輝

目次 はじめに １．はじめに ２．チームの状態と成長につながるエピソード ３．EP1：POとの越境 ４．EP2：開発者×ステークホルダーでの越境エピソード ５．EP3：デザイナー×開発者での越境エピソード ６．おわりに 1

はじめに はじめに 2

はじめに 本日の概要とラーニングアウトカム ・プロダクト作成に関して越境の重要性やポイント、 越境するためのマインドについて理解できる 3

自己紹介 はじめに 小泉 岳人 ニッセイ情報 テクノロジー株式会社 趣味：コントラバス 奥田 真史 (株)アートテクノロジー 趣味：PCゲーム 竹原 武志 （株）ソラマス・ ソフトウェア・サービス 趣味：読書 市橋 祐輝 Sasuke Financial Lab いちはし 株式会社 趣味：CG 4

はじめに InsurTech Labとは 5

はじめに InsurTech Labとは 社内 アジャイル展開 デザイン思考 仮説検証 コンサル PO PO プロダクト 作成1 プロダクト 作成2 プロダクト 保守 PO Dev Dev Dev 数名 SM SM SM コーチ コーチ コーチ PO Dev 数名 Dev 数名 SM SM コーチ 6

はじめに InsurTech Labとは アジャイル展開 デザイン思考 仮説検証 コンサル PO PO PO 社内 プロダクト 作成1 プロダクト 作成2 開発者 プロダクト 保守 PO Dev 開発者 Dev Dev 数名 SM SM SM コーチ コーチ コーチ PO Dev 数名 SM Dev 数名 デザイナー SM コーチ 7

はじめに 本日説明するプロジェクト＆プロダクト Lab‐SS（Sales Solution）※仮称 ・保険をWebダイレクトで申込むための一連のシステム ・AWS Amplify StudioとUnqorkという２つのローコードで別々に作成 ・ドアノックツールとして、保険会社様にアーキテクチャ・アジャイル・ 仮説検証の重要性及びローコードアーキテクチャの内容を伝えられる ソリューションとして構築 ⇒爆速で開発＆検証ができる 8

はじめに 本日説明するプロジェクト＆プロダクト AWS-Amplify Studio ・Webアプリケーションを 支援するフレームワーク ・デザインツールである Figmaからコード生成し、 デザイン駆動で開発可能 PO Dev 数名 Dev 数名 SM SM Unqork ・インフラまで含めた SaaSサービスとしての ノーコードツール、GUI ベースで開発ができ、数 日でリリース可能 9

はじめに 本日説明するプロジェクト＆プロダクト ソリューション動画 画像 10

はじめに 本日説明するプロジェクト＆プロダクト スケジュール 立ち上げ 第１段デモ 資料作成 プロダクト オープン チーム 再編成 11

はじめに 本日説明するプロジェクト＆プロダクト AWS-Amplify Studio Unqork 開発チームとして モノ作り ステークホルダーとして 相手チームにフィードバック 12

チームの状態と成長につながるエピソード チームの状態と成長につながるエピソード 実際にアンケートをとってみて 13

チームの状態と成長につながるエピソード ８月にメンバーに対してアンケートを実施 80%以上が「満足」、「過去のプロジェクトと比べて成長を実感できた」と回答 満足度 47.1% 35.3% とても満足 やや満足 29.4% 成長度 とても成長できた 58.8% やや成長できた どちらでもない どちらでもない やや不満足 あまり成長できなかった とても不満足 全く成長できなかった 14

チームの状態と成長につながるエピソード 成長できたと思えたポイント/要因 ・グループからチームとしての一歩を踏み出せた感覚があった ・「自分の思いを伝えて、よく考える」という習慣ができたことで、自分の 思いがパッとでるようになった　 ・プロダクト価値について、お互いのデモンストレーションを発表し合うことで、 重視するポイントの違いを意識できた。 一方のステークホルダーに他方がなるという進め方が大変刺激的であった ・デザイナーとして開発メンバーに混ぜてもらい、一緒に手を動かす経験ができた ・自分たちの作業プロセスの効率化自体に成功したこと ・スキルシェアの文化があり、教え合うことができモチベーションになった 15

チームの状態と成長につながるエピソード 成長の要因はマインドの越境が大きかった ・POからのゴールの設定を待っていた働き方から、 主体的なゴールを置く働き方に変わり、POとの壁を 越境した ・自分自身がステークホルダーとしてプロダクト価値に 向き合う事で、開発者とステークホルダーの壁を 越境した ・作業プロセス効率化に向けて開発者としての 効率化を考えていたがデザイン含めたチーム全体を 主語にして考えた(開発者×デザイナーの越境) 16

チームの状態と成長につながるエピソード 3つのエピソード紹介 EP1. POとの越境 開発者自身がゴールを立てたエピソード EP2. 開発者 x ステークホルダーとの越境 お互いがチームのステークホルダーになって取り組んだエピソード EP3. 開発者 x デザイナーの越境 開発者とデザイナー間のコラボエピソード 17

EP1 : POとの越境 EP1 : POとの越境 ゴールは開発者で作れ！ プロダクト価値を現場から高める簡単な方法 18

EP1 : POとの越境 開発者自身でゴールを作ることの難しさと面白さ ・POが初版作成のインセプションデッキを見ながら 開発者自身がゴールを検討し、POと議論した ・ゴール作成は未経験で難しかったが、 このことが後のスプリント活動に良い効果を与えた 以下では、ゴール作成の背景と効果について説明する 19

はじめに EP1：POとの越境 背景 20

EP1 : POとの越境 1つのプロジェクト、2つのプロダクト実装 ・「Amplify」「Unqork」を使った2つのプロダクト実装あり ・2つのツール特性を十分に生かしたプロダクト開発をしたい ローコードツール ノーコードツール 21

EP1 : POとの越境 「その開発なら大体わかりますよ」 ・数ヶ月前にPoCを実施済み ・作るプロダクトの見た目も似ているようだ（これは余裕ですね） 22

EP1 : POとの越境 「さぁ、やりたいようにゴール設定して」 POが立てたゴールを開発メンバーに提示 これをやりたいように ゴールを変えてね」 ん？POが作ってくれると思ってた… ところで、私のやりたいこ とってなんでしたっけ？ 23

EP1 : POとの越境 EP1：POとの越境 うまくいかなかった施策 24

EP1 : POとの越境 やったこと ・「今から5分タイマーかけるのでゴール書いて」で意見を募る （よくわからないので、とりあえず意見を聞いてみよう） ・集まった意見を多数決で選択する （聞くだけ聞いて削り落とす） 25

EP1 : POとの越境 その結果… ・開発者間の共通認識を合わせないまま意見を募ったので、 目指したい先がバラバラで混乱 ・目指したい先ではなく、いま思いついたタスクが目的になりがち。 → プロダクトの根本となるWHYを問わないままのため、 このプロダクトとして何をすべきかが分からないままになる 26

EP1 : POとの越境 EP1：POとの越境 うまくいった施策 27

EP1 : POとの越境 やったこと ・開発者間でなぜそのような差分が生じたのか議論する ・タスク＝「やること」しか見えてこないのならば、 そこから「どのようにやりたいのか」「なぜそれをやりたいのか」 と遡り、根本となるWHYを見つけにいく なぜそれをやりたいのか どのようにやりたい やること 28

EP1 : POとの越境 その結果… ・プロダクトの方向性が明確になり、開発者間で共通理解を得た ・何のためにやるのかを起点とした目先のタスクではない ゴールを検討できた → WHYを明確にしたのでゴールが立て易くなった → 場当たり的ではなくやり切った、プロダクトにより思いを 込められたという感覚も得られた 29

EP1 : POとの越境 ゴール検討で副次的に得られたもの ・プロダクトの価値や良いところはどこか？をずっと考え続ける という行為が、開発者自身をポジティブなマインドにした ・スプリント中、自分たちの行動でゴールに近づいているかを意識する 前よりも何事もよく考える癖がついてきた ・自分たちがやりたいと思ったことなので、 多少困難であっても高いモチベーションで取り組む 30

EP1 : POとの越境 以前の開発と違うのはどこだろう？ before POは特別枠（怖い） 如何に正確に最後まで見通し た指示をするかが寛容 （ChatGPTみたいにね） ゴールは降りてくるもの POのお言葉を理解する POが想定した風の プロダクトができる PBIを効率よく消化し、 （想定を超えてこない） 不明点は即座にPOに聞く after POもチーム（怖くないよ） ゴールは自ら考えるもの 深掘りし過ぎて迷子になる開 発者に外からの視点を。 プロダクトの価値を考える プロダクトを一緒に考える POも予想外の プロダクトが生まれる （かもしれない） ゴールへの挑戦、 迷ったらゴールを道標にする 31

EP1 : POとの越境 開発者がゴールを立てるということ ・開発者にゴールを刻み込み、自分ごとにする儀式である 良いゴールを立てることはもちろん重要なのだが、 それ以上に開発者自身が納得して立てたことが大事 ・この儀式によって、開発者はプロダクトに興味を持ち、 ゴール自身やプロダクトの価値を強く意識する → プロダクトの価値を高める努力、継続的な改善の燃料になる 32

EP2 : 開発者×ステークホルダーでの越境 EP2 : 開発者×ステークホルダーとの越境 開発者がステークホルダーの アウトカムを意識できるようになるまで 33

EP2 : 開発者×ステークホルダーでの越境 ① 自身がステークホルダーとして どう振る舞えばよいかを考えた話 ② ステークホルダーに対して どんな価値があるのかを考えた話 34

EP2 : 開発者×ステークホルダーでの越境 POからのメッセージ 「スプリントレビューではお互いステークホルダーとして振る舞ってください」 お互いが 開発者でステークホルダー となり、意見を出し合う 35

EP2 : 開発者×ステークホルダーでの越境 開発者として 開発中に困ったことや詰まったことを共有したり、 悩んだデザインや機能を話し合うことはできた ステークホルダーとして どう振る舞って良いかわからない 36

EP2 : 開発者×ステークホルダーでの越境 ステークホルダーとして振る舞うために 他社事例をチームで分析 37

EP2 : 開発者×ステークホルダーでの越境 どんなことをしたのか？ １．チームメンバーが各自で他社の類似画面フローを操作 ２．良い・悪いの気づきを書き出す ３．チーム内で共有 38

EP2 : 開発者×ステークホルダーでの越境 出た気づきの紹介 ・生年月日入力が3つに割れている ・月を選択したら日の選択にすぐに移ってくれる ・文字が小さく説明が多く、難しい印象を受ける ・PR,header,footerが大きく邪魔 ・性別、生年月日、保障の選択までは分かりやす くて良かった 39

EP2 : 開発者×ステークホルダーでの越境 何を知った？ ・デザインや必要な機能の解像度が上がった ・自分が利用する場合に感じること(=エンドユーザーとして感じること) ・他人が作ったものなので良くも悪くもズバズバ意見が出る 40

EP2 : 開発者×ステークホルダーでの越境 あるスプリントの話 スプリント期間は前回のスプリントレビューまでもらったフィードバック の取り込みや開発環境の改善を実施していた スプリントは順調に進んでいた スプリントレビューの準備を始めるとフィードバックをもらいたい作業や 成果物がなかった 続く 41

EP2 : 開発者×ステークホルダーでの越境 スプリントレビューの時に事件発生 とはいえスプリントレビューがあるので何か成果物を出さないといけない フィードバックをもらわないといけない そんな考えで過去にフィードバックをもらったものに少し改善を加えてい たのでフィードバックをもらおうとスプリントレビューに持っていった とりあえず修正したので、 フィードバックください！！ 42

EP2 : 開発者×ステークホルダーでの越境 フィードバックを求めると意見は出るものの、仮説をもって 臨まないと評価できない ○○の欄が大きい方 が使いやすい 見た目を▲▲にした 方が好み □□のチェックが あった方が良い ⇒ 開発初期であれば役に立っても、改善した事にともなう フィードバックとしては使えないものが多かった 結果、スプリント レビューを中断した 43

EP2 : 開発者×ステークホルダーでの越境 何がダメだった？ ・作ったものを見てもらい、意見をもらうことが重要になって、 なんのためにフィードバックをもらうのかを考えられていなかった ・意見を募るとさまざまな意見が出るが、何を優先すべきかの軸を 持てていなかった ・改善しないよりはした方が良いとなる （狩野モデルの品質種類を意識できていない） ※「当たり前品質」や「無関心品質」を 充足させつづけても仕方がない 44

EP2 : 開発者×ステークホルダーでの越境 EP2：開発者×ステークホルダーとの越境 思考の変化 45

EP2 : 開発者×ステークホルダーでの越境 アウトプット思考 言われたものを作る、実施することを考える PBIがあって、優先順位が決まっていて、優先度の高いものからを作る 作ったものをスプリントレビューで見てもらう 46

EP2 : 開発者×ステークホルダーでの越境 アウトカム思考 ステークホルダー側に立って考える。作ったものがステークホルダー にどんな効果や価値があるのかを考える ・誰にとっての価値なのか？ ・こんな使い方をするからこんなデザインにしたほうが良いのでは？ ・こういう機能にしたほうが良いのでは？ ・なんでこれが必要なんだっけ？ 重要 ・なんのためのフィードバックが欲しいのか？ 47

EP3 : デザイナー×開発者での越境 EP3 : デザイナー×開発者での越境 開発・デザイン協働でVSM分析した結果 ボトルネック箇所の手戻りを9割削減できた 48

EP3 : デザイナー×開発者での越境 課題と背景 FigmaからAmplifyへ変換する度に 長い手直しが必要 49

EP3 : デザイナー×開発者での越境 AWS Amplify Studioとは AWS Amplify AWSの提供するローコード開発ツール Amplify Studio デザインデータからコードへの変換ツール 50

EP3 : デザイナー×開発者での越境 リードタイム短縮に当たり、 FigmaとAmplifyの連携に課題感があった デザインデータそのままでは正しく読み込まれない 何度も試行しては手直しをする作業が必要で時間がかかる Figmaデータ Amplify同期 （数十秒待ち） エラーでReject （箇所は不明） Figma修正 しらみつぶしに確認 Amplify同期 繰り返し 51

EP3 : デザイナー×開発者での越境 だめだった施策 デザイン制作にAmplify対応を 盛り込もうとした 52

EP3 : デザイナー×開発者での越境 Figma作業が 二度手間になっている という仮説 デザイナーが作成したFigmaデータを エンジニアがAmplify用に作り直していた 最初からAmplify連携を想定して デザインを制作すればいいのでは？ 53

EP3 : デザイナー×開発者での越境 だめだった 画面構成とAmplify向け構成、SPとPC共通のレイヤー構成など... 同時に想定しながら作業すると、余計にリードタイムが悪化 54

EP3 : デザイナー×開発者での越境 うまくいった施策 VSMでボトルネックをあぶり出し、 問題箇所を自動化した 55

EP3 : デザイナー×開発者での越境 ワークフローの中で本当の問題点を探す VSM分析でデザイン〜開発までの中で ボトルネックとなっている箇所を探した 56

EP3 : デザイナー×開発者での越境 Figmaアドオン開発で 問題箇所を自動化 特に作業負荷の高い SP・PCレイヤー構成の共通化を 自動でチェックするツールを開発 57

EP3 : デザイナー×開発者での越境 結果 手戻りを9割削減できた 58

EP3 : デザイナー×開発者での越境 今まで10回必要だった作業が1回になった 自動チェックで、Amplify取り込み前に修正 従来のフロー Amplify同期 （数十秒待ち） エラーでReject （箇所は不明） 変更後 アドオンで自動チェック （1秒以内） しらみつぶしに確認 Figma修正 Amplify同期 繰り返し 修正箇所特定 Figma修正 Amplify同期 59

EP3 : デザイナー×開発者での越境 切り分けても問題はなくならない チーム全体で負担箇所を探すことが重要 隣接する担当箇所をまとめれば効率化すると思っていた 見直してみると、負担の原因は別のところにあった 60

おわりに おわりに 61

おわりに なぜ、越境できたのか？？ １．ゴール（価値）を考えるスキル ２．モブワーク中心 62

おわりに １．ゴール（価値）を考えるスキル これらのゴールを定義することは難 しいが、各種イベントやスプリント の都度、設定することでゴール設定 のスキルが高まっていった プロダクトの 価値 ステークホルダー の価値 チームの 価値 自分の 価値 63

おわりに 仮説キャンバス インセプションデッキ スプリントゴール ユーザーインタビュー スプリントレビュー準備 プロダクトの 価値 チームの 価値 ステークホルダー の価値 自分の 価値 ゴールデンサークル ⇒ゴール・価値を追求することで「越境」マインドが育つ 64

おわりに ２．モブワーク中心 ⇒モブワークで「協働」に慣れると、「越境」マインドが育つ！ 65

おわりに チーム全体 ・一員である ・共に取り組んでいる ・互いの作業、成長、学習をサポートする 役割 成熟したXPチームでの役割は一定ではない。目標は チームの成功のために全員が最善を尽くすことである 66

おわりに 今回のXP祭りで、一緒のチームで働いている 複数会社のメンバーで「越境」をテーマに 登壇できたことは、本当に嬉しいです！！ メンバーの皆、話してくれてありがとう 聞いてくれた方、ありがとうございました！！ 67