Kanban and Scrum 〜 デブサミ2013 OpenJam で発表してきました。

デブサミ2013の Open Jam で発表をしてきました。
最近周りでカンバンについて整理してほしいという要望をいただいたので、作ってみた資料です。

今年も関さん( @m_seki )に鋭いご指摘を頂きました。「ScrumとKanban、入り口をあえて分ける必要がないのでは?」うーむそうかもしれません。どっちから入っても、Kanbanなら多能工が重要になってロールがオーバーラップしていくし、Scrumなら徐々にプロセスが安定化して列が増えていきます。関さんとは昨年のOpenJamでのSECIモデルの話を一緒にさせていただいたのですがすごく勉強になりました。

instagram白羽さんに撮影していただいた風景です。( instagramからの貼付け方が分からず画面キャプチャです。)

結構、聞いてくださる方が多くて感動しました。(ほとんど技術と関係ないカンバンの話ですみません。)

長々と謝辞(忘れないうちに....)

トヨタのカンバンについては2008年の暮れくらいに当時初対面の原田騎郎さんから聞いた内容がほとんどです。書籍からいろいろ補完したものはあるけど、やはり根本の理解は原田さんから頂いたものが基盤にあります、大変感謝しています。Kanban手法については平鍋さんと知り合った2008年当時から平鍋健児さんがプッシュされていて、調べるきっかけを頂きました。トヨタのカンバンについても緻密な記事を書かれています。しかし、正直当時はScrumすら学習中でしたので、消化不良であったのが大変悔やまれます。そして、本資料でも引用させていただいてますが、Henrik Kniberg さんのいくつかの資料は、いつもシンプルにまとまっており、私の理解を促進してくれました(この資料を思い出させてくれたのは同僚の藤原大さんのおかげです)。Henrik さんの最新の著作 Lean from the Trenches
は Kanban 手法を大組織に適用してみた事例が中心です。安井力さんは「Kanbanゲーム」を通じて、多能工の重要性を体感させてくれました。バリューストリームマッピングはもちろん Mary Poppendieck さんに教えていただきました。特に2番目の本「リーン開発の本質」が私の好みです。スクラムのタスクボードについては、非常に多くの方から教えてもらいました。Bas Vodde さん、Jim Coplienさん、Jeff Sutherlandさん、Gabrielle Benefield さんには研修を通じて、実践的な使い方を教わりました。最初にカンバンとスクラムのタスクボードが違うんだという点について指摘をしてくれたのは懸田剛さんです。また、実践を通じてともに学ぶ場所を提供してくれた同僚の皆様に厚く御礼申し上げます。

コミュニティブース

今回はアジャイルUCD研究会のコミュニティ枠ということで参加してきました。毎年、コミュニティが集まる素敵な場所を作っていただいているデブサミ事務局のみなさまに感謝いたします。

たぶん10月あたりから1月にかけてほとんどコミュニティ活動ができていなかったので、久しぶりにゆっくりコミュニティブースに座っていろんな方と話せたので、収穫が多かったです。

コミュニティブースのある廊下に滞留する人が増えたことが、とても嬉しいです。
これはきっと計測はされないし、コストもかかることだし、ほとんどの会場空き待ちの人からみれば仲間内で変な人達が集まっているようにも見えるかもしれないけれど、そういう境界面がぱっくりと口を開けているということが重要かな、と思う次第です。整理された境界面の内側で泳いでいても何も変わらないし、水面があれば間違って飛び出ちゃう人が常に一定数いるものと信じます。

以上、ありがとうございました。

アジャイルとリーンの図を公開いたします。

発表の途中で作ったアジャイルとリーンの図を公開いたしますー。
https://dl.dropboxusercontent.com/u/2873528/AgileAndLean.jpg
https://dl.dropboxusercontent.com/u/2873528/AgileAndLean.pdf

インセンティブと報酬 〜 「リーン開発の本質」より

野中先生と平鍋さんの「アジャイル開発とスクラム」が出版された。まだレビューできないでいるのだけれど近いうちにぜひ。プランニングポーカーの説明の部分は本ブログを参考にしていただいたようだ。ありがとうございます。

平鍋さんが経営寄りの視点で本を書くのはメアリーポッペンディークの「リーン開発の本質」以来のことではないかと思う。このリーン開発の本質は、私もイノベーションスプリント2011を企画している段階で読み返し、愛読していた。イノベーションスプリントは経営者やマネジメントにスクラムを届けるために企画したものだったからだ。

リーン開発の本質

リーン開発の本質

昨年10月に改めて平鍋さんがブログを書いている。「『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。

この本の中から、インセンティブと報酬についての項目が目に留まったので、読み返しつつ紹介したい。チームの活動を推進する上で、いずれは避けて通れない課題として出てくるケースも多いのではないかと想像する。一個人では、簡単には変えられないだろうが、本質的な課題だ。

p.176 インセンティブ

インセンティブについては、ダニエルピンクのDRiVE(モチベーション3.0)で成果報酬の限界について語られていて、日本でも多くの人の共通言語になりつつある。スタンフォード大学の Bob Sutton 教授の 「HARD FACTS」(事実に基づいた経営)でも成果報酬制度はモチベーションへのマイナスの影響の方が大きいと批判されている。

「リーン開発の本質」では、エドワード・デミングの教えとして、同じものを扱っている。

業績評価

                        • -

おそらく、デミングのアドバイスの中で、最も無視されているのがこれだ。「従業員に対する毎年の査定をやめる。個人の成績を評価して、チーム内の協力関係の土台を崩してはならない。」デミングは、毎年の成績評価は協力よりも競争を生み、職人のプライドをだめにしてしまうという信念を持っていた。しかし、業績評価は個人が企業と暗黙的に取り交わしている契約の内容によって、異なる目的を果たす。営利企業では、従業員は給料とスキルと交換するという契約を結ぶが、能力査定の目的は、個人が受け取るべき給料の額を決定することだ。いかにも、この目的は協力よりも競争を促す傾向が強い。

一方、企業が各個人の潜在能力を最大限に引き出すことに全力をあげれば、業績評価は、どこに潜在能力が眠っているのか、そして個人の潜在能力をのばすために、企業や個人がどのような手段を講じるべきなのかを顧みる時間になる。そのため、個人が技術やマネジメントで着実に能力を高めているか、翌年にどのようなトレーニングや仕事の担当をすればよいか、キャリアの発展のためにはどのような分野(たとえば、プレゼンテーション能力など)をのばさなくてはならないかを、誠実かつ率直に考えていれば、給与査定システムは不要である。

(中略)

能力査定の基準では、(もし現状がそうでないなら) 個人の業績よりも、チームの成功への貢献を重視し、チームワークに重点を置くべきである。

(中略)

評価は一方通行であるため、評価される側の人だけが改善しなくてはならないという印象を与える。しかし、デミングは、効率に関する問題のほとんどが、マネジメント側の問題であると主張している。ある社員の効率が芳しくないのであれば、マネジャーはまず、「自分の行動のどこが間違っているのか?」と問うべきだ。マネジャーは、組織の業績に対する責任を負い、システムの効率を改善するために、部下と協力しなくてはならない。

P.178 報酬

続く「報酬」の項で4つのガイドラインを提案している。

昇格(役職)と昇給(報酬)を分け、ふさわしい役職につけ、一方で報酬は分けて考えるべきとのことだ。

社会通念では、人は自ら担当する範囲の成果に基づいて報酬を受けるべきだということになっている。しかし、情報共有と協力が不可欠な場合には、個人の管理範囲よりも影響範囲に基づいて報酬が与えられるべきなのだ。たとえば、テスト技術者は、発見した欠陥の数に基づいて報酬を受けるべきではない。むしろ開発者やテスト技術者は、欠陥のないコードを作り出すチームとしての能力を基に、報酬を受けるべきなのである。開発チームは、その作業の技術的な成功に基づいて報酬を受けるべきではない。チーム全体が、チームとして行った作業による、ビジネス的な成功に基づいて報酬を受けるべきなのだ。

成果報酬の全否定ではなく、その先の話

成果報酬が全く無意味だと否定するのが、この項の目的ではないだろう。私は成熟度の問題だと考えている。チームのメンバーは単純作業を行うワーカーだと考えれば、さぼらないように、適切な報酬を考えなければならないだろう。一方で、イノベーションを担うナレッジワーカーのチームだと考えるならば、他に検討すべきパラメータがたくさんある、ということではないかとおもう。ニンジンをぶら下げたり、ムチを入れる、という馬レベルのコントロールが、成長する人間にいつまでも使えると思っている人はあまりいないと信じたい。これといった答えはないので、偉そうなことは書けないが...。