第8回読書会

• 2011年11月08日 19:00-21:00
• エスプランニング開発室
• 参加者 6人
• 5.5 ～ 6.2

第5章 具現化させる

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

君の「Aチーム」を編成する

• 「命令と制御ではない形」のPMってどのような形？
  • 上（顧客）からの命令を絶対に従わせようとするPMに対しての皮肉じゃないかな
    • PMには調整力が必要
    • 余計なことをしない
    • のびのびと仕事が出来る環境を提供すること > 35ページとかに書いてあるね
  • プロジェクトチームは軍隊じゃないから軍隊のやり方を適用させてもだめだよね
  • 「不確実な状況に立ち向かえること」
  • 自分がいなくても動くような環境になっていることが良いチームだと思ってPMをやっているよ
• 「Aチーム」のようなスペシャルメンバーって本当に集まる？
  • 期待することを全て満たせるようなスキルを持った人なんてなかなかいない
  • でも、何を期待されているかを理解して、その期待に答えられるような覚悟を持つことは大事だよね
  • そういう気持ちを持っている人で編成されているチームだといいよね
• Aチームと言い切れるようなメンバーを揃えた上で、お客さんに「あなたにも覚悟がありますか？」と聞くフェーズの話なのかな
  • ここに書かれている期待を満たせるようなお客さんに出会えることはなかなかないし、あえて高い期待を書いてあるんじゃないかな
  • こちらも本気です、あなたも本気で関わってくださいね、というような意味で

最終判断を下すのは誰か

• アジャイルだけの話じゃないよね、アジャイル特有の話ではない
  • ステークホルダー同士の話し合いが大切であるとか
  • 最終判断する人を最初に明確にしておくとか
  • 100%コミットできないことを表明しておくとか
• プロジェクトを遂行するうえで必要なことを書いている
  • 「アジャイル」だけが特別じゃないということだね

コストがどれくらいかを見積もる

• スペシャリスト（少数精鋭）で参画するという前提だからざっくりコストがそんなにずれることがない
• 小さくしているから規模と金額が見えやすい

最後のスライドを仕上げる

• 君が責任者だとしたらという問いについて
  • 「全部決めたとおりにやって責任も取って欲しい」と思っているお客さんが多いのが現実なんだよなぁ
    • 「毎週動くもの」が必要ないと思っている顧客が多い現実
    • 理解あるお客さんじゃないとそもそも「参加する覚悟」がない、覚悟あるお客さんと出会えない、難しい
  • ここで書かれている責任者 = プロジェクトオーナー
    • 自分のお金だとしたら、という意味で読み替えるのがよいね
• スライド「最初のリリース」で数値の見せ方を工夫しているところは具体的にはどこなんだろう？
  • 「最初の」というところで「コミットできないよ」という意味を含めている
  • 数字はあくまでも参考値、リリースまでの道を見せる
  • WBSやチャートを見せるのではないというところ
• 別の見方をすれば「今までのやり方」にアジャイルも歩み寄っている（近い）というのを伝えている章ともいえるよね
  • 特別な方法なのではなく、共通点はたくさんあるということがわかった
  • ウォーターフォールでも良い部分は取り入れて、アジャイル的な開発でもっと良い形を見つけていこうということが書かれてあるのだな

第Ⅲ部 アジャイルな計画づくり

第6章 ユーザーストーリーを集める

6.1 文章化の難しさ

• あるあるすぎる
  • 文章だけで勝手に判断して確認しない、作り込んでしまう、覚えがある
    • 文章の裏を読みすぎる
    • そのことを考えなくてよい、ということではなくて、勝手に考えて判断することが良くないと思う
    • 文書から読み取って自分で判断するのではなくお客さんに確認すればいいことなんだよね
• この章は前後の段落で文脈がずれている気がする
  • 前： 重厚な文書化は必要ない
  • 後： 文書じゃなくてコミュニケーションが大切
  • → どうして「伝わりやすい文章」を書こうという点がないのか、「文書が重厚だ」ということと「言葉は危なっかしい」は直接関連しないのではないかな
  • 「文書で表現すること」そのものが誤解を生むわけではないはず
    • ユーザーストーリーも文書でしょ
  • マーチン・ファウラーの読者の誤解の例
    • 「読者」と「仕様書」って文書の質が違う
  • （しっくりこないという人と、特に違和感がなかったという人がいた）
  • ユーザーストーリーと文書の違い、「文書」英訳に意味があるのかもしれないね
    • ここでの「文書」という言葉には「重厚で読む気にならない何か」という意味が含まれているのかもしれない
  • 先を読み進めて話していったらこの違和感が解消されるかな
• 「要件」という言葉 - requirement
  • 人によって定義が違う
  • やりたいこと(≒要求)＝要件 ではない
    • やりたいことから選んでもらった残りが「要件（やらなければいけないこと）」
    • 機能要件、非機能要件（権限とか法令とか）
    • 仕様（spec) はこうしたらこうなるというシステムの動きの定義
  • 「要件定義」という名の文書が膨らむのは、仕様まで書いてしまっているからであることが多いよ
    • ただの「仕様」まで細かく「要件」に盛り込んでしまっている
• 「文書化は必要ない」というのは「要求」段階だから必要ないという意味なのかな？
  • ユーザーストーリーは要求ですらない、もっと前の段階、お客さんがやりたいこと、要求をあらいだすためのこと
  • ユーザーストーリーを出す以前に重厚な文書はいらない、という捉え方もできるよね
• 実際文書がないとプロジェクトが始められない現実
  • きっと別の問題（ここで言われている文書とはまた立ち位置の異なる文書）
  • 全く文書がない状態で始まるプロジェクトのほうが珍しい
    • よくある「プロジェクト定義書」はここでいうインセプションデッキのような役割として必要な文書にあたるのかな？

6.2 そこでユーザーストーリーですよ

• この章は超巨大プロジェクトに対してのあてつけもあるよね
  • 最初に半年かけて要求分析と要件定義をやる必要はないよね、そういう形のプロジェクトは成功しないよ、という裏がある気がする
  • 本当に必要になるまで着手しないというのはアジャイル的
    • お客さんと密に連絡が取れることが絶対条件だよね
• 着手しないこと
  • 短期間で必要な物が変わったりするのかな？そんなに世の中の状況が変わったりしない気がする
  • ソフトウェアが見違えるほど変わっていることはあるかも
    • 実際に動かしてみたら欲しいものが変わる
    • 検索条件やソート条件 ・・・ 最初から全部作ろうとするとフルフル（全項目検索条件に、全項目ソートしてほしい）になりがち
      • 使ってみたらこの条件で十分となることは結構あると思う
• 性格的に細かい人がいると検討段階でオーバースペックになりがちだよね
  • 開発者側もお客さん側も、性格による部分は大きい
  • 何かを検討する時に、必要な方向だけでなく、現実にあり得ないパターンでもすべての条件マトリクスが埋まってないと納得できない * aかつbは現実ではあり得なくてもパターンとして存在するから検討しておきたい、みたいな
• 「会話の約束」ってどういう意味だろう？
  • 「これから会話をすること」を約束
• 何ヶ月か後にカードの短い言葉だけで、その時の会話を思い出せるのかな？
  • お客さんが本当に欲しいものだけがユーザーストーリーになっているはず
  • 今のソフトウェアと以前に書いたストーリーカードを見比べて、具体的にやりたいことが思い出せなかったら必要なものじゃないと判断していんじゃないかな
  • 欲しいものだったら具体的なものを思い出せるはず
• SIerの立場からアジャイル導入が難しいのは「途中で満足される」と困るから？
  • お客さんのためにはならないのだけど、実際にそういう側面はあると思う
  • 段階リリースを行っていった結果「これ以降はやっぱりいらないわ」「途中でおしまい」は困るんだろうなぁ
• ソフトウェアの発注が「定期予算」なのは不健康な形なんだよねぇ
  • 必要なものが発生したときに予算を組んで発注するのが健康的な形なんだよねぇ
    • とりあえず予算を組んだから家を作る、車を買うとかないよね
  • 定期的にものを作らなければいけないという形が色々と問題
    • 期末の「とりあえず作ってよ、予算あるから」問題
  • ものに対してしかお金が発生しない、そしてそれが「定期的に」必要という形になるから不健全なプロジェクトが生まれるのかな
    • ベンダの「雇用」を守るためには定期予算が必要 = 定期的に物をつくる、発注してもらわなくてはいけないとなっている
    • 「欲しいものが必要になったら作ります」ということができる継続的な（プロダクトへの対価ではない）契約形態があるとよいのかもね
• ユーザーストーリーはお客さんの要求を書き留めるもの、ユーザーが書くわけではないんだね
  • お客さんは書いた物をみて判断する、欲しい物をはっきりさせるもの
  • 要求を引き出してストーリーという形にするのはこっちの仕事
  • もやもやしていることを言葉にしてあげるのはこっちの仕事
  • やりたいことを引き出したあとの「メモ」的位置づけ
  • 成果物ではない（確約していないから）、会話は約束している（TODO、備忘録的な位置づけ）

---

次は6.3からです

---

余談

• http://atnd.org/events/21754
• 本の紹介をしてもしょうがないよね（参加者はだいたいこの本のことは知っているはず）
• 何の話をしようか？
• ディスカッションの内容は「wiki参照してね」で済むよね・・・
• 「いつももやもやしている」という話
• 「毎回いろんな疑問が生まれる」という話