第12回 リーンソフトウェア開発

原則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回：従来型開発とアジャイル開発の違い　その１
第4回：従来型開発とアジャイル開発の違い　その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps