経験主義的アジャイル思想

ローカルローカル @tebasak_i

そうなんだよなー。最初の計画通りいくのはよほど鉄板な案件。成功には実践フェーズのコミュニケーションが肝。RT @takaosue 事業計画もまったく同じだと思った！　RT @zerobase すべてのデザイナとアジャイル実践者に読んで欲しい：『橋はなぜ落ちたのか』第一章 はじめに

石橋秀仁 @zerobase

『橋はなぜ落ちたのか』いきなりクリストファー・アレクザンダーが出てくる。当たり前の様に。あ、ちなみにこの本を読むのは三度目かな。 #empiricagile

旧姓なごや @Macau_chan

御意。「1」を「2」に出来ても「0」を「1」には出来ない。RT @zerobase 「手を動かす」のが下賤な仕事だというエリート主義が「MBA的」ビジネスエリートにある限り、彼らに新規事業は無理。既存事業のビジネスアドミニストレーションはうまく出来るかもしれないが、新規事業は無理

石橋秀仁 @zerobase

経験主義／懐疑主義の精神。無知の知。分からないことを分からないと認める謙虚さ。 #empiricagile

石橋秀仁 @zerobase

超線形設計プロセスと、ゼロベース式経験主義アジャイルの違いは、ご破算(不連続な手戻り)の許容 #empiricagile

石橋秀仁 @zerobase

ペトロスキーは設計の失敗を普遍的に論じる上で、もっとも情報が得やすく、事例として心に残りやすい分野(素材)として、構造工学／構造力学という題材を選んだ。ここが邦題『橋はなぜ落ちたのか』の罪深さ。「設計」を普遍的に論じようとした問題意識を矮小化した #empiricagile

石橋秀仁 @zerobase

構造工学という素材を使って「設計」を普遍的に論じた書だから、あらゆるエンジニアやデザイナの仕事に通じるのが『橋はなぜ落ちたのか』だと思う。 #empiricagile

石橋秀仁 @zerobase

『橋はなぜ落ちたのか』pp.17引用 設計ミスが起こるのを避けることはできない。概念設計には最初から誤っているものもあり、製図板上で自己点検して誤った考えを捨て去るためには、設計者の自己批判能力こそが働かなければならない。 #empiricagile

石橋秀仁 @zerobase

16年前の古典にアジャイルの本質が書かれてる気がする #empiricagile

石橋秀仁 @zerobase

ほんと『橋はなぜ落ちたのか』とゆう邦題はどうしようもないな。この邦題は許せん。

岐阜の方の人 @doubledispatch

そうかなあ。工程跨いて同一チームの場合、現工程終盤から先発担当に次工程のパイロットさせるのは、どこも同じでは。会社や組織跨ぐ文脈前提？QT @HHany:RT @4EX:ウォーターフォール型開発の最大の問題は上流工程のアウトプットを待つという態度が刷り込まれてしまうこと。 略

Masanori Kusunoki / 楠 正憲 @masanork

個人的に「製造業の重層下請け構造が日本を強くしたのに、なぜITじゃ駄目？」って問いに沈黙が返ってきたのが残念。個人的に用意してた解は「モノの取引では生産性向上によるレントが継続的に生産者余剰となるが人月取引は発注者のものとなるため競争の軸が歪むから」だった #sentanmeti

MASA Nakamura @masayang

@masanork 製造業の生産(Production)はITでいえば本番運用(Production)。開発(Development)を重層下請にすることは製造業では有り得なかったが、なぜかITではそこを勘違いしている。

石橋秀仁 @zerobase

設計の改悪。当初の設計意図に立ち返って全体を改めて設計し直すことなしに、部分的な設計変更をするとき。ゆえにコンセプトの一貫性は重要。 #empiricagile

石橋秀仁 @zerobase

『橋はなぜ落ちたのか』pp.95 どんなに無数の成功した設計がそこから導き出されたとしても、いかなる仮説も決して議論の余地なく証明されたことにはならない。しかし、仮説の反証はたった一つの失敗（解析上でも現実でも）で足りるのであり、このことを認識するのは技術者の責任である。

石橋秀仁 @zerobase

『橋はなぜ落ちたのか』pp.111 引用：熟練工や職人と一緒になって試作品からついにはプロトタイプまで作り出していく発明家と設計家の能力は、経験の積み重ねと経験的センスにすべて依拠している。 #empiricagile

石橋秀仁 @zerobase

『橋はなぜ落ちたのか』pp.111 引用：スケッチ、寸法決め、製作、試験、ディバッグは、ほとんど何の理論もなしに進められる設計活動であり、失敗を重ねて成功へと至ることができる。 #empiricagile

Masanori Kusunoki / 楠 正憲 @masanork

建設業のアナロジーでいうと設計は多重下請け構造にはなくて、あくまで施工フェーズ。この指摘はソフトウェア開発が設計なのか製造・施工なのかが大きな論点 @HYamaguchi

Masanori Kusunoki / 楠 正憲 @masanork

コンピュータ分野の失敗学に興味があれば本書が古典。ACM Risks Forum事例からの抜粋で古いが参考になる #sentanmeti / Amazon.co.jp： あぶないコンピュータ―頻発するコンピユータ事故からの教訓: ピータ… http://htn.to/ezkCZ6

羽生田 栄一 @HHany

うまい組織はWF超える裏工夫をしている。それを表立って体系化する営みがアジャイル。@doubledispatch: 工程跨いて同一チームの場合、現工程終盤から先発担当に次工程のパイロットさせるのは、どこも同じでは。@4EX:WFの問題は上流アウトプットを待つという態度の刷り込み

tkskkd.deso | Takeshi Kakeda @kkd

@HHany それでもWFを表で標榜する理由って何なのでしょうかね？

motohasi(ari) @motohasi

@kkd @HHany WFでありたいという組織や方々に対する説得のしやすさ、政治的／営業的／戦略的なアプローチなのではないでしょうか。

MASA Nakamura @masayang

@yamasan007 だったらなおさらのこと「業務要件確定」「基本設計確定」という手戻りを許さない順序で作っていくのは「顧客にとって」不利なのでは？

Yuki Sakurai @yuki_samurai

PMPとか持っていてもダメダメな人も多い（PM=Prj Managementなら） RT @masayang: クソ野郎がPMとかやるから業界がいつまでもクソなんだよ

羽生田 栄一 @HHany

裏仕事では済まない黒船の襲来では。あと体系化というより戦略的アプローチという方がしっくりきますね。学問ではないので。RT @motohasi: @kkd @HHany WFでありたいという組織や方々に対する説得のしやすさ、政治的／営業的／戦略的なアプローチなのではないでしょうか。