社内受託開発からの脱却〜考える人と作る人の壁を越えるためのアプローチ〜

by いっしー

Slide 1

Slide 1 text

社内受託開発からの脱却考える人と作る人の壁を越えるためのアプローチいっしー@RSGT2025

Slide 2

Slide 2 text

自己紹介石毛琴恵（いっしー）所属：人生の休暇中 WEB系エンジニア→SM→EM→アジャイルコーチ furoshiki.fm の茶髪担当 #furoshiki_fm @oturu333

Slide 3

Slide 3 text

なぜ社内受託開発を脱却したいか

Slide 4

Slide 4 text

なぜ社内受託開発を脱却したいか良いものを作りたいから！

Slide 5

Slide 5 text

なぜ社内受託開発を脱却したいか良いものを作りたいから！ユーザーの困りごとを解決し、プロダクトを利用していただく

Slide 6

Slide 6 text

なぜ社内受託開発を脱却したいか良いものを作りたいから！ユーザーの困りごとを解決し、プロダクトを利用していただくビジネスにも貢献できる

Slide 7

Slide 7 text

本資料における社内受託開発の定義自社開発において「作る人」がユーザーの困りごとを理解しないまま、社内の「考える人」から依頼されたものを作っている状態考える人作る人あとはよろしく！オーライ！

Slide 8

Slide 8 text

本資料における社内受託開発の定義自社開発において「作る人」がユーザーの困りごとを理解しないまま、社内の「考える人」から依頼されたものを作っている状態考える人作る人あとはよろしく！オーライ！果てしなく高く見える壁

Slide 9

Slide 9 text

社内受託開発で発生する問題より良いアイデアが隠れる作る人の知識による、より良い（あるいは簡単な）実現方法があったとしても反映されない。機能が大きくなり、リリースが遅くなる本来であれば、どんな困りごとを解決したいかでスコープが決定するが、作るものだけを見ていると「これもあれも必要では？」と大きな機能に成長しがち。作る人のモチベーション低下「作る理由が分からない」のに「作ったものが使われない」状態が続くと、作る人のモチベーションが下がる。

Slide 10

Slide 10 text

社内受託開発の脱却とはアイデアを出し合う考える人、作る人で協働することで、より良いアイデアを出し合う。ゴールを定めスコープを設定する困りごとをベースにゴールを設定し、そのゴールを達成するために最低限必要なものは何かという視点で、スコープを設定する結果、作る人のモチベーションが上がる作る人も作る目的を理解し、ゴール達成のために何をするべきか考える。リリース結果を振り返り、次の行動につなげる。モチベーションを高く維持できる。

Slide 11

Slide 11 text

社内受託開発、脱却したい！！

Slide 12

Slide 12 text

自社開発において「作る人」がユーザーの困りごとを理解しないまま、社内の「考える人」から依頼されたものを作っている状態考える人作る人あとはよろしく！オーライ！脱却する方法を考えた果てしなく高く見える壁

Slide 13

Slide 13 text

自社開発において「作る人」がユーザーの困りごとを理解しないまま、社内の「考える人」から依頼されたものを作っている状態考える人作る人あとはよろしく！オーライ！なぜこうなる？脱却する方法を考えた果てしなく高く見える壁

Slide 14

Slide 14 text

自社開発において「作る人」がユーザーの困りごとを理解しないまま、社内の「考える人」から依頼されたものを作っている状態考える人作る人あとはよろしく！オーライ！なぜこうなる？ドキュメント脱却する方法を考えた果てしなく高く見える壁

Slide 15

Slide 15 text

考える人自社開発において「作る人」がユーザーの困りごとを理解しないまま、社内の「考える人」から依頼されたものを作っている状態作る人あとはよろしく！オーライ！なぜこうなる？ WHY 解決策ドキュメント脱却する方法を考えた果てしなく高く見える壁

Slide 16

Slide 16 text

WHYの記載はあるが、理解ができない！理解ができないときのアクションが難しい。脱却する方法を考えた

Slide 17

Slide 17 text

WHYが「ユーザーに良い感じに使ってほしいから」では、実際はなぜ作るか分からない… 自分も、良い感じに使ってほしいとは思っているが。脱却する方法を考えた WHYの記載はあるが、理解ができない！理解ができないときのアクションが難しい。

Slide 18

Slide 18 text

WHYは、考える人がユーザーの何かしらの困りごとを知っていて、その困りごとから考える人個人の思考プロセスを経て生み出されたもの。壁の向こうが見えない中でのWHYへの言及は、職能や個人の思考プロセスの否定にならないか。どう聴いたら否定と捉えられず、コミュニケーションができるのか。 WHYへの疑問を伝えて期待した返答が返って来なかった場合、たぶん何度も疑問を伝えるのは、気を使ってしまう。脱却する方法を考えた WHYの記載はあるが、理解ができない！理解ができないときのアクションが難しい。 WHYが「ユーザーに良い感じに使ってほしいから」では、実際はなぜ作るか分からない… 自分も、良い感じに使ってほしいとは思っているが。

Slide 19

Slide 19 text

考える人を否定せず WHYを考える人と作る人で理解できる脱却したときの状態難しい…

Slide 20

Slide 20 text

考える人と作る人が、なぜ・何を作るかを一緒に考える考える人作る人一緒に考えればこんな問題は起こらないね！脱却方法作る人

Slide 21

Slide 21 text

そうは思っていても壁の向こうからドキュメントが到着する考える人作る人あとはよろしく！ちょっと待って〜！ドキュメント果てしなく高く見える壁 WHY 解決策

Slide 22

Slide 22 text

WHYから一緒に考えたいけどどうしたら良いのかな…

Slide 23

Slide 23 text

月日が流れ、とあるPJに関わることになった

Slide 24

Slide 24 text

とあるPJでのできごと開発者 PdM デザイナーコーチ

Slide 25

Slide 25 text

とあるPJでのできごと PdM デザイナーはじめまして〜コーチ開発者

Slide 26

Slide 26 text

機能A 機能B とあるPJでのできごと PdM デザイナー機能ロードマップコーチ開発者

Slide 27

Slide 27 text

機能A 機能B とあるPJでのできごと PdM デザイナー機能ロードマップ開発を依頼コーチドキュメント開発者

Slide 28

Slide 28 text

機能A 機能B とあるPJでのできごと PdM デザイナー機能ロードマップドキュメント開発を依頼コーチ WHY UI 表示項目 MUST/WANT 開発者

Slide 29

Slide 29 text

機能A 機能B とあるPJでのできごと PdM デザイナー機能ロードマップ開発を依頼コーチドキュメント開発者

Slide 30

Slide 30 text

開発者（作る人）が考えたことこの機能を作る目的がドキュメントだけではまだ理解できない。もっと理解して開発をしたい作るなら、ユーザーに使ってもらえる機能にしたい頼まれたものを作るだけではなく、関係者とコミュニケーションを取りながら開発がしたい

Slide 31

Slide 31 text

なぜ開発者（作る人）はそう考えたか社内受託開発のプロセスで実装した機能がユーザーに使われなかった経験があるからなぜ作るかを理解しないまま作り、その機能が使われなかった。使われなかったが、どのような問題があったのか分からないままでいる。機能はもっと改善ができたかもしれないが、分からない。現在のものの作り方にどのような課題があるか、考える人とふりかえる機会がなかった。使われなかった機能は、そのままプロダクトに残っていて、保守コストだけが増えている。

Slide 32

Slide 32 text

WHYから一緒に考えるのは、今からはできない。WHYや解決策の大きな変更も難しそう。考える人がすでに解決策を大方決めている状況で、WHYや解決策に手を出す何かをするのはリスクはある。ただ、できれば開発者が考えていることを少しでも改善できるような実験をしてほしい。あわよくば、考える人・作る人双方、今のものづくりのあり方（社内受託開発キャッチボール）に疑問を持ったり、今後のPJに活かせる学びを得てほしい。リスク：考える人作る人とで関係性が出来ていない状況で、両者間でハレーションが発生する私（コーチ）が考えたこと

Slide 33

Slide 33 text

まずは開発者（作る人）に試みの提案やってみたい！とのことその後、考える人にも、こういうことをやってみたいと相談ドキュメントにあるものを大きく変えたいのではなく、考える人・作る人で1つのチームとして、理解を揃え、安定してPJを進めたい目的とお伝え了承をいただいた私（コーチ）のアクション

Slide 34

Slide 34 text

試してみることにした 1 PJチーム全体で、プロダクトゴールを設定する PMが作成したドキュメントのWHYを元に、この機能を作る目的をチームで言語化考える人・作る人で機能を作る目的を認識し、そのゴールに向かえているかを問い続けるため。

Slide 35

Slide 35 text

試してみることにした https://www.agile-studio.jp/post/apm-user-story-mapping 2 PJチーム全体で、ユーザーストーリーマッピングを実施する

Slide 36

Slide 36 text

試してみることにした 2 PJチーム全体で、ユーザーストーリーマッピングを実施する PMが作成したドキュメントを元に、必要なユーザー体験をリストアップその他メンバーからのアイデアもリストアッププロダクトゴールを達成するために必要なMVPを議論の上で設定期日や工数感だけではなく、考える人・作る人のアイデアと知識を元に、プロダクトゴールを念頭においてスコープを設定する。

Slide 37

Slide 37 text

試してみることにした 3 PJチーム全体でスプリントレビューを実施する作る人（開発者）だけでもともとスクラムイベントを実施していたので、考える人も一緒にやりましょう。まずはスプリントレビューからとお誘い後に、全員でスクラムイベントを実施するように進化した FBサイクルを意識した開発ができるようにする。考える人も作る人も、プロダクトゴールに向かえているのかを考え続ける。

Slide 38

Slide 38 text

Slide 39

Slide 39 text

社内受託開発で発生する問題より良いアイデアが隠れる作る人の知識による、より良い（あるいは簡単な）実現方法があったとしても反映されない。機能が大きくなり、リリースが遅くなる作る人のモチベーション低下「作ったものが使われない」「作ったものの反応が分からない」状態が続くと、作る人のモチベーションが下がるリスクがある。今回の試みは社内受託開発の問題を解決できる！

Slide 40

Slide 40 text

試みてどうだった？狙いはおおむね達成！プロダクトゴール（目的）を揃えてスタートし、スコープも適切なものとサイズにした！想定より早期にユーザーへ価値提供できた！ついでに、リリース後にやりたいことも認識を揃えながら進められた！

Slide 41

Slide 41 text

リリース後、チームの声なぜやるかを意識して開発を進めることができた FBサイクルを回すため、着手順やバックログアイテムを工夫して、動くプロダクトを一緒に見ながら開発を進めることができた最初はやり方に戸惑ったけど、一緒にイベントを重ねるにつれ、あの人は今これをやっている、あの人はきっと今こんなことを考えているということが分かるようになった。不安になったらすぐ話せば良いと思えるようになった。動くプロダクトを中心に会話をする価値が分かった。アジャイル、ちょっと分かった！考える人だけで要件定義に時間をかけるのを改善したい

Slide 42

Slide 42 text

なぜやるかを意識して開発を進めることができた FBサイクルを回すため、着手順やバックログアイテムを工夫して、動くプロダクトを一緒に見ながら開発を進めることができた最初はやり方に戸惑ったけど、一緒にイベントを重ねるにつれ、あの人は今これをやっている、あの人はきっと今こんなことを考えているということが分かるようになった。不安になったらすぐ話せば良いと思えるようになった。動くプロダクトを中心に会話をする価値が分かった。アジャイル、ちょっと分かった！考える人だけで要件定義に時間をかけるのを改善したいリリース後、チームの声考える人が、社内受託開発キャッチボールから脱却したい気持ちを表明してくれた！

Slide 43

Slide 43 text

社内受託開発脱却できた！さらに、根本を改善したい声も聞こえた！

Slide 44

Slide 44 text

考える人作る人一緒に考えればこんな問題は起こらないね！かつて想像していた脱却方法作る人考える人と作る人が、なぜ・何を作るかを一緒に考える

Slide 45

Slide 45 text

課題を設定する深く関わる解決方法の方向性を考えるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整考える人と作る人が、なぜ・何を作るかを一緒に考える全面的な協働考える人作る人時間軸かつて想像していた脱却方法

Slide 46

Slide 46 text

深く関わる薄く関わるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整部分的な協働考える人作る人時間軸今回の実験で得た脱却方法課題を設定する課題を理解する解決方法の方向性を考える解決方法を理解する全員で考えるわけではない。必要なところで協働する。

Slide 47

Slide 47 text

深く関わる薄く関わるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整課題を設定する課題を理解する解決方法の方向性を考える解決方法を理解する全員で考えるわけではない。必要なところで協働する。部分的な協働考える人作る人時間軸ユーザーストーリーマッピングプロダクトゴールの設定今回の実験で得た脱却方法

Slide 48

Slide 48 text

帽子をかぶったまま、お互いに固い握手。部分的な協働今回の実験で得た脱却方法考える人作る人

Slide 49

Slide 49 text

社内受託開発脱却のアプローチ考える人作る人社内受託開発は、壁の向こうで考えられたWHY に触れられずにものを作っている状態壁を取り払い、作る人もWHYを理解する取り組みから始める WHYを揃えた上で、必要なスコープを考える人と作る人とで一緒に考える

Slide 50

Slide 50 text

今回の実験のその先今回の実験ではすでにWHYや解決方法の方向性がある程度決まった（開発依頼ドキュメントがある）状態でスタートしているので、手戻りが大きいなど改善点がありそう今回の振り返りで出た話題を元にさらに、今後の開発でどのような部分的協働のあり方が自分たちにとって良いのかを模索していくことになる

Slide 51

Slide 51 text

全面的な協働ではだめなのか？全面的な協働もだめではないが、ユーザー理解やドメイン理解が全員に必要だったり、意思決定権限の在り処をどうするかなど、部分的協働に比べて難易度が高い。まずは考える人の1人（主にPM）がWHYや解決策の設定をできるようになり、部分的協働ができるようになり、その先に全面的な協働を目指すのは、ありかもしれない。考える人作る人

Slide 52

Slide 52 text

社内受託開発からの脱却ご清聴ありがとうございました。完

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

開発の途中でチームがプロダクトゴール自体に違和感を持つ状況になり、スプリントレビューがなぁなぁに。誰のための何の機能なのかが、濁ったままのリリースとなってしまった。そして、ユーザーはその機能を使わなかった。社内受託開発を脱却したけど

Slide 55

Slide 55 text

社内受託開発を脱却したけど良いものを作るためには、社内受託開発の脱却から、もう少し先がありそうユーザーの困りごとを解決し、プロダクトを利用していただくビジネスにも貢献できる

Slide 56

Slide 56 text

社内受託開発の脱却 ⊂ 良いものを作る良いものを作る社内受託開発からの脱却

Slide 57

Slide 57 text

もう少し前に進むアプローチ 1 考える人、作る人で信頼のあるチームを作る 2 WHYをシャープにする 3 作る前に「すでに決まっている」ことを減らす

Slide 58

Slide 58 text

①信頼関係のあるチームチーム内の人間が互いに信頼しあうことが欠かせない。そうでなければ、何かをやりとげることは難しいだろう。組織パターンJames O.Coplien (著), Neil B.Harrison (著), 和智右桂 (翻訳) プロジェクトマネジメントのためのパターン言語

Slide 59

Slide 59 text

①信頼関係のあるチーム分からないことを分からないと伝える必要がある。そのためには信頼関係は必須チームを組成して最初から成功するのは難しいのは、信頼関係の欠如により、有益なコラボレーションが生まれないから信頼関係から、建設的相互作用が生まれる（ボビンの論文）下向きの批判新しい提案 https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2

Slide 60

Slide 60 text

②WHYをシャープにするドキュメントの「WHY」を深堀りする今回の実験ではWHYからプロダクトゴールを作ったが、実はWHYの背景について深堀りができていなかった WHYが事実なのか想像なのかを、作る人から質問して深堀りする（下向きの批判）課題は何ですか？うまくいったらユーザーはどうなりますか？

Slide 61

Slide 61 text

信頼を基盤とした部分的な協働で、課題理解は深く協働する。深く、部分的に協働する

Slide 62

Slide 62 text

深く関わる薄く関わるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整課題を設定する課題を理解する解決方法の方向性を考える解決方法を理解する信頼を基盤とした部分的な協働で、課題理解は深く協働する。考える人作る人時間軸深く、部分的に協働する

Slide 63

Slide 63 text

深く関わる薄く関わるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整課題を設定する課題を理解する解決方法の方向性を考える解決方法を理解する信頼を基盤とした部分的な協働で、課題理解は深く協働する。そのサイクルを繰り返すことで学びを積み上げ良いものを作れるようになっていく！考える人作る人時間軸繰り返すことでうまくなる

Slide 64

Slide 64 text

WHYから解決策を考え続けたい。そうなると、気になるあいつがいる。

Slide 65

Slide 65 text

機能A 機能B とあるPJでのできごと PdM デザイナー機能ロードマップ開発を依頼コーチドキュメント開発者

Slide 66

Slide 66 text

機能A 機能B とあるPJでのできごと PdM デザイナー機能ロードマップ開発を依頼コーチドキュメント開発者機能一覧ロードマップで作るもの（解決策）が事前に決まっている！

Slide 67

Slide 67 text

https://note.com/ozyozyo/n/nfb370fadd70c ③事前に決まっていることを減らすロードマップには機能ではなく数字（売上や指標）が書いてあると良い

Slide 68

Slide 68 text

より良いものを作れるようになるためのアプローチ

Slide 69

Slide 69 text

良いものづくりに向けたアプローチ機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームできごとおこないメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的である

Slide 70

Slide 70 text

良いものづくりに向けたアプローチ機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的であるものづくりあり方や仕事の進め方を変えるためにはメンタルモデルを変える必要がある。できごとおこない

Slide 71

Slide 71 text

良いものづくりに向けたアプローチ機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的であるメンタルモデルを直接変えに行く（ティーチング）のは難しい。自分で実験することで学びを得ることが大切。できごとおこない

Slide 72

Slide 72 text

社内受託開発脱却のときの変化機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的であるここを変えたここ影響を与えたできごとおこない

Slide 73

Slide 73 text

なぜやるかを意識して開発を進めることができた FBサイクルを回すため、着手順やバックログアイテムを工夫して、動くプロダクトを一緒に見ながら開発を進めることができた最初はやり方に戸惑ったけど、一緒にイベントを重ねるにつれ、あの人は今これをやっている、あの人はきっと今こんなことを考えているということが分かるようになった。不安になったらすぐ話せば良いと思えるようになった。動くプロダクトを中心に会話をする価値が分かった。アジャイル、ちょっと分かった！考える人だけで要件定義に時間をかけるのを改善したい分業のメンタルモデルに影響を与えている社内受託開発脱却のときの変化

Slide 74

Slide 74 text

社内受託開発脱却のときの変化機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的であるここを変えた「完全な分業ではなく部分的な協働に価値がある」と気付いたできごとおこない

Slide 75

Slide 75 text

繰り返し学んで、メンタルモデルを変える機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームアウトプットメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的であるロードマップで事前に作るものを決める必要性はあるのか？ WHYをシャープにする実験を続けると機能一覧ロードマップの必要性が薄れる「完全な分業ではなく部分的な協働に価値がある」と気付いた

Slide 76

Slide 76 text

繰り返し学んで、メンタルモデルを変える機能一覧ロードマップドキュメントによる開発依頼不透明なバリューストリームアウトプットメンタルモデル事前に具体的な計画を立てるのが是専門家（考える専門家、作る専門家）による分業が効率的であるロードマップを変える実験を続けるとまたメンタルモデルが変化する。「事前に具体的な計画をすべて立てる必要はない」と変わる

Slide 77

Slide 77 text

深く関わる薄く関わるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整考える人作る人時間軸社内受託開発を脱却したとき課題を設定する課題を理解する解決方法の方向性を考える解決方法を理解する考える人作る人よろしくねの固い握手！

Slide 78

Slide 78 text

深く関わる薄く関わるスコープを設定するスコープを設定する設計・実装・テスト方向性の調整課題を設定する課題を理解する解決方法の方向性を考える解決方法を理解する考える人作る人考える人作る人時間軸より良いものを作れる組織作る人それぞれの帽子をかぶりつつ、同じゴールを共に目指すチームメイトそこにはもう高い壁は存在しない

Slide 79

Slide 79 text

社内受託開発を脱却したいともがいていた。少し小さな実験をした。より良いものを作れる未来が見えてきた。

Slide 80

Slide 80 text

一度の実験でうまくいくことはないでしょう。でも実験を繰り返すことで少しずつ前に進んでいきます。ともに、より良いものづくりへの険しい道を歩んでいきましょう！未来への道のり

Slide 81

Slide 81 text

We are hiring!

Slide 82

Slide 82 text

furoshiki.fm のep.57-63はこの解決編につながる話題がぎゅっと詰まってるので後で聴いてみてね