「リーン開発の現場」 - 大好き！にちようび

この記事は「ひとりでアジャイルo0h② Advent Calendar 2021」のday-3です。 adventar.org

今日から12/10までは「リーン/カンバン祭り」です。連続的に、リーンやカンバンを中心的な話題として扱った本を取り上げていきます。

day-3は「リーン開発の現場」になります。

どんな本

読みやすい文章でワクワクする内容、そして180ページほどのボリューム！という嬉しいことづくめの本です。
タイトルに相応しく、「リーン開発を現場に取り入れていることで、(問題と効果の両面で)何が起こるか？」を叙述した本です。
何というか、「こういう事が起きました」「だからこういう風にしたんだよね」を、副音声付きで聞いているような感じがしました。

個人的には、「まずはちょっとアジャイルやリーンとかの概要・原則を知ってから読むと、内容が入ってきやすいのかな？」と思います。平たく言えば、「リーン開発を知ってみたい」と思って「1冊目に読むべき本」とはちょっとズレるのかな？と。

ただし、文体含め内容的には小難しくなく、背景・原理の解説も丁寧に施されているので、そんなに気にすることもないかもです。
「この本の対象読者」には、「チームリーダー、マネージャー、コーチ」が主な対象である旨が述べられている一方で、「必ずしもマネジメント側や開発者でなくても、ソフトウェア開発者やリーンに興味がある人には役に立つ部分もあるはず」とも説明されています。実際、「(工業)製品開発のやり方をソフトウェア開発に適用したもの」がリーンの生い立ちであることを考えると、「業界に関係なく役に立つ部分がある」だろうとうのは道理です。
そんな訳で、「リーン(開発)って何？」というよりは「リーン開発を取り入れていくには？」に興味のウェイトが置かれる人がメインなのかな、と感じるところです。
(まえがきの言葉に従えば、「アジャイルやリーンの初心者であっても心配しなくてもいい。」であり、17章の言葉を借りれば「おそらく，この本を読んでいるほとんどの人は、アジャイル愛r−ンの原則について基本的な知識を持っていると思う。」です。)

それにしても、「角谷信太郎　監訳／市谷聡啓・藤原大　共訳」であり、また冒頭の読者の声に「メアリー・ポッペンディーク(リーン開発の本質などの著者)」「ケント・ベック」「ウォード・カニンガム」がいきなり並ぶなど、かなり”信頼できる1冊”感が激アゲです。

著者のヘンリックさんについては、読後に何となくなツイートしたらこのようなRTを頂きましたw

その後、ジョナサンはヘンリックに声をかけられて、ひとり親方LLCをやめてSpotifyに就職するのであった…(そして『ユニコーン企業のひみつ』へ続く) https://t.co/zZvrtHk7lU
— Kakutani Shintaro (@kakutani) 2021年11月23日

(”ジョナサン”氏のアジャイルサムライについては、day-4で扱います)

お気に入りポイントかいつまみ

段々と現場が良くなっている感がワクワクする

カイゼン・ジャーニーやSCRUM BOOTCAMP THE BOOKほど「チームが進化していく物語」ではありませんが、本書の前半(第1部)は1つの企業(スウェーデン警察のプロジェクト)において「とても大きなプロジェクトの中で、どのようにカンバンとリーンの原則を適用したかがわかるように事例を紹介」するものになっています。
実体験に即しながら所々のプラクティスを適用していく感じは、導入される各プラクティスに「必要性、求める効果」についての納得感を持たせてくれました。

その雰囲気は、目次を見ることで何となく感じ取ることが出来るでしょうか。

第1章プロジェクトについて
第2章チーム編成
第3章デイリーカクテルパーティーに参加しよう
第4章プロジェクトボード
第5章カンバンボードをスケールさせる
第6章プロジェクトのゴールを追え！
第7章準備OKを定義する
第8章技術課題をさばく
第9章バグをさばく
第10章継続的プロセス改善
第11章 WIP をマネジメントする
第12章プロセスメトリクス
第13章スプリントとリリースの計画
第14章バージョン管理の方法
第15章アナログなカンバンボードを使う理由
第16章僕たちが学んだこと

これによって、例えば「カンバンとはこういうものである」という定義の話より踏み込んで、「こうしたいから、カンバンをこう使う・こういう風に変える」といった事例にも触れていけるのです。

「柔軟」な開発アプローチが語られている

リーン開発にも「ルール、べき」だったり中心的なアプローチはあると思いますが、(特にスクラムからアジャイル似興味を持った人などは)「やらなきゃいけないこと」を意識したくなるかも知れません。
この本では、あくまで「現場の課題を解決するために、手法を導入する」という態度が強く見られます。
もっといえば、まえがきにある「注意してほしいこと」において次のような記述があります。

ボクは自分たちのやり方が、完璧にリーンであるとは主張しない。リーンは向かうべき方向であり、ゴールではない。継続的な改善。これがリーンソフトウェア開発のすべてなんだ。 (中略)
だから、実践してきたことは、期せずしてアジャイルの原則に多くの点でとても一致している。

(Px まえがき)

逆に言えば、「こういう方法を使うべきだよね」という語ではなく、「こういうところを解決すべきだよね」が自ずと先に語られるようになるわけです。

印象に残っている箇所を具体的に1点挙げるなら、「12章プロセスメトリクス」の章にあるコラムで「なぜ本番リリースまでのサイクルタイムを計測しないの？」があります。
一般的に、「サイクルタイム(スループット)」を扱う際には、「リーン開発で行いたいのは素早く・持続的に顧客に価値を届けること」という原則に従って「本番でプロイされるまで」「Time to Market」が想起されると思います。しかし、本書の事例の環境では「受け入れテスト準備OK」を終点としてサイクルタイムの計測をした、と。
受け入れテストを経てリリースサイクルが完了するまでの工程が、「かなりがっちりと決められていたこと」が問題だと述べられています。そして、それは「ウォーターフォールから移行したことの名残とも言える……。」とも。
それ故に、このような対応が採択されたのです。プロセス上で自分たちがコントロールできるのが「受け入れテスト準備OK」であること、また「僕らの経験だと、深刻な問題は受け入れテスト中にめったに見つからなかった」ことが材料として挙げられています。すなわち、「ワークフローの中でも、「受け入れテスト準備OK」までのサイクルタイムを計測すれば、問題発生のリスクが高い部分をカバーすることができた。僕らにとってはそれで十分だったんだ。」と説明できるわけです。

このような著者の態度は、ただの「理想論」ではなく「現場」の話なんだな〜と説得力を増しています。