Skip to content

Readingagilesamuraiinhiroshima20120410

Torokun edited this page Apr 16, 2012 · 8 revisions

アジャイルサムライ読書会 in 廣島道場(第四回)

記録


今回も「タリーズコーヒー中央通り店2階」で始まった第四回、今回から参加の方が2名(内1名は準備会参加)こられました。
全部で7名になったので、3階を使わせていただきたかったのですが、事前予約が必須とのことでいつもどおり2階で開催しました。 二人がけの机を三つ並べて、お雛様席も作っての7人座りでしたが狭かったですね、直前にATNDチェックしなかった私の責任です、次回は予約するようにします。
第5章はインセプションデッキの後半です、今回でインセプションデッキとは何かを把握出来る様に理解を深めたいと思っていました。


ふりかえり(約10分)
  三回目の記録を元に、説明を行いました。


Reading Time(約30分)


今回から、章毎に意見を出し合って進める形態にしました。よって、記録もそのように書いていただけると幸いです。

5. 具現化させる

5.1. 解決案を描く

アーキテクチャ、技術課題とは → システム方式設計のこと?ならば、図にするのは普通かなあ
チームメンバを選んだ時点で → いままで選んだことは無いに等しい、既に決まっているか(押付けの感じはある)
図で伝える。 → これは全員で各々が書いてくるのであれば有効に思う。主導権をもってる人のイメージで進行してしまうのを防げる
全員が同意していると思っているとしても → 重要。合意事項を各自書き出して改めてみなおすと結構違う
使いたいツールをここで提案。→ あとではなかなか変更できないものね。

5.2. 夜も眠れなくなるような問題はなんだろう

プロジェクトのリスク → いつも想定外なことが多い(一番最悪なのは人員的なこと)例えば、客先要件確定者の退職、基本設計会社の降板など
これは、チームビルディングのこと、タックマンモデルの混乱期(Storming)をきちんと起こしなさいということ
チームにとって取り組む値打ちのあるリスクを見極める (今回のコンセプトは何か)
それぞれ不安を抱えぬ部分は違う。各々が中止に考えたリスクを明確しておけば、継続的にリリースを止めずにすみそう。
なんだかGTDに似ている。不安要素は開発中は忘れたい。
チーム=アーキテクチャ → チームの特性を理解しないと、提案もなにも通らないので、特性や方向性を理解するのは重要。
リスクを正直に言えるためにはカジュアルな場が必要なこともある。

5.3. 期間を見きわめる

ざっくりしたタイムライン(線表、マスタースケジュール)
小さく考える(大きなことを小さなこととしてとらまえる?)違う→小さく切る
2次開発に回しましょう→取り込んだほうが良い場合もある
グランドデザインという名の、大きな罠、
ここではコミットメントだと思われちゃいけないんだ→そんな言い方できる?
リスクが明確にしてあるこそできる話?
リスクの事前抽出ってセレモニー化されてしまってませんか? → 解決のめどがつくものしか提案されないリスク。
6ヶ月を超えると失敗の確率が高まる話。期待と現実が乖離しすぎる。
やはり、お客さんとこの期間情報(最終決定でもないことも含む)を共有しておくことが大事のようだ。

5.4. 何を諦めるのかをはっきりさせる

スコープを諦める?品質を諦める?、どれも難しい。 でも、真理は真理!
プロジェクトで最重要視される要素は、お客が選択するべき、もっとも全部って言われる
リリースを延期するを選択することが多い。
荒ぶる四天王の(時間、予算)は(工程「納期」「デリバリー」、原価「コスト」)と言ってきた(QCDとなにか違うのだろうか)
重要なのは結局バランス。それでは話がすすまないので…
トレードオフスライダー → 是非商品化を!
プロジェクトの終わりはお客さんにとっては運用というプロジェクトの開始。運用のことを考えてシステムを作る。

5.5. 何がどれだけ必要なのか

最終判断を下すのはだれだ? なんだか商売の観点が無いような気がする
やはり、バスの運転手が必要。誰が運転手かの見極めは・・・?
マスターセンセイと熱心な弟子(覚悟を決めるってこと)
やはり、インセプションデッキはチームビルディング時の手法かな、見積要素も入っているけれど
本来顧客であるべき人がチームにいない?使わない人が顧客になってる?
顧客は本当に(良い意味で)意思決定責任者足りうるか?実はプロジェクト内に意思決定できる人はいないのでは?疑惑が。
インセプションデッキを数日で作るというスピード感。必要に応じてやり直す勇気も。

その他出た話

日本とアメリカの違いについて

米国では顧客の中に入って一緒に開発するというスタンスが一般的であり、日本と事情が異なる。
では、日本でアジャイルが普及するには、ユーザーのスタンスを変えないと無理ということか?
また、何が日本と米国のシステム開発の形態が異なる要因となったのか?

建設業との類似性について

どうも日本のITは建設業のやり方を模倣していて、そこから抜け出せていない気がする。
建設業と違ってITは過去と同じことの繰り返しができない世界。

Clone this wiki locally