読者です 読者をやめる 読者になる 読者になる

「Fearless Change」を読みました

書評

いいものは色々取り入れようと日々奮闘しているのですが、そうは言っても取り入れ方にもいいやり方とちょっと受け入れづらいやり方ありますよね。というわけで、お次はこの本です。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

第1部 概要

第3章 さて、どこから始めよう

最初の足がかりとして、「エバンジェリスト」パターンが紹介されています。自分が「これはいい!」と情熱を持って導入・推進しないと、何事も進まないというのは、その通りだと思います。

エバンジェリストを前提として、以下が最初に導入する際の1セットとして紹介されています。とくに、後ろ三つの(ふりかえりの時間・小さな成功・ステップバイステップ)は、いわゆるスクラムでのふりかえりでもかなり重要視しています。色々根付かせるのは、ここからですよね。

  • 予備調査
  • ふりかえりの時間
  • 小さな成功
  • ステップバイステップ

第3部 48のパターン

どうでもいい話ですが、48という数字を見ると別のものを連想しちゃいます。。。

7 ブラウンバッグ・ミーティング / 9 何か食べながら

両方とも、食べることに関するパターンです。

「ブラウンバッグ・ミーティング」は、要するにランチミーティング。ランチミーティングは結構好きなんです。時間を有効活用してる感じがするとか、お弁当持ってきてるからとか仕事上人と合わせづらくてランチ一緒に行けてないけど行きたいとかの理由で。ただ、何回かランチミーティングやったら、あまり芳しくなかったのでちょっとサミシイ><

「何か食べながら」は、そのまんまですね。食べながら話すと、リラックスできてより前向きに話し合えるとのこと。うちでも、リリース後のふりかえりとか、特別なイベントの際には経費でケーキなどを準備してもらうように進めています。あとは、ちょっと長くなりそうなミーティングの場合、1時間ぐらいでいったん休憩を挟んで、甘いものやコーヒーなどをとってもらうように仕向けるとか。

15 空間を演出する

物理的に掲載して、否応なしに目に入るようにするパターン。カンバンなどでもあるように、物理で見せるとやっぱり分かりやすい。ただ、うちはオフィスが分散してるので、ちょっと難しいんですよね。物理の力は偉大だと思ってるので、何かうまくやる方法を見つけたいとは思ってるところ。

お隣さんの製品ですが、「JIRA とアナログのボードの併用」ってのはいいアイデアだなーと思いました。一度試しにやってみたい。オフィスに遊びに行って見せてもらうかーw

www.evangelism.jp

22 種をまく

プレゼンやミーティングを行うときに、参考書籍やURLを出せるようにしておく、というパターン。割りとこれはやってる。特に、リモートの人と会話するときは、参考URLをぱっと出すと、相手もイメージしやすいので。

24 定期的な連絡

「コーチングマネジメント」を読みました - @ikikko のはてなブログにもあったけど、定期的にリマインドするの大事。何もしないと、人は忘れるものなので。

36 場所重要

少し特別なイベントを行うときは、普段の作業場所ではなく、ちょっと場所を入れ替えるというパターン。普段の場所だと、良くも悪くもすぐに普段の仕事に戻れるので、半強制的に切り替える。「9 何か食べながら」とかと組み合わせるとよさげですね。

46 恐れは無用

抵抗勢力がまったくいない状況を想像すると、ぞっとする。あなた一人で常に 100% の正しさを保証しなければならない。これはおそろしいことではないだろうか。

なるほど。こういう視点はなかった。こういうのを意識しておくと、何か抵抗や批判を受けたときも、リスクを潰してくれた・協力してくれたと前向きに考えることができるようになりますね。



基本的にこの本はパターン集なので、ざっくり頭に入れておいて、よさそうな機会に本引っ張り出して確認・適用みたいな流れになりそうかな。

「ユーザーストーリーマッピング」を読みました

書評

良くも悪くも独自の感性でやってきた今の組織に対して、外部のベストプラクティスをうまく取り入れながらよりよいやり方を模索するのが、今の自分の役割の一つです。そのうちの一つに、ユーザーストーリーがありました。ユーザーストーリーはいいものだと思うのですが、全体像がちょっと掴みにくいなあと思ってたところだったので、この本を手に取ってみました。

ユーザーストーリーマッピング

ユーザーストーリーマッピング

3章 より早く学ぶためのプラン

ちょいちょい見る、下記の図の説明が腑に落ちました。

http://blog.crisp.se/wp-content/uploads/2016/01/mvp.png

このようなリリースプランを立てれば、毎回のリリースで人々が実際に使えるものを届けることができる。しかし、私の目的が長距離旅行で、大きな荷物を持っていたら、この乗り物の例みたいにスケートボードなんかもらっても、ちょっとイラッとするだろう。(中略)あなたの目標が私を喜ばせることなら、これはまずいと思うはずだ。しかし、あなたの目標が学ぶことなら、その目標は達成できている。そう、これでいいのだ。あなたは、私がおもったより遠方まで旅行したいんだと考えていることを学んだし、その課題が片付いたら、私が楽しさにも価値を置いていることを学ぶだろう。

...

すべてのリリースを実験として扱い、何を学びたいのか忘れないようにしよう。

よく「単位を小さくリリースしろ」って言われるけど、(単位が小さいがゆえに)ユーザにとって価値が小さいのをリリースしてもどうなんだろう?と思ってました。けど、そのリリースの目的が(ユーザへの価値提供ではなく)学びであるならば、小さくリリースすることによってその学びを達成できたのであればいいことなんですね。予測と違う結果でも、「予測が違うかった」と学べたということで。

5章 あなたはもうやり方を知っている

この章では、「朝起きてから仕事に行く準備ができるまで」という題材で、実際にストーリーマッピングの作り方を試す流れになっています。こうやって、本で学んだ知識を実際に体験できるような章を用意しておいてくれるの、非常にありがたいですね。本読んだだけだと、ふむふむじゃあ実際にはどうやるの?ってなりがちですが、一度体験しておくと実導入する際にもう少し取り掛かりやすくなるので。

せっかくなので、会社で希望者募って一緒にやってみようかな。もし誰も希望者いなければ、会社の隅で一人さみしく付箋紙と戯れることになると思いますが・・・


(2016/11/16 追記)

やってみました。結果はこちら。オフィスの3~4名ぐらいが乗ってくれて、嬉しかったです。

f:id:ikikko:20161121004333j:plain

16章 リファイン、定義、構築

ミーティングの形式について。

人数がある程度以上になると、興味が薄くてスマートフォンをいじったり別のチャットをやったりする人が出てきますよね。積極的に関与するほどではないけど、会話の流れを聞いておきたい人もいるという場合に有効なミーティングの形式として、「フィッシュボウル・コラボレーション」というパターンが紹介されていました。詳細は以下の画像を。

f:id:ikikko:20161112215703p:plain

これ、割りといいなあと思いました。人数増えてくると参加者間で温度差が出て来るけど、それをうまく吸収できそう。一度取り入れてみたいですね。うちは拠点が分散してて hangouts などオンラインでミーティングする形式なので、物理的な円を描くとかはできなさそう。各参加者が、積極モードなのか、観察モードなのかを判別できるような仕組みがあればよさそう。


あと当たり前だけど、ユーザーストーリーマップを扱うときはユーザーストーリーも扱います。本の半分ぐらいはユーザーストーリーの説明も色々書かれてて参考になりました。まだ知識レベルな理解なので、ちゃんと実践投入してこの本で得た知識を活かせるようにいきたいです。(もしくは、やってみた結果今の自分たちに合わないと学んだならば、それはそれで成果だと思うし)

「XPエクストリームプログラミング入門」を読みました

書評

基本的に仕事ではスクラム(or カンバン)をベースに考えてるのですが、スクラムの中でもXPのプラクティスは補完的に使えると思うし、Webで流し読みぐらいしかしたことなかったので、今改めて。

XPエクストリーム・プログラミング入門―変化を受け入れる

XPエクストリーム・プログラミング入門―変化を受け入れる

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/12
  • メディア: 単行本
  • 購入: 3人 クリック: 55回
  • この商品を含むブログ (70件) を見る

第3章 価値、原則、プラクティス

よく出てくる用語だけど、それぞれの意味や関係をちゃんと理解してなかったので。こういうことらしいです。

第9章 応用プラクティス

「チームの継続」と「チームの縮小」。まさに考えてるところなので、参考になりました。

小規模な組織にはこのような問題はない。チームが1つあるだけだ。

...

大規模な組織は、チームの価値を無視し、代わりに「プログラミングリソース」という分子または流動体のメタファを採用する場合が多い。(中略)この戦略では、部分的な効率性は最大限となるが、全体的には組織の効率性が損なわれる。

今僕が見ているチームは、まさにスケールしている最中なので、小規模・大規模のこの辺がよく実感できます。合わせて、うちでは分散拠点なので、ロケーションの問題も考慮しないといけないのが、更にややこしいところなんですよね。もちろん、ロケーションの問題を極力埋めるために、オンラインビデオ会議などシステムで回避できるようなものも積極的に取り入れようと試みてはいますが。

第10章 XPチーム全体

メトリクス(測定値)とは何ぞや?というのを、すごい分かりやすく説明した文章があったので引用。

速度計が速度を指し示すのと同じように、開発後の欠陥と投資から収益までの時間はどちらもチームの有効性を示している。速度計の針をつかんで動かしてみても、車の速度を上げることはできない。速度を上げたければ、アクセルを踏み、その効果を確認するために速度計を見る。同じように、測定値に基づいて目標を設定できるが、チームは根本的な問題に対処する必要がある。数字を直接改善しようとしても、数字が修正されるだけで、プロジェクトに関する透明性の価値が排除されてしまう。

メトリクスはあくまで現状を測るためのものなんですよね。メトリクス自体を補正しようとしても、まったく意味がない、というのが分かりやすい例えでした。

ただ、そもそもメトリクスがないと、実際にいい方向に向かってるのか悪い方向に向かってるのかが分からない(感覚的にはある程度わかっていても)。なので、まずはメトリクスを取ってみるというところは意識付けしていきたいなと思ってます。


その他にも制約理論の話とか、ちょいちょい見たことがある話もありましたが、もろもろ再確認できました。ただ、正直なところ、何か文章が頭に入ってきづらかったんですよね。。寝不足で疲れてたとかもあるのかも。読書も持続可能なペースでいきたいものです。

「コーチングマネジメント」を読みました

書評

テクニックや知識的なところだけでなく、人と対峙する面も求められる今の役割・立場的に必要そうとは思ってた「コーチングスキル」。いくつか推薦してもらった本の中から、まずはこれを読んでみました。

PART1 : 今求められるマネジメント革命

ゴルフを教えないゴルフコーチ

ここで取り上げられてたやり取りが印象的でした。なるほど、こういうのがコーチングの基本形なのかなと感じました。

「目標に対する集中度は1から10で何点?」
「自分の体や動きに対する気づきは1から10で何点?」
「今のショットから学んだレベルは1から10で何点?」

みたいな感じで、コーチが特に技術的なアドバイスをするわけではなく、現状を気づかせる問いかけをするだけ。けれど、それによって、自分自身で考えて行動するようになる、という話。

ミスショットのときも、それを責めるとかではなくあくまで気づきを与えるような問いかけが、例に挙げられていました。

「どうやってあんなふうにボールを曲げたんだね?」
「打つ前から曲がるような気がしたし、・・・頭が混乱していたし、腕も緊張していた」
「そう、それでどんなことを学んだ?」
「混乱しているときは、仕切り直しだな」
「今までだって仕切りなおしのチャンスはあったと思うんだけど、それができなかったのはどうしてなんだろう?」
「一緒にプレーしている人の目を気にしていたのかな?」

PART3 : コーチング・スキル

クローズド・クエスチョンとオープン・クエスチョン

「なぜ?」って言葉は、オープンクエスチョンに見えて、実はクローズドクエスチョンに近いという話。「なぜ」と聞くと相手を萎縮させてしまって、結果的にクローズドクエスチョンになりがちだということです。

「なぜできなかったんだ?」
「なぜそんなことをやってしまったんだ?」

そのかわり、「HOW」や「WHAT」を使うとのこと。一般的には、HOWがアイディアを発展させて、WHATが問題をはっきりさせると説明されています。

「どうやったら、同じ失敗を繰り返さないですむと思う?」
「次はどういうふうにやる予定?」


「何が足りなかったんだろう?」
「何か気がついたことはなかった?」

効果的な質問のためにすること・実際のコーチングクエスチョン

コーチングの質問に際して考えておくべきことや、質問リストがきれいにまとまってました。ちょくちょく見直すことになりそう。

選択の幅を広げる質問

クローズド・クエスチョンの「Yes / No」「やるか、やらないか」は選択ではなくて脅迫らしい。コーチは、必ず3つ以上の選択肢を見つけ出して、自発的に選択できる状態をセットしなければいけないって。

結構難しい気がするけど、頑張ってみる。

アクナレッジメント

「賞賛」などの評価を含む言葉ではなく、事実を事実として伝える。評価が入ると、意見なので受け取りにくくなるということらしいです。「You」「I」「We」の視点があり、一番効果的なのは「We」のアクナレッジメント。

具体例をあげるのはやめておくかな。意識的か無意識的かにせよ、これと同じ言葉を誰かが聞いたとき、わざとらしく感じるかもなので。

エコロジカルチェック

何か変化があったときに、質問しながらその変化によって生じた歪みを見つけること、らしい。例えば、こんな状態になってるとして、

「頭では分かっているんだけどしっくりしない」
「何か違和感がある」
「最初はいいと思ったけど、今はちょっと」

これらの心理的な違和感や歪みを、こんな質問であらためて確認する感じ。

「今やっていることは、やる前に考えていたことと一致していますか?」
「やり方を変えて、気分はどうですか?」
「思ったような成果が上がっていますか?」
「ストレスはどうですか?」
「何か違和感はありませんか?」
「体の変化どうですか?」
「生活のバランスはとれていますか?」

要はやりっぱなしでなくて、ちゃんとアフターフォロー的なところも意識してってことかな。こういった「継続的な取り組み」ってのは、最近のマイブームというか、自分・組織に対して根付かせていきたいと思ってます。ふりかえりにしろ、例の本で学んだ見積もりと計画づくりにしろ、ここでのエコロジカルチェックにしろ。


一通り書いた後に見返してみると、ちょっとコーチングのスキル的なところばっかり目についちゃったかな。また適当なタイミングで見返してみて、そのときはどう思うかを感じてみたいです。

「アジャイルな見積もりと計画づくり」を読みました

書評

名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった&活かせなかっただろうなと思ってはいます。

1章:計画の目的

1. なぜ見積もりや計画づくりが必要なのか?

しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。

  • リスクを軽減する
  • 不確実性を減らす
  • 意思決定を支援する
  • 信頼を確立する
  • 情報を伝達する

この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。

あとは、これかな。

3. アジャイルな計画づくりとは?

本書で扱うのはアジャイルな「計画づくり(planning)」だ。アジャイルな「計画(plan)」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。

プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。

11章:「望ましさ」による優先順位づけ

狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。

モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp

16章:ベロシティの見積もり

ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション(スプリント)以上取れる場合、以下の方法が挙げられていました。

  • イテレーション毎のベロシティをそのまま幅として扱う
  • 不確実性コーンを活用する

前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。

後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。

f:id:ikikko:20160813102519p:plain

実施したイテレーション 下限の係数 上限の係数
1 0.60 1.60
2 0.80 1.25
3 0.85 1.15
4以上 0.90 1.10

ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。

うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。

22章:なぜアジャイルな計画づくりがうまくいくのか

11. ゆとりを残す

チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。

はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。

なので、最近ではベロシティ(実績)ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、(作業時間はもうちょい余裕あるけど)計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。

チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。


いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか?」は常に意識しておきたいです。

あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。

WEB+DB PRESS Vol.93

WEB+DB PRESS Vol.93

*1:この辺は「7章:再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。

「ピープルウエア」を読みました

書評

事務所にあったやつをひっぱってきたので、最新でないちょっと古いやつ。名著と言われてたけど読んだことなかったし、今の立ち位置的に読んでおいて損はないと思って。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

第 II 部:オフィス環境と生産性

騒音、特に電話の話。電話という点では、うちにはそこまで影響がないとは思ってます。が、(別チームの)ミーティングがうるさい問題は以前ちょっと感じてたので、その辺を頭に思い浮かべながら読んでました。

なお、つい先日事務所引っ越しして、ミーティングルームが増えたので、今はかなり改善されてるのかなと思ってます。

第 III 部:人材を揃える

採用における「能力テスト」についての説明が気になりました。

その人物は、能力テストで測られた作業を2年間で終え、他の作業を20年間やることになるかもしれない。

採用の際には、今できることという短期的な視点だけではなく、長期的にどうなりそうかを重視するのがよさそうだというのを、改めて考える機会となりました(もちろん、今までも無意識的にそういう風に考えていたとは思いますが、改めてということで)。

第 IV 部:生産性の高いチームを育てる

組織のビジネス的な目標、例えば「今期の利益を2倍にする」といったものが、ダイレクトに個人やチームの目標と結びつくかは分からないという話。この点も、うちではある程度解消されているのかなと感じています。というのは、自分たちが作ってるサービスを自分たち自身でも使ってるので、「サービスをよりよくすること=自分たちも楽になる」というのが分かりやすく実感できる目標なためです。

とは言っても、「自分たちのサービスをよりよくする」だけじゃ足りないところももちろんあるので、やっぱりその他やれることはやっておく必要があります。という点では、この辺かな。

チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。

このチームの目的は満たされたとき、チームのメンバーはずっと効率よく働く。一体になったことでベクトルが合ったからだ。

これを達成するためにも、チームの目標が何なのかと、それを各チームメンバーにも意識付ける取り組みに注力しようとしてるところです。


全般的に、名著と言われるほどには自分が読み解けない点が多かった気がしました。もっと経験を積んだ後に読み直すと、また違ったものが見えてくるのかなあ。

「リーン開発の現場」を読みました

書評

前回のカンバン仕事術でカンバンが気になってきたので、もう一冊カンバン系の本を読んでみました。少し昔の本ですが、カンバン仕事術が最近の本だったので、敢えて古めの本を手にとってみることに。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

第3章:デイリーカクテルパーティーに参加しよう

30人から60人の大規模チームにおける、デイリースタンドアップミーティングの効率的なやり方について。

こんな感じで、3段階に分かれてそれぞれデイリーミーティングを行ってるようです。

  • 第1段階:機能開発チームのスタンドアップミーティング
  • 第2段階:スペシャリティ同期ミーティング(テスター同士のミーティングや、開発リーダーミーティングなど)
  • 第3段階:プロジェクト同期ミーティング(プロジェクト全体に関連するミーティング)

今の自分のチームの状況と照らし合わせると。規模がここまではないので3段階はやり過ぎ感があるけど、2段階で各チーム + 開発リーダーミーティング的なのはありかなと思いました。というのも、今は自分がハブになる感じで各チームとのミーティングを個別にやってるけど、それだとどうしても自分がボトルネックになりがちなんですよね。持続可能じゃない気がするので何とかしたいところ。

第16章:僕たちが学んだこと

「実験しよう」「失敗を抱擁しよう」とか、色々いい言葉が書いてます。時々、この辺の言葉を思い出したいです。

いくつか気に入った言葉をピックアップしておこう。

完璧な解決策を探そうとしてはダメだ。そんなものを期待して待ってもたぶん仕方がないだろう。
...
その代わりに、小さく少しずつできる改善点を探して、改善を実験だと考えてみよう。

失敗への恐怖が、改善の最大の敵だ。「なぜ俺達は失敗したんだ?誰がやらかしたんだ?」と問いただす代わりに、「僕たちは何を学んだんだろう?そして、次に何を試そう?」と聞いてみよう。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

たいていの人は変化を好む。でも、他の誰かに変えられるのは好まない。だから変化を起こすときは、影響を受ける人々をまず主体に巻き込まなければならない。

第20章:因果関係図

カンバン仕事術でも紹介されてたし、「なぜ5回」とかも呼ばれてるよくあるやり方だと思うけど、この本は説明が多く例が分かりやすかったです。これやらないと、何か気持ちモヤモヤしたままになったり、ひとまず一番最初に思いついた問題に対して(結果として表層的な)解決策を実施しようとかなったりするので、大事なことかなと思ってます。結構時間使うのでいつでもできることじゃないとは思いますが、ふりかえりと合わせて、自分も取り入れ始めてみました。

翻訳者の一人の@papandaさんのスライドも合わせて。

www.slideshare.net

おまけ:5分で理解するリーンな「かんばん」

本書でもとりあげられてますが、このサイトのマンガ、カンバンやWIPの制限の紹介に便利なのでよく引用させてもらってます。

lean-trenches.com