NISHIO Hirokazu[Translate]
思考の結節点2025-05-03
この二つの関連

なぜそうなのか?
PrototypingどまりでなくPerformingするためには既存のシステムに対するembeddingが必要
この表現だと「リスペクト」がなんなのかよくわからんよね、精神論的と捉えられるかも
「既存システムと接続することで価値を発揮するアイデア」が価値を発揮するためには「既存システム」を理解する必要があるということ、当たり前だよね

o3
評価関数の違いを可視化せよ
「リスクを取って注目を集める=価値」という個人の尺度と、
協調コスト法的リスクを最小化しつつ成果を出す=価値」という組織の尺度はしばしば衝突する。
まず双方の評価軸を言語化し、比較できる形で提示するとミスマッチが早期に発見できる。
o3は分けてたけど下記もほぼ同じnishio
起業志向で「スピード独自性」を最重視する個人と、
安定志向で「再現性合意形成」を重視する組織では、
同じ成果でも評価ポイントが異なる。
ギャップを放置すると『摩擦コスト>成果』となり、協働解消が最適解と判断されやすい。
若年期ボーナス”は消耗品
若手なら許される「失敗回数の多さ」や「尖った言動」も、年齢とともに評価が急速に反転する。
ボーナスの残量を意識し、失敗許容量が減る前に「注目」を「信頼資産」に転換する設計が必要。
法的・倫理的リスクは、本人だけでなく関係者全体に波及する。
「自分は平気」でも“巻き添えロス”を嫌う周囲からは敬遠される
“資産”への転換フローを作る
アイデアや注目度を短命で終わらせず、
小規模検証 → 成功パターンのテンプレ化 → ノウハウやツールとして再配布
の流れで資産化する。
この流れが適切かどうかは微妙nishio
これにより「話題性だけの人」評から脱し、組織側の説得材料にもなる。
協調コストを KPI として計測
周囲がどれだけ追加工数・火消し対応を強いられたかを数値化し、自ら改善目標を置くと信頼回復が早まる。
“自分のアウトプット単体”ではなく“総コストに対する総価値”を意識することが鍵。


AとBがコミュニケーションに問題を起こした場合、まあどっちもどっち
AがB, C, Dと問題を起こした場合、Aが悪く見える
組織はその中にいる人たちが長期にわたり「互いにコミュニケーションに問題がない」を続けることによって信頼のネットワークを形成している
個人Aと個人Bはコミュニケーションに問題がないとして
BがAを自分の所属する組織に紹介してメンバーCと問題を起こしたとする
このときDやEはCと「互いにコミュニケーションに問題がない」を続けて来ているので、当然「Aが悪い」と判断する
Bにとって、AとC,D,Eの対立の板挟みの構図になる
これはめんどくさい
C,D,EからはAをつれてきたことで信頼の低下が起きる
明示的に制度化されていない紹介者責任制
これはAがBの財布のお金をとって消費したように見える
連帯保証人のようなもの、Aが起こしたトラブルによるコストはBが支払っている
これが複数件観測されると「Aはそういうトラブルを起こしがちだ」という認識が広がるので、紹介をしなくなる
全然違う文脈の似た構図として、他人を不快にさせるゲームプレイヤーを自分たちが楽しくゲームしてる場には招かないよね、という事例があった
社会資本の拡大再生産の逆をやってるんだよな
>DとSの取引が起きた後に、両者のハピネスが増加することは必要条件
>取引が良い結果につながらなかった場合に、仲介者Mに対する信頼が低下するから
短期的に「若者にありがちな無謀さ」で獲得したリソースを、増やさないで燃やしてしまう、的なもったいなさ
「既存システムを理解する」こと
そんな難しいことではない
平均的な知能のホモサピエンスが平均的に実行できてるメカニズムなので
システム理解能力が高いならよりよく理解できるはず
これはU理論U曲線モデルにおけるDownloading
自分の思い込みの枠に囚われていると理解できない
「こうであるべきだ」「なってない」「既存システムがクソ」みたいに反応すると情報が入ってこないので理解できない
その状態でアイデアを言語化したりプロトタイプを作ったりしてもPresensingにおけるソーシャルフィールドとの接続が起きてないのでPerformingの段階で困難を抱えるのだな

"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]