組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk

PHPカンファレンス福岡2025の発表資料です。
https://fortee.jp/phpcon-fukuoka-2025/proposal/01c22f2b-e1bc-467d-ad9c-f696535c9466

Transcript

1. 組織もソフトウェアも難しく考えない、 もっとシンプルな考え方で設計する PHPカンファレンス福岡2025 Hideki Kinjyo GitHub: o0h / X: @o0h_ [公開用] v1.2.2
2. 今日のお話  2
3. 今日のお話  3
4. 俺みたいな 「ソフトウェアも組織も同じように考えたい」 ってやつ、他に、いますか  4
5. なぜ、そんな話なのか 「フィードバック」とやらに注目すると、 何かに役立てられるんでない？  ソフトウェアにも組織にも  5 今日のお題
6. おしながき §1 定義:フィードバックって何だ！？ @5分 §2 活用:フィードバックを設計に活かす @10分 §3 発展:組織もソフトウェアも @8分 §4 エピローグ @3分  6
7. 自己紹介 • 金城秀樹 / きんじょうひでき • GitHub: @o0h / 𝕏 : @o0h_ • 好きなFWはCakePHP • アイコンは美味しい鮭親子丼の写真です • 最近はPodcastをやっています • ハッシュタグ: #readlinefm  
8. §1 定義:フィードバックって何だ！？ §3 活用:フィードバックを設計に活かす §3 発展:組織もソフトウェアも エピローグ
9. ここからの話 このトークにおける「フィードバックとは何か」を話していきます。 1. 形式・構造的なフィードバックの定義 2. フィードバックにはどんな意義があるのか  9
10. フィードバックって何のこと？ そもそも！
11. 最初に結論 フィードバックとは 何かをすると、 何かをされた対象から、 反応が返ってくる 構造のこと  11
12. いくつかの例を見てみましょう  12
13. フィードバックの素朴な形  13 こんにちは！ (にっこり)
14. フィードバックの素朴な形  14 ラーメンください へい、 お待ちぃ！
15. ↑ 概論ここまで ↓ ここから具体例  15
16. 組織とソフトウェアに見るフィードバック
17. 組織で見るフィードバック①  17 こういうのが 欲しい〜 作ったぞ〜〜！ PdM DEV
18. 組織で見るフィードバック②  18 最近多い 顧客の声を教えて 集計データどうぞ！ PdM CS
19. ソフトウェアにおけるフィードバック①  19 クラスA クラスB メソッドX 結果
20. ソフトウェアにおけるフィードバック①  20 クラスA クラスB メソッドX 結果 何かをする 何かをされた 反応が返る
21. [ソ]フィードバック① $fp = Utils::tryFopen($file);   何かをする 何かをされた 反応が返る
22. [ソ]フィードバック② $version = $this->version;   プロパティへのアクセスも 「取得結果」がある 反応が返る 何かをされた 何かをする
23. [ソ]フィードバック③ try { $fp = fopen($file, $mode); } catch (Throwable $e) { $ex = new RuntimeException( sprintf( 'Unable to open %s w/%s', $file, $mode, ), previous: $e); }   例外のthrowもフィードバック 反応が返る 何かをする
24. 現時点では、 「小さなフィードバック関係が沢山あるんだな」を 感じてもらえればOK  24
25. (形式的な定義は分かったけど) フィードバックにはどんな意義があるの？ 何を もたらすのか？
26. フィードバックの意義と働き 「投げて返ってきたものを受け取る」 コレだけなら注目するまでもない  26
27. フィードバックの意義と働き 「投げて返ってきたものを受け取る」 コレだけなら注目するまでもない  フィードバックは何をもたらしているのか に注目したい  27
28. フィードバックの意義と働き 自身の目的を達成するために 適切な相手に働きかけ、 そのフィードバックから 自身の行動を調整できる ことが、フィードバックの意義  28
29. フィードバックの働き  29 お、良いボタンがある。 押してみようかな。ポチ〜 押すだけで 1000万円 当たるボタン 押す ◯◯サービスに 登録されました (月額30万円) 視覚に訴える めちゃヤバ案件 (変化)
30. フィードバックの働き 受け取った後に、 次の行動が促される  30 めちゃヤバ案件 逃げる？ 問題を取り除く？ 信じる？ ◯◯サービスに 登録されました (月額30万円)
31. フィードバックの働き -より俯瞰して-  31 #phpconfuk #hall_hz で「FFBなう」って呟いて！今！！ 🐦「FFBなう」 私 皆様
32. フィードバックの働き -より俯瞰して-  32 #phpconfuk #hall_hz で「FFBなう」って呟いて！今 🐦 なぜ、 「呼びかける」という 行動をしたのか？
33. フィードバックの働き -より俯瞰して-  33 そもそもの行動には、 起点となる目的がある で「FF 登壇した痕跡 残してぇ〜〜
34. 登壇した痕跡 残してぇ〜〜 フィードバックの働き -より俯瞰して-  34 行動の結果として フィードバックを得る  次の行動は、 「目的」に照らし合わせて 調整される 「FFBなう」っ て呟いて！ たくさん流れ てきた！！ RePost.. RePost.. RePost.. RePost..
35. フィードバックの働き -より俯瞰して-  35 行動の結果として フィードバックを得る  次の行動は、 「目的」に照らし合わせて 調整される 登壇した痕跡 残してぇ〜〜 「FFBなう」っ て呟いて！ あんま流れて こない。。。 早く！！ 「FFBなう」って呟 いて！
36. ↑ 概論ここまで ↓ ここから具体例  36
37. 組織とソフトウェアに見るフィードバック
38. 組織で見るフィードバック  38 法務 営業 ★法務には、自分のための目的があって 業務効率を 上げるぞ！
39. 組織で見るフィードバック  39 ★ 行動を起こし、営業に働きかけを行う 業務効率を 上げるぞ！ 契約書の 雛形を 更新したよ！
40. 組織で見るフィードバック  40 ★ その結果が、フィードバックとして返ってくる 契約書の 雛形を 更新したよ！ 使いにくい！ 業務効率を 上げるぞ！
41. 契約書の 雛形を 更新したよ！ 使いにくい！ 組織で見るフィードバック  41 ★ 目的に合わせて、フィードバックを次のアクションにつなげる 契約書の 雛形を 更新したよ！ 共有・説明会を開こう！ 業務効率を 上げるぞ！
42. 契約書の 雛形を 更新したよ！ 契約書の 雛形を 更新したよ！ 組織で見るフィードバック  42 ★ 目的に影響を与えないフィードバックは影響を及ぼさない 経費精算 大変すぎる〜 ふーん 業務効率を 上げるぞ！
43. [ソ]フィードバック $version = $this->getVersion(); if ($version->lt($minVersion)) { return false; } return true;  
44. [ソ]フィードバック $version = $this->getVersion(); if ($version->lt($minVersion)) { return false; } return true;   「バージョンどうですか？」 の入力 $version = $this->getVersion(); $version->lt($minVersion)
45. [ソ]フィードバック $version = $this->getVersion(); if ($version->lt($minVersion)) { return false; } return true;   true or falseの フィードバック $version->lt($minVersion)
46. [ソ]フィードバック $version = $this->getVersion(); if ($version->lt($minVersion)) { return false; } return true;   入力者側が、 フィードバック内容を見て 次のアクションを行う return false; return true;
47. [ソ]フィードバック function isSupported() { $version = $this->getVersion(); if ( $version->lt($minVersion) ) { return false; } return true; }   この手続きは 「バージョンで判定する」 という目的がある function isSupported()
48. §1 まとめ
49. このトークでの定義 フィードバックとは 何かをすると、 何かをされた対象から、 反応が返ってくる 構造のこと  49
50. もたらすもの 自身の目的を達成するために 適切な相手に働きかけ、 そのフィードバックから 自身の行動を調整できる ことが、フィードバックの意義  50
51. §1 定義:フィードバックって何だ！？ §2 活用:フィードバックを設計に活かす §3 発展:組織もソフトウェアも エピローグ
52. ここからの話 「フィードバックを設計に活かす」ための観点を話していきます • フィードバックを受け取った後に何をしているか？が肝 • 受け取った後に「頑張っている」か「あまり苦労しない」か • 良いフィードバックであれば、苦労しないでそのまま使える • 良いフィードバックを受け取れる構造を作り込んでいく • 適切な責務分割を促し、凝集性を高める  52
53. (意義が分かったとして) フィードバックから何が分かるの？ 何を もたらすのか？
54. フィードバックが「分かる」と何を得られるのか  54 入力者 システム 何かをする 反応を返す (フィードバック) こういう構造があって 何かをされた 最終出力
55. 入力者 フィードバックが「分かる」と何を得られるのか  55 こう機能するところに システム 何かをする 反応を返す 目的 調整 何かをされた 最終出力
56. 入力者 最終出力 フィードバックが「分かる」と何を得られるのか  56 この内容に注目して システム 何かをする 反応を返す 目的 調整 何かをされた
57. 入力者 最終出力 フィードバックが「分かる」と何を得られるのか  57 ここの構造を変えるヒントとする システム 何かをする 反応を返す 目的 調整 何かをされた
58. ヒントはどこに眠っているのか 「本来の目的」と 「フィードバックを受け取った後」に注目する (どんな調整をしているか？どのくらい複雑か？)  そこには「本来の目的とのギャップ」がある  58
59. 入力者 最終出力 本来の目的とのギャップ  59 目的 ここにギャップがあるから
60. 入力者 最終出力 本来の目的とのギャップ  60 目的 調整 その調整にコストがかかる、という考え方
61. コストを下げるために良いフィードバックを 良いフィードバックであれば、 「本来の目的とのギャップ」が少なくなる  良いフィードバックを生み出す構造をつくる = 良い設計をする  61
62. ↑ 概論ここまで ↓ ここから具体例  62
63. 組織に見るフィードバックの活用例
64. 組織で見るフィードバック  64 最近多い顧客の声を教えて 集計データどうぞ！ 次の施策を考えるぞ〜 企画会議 (データを読み解か ないと。。) PdM CS
65. 組織で見るフィードバック  65 最近多い顧客の声を教えて 集計データどうぞ！ 次の施策を考えるぞ〜 企画会議 (データを読み解か ないと。。) 本当に必要なのはコッチっぽい
66. 組織で見るフィードバック  66 最近多い顧客の声を教えて 集計データどうぞ！ 次の施策を考えるぞ〜 企画会議 受け取った後に 「一手間」のコストがある (データを読み解か ないと。。)
67. 組織で見るフィードバック  67 最近多い顧客の声を教えて 集計データどうぞ！ 次の施策を考えるぞ〜 企画会議 「入出力」の発生も コストと見なせる
68. 分析結果を踏まえて • 目的: 良い企画を考える(企画会議で提案する) • 現状の実装: CSからデータを取り寄せ、自分で解釈する • オーバーヘッド: • 受け取り後の分析コスト • CSとの一往復(欲しい内容の指示、出力結果の受信)  68
69. 分析結果を踏まえて • 目的: 良い企画を考える(企画会議で提案する) • 現状の実装: CSからデータを取り寄せ、自分で解釈する • オーバーヘッド: • 受け取り後の分析コスト • CSとの一往復(欲しい内容の指示、出力結果の受信)  69 ここのコストの高さが、 「組織の構造から生じる問題」の大きさ
70. 分析結果を踏まえて • 目的: 良い企画を考える(企画会議で提案する) • 現状の実装: CSからデータを取り寄せ、自分で解釈する • オーバーヘッド: • 受け取り後の分析コスト • CSとの一往復(欲しい内容の指示、出力結果の受信)  70 この構造を修正することで、 コストの総和を下げられないか？
71. 組織の出力を低コストで支える構造  71 企画会議 構造を変更して、 より自然な「適応」を促す 顧客の声 インストール済み グロース全体像 インストール済み 次の施策を考えるぞ〜 PdM CS
72. ソフトウェアに見るフィードバックの活用例
73. ソフトウェアで見るフィードバック $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);  
74. ソフトウェアで見るフィードバック $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   $this->productApiClient->request($productId); API Clientで 商品を取ってくる
75. ソフトウェアで見るフィードバック $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } HTTPステータスから エラーを判定＆処理を中断する
76. ソフトウェアで見るフィードバック $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } 応答本文から エラーを判定＆処理を中断する
77. ソフトウェアで見るフィードバック $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   return $this->success(['product' => $data['detail']]); 商品情報を返す
78. 受け取った後に「何をしているか」を分析する コントローラーが持っている仕事 • HTTPステータスからエラーを判定=>エラーを返す • 応答本文からエラーを判定=>エラーを返す • 商品情報を返す  78 Controller API Client 商品情報くれ〜 取ってきた結果〜 中身を精査しないと
79. 受け取った後に「何をしているか」を分析する コントローラーが持っている仕事 • HTTPステータスからエラーを判定=>エラーを返す • 応答本文からエラーを判定=>エラーを返す • 商品情報を返す  79 目的ってコッチっぽくない？
80. 受け取った後に「何をしているか」を分析する コントローラーが持っている仕事 • HTTPステータスからエラーを判定=>エラーを返す • 応答本文からエラーを判定=>エラーを返す • 商品情報を返す  80 本来の目的では無さそう！
81. 本来の目的と非本来的なコスト $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   return $this->success(['product' => $data['detail']]); $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); return $this->error('Please try again later'); return $this->error('Unable to load product', 400); return $this->error('Product unavailable', 404); このあたりが「本題」で
82. 本来の目的と非本来的なコスト $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   } $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { このあたりが 「本題以外」と言える } elseif ($statusCode >= 400) { $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { }
83. 本来の目的と非本来的なコスト $productId = $request->get('product_id'); $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error('Unable to load product', 400); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error('Product unavailable', 404); } return $this->success(['product' => $data['detail']]);   「本題」は 全体の半分に満たない！
84. 分析から見えてきたこと どんな問題が見えて来たのか • フィードバックを受け取ってからの処理が長い、煩雑 • => 目的のために利用するコストが高い(良いフィードバックになっていない) • 利用するために必要な知識が多様 • HTTPステータス・APIレスポンスの形式、と複数のレイヤーにまたがる • => 知識の多様化は高機能化をもたらし、目的を曇らせやすい  84
85. 分析結果を踏まえて • コントローラーは 「商品情報を返す、ダメならエラーメッセージを」に集中させる • そのために新しいレイヤーを導入 • APIクライアントをラップしてエラー判定とかをよしなにやってくれる君 • 結果について持ち運んでくれる君(Resultオブジェクト)  85
86. ProductApiGateway: fetchメソッド public function fetch(int $productId): ProductApiResult { $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return ProductApiResult::error('Please try again later'); } elseif ($statusCode >= 400) { return ProductApiResult::error('Unable to load product'); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return ProductApiResult::error('Product unavailable'); } return ProductApiResult::success($data['detail']); }  
87. ProductApiGateway: fetchメソッド public function fetch(int $productId): ProductApiResult { $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return ProductApiResult::error('Please try again later'); } elseif ($statusCode >= 400) { return ProductApiResult::error('Unable to load product'); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return ProductApiResult::error('Product unavailable'); } return ProductApiResult::success($data['detail']); }   $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return ProductApiResult::error('Please try again later'); } elseif ($statusCode >= 400) { return ProductApiResult::error('Unable to load product'); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return ProductApiResult::error('Product unavailable'); } 中身は コントローラーで やっていた処理と 大体同じ
88. ProductApiGateway: fetchメソッド public function fetch(int $productId): ProductApiResult { $result = $this->productApiClient->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return ProductApiResult::error('Please try again later'); } elseif ($statusCode >= 400) { return ProductApiResult::error('Unable to load product'); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return ProductApiResult::error('Product unavailable'); } return ProductApiResult::success($data['detail']); }   ProductApiResult ProductApiResult::error('Please try again later'); ProductApiResult::error('Unable to load product'); ProductApiResult::error('Product unavailable'); ProductApiResult::success($data['detail']); 利用目的に合わせた 「ハイレベル」な表現で 結果を返す
89. Controller before/After $productId = $request ->get('product_id'); $result = $this ->gateway ->fetch($productId); if (!$result->isOk) { $this->error($result->reason); } else { $this->success([ 'product' => $data['detail'] ]); }   $productId = $request->get('product_id'); $result = $this ->productApiClient ->request($productId); $statusCode = $result->getStatusCode(); if ($statusCode >= 500) { return $this->error('Please try again later'); } elseif ($statusCode >= 400) { return $this->error( 'Unable to load product', 400 ); } $body = $result->getBody()->getContents(); $data = json_decode($body, true); if ($data['status'] === 'invalid') { return $this->error( 'Product unavailable', 404 ); } return $this->success(['product' => $data['detail']]);
90. 構造が変更される 元々は大きなコストがControllerで発生していたのが…  90 Controller API Client 商品情報くれ〜 取ってきた結果〜 中身を精査しないと コスト高 コスト低
91. 「良いフィードバック」のための調整が行われ、均等化・減少した 構造が変更される  91 Controller Gateway 商品情報くれ〜 取ってきた結果〜 Result API Client 中身を精査済み★ コスト激低 コスト低 コスト低 コスト激低
92. §3まとめ
93. フィードバックに注目して分析＆設計する • フィードバックを受け取った後に何をしているかが肝 • 「何かたくさん頑張っているな」と思ったら、コストが高いと判断 • 目的に沿ったフィードバックになっていれば、コストが低くなる • 良いフィードバックを受け取れる構造を作り込んでいく • 適切な責務分割を促し、凝集性を高める  93
94. 「フィードバックに注目する」ことの意義 • フィードバック(=何を受け取り、どう使っているか)には、 自身に本当に必要なこと・やりたいことが詰め込まれている • ここに着目して、より抽象レベルの「目的は何？」を可視化していく • 頭の中だけで概念的に考えるだけでなく、「実際に目の前にある活動」から「コ ストが大きい？小さい？」を捉えるヒントになる  94
95. §1 定義:フィードバックって何だ！？ §2 活用:フィードバックを設計に活かす §3 発展:組織もソフトウェアも エピローグ
96. RT: 今日のお話  96
97. どちらにも通用するのはなぜか？ どちらも 「目的」「フィードバック」「調整」という仕組み を共通して備えている  97
98. どちらにも通用するのはなぜか？ 同じ仕組みを持つ = 同じ問題を持つ  同じアプローチが通用する  98
99. 全く別々でも問題が似ている 問題は「要素間のやりとりから出るコスト」 (=> 受信後の調整コスト、やり取り自体のコスト)  コストの総和が大きくなれば、 トータルの出力が落ちる  99
100. やるべき事も似てくる 「良いやり取り」のための構造を作る 各所で、良いフィードバックを生み出させる  100
101. ↑ 概論ここまで ↓ ここから具体例  101
102. 実験: 「組織設計の見方」と 「ソフトウェア設計の見方」を 越境してみる
103. 再掲: 先程の例  103 最近多い顧客の声を教えて 集計データどうぞ！ 次の施策を考えるぞ〜 企画会議 (データを読み解か ないと。。)
104. UMLで書いてみるとこんな感じ？  104
105. UMLで書いてみるとこんな感じ？  105 getterを叩いているだけ
106. UMLで書いてみるとこんな感じ？  106 "ビジネスロジック"は 自前で持っている
107. 擬似コードにするとこんな感じ？ class PdM { private Cs $cs; public function createKikakuIdea(): Kikaku { $voiceCollection = $this->cs->getUserVoiceCollection(); // ͛͢ʔෳࡶͳͷͰ͜͜ʹ1,000ߦ͘Β͍ͷώϡʔϦεςΟοΫͳϩδοΫ͕ੜ͑Δ // $voiceCollectionΰχϣΰχϣɾɾɾͰɺ$kikakuΛಘΔ return $kikaku; } } }   ので
108. アンチパターンぽくないですか？ 状況: • 「CS」は「顧客の声を取る」ための仲介者としてしか利用されない • その後、「PdM」は、複雑なビジネスロジックを適用する • 多分「集計して見やすくする」「考える」の仕事が入っていそうじゃない？  108
109. 「ドメインモデル貧血症」的な見方 問題の形: • getterを提供しているだけでデータを使う知識がない • (悪い)結合や、(悪い)トランザクションスクリプトを誘発する なぜならば: • CSに「プロダクトを一緒に作る」という役割がない • ゆえに、「ただgetterを公開しているだけ」に成り下がっている それゆえ: • フィードバックを利用するためのコストを高めている  109
110. 「機能の横恋慕的」な見方 問題の形: • 自身よりも、他のオブジェクトの機能やデータにばかり関心がある • 低凝集なオブジェクトの典型的な症状(不吉な臭い) なぜならば: • 「顧客の反応にアクセスする」のは「CSの機能」という思い込み • ゆえに、「わざわざCSを経由する」という教条的なコミュニケーションに陥る それゆえ: • 必要なデータを得る際にオーバーヘッドが生じている  110
111. 組織構造のアーキタイプ これらの要素を組み合わせて、組織の「構造」が作られる • 公式な組織 - 部門、部署 • 組織図上に現れる単位 • 準公式な組織 - 時限的なプロジェクト、委員会 • 部署・部門と境界線を同一としない集約 • 会議体 / 会議 - 情報共有、意思決定のための集まり • アジェンダありきの単発・連続の集合 • 非公式なつながり - 偶発的な交流、(構造に用いる場合には)意図的な交流の仕組み • 業務上の結合に閉ざされない関係 • 組織パターン「冷水機」 スクラムパターン「おやつ神社」、Slackのtimesなども  111
112. どんな構造へのアプローチで、どう改善できる？ ざっくりと考えて2つの方向性 1.「CS」を「プロダクト開発ドメイン」に組み込む 2.「顧客の声へのアクセス」を「CS」以外にも開放する  112
113. CS 1. 「CS」を「プロダクト開発ドメイン」に組み込む • 「プロダクト開発ドメイン」の拡張: CSの参画 • アーキタイプ「会議」や「チーム」でリファクタ  113 企画会議 顧客の声 インストール済み グロース全体像 インストール済み 次の施策を考えるぞ〜 PdM
114. 2. 「顧客の声へのアクセス」を「CS」以外にも開放する • 「ロール-アクセスpermission」の見直し: PdMロールへの機能付与 • PdM-CS間の結合の解消  114 最近多い顧客の声を教えて 集計データどうぞ！ 次の施策を考えるぞ〜 企画会議 データを取り出して 読み解く俺・・
115. 共通する視点で見えてくるもの・改善方法がある • 組織の問題を「ソフトウェアっぽい知識」で解釈できた • フィードバックに着目した分析によって、 コミュニケーションの在り方にメスを入れる • より「本来の目的」とのギャップが少ない状態を目指す  115
116. §1 定義:フィードバックって何だ！？ §2 活用:フィードバックを設計に活かす §3 発展:組織もソフトウェアも エピローグ
117. 残っている話を回収 プロポーザルに書かれているのにノータッチになっている話に触れます  117
118. 残っている話を回収 プロポーザルに書かれているのにノータッチになっている話に触れます  118
119. より一般化して捉えることの持つ力
120. (突然ですが) 統一理論って言葉があります  120
121. ChatGPT(GPT-5)の回答  121
122. 一つの根本原理で、全てを理解する  122
123. 「設計の小難しさ」をほぐしたい お仕事、難しいですよね  123
124. 「設計の小難しさ」をほぐしたい - ビジネス領域、プロダクト領域の難しさ - 人間、組織領域の難しさ - 技術領域の難しさ  124 👀
125. 「設計の小難しさ」をほぐしたい これらに共通する「力の流れ」が見えてくれば、 もっとシンプルに考えられるかもしれない  125
126. 「設計の小難しさ」をほぐしたい これらに共通する「力の流れ」が見えてくれば、 もっとシンプルに考えられるかもしれない  逆に言えば、そうしなければ、 領域ごとの個別の理論を個別に暗記する、を強いられる  126
127. ここまでのトークで提示したもの シンプルに考えてみる、の1つの例として 「組織設計もソフトウェアも、 実は同じように問題を見抜けるはずなんだ」 というお話  127
128. 「one of themな考え方」を超えて 自分なりの「全てを説明できる見方」を手に入れた時、 それは「とある1つの見方」を超えて 「哲学」「美学」になる  128
129. 「one of themな考え方」を超えて 哲学 = 世界がどのようになっているか、という見方 美学 = 美しいと感じるもの、それはなぜか？の探求  129
130. 色々な「哲学」の例  130 t-wadaさんの『技術選定の審美眼』 https://speakerdeck.com/twada/understanding-the-spiral-of-technologies-2025-edition
131. 色々な「哲学」の例  131 k1LoWさんの 『ソフトウェア開発におけるインターフェイスという考え方』 https://speakerdeck.com/k1low/phperkaigi-2025
132. 色々な「哲学」の例 クリストファー・アレグザンダーの 「パタン・ランゲージ」 「利用者参加の原則」  なぜ、建築の枠組みを超えて現れるのか  132 顧客が本当に 必要だったもの
133. お伝えしたかったこと 自分なりの哲学を持つことで、 生み出す設計に筋が通る。 それが設計の地力の向上につながる  133
134. お伝えしたかったこと なにか「哲学」と呼べる1つの軸を持つ。 色々な問題に素振りしてみる。 より深淵を覗き込んで、磨きをかけていく  134
135. まとめ
136. 最後に言いたいこと 「フィードバックに着目せよ！」という方法、 面白いと思うので、 ぜひ遊んでみてください！  136
137. 最後に言いたいこと が！！！ そんなのはあくまで一例。 自分なりの哲学を見出してみてください！  137
138. おしまい！ お付き合いいただき ありがとうございました!!
139. ご出演の皆さん from ゆるかわいい無料イラスト素材集 | いらすとん https://www.irasuton.com/ PdM CS 法務 営業 DEV
140. Appendix-Ⅲ 色々な「システム」
141. What's this • 今回の話の背景に、 「システムっぽいものとして対象を見る」という感覚があります • 発表では触れられていませんが、 枠外でちょっと整理しようかなと・・・  141
142. システム？  142 https://ja.wiktionary.org/wiki/システム
143. 「システム」 一般に対するアプローチ • システムには • 「要素」がある • 要素同士の「繋がり」がある • 繋がった者同士の「相互作用」がある • 分析した要素の1つ1つだけを見ても、システムの理解は得難い • 代わりに、「繋がり」「相互作用」を見る必要がある  143
144. 色々なシステム
145. サイバネティクス(古典的な) • https://ja.wikipedia.org/wiki/サイバネティックス • 「観察」「行動」「フィードバック」と「フィードバックを受けて制 御する」という構図 • 「フィードバックを結果として受けとり、自己の調整を行う」という 世界観  145
146. 一般システム理論 • 還元主義(=要素を観察すれば、システムのすべてがわかる)を超えて、 「システムとは、要素の集合以上の意味を持つもの」の世界観 • 「一般的」な見方として、全体性・相互的な依存等の観点を適用する もの  146
147. G・M・ワインバーグの「一般システム思考入門」 • 「観察」を行う主体もシステムの一部であるという立場 • ("ネオ・サイバネティクス"と通ずるものがありそう • システムは、(依存関係にある)対象を「観察」して、自身の変化・適応を自律 的に行うもの • また、フラクタルな構造を持ち、ミクロなシステムは全て上位の「環境」の一 部である、という論も展開している • 「コード→パッケージ→ソフトウェア→インフラを含めたITシステム→ビジネス要求→ マーケットや現実世界→自然法則・宇宙」という感じに • 下位だけを見ると「変更」であっても、上位に対する「適応」にしか過ぎない  147
148. ノーマンの「行為の7段階理論」 • ゴールの形成 → 意図の形成 → 行為の詳細化 → 行為の実行 → 外 界の状況の知覚 → 外界の状況の解釈 → 結果の評価 • これも「フィードバックがあったときに、それを拾って、判断し、次 の行動に」という世界観と一致する  148
149. 家族療法の「システムズアプローチ」 • 「問題は、個別の対象(クライエント)にあるのではなく、それをとり まく環境にある」という考えに基づくアプローチ • 例えば、「不登校の子ども」は「本人に原因がある」のではなく「家 族の接し方」に方策を求める、みたいな世界観 • つまり「個別の要素そのもの」ではなく「環境に変更を加える」。 それによって、「要素(=サブシステム)に流れる刺激が変わる→要素が 自律的な反応を起こす→問題の改善へ」という流れ  149
150. ヴァージニア・サティアの交流モデル • 取り込み→意味づけ→意義付け→反応という 構造 • 刺激(この発表で言うとフィードバックみた いなやつ)→それを受け取った人の解釈・評 価→結果に基づく行動 という構造としてモ デル化されている • 「ワインバーグのシステム洞察法」か「パー フェクトソフトウェア」あたりを読んでくだ さい  150
151. システム・ダイナミクス / システム思考  151 昨日ちょうど話があったっぽいから割愛！！
152. システム・ダイナミクス / システム思考  152 ヒューマンエラーの本を読んだ報告会 - Speaker Deck https://speakerdeck.com/o0h/funabashidev-1 関連する話題 これも読んで！
153. 「システム的に物事を見る」と面白そうなこと
154. 面白そう・可能性を感じること まだ自分の中で言語化しきれていませんが、 「もしかして、こういう風にソフトウェア設計を覗き込 んだら、見え方が変わってくるのではないか・・？」 と考えていたことをメモします  154
155. ① システムは自律的に変化する • システムは「外部からの刺激を取り込み、それに対して内部からの適 応を図る」という捉え方 • なので、操作者が「手取り足取り動かす」ものではなく、主体的に変化する • かつ、そうした変動は経時的に起こる • 刺激→取り込み→適応、というのがシステムに蓄積されていく  155
156. ② システムはブラックボックス • システムは「ブラック・ボックス」として動く • どういう評価基準・反応メカニズムを内部に持っているか？は、観察する側か らは見えない  156
157. ①+② => システムは「どんな刺激が流れ込むか」次第 • 利用者がシステムに対してできることは、「境界線の外界から働きか ける」だけ • しかも、そうして流し込んだ刺激がどう取り込まれるか・何を起こす か？はブラックボックス • なので、利用者ができることは「システムの周辺・環境を整えること」 だけになる  157
158. この見方でソフトウェア設計を考えると • あるクラス設計や結合を考えるときに、 箱庭のように「このクラスは、どうやって育っていくだろうか」と眺 めることができそう • シムシティみたいなイメージ。区画や建造物を決めることはできるし、それに よって人口や生活に方向づけは出来るが、細部までは決めきれない。勝手に動 く  158
159. この見方でソフトウェア設計を考えると • 例えば • 「このクラスをこのnamespaceにおいたら、どんなメソッドが生えてきそうか な？」とか • 「クラス名を◯◯Managerにしたら、どんなメソッドが生えるだろう？」 • 未来のチームメンバーがどんなメソッドを"アリ"と捉えそうか • このあたりは「シグニファイア/アフォーダンス」っぽい感覚も伴う  159
160. この見方でソフトウェア設計を考えると つまるところ、 「クラスの内部(=要素への還元的な見方)」ではなく、 「それをとりまく環境が、どのような変化を促すか」 ・・・で掴めると、何か面白そうじゃないですか？？  160