リーンとはムダのない、を意味する言葉ですが、今回は特にその「ムダ」について考えてみたいと思います。リーンソフトウェアの中で、7つのムダが定義されています。
- 未完成の作業のムダ
- 余分な機能のムダ
- 再学習のムダ
- 引き継ぎのムダ
- タスク切り替えのムダ
- 遅れのムダ
- 欠陥のムダ
になります。個々の項目について簡単に説明をしていきます。
未完成の作業のムダ
未完成とは、システム開発における
仕様決定 → コーディング → 統合 → テスト → ドキュメント化（必要に応じて）→ 導入
までの途中に存在する仕掛品を意味します。例えば、
- コーディング前の作業
- 仕様だけ決定し、コーディングが行われていないドキュメント。これは保存期間が長ければ長いほど、変更が発生する可能性が高くなっていきます。要求の変更はビジネスや市場の変化に応じて必ず発生するものであり、それがコーディングされていないのであれば要求を定義するのが早すぎたということになります。
- 同期されていないコード
- リポジトリへのコミット作業はマージが付き物であり、コミットしない時間が伸びれば伸びるほどマージ作業時間も長くなります。できるだけ早めにコミットしていくべきです。
- テストされていないコード
- テストされていないコードはバグをはらんでいる可能性があり、それをそのまま利用していると連鎖的に問題が起こる可能性が高まります。テストはできるだけ早期に、継続的に行うべきです。
- ドキュメントのないコード
- ドキュメントを後でまとめて書く場合もありますが、結局の所ヘルプレベルの文書がなければ顧客や関係者のテストは難しくなります。できるだけコードと一緒に提出できるべきです。
- 導入されていないコード
- 導入されていないコードがたまると変化を一気に起こすことになります。できるだけ小出しに導入し、変化の波を低く抑えるのが理想です。
といった類のものです。
余分な機能のムダ
余分な機能は使われることもなく、品質管理上のムダにもなり、そもそも邪魔なものになりかねない。顧客の80%のニーズは20%の機能で満たされるとさえ言われているので、できるだけ少ない機能で顧客のニーズを満たすことが重要です。顧客にとっての本来のニーズは要望が満たされることであり、混乱することでも、ただ多機能なことでもないのです。
再学習のムダ
再学習とは、既に経験していることを再度繰り返してしまうことになります。それは個人レベルであっても、組織レベルであっても同様です。そのようなナレッジを蓄積し、同じ問題に対して効率的に取り組めるようにする必要があります。
引き継ぎのムダ
開発チームから運用チームや、担当者から別な担当者に引き継ぎを行った場合、相当数の暗黙知が取りこぼされる。また、その引き継ぎにかかるコストも相当になる。なるだけ引き継ぎが発生しないような体制を作り上げることや、常に少数のグループ単位で取り組むことで数名でフォローし合える体制にするといった工夫が必要です。
タスク切り替えのムダ
複数のプロジェクトに参加したり、やるべきことを複数持ち、それを同時にこなすのは無理があります。マルチタスクにこなす人もいますが、実際には作業レベルは別な方が行っている場合が殆どです。実務を伴うマルチタスクは非常に困難であり、開発作業者はできるだけ集中して一つのタスクを行っていく必要があります。
過去のプロジェクトの保守作業がある場合は、複数人でチームを組み、週間の交代制で保守を全て引き受けるようにしたり、毎日の決められた時間（午前中の2時間など）を保守作業の時間と決めてしまうといった集中型への切り替えが重要です。
遅れのムダ
意思決定や問題解決に際して、遠隔地にいる人に対して都度問い合わせていたりすると時間が余計にかかってしまう。開発者、プロジェクトマネージャ、顧客とリスクテイカーができるだけ一同に集まって素早く決定を下せるようにすべきです。少なくとも全員に配信されるメーリングリストなどを介して、素早く情報共有と決定がなされる体制を作っていく必要があります。また、そのためにはお互いに権限委譲を推進し、責任者を明確にする必要があります。
欠陥のムダ
欠陥を作り込まないようにするには、テストが最重要です。自動的にテストを行う仕組みを早期に導入し、継続的にテストを行うことで欠陥の入り込む余地を減らしていきます。アジャイル開発ではテストしやすいコードを書くことが原則になっています。
テストを自動化するメリットとして、リファクタリングが容易であるということがあります。インタフェースが決まっているのであれば、中身を分かりやすく、使いやすく作り直しても動作が保証されます。それによってコードの変更が怖くなくなり、より良い設計に基づいたコーディングが可能になります。
まとめ
トヨタのカンバン方式などに代表されるムダの排除は「顧客が注文を出し、現金を改修するまでの時間軸において価値を付与すると思われないものは全て排除する」という考えに基づいています。そこには社内の体制や考え方、全体最適化など多岐にわたって考えていく必要があると書かれています。各自が自己や自社、部署の満足感のために行動するのではなく、顧客へ価値を提供するという一点に対して何をすべきなのか、その原点に立ち戻って考えると色々なムダが見えてくるかも知れません。