Readingagilesamuraiinsapporo20120214

第14回読書会

• 2012年02月14日 19:00-21:00
• エスプランニング開発室
• 参加者 9人
• 9.1 ～ 9.5 冒頭

第Ⅳ部 アジャイルなプロジェクト運営

9章 イテレーションの運営：実現させる

9.1 価値ある成果を毎週届ける

• 183P2パラグラフ目「アジャイルプロジェクトのマネジメント」
  • なぜいきなり「マネジメント」という言葉が出てきたのか？
  • 原著確認 "イテレーションの運営" -> "iteration management"
    • 日本だと「マネジメント」という言葉だと誤解を受けやすいから敢えて運営にしたのかな
• テストは開発と一緒になって進めていく必要がある -> プロジェクトの初日からテストが必要ってこと？
  • システムが全体として適切に動作し続けられる ＝ テストがないといけない ではないと思うよ

9.2 アジャイルなイテレーション

• 特になし（次からの実例を見ていきましょう）

9.3 【急募】アジャイルチーム【切実】

• 特になし（次からの実例を見ていきましょう）

9.4 ステップ1：分析と設計：作業の段取りをする

• 「必要な分だけ、必要なときに」 で本当にいいの？

  • 部分だけをやって全体を見ていなかったらそのプロジェクトは破綻するんじゃないかな？
  • 設計はともかく分析は全体を俯瞰しなければいけないんじゃないかな
  • 本当に全く分析をしていないとそのプロジェクトは事故るよね
  • これは「全体を見通さないという」話ではないよね
    • 先まではなんとなく見えているけど詰めるのは後で、という意味なんじゃないかな
  • 分析の段階で手元にある材料がインデックスカードだけならそこから全体を把握するのなんて無理じゃないかな？
    • インデックスカードを作るまでの段階でその他の材料や話し合い、全体をどうするかという事はある程度話しているはず？
    • 手元にある材料はインデックスカードしかないわけじゃないと思う
    • イテレーションを開始するまでの段階で（Ⅲ部までの経緯がある）、ある程度準備ができているはず
  • ここでいう「分析」の言葉の意味はなんだろう
    • 見積りをする段階で概要設計レベルの分析は終わらせていないとおかしい、見積りできないよね
    • 9.3の最後にある「作業の段取りをする」を「タスクに落とす」「具体化する」 と考えると納得しやすいかも

• 全体を見通すと言う話でスクエニさんの話を思い出したよ

  • スクウェア・エニックス オープンカンファレンスの「ゲーム開発プロジェクトマネジメント講座」の資料 http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf

• フローチャートやペルソナ分析をこの段階でしていちゃ遅すぎるとおもう、あまりに遅い、ここで初めて分析するプロジェクトなんて、うまくできるきがしない

  • 確かにこの段階で全く白紙っていうのはおかしいよね
  • この段階より前に全体の分析はできている前提なのかな？

• 「形式的な文書はそんなに必要にならないだろう」-> ホントにそうかな？

  • 大事なものはメールとかしない？
  • 「そんなに」にだから全く不要なわけじゃないんじゃないかな？大事なメールなどは「そんなに」に含まれているんじゃない？
    • 文書を書くか書かないかは文化の違いなんじゃないかな
    • 言質をとらないとだめ・証拠として文書が必要という文化ばかりではないのでは？
  • 「会話とちょっとした文章だけで伝わる」と思っているとしたらそれは良くない文化だと思う、ただの文書化できない事に対する言い訳じゃない？
    • 文書化できないではなくチームにとって必要な文書が違うという話なんじゃないかな？
    • その分、会話や話し合い、頭の中の説明のような事をたくさんするんじゃないかな
    • それぞれ頭に描いていたものがずれていたらどうするの？
      • 文書、客観的に見える形のものがないとずれているのに気がつかないんじゃないかな
      • 同じものをイメージしているか都度、意識共有（話し合い）するんじゃないかな、「文書」という形がないだけで * お互い「言葉」にはしているんじゃないかなぁ
    • 文書化するよりも意思疎通、目的共有する方がずっと難しいと思うんだけど....
      • 何をやるかを第三者が見て客観的に理解できる文章で書いてある事で初めて同じものを見ていると言えるんじゃないかな、客観的に同じものかどうかが大事になってくると思う
      • 同意や同じものかどうかという共有は必要、それを「文書」にする必要があるか、十分か十分じゃないかはチームや状況によるんじゃないかな
      • 第三者って誰？ -> ステークホルダー、新しく入ってくるかもしれないチームメンバー
        • そういう人達と意思疎通ができないようにするべきとかいう話じゃないよね
        • 第三者という意味で、GitHubのプロジェクトの経過を残そうとしている計画が書いてある文書は面白いよ http://zachholman.com/talk/scaling-github
    • 「そんなに文書が必要じゃない」と書かれているのは同じ机を全員が囲めるような小さなチームをイメージしていたよ
      • 文書を書くよりも絵や図を使って話し合う方が早いというイメージ
        • そのイメージが本当に共有できたかどうかって文書に残しておかないとわからないんじゃないかな、忘れちゃうし
      • 文書の形がいろいろなのかなホワイトボードのスナップショットを残しておくとかでも十分な事もあるんじゃないかな
        • その場の話し合いにいた人しかわからない図や記号だけのスナップショットは意味ないんじゃないかな
  • 文書を全く残さないわけじゃないし、必要があると判断したら話し合いの結果を残しておけばいいんじゃない？
    • 「形式的な」文書がいらないと書いてあるわけだし
  • 全部が全部、文書がいらないと言っているわけではないよね、必要な所では必要な文書を書くと書いてあると思うよ
  • 「文書はいらない」と軽視しているようなこの書き方は好きじゃないな

• ここででてきた「ペルソナ」という言葉に違和感を覚えた

  • ペルソナ-> アクターじゃないのかな？
  • 業務アプリだとロールレベルでしか考えないからペルソナという言葉に違和感を感じるかもしれないね
  • アクターもペルソナもロールも広い意味を持っている、役割としては同じ方向を目指している
  • 「ペルソナはリアルな人間であり」そうなのかな、リアル化がどこまで必要なんだろう
  • 業務アプリだとロール以上の分析は不要になると思うよ
    • 人間味を排除してロールで考える -> アクターの考え方（同じロールの人であれば誰でも使えるように考える）

• 業務アプリでも「コンピューターの操作には慣れている」などの情報は必要、あると嬉しいと思う

  • UX設計を考える時にそういうポイントはとても大事になるね

• みんな「ペルソナ分析」という言葉で通じるの？

  • 「ペルソナ分析」という手法に触れることが今までなかったよ
  • サービス系だと必ず必要になる分析だよ（どんな人が使うかを考えずにサービスを作る事はまずないかな）
  • ペルソナ分析という言葉を使わなくても「これは誰がどのように使って幸せになるんだろう」と作る時には考えるよね
    • どういう風に使うかわからないからまず触ってもらおうというアプローチをとる事もあるよ

• ペルソナ分析をするのはいつ？ -> 企画・分析 の段階でまず使うかな

• フローチャートのあとの設計って何をするんだろう、何となくフローチャートができれば設計は完了な気がする

  • ここに書いていない事だと、作業許可書への入力項目とか、承認者ログインが必要かどうかとか
  • インプットとアウトプットをはっきりさせる必要もあるね
  • これとは別にペーパープロとタイプを使った画面設計をする必要もあるね

• この本に書いてある順番のまま分析と設計を行う必要はないよね（フローチャート->ペルソナ->ペーパープロトタイプ）

• ツールやテクニックいろいろ

  • コンカレンシー図ってなに？
    • 並列処理を表す図一般？
    • あまりにマイナーすぎてわからないよ・・・
  • プロセスマップって何？
  • ワイヤーフレーム
    • 配置のバランスを考えるもの、画面デザイン

9.5 ステップ2：開発：作業する

ペアプログラミングってどうなの？

• ペアプロしたことありますか？
  • 大事なところだけやっている
  • 業務でやったことある
  • 「ペアプロやってる」という定義が難しい
• ペアになる人の組ってどうやって決まるの？
  • 初心者×初心者は絶対にNG （生産性が上がらない）
  • 技術に差がある場合は「技術継承」、教育目的になるよね
  • ドメイン（知識がある領域）が違う人同士だと技術に差があっても良い感じになる
    • 業務仕様を熟知している人と、技術力のある人など
• 教育目的以外では導入しづらいと感じているよ
  • 技術レベルの高い人はペアになるより一人づつ作ったほうが、成果物が速くできるんじゃないかな
    • そのコードがどうしてそうなっているか、という経緯と理由の知見を持っている人は増えると思う
  • 教育と言うよりは「学習」じゃないかな、プロジェクト内での学習、先行投資と考えた方がいいと思う
  • 属人性の排除、意識共有という意味ではとても大事
  • 全体のレベル（ボーダー）をあげる事もできると思うよ
    • 極端に質の悪いコードが埋もれないようになると思う
• はじめてモジュールを触るときにそれを知っている人に横にいてもらうというのはとてもよいペアプロの形だったよ
  • あくまで横にいてもらう、実際に書くのは初めて触る人
• ペアレビューをしたことがあるよ
  • ペアで別の作業、第三者を連れてきてレビュー
  • ペアレビューだと「何故そういうコードを書いたのか」という経緯を共有するのは難しかった
• レビューって効果薄い - 学習効果があまりないと感じているよ、それよりはペアプロの方がよい
  • 指摘することが「まちがい探し」のように思われる
  • 裁判っぽいと感じる人、怒られたって感じる人は結構多いみたい、晒し者にされている気持ちになるらしい
    • 「誰のコード」という意識があるのだろうね
    • 書いたものが否定されるのはいやだという人はいるみたいだね
    • 「なんで？動くのにいいじゃん」という人へレビューするのは結構辛い
  • レビュー好きだけどなぁ
    • （読書会に参加している人はレビューする／されるのが好きな人が多数だった）
  • 皆でレビューして自分のコードも良くしていこうと思えたらいいよね
  • えにしテックレビュー道場をやってます！
    • 本気で書いたものをレビューされないと面白くない
    • ここまでやった、これ以上１人ではうまくかけない、と言う所まで高めてからレビューをしあう
• 「テストをペアで」ってどういうこと？
  • 項目表があればペアでやる意味はないよ
  • 探索テストとかTDDのペアプロとか
  • ペアでやる必要があることもあるよねー
    • テストは繰り返し作業が多いけど単純作業ではない
    • あるテスト手順を手順通りにできているか、バディの役割があるといい事もあるよ
• 探索テストと文書化されたテスト、ユニットテストは違うもの？
  • アジャイルのプロセスでのテストリストって「要求を満たしているかどうか」しかないから探索テストでしか品質を高められないんじゃないかな
    • そんな事はない、品質を犠牲にすることはできない、イテレーション毎に品質を作り込んでいくイメージ
      • よいコードを書く、自動化テストなどを通じて
  • （テストの話はテストの項でしましょう） -- 時間切れでした
• ペアプロしてよかったなと思ったことはどんな事だったかを聞いてみたかったなー

---

次回は2月28日（火）9.5の中からです。