ソフトウェア開発におけるムダとは何か – 読書 – リーン開発の本質

お仕事でのチームで課題図書になっていたので読んでみました。チームのプロセスを改善するためのヒントがたくさんつまった良書です。

リーン開発の本質
リーン開発の本質

本書は、「アジャイル」と「トヨタ生産方式」が融合した形ともいえる「リーン開発」について説明している本です。以下、あとがきから引用。

ソフトウエア開発の現場を活性化し、反復によってフィードバックを得ながら人とチームの学習を促進する「アジャイル」の考え方と、顧客価値の流れを重視し、ムダをそぎ落とした改善指向の「リーン」の考え方が、Mary Poppendieck と Tom Poppendieckによって出会い、本書「リーン開発」が生まれた。

本書では、コンセプトを無駄なく価値に変換(開発)して顧客に素早く届けるための「リーン開発の7つの原則」の概念や詳細が、具体的かつ豊富な事例とともにわかりやすく解説されています。

原則1:ムダをなくす
原則2:品質を作りこむ
原則3:知識を作り出す
原則4:決定を遅らせる
原則5:速く提供する
原則6:人を尊重する
原則7:全体を最適化する

本書の「あとがき」で内容について非常にわかりやすくまとめられています。「本を買う前にまず大枠を知りたい」という方は、以下の記事であとがき全文を読むことができるので、ぜひ見てみてください。

『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。:An Agile Way:ITmedia オルタナティブ・ブログ

では、自分が本書を読んでみて、勉強になったことを幾つかピックアップして紹介したいと思います。

ソフトウェア開発における「ムダ」

アジャイル開発における重要なポイントのひとつに「反復によるフィードバックに基づいたチームの学習」があります。チームの活動やプロセスを定期的に振り返り、次のプロセスをより良いものにしていくことで、プロダクトが顧客に届ける価値を最大化しようと試みます。

自分が開発者として所属しているスクラムチームでも、スプリントの最後に振り返り(スプリントレトロスペクティブ)を実施し、継続的なチームのプロセス改善に取り組んでいます。「KPT」によって、そのスプリントで発生したProblem(問題)を洗い出し、それに対するTryをチーム内で議論し、次のスプリントのプロセス改善に活かします。

一見簡単そうに聞こえる取り組みなのですが、効果的な振り返りをするためにすごく大事なポイントがあり、ちょっとやり方を間違えると、せっかくの振り返りが効果的でないものになってしまいます。

その大事なポイントというのは、「メンバー間でProblemの定義を揃えること」です。このチームにおけるProblemとは何なのか、メンバー間で定義を揃えておかないと、各々が思い思いのProblemを出し始め、議論が分散し、プロセスを改善する効果的なTryを打ち出せなくなります。

本書で紹介されている「ソフトウェア開発におけるムダ」の概念は、上記問題を改善するために非常に有用です。

本書では、チームが行うすべて活動の中で、顧客に価値を届けることに貢献していないものすべてを「ムダ」と定義し、かつそれらを「7つのムダ」に分類しています。

未完成な作業のムダ
余分な機能のムダ
再学習のムダ
引き継ぎのムダ
タスク切り替えのムダ
遅れのムダ
欠陥のムダ

これらのムダの定義についてメンバー全員が把握しておくことで、Problemの定義(=ムダ)やTryの定義(=ムダを削ぎ落とすための打ち手)がはっきりします。結果として、チームが抱えているムダを発見しやすくなり、顧客に価値を届けるという目的において、効果的にチームの活動を改善できるようになります。

ムダの各分類はそれほど難しいものではありません。また、振り返りの実施前に少し各メンバーが意識するだけでもかなり結果が変わってくると思うので、チームへの導入は比較的スムーズに行えるのではないかと思います。

まだ「ムダ」についてしっかり意識したことがないチームはぜひやってみてください。また、意識し始めたチームも、

  • 自分たちのチームにおける「ムダ」とはどういったものか
  • 今チームでは、どの種類のムダがボトルネックになっているのか

などについてメンバー間で話し合ってみると、より共通理解が深まって、効果的な振り返りが行えるようになるかと思います。

バリューストリームマップによる開発プロセスの可視化

本書では「バリューストリームマップ」というツールがいろんな箇所に登場します。製品に関するアイデアが生まれてから、開発を経て、価値として顧客のもとに届くまでのプロセスを時系列にならべ、各工程と工程間にかかる平均的な時間を図示したものがバリューストリームマップです。

バリューストリームマップによって、アイデアが顧客にとっての価値に変わるまでに、どのような工程が存在し、それぞれにどのくらい時間がかかっているのかが一目瞭然になります。

リーンソフトウェア開発の「原則5:速く開発する」を実現する上で、バリューストリームマップは有用です。例えば、工程と工程の間にかかる時間は「ムダ」そのものなので、時間がかかっている原因を分析、解消することで、ムダが軽減し、顧客に素早く価値を届けられるようになります。

また、局所最適化の問題を起こさないためにもバリューストリームマップは役立ちます。

プロセス全体のスループットは、ボトルネックになっている工程のスループットに依存します。そのため、ボトルネックになって「いない」工程を最適化したとしても、プロセス全体の改善にはつながりません。顧客に届く価値には何ら影響を与えないので、その改善活動自体がムダになってしまいます。

バリューストリームマップによって、プロセス全体の中で「今どこがボトルネックになっているのか」が可視化されます。常にプロセス全体を意識しながら、ムダを発見できるため、局所最適化の問題も起きにくくなるはずです。

自分が今所属しているチームでも、一度、バリューストリームマップを作成することで、チームの開発プロセス全体を振り返りたいと思いました。作成していく中で、「あれ、こんなところに時間がかかってたんだ」という新しい気付きも得られそうですね。

品質を作りこむ

リーンソフトウェア開発の原則に「原則2:品質を作りこむ」という項目があります。本書では、品質を作りこむために以下の2つの方針をチームで採用することを推奨しています。

  • 欠陥を未然に防ぐためのテストを実施する
  • 欠陥が発生したら工程をすべて止めてすぐに直してしまう

欠陥が顧客に価値を届けることはありません。ただ開発者が作業をして作りこんだことにはかわらないので、欠陥は「未完成な作業(=在庫)」のひとつに分類できます。

リーン開発において、未完成な作業はムダです。なので、できるだけすみやかに欠陥は解消する必要があります。上述の2つの方針は、欠陥の早期解消に非常に有用な考え方です。

テストには「欠陥を発見するためのもの」と「欠陥を未然に防ぐためのもの」の2種類が存在しています。テストの役割を「欠陥を発見するためのもの」と置いている場合と、「欠陥を未然に防ぐためのもの」と置いている場合を比較して、欠陥が「未完成な作業」の状態で放置されている時間がどちらの方が長いかというと、明らかに前者です。そのため、テストは欠陥を未然に防ぐためのものと定義し、欠陥が未完成な作業として存在している時間を最小化するように心がけるべきです。

欠陥を未然に防ぐためのテストを実現するプラクティスとしては、例えばTDDやCI(継続的インテグレーション)があります。そういったプラクティスを実践し、発見した欠陥をすぐ直すことで、高い品質を継続的に作りこむことができます。

欠陥を発見するためのテストだけでも、同じレベルの品質を作りこむことは不可能ではありません。ただ、非常に大きな工数がかかってしまうはずです。

今までの経験から、欠陥は放っておく時間が長くなれば長くなるほど、影響範囲が大きくなり、直すために必要な時間も長くなる傾向があると思います。テストの工数が長くなれば、それはバリューストリームマップに顕著に表れます。そして、顧客に価値を届けることを妨げるムダとして扱われます。

なので、やはりテストは「欠陥を未然に防ぐためのもの」であるべきです。

今自分が所属しているチームでも、テストの方法や考え方に関して、まだまだ改善の余地があると思いました。メンバー間でもう一度、このチームにおけるテストの目的と方法について話し合い、意識をあわせることからやってみるとよいかもしれませんね。

おわりに

ソフトウェア開発を、アイデアを価値に変え、顧客に届けるためのプロセスの一部分としてとらえた上で、そのプロセス全体を最適化するための方法について俯瞰的に解説しているのが、本書の良い所です。

自分には経験ないけど、きっとアジャイル開発を導入しようとしている組織のマネージャー層や経営層に対して、

  • アジャイル開発を導入すると組織にどのようなことが起きるか
  • アジャイル開発を導入しただけではダメで、プロセスや組織自体も変えていかないと顧客への価値最大化は実現できないこと

などを説明するのに非常に役立つ本ではないかと感じています。具体的な事例がたくさん掲載されているのも理解を促してくれますね。

個人的には、事前知識不足が影響して(契約など)少々読みづらいところもありましたが、上述したところをはじめ、開発チームやそれらをとりまく組織のプロセスについて考えるきっかけとなる、よいきっかけとなりました。「リーン開発」系の書籍は他にもあるみたいなので、他の本も近々読んでみようと思います。

それでは以上です。ありがとうございました。