Skip to content

Readingagilesamuraiinsapporo20110802

sandinist edited this page Aug 3, 2011 · 13 revisions

第1回読書会

  • 2011年8月2日 19:00-21:00
  • エスプランニング開発室
  • 参加者 13人
  • 前書き〜第1章まで

日本の読者の皆様へ

Q 才気煥発なんて読むの? → さいきかんぱつ

お目にかかれて光栄です

###Q どの立場で読みますか?

  • プロジェクトを率いる人
  • メンバーとしてどう振る舞うか
    • → 両方の立場の人が多い
  • 「お客様にどう伝えるか」を考えているという立場もあるよね
  • 発注をする人(顧客として振舞っている人)が参加者にいるといいな -- 今回はいないけど
    • お客さんをメインに集めるような勉強会があるといいのかな、興味があるのかな
    • 「アジャイル」がバズワードになり、そこから興味を持ってもらってからじゃないとなかなか
    • まだまだ牽引力は低いのかな
    • どこからお客様サイドに伝えていくのがいいのだろうねぇ
    • なぜお客様側を巻き込むのが難しいのかを考えないとね
    • お客様のシステム管理部門とかから良さを伝えられるかも
    • 営業や企画など攻めの部署に効果を伝えたほうが変わりやすいという話も
  • 「アジャイル」というキーワードだけはあるけど全然違うものもあるよね
    • 契約からきちんとアジャイル的な手法を見せる事ができるのはいいよね
    • 契約はガチガチ従来方法で、手法だけアジャイル的にしている事が多い
    • そう考えるとお客様の前に通さなければいけない壁がある

###Q その他 各自の思い、感想

  • 大事なこと

  • 「からかってるわけじゃない」「楽しんでよんでもらえたらうれしい」

  • 教科書としてではなく、考えるための教材として

  • 心構えとして読む

第1章 ざっくりわかるアジャイル開発

章ごとに切ってディスカッションしようかとおもったが、長すぎるのでセクションで切ってディスカッションすることにした

1.1 価値ある成果を毎週届ける

お客さんにとっての価値ある成果物は「ちゃんと動くソフトウェア」である

  • この本で「無駄」と言われているものを求められていることもあるよね
  • 無駄と言われているものでもお客さんが必要といえばそれは必要なもの
    • それを優先するのが第一になる
    • そのためにフィーチャを削ることになるかもしれない
  • 「動かなくていいからドキュメントをください」という極論もある
    • 「動作保証は契約に含まれていない」とか
    • それは成果物がドキュメントになっているのでは
  • お客さんと「お客さんのお客さん」では価値が異なることがある
    • お客さんのお客さんにどう価値を届けるかを考えたい
    • お客さんのお客さんにとってそのドキュメントが本当に価値があるのか
  • 現状がおかしい、変えていなかければならない(そういうプロジェクトが存在する)のは全員わかっている。しかし現実は全てのお客様が「動くソフトウェア」を求めているわけではない、という事を理解しなければならない
    • ドキュメントがあればソフトウェアは動かなくて良い(ソフトウェアが動いてもドキュメントが揃ってないなら困る) とか
  • ドキュメントがあれば安心と思っている、それ以上にいい方法を知らないお客様がいる * エンドユーザーがお客さんのお客さん * 検収できないお客さん
    • ソフトウェアが動いている -> あいまい、ドキュメントは安心
    • ドキュメントだったらそれが完璧にあらわされていると思っている -> そんなことはないのに * 知らないだけで提案していけば変化していくお客様は一定数いるとおもう

###誰もがその働き方を気に入るわけじゃない

  • 定期的に成果物を持ってくるのは迷惑と思うお客様もいる
    • 理由がわからないと小出しにされても迷惑だよね
    • 「定期的に動くものが届く」その価値をどう伝えていくか

###お客さんにとっての価値、本当に必要なもの

  • お客様が本当にソフトウェアが必要なのかどうか
  • 「今使えているもので十分だよね」ということもある -> とくにリニューアル
    • リニューアルとか、立場の違いによって 重要性や必要性が変わる
    • リプレースしないほうがいい場合もあるしね
    • その場合まずお客様が望むものは「今と同じもの」
      • その考え方はプロジェクトが後ろ向きになるからよくない
      • 要求開発などの話になるが必ずよく出来るところはある。習熟コストを上回る価値提供をするべき
  • これでもいい→こっちのほうがいい というふうに変えられる それが「価値の提案」なんじゃないのかな * 押し付けではなく

###計画を乱すような現実に遭遇したら計画を変えるんだ

  • WBSとかは「変えられない計画」ではないから手法として「計画が変えられない」わけではない
    • PMBOKとかはプロジェクト管理の知識体系であって、手法ややり方ではない
    • この辺りを勘違いしているプロジェクトはけっこう存在する
      • アジャイル的かどうかに関わりなく

###身銭を切るかのような覚悟でお客さんの資金を扱う

  • あんまりそういう風に考えたことがなかったなぁ
    • 一括請け負い契約の弊害
      • もらったら終わり、変わらない
      • 「人月」だから「価値」に対して対価が支払われていない

1.2 アジャイルな計画づくりがうまくいく理由

###できないものはできないんだ

  • 「できない」の定義 - 徹夜すれば/無理すれば「できる」は「できない」
    • 徹夜は奇跡のマネジメント
      • それが「できた」となってしまうことが問題

###もし金額固定の一括契約だったらどうすんの?殺されちゃうよ?

  • これに対する明確な答えは?→ 「一括契約をしちゃだめだよ」なのかなぁ
  • "当初から顧客には隠し立てをせず、誠実に仕事を進める"というその後に続く文も解ではないか

###奇跡によるマネジメント

  • 何が幻想か
    • 1年前に1年後の計画を全てわかっているということが幻想だよね
    • プロジェクトの最初にプロジェクトの終わりがわかっていることなんてありえない
      • 何度も同じことを繰り返している、過去を生かしてないよね
  • ソフトウェアはそんなに計画通りに簡単に作れるものじゃない
    • 「簡単じゃない」ことが外から見えにくい
    • だからこそお客様をチームに引きこんでいきたいんだよね
  • 歩み寄りが大切
    • お客さまにとってはわからないことが当たり前
    • お客さまにとって「良い経験」がどちらであったかで判断していってもらうしかない
      • 良い経験が増えたあとに選択される方法であるといいよね

###フィーチャ

  • 「フィーチャ」って初めて聞きました
  • ユースケースよりも抽象的でユーザーの価値に着目した概念
    • 機能と混ぜてはいけない
    • ユーザーが使う機能についての説明
  • モジュールという意味で使うこともある(違う使われ方として)
  • ex) ログインとマイページ
    • [機能] ログイン機能
    • [フィーチャ] 会員登録したらマイページが持てること

1.3 「完了」とは完了のことだ

完了とは完了のこと

  • リーン生産方式の書籍 - Ready Ready / Done Done, "Ready,ready.Done,done"

###「動くソフトウェア」が最も重要な進捗(1.2にも関連する)

  • フレームワークや環境構築、プロジェクト管理は目に見えない、その辺りをどうするか

    • かっこいい熊手を手に入れるところは価値ではなく前提
    • 熊手を手に入れるのに1h、熊手を使って落ち葉を集めるのに1h・素手でやれば3h
      • 1/3 進んだところでの進捗は素手だったりするのだよね
      • 今後の保守などを考えたら今のうちに熊手を手に入れておいた方がいいよねという説明が必要だよね
  • 最初の1イテレーションで動くものを出すことは難しいよね、どうしているのかな

    • イテレーションゼロ のイテレーション
    • はじめの頃のイテレーションはお客さんと話をするのに注力する

1.4 3つの真実

変化は起きるもの

  • 変化に対応する 角谷さんのお話

    • 予測できる変化は変化じゃない
      • 予測できる変化の量を増やすためにはスキルが必要
      • トータルのコストの話ではないか、予測できるものを全て作るのは無駄を作り込むことになる
      • 作り込みの無駄をなくすために決定は可能なかぎり遅らせるべき、という考え方もある
      • 人間は不完全なのですべて予測なんてできない
    • 予測できない変化こそが変化
      • 変化を予測する
      • 対応しなければいけない時に対応すること
  • 予測、変化どっちに重きを置くの?

  • アジャイルは変化に重きを置いている?

  • 何かが起きた時に「それに対応しよう」とすることが大事なんじゃない?

    • 「そんなの聞いていない」と思考停止しないこと
  • 予測なのか変化なのかが重要じゃなくて、変わることへ全力で対応しようとすることが求められるのでは

優先順位をつける

  • 優先順位をつけるのが一番難しい
  • スモールスタートできるパッケージソフトウェアはお客さんにとっていい形なのかも
    • 大切なものが見えやすいから
  • もしかしたらこの機能はいらないのかもしれないということまで踏み込めるかどうか
    • 「お客様のやりたいことをお客様の知らない方法で実現できる事を提供する」 というのが目指すところ

やるべきことはいつだって与えられた時間と資金よりも多い

  • 経営者としてはそれを認めていいのか
    • やりたいこととやるべきことの違い
      • ここでは「やりたいこと」というニュアンスが強いね
  • 取り組む価値があるプロジェクトであればそうなっていることが望ましい
  • やるべきことから本当にやるべきことを見つけていく -> 優先順位をつける

「チーム」

  • この本の「チーム」には基本的にお客様が含まれている事を忘れないように
    • 時々そうじゃないこともあるから注意
Clone this wiki locally