チームの学びカンバン仕事術という本を社内で輪読会を行うので、内容をまとめてみました。カンバンに関する実例と原則など、事細かに解説してあって、いい本です。みんなで確認するために、引用しながら所感を書いてみました。見るP.48スクラム、XP、ラショナル統一プロセスなどを紹介する本では、最初の章はもっと違った内容になるはずだ。プロセスが、どのように働くかについてまず説明をするだろう。用意した処方箋はない。どんなプロセスにも適用できるメタプロセスと呼ぶのが近い。あなた自身が今いる状況を何も変えず、カンバンを適用して改善を初められるのだ。作業項目を表す付箋紙を作り、ボードに貼ってワークフローを見えるようにし、個々の項目がわかるようにする。これだけで自分たちの仕事を理解し、「仕事がどう進むか」を学び、ワークフローから改善の可能性を発見できるようになる。見えるだけで課題と答えが見えることがあります。細かいことは考えず、まずは見えるようにしてみる。これはチームでの仕事の基本原則だと思います。簡単に言うと、同時に進める仕事の数に制限を設けるということだ。WIP制限はよい意味での緊張感を生み、システムの問題を暴き出すのだ。WIP制限により、改善の機会が浮き彫りになってくる。ワークフローの流れが悪くなったり、滞留したり、完全に止まってしまったりする。人は同時に2つの作業を行うことはできません。Doingのワークフローに複数の付箋がはられており、何日もそのままになっていたらそれは事実を示しているとは言えません。Doingなのに「その日やろうと思った」タスクが貼ってあったのかもしれない。したらDoingではありません。WIP制限をした場合、例えばそこにタスクが滞留していたとしたら何か課題があることは明確ですし、WIP制限が色々な課題を見えるようにしてくれる、というのは私も経験があります。3.流れの整理ここがワークフローを常に改善し続けるという旅の出発点になる。仕事がワークフローを早く流れるようにしよう。実現のためにできることはいろいろある。この原則を使うにあたっては、リーンシンキングから着想を得られる。流れをスムーズにするために、プロセスのムダを取り除くのだ。大切なのは、仕事から得られるシグナルに反応し、そこから改善していくことだ。流れない、それこそが課題であり改善点になる、というのは本当にそうだと思います。4.ポリシーの明示ポリシーを明示しておけば、自分の考え、感覚、他の事例などを持ち出すこと無く、客観的データを使ってプロセスのことを議論できる。多くの場合、ポリシーをボードに書きだすのが最重要というわけではなく、議論を重ねながら新たなポリシーを合意形成するのが最も重要だ。暗黙的に仕事をすると、些細なことでも認識が違っていたりします。違っている事自体認識できないことがある。そのために、ポリシーを言語化し、チーム全体が認識しておけるようにする。チームで合意で作り、常にカイゼン(変える)することが大切です。自分のプロセスからフィードバックを得る方法に集中できる。運用レビューというプロセス自体のふりかえりの中で行う。これは流れの管理の一部だと我々は考えている。課題が見えれば即改善する。その改善の速度と数が増えれば増えるほどチームに変化が起き、パフォーマンスが上がっていくような実感があります。朝会やふりかえりなども通してフィードバックループの実現ができれば良いのではと思います。6.コラボレーティブな改善と実験的な進化(モデルや科学的手法を利用)チームがさらに改善するために、制約理論やリーンなどのモデルを利用するように勧めている。ここはもう少し読み進めないと具体論がまだ無かったのですが、より深みがある改善を行う場合にそのようなモデルを利用するというのは、変化の深度とスピードを上げる経験があります。始めるP.54あなたもすぐに初められる。カンバンが軽量なおかげだ。1.まず、自分たちの仕事を見える化する。我々は、作業項目を付箋紙に書き、ホワイトボードに張り出すように頼んだ。2.ボードにワークフローをマッピングする3.いくつかの作業をワークフローに流して、実際のワークフローと一致するかどうかを何度か確認する4.WIPの制限を決める。チームとして、同時に進められる仕事の数を決めるのだ。5.されに、各メンバーのアバター(小さな絵か写真)を用意して、作業中の仕事の付箋紙の上に乗せる。カンバンのいいところはこれがすぐにできるところですね。はやってみるところから始める、始められるというのは素晴らしいプラクティスだと思います。この見える化を高めて、誰か管理者一人で管理するのではなく、チームで、またはチーム間など、コラボレーティブなPJの進め方をできるようにしていきたいです。2章のみ読みましたが、この後の章も楽しみです。Yasunishiクラシック音楽好きのWebエンジニア、マネージャー、コーチ。Webのフレームワークを作ったり、サービスを作ったりしていたところ、スクラムとドメイン駆動設計(DDD)に出会いました。スクラムでの考え方に感動し、いかに最高のパフォーマンスを発揮できるチームにすることと、組織をどう変えていくかを考え続けると同時に、ドメイン駆動設計で巨大で複雑なソフトウェアをどう設計するかということを追求しています。頭で考えるのも好きですが、あくまで現場が大事。現場で体験したことをベースに、書いていきたいと思います。(2)スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。