Skip to content

ReadingAgileSamuraiInOimachi 2nd

kei-s edited this page Aug 23, 2011 · 14 revisions

Home / AgilesamuraiDojo / ReadingAgileSamuraiInOimachi

第2回

2011年08月18日(木)に開催しました。

参加者

読み込み対象

  • 第II部 アジャイルな方向づけ
    • 第3章 みんなをバスに乗せる
    • 第4章 全体像を捉える
    • 第5章 具現化させる

持ち寄り議題と、会話の記録

議題1 : 自社サービスにおける「顧客」とは何か?

  • 「顧客を巻き込む」のが大事、ってのは分かる
  • 自社サービスにおける「顧客」って誰なの
    • 「顧客」の捉え方1 : プロダクトオーナ
    • 「顧客」の捉え方2 : エンドユーザ
    • それぞれの捉え方をしたときに、本書をどう読めばいいだろうね
  • 「エンドユーザ」を積極的に巻き込め、ってお話だと捉えると、リーンスタートアップなんかを勉強すると学びがありそう
  • 「顧客」でも「プログラマ」でも「デザイナ」でも、スピードを上げるときにネックになっている部分を「もっとはやく!!」
  • 「1週間に1回しか会えない凄腕のデザイナさん」と「毎日会って話せるちょっとすごいデザイナさん」どっちがプロジェクトにとって望ましいかな

議題2 : インセプションデッキを自分の現場向けにカスタマイズするとしたら

  • インセプションデッキを解体して理解したい
    • 10個ぜんぶやろう!って、けっこう重く受け止めた
    • 3個くらいだったら、やりやすいかも
    • (4)と(9)は、どっちかでいいんじゃない、とか思っちゃうのはよくない…?
    • ひとつひとつの項目の関わり合いがあれば、知りたい
    • 意思決定する人たちの間で認識が合えばいいのだろうね
    • プロジェクトを進行する上で相談事が発生する度にデッキを育てていけばいいのかな
    • プロジェクトの開始時にこれを作ることに一生懸命になりすぎるのもアジャイルじゃない感じがします
    • (1)〜(10)の順番に意味はあるのかしら

議題3 : トレードオフ・スライダーをやってみたとして、どんないいことがおきる?

  • 4つの語彙は、心強い

  • 「品質」の定量化ってむつかしいんじゃないの

  • スライダーをセットしたとして、メンバー間で認識は合うの

  • 「スコープ」を調整するだけだったら、こんな小難しいツールを持ち出さなくてもいいんじゃないの

  • 実際に上手く運用している事例があったら知りたい、お話を聞かせてほしい

  • 「この4つのすべてをMAXにはできないよ」って同意だけ持てていれば大丈夫なのかな…?

議題4 : 外部のデザイナー、エンジニアさんがいる場合にどうアジャイルにやるのがいいか?

  • 「バスに乗せる」のむつかしさ、自分はもう乗っているのだけれど

  • どうやって乗せる…?

    • こんなに乗り心地がいいんだよ、とバスの魅力を語る…?
    • こんな素敵な場所に行くんだよ、と行き先の魅力を語る…?
    • こんなに面白いやつらが乗っているんだよ、とメンバーの魅力を語る…?
  • チームづくり

  • 「引っ張っていく立場の人」と「引っ張られる立場の人」の比率によって、負荷が変わる

  • 波長が合う人を見つけてくる、というお話だとしたら、恋人を探すようなお話だよね

    • 恋人探しに比べて幸いなのは「とりあえずこの期間はお願いします」が言えることだけれど
    • 「学歴」「業務経験年数」「習得言語」とかのフィルタは、その人の波長を見る指標じゃないよね

参加者の声

From @kei_s

議題1 : 自社サービスにおける「顧客」とは何か? について

  • 「 顧客」という名前は、誤解が生じてしまいそうな予感がした。広く適用できるいい名前がみつかるといいなぁ。
  • 「エンドユーザ」も顧客と呼べるけど、予算や責任をもつ人ではないので、ここでいう「顧客」にはならない
  • エンドユーザに向けて、どう価値を提供するかについては、「リーンスタートアップ」などの方面が詳しそうなかんじ
  • はじめてのリーンスタートアップ はわかりやすくて良い資料でした

議題2 : インセプションデッキを自分の現場向けにカスタマイズするとしたら について

  • インセプションデッキのそれぞれの良さはなんとなくわかった。
  • でも、けっこう思いつきというか網羅性がないような印象を受けた。
  • 「10個である」ことにあまり意味がなさそうに感じた。
  • これは、一回素振りをしないとわからないたぐいのことなので、一度なにかでやってみたい。

議題3 : トレードオフ・スライダーをやってみたとして、どんないいことがおきる? について

  • (私が議題を出しました) 読んで良さはわかったものの、みんなで実際にやっている姿を想像できなかったので聞いてみました。
  • 結局スコープしかいじれないよね、というのをみんなが理解するのが目的なのかな?
  • それならこの章を読んでもらえば良いのでは?と感じた
  • 話をしている中で、「品質」のスライダーは調整した人と他の人の認識合わせが難しそうだなぁと感じた。
  • これも素振りが必要そう。

議題4 : 外部のデザイナー、エンジニアさんがいる場合にどうアジャイルにやるのがいいか? について

  • むずかしいですね。
  • 「チームづくり」も「ものづくり」だとおもう

From @ikuma

From @june29

「インセプションデッキ」と「トレードオフスライダー」というツールについて、他の参加者の人たちとあれやこれやと話せたのがよかったです。

どちらも、本書の中の説明を読んでみて「話は分かる、でも自分の現場で活かせるかは、よく分からん」という感覚を持ったので、自分の現場の問題を解消するために、これらを活用できるだろうか、ってことをずっと考えながら、会話に参加していました。

インセプションデッキの項目が「10個ある」ってのは、自分の感覚からすると「けっこう多いなあ」で、かつ、プロジェクト開始前に「これらをすべて揃える」ことが、本当に「アジャイルなのか」よく分からなかったのです。また、項目同士の関わり合いについても、イメージをつかめずにいます。どの順番で項目に答えていけばいいのかな、とか、作成に必要とされる時間の半分の時間しか確保できないときに優先して話すべき項目はどれかな、とか、そういった思考を通じて、インセプションデッキの核とはなんなのかを探っていました。

10個の項目、空っぽのものもあっていいから、とりあえず壁に貼っておくかどうにかして、何かの拍子にメンバー間でお話する中から「これは "やらないこと" だね」と認識が合ったポイントを確認して、項目に対するチームの「応え」を少しずつ育てていくのは、よさそう。つまり、なんだ、日常の中で何気なくお話する「プロジェクトについての大事なこと」をただ揮発させるのではなく、整理して認識を合わせて残して参照可能にしていきましょう、ってことを意識しておけばよいだろうか。

Clone this wiki locally