デブサミ2006-2日目の所感まとめ
1日目のセミナー感想について2日目もまとめてみました。
◆プロジェクトオートメーション〜コンピュータもチームメンバだ！〜（角谷さん）
態度としての自動化
- 石井勝（まさーる）さんによるデキるエンジニアになるための条件
- 単調かつ繰り返し作業をコンピュータにさせるように考えられるようになる
- 素振りが必要。いきなり自動化やれってできます？
PAとPF
- プロジェクトファシリテーションは、個人以上の力を引き出すための場作りを行う技術
- コンピュータは奴隷的な作業を行う代わりに、人は「人らしい」仕事を行う
- あなたにしかできないこと
- 陰と陽、つまり、成功の道！
自動化重要
- ソフトウェアの公理
- 価値あるもの
- 動作可能であるもの
- 提供し続けること
- リリースまでが開発
- 設計成果物はソースコードであり、「人」が作成する
- ビルド成果物はビルドファイルであり、「マシン」が作成する
- つまり、人とマシンのコラボにより開発が進むと考えられる
誰が重要？
- アーキテクト
- 開発者全員がアーキテクトになるべきで、全員が責任を持つ必要がある！
所感
この内容、技術的なことは語ってないだけにすごく分かりやすかったです。やっぱ、技術云々以前に考え方や態度に関して説明するほうが効果があるような気がしました。
個人的には手動より自動でやるほうが変なリスクが発生しないという考えでツールをいろいろと作ってきましたが、この考え方に賛同する人が意外にも少なかったのですが、それはまず今回角谷さんのような説明により理解を得る努力を怠っていたことが原因であった気がします。今度何かの機会にこの説明の内容をベースに説得してみたいと思う勇気が湧いてきました。
ちなみに、角谷さんがまさーるさんの話題を語るとき、思わず涙があふれ出す瞬間を見逃しませんでした。まさーる三とは面識はないのですが、例の事故についていろいろと聞いていただけに、思わずこちらも胸が熱くなりそうでした。
◆ファシリテーション入門（本間さん）
ワークショップ：「後出しジャンケンで負けてください。」
ワークショップ：「今ここから東京ディズニーランドへ行くよう説明してください。」
- 誰1人として同じ説明にならない
- もし説明する相手が「体の不自由な方」、「既にＴＤＬへの行き方を知っている方」の場合でも同じ説明をしていたか？
- 説明する相手のことをしっかり知る必要がある。
- 無説明で実現する方法もある
- 受動、単純ではなく、喜びがあり、行き方を自分で調べられるなら大丈夫
喜び、ビジョンをしっかり示してあげることで、途中の不安感やおそれを乗り越えられる勇気が持てる。
何を知っていて、何を知らないか？
できることは何か？
双方向のやりとりの中で一緒に共通理解を得る
T字型人材
第三の道（喜び、対話、信頼、成長）
より良い指導とは、壁を乗り越え、喜べる体験をたくさん与えてあげること
一緒に喜びを共有し成長することを目指すべき
◆狛犬(Seasar2)の飼い方教えます。〜企業とオープンソースの生きる道〜（飯田さん＆ひがさん）
ビジネスとしてのOSSは取り扱いが難しい
- 収益モデルが難しい
- 経営層への説得が困難
- 製品での囲い込みができない
企業へのアピールとしての戦略
- コミッターが有名人になる
- プロダクトが有名になる
OSSの落とし穴
- 業績に結びつかない
- サポートビジネスが金にならない
対策はプロダクトまたは個人で仕事が取ってこれるだけの魅力をプロダクトに注入する！
まずはS2アライアンスを実現する！
これからのOSSを扱う企業はビラミッド構造から自給自足型へ
- 全部自分自身で面倒を見るようにする
- オーバーヘッド少
- スキルアップ
- できないところを提携企業にお願いする（S2アライアンス）
所感
ひがさんが会社内で結構苦労されてたんだなぁというのが良く分かりました(w
でも、何がすごいかって、ただ愚痴を言って終わるようなことはせず、積極的にS2を世間に売り出し、企業にとってもメリットが出るように戦略を立てて、実際に行動したことでしょう。
この点は是非見習っていきたいところです。
また、S2アライアンスの説明の中に出てきたソフト開発のセル化については以前から思っていたことをズバズバッ！と言い切ってくれたのですごく気持ちが良かったです。
やはり、要求定義とコーディングする人が別々だからいろいろと問題が起こるんですよ。
人手が足りない上に不可能だ！って良く言われるんですが、その否定で終わらせるのではなくて、
どうやったらできるようになるか？
という点をしっかり考えていかないとこれからの競争に勝てなくなると思います。
◆泥臭い事例からの飛翔〜Developer2.0のためのプロジェクト上流編〜（漆原さん）
上流失敗の三大疾病
- まとまらない
- 絵に描いた餅
- 大風呂敷がたためない
対策
- ヒアリングではなく、インタビューにより要件を引き出す
- インタビューは明確な目的があり、意思がある。ヒアリングはそれがないため、発散しやすい
- PJの軸はこちらが決める（仮説のインタビュー）
- モデリングはお客様の分かる形で図表により表現する
- 内部でのノウハウをとりまとめるときにはモデリングするほうが良い
- ビジネスの重み付けをしっかりする
- お客様の思考回路を見極めた上でロジカルシンキングを適用
- 妥当性の判断基準は常にお客様のほうである
- 自分を納得させるロジカルシンキング病に陥らない
- ゴール定義と仮説＆検証
- 有限化、数値化
- 課題の根本原因をしっかり追求する
- 課題は絞ることが重要
- 業務とシステムをセットで考える
- 網羅性は必要だが、やりすぎは注意する。
- 4回くらいイテレーションを回せば要件は出なくなる
- 現場トレーニングを見逃すな
これから求められる人材
- ビジネスとITの両方が語れる人
- IT側からビジネスのほうに進む方が近道
所感
いつも配布資料はないものの、歯切れの良いトークで楽しませてくれる漆原さん。
今回も気持ちいい内容でした。
ただ、耳が痛かったのは失敗事例として取り上げられている内容が4月から携わるプロジェクトに近いってこと。
さぁて、何から対策すんべかなぁ。
