「リーンソフトウエア開発~アジャイル開発を実践する22の方法~」

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

day-4は「リーンソフトウエア開発~アジャイル開発を実践する22の方法~」です。

どんな本

オリジナルは2003年ということで、アジャイルマニフェストがまとめられた2001年から数年ほどの世界に生まれた本になります。
本書の著者2名が「リーンソフトウェア開発」の生みの親であり、もっと言えば「アジャイルマニフェストができた頃にはなかった言葉」が生まれたのが、この本が世に出た時代ということになります*1

そのため、「工業製品の生産におけるやり方」を「いかにソフトウェア開発に適用できるか?」という、今のような「(ソフトウェアの)リーンありき」ではない視点で書かれているのが本書です。そうした背景を踏まえた上で、副題「アジャイル開発を実践する22の方法」に目を向けると、その意味合いが少し味わい深く感じ取れるのではないでしょうか。

まえがきを見ると、著者らが「アジャイルなプロセスが、なぜ正しい(本質的に証明できる)のか」について考えている際に、工業製品の現場などで以前から取り入れられている「リーン手法」に多大なヒントを得て、「ソフトウェア開発でも、もっと”無駄”をそぎ落とせる」ことを学んだのだ、と分かります。
「価値を素早く、無駄なく届ける」ためのヒントを紹介するのが本書です。

22(節)のプラクティス・視点を、7つ(章)の原則に分類して*2紹介されています。 最終章となる8章は、これらの原則を「どうやったらスムースに適用できるか」を述べているものです。

ということで、目次の一部を引用しておきます。

  • 第1章 ムダを排除する
    • リーン思考の原点
    • ツール1: 無駄を認識する
    • ツール2: バリューストリーミングマップ
  • 第2章 学習効果を高める
    • ソフトウェア開発の性質
    • ツール3: フィードバック
    • ツール4: イテレーション
    • ツール5: 同期
    • ツール6: 集合ベース開発
  • 第3章 決定をできるだけ遅らせる
    • コンカレント開発
    • ツール7: オプション思考
    • ツール8: 最終責任時点
    • ツール9: 意思決定
  • 第4章 できるだけ速く提供する
    • ツール10: プルシステム
    • ツール11: 待ち行列理論
    • ツール12: 遅れのコスト
  • 第5章 チームに権限をあたえる
    • 科学的管理法を超えて
    • ツール13: 自発的決定
    • ツール14: モチベーション
    • ツール15: リーダーシップ
    • ツール16: 専門知識
  • 第6章 統一性を作りこむ
    • 統一性
    • ツール17: 認知統一性
    • ツール18: コンセプト統一性
    • ツール19: リファクタリング
    • ツール20: テスティング
  • 第7章 全体を見る
    • システム思考
    • ツール21: 計測
    • ツール22: 契約
  • 第8章 使用説明書と保証書

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

7つの原則

どんなものも中心には原則を据えて話をすることが多いですが、特に本書で挙げられている7つの原則は共感しやすいものが多いな、と感じました。 やるべきなのは「ツールを活用する」ことではなく、「原則に従う」ことなのだなぁと改めて思います。

結果として、 「アジャイルって、結局のところ何を目指すんだっけ?」をイメージしやすい本であるとも感じました。 本書は、「他の業界の動き方をソフトウェア開発に適用する」という野心に溢れたものであって、ある意味では「前提(リーンソフトウェア開発とは?)を共有していない人にどう説明するか」が目的になります。
そういう理由から、全体を通じて「なぜ必要か」「それの良さはどこか」について論理だって説明されているように感じました。価値(アウトカム)に直結するようなソフトウェア開発を、という挑戦が見て取れました。

スクラムにせよカンバンにせよXPにせよ、「どういう状態を目指したいか」でいえば「適応的に動いて、無駄を排除して成功率を上げよう」であり「臨機応変さを手に入れるためにはモチベーションの統一とコミュニケーションを大事にしよう」なのかな?と思います。
それらが、「7つの原則」という形でまとめ上げられて、各章では「それ(原則)は何であるか」という解説から始まって、その実現のためのツールが並んでいきます。

「リーンソフトウェア開発」というカタログだったりフレームワークがあるからそれを説明しよう!という訳ではないし、あくまで「アジャイルを目指すための取り組み方」という視点での話、でもあるのです。

書かれている内容は、至極真っ当だと感じます。

「リーンっぽい」部分

言い方が適切かはわかりませんが、リーン開発の本なので当然ながら「このあたりがリーンぽいよな」と感じられる内容がふんだんに取り上げられています。言い換えると、「スクラムについての勉強をしてもあまり言及されないような、プロセス/プロダクト改善に役立ちそうなプラクティス」です。

例えば「無駄を排除する」ではバリューストリームマップの話がでてきます。「開発を早くするためにペアプログラミングをしよう」とか「バグを減らすために開発者がテストを書こう」といった話よりも外側の、「開発工程全体でのボトルネックを探り、認識しよう」という話です。

第3章「決定をできるだけ遅らせる」にて取り上げられている、「コンカレント開発」「ツール7: オプション思考」「ツール8: 最終責任時点」「ツール9: 意思決定」は、コレも(最初の原則である)「ムダを排除する」の実現のために「最終的に価値のあるものを作るが、そこに至る過程で手戻りや非効率をなくせ」といった話に感じました。
これはアジャイルマニフェストの「計画に従うことよりも変化への対応を」あるいは背後にある原則の「要求の変更はたとえ開発の後期であっても歓迎します。」に直結しているようにも感じます。

それ以外にも、(カンバンの形に至る)「プルシステム」「待ち行列理論」の話も、自分の中にある「リーンといえば?」のイメージに応えるものでした。

まとめ

全編に渡って、とても重要で視座の高いことが書かれているなぁと感じます。
アジャイル関連のツールや思考について、「何がどれ(のプラクティス)か?」を考えることにはあまり意義を感じませんが、例えば「スクラムの勉強をしている」という人にも薦めてみたい本であると言えます。何となく「別物」と感じて遠ざかっている・・のであれば勿体ないな、と。
(そもそも、スクラムガイドには スクラムは「経験主義」と「リーン思考」に基づいている。 と書かれていますし、間違いなく「リーン的」なものを学ぶ価値は高いと感じますが。)

*1:興味深い記事。とても参考になります https://fkino.net/20141014.html

*2:まだ手に入れられていないのですが、「リーン開発の本質」では「リーンの7大原則 」が紹介されているとのことです