第15回読書会

• 2012年02月28日 19:00-21:00
• エスプランニング開発室
• 参加者 4人
• 9.5 ～ 9章終わりまで

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

• "本書で説明しているアジャイルの魔法を引き起こすことには、本格的なエンジニアリングのプラクティスで支えなければならない"

• 唐突でびっくりした。 今まで心がけみたいなことしか書いていなかったように思えたから余計に意外に感じた

• "エンジニアリングのプラクティス"は絶対必要、むしろ前提条件になっていると思っていたから違和感はなかったよ

  • いわゆる"アジャイルプラクティス"が必要という文脈ではなく、"エンジニアリングのプラクティス"の話だよね

• 「アジャイルのプラクティスを行なっていればアジャイル開発だ」とか「アジャイル開発にはアジャイルのプラクティスが絶対必要」とかそういう文脈ではないね

  • プラクティスだけをやればアジャイルか => そうではない

• ここでいうプラクティスとは具体的にどんなこと？

  • 194ページで箇条書きになっている項目 => 具体化したものが195ページにある（12章以降に書かれている）という構成だと思うよ

• ペアプログラミングって実際にやっていますか？ やったことがないのでよくわからない。

  • どういう人の組み合わせでやるのですか？
    • 新人 × 経験豊富な人 -> 片方の成長が目的
    • できる人同士 -> 状況、相性次第
    • 中堅者同士 -> お互いに成長し合う
    • 初心者同士 -> やってはいけない
    • ないものを持っている人同士、ドメインが同じ人同士 -> お互いが補い合ってうまくいく
    • プログラマとテスター、デザイナーなど -> ほかの業務を知りたい気持ちがあるならうまくいく

• 実際「ペアプロやりましょう」って上司にいいづらいし、同意を得にくいような・・・

  • 提案して受け入れてもらうのは現実問題なかなか難しいよね
    • 説得できる数値が出ている訳ではない（数学的な数値でいえば開発のコストは倍に見えるので）
  • チームリーダーが責任を持つつもりで導入 -> 導入成功してメンバーがいいね！という気持ちになる -> 広められる可能性もある
  • 「プログラミングは単なるタイピング」であるという文化のところにペアプロを導入するのは難しい
    • 詳細設計書通りに作らねばならない、頭を使ってはいけない という文化
    • プログラミングは知的創造であるということはアジャイルを推進している人たちの前提条件なのだけど、そう思っていない文化も根強くあるよね
  • ペアプロは万人向けのプラクティスじゃないという点は注意が必要
    • 何でも強制的に導入すれば良いわけではないよ

• ペアプロのよいところってなんだろう

• コミュニケーションがとれる、会話が増える

• 相性の問題もあるので、定期的にペアがかわる方が望ましいね

• イテレーションゼロについて

• 普通のイテレーションと同じ期間なのかな

  • そうは書かれていないし、そうである必要はないよね
  • イテレーションゼロとなる期間が長い場合もあるよね

• 「イテレーションゼロ」の期間、チーム全体で環境構築をするためには、環境構築スキルが全員にないとだめだね

  • イテレーションゼロの期間はメンバー全員で準備に取り組める必要がある、そのためにはチームメンバーが個々に何らかの環境構築できるスキルが必要になるね
  • 環境構築スキルがある人が限られていて、環境構築が属人的になってしまっているプロジェクト（会社）はあるよね

• スキルって各個人で学んでいくの？会社によって環境構築手順書があって誰でもできるようになっているもの？

  • 個人の努力でスキルを身につけることが必要
  • 全体の手順は会社としての基準を共有できるけど、どうやるか、方法は個人で習得しなければいけないとおもう
  • クックパッドさんの開発支援チームのような部署（チーム）が社内にある形は理想だね

• コードの共同所有っていう考え方はいいと思うけど、そういうプロジェクトはなかなかないよね

  • 共同所有は「誰のものかわからない」じゃなく「チーム」のもの、である意識が必要
    • チーム名は「メンバーの連名」という考えである
    • そこを間違えると誰もコードに対して責任を持たなくなる危険がある
  • アジャイルの考えが共有できて初めてそのチームで「コードの共同所有」ができるようになるね
    • 「コードの共同所有」をアジャイルのプラクティスとするのはちょっと危険
    • 考えが育った上で「コードの共同所有」という意識が芽生えることが理想だね

• コードの共有所有って具体的にどんなもの？想像がつかない、物理的にはソースコード管理しておけば共同で使っているよね

  • タイポを誰が直すか、バグを誰が直すか => コードによって「担当者」が決まっていないこと、気がついた人が直すことのできる空気
  • 具体例を挙げて：
    • 例えば、 Aさん, Bさん, Cさんがそれぞれ モジュール1, モジュール2, モジュール3 を作ったとする。
    • Bさんがモジュール1の不具合を見つけた
    • Bさん自らが直してコミットするか、 Aさんに「不具合です」とだけ伝えて終わりにするか
    • ・・・・というような意識の違い
  • ソースコードを勝手に触られるのを嫌がる人もいるよね
    • アジャイルなプラクティスが肌に合わない人の例だと思うよ
    • 全部がそうとは限らないけれど、こういう人はペアプロも好きではなかったりする傾向があるね
  • プロジェクトのソースコードをまるごと「自分が責任を持たなければいけないもの」と思えるかどうかだと思うよ
  • 自分の作業に壁を作る（自分がやるべきところはここだけ）と共同所有の考えには発展しにくいね

• 共同所有をするためには前提としてやっておかなければいけないことがいろいろあるよ

  • バージョン管理がされていること
  • こまめにコミットしていること
  • コミットコメントをきちんと書いていること、全員が他のコミットログも追っていること
  • テストが書いてあること
  • 上記のようなエンジニアリング的なプラクティスはコードを共同所有するための前提になるね

9.6 ステップ3：テスト：作業の結果を確認する

• 197ページの文脈"アジャイルプロジェクトは何もかもをテストしているはずなのにリリース前には正式な受け入れテストも必要なの？"がわからない
• 受け入れテストに二つの意味がある
  • ユーザー受け入れテスト
    • ストーリーの受け入れテスト
  • 製品に対する受け入れテスト
    • 製品がリリースされる直前に行う正式な受け入れテスト
  • ステージング環境、プロダクション環境の違いがある
• ここでいう受け入れテストって何？どの段階のテストのこと？
  • ユーザー受け入れテスト？ストーリーの終わり毎にやるものだとすると文脈がおかしいよね
  • そもそも、ユーザー受け入れテストが終わらないとストーリーが完了しないはず
• 要求（ストーリー） -> プロダクト ->(ここでユーザー受け入れテスト)-> （ここでイテレーション分まとめて受け入れテスト="正式な受け入れテスト"）出荷 となるのではないかな
• 出荷のタイミングはイテレーション毎ではないこともある？
  • 本気になるタイミング ＝ リリースするとき なので イテレーションごとに正式な受け入れテストが発生しないこともある？
• なぜ"正式な受け入れテスト"が必要か
  • お客さんが本気になっていない -> バグが見つかりにくい
  • ソースコードは完璧か -> 血眼になってバグを見つけてもらっていない状態で完璧と言い切れるか？
  • リリース前は慎重になるべきということを伝えているね
• 受け入れテストやリリースをどうするかという点に関して書かれている量が少ないね
  • リリース、受け入れテストについてもう少し書いてほしかったなぁ
  • なにをもってリリースとするか、リリースしたらどうなるのか、など

9.7 カンバン

• ここで「カンバン」がでてきたのは、運用やサポートなどでは「カンバン」を使った方がいいよ、という流れだね
• タイムボックスがないことが一番大きな違いかな
  • 一定期間で何をやるか、ではなくて、限られたリソースで一度にできることはこれという見せ方なのが重要だね
• 早く完了に流さなければ次にいけないというのが見えやすいね
  • 進捗90%で未完成（停滞したまま）という状態を減らすことができるね
• 運用が前提だとすると、TODOがゼロになることはないね
• 各イテレーションが長い場合、イテレーションの中のタスクを細かくしてカンバンで運用するというのはありかもしれないね
• タイムボックスより短い周期で考えないといけない作業がたくさんある場合はカンバンが必要になるね
  • 個人のTODO管理のレベルの内容をチーム全体が早く共有しなければならないとき -> ソーシャルゲームなど
• スループットをどこまであげることができるのかが大事になってくるね
  • 完了になるまでのスピードがある程度ないと流れが悪くなる
  • 終わりどころのわからないタスクをどうするかを考えないといけないね
  • カンバンでも「やめどき（完了）」を定義していないと危険だね
• 「僕らは僕らでがんばっている」からといってずっと同じ仕事をしていていいわけじゃないよね、いつまでも時間をかけられない
  • 期待をマネジメントしやすいけれど、ずっと同じ仕事をしていることもすぐに分かってしまうよね
  • お客さんからみて進捗がわかりやすい、優先順位を示しやすいんじゃないかな
    • 平鍋さんの話（ブラジルの開発現場の話）でもお客さんに見える形になっていることが大事って話があったよね
• カンバンが動いていない = 進んでいないことがまるわかり
  • カンバンを使ってタスクを見える化したら、何が滞っているのかがすぐわかる
    • お客さんの返答待ちのタスクがたくさん溜まっていくなどの問題点を共有できた
    • 返事待ちが増えるとWIPを動かさざるを得ない = よくないこと という意識の共有
• カンバンは導入が簡単で運用が難しいね
  • タスクが動かないとカンバンはすぐに死んでしまう
  • 状況が確認できる、未来をみるためのものなのかなー
• お客さんがわがままだとカンバンは破綻する？かもしれないね
  • それはまた別の問題だけど
• カンバンのプラクティスは札幌だと一番話を聞きやすいのではないかな（実際にやっているところが多そうだよ）
  • 聞いてみると面白いかも
  • ほかはユニットテストかなー
    • インテグレーションテストの活用例はまだまだ少ないかもしれない
  • ペアプロもやっているところはあるね

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

• "収まらないなら、それは収まらないのだ"
  • お客さんの同意を得ることの重要性
  • そういう場合もあるよね
• 成果を早く出すために、タスクを切り分けて出すほうがよいかもケイスバイケースだったりするね
  • 例えばビックデータの解析プロダクトだった場合に、ビックデータの調査(Hadoopなど）をせずに小さなデータの解析結果を渡しても、そこに価値はあまりないのかもしれない

---

次回は第10章からです。 3/13開催です！