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

組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する PHPカンファレンス福岡2025 Hideki Kinjyo GitHub: o0h / X: @o0h_
[公開用] v1.2.2

今日のお話 2

今日のお話 3

俺みたいな「ソフトウェアも組織も同じように考えたい」ってやつ、他に、いますか 4

なぜ、そんな話なのか「フィードバック」とやらに注目すると、何かに役立てられるんでない？ソフトウェアにも組織にも 5 今日のお題

おしながき §1 定義:フィードバックって何だ！？ @5分 §2 活用:フィードバックを設計に活かす @10分 §3 発展:組織もソフトウェアも @8分
§4 エピローグ @3分 6

自己紹介 • 金城秀樹 / きんじょうひでき • GitHub: @o0h / 𝕏
: @o0h_ • 好きなFWはCakePHP • アイコンは美味しい鮭親子丼の写真です • 最近はPodcastをやっています • ハッシュタグ: #readlinefm

§1 定義:フィードバックって何だ！？ §3 活用:フィードバックを設計に活かす §3 発展:組織もソフトウェアもエピローグ

ここからの話このトークにおける「フィードバックとは何か」を話していきます。 1. 形式・構造的なフィードバックの定義 2. フィードバックにはどんな意義があるのか 9

フィードバックって何のこと？そもそも！

最初に結論フィードバックとは何かをすると、何かをされた対象から、反応が返ってくる構造のこと 11

いくつかの例を見てみましょう 12

フィードバックの素朴な形 13 こんにちは！ (にっこり)

フィードバックの素朴な形 14 ラーメンくださいへい、お待ちぃ！

↑ 概論ここまで ↓ ここから具体例 15

組織とソフトウェアに見るフィードバック

組織で見るフィードバック① 17 こういうのが欲しい〜作ったぞ〜〜！ PdM DEV

組織で見るフィードバック② 18 最近多い顧客の声を教えて集計データどうぞ！ PdM CS

ソフトウェアにおけるフィードバック① 19 クラスA クラスB メソッドX 結果

ソフトウェアにおけるフィードバック① 20 クラスA クラスB メソッドX 結果何かをする何かをされた反応が返る

[ソ]フィードバック① $fp = Utils::tryFopen($file); 何かをする何かをされた反応が返る

[ソ]フィードバック② $version = $this->version; プロパティへのアクセスも「取得結果」がある反応が返る何かをされた
何かをする

[ソ]フィードバック③ try { $fp = fopen($file, $mode); } catch (Throwable
$e) { $ex = new RuntimeException( sprintf( 'Unable to open %s w/%s', $file, $mode, ), previous: $e); } 例外のthrowもフィードバック反応が返る何かをする

現時点では、「小さなフィードバック関係が沢山あるんだな」を感じてもらえればOK 24

(形式的な定義は分かったけど) フィードバックにはどんな意義があるの？何をもたらすのか？

フィードバックの意義と働き「投げて返ってきたものを受け取る」コレだけなら注目するまでもない 26

フィードバックの意義と働き「投げて返ってきたものを受け取る」コレだけなら注目するまでもないフィードバックは何をもたらしているのかに注目したい 27

フィードバックの意義と働き自身の目的を達成するために適切な相手に働きかけ、そのフィードバックから自身の行動を調整できることが、フィードバックの意義 28

フィードバックの働き 29 お、良いボタンがある。押してみようかな。ポチ〜押すだけで 1000万円当たるボタン押す ◯◯サービスに
登録されました (月額30万円) 視覚に訴えるめちゃヤバ案件 (変化)

フィードバックの働き受け取った後に、次の行動が促される 30 めちゃヤバ案件逃げる？問題を取り除く？信じる？ ◯◯サービスに
登録されました (月額30万円)

フィードバックの働き -より俯瞰して- 31 #phpconfuk #hall_hz で「FFBなう」って呟いて！今！！ 🐦「FFBなう」私皆様

フィードバックの働き -より俯瞰して- 32 #phpconfuk #hall_hz で「FFBなう」って呟いて！今 🐦 なぜ、「呼びかける」という
行動をしたのか？

フィードバックの働き -より俯瞰して- 33 そもそもの行動には、起点となる目的があるで「FF 登壇した痕跡残してぇ〜〜

登壇した痕跡残してぇ〜〜フィードバックの働き -より俯瞰して- 34 行動の結果としてフィードバックを得る次の行動は、
「目的」に照らし合わせて調整される「FFBなう」って呟いて！たくさん流れてきた！！ RePost.. RePost.. RePost.. RePost..

フィードバックの働き -より俯瞰して- 35 行動の結果としてフィードバックを得る次の行動は、「目的」に照らし合わせて調整される
登壇した痕跡残してぇ〜〜「FFBなう」って呟いて！あんま流れてこない。。。早く！！「FFBなう」って呟いて！

組織とソフトウェアに見るフィードバック

組織で見るフィードバック 38 法務営業 ★法務には、自分のための目的があって業務効率を上げるぞ！

組織で見るフィードバック 39 ★ 行動を起こし、営業に働きかけを行う業務効率を上げるぞ！契約書の雛形を更新したよ！

組織で見るフィードバック 40 ★ その結果が、フィードバックとして返ってくる契約書の雛形を更新したよ！使いにくい！業務効率を
上げるぞ！

契約書の雛形を更新したよ！使いにくい！組織で見るフィードバック 41 ★ 目的に合わせて、フィードバックを次のアクションにつなげる契約書の
雛形を更新したよ！共有・説明会を開こう！業務効率を上げるぞ！

契約書の雛形を更新したよ！契約書の雛形を更新したよ！組織で見るフィードバック 42 ★
目的に影響を与えないフィードバックは影響を及ぼさない経費精算大変すぎる〜ふーん業務効率を上げるぞ！

[ソ]フィードバック $version = $this->getVersion(); if ($version->lt($minVersion)) { return false; }
return true;

return true; 「バージョンどうですか？」の入力 $version = $this->getVersion(); $version->lt($minVersion)

return true; true or falseのフィードバック $version->lt($minVersion)

return true; 入力者側が、フィードバック内容を見て次のアクションを行う return false; return true;

[ソ]フィードバック function isSupported() { $version = $this->getVersion(); if ( $version->lt($minVersion)
) { return false; } return true; } この手続きは「バージョンで判定する」という目的がある function isSupported()

§1 まとめ

このトークでの定義フィードバックとは何かをすると、何かをされた対象から、反応が返ってくる構造のこと 49

もたらすもの自身の目的を達成するために適切な相手に働きかけ、そのフィードバックから自身の行動を調整できることが、フィードバックの意義 50

ここからの話「フィードバックを設計に活かす」ための観点を話していきます • フィードバックを受け取った後に何をしているか？が肝 • 受け取った後に「頑張っている」か「あまり苦労しない」か • 良いフィードバックであれば、苦労しないでそのまま使える • 良いフィードバックを受け取れる構造を作り込んでいく
• 適切な責務分割を促し、凝集性を高める 52

(意義が分かったとして) フィードバックから何が分かるの？何をもたらすのか？

フィードバックが「分かる」と何を得られるのか 54 入力者システム何かをする反応を返す (フィードバック) こういう構造があって何かをされた
最終出力

入力者フィードバックが「分かる」と何を得られるのか 55 こう機能するところにシステム何かをする反応を返す目的調整
何かをされた最終出力

入力者最終出力フィードバックが「分かる」と何を得られるのか 56 この内容に注目してシステム何かをする反応を返す目的
調整何かをされた

入力者最終出力フィードバックが「分かる」と何を得られるのか 57 ここの構造を変えるヒントとするシステム何かをする反応を返す目的
調整何かをされた

ヒントはどこに眠っているのか「本来の目的」と「フィードバックを受け取った後」に注目する (どんな調整をしているか？どのくらい複雑か？) そこには「本来の目的とのギャップ」がある 58

入力者最終出力本来の目的とのギャップ 59 目的ここにギャップがあるから

入力者最終出力本来の目的とのギャップ 60 目的調整その調整にコストがかかる、という考え方

コストを下げるために良いフィードバックを良いフィードバックであれば、「本来の目的とのギャップ」が少なくなる良いフィードバックを生み出す構造をつくる = 良い設計をする 61

組織に見るフィードバックの活用例

組織で見るフィードバック 64 最近多い顧客の声を教えて集計データどうぞ！次の施策を考えるぞ〜企画会議 (データを読み解かないと。。) PdM
CS

組織で見るフィードバック 65 最近多い顧客の声を教えて集計データどうぞ！次の施策を考えるぞ〜企画会議 (データを読み解かないと。。) 本当に必要なのはコッチっぽい

組織で見るフィードバック 66 最近多い顧客の声を教えて集計データどうぞ！次の施策を考えるぞ〜企画会議受け取った後に「一手間」のコストがある (データを読み解か
ないと。。)

組織で見るフィードバック 67 最近多い顧客の声を教えて集計データどうぞ！次の施策を考えるぞ〜企画会議「入出力」の発生もコストと見なせる

分析結果を踏まえて • 目的: 良い企画を考える(企画会議で提案する) • 現状の実装: CSからデータを取り寄せ、自分で解釈する • オーバーヘッド: •
受け取り後の分析コスト • CSとの一往復(欲しい内容の指示、出力結果の受信) 68

受け取り後の分析コスト • CSとの一往復(欲しい内容の指示、出力結果の受信) 69 ここのコストの高さが、「組織の構造から生じる問題」の大きさ

受け取り後の分析コスト • CSとの一往復(欲しい内容の指示、出力結果の受信) 70 この構造を修正することで、コストの総和を下げられないか？

組織の出力を低コストで支える構造 71 企画会議構造を変更して、より自然な「適応」を促す顧客の声インストール済みグロース全体像インストール済み
次の施策を考えるぞ〜 PdM CS

ソフトウェアに見るフィードバックの活用例

ソフトウェアで見るフィードバック $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']]);

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で商品を取ってくる

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ステータスからエラーを判定＆処理を中断する

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); } 応答本文からエラーを判定＆処理を中断する

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']]); 商品情報を返す

受け取った後に「何をしているか」を分析するコントローラーが持っている仕事 • HTTPステータスからエラーを判定=>エラーを返す • 応答本文からエラーを判定=>エラーを返す • 商品情報を返す 78
Controller API Client 商品情報くれ〜取ってきた結果〜中身を精査しないと

目的ってコッチっぽくない？

本来の目的では無さそう！

本来の目的と非本来的なコスト $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); このあたりが「本題」で

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') { }

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']]); 「本題」は全体の半分に満たない！

分析から見えてきたことどんな問題が見えて来たのか • フィードバックを受け取ってからの処理が長い、煩雑 • => 目的のために利用するコストが高い(良いフィードバックになっていない) • 利用するために必要な知識が多様 •
HTTPステータス・APIレスポンスの形式、と複数のレイヤーにまたがる • => 知識の多様化は高機能化をもたらし、目的を曇らせやすい 84

分析結果を踏まえて • コントローラーは「商品情報を返す、ダメならエラーメッセージを」に集中させる • そのために新しいレイヤーを導入 • APIクライアントをラップしてエラー判定とかをよしなにやってくれる君 • 結果について持ち運んでくれる君(Resultオブジェクト)
85

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']); }

$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'); } 中身はコントローラーでやっていた処理と大体同じ

$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']); 利用目的に合わせた「ハイレベル」な表現で結果を返す

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']]);

構造が変更される元々は大きなコストがControllerで発生していたのが… 90 Controller API Client 商品情報くれ〜取ってきた結果〜中身を精査しないと
コスト高コスト低

「良いフィードバック」のための調整が行われ、均等化・減少した構造が変更される 91 Controller Gateway 商品情報くれ〜取ってきた結果〜 Result API
Client 中身を精査済み★ コスト激低コスト低コスト低コスト激低

§3まとめ

フィードバックに注目して分析＆設計する • フィードバックを受け取った後に何をしているかが肝 • 「何かたくさん頑張っているな」と思ったら、コストが高いと判断 • 目的に沿ったフィードバックになっていれば、コストが低くなる • 良いフィードバックを受け取れる構造を作り込んでいく •
適切な責務分割を促し、凝集性を高める 93

「フィードバックに注目する」ことの意義 • フィードバック(=何を受け取り、どう使っているか)には、自身に本当に必要なこと・やりたいことが詰め込まれている • ここに着目して、より抽象レベルの「目的は何？」を可視化していく • 頭の中だけで概念的に考えるだけでなく、「実際に目の前にある活動」から「コストが大きい？小さい？」を捉えるヒントになる
94

RT: 今日のお話 96

どちらにも通用するのはなぜか？どちらも「目的」「フィードバック」「調整」という仕組みを共通して備えている 97

どちらにも通用するのはなぜか？同じ仕組みを持つ = 同じ問題を持つ同じアプローチが通用する 98

全く別々でも問題が似ている問題は「要素間のやりとりから出るコスト」 (=> 受信後の調整コスト、やり取り自体のコスト) コストの総和が大きくなれば、トータルの出力が落ちる 99

やるべき事も似てくる「良いやり取り」のための構造を作る各所で、良いフィードバックを生み出させる 100

実験: 「組織設計の見方」と「ソフトウェア設計の見方」を越境してみる

再掲: 先程の例 103 最近多い顧客の声を教えて集計データどうぞ！次の施策を考えるぞ〜企画会議 (データを読み解かないと。。)

UMLで書いてみるとこんな感じ？ 104

UMLで書いてみるとこんな感じ？ 105 getterを叩いているだけ

UMLで書いてみるとこんな感じ？ 106 "ビジネスロジック"は自前で持っている

擬似コードにするとこんな感じ？ class PdM { private Cs $cs; public function createKikakuIdea():
Kikaku { $voiceCollection = $this->cs->getUserVoiceCollection(); // ͛͢ʔෳࡶͳͷͰ͜͜ʹ1,000ߦ͘Β͍ͷώϡʔϦεςΟοΫͳϩδοΫ͕ੜ͑Δ // $voiceCollectionΰχϣΰχϣɾɾɾͰɺ$kikakuΛಘΔ return $kikaku; } } } ので

アンチパターンぽくないですか？状況: • 「CS」は「顧客の声を取る」ための仲介者としてしか利用されない • その後、「PdM」は、複雑なビジネスロジックを適用する • 多分「集計して見やすくする」「考える」の仕事が入っていそうじゃない？ 108

「ドメインモデル貧血症」的な見方問題の形: • getterを提供しているだけでデータを使う知識がない • (悪い)結合や、(悪い)トランザクションスクリプトを誘発するなぜならば: • CSに「プロダクトを一緒に作る」という役割がない •
ゆえに、「ただgetterを公開しているだけ」に成り下がっているそれゆえ: • フィードバックを利用するためのコストを高めている 109

「機能の横恋慕的」な見方問題の形: • 自身よりも、他のオブジェクトの機能やデータにばかり関心がある • 低凝集なオブジェクトの典型的な症状(不吉な臭い) なぜならば: • 「顧客の反応にアクセスする」のは「CSの機能」という思い込み •
ゆえに、「わざわざCSを経由する」という教条的なコミュニケーションに陥るそれゆえ: • 必要なデータを得る際にオーバーヘッドが生じている 110

組織構造のアーキタイプこれらの要素を組み合わせて、組織の「構造」が作られる • 公式な組織 - 部門、部署 • 組織図上に現れる単位 • 準公式な組織
- 時限的なプロジェクト、委員会 • 部署・部門と境界線を同一としない集約 • 会議体 / 会議 - 情報共有、意思決定のための集まり • アジェンダありきの単発・連続の集合 • 非公式なつながり - 偶発的な交流、(構造に用いる場合には)意図的な交流の仕組み • 業務上の結合に閉ざされない関係 • 組織パターン「冷水機」スクラムパターン「おやつ神社」、Slackのtimesなども 111

どんな構造へのアプローチで、どう改善できる？ざっくりと考えて2つの方向性 1.「CS」を「プロダクト開発ドメイン」に組み込む 2.「顧客の声へのアクセス」を「CS」以外にも開放する 112

CS 1. 「CS」を「プロダクト開発ドメイン」に組み込む • 「プロダクト開発ドメイン」の拡張: CSの参画 • アーキタイプ「会議」や「チーム」でリファクタ 113
企画会議顧客の声インストール済みグロース全体像インストール済み次の施策を考えるぞ〜 PdM

2. 「顧客の声へのアクセス」を「CS」以外にも開放する • 「ロール-アクセスpermission」の見直し: PdMロールへの機能付与 • PdM-CS間の結合の解消 114 最近多い顧客の声を教えて
集計データどうぞ！次の施策を考えるぞ〜企画会議データを取り出して読み解く俺・・

共通する視点で見えてくるもの・改善方法がある • 組織の問題を「ソフトウェアっぽい知識」で解釈できた • フィードバックに着目した分析によって、コミュニケーションの在り方にメスを入れる • より「本来の目的」とのギャップが少ない状態を目指す 115

残っている話を回収プロポーザルに書かれているのにノータッチになっている話に触れます 117

残っている話を回収プロポーザルに書かれているのにノータッチになっている話に触れます 118

より一般化して捉えることの持つ力

(突然ですが) 統一理論って言葉があります 120

ChatGPT(GPT-5)の回答 121

一つの根本原理で、全てを理解する 122

「設計の小難しさ」をほぐしたいお仕事、難しいですよね 123

「設計の小難しさ」をほぐしたい - ビジネス領域、プロダクト領域の難しさ - 人間、組織領域の難しさ - 技術領域の難しさ 124 👀

「設計の小難しさ」をほぐしたいこれらに共通する「力の流れ」が見えてくれば、もっとシンプルに考えられるかもしれない 125

「設計の小難しさ」をほぐしたいこれらに共通する「力の流れ」が見えてくれば、もっとシンプルに考えられるかもしれない逆に言えば、そうしなければ、領域ごとの個別の理論を個別に暗記する、を強いられる 126

ここまでのトークで提示したものシンプルに考えてみる、の1つの例として「組織設計もソフトウェアも、実は同じように問題を見抜けるはずなんだ」というお話 127

「one of themな考え方」を超えて自分なりの「全てを説明できる見方」を手に入れた時、それは「とある1つの見方」を超えて「哲学」「美学」になる 128

「one of themな考え方」を超えて哲学 = 世界がどのようになっているか、という見方美学 = 美しいと感じるもの、それはなぜか？の探求
129

色々な「哲学」の例 130 t-wadaさんの『技術選定の審美眼』 https://speakerdeck.com/twada/understanding-the-spiral-of-technologies-2025-edition

色々な「哲学」の例 131 k1LoWさんの『ソフトウェア開発におけるインターフェイスという考え方』 https://speakerdeck.com/k1low/phperkaigi-2025

色々な「哲学」の例クリストファー・アレグザンダーの「パタン・ランゲージ」「利用者参加の原則」なぜ、建築の枠組みを超えて現れるのか 132 顧客が本当に必要だったもの

お伝えしたかったこと自分なりの哲学を持つことで、生み出す設計に筋が通る。それが設計の地力の向上につながる 133

お伝えしたかったことなにか「哲学」と呼べる1つの軸を持つ。色々な問題に素振りしてみる。より深淵を覗き込んで、磨きをかけていく 134

まとめ

最後に言いたいこと「フィードバックに着目せよ！」という方法、面白いと思うので、ぜひ遊んでみてください！ 136

最後に言いたいことが！！！そんなのはあくまで一例。自分なりの哲学を見出してみてください！ 137

おしまい！お付き合いいただきありがとうございました!!

ご出演の皆さん from ゆるかわいい無料イラスト素材集 | いらすとん https://www.irasuton.com/ PdM CS 法務営業
DEV

Appendix-Ⅲ 色々な「システム」

What's this • 今回の話の背景に、「システムっぽいものとして対象を見る」という感覚があります • 発表では触れられていませんが、枠外でちょっと整理しようかなと・・・ 141

システム？ 142 https://ja.wiktionary.org/wiki/システム

「システム」一般に対するアプローチ • システムには • 「要素」がある • 要素同士の「繋がり」がある • 繋がった者同士の「相互作用」がある
• 分析した要素の1つ1つだけを見ても、システムの理解は得難い • 代わりに、「繋がり」「相互作用」を見る必要がある 143

色々なシステム

サイバネティクス(古典的な) • https://ja.wikipedia.org/wiki/サイバネティックス • 「観察」「行動」「フィードバック」と「フィードバックを受けて制御する」という構図 • 「フィードバックを結果として受けとり、自己の調整を行う」という世界観
145

一般システム理論 • 還元主義(=要素を観察すれば、システムのすべてがわかる)を超えて、「システムとは、要素の集合以上の意味を持つもの」の世界観 • 「一般的」な見方として、全体性・相互的な依存等の観点を適用するもの 146

G・M・ワインバーグの「一般システム思考入門」 • 「観察」を行う主体もシステムの一部であるという立場 • ("ネオ・サイバネティクス"と通ずるものがありそう • システムは、(依存関係にある)対象を「観察」して、自身の変化・適応を自律的に行うもの • また、フラクタルな構造を持ち、ミクロなシステムは全て上位の「環境」の一
部である、という論も展開している • 「コード→パッケージ→ソフトウェア→インフラを含めたITシステム→ビジネス要求→ マーケットや現実世界→自然法則・宇宙」という感じに • 下位だけを見ると「変更」であっても、上位に対する「適応」にしか過ぎない 147

ノーマンの「行為の7段階理論」 • ゴールの形成 → 意図の形成 → 行為の詳細化 → 行為の実行 →
外界の状況の知覚 → 外界の状況の解釈 → 結果の評価 • これも「フィードバックがあったときに、それを拾って、判断し、次の行動に」という世界観と一致する 148

家族療法の「システムズアプローチ」 • 「問題は、個別の対象(クライエント)にあるのではなく、それをとりまく環境にある」という考えに基づくアプローチ • 例えば、「不登校の子ども」は「本人に原因がある」のではなく「家族の接し方」に方策を求める、みたいな世界観 • つまり「個別の要素そのもの」ではなく「環境に変更を加える」。それによって、「要素(=サブシステム)に流れる刺激が変わる→要素が
自律的な反応を起こす→問題の改善へ」という流れ 149

ヴァージニア・サティアの交流モデル • 取り込み→意味づけ→意義付け→反応という構造 • 刺激(この発表で言うとフィードバックみたいなやつ)→それを受け取った人の解釈・評価→結果に基づく行動という構造としてモデル化されている
• 「ワインバーグのシステム洞察法」か「パーフェクトソフトウェア」あたりを読んでください 150

システム・ダイナミクス / システム思考 151 昨日ちょうど話があったっぽいから割愛！！

システム・ダイナミクス / システム思考 152 ヒューマンエラーの本を読んだ報告会 - Speaker Deck https://speakerdeck.com/o0h/funabashidev-1
関連する話題これも読んで！

「システム的に物事を見る」と面白そうなこと

面白そう・可能性を感じることまだ自分の中で言語化しきれていませんが、「もしかして、こういう風にソフトウェア設計を覗き込んだら、見え方が変わってくるのではないか・・？」と考えていたことをメモします 154

① システムは自律的に変化する • システムは「外部からの刺激を取り込み、それに対して内部からの適応を図る」という捉え方 • なので、操作者が「手取り足取り動かす」ものではなく、主体的に変化する • かつ、そうした変動は経時的に起こる •
刺激→取り込み→適応、というのがシステムに蓄積されていく 155

② システムはブラックボックス • システムは「ブラック・ボックス」として動く • どういう評価基準・反応メカニズムを内部に持っているか？は、観察する側からは見えない 156

①+② => システムは「どんな刺激が流れ込むか」次第 • 利用者がシステムに対してできることは、「境界線の外界から働きかける」だけ • しかも、そうして流し込んだ刺激がどう取り込まれるか・何を起こすか？はブラックボックス •
なので、利用者ができることは「システムの周辺・環境を整えること」だけになる 157

この見方でソフトウェア設計を考えると • あるクラス設計や結合を考えるときに、箱庭のように「このクラスは、どうやって育っていくだろうか」と眺めることができそう • シムシティみたいなイメージ。区画や建造物を決めることはできるし、それによって人口や生活に方向づけは出来るが、細部までは決めきれない。勝手に動く
158

この見方でソフトウェア設計を考えると • 例えば • 「このクラスをこのnamespaceにおいたら、どんなメソッドが生えてきそうかな？」とか • 「クラス名を◯◯Managerにしたら、どんなメソッドが生えるだろう？」 • 未来のチームメンバーがどんなメソッドを"アリ"と捉えそうか
• このあたりは「シグニファイア/アフォーダンス」っぽい感覚も伴う 159

この見方でソフトウェア設計を考えるとつまるところ、「クラスの内部(=要素への還元的な見方)」ではなく、「それをとりまく環境が、どのような変化を促すか」・・・で掴めると、何か面白そうじゃないですか？？ 160

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

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

More Decks by hideki kinjyo

Other Decks in Programming

Featured

Transcript