スクラムを実践していても「リーン思考」をあまり意識できていない気がした

「リーン思考」はスクラムの理論の一つ

スクラムを実践するにあたり、理論の一つである「経験主義」の3本柱(透明性・検査・適応)はスクラムガイドの中でも多く触れられているため、意識して実践できていると思います。
しかし、もう一つスクラムの理論の中で触れられている「リーン思考」については、スクラムガイドでも「スクラムの理論」の章でしか触れられておらず、スクラム実践の中でどのようにリーン思考を実現するかは記載されていません。
だからというわけではありませんが、私自身が経験主義の3本柱をチームに意識させるべくメッセージを伝え続けていますが、リーン思考については特に何もアクションを起こしてきてないことにふと気づきました。

スクラムの中でどんな「ムダ」をどんな時に無くしていけるだろうか

そもそも、自分自身誰かに教えられるほどリーン思考について深く理解できていない気がしますが、私の中でのリーン思考について、「価値提供の流れの中で発生する「ムダ」を無くしていくこと」と捉えています。
その上でスクラムの中でどんな「ムダ」をどんな時に無くしていけそうか考えてみま

造りすぎのムダ

プロダクト開発における「造りすぎのムダ」はやはり「使われない機能」を生み出すことだと思います。
スクラムでこれを避けるにはプロダクトバックログがMVP(Minimum Viable Product)の実現に向けたものになっているか定期的に確認をして手入れをする作業、すなわちリファインメントがカギになってくると思います。
検討段階ではあれもこれもあるべきではないかとどうしても考えがちですが、チーム全体が価値実現に向けてどうしたらシンプルに開発を最小限に実現できるか考え続ける必要があると思います。

手待ちのムダ

「手待ちのムダ」については、タスクを細分化することでそのムダの発生を極力抑えるように取り組めている場合が多い気がします。
それでも発生することのある「手待ちのムダ」で言うと、特にスプリント終盤にタスク数が少なくなってきた時に「次取れるタスクがありません」という開発者が出てくることな気がします。
スプリントのどのタイミングでも関わらず、次のタスクに取り掛かる前に他の開発者が担当しているタスクについて何かサポートできることは無いか確認する文化を作ることでこのムダは減らしていけると思います。

運搬のムダ

タスクの引き渡しを一つの「運搬のムダ」と捉えた場合、実装者とレビュー担当で引き渡しをするのはムダと言えるのかもしれません。その場合だとペアプログラミングを実施して、実装とレビューを兼ねる等が考えられますが、実装者とレビュー担当を分けることを「ムダ」とするチームはあまりないと思います。
個人的にはこの問題はリリースに向けてスクラムチームからチームの外にプロダクトが出た時に発生する気がします。例えば、スプリントレビューの場にいなかったチーム外関係者からプロダクトに関する問合せが発生し、その対応に追われる等です。
この場合の「ムダ」削減の方法はいくつか考えられ、スプリントレビューに必要で適切なステークホルダーを招待する、チーム外にプロダクトを渡す際に必要なドキュメント(あるいはそれに相当する伝達手段)を用意する等です。いずれにせよ、プロダクトがリリースされるまでにどのような社内ステップを踏むのかを事前に認識しておくことでスクラムチームとしての振る舞い方が変わってくるので、そのあたりの把握をスクラムマスターは率先して取り組むべきかもしれません。

加工のムダ

インクリメントを生み出すにあたって、得たフィードバックを元に加工すること自体は一概に「ムダ」とは定義できないと思います。
しかし、価値の提供や検証につながらない加工は間違いなく「ムダ」と呼べます。
それを避けるためにもそのPBIをこなすことによって、どんな価値の提供・検証に結び付けようとしているのか定義できているかを定期的に確認するのが必要だと思います。
プロダクトバックログにあるすべてのアイテムについて、価値の結びつきができていると、各スプリントでスプリントゴールを立てる際にも大きく役に立つのではないでしょうか？優先度の高いアイテムに紐づく価値が明確であるため、その価値提供・検証に関するスプリントゴールを立てやすくなるでしょう。

在庫のムダ

スクラムにおける「在庫のムダ」はスプリント期間中にインクリメントを生み出すにあたり、完成の定義を満たせないままスプリントを終えてしまうことでしょう。
完成の定義を満たせないものはインクリメントと呼ぶことができず、スプリントレビューに持ち込むことができません。すなわちフィードバックを受ける機会を得ることができません。
インクリメントを確実に生み出すために、チーム全員でスプリントバックログの優先度の高いアイテムから取り組んでいくことが重要です。たまにアイテムごとに担当者をアサインし、完了したアイテムと未完了のアイテムが混在することで結果としてインクリメントが生み出せなかった(あるいは想定よりもインクリメントが小さかった)ということがあります。
やはりこのような「ムダ」を減らすためにもチームでインクリメントを生みだしていく文化を創ることが非常に大事になってきます。

動作のムダ

スクラムチームで起きる「動作のムダ」としてはタスクの切替があげられるかと思います。タスクの切替にはスイッチコストが掛かります。このコストは間違いなく削減していける「ムダ」です。
これは個人レベルでもチームレベルでも起こる「ムダ」だと思います。チームとしてこの「ムダ」を減らすためにどのようにタスクに取り組んでいくのか、チームで検討して実践していくのが大事になってきます。これを避けるのによく利用されるのが「WIP制限」になると思います。

不良を作るムダ

「不良を作るムダ」と聞いて思い浮かぶのはバグやエラーの多いプロダクトをリリースしてしまうことです。品質を担保するために完成の定義を満たしたインクリメントを生み出し続けることが当然求められるのですが、それと同時にそもそも完成の定義がリリース品質を満たしているものなのかを検査するのも必要かもしれません。
完成の定義自体も一度決めたら変えていけないのではなく、実情に合わせて変更していくべきです。また、あまり無いかもしれませんが、完成の定義には不必要だったものも出てくる可能性もあるのでその観点で確認をしてみるのも大事かと思います。(それも一つの「ムダ」取り)

最後に

今回の「ムダ」の定義はリーン生産方式に則り考えてみました。こうして列挙してみるとリーンを意識せずとも普段から実施できている「ムダ」削減もあることが分かりました。
逆に意識することでよりチームとしてプロダクトやインクリメントを生み出すにあたっての生産性が上がるのは間違いありません。
今回書いた「ムダ」に限らずチームによって様々な「ムダ」が発生していると思いますので、「リーン思考」も意識してチームに「ムダ」が無いか検査と適応していくことが更なるスクラム成功のカギになると思いました。