チームの生産性をアップ！プロダクト開発に起きがちな「７つのムダ」を防ぐ方法とは？

前回の「プロダクトのムダを排除するには」では、プロダクト開発におけるムダとそれを排除するための開発プロセス改善の重要性についてお話しし、中でも特に効果的なリーン開発について紹介しました。

では、ユーザーが求めるものを作れるようになれば、もうムダはないのでしょうか。

残念ながら、それは違います。プロダクト全体の話に限らず、実は細かなタスクやプロセス上にもいくつものムダが潜んでいます。
では、プロダクト開発プロセスにおけるムダとはなんでしょうか？

それは、ユーザーにとって価値を生み出さないすべての活動です。
実際にプロダクト開発プロセスにおけるムダと言われているものを挙げてみます。

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

これらのムダが開発スピードへ影響し、ユーザーに価値を提供する時間を伸ばす原因になります。

例えば、丸一日ミーティングで埋まってしまったような日には、「今日は何をやったっけ？」と実際には仕事をしていないように思ったりしませんか？あなたが費やした時間がユーザーへの価値提供と直接繋がらなければ、ムダが多い日に感じることでしょう。

今日はこれらの７つのムダの内容や問題点、そうならないための対策についてひとつずつご紹介していきたいと思います。

1.余計な機能（リーン生産方式における作り過ぎのムダ）

みなさんも経験したことがあると思います。ステークホルダーの誰かがどこかで目にした「カッコイイ機能」を追加したいと主張すること。たとえば、経営者が巷で流行しているツールの機能にすっかり惚れ込んで、自社プロダクトにもぜひその機能を搭載してほしいと口を挟んできたり、デザイナーやエンジニアが自身のスキルを試す感覚で最新の機能や技術を追加しようとしたりするイメージです。

ご存知の方も多いと思うのですが、経済学において「パレートの法則」という言葉があります。結果の80％は20％の原因から生まれるという意味ですが、ソフトウェアの利用についても類似の傾向があり、80%のユーザーは、プロダクトの20%の機能しか使っていないと言われています。

2002年のスタンディッシュグループの研究では、（常に）使われる機能は20%で、時々使う機能が16%、稀に使われる機能が19%で、実に全体の機能の45％は使用されていないことが明らかになっています。

豊富な機能を搭載しても、本当に使われるコアな機能は全体の20%にすぎない。そうだとすると、やたらと機能を追加することは問題ですね。管理コストは膨らみ、開発スピードが落ちます。プロダクトが複雑化することでエラーが発生する危険性も高くなります。そしてなにより、ユーザーにとって価値のない、余計な機能を追加することでプロダクト全体の価値が薄まってしまいます。

これを防ぐためには、常にユーザーの視点を保つことが重要です。社内のステークホルダーの希望に逐一振り回されてはいけません。

具体的な対策としては、以下が挙げられます。

• いま作っているプロダクトが本当にユーザーにとって価値があるものかどうか、常に疑う
• ユーザーにとって価値があるかをテストしたり、ユーザーの反応を客観的に判断可能な仕組みを作る。（例えば、こまめにA/Bテストを実施したり、プロトタイプを用いた実験によるフィードバックサイクルを回すなど）
• 自分（他のステークホルダー）のアイディアは正しいと思い込まない

2. 引き渡し（リーン生産方式における運搬のムダ）

引き渡しは、ウォーターフォール型の開発プロセスでよく見られる課題です。タスクごとに担当者が異なるため、人から人へタスクを渡していきます。例えば、アナリストからデザイナーへ、デザイナーからエンジニアへ、エンジニアからテスターへ･･･という具合です。
ここでの問題は、「引き渡しを繰り返すうちに内容が変わってしまう」点です。いわば伝言ゲーム状態。
引き渡しの回数が増えるに従い、正確な知識を引き継げないことが明らかになっています。勘違いや情報の漏れはアウトプットの質の低下や全体の工程のスピードにも影響を及ぼします。

これを防ぐ方法は以下の通りです。

• バラバラのチームをまとめる工夫をしたり、クロスファンクショナルチーム（いわゆる横断的なチーム）を作ることで引き渡しの数を減らす
• できるだけ小さい機能の開発や改善から始め、小まめにテストすることにより、フィードバックサイクルを短くする
• コミュニケーション方法をより正確性を保てるものに改善する。具体的にはドキュメンテーションでの引き渡しではなく、プロトタイプを用いてプロダクトのコンセプトや形状についての認識を共有する

3. 習得の繰り返し（再習得）（リーン生産方式における加工そのもののムダ）

先ほどの「引き渡し」と近いですが、習得を繰り返さないといけないのもみなさんが経験したことのあるムダでしょう。
よくある話として、ナレッジ継承の問題が挙げられます。プロジェクトの重要人物が退職すると、その人が持っていた知識や背景への理解が失われてしまいます。そうなると、新たにアサインされたメンバーが過去の情報を追い、勉強しなおす必要があります。
また実は、とある分野のスペシャリストが社内にいるのに、そうと知らずに現メンバーで解決しようと勉強していた、という話も似たような状況と言えるでしょう。

なぜこんなことが起きるかというと、原因は二つです。

• 社内にある知識がきちんと管理されていないこと
• プロセスが十分整備されておらず、細かいタスクまで明確化していないこと

これによる問題は、プロジェクトの進行スピードが落ちることです。さらに、ナレッジやメンバーのスキルに関する情報が共有できていないことで、単に時間を費やすばかりか、問題発生時にすばやく反応することができない可能性もあります。そのようなバタバタした状況で開発が行われていくため、プロダクト品質への影響も否めません。

こうしたムダを防ぐ方法は、以下の通りです。

• チームで問題を解決することを意識する。
• 縦割りの意識から離れ、横断的なチームを作って、常にコミュニケーションを深めることで、互いの専門性をいかしたコラボレーションを生み出す
• 常に「改善」を意識する。
• 改善することを習慣化し、文化として組織に定着させる

4. 欠陥（リーン生産方式における不良をつくるムダ）

欠陥のムダ、つまり欠陥品を作るムダはイメージしやすいのではないでしょうか。

例えば、エンジニアにプロダクトの開発を託したら、全く想像と異なるプロダクトが完成してしまった、あるいは、テストを十分に行わないままリリースしてみたらエラーやバグだらけで、とても販売できる状態ではなかった、という話がこれに該当します。

ここでの問題は、バグの存在そのものというより、「エンジニアにきちんとビジョンやユーザーが求めている価値とは何か」ということが伝わっていないということです。プロダクトのコンセプトや明確な判断軸がわからないと確認や修正に時間がかかってしまいます。目指すイメージが曖昧なことで、担当者の間にもストレスがかかり、フラストレーションもたまってしまいます。

これを防ぐ方法は以下の通りです。

• プロセスの最初からエンジニアも含めたすべての関係者を巻き込む
• 情報伝達や認識共有の際は、立派なドキュメンテーションに頼らず、こまめにワイヤーフレームやプロトタイプを作ってプロダクトのコンセプトや形状をより分かりやすく伝えることを意識する

5. 未完成のもの（リーン生産方式における在庫のムダ）

リーン生産方式では在庫のムダも徹底的に排除すべきことの一つです。在庫があると場所が必要になる上、探したり移動する時間もかかるのでコストがかかります。そして、プロセス上の非効率を隠す要因ともなります。

こうした在庫のムダは、リーン開発において未完成のムダと置き換えられます。例えば、以下のようなものです。

• 開発されたけれど、ユーザーにまだテストしてもらっていない機能（価値がまだ確認できていないもの）
• 作りかけの機能を途中で他のアイディアや機能に差し替えたもの
• 最初にアイディアを実現（開発）する難しさを把握せずに進めてきたものの、やはり完成できない、あるいは困難であるということを途中で発見してプロセスが止まってしまったもの

ここでの問題は、「情熱やリソースをかけて作業を進めても完成前に廃れてしまう」ということです。実際にユーザーによるテストを経なければ、ビジネスやユーザーに価値を生み出せるか判断をすることはできません。ユーザーが必要とするものを作っているかどうかがわからないままです。

また、見切り発車で進めたものの、途中で機能が変わったり実現が困難だという判断が下されると、他の仕事に影響を与えるのも問題です。少なくとも後工程には直接的な影響が出ますし、思うように進められなかった罪悪感を抱えてしまう人もいるかもしれませんね･･･

これを防ぐための対策は以下の通りです。

• アイディア（機能など）を実現する前に、複雑さや必要なリソースをしっかり把握する
• 開発中の機能の条件などを変えない
• 備える各機能の役割や相関関係を明確にする
• これらの対策をとれるよう、部門横断的なチームを作る。
• 個々の持つ専門スキルで互いを補い、改善の企画や必要な機能の見積もりを最適なものに近づける。クロスファンクンションチームが必要（お互いに助けになる、企画に必要なものを見積ることができるため）

6. タスク切り替え（リーン生産方式における動作のムダ）

一般的に職務上求められる能力の一つに、同時平行で複数のタスクを管理できることが挙げられるのではないでしょうか。たしかに、その力が必要な場面を想像するのは容易ですね。しかし、本当は同時に複数のタスクを進めるのは良いことと言えません。本質的には、効率良く働き品質の高い結果を出すためには、仕事のフローが滞ることなく集中力を最大限担保できることこそ必要不可欠なのです。

しかるべきフローが邪魔されると、品質やスピードへの影響が必ず出ます。リーン開発でも、複数のタスクを兼任することによる作業効率と品質の低下は、ムダを生み出すと考えられています。

これを防ぐ方法は以下の通りです。

• 多数のプロジェクトを管理しないといけない場合でも、一つずつ完遂する
• お客様のリクエストなど、チームが邪魔されることがよくある場合、その対応を分担する（一週間目はAさん、二週間目はBさん、・・・）
• 重要ではないタスクは削る
• 与えられたタスクとスキルの不一致が起きないよう、必要な知識を担当者がもっていることを確認する。事前に知識を提供するか、持っている人に委ねる

7. 遅れ（リーン生産方式における手待ちのムダ）

リーン生産方式における手待ちのムダとは、業務のなかで次の仕事に進めず一時的に何もやることがない状態のことを指します。自分が使う資料の作成を他の人に頼んだために、出来上がりまで次の作業に進めず手持ち無沙汰・・・多くの人がこのような経験をしたことがあると思います。

リーン開発ではこれを「遅れ」のムダとしています。

例えば企画はあるのに採用が予定より遅れてしまいプロジェクトがスタートできないという例や、責任者が多忙すぎてなかなか捕まらず、開発を進めるための確認・許可待ちが都度発生するという状態を想像していただけるとわかりやすいでしょう。

遅れのムダは非常に危険な問題です。
もし他のムダを排除できていたとしても、遅れの発生はお客様に価値を生み出すまでの余計な時間に直結するからです。開発する側の遅れを市場やユーザーは待ってはくれません。ユーザーに届ける適切なタイミングを逃すことで、競争優位性など実際の価値への悪影響がでることもあります。また、フィードバックサイクルが長くなることでタスク切替えに影響が出たり、未完成なものを作り出す可能性が出るなど、他のムダを誘発しかねないという点も怖い問題です。

これを防ぐ方法は以下の通りです。

• 「完全な」チームを作る。具体的には、チームメンバーが持つ知識が十分で、プロジェクト進行のために必要な権限がチームに委ねられており、責任の所在が明確になっていること。
• フィードバックを振り返ることを習慣化し、そのための時間枠を設ける
• フィードバックの内容に妥協しない。決定すべきことの見落としや意識合わせの漏れがないかを考えながら、フィードバックを求める。

おわりに

今日は、プロダクト開発に潜むムダのうち、細かな機能やプロセス上のタスクに潜む7つのムダに焦点を当ててお話してきました。
皆さんはいかがでしょうか？ムダなくプロダクトを開発できていますか？

全くムダなく開発ができているチームはなかなかないと思います。しかし、今回紹介したのは小さなムダですが、どれもプロダクトの品質や開発スピードに影響を及ぼし、事業の成否を決定づける重要な問題になりがちなので、小さいムダでもできるだけ減らしましょう！。

それぞれのムダを防ぐために何をすべきか、対策についてもご紹介しました。「複雑そう！」と皆さんは今思っているかもしれませんが、よく見るとほとんど似たようなことの連続です！「横断的なチームを作って関係者をまとめること」や「プロトタイピングを活用し、コンセプトやユーザーへのフォーカスを維持しながら短いスパンでフィードバックサイクルをまわすこと」など、こうした対策を徹底していくことが、大小すべてのムダの解消につながるのです。

前回の記事とあわせてご覧いただき、チームでムダのないプロダクト開発を目指しましょう！