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

#RSGT2025 の登壇資料です。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2025/proposal/20636

Transcript

1. 社内受託開発 からの脱却 考える人と作る人の壁を 越えるためのアプローチ いっしー@RSGT2025
2. 自己紹介 石毛 琴恵（いっしー） 所属：人生の休暇中 WEB系エンジニア→SM→EM→アジャイルコーチ furoshiki.fm の茶髪担当 #furoshiki_fm @oturu333
3. なぜ社内受託開発を脱却したいか
4. なぜ社内受託開発を脱却したいか 良いものを作りたいから！
5. なぜ社内受託開発を脱却したいか 良いものを作りたいから！ ユーザーの困りごとを解決し、 プロダクトを利用していただく
6. なぜ社内受託開発を脱却したいか 良いものを作りたいから！ ユーザーの困りごとを解決し、 プロダクトを利用していただく ビジネスにも貢献できる
7. 本資料における社内受託開発の定義 自社開発において「作る人」がユーザーの困りごとを理解しないま ま、社内の「考える人」から依頼されたものを作っている状態 考える人 作る人 あとはよろしく！ オーライ！
8. 本資料における社内受託開発の定義 自社開発において「作る人」がユーザーの困りごとを理解しないま ま、社内の「考える人」から依頼されたものを作っている状態 考える人 作る人 あとはよろしく！ オーライ！ 果 て し な く 高 く 見 え る 壁
9. 社内受託開発で発生する問題 より良いアイデアが 隠れる 作る人の知識による、より良 い（あるいは簡単な）実現方 法があったとしても反映され ない。 機能が大きくなり、 リリースが遅くなる 本来であれば、どんな困りご とを解決したいかでスコープ が決定するが、作るものだけ を見ていると「これもあれも 必要では？」と大きな機能に 成長しがち。 作る人の モチベーション低下 「作る理由が分からない」の に「作ったものが使われない」 状態が続くと、作る人のモチ ベーションが下がる。
10. 社内受託開発の脱却とは アイデアを出し合う 考える人、作る人で協働する ことで、より良いアイデアを 出し合う。 ゴールを定め スコープを設定する 困りごとをベースにゴールを 設定し、そのゴールを達成す るために最低限必要なものは 何かという視点で、スコープ を設定する 結果、作る人のモチ ベーションが上がる 作る人も作る目的を理解し、 ゴール達成のために何をする べきか考える。リリース結果 を振り返り、次の行動につな げる。モチベーションを高く 維持できる。
11. 社内受託開発、脱却したい！！
12. 自社開発において「作る人」がユーザーの困りごとを理解しないま ま、社内の「考える人」から依頼されたものを作っている状態 考える人 作る人 あとはよろしく！ オーライ！ 脱却する方法を考えた 果 て し な く 高 く 見 え る 壁
13. 自社開発において「作る人」がユーザーの困りごとを理解しないま ま、社内の「考える人」から依頼されたものを作っている状態 考える人 作る人 あとはよろしく！ オーライ！ なぜこうなる？ 脱却する方法を考えた 果 て し な く 高 く 見 え る 壁
14. 自社開発において「作る人」がユーザーの困りごとを理解しないま ま、社内の「考える人」から依頼されたものを作っている状態 考える人 作る人 あとはよろしく！ オーライ！ なぜこうなる？ ドキュメント 脱却する方法を考えた 果 て し な く 高 く 見 え る 壁
15. 考える人 自社開発において「作る人」がユーザーの困りごとを理解しないま ま、社内の「考える人」から依頼されたものを作っている状態 作る人 あとはよろしく！ オーライ！ なぜこうなる？ WHY 解決策 ドキュメント 脱却する方法を考えた 果 て し な く 高 く 見 え る 壁
16. WHYの記載はあるが、理解ができない！ 理解ができないときのアクションが難しい。 脱却する方法を考えた
17. WHYが「ユーザーに良い感じに使ってほしいから」では、実際はなぜ作るか分からない… 自分も、良い感じに使ってほしいとは思っているが。 脱却する方法を考えた WHYの記載はあるが、理解ができない！ 理解ができないときのアクションが難しい。
18. WHYは、考える人がユーザーの何かしらの困りごとを知っていて、その困りごとから 考える人個人の思考プロセスを経て生み出されたもの。 壁の向こうが見えない中でのWHYへの言及は、職能や個人の思考プロセスの否定にな らないか。どう聴いたら否定と捉えられず、コミュニケーションができるのか。 WHYへの疑問を伝えて期待した返答が返って来なかった場合、たぶん何度も疑問を伝 えるのは、気を使ってしまう。 脱却する方法を考えた WHYの記載はあるが、理解ができない！ 理解ができないときのアクションが難しい。 WHYが「ユーザーに良い感じに使ってほしいから」では、実際はなぜ作るか分からない… 自分も、良い感じに使ってほしいとは思っているが。
19. 考える人を否定せず WHYを考える人と作る人で理解できる 脱却したときの状態 難しい…
20. 考える人と作る人が、なぜ・何を作るかを 一緒に考える 考える人 作 る 人 一緒に考えれば こんな問題は 起こらないね！ 脱却方法 作る人
21. そうは思っていても 壁の向こうからドキュメントが到着する 考える人 作る人 あとはよろしく！ ちょっと 待って〜！ ドキュメント 果 て し な く 高 く 見 え る 壁 WHY 解決策
22. WHYから一緒に考えたいけど どうしたら良いのかな…
23. 月日が流れ、 とあるPJに関わることになった
24. とあるPJでのできごと 開発者 PdM デザイナー コーチ
25. とあるPJでのできごと PdM デザイナー はじめまして〜 コーチ 開発者
26. 機能A 機能B とあるPJでのできごと PdM デザイナー 機能ロードマップ コーチ 開発者
27. 機能A 機能B とあるPJでのできごと PdM デザイナー 機能ロードマップ 開発を依頼 コーチ ドキュメント 開発者
28. 機能A 機能B とあるPJでのできごと PdM デザイナー 機能ロードマップ ドキュメント 開発を依頼 コーチ WHY UI 表示項目 MUST/WANT 開発者
29. 機能A 機能B とあるPJでのできごと PdM デザイナー 機能ロードマップ 開発を依頼 コーチ ドキュメント 開発者
30. 開発者（作る人）が考えたこと この機能を作る目的がドキュメントだけではまだ理解できな い。もっと理解して開発をしたい 作るなら、ユーザーに使ってもらえる機能にしたい 頼まれたものを作るだけではなく、関係者とコミュニケーシ ョンを取りながら開発がしたい
31. なぜ開発者（作る人）はそう考えたか 社内受託開発のプロセスで実装した機能がユーザーに使われなか った経験があるから なぜ作るかを理解しないまま作り、その機能が使われなかった。 使われなかったが、どのような問題があったのか分からないままでい る。機能はもっと改善ができたかもしれないが、分からない。 現在のものの作り方にどのような課題があるか、考える人とふりかえ る機会がなかった。 使われなかった機能は、そのままプロダクトに残っていて、保守コス トだけが増えている。
32. WHYから一緒に考えるのは、今からはできない。WHYや解決策の大きな変 更も難しそう。 考える人がすでに解決策を大方決めている状況で、WHYや解決策に手を出 す何かをするのはリスクはある。ただ、できれば開発者が考えていること を少しでも改善できるような実験をしてほしい。あわよくば、考える人・ 作る人双方、今のものづくりのあり方（社内受託開発キャッチボール）に 疑問を持ったり、今後のPJに活かせる学びを得てほしい。 リスク：考える人作る人とで関係性が出来ていない状況で、両者間でハ レーションが発生する 私（コーチ）が考えたこと
33. まずは開発者（作る人）に試みの提案 やってみたい！とのこと その後、考える人にも、こういうことをやってみたいと相談 ドキュメントにあるものを大きく変えたいのではなく、考える人・ 作る人で1つのチームとして、理解を揃え、安定してPJを進めたい 目的とお伝え 了承をいただいた 私（コーチ）のアクション
34. 試してみることにした 1 PJチーム全体で、プロダクトゴールを設定する PMが作成したドキュメントのWHYを元に、この機能を作る目的 をチームで言語化 考える人・作る人で機能を作る目的を認識し、そのゴールに向かえているかを 問い続けるため。
35. 試してみることにした https://www.agile-studio.jp/post/apm-user-story-mapping 2 PJチーム全体で、ユーザーストーリーマッピングを実 施する
36. 試してみることにした 2 PJチーム全体で、ユーザーストーリーマッピングを実 施する PMが作成したドキュメントを元に、必要なユーザー体験をリスト アップ その他メンバーからのアイデアもリストアップ プロダクトゴールを達成するために必要なMVPを議論の上で設定 期日や工数感だけではなく、考える人・作る人のアイデアと知識を元に、プロ ダクトゴールを念頭においてスコープを設定する。
37. 試してみることにした 3 PJチーム全体でスプリントレビューを実施する 作る人（開発者）だけでもともとスクラムイベントを実施してい たので、考える人も一緒にやりましょう。まずはスプリントレビ ューからとお誘い 後に、全員でスクラムイベントを実施するように進化した FBサイクルを意識した開発ができるようにする。 考える人も作る人も、プロダクトゴールに向かえているのかを考え続ける。
38. 社内受託開発で発生する問題 より良いアイデアが 隠れる 作る人の知識による、より良 い（あるいは簡単な）実現方 法があったとしても反映され ない。 機能が大きくなり、 リリースが遅くなる 本来であれば、どんな困りご とを解決したいかでスコープ が決定するが、作るものだけ を見ていると「これもあれも 必要では？」と大きな機能に 成長しがち。 作る人の モチベーション低下 「作る理由が分からない」の に「作ったものが使われない」 状態が続くと、作る人のモチ ベーションが下がる。
39. 社内受託開発で発生する問題 より良いアイデアが 隠れる 作る人の知識による、より良 い（あるいは簡単な）実現方 法があったとしても反映され ない。 機能が大きくなり、 リリースが遅くなる 作る人の モチベーション低下 「作ったものが使われない」 「作ったものの反応が分から ない」状態が続くと、作る人 のモチベーションが下がるリ スクがある。 今回の試みは 社内受託開発の問題を 解決できる！
40. 試みてどうだった？ 狙いはおおむね達成！ プロダクトゴール（目的）を揃えてスタートし、 スコープも適切なものとサイズにした！ 想定より早期にユーザーへ価値提供できた！ ついでに、リリース後にやりたいことも認識を揃 えながら進められた！
41. リリース後、チームの声 なぜやるかを意識して開発を進めることができた FBサイクルを回すため、着手順やバックログアイテムを工夫し て、動くプロダクトを一緒に見ながら開発を進めることができた 最初はやり方に戸惑ったけど、一緒にイベントを重ねるにつれ、 あの人は今これをやっている、あの人はきっと今こんなことを考 えているということが分かるようになった。不安になったらすぐ 話せば良いと思えるようになった。 動くプロダクトを中心に会話をする価値が分かった。 アジャイル、ちょっと分かった！ 考える人だけで要件定義に時間をかけるのを改善したい
42. なぜやるかを意識して開発を進めることができた FBサイクルを回すため、着手順やバックログアイテムを工夫し て、動くプロダクトを一緒に見ながら開発を進めることができた 最初はやり方に戸惑ったけど、一緒にイベントを重ねるにつれ、 あの人は今これをやっている、あの人はきっと今こんなことを考 えているということが分かるようになった。不安になったらすぐ 話せば良いと思えるようになった。 動くプロダクトを中心に会話をする価値が分かった。 アジャイル、ちょっと分かった！ 考える人だけで要件定義に時間をかけるのを改善したい リリース後、チームの声 考える人が、 社内受託開発キャッチボール から脱却したい気持ちを 表明してくれた！
43. 社内受託開発脱却できた！ さらに、根本を改善したい声も聞こえた！
44. 考える人 作 る 人 一緒に考えれば こんな問題は 起こらないね！ かつて想像していた脱却方法 作る人 考える人と作る人が、なぜ・何を作るかを 一緒に考える
45. 課題を設定する 深く関わる 解決方法の方向性を考える スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 考える人と作る人が、なぜ・何を作るかを一緒に考える 全面的な協働 考える人 作る人 時間軸 かつて想像していた脱却方法
46. 深く関わる 薄く関わる スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 部分的な協働 考える人 作る人 時間軸 今回の実験で得た脱却方法 課題を設定する 課題を理解 する 解決方法の方向性を考える 解決方法を 理解する 全員で考えるわけではない。必要なところで協働する。
47. 深く関わる 薄く関わる スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 課題を設定する 課題を理解 する 解決方法の方向性を考える 解決方法を 理解する 全員で考えるわけではない。必要なところで協働する。 部分的な協働 考える人 作る人 時間軸 ユーザーストーリー マッピング プロダクトゴール の設定 今回の実験で得た脱却方法
48. 帽子をかぶったまま、お互いに固い握手。 部分的な協働 今回の実験で得た脱却方法 考える人 作る人
49. 社内受託開発脱却のアプローチ 考える人 作る人 社内受託開発は、壁の向こうで考えられたWHY に触れられずにものを作っている状態 壁を取り払い、作る人もWHYを理解する取り組 みから始める WHYを揃えた上で、必要なスコープを考える人 と作る人とで一緒に考える
50. 今回の実験のその先 今回の実験ではすでにWHYや解決方法の方向性がある程度決 まった（開発依頼ドキュメントがある）状態でスタートして いるので、手戻りが大きいなど改善点がありそう 今回の振り返りで出た話題を元にさらに、今後の開発でどの ような部分的協働のあり方が自分たちにとって良いのかを模 索していくことになる
51. 全面的な協働ではだめなのか？ 全面的な協働もだめではないが、ユーザー理解やドメイン理 解が全員に必要だったり、意思決定権限の在り処をどうする かなど、部分的協働に比べて難易度が高い。 まずは考える人の1人（主にPM）がWHYや解決策の設定をで きるようになり、部分的協働ができるようになり、その先に 全面的な協働を目指すのは、ありかもしれない。 考える人 作 る 人
52. 社内受託開発 からの脱却 ご清聴ありがとうございました。 完
54. 開発の途中で チームがプロダクトゴール自体に 違和感を持つ状況になり、スプリントレビューが なぁなぁに。 誰のための何の機能なのかが、濁ったままの リリースとなってしまった。 そして、ユーザーはその機能を使わなかった。 社内受託開発を脱却したけど
55. 社内受託開発を脱却したけど 良いものを作るためには、 社内受託開発の脱却から、もう少し先がありそう ユーザーの困りごとを解決し、 プロダクトを利用していただく ビジネスにも貢献できる
56. 社内受託開発の脱却 ⊂ 良いものを作る 良いものを作る 社内受託開発 からの脱却
57. もう少し前に進むアプローチ 1 考える人、作る人で信頼のあるチームを作る 2 WHYをシャープにする 3 作る前に「すでに決まっている」ことを減らす
58. ①信頼関係のあるチーム チーム内の人間が互いに信頼しあうことが欠かせない。 そうでなければ、何かをやりとげることは難しいだろう。 組織パターンJames O.Coplien (著), Neil B.Harrison (著), 和智 右桂 (翻訳) プロジェクトマネジメントのためのパターン言語
59. ①信頼関係のあるチーム 分からないことを分からないと伝える必要がある。 そのためには信頼関係は必須 チームを組成して最初から成功するのは難しいのは、信頼関 係の欠如により、有益なコラボレーションが生まれないから 信頼関係から、建設的相互作用が生まれる（ボビンの論文） 下向きの批判 新しい提案 https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2
60. ②WHYをシャープにする ドキュメントの「WHY」を深堀りする 今回の実験ではWHYからプロダクトゴールを作ったが、実 はWHYの背景について深堀りができていなかった WHYが事実なのか想像なのかを、作る人から質問して深堀 りする（下向きの批判） 課題は何ですか？ うまくいったらユーザーはどうなりますか？
61. 信頼を基盤とした部分的な協働で、課題理解は深く協働する。 深く、部分的に協働する
62. 深く関わる 薄く関わる スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 課題を設定する 課題を理解 する 解決方法の方向性を考える 解決方法を 理解する 信頼を基盤とした部分的な協働で、課題理解は深く協働する。 考える人 作る人 時間軸 深く、部分的に協働する
63. 深く関わる 薄く関わる スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 課題を設定する 課題を理解 する 解決方法の方向性を考える 解決方法を 理解する 信頼を基盤とした部分的な協働で、課題理解は深く協働する。 そのサイクルを繰り返すことで学びを積み上げ 良いものを作れるようになっていく！ 考える人 作る人 時間軸 繰り返すことでうまくなる
64. WHYから解決策を考え続けたい。 そうなると、気になるあいつがいる。
65. 機能A 機能B とあるPJでのできごと PdM デザイナー 機能ロードマップ 開発を依頼 コーチ ドキュメント 開発者
66. 機能A 機能B とあるPJでのできごと PdM デザイナー 機能ロードマップ 開発を依頼 コーチ ドキュメント 開発者 機能一覧ロードマップで 作るもの（解決策）が事前に決まっている！
67. https://note.com/ozyozyo/n/nfb370fadd70c ③事前に決まっていることを減らす ロードマップには機能ではなく 数字（売上や指標）が書いてあると良い
68. より良いものを作れる ようになるためのアプローチ
69. 良いものづくりに向けたアプローチ 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム できごと おこない メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である
70. 良いものづくりに向けたアプローチ 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である ものづくりあり方や仕事の進め方を変えるためには メンタルモデルを変える必要がある。 できごと おこない
71. 良いものづくりに向けたアプローチ 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である メンタルモデルを直接変えに行く（ティーチング）のは難しい。 自分で実験することで学びを得ることが大切。 できごと おこない
72. 社内受託開発脱却のときの変化 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である ここを変えた ここ影響を与えた できごと おこない
73. なぜやるかを意識して開発を進めることができた FBサイクルを回すため、着手順やバックログアイテムを工夫し て、動くプロダクトを一緒に見ながら開発を進めることができた 最初はやり方に戸惑ったけど、一緒にイベントを重ねるにつれ、 あの人は今これをやっている、あの人はきっと今こんなことを考 えているということが分かるようになった。不安になったらすぐ 話せば良いと思えるようになった。 動くプロダクトを中心に会話をする価値が分かった。 アジャイル、ちょっと分かった！ 考える人だけで要件定義に時間をかけるのを改善したい 分業のメンタルモ デルに影響を与え ている 社内受託開発脱却のときの変化
74. 社内受託開発脱却のときの変化 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である ここを変えた 「完全な分業ではなく 部分的な協働に価値がある」 と気付いた できごと おこない
75. 繰り返し学んで、メンタルモデルを変える 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム アウトプット メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である ロードマップで 事前に作るものを 決める必要性はあるのか？ WHYをシャープにする実験を続けると 機能一覧ロードマップの必要性が薄れる 「完全な分業ではなく 部分的な協働に価値がある」 と気付いた
76. 繰り返し学んで、メンタルモデルを変える 機能一覧ロードマップ ドキュメントによる開発依頼 不透明なバリューストリーム アウトプット メンタルモデル 事前に具体的な計画を立てるのが是 専門家（考える専門家、作る専門家） による分業が効率的である ロードマップを変える実験を続けると またメンタルモデルが変化する。 「事前に具体的な計画をすべて 立てる必要はない」と変わる
77. 深く関わる 薄く関わる スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 考える人 作る人 時間軸 社内受託開発を脱却したとき 課題を設定する 課題を理解 する 解決方法の方向性を考える 解決方法を 理解する 考える人 作る人 よろしくねの固い握手！
78. 深く関わる 薄く関わる スコープを設定する スコープを設定する 設計・実装・テスト 方向性の調整 課題を設定する 課題を理解 する 解決方法の方向性を考える 解決方法を 理解する 考える人 作る人 考える人 作る人 時間軸 より良いものを作れる組織 作る人 それぞれの帽子をかぶりつつ、 同じゴールを共に目指すチームメイト そこにはもう高い壁は存在しない
79. 社内受託開発を脱却したいともがいていた。 少し小さな実験をした。 より良いものを作れる未来が見えてきた。
80. 一度の実験でうまくいくことはないでしょう。 でも実験を繰り返すことで 少しずつ前に進んでいきます。 ともに、より良いものづくりへの 険しい道を歩んでいきましょう！ 未来への道のり
81. We are hiring!
82. furoshiki.fm のep.57-63はこの解決編につながる話題が ぎゅっと詰まってるので後で聴いてみてね