Readingagilesamuraiinsapporo20120327

第17回読書会

• 2012年03月27日 19:30-21:00
• エスプランニング開発室
• 参加者 9人
• 第11章

第11章 現場の状況を目に見えるようにする

11.1 これは･･････荒れる！

• 経営陣の方々が現場に来るなんてことがない
  • 現場にくるという発想がなかったわー
• 炎上を食い止められた例なのかな？
• 「開発チームの要員が半分になれば生産性が半分になる」という計算はおかしいよね
  • 算数で人と生産性を計算するのは好きじゃない
  • メンバーが倍になったら生産性が倍になるのか？ とも受け取られかねない・・・
  • 半分って数字じゃなくて「明らかに生産性は下がるよね」くらいのニュアンスかな
• 経営陣を現場に招く、現状を説明しても効果がないという感覚がある
  • 材料を出して説得しておいたことがあるが、「現状のメンバー、期間、内容で、生産性（ベロシティ）を上げる方法をかんがえなさい」と言われて終わった
    • 上げろと言われて上がるならそれはサボっていたということだよね
    • 少なくてもこの話は、経営陣にフルで働いているという理解は得られているという前提だろうね
• この話の経営陣判断は「そこまで価値がないからやめたよ」ということだね
• でもまあ、たぶん、こうなる前にできることはあったんじゃないかな
  • 経営陣の突然の宣告の裏に何があったのか・・・
• これまでのプロジェクトのやり方では「どうやって○○させないか」という守りに入ることしか考えていなかったけど、この本を読んで、周りを固める・防御することに注力しないで、正直に伝え、できることを精一杯やるという方法もあるんだなーと思うようになった
• 正直にやることで信用を得ることが大事
  • 信用を得るためにやっているのにこっちが信頼できなくなるというケースが今まで多かった
  • 信頼を得られず互いに信用できなくなるのがこの業界のスタンダード
    • それがスタンダードじゃなくなるようにしたいという思いやムーブメントが今起こっているのではないかな
  • 現状はまだまだそうである、という認識は大事だね

11.2 貼りものの作り方

• ストーリーボードとカンバンってどう違うの？
  • カンバンをもっと汎用的にしたものじゃないかな
  • 使い方を工夫していったら、カンバンとストリーボードは限りなく近づいていくよね
• カンバンとストリーボードを併用することはあるのかな
  • ないとおもうなー、チームで使いやすいものを使っていくんじゃないかな
• カンバン（方式）はWIPが決まっている、上限があるところがストーリーボードとの一番の違いだね（P.198-199)
• インセプションデッキは作るけど貼らないという選択肢もありということだね
  • スペースの問題、でもできれば目につくところにある方がよいね
• 壁に貼るスペースがなかなか無い
• 貼るのも難しい - セキュリティとかいろいろ
  • 既成事実を作ってしまうというのは一つの方法としてありだよね
• 壁がホワイトボードになっている会社もあるよ
  • いいなあ
• 壁に貼るものを作ること自体は難しくないのかな、大変じゃないのかな
  • 書き出すというところは慣れないと難しいよ
  • カードを集計する（あとから電子化、同期する）のは結構たいへん
    • あとからきちんと同期したいのであれば最初から電子化しておくのも一つの方法
• ストーリー（タスク）カードを書く効果
  • 自分の作業を細分化してTODOを洗い出すというトレーニングになる
    • まだ仕事に慣れていない頃はそれもできなかったりする（人もいる）
  • 与えられたことをこなすだけで自分の作業量を見積もれない人というのが現実にいる
    • 悲しい・・・・
• 壁に書くか、電子化をするか
  • Pivotal Trackerを使う事、紙との同期なしで壁に貼りたいものを再現できている
    • 遠隔地のお客さんともスムーズにできる
  • 紙の良さもあるし、ツールの良さもある
    • 紙の質感がいいよねー
  • キネクトで紙とWebを同期するとか面白そうだね
• 最初の導入は電子化のほうが楽かもなー
  • 慣れてきたら紙のほうがいいよね、リアルに感じられる
  • ただ、この業界の場合導入コストは電子の方が低いよね
• いつでも見ることができるのが大事だね
  • プラグイン連携で開発環境でいつも見ることが出来るようにするとか
  • プロジェクトによって「常に見ることが出来る」ものを選ぶのが大事だね
• プロジェクト全体で「同じ物をみている」ことは大事だよね
  • トラッカーとかだと自分の作業のみフィルタかけたりできてしまう
    • その点、紙だと必ず同じものを見ている
  • 同じ物を見ることができていないのは誤解を生みやすい
    • ソート順とか、フィルタによって感じるものが変わってきてしまう

11.3 チームの意思を明確にする

• これ、やったことないなあ
• "本来の"プロジェクト憲章ってこの辺りが書いてあるはずなんだよね
  • "本来の"プロジェクト憲章は、インセプションデッキやチームの決まり事なと全てが書かれているもの
  • （プロジェクト憲章がきちんと掲げられていたプロジェクトの経験がある人はほとんどいなかった）
• 「チームで決めた」約束であるというのはとても大事な事だよなあ
  • 自分たちを律するために自分たちが決めた決まりだから
    • ”規則とはそんなに起こらない状況に会社が大げさに反応した傷痕だ。一人の間違いに対する皆への罰だ。”
      • 「小さなチーム、大きな仕事」(完全版 p.253、新書 p.169 :「大げさに反応しない」)
  • "チーム"で決めたことを、チームにあわせてアップデートしていけるといいよね
  • ルールをつく（って与える）ことでルールに縛られる人が出てくるという話がアジャイルJAPANでもでてきていたね
  • ルールを作りたくないと言っても無法地帯は人間甘えが出るので、律するための決まりを自分たちで作るのは大切だね

11.4 プロジェクトで使う言葉を共有する

• 本当にそうですね（しみじみ）
• 必読書（エリックエヴァンスのドメイン駆動設計）：すごく難しい
• 言葉の共有ってすごく大事
  • 業務知識が必要なプロジェクト
    • チーム全体で業務知識を共有しておかないと「中用」「外用」の言葉が生まれてしまう
    • 間の人が苦労する
  • 業務用語がぶれていくプロジェクトはコードの名前でも悩まないことが多い
    • お客さんの言葉を理解するだけじゃなく、こちらから言葉の定義の提案も必要だよね
    • お客さんは全てを「保存」と言っているけれど「追加」と「更新」と「削除」は違う言葉として定義しましょう、とか。
• 日本語は表記のゆれが多いから苦労することが英語よりも多いかもしれないね
  • かな、カナ、ｶﾅ とか。
• 用語辞書を作っていたけれど、単語の関係性などが意味がわからなかった
  • ドメイン分析をしながら単語の関係性を理解する（地図のように）と理解を深めることができた
  • 図は言葉の関連を理解するのにとても役立つよね

11.5 バグを監視する

• あっさり
• 詳しい話は次の部で書かれているね！

マスターセンセイと熱心な弟子

• 今回のセンセイはとても良い話をしているなあ
• 巻き込まれると逃げたくなる
  • 反対向きの力はなくても、少なくても「巻き込まれなくない、その場にとどまりたい」力が本能的に働く事は多い
  • 強い力で巻き込むのではなく、粘り強く話し合うこと
    • 納得して近づいていく
  • 仲間を作る
• 自分自身が納得できているか、本当にやりたいことか
  • 納得できていない、本人に強い気持ちのないことは人にも伝えられない
• チームや周りを変えていく事、巻き込む事について
  • どこからどう変えていくか
    • 上から変えるか、周りから変えるか
  • 組織を巻き込んでまで何かを変えていこうとしている人は実は少ない
    • たくさんの傷を受ける覚悟がなければいけない
  • 手の届くところから変えていきたいと思っている人が多いよね
    • それならできる事も多い
    • みんながそう思って行動をおこせば世界も変わっていくと思う
• 組織を巻き込む、組織を変えるやりかたについて
  • Weといえる会社 / Theyという会社
    • 会社の事をWeと考えられるかどうか
  • 経営者になるのが一番はやいよね
    • 向き、不向きがある
    • プログラマの人は一般的に経営者にむかないとよく言われているようだ

---

次回は4/10(火) 19:30～です