設計と収束は少人数でやるのが良い
設計
良い設計は、大人数で行うよりは、少人数で基本設計を決めるのがよいように思う。
収束
Value（組織のビジョンや理念）を決める文脈
PFN Values Week
以下3つを1week行ったらしい
1: ランダムにアサインされた6人組がface2faceで議論
2: Slackによる全体議論
3: お弁当持って集まるランチ会議
モデレータには以下をお願いした
参加者から意見引き出せ
批評するな
停滞したら以下の質問をぶつけてみよ
議論の後、すぐにサマリーをSlackに共有せよ
あ、これも収束の過程書いてないsta.icon
気が向いたら。。。
IBM Values Jam
2003年
72時間の大規模オンライン議論
5万人の社員が本音をぶつけ合った
あ、どう収束させたかまでは書いてないなsta.icon
少人数でやったとは思うんだけど
収束プロセスまでは言及されてないわね
これも設計は少人数でやるべしって話
規模がでかいからといって別に統合・統一はしなくてもいい
みんな大規模システム、大規模システムと言うから、「大規模なものは大規模に作らなきゃいけない」という常識にとらわれ過ぎているところはあるのかもなという気はしますね。
Amazonのように自社のサービスだと、どんどん作りながら、大きくしながらみたいなことができる気がするんですけど、例えば銀行から受託を受けて、何千店舗に一気にドンみたいなことだと、事情が違うのかなという気もしたんですけど、そんなこともないんですか？ ちょっとずつ、アジャイル的に作りながらみたいのが難しそうなイメージがあります。
難しいのかどうかは証明できないので、できるんじゃないかなとは思っていますけど。それは、いつか僕らができたら「やれましたね」と言うしかないのかなとは思います。
+1。ウォーターフォールとプロジェクトマネジメントしか知らない老害ではなく、今のやり方考え方を知ってる俺達ならまあたぶん出来る気はするねsta.icon
明示的に言及されてはいないが、結局コミュニケーションコストがかかる
安藤忠雄というコンクリートの建物を作る人がいますけど、安藤忠雄が10人とか100人とかいれば、100倍いいものが作れるとか速く作れるとかいうことじゃないということですね。
倉貫：たぶん安藤忠雄同士で大喧嘩しますよね。