良いプロセスとは
#設計 #アイデア #「〜とは何か」とは #エンジニアリング #問題解決
出典:
@tenjuu99: スクラムにしろUXにしろうーんってなるのは、結局どうやって優れたソフトウェアが生産されるかについてはなにも言えないからなんだよな。Excelがどうやって作られかとかSmalltalkがどう生まれたかとか、UXとかスクラムとかのプロセスから出てきたわけではないしそういうところから出てこない。
良いプロセスが悪いアイデアを救うことはない
どちらも適応的プロセスなんだけど、適応っていっても最初はどうするの。何かが環境に適応に至るまでの過程ってもっと多様で、その生産物がとる過程というのは、それが配置された力関係から自然と決まるはずで、過程にたいして規律をもって介入したからといって優れたソフトウェアになるとは言えない。
#Smalltalk_MVC
#戦略の失敗は戦術で補うことはできない
koushisa.iconの解釈
何を作るべきか、という問いには方法論や手法、プロセスで応えられない
方法論はWhyへの一方通行であり、方法論の変化によってWhyが変わることはありえないため
アイデアは人の創造性から湧くように思えるが、おそらく違う
アイデアを出した人はそれが唯一無二の正解などという確信は持ってない
仮説検証として一回出してみて、それが受け入れられるかを試してみたい
内省を繰り返しながらブラッシュアップされていく
現在のアイデア→振り返りの過程で次のアイデアが生まれる
アイデアは最初から完全な形で生まれるのではない
アイデアの価値は「検証」してみないとわからない
アイデアのテンプレート化に対する批判
方法論を語る前にそのアイデアを出した人の心情やバイアス、未検証なことに耳を傾ける
手段の固定化を防ぎたい
問いかけ
多様性や負債を排除せずに受け入れる
解像度が高いと手段の多様性が生まれる
つまり、設計は生成的にならざるを得ない
エンジニアリングの本質は問題定義能力
作られたものが環境に適応し、環境が作られたものに適応するのが、よい状況
これは人と人の間、あるいは人と社会の相互作用の中から湧き出す
プログラム以外にもあらゆる観点でメンタルモデルと一致した状態を目指す
設計
"良いプロセス"とは
アイデアを100%綺麗に実現することではない
その領域に専門性があり、要求分析からアプローチのトレードオフを見いだせる
アイデアにフィードバックを返し、それを基に次のアイデアを生めるフィードバックループを生み出せるもの
脇道にそれることをよしとする
環境のニーズに適応する、または環境から適応してもらえるようにPDCAやOODAを回し続けることそのもの
専門家の価値はドメインとレンジをつなぐ関数のパターン化と選択肢の具象化
先ずプロセスを効率的になるように再構築してから自動化に着手せよ
プロセス中心設計