僕はここだ!

読書記録とか、ポエムとか、メモとか、コードスニペットとか。まとまったのはQiitaにも書きます。(http://qiita.com/RyotaMurohoshi) 掲載内容は個人の見解であり、所属する企業を代表するものではありません。

読書メモ カンバン仕事術 チームで始める見えるかと改善 (その1)

 O'Reillyの「カンバン仕事術 チームではじめる見えるかと改善」の途中までのメモです。

www.oreilly.co.jp

  • 自分の疑問点を多め
  • イントロの第1部「カンバンの学習」と第2部「カンバンの理解」までのメモ
  • 1部を読むのはこれで3週目、2部は初めて
  • 1カ月くらいカンバンを使って、まわしている
  • 応用の第3部も1日1章くらい読み進めたい

1章 チーム「カンバネロス」のはじまり

  • カンバンにすべてのタスクを書き出す => 自分以外のメンバーに関係のないタスクも?他チーム・他部門と兼任の人は?
  • カンバンに入る条件はチームごと違う、この定義が大切そう。
  • カンバンは、それ自体を改良するもの
  • 『「課題」というより、「実現していない改善の機会」』 => いいフレーズ、使いたい。
  • カンバンを作る目的 => 作業項目の状況を把握する、次に何をすべきか判断する
  • カンバン見える化、WIP制限をしても、カンバンにタスクを入れる人(?)がそのカンバンを見ていない顧客であれば、タスクであふれかえるのでは?
  • 専門的なタスクが多いと手伝えないのでは? => 邪魔しないことはできる。その人がやるべき雑用をまきとることはできるかも
  • 遠隔メンバーがいる場合、物理カンバンでやる?別の手段?

2章 カンバンの原則

  • カンバンを作ることにも価値がある。暗黙的だった作業ポリシー・フローの見える化 => 一人できるもの突発タスク、煩雑なもの、リーダーだけ知っているものはどうする?
  • まずは現在のワークフローでカンバンつくること
  • 一人でカンバンをつくるのはよくないこと => 改善ミーティングもみんなでやったほうがいい?

3章 作業の見える化

  • ポリシーの明示がやりずらいこともあるかも? 流れてくるタスクが、時と場合によって違うことが多いならば、そのポリシーはどうなる?どう定義する?
  • 物理カンバンのメリットは、通りかかるだけで常に情報がみえること
  • 電子ツールには、メリット・デメリットがある
  • 最大のデメリットは、壁やホワイトボードに張っているとはカンバンを無意識でも見るが、電子ツールだとその機会がなくなること
  • 電子ツールを選ぶポイントは、自分たちにあっている設定・枠組みに変更可能かどうかという点
  • Trelloを常に大きなディスプレイで表示するのもありに感じた?アバターが見えずらいことが問題点か?
  • ステークホルダーに重要」とあるけど、ステークホルダーがカンバンを見る立場でないこともあるよね
  • カンバンの近くでメンバーが集まっていろいろ相談する、と本書にある。実際そうだったし、電子ツールを使う場合でもやはりディスプレイには常に表示したほうがいい気がする
  • 新入条件と退出条件の明示(カンバンの下に書いておく) => これやろう。

4章 作業項目

  • 簡潔に、要点を抑えて
  • 「チームの全員が理解できるように」ってあるけど、これ難しいのでは?インフラとか特に。
  • POST IT(商品名)でも微妙に色が違うものがあったから、やっかい
  • 人にWIPを制限を加えるのもあり
  • ブロッカーに滞留している日付を書くの、良さそう
  • メンテナンス・技術タスクの付箋紙がない場合は技術的負債がたまっている可能性がある、っていうのは今までにない見方だった
  • カードに書く見積もり、難しそう => S・M・L、くらいならばなんとかできそうだろうか?
  • 「完了後の付箋紙に感情を書く」 => 面白そう

5章 仕掛り作業

  • リトルの法則
  • 「二人以上の作業者を同じ作業に割り当てたときに効率が下がったりするからだ」 => そもそもアサインできない場合も
  • 『仕様には「賞味期限」がある』 => それな
  • 『僕のマシンなら動くんだけど』 => それなorz
  • 『「本番環境にリリースされていないコードも」WIP』 => それな!!!!!
  • フィードバックループを素早く回す => 他の人からのレビュー依頼やテスト依頼はすぐにやったほうがいいね!
  • リソースの稼働率 => 難しい問題だ

6章 WIP制限

  • WIP制限は運用しながら、改善する
  • 『始めるのをやめて、終わらせることを始めよう』
  • WIP制限には正解はない、改善のためのツール
  • ボードごと・列ごと・人事のWIP
  • 枠を書くなど、カンバンを工夫することでWIPを制限するのもよさそう
  • ○○完了や××可能なキューの列のWIPの数え方は場合による

7章 流れの管理

  • 『何が作業の流れを止めているのか』
  • ソフトウェア開発の7つの無駄
  • 『「流れ」対「リソースの稼働率」』
  • デプロイ待ち、リリース待ちなんかは時間が多そう
  • スウォーミング => 問題をメンバーが多く集まって一気に解決する
  • タイムボックス、実際それっぽいことをしているけど9章にあるらしい
  • 『みんなで一緒に作業を完了させるチームのメンバーであることを理解しよう』
  • 『すぐに辞められる面白い作業』とあるけれど、これはカンバンでタスク管理しなくていいの?
  • 『始めるのをやめて、終わらせることを始めよう』 => 他の人を手伝うの、(実際は難しいけれど)大事