← Readingagilesamuraiinshibuya

• 読書会終了後に有志で飲み会があると思います。
• どんどんWikiになんでも書いてください。（まずいことがあれば消しますので）

インセプションデッキのテンプレート https://github.com/agile-samurai-ja/support

現場に行って確かめることが大事｡現場でしかわからないことはたくさんある｡

この章を読んで、下記の記事を思い出した。
明快なキャッチフレーズが大事ということは共通していると思う。

日経ものづくり ホンダ イノベーション魂！ 【第14回】コンセプトと本質（3）言葉の力
http://techon.nikkeibp.co.jp/article/HONSHI/20110427/191476/

特に後半は書きにくい(競合､差別化の決定的特徴など)｡しかし､わからないことを理由に書かないと､プロジェクトは失敗する｡わからないなら､わからないことをはっきりさせる(談)

ゲーム開発の現場で経験者がいた｡プロデューサがつくってチームで目的を共有｡シンプルに書くことが大事｡

この本で紹介されているエレベータピッチのテンプレートは「キャズム」に載ってるやりかた｡なぜこうするのかについて知ったほうがやりやすい｡

キャズム [単行本] ジェフリー・ムーア￥ 2,100

(ちなみにAmazonへのリンク作成には[AmaGrea](http://d.hatena.ne.jp/Koonies/20091107/AmaGrea)がおすすめ)

「我々はなぜここにいるのか？」「エレベーターピッチを作る」「パッケージデザインを作る」は種類的に類似点があると感じますが、自分は「エレベーターピッチを作る」が折々で振り返って確認する際の素材にバランス良さそうと思いました

自社開発オレオレレガシーフレームワークを新しいものに入れ替えたいという事例｡レガシーコード減るとかでは説得できない｡それによってどんな価値を顧客に提供できるのか説明することで説得できたといういい話｡

• 携帯音楽ストレージをMicrosoftは「40GBともの大容量を実現」と表現する。
• Appleは「3000曲も持ち歩ける大容量」と表現する。
• この話聞いててもし日本のメーカーがiPhoneを作ったらを思い出しました。

ここに記載されている内容は全く以って同意。単に開発だけでなく、商品企画にも応用できると思う。 ユーザにとっては体験が全て。フィーチャーに興味はないと思ってよい。 「何を体験したいのか」を明確にしておくと、仕様を作る際のメンバー間のコンセプト共有も円滑になる。

みみっちい機能を断るみたいなのは､ユーザストーリーと優先順位で対応可能｡やらないことリストは､もっとでかい機能に対して使う

やらないことを今決めるのか､「あとで決める」に置いとくのか｡優柔不断だと「あとで決める」が肥大化しまくるのでは?? → やらないことリストは制約｡旧システムとの連携をやらないとか､DBの構造変更はしないとか､そういう根本的なものを書く｡

「あとで決める」が多いプロジェクトは破綻する｡

前回、アジャイルは0か1ではなく、取り入れられるものから、と言う話があったが、顧客を巻き込めない限りは他の顧客向けの仕事をするしかない、とある。 つまり、顧客を巻き込むことはアジャイル開発の絶対条件ということか？

• 「そういうのを断らず進めるとどうなっちゃうんですか」「炎上しちゃいます」みたいな会話があった｡
• そうしないと失敗するなら､それを伝えるべき
• 「やらないと失敗しますよと言い続けて失敗すればいいんじゃないでしょうか」
• 失敗事例トークになった
• 取引先を選ぶ

感想: 顧客が価値あるソフトウェア開発にコミットしないとエンジニアのモラルが崩壊して「価値のないソフトウェアを開発するのに成功した」とか言い出す

新たに開発を依頼する会社を試す為に、最初は規模の小さな仕事であえて積極的に関わらず、色々なアラートを上げてくれるかで次回以降も仕事を依頼して行けそうかの判断材料にするとか、みたいなお話があって印象的でした

顧客が関わってくれるようになるまで時間を引き延ばすことができない場合はどうするのでしょうか？ 　＊仕事をキャンセルすることもできない

「嗚呼、この方もご近所さんとして意識するべきだったんだあー」というような意外なご近所さんと遭遇された事はありますか？

この勉強会を１つのプロジェクトに見立てて、テーブル毎に4章の5項目を相談するのはどうでしょうか？結果をwikiに書き込むなどで発表？

複数の案が、ある場合は、どのようにすべきでしょう？

(完成した場合の性能の見積もりが難しいなど､どのアーキテクチャを採用すべきかわからない場合)

• ケースバイケースだが､まずはその問題を明らかにすることが大切｡

5.1 からリスクを抜粋し、真に恐ろしい問題を検討するのかな？

• それに限らず､ソフトウェア開発をするうえで考えられるリスク
• そして､取り組む価値のあるリスクを見極める

取り組む価値のあるリスクと取り組む価値のないリスクとの振り分けは「やらないことリスト」にも似ていると思った

• そのリスクに取り組むことで､自分やチームがどれだけの価値を生み出せるか?を考える
• リスクに対しても「あとで決める」はあるのか
  • その時に取り組むか取り組まないか判断する
  • 判断はその時点でのスナップショットなので､判断が将来変わることはある
  • 可視化しろ､更新しろ(wikiと同じ)
    • wikiを活用できないチームはアジャイルになれない!!!

大きな仕事を成し遂げようと思ったら、それをもっと小さな、制御できる単位へと分割…　が印象的 アジャイルな開発では色々な粒度での「分割」が見受けられる、手に負える課題であれば気持ちの余裕もできる 経験を重ねながら「チームの制御可能な単位の大きさ」を見定めて行くと良いかも

• 後の事は後で考える(判断を先送りする)事によって、今取り組むべき事がより明確に見えてくる
  • 金曜日はコードを書かかずに来週やる事を固め、月～木はその計画に対して集中するという運用事例もあがりました

「時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。」（p88）
⇒受託開発の経験では、プロジェクトを始めるとき、顧客はスコープこそが固定したいものだと考えがちだと思う。顧客のためを思えばこそ、時間と予算と品質は固定なものであってスコープのみが調整可能だということを、どのようにしてサムライたちは顧客と合意を形成していくのだろう。トレードオフ・スライダーを使ってその合意を可視化すると、具体的にどんなメリットが生まれるだろう。機会を見つけてやってみたい。

「時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。」（p88）
⇒時間、予算は、定義（数字）を決めることは比較的容易だと思いますが、品質は定義が難しく、何を持って品質が問題ないかを見極めるは容易ではないと思います。サービス内容によっても品質に注力するパワーも違う面があると思います（例：命、お金、個人情報を扱うか否かなど）。その点はみなさまどう思われるのでしょうか。

• ここで言う品質とは､「当たり前に動く」こと､要望されている通りに動作すること｡だから「品質固定」と言っているのだ｡
  • 「要求したとおりに動く」以下の品質とかありえないよね

顧客にスコープを絞ってもらう為には、優先順位のしっかり付いたユーザストーリーと日々の誠実な価値の提供があってこそかなと感じた

「捉えどころのないもの」の例えが今ひとつ掴みきれません…

• 5年ほど前にアップル本社でUI開発をしている日本人の方とランチをご一緒させていただいたことがあった。その時の話（結構前なので記憶があいまいなところもありますが）：週一回のペースで、Steve Jobsが直接新しいUIの出来栄えを確認する。ドット単位での修正を要求することもあるのだとか。こういった「使いやすい、美しいインタフェースを実現する」こだわりは本の中にある「捉えどころのないもの」の一例に挙げられるのではないかと思います。
• プロジェクトの特性による個別な項目(スコープ、予算、時間、品質の４つはどんなプロジェクトにもある項目)
• 意気込み的な部分、P.60で言う所の効能の部分、というご意見も

4.4で「やらないことリスト」、5.4で「何をあきらめるか」で似ていると思った。インセプションデッキの全体像（なぜ）を4章、具現化を5章（どうやって）で扱ってますが、どちらの側面でも出てくるのですね。

• 「やらないことリスト」に出てくる「やらないこと」は本当に実行しない項目。
• トレードオフ・スライダーは､優先度が低くてもやらないわけではない｡重要だが､しかし他のもののほうが大事なので手を抜く｡

具体的なインセプションデッキを見てみたい

• 自分で作れば見られるので作れ
• ギークハウス武蔵小杉（この読書会に参加している）で見れるらしいアジャイル開発！（インセプションデッキ編） - u16suzuの日記

• 女の子参加！
• 前回よりも意見が出ていた気がする
• 座席表があった
• 何かしら答えが出た
• 安直な[感想]ばかりしかwikiれなかったけど続けてみる
• 実体験に基づいた話が聞けた
• 予習してくる人が多い
• 現場の話が聞けるのが良い
• リアルタイムなwiki更新
• wikiとは何か?について知ることができた
• 大塚さんいいね
• 基本的な話が聞けたのがよかった(_?)
• リピーター多いのは良い
• ニジボックス会場ステキ！(x2)
• ノートにマインドマップ書いた
• 女子増えた！

• やらない章（ページ）を決める
• フリープログラマなので時間は無問題（延長OK？）
• 席の配置を変える（中心を向くように）/机の形（Life hacks PRESSの@kakutani執筆「勉強会のススメ」の馬蹄形の座席配置）
• 自己紹介がほしい
• スイーツタイム
• タイムテーブルを決めて話し合いに取り組む
• ワークショップで体験してみたい/ワークショップ（5分くらいでいいので）

Life Hacks PRESS ~デジタル世代の「カイゼン」術~ [大型本] 田口 元 (著), 安藤 幸央 (著), 平林 純 (著), 角 征典 (著), 和田 卓人 (著), 金子 順 (著), 角谷 信太郎 (著)

• 遅刻しない
• もっとしゃべろう/声を出す/発言は大きな声で
• 前に座る
• 飲み会参加者UP
• Wikiを事前に書く/Wikiに感想をあらかじめ書く/* Wiki書いてくる
• Wikiにノートをアップする
• Wikiに質問への答えを積極的に書いてみる

• Wikiに何でも共有する（細かいことでもチームで共有できるように）
• 社内でフィードバックします（イイネ！）
• インセプションデッキ（を作る）
• 顧客をもっと巻き込む

• 感想文的になってしまいましたが、社内へのFBも目的としてBlogを書きました。 by angler_ishikoro
• ブログ書かせていただきました。by jptomo
• ブログとインセプションデッキを書いてみました。
• ブログ書きました norry_gogo