
この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第12回目のテーマは、「リーンソフトウェア開発」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える!半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
リーンという思想
リーンソフトウェア開発は、リーン開発とも呼ばれています。
日本で生まれたトヨタ生産方式は、アメリカやヨーロッパのソフトウェア開発で活用・適用され、体系化されて日本に逆輸入された開発手法です。リーンの考えが、日本のソフトウェア産業に直結していかなかったのは、日本人として残念に思います。
リーンという言葉は、リーンスタートアップなど、現在、様々な書籍でも使われていますが、リーン開発自体はあまり話題にならないように感じています。どちらかというと不人気です。
その理由を考えてみると、リーン開発には、具体的なプラクティスが少なく、「22の思考ツール」と呼ばれるリーンの考え方(スクラムでも出てきたリーン思考)が、多く語られているからかもしれません。
リーン関係の書籍を読み解いていくと、リーン開発にはプラクティスがないのではなく、リーン思考をベースに現場に即したプラクティスを考えていきなさいというメッセージということが見えてきます。このあたりもスクラムととても似ています。
しかし、自分たちで考えるのは大切なことですが、読者を突き放したような言い方にも感じます。せっかくいい思想であっても、使われなければ意味がありません。せっかく、リーン思考、リーンの原則には、現在の開発でも通用するものがたくさんあるのに、このあたりはもったいないと思わざるを得ません。
リーン開発の本はこれまで3冊が日本語訳されています。もし、これからリーン開発を学ぶのであれば、廃盤になってしまいますが、『リーン開発の本質』がおすすめです。
この記事でも『リーン開発の本質』をベースに解説します。
リーンソフトウェアの7つの原則
リーンソフトウェアの7つの原則をみていきましょう。書籍『リーン開発の本質』を見ると、価値より原則が先に登場しています。
原則1: ムダをなくす
ひとつめは「ムダをなくす」です。「ムダ」がカタカナなのは、リーンが海外からやってきた考え方だからでしょう。英語だと「Waste(無駄、浪費)」という言葉がありますが、トヨタの考えが尊重された結果、「無駄」が「ムダ」になり、その言葉自体が海外でも通じるようになりました。
トヨタ生産方式を源流とするリーン開発なので、ムダ取りは大切な原則でしょう。ムダを見つけ、ムダをなくすことで、顧客への価値提供を最短距離で行っていきます。また、ムダをなくすのは、さまざまなアジャイル開発手法でも取り入れられている考え方です。そう考えると、トヨタ生産方式はさまざまな開発手法に影響を与えたのだと言えます。
原則2: 品質を作り込む
2つ目は「品質を作り込む」です。
事後に欠陥を見つけるのではなく、最初から欠陥が入り込まないようにしていくこと。これを「作り込む」と表現しています。
ソフトウェアだと、作ったあとでも修正ができてしまうので、「作り込む」という意識を持ちにくい部分があるのかもしれません。しかし、トヨタ生産方式だと、生産物が車なので、欠陥を後で取り除けません。製品に欠陥が入り込むと、命の危険にもなります。
日本だと、ソフトウェアのテストは、作ったものをテストするのが主流です。しかもバグを出すと大騒ぎする文化なので、大量のテストを、手動で実行する現場も多いでしょう。トヨタ出身の人が言っていたこんな言葉があります。
すでにバグが埋め込まれているものをテストしてバグを取り除いても、品質がいいとは言えない。
バグを取り除くことに必死になるのではなく、バグそのものが埋め込まれない仕組みや方法を考える必要があります。そうしなければ、開発がバグを作り、テストで発見するという、非効率なもぐらたたきがずっと続いてしまいます。
「品質を作り込む」も、開発手法全般で大切にされている原則です。
原則3: 知識を作り出す
3つ目は「知識を作り出す」です。
ソフトウェア開発は知識創造のプロセスです。プロセスを運営しながら知識を生み出し、成果物だけでなくプロセス本体も改善していきます。
原則4: 決定を遅らせる
4つ目は「決定を遅らせる」です。
ソフトウェア開発において、最初にすべてを決めるのは不可能と言えます。なぜなら、未来を見通すのが難しいからです。
書籍には「ソフトウェアの詳細な設計は、コーディングの最中に行われるものである」とも書かれています。設計を詳細に書きすぎるとコードに近づいてしまいます。だから、あえて決定を遅らせて、コーディング中に設計していく・・・のもひとつの手かもしれません。
意思決定は素早く行うことも大切ですが、「決定を遅らせる」では、大切な意思決定を「あえて」先延ばしし、ぎりぎりまで情報やフィードバックを集めて、決定を行います。
原則5: 速く提供する
5つ目の原則は「速く提供する」です。ひとつめの「ムダをなくす」でもでてきた「速い価値提供」です。
スピードを強みとすることで、競合他社との競争に打ち勝ちます。これはリーンに限らず、アジャイル開発の本質とも言える内容です。
原則6: 人を尊重する
6つ目の原則は「人を尊重する」です。
書籍には「トヨタの製品開発システムの4つの基本理念のうち、3つまでが、製品開発プロセスに携わる人に関係している」とあります。ソフトウェア開発は人間中心の活動です。
さらに、トヨタ生産方式では、自動化を、ニンベンの付いた「自働化」という表現にします。人間を大切にしたトヨタ生産方式らしい表現だと思います。
原則7: 全体を最適化する
最後の原則は「全体を最適化する」です。
リーンではアイデアが生まれてリリースするまでの流れを「バリューストリーム」と捉えて改善していきます。バリューストリームは、日本語にすると価値の流れです。リーン開発ではバリューストリームの一部分ではなく、全体を最適化します。
全体を見ず、部分最適をしても、問題がどこかに移動してまた別の問題が生まれてしまいます。だから、全体を見ながら改善を行っていきます。これは制約理論という有名な理論でも語られています。
リーンソフトウェア開発の22の思考ツール
最後に、リーンソフトウェア開発の22の思考ツールを解説します。この思考ツールは、XPでいうプラクティスに似た立ち位置のものです。これらのツールは7つの原則に分類できます。
- 1. ムダをなくす
- ムダを認識する
- バリューストリームマッピング
- 価値の流れを図解し、流れる時間を計測して流れを短縮していく
- 2. 品質を作り込む
- 認知統一性
- 統一性を作り込む
- コンセプト統一性
- 統一性を作り込む
- リファクタリング
- テスティング
- 認知統一性
- 3. 知識を作り出す
- フィードバック
- イテレーション
- 同期
- 集合ベース開発
- チーム開発
- 4. 決定を遅らせる
- オプション思考
- 最終責任時点
- 意思決定
- 5. 速く提供する
- プルシステム
- かんばんの考え方
- 待ち行列理論
- リーンとは別の理論
- 遅れのコスト
- プルシステム
- 6. 人を尊重する
- 自発的決定
- モチベーション
- リーダーシップ
- 専門知識
- 7. 全体を最適化する
- 計測
- 契約
より詳細を知りたい場合は、書籍『リーンソフトウエア開発 アジャイル開発を実践する22の方法』をご確認ください。
連載一覧
第1回:アジャイル開発の過去、現在、未来を知ろう!
第2回:声に出して読みたいアジャイルマニフェスト
第3回:従来型開発とアジャイル開発の違い その1
第4回:従来型開発とアジャイル開発の違い その2
第5回:アジャイル開発のよくある誤解を解いていこう!
第6回:世界中で大人気の秘密に迫る!スクラムを使ったソフトウェア開発
第7回:わかるようでわかりにくいスクラムチームの責任
第8回:スクラムイベントの実践方法
第9回:エクストリーム・プログラミングとその価値
第10回:エクストリーム・プログラミングの原則と基礎プラクティス
第11回:エクストリーム・プログラミングの応用プラクティス
第12回:リーンソフトウェア開発
第13回:ソフトウェア開発における「かんばん」
第14回:さまざまな方法論 − リーンスタートアップ・DevOps