Skip to content

ReadingAgileSamuraiInShibuya20110803

hfukumori edited this page Aug 11, 2011 · 85 revisions

Readingagilesamuraiinshibuya

参加者の皆様へ

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

第2回アジャイルサムライ読書会 渋谷道場 #agilesamurai

第4章 全体像を捉える

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

4.1 我々はなぜここにいるのか?

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

[感想] jptomo

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

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

4.2 エレベーターピッチを作る

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

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

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

ジェフリー・ムーア¥ 2,100
(ちなみにAmazonへのリンク作成には[AmaGrea](http://d.hatena.ne.jp/Koonies/20091107/AmaGrea)がおすすめ)

[感想] norry_gogo

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

4.3 パッケージデザインを作る

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

フィーチャと効能はMicrosoftとApple(思い出したから書いただけ)

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

[感想] kotonohana

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

4.4 やらないことリスト

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

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

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

4.5 「ご近所さん」を探せ

[疑問] ご近所さんとも極力face to faceでコミュニケーションをとっておくべき?

[疑問] shishi

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

会場で出た意見

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

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

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

[疑問] shio1997

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

[質問] norry_gogo

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

[感想] ibsg

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

第5章 具現化させる

5.1 解決案を描く

[疑問] ibsg

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

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

会場で出た意見

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

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

[疑問] jptomo

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

会場で出た意見

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

[感想] norry_gogo

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

会場で出た意見

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

5.3 期間を見定める

[感想] norry_gogo

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

会場で出た意見

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

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

[感想] remore

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

[疑問] tsuyok

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

出た意見

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

[感想] norry_gogo

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

[疑問] norry_gogo

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

出た意見

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

[感想] ibsg

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

出た意見

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

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

[感想] shishi

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

出た意見

KPT

Keep

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

アジャイルサムライ渋谷道場 第2回のKPT

Problem

アジャイルサムライ渋谷道場 第2回のKPT

Try

運営や進め方に関するTry

  • やらない章(ページ)を決める
  • フリープログラマなので時間は無問題(延長OK?)
  • 席の配置を変える(中心を向くように)/机の形(Life hacks PRESSの@kakutani執筆「勉強会のススメ」の馬蹄形の座席配置)
  • 自己紹介がほしい
  • スイーツタイム
  • タイムテーブルを決めて話し合いに取り組む
  • ワークショップで体験してみたい/ワークショップ(5分くらいでいいので)
田口 元 (著), 安藤 幸央 (著), 平林 純 (著), 角 征典 (著), 和田 卓人 (著), 金子 順 (著), 角谷 信太郎 (著)

個人的なTry

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

各自の現場でやるTry

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

アジャイルサムライ渋谷道場 第2回のKPT

集合写真

アジャイルサムライ読書会渋谷道場 第二回 #1 アジャイルサムライ読書会渋谷道場 第二回 #2

参加者レポート

Clone this wiki locally
You can’t perform that action at this time.