技術の創造と設計
https://gyazo.com/e22225904b6b40ee8d3ad2e855ada09f
ところてんさんのスライドで引用されて以来気になってた @tkdn: 詳細を作れない人は全体を作れない、いい言葉だな。ゼネラリストは元々何かのプロフェッショナルであってほしい @tkdn: マニュアル化の弊害の話。これは組織デザインでも出てきた、安定供給や労働統合の話にも近そう。ここでは "気" が結果として生まれて組織の文化となる、といった内容。例外を管理・ヒエラルキーに頼り過ぎるようになってしまうんだよな @tkdn: 隙間組織のくだりでよく見てた図が出てきた https://pbs.twimg.com/media/EztQohdVIAA9h6W.jpg
@tkdn: 技術の萌芽から衰退までが約 30 年、あとは失敗に絡んで 1/300 というキーワード、この二つの数字 @tkdn: 産業における、技術的失敗が及ぼした悲惨な事故が列挙される。公開されることで類似した事故がなくなるとも。ダイヤモンド・プリンセス号の火災事故の非難はカオスエンジニアリングに通じるものがありそう。普段からフローを決めておくの大事だよね。 @tkdn: 滅多にないけど、ちょっと心的負荷が高いデプロイでロールバック手順がめちゃくちゃ分かりやすく、オペレーションが想起しやすいだけでかなり安心感がある @tkdn: "日本には、責任追求が自己目的化しやすい風土にある" マジでこれ～～ @tkdn: "個人だけが原因で起こる失敗は軽微な事故、組織運営が原因で起こる失敗は重大な事故" @tkdn: "局所最適が全体最悪をもたらす" めちゃくちゃいい言葉だな。これだけ切り取ると賛否両論ありそうだけど。 @tkdn: JCO の臨界事故って発生前にアメリカから指摘受けてたんだな。失敗は薄々感じていた危機を口に出来なかった、つまり法体系自体が事実を覆い隠し事故を再発させた、と。 @tkdn: 「業務上過失障害」のように扱って、再発防止のためと言いながら、その実、責任追求のためだけに原因究明を行ってしまっていることが問題。真の科学的理解や体系だった知識が定着しなくなる @tkdn: 「バカと技術屋はデカイものを作りたがる、バカと技術屋は速いものを作りたがる、バカと技術屋は高いものを作りたがる」なるほど(笑) 悦に入っていい気になってると事故は起こる。 https://pbs.twimg.com/media/E0GalXQVEAAcLxP.jpg
@tkdn: 失敗事例の共有について、組織文化はボトムアップじゃ変わらないって書いてあるね。どうしても個別最適に陥って管轄内でのみ始末しようとしたがる。強力なリーダーシップで逆ツリーの上に情報を登らせないといけない @tkdn: そうそう、ただの事例共有に執着しただけの資料作成だとあまり意味がなくて、知識にするための体系だてた情報にしなくちゃ意味ないんだよなー。個々の失敗事例から上位概念まで体系化して水平展開させる。 @tkdn: 失敗知識データベース（すでに更新はないけど）。同じ（失敗における）階層の原因があらゆる分野で網羅する必要ではない、また同じ分野であらゆる原因階層を網羅する必要もない。位相にまあまあ均等に失敗知識がある構成になっている @tkdn: "本当の技術とは、自分で行動をして、「真の科学的理解」を得ることで獲得できるものなのである" @tkdn: "設計において暗黙の了解は要注意である"。図面や構成図だけじゃなくて、決定背景や意図が汲み取れる ADR のようなもの、やっぱり必要なんだよな。時間がないのでなかなかできないけれど。同期タイミングでなんとかしても結局口頭伝承で終わってしまう（徐々に薄まってしまう） @tkdn: "設計において暗黙の了解は要注意である"。図面や構成図だけじゃなくて、決定背景や意図が汲み取れる ADR のようなもの、やっぱり必要なんだよな。時間がないのでなかなかできないけれど。同期タイミングでなんとかしても結局口頭伝承で終わってしまう（徐々に薄まってしまう） @tkdn: 実際の設計では、要求機能から分析・分解を行い（制約条件のあぶり出しなど）、機能 ⇢ 機構 ⇢ 構造 ⇢ ... の思考をループ、適用と評価を繰り返しブラッシュアップさせている。機能から機構へと決定づけたものが写像、機構から構造へは展開と統合によって行われる @tkdn: "選択・決定のない設計は、設計ではない" @tkdn: 決定によって他の選択肢は消え選択した機構の蓋然性が 100% となる心理。迷いや懸念のために踏み出せない心理的障壁に、選択・決定という動作自体が作用して乗り越えられる。腹をくくって乗り越える胆力…なんかメンタルな話になってきた @tkdn: 選択・決定には種類があり、解まで選択肢のない直列な単純決断、いくつかの選択肢がある単純選択がある。一方で決定因子が次の選択候補を生む構造選択があり、この場合どういった決定を思考過程で行ったか、つまり選択の構造を分かりやすくすることが良い設計となる。 https://pbs.twimg.com/media/E0VSbcRVEAk4OvS.jpg
@tkdn: "世に行われる「決定」というものの多くは、いかに理路整然として筋が通っているように見えても、実際のところはそうでもない" ことが多い。蛇足に大事なことが書いてあるが、そういう実態に対して理屈を後からつけて公正で適正であるとするのが問題 @tkdn: 機能領域では抽象度が高く、機構・構造領域では実現手段・実物にする。ただこの流れには行きつ戻りつが必ず含まれる。 https://pbs.twimg.com/media/E0VaVM_VkAAKrw6.jpg
@tkdn: 要求機能から機能へ、機能分解から機構への写像、展開され機構へと総合されて全体俯瞰となる平面の思考展開図、非常に良さそう。生産性をどう測ったか分からないけど、ソフトウェアをつくるうえで生産性が 10 倍になったらしい（本当？？ @tkdn: 要求機能から機能へと分析・分解していく行為、ユーザーストーリーマッピングとも言えるし、それらを現実の設計に落とし込んでいく作業が写像と言える。それらが統合されて機能全体を俯瞰した設計となるのはまさにソフトウェアのそれだね！ @tkdn: 本書では、設計活動における、知識・山勘・経験・好み・主張など種を想念源と呼んだ。様々なクラスタから設計の思考平面にプロットしていくとそれらには関係線が生まれない。これら全体に脈絡をつけることこそがまさに設計である @tkdn: 仮説立証における全体の脈絡のつけ方は「エイヤ」3/1000 の成功率だと考えるとほとんどの脈絡づけは失敗に終わる。"うまくいく脈絡は論理的な構造をしているが、その脈絡は論理では見つけられない" = トライ・アンド・エラー = 仮設立証に他ならない @tkdn: 設計者は論理的に設計を導き出しているかのような誤解があるが、実際には直観と逆演算思考で設計をしている。直感ではなく直観。 @tkdn: 直観とはひらめきではなく、頭を振り絞って考えに考え、考え尽くしたあとに検証を重ねてあらゆる行動に対して「真の科学的理解」を得ることで発揮される。 @tkdn: いつもメンバー集めてブレストしましょうっての悪手なんだよね。課題の重要性を理解した、分野や考え方・専門性もがまったく違う人を集めなくてはならないし、強度も問題。課題に対して意欲的ではない人を入れてブレストしても全く意味がない @tkdn: 着想を発展させるためには、思考演算・思考探索・仮想演習の３つが必要になる。 https://pbs.twimg.com/media/E0acgnVVIAU4PUe.jpg
@tkdn: 解像度を上げる、抽象度を高くするなど普段から使っているけれど、これ着想をまとめる（もしくは他人の設計を理解を理解する）ために、上位概念までのぼってから別の下位概念へ降りてくことを確認したりする作業に他ならないかも @tkdn: 設計能力を高めるために普段から意識できることは、トータルエンジニアリング（全体を定性・定量的に捉える）、エンジニアリングセンス（いつも使う計算式なら結果を覚えておく、知る限り総動員するなど） https://pbs.twimg.com/media/E0gn1HxVcAMxoLA.jpg
@tkdn: 仮想演習 ＝ 始点から終点まで脈絡をつけた後も繰り返し制約条件のパラメータを変えたり影響を考えたり、予備的脈絡を準備したり、特にリーダーは予備的脈絡を多く有し仮想演習は必須の資質 https://pbs.twimg.com/media/E0gn1r1UUA0UiaT.jpg
@tkdn: 課題設定＝問題点の摘出を行う→課題の選択と決定を行う。曖昧ではなく具体的に入りこんで設定する。 頭に抽出しを作る＝大局を分類し新しいものへ再構成する仮想演習を繰り返すと知見が蓄積する。先見性そのものである。
人生を設計する＝人間の記憶力は 5 年で半分になると心得よ。
@tkdn: 思いつきを記録する＝一度消えた思いつきは二度と再び出てくることはない。一度徹底的に考えたことをまた考え直すのはムダ。なので記録する 裏図面を作る＝製作指示図、結果図、迷い図、伝承図など（言葉の発祥などは日産が使い始めたらしい）
@tkdn: 設計において「よく分からないが口頭伝承でこうなっている」という曖昧な部分をそのまま曖昧にしておくと大きな事故が起きやすい。後続の設計者が欲しいものに対応する設計図と情報の支援は本当に大事だねえ @tkdn: "論理ばかり振りかざす人間は、実に困り者である。論理は後付け、理屈付けであることをユメユメ忘れてはならない" @tkdn: 4 章、思考の種だしからくくり図からの関連図、そこから思考展開図を作戦する実践。5 章は現代日本におけるものづくりへの提言のような内容。コアな部分は過ぎたのでさらっと読んでる @tkdn: デジタルやソフトウェアにおいては "動態保存" というのが難しそうだよね。ソースコードなら git などでスナップショットを取れるけど、動作環境などはちょっと難しそう。ソフトウェアの場合、カオスエンジニアリングというまた別の手法が発達してるから独特なのかも @tkdn: "見せない・しゃべらない・触らせない" は同意しかねるかなぁ。"バカと技術屋はしゃべりたがる、変えたがる" は同意するけど(笑) 作り上げた技術を外に出さないというのを至高とする文化がソフトウェアにはない気がするけどどうだろ。むしろ独自で開発した何かを使う方が危険なんじゃないか @tkdn: 技術を毟り取れる場を作るというのも古き良き職人の技を見て盗むみたいな印象を受けてあまり賛同できないかな。同期するポイントを適切に設ければある程度は伝達可能だと思う。惜しみなく何でも give/take できる関係性はもちろん必要だけど。 @tkdn: 読了。技術屋が考えるべき思考訓練や失敗を下敷きにして失敗に限らず暗黙知をどう表出すれば伝播可能か、など技能に付随したメタ能力の訓練に近い。既存知識のモデリングや記憶定着について科学的に考えていた、エンジニアの知的生産術に近いものを感じた