「バージョン3の法則」～イノベーション早期実現のための思考法
デジタルトランスフォーメーションやイノベーションを推進して組織の差別化要素を実装するにあたっては、スピードが不可欠です。一方、既に確固としたビジネスや仕事の流儀が確立した組織では、このスピードが保てない場合が多く発生します。読者の皆様がそのような組織に所属していて、そのような場面に遭遇した場合に、どのように対応すればよいか考えてみることにしました。
最初の成果がリリースできないという罠
何か新しいことをやろうとしたときに、ビジネスや仕事の流儀が確立した組織でよく見る現象として挙げられるのが、過去に似たような実施例があるかどうか、ということです。過去の事例があるものは、同じ方法論を辿ることで関係者を比較的説得しやすいのですが、その一方、事例が存在しない場合は、先に進めるという判断を誰もしないというケースが多くなります。
このような場合は、現場で考えたデジタルトランスフォーメーションやイノベーションの推進プロジェクトが進まなくなり、誰もボールを拾わずタライ回しに合う、最終的に頓挫する、棚上げになる、となってしまいます。
特に見受けられるパターンは「出す予定の成果が経営陣、もしくは社内外の顧客が期待した通りの内容/モノなのか」「下手にリリースすると評判を落とすのではないか」ということを判断できずに止まるケースです。私もいままでこのパターンを何度となく見てきました。しかし、このような理由でプロジェクトが止まってしまうのは何とも忍びないもので、どうにかして避けたいところです。
最初から完璧な成果なんて存在しない
ところで、IT業界 (外資系) では「バージョン3の法則」というものがあることをご存知でしょうか？これはソフトウェアのリリース等に代表される「IT関連の商品はバージョン3くらいまで来ると実用的なレベルで使えるようになる」というジンクスです。
たとえば、過去にマイクロソフトがリリースした製品でいうと、Windowsはバージョン3になってやっとブレイクしました。前身であるMS-DOSも日本ではバージョン3になって広まりました。
Microsoft Officeも4.xがWindows 3.1で利用可能な最初のリリースにあたります。そこから数えて3つ目のMicrosoft Office 97で機能とシェアが大きく伸びました。メールサーバーのExchange Serverもバージョン4が外販製品のバージョン1なので、3つ目のリリースにあたる1998年のExchange Server 5.5あたりから勢いが付いてきました。
以下で紹介するのは2004年に書かれたWindows Small Business Server (SBS) 2003 の記事ですが、この時期には既に「バージョン3の法則」は定着したジンクスとなっていました。私もちょうどこの頃はマイクロソフトで、まだ世に出ていない新製品のソフトウェアの開発業務を行っていました。
また、ドイツのSAP AGがリリースしているERP製品も、メインストリームとなったのは1992年のSAP R/3であり、SAPはその後10年以上にわたり市場を席巻しています。
2000年代を見てみると、アップルもiPhoneを出したときに3つ目のリリースであるiPhone 3GSで機能が大きく強化され、3年という比較的長い期間にわたり市場に現役機種として存在した最初のバージョンでした。
これら以外にも、IT業界の商品がバージョン3で実用的なレベルに達したという例は多数あり、枚挙にいとまがありません。
＊
このように当時から先進的でイノベーションを提供してきた外資系のIT業界では、バージョン3までに実用的なモノを提供するようにプロジェクトが進んでいました。これが意図してこうなっていたのか結果論なのかは中々難しいところですが、当時「中の人」であった私の感触から言うと、意図したプロジェクト管理が半分、結果論が半分なのではないかと思います。
最初のバージョンを作成するときには、市場のニーズや反応に対して様々な仮説を立てます。ベータテストも行うものの、製品が不完全であったり実際にお金を払って買ってくれている顧客がいないために、本格的なフィードバックを得るのはなかなか難しいのです。
また、大抵のプロジェクトは最初のリリースまでにあれもこれもやりたくなり、To Doリストが膨れ上がります。そうするとリリースを無駄に先延ばしにするよりは、優先度を付けて実用最小限の製品（Minimum Viable Product、MVP）に機能を絞ってまずはリリースしてしまうのが得策という判断が下されます。その代わり、バージョン2、3の機能のロードマップを予め決めておきます。これが「バージョン3の法則」を裏付ける「プロジェクト管理」による要素です。
一方、バージョン1の製品を出すと、市場からの本格的な反応が帰ってき始めます。機能を削ったために予め分かっていた内容もあれば、新たな発見もあります。これらを次のバージョンに入れ込んでいくわけですが、バージョン2は大抵バージョン1をリリースした直後にプロジェクトが始まっているため、本格的なフィードバックが返ってくる頃には既にバージョン2の製品仕様の大半が決定されており、バージョン2にすべてを入れ込むことはできなくなります。
そのため顧客のフィードバックを完全に反映するには結果としてバージョン3まで待つ必要があります。バージョン3までのリリース間隔を狭めることで実用的な製品を早めに市場に投入するようにすることができます。これが「バージョン3の法則」を裏付ける「結果論」による要素です。
＊
一方、ビジネスや仕事の流儀が確立した組織では、最初から完璧な商品をリリースしようとしてしまいます。しかし、新製品を出すときの前述の状況を考えると、最初から完璧を目指すということは不可能であることがわかります。世の中で成功している有名な商品ですら、最初のバージョンでは期待値を満たせていなかったことを思い出してください。
3回で期待値を上回るロードマップを引く
これらのことを参考にして、一般的なトランスフォーメーションやイノベーションのプロジェクトも、きちんとバージョン1をリリースして、バージョン3までに実用的な内容に仕上げるロードマップを書くようにしましょう。
最初から完璧な成果を出す代わりに、実用的な成果となるまでのロードマップを提示することで、ステークホルダーや経営陣に理解を得るという戦略です。
分からない時は立ち止まらずに行動しよう
また、プロジェクトの初期段階、最初の成果をリリースするまでの間は最初の仮説がひっくり返ったり、プロジェクトの予定が狂ったりと、比較的大きな混乱が生じて進む方向が分からなくなるときが良くあります。
そのような時は立ち止まらずに、様々な可能性を考えて仮説を立ててそれを片っ端から検証していき正解を探すように心がけましょう。ここで立ち止まってしまうと、プロジェクトが大幅に遅延したり無期延期になってお蔵入りになる危険性が増してしまいます。
トランスフォーメーションプロジェクトに関わるときの心構え
以上のことを踏まえて、プロジェクトの推進にあたり実行者側と評価者側の双方に必要な努力と心構えをまとめてみました。
実行者側
初回のリリースについては、産みの苦しみがあり、必要なことをすべて入れ込めないかもしれません。1回目のリリースに入れ込む項目には優先度を付けて、リリース基準は満たす前提で、2回目のリリースをターゲットに変更するものを途中で決め、何でもかんでも1回目をターゲットにすることでプロジェクトの大幅な遅延や無期延期となることを避けましょう。
また、分かっていることと不明なこと (ステークホルダーの意見が必要なこと) を明確にして、前者を元にしている内容はリリースできる精度まで高めつつ、後者については集められる情報は事前に集めるものの、リリースしてみないと分からないことについては、リリース後にアジャイルに情報を集めるロードマップを描いておき、あらかじめ評価者側に知らせて承認を得ておくようにしましょう。
これらのことをだいたい満たせるようになるために、3回目のリリースまでを念頭に置いた長期的なロードマップを最初から描いておく必要があります。
評価者側
プロジェクトをレビューする側の心構えとしては、せっかく現場から上がってくるイノベーションの芽を過去の先入観で安易に潰さないように心がけることです。
もちろん組織が法的に責任を負っているもの (製造者責任、個人情報保護、法令遵守など) や品質基準はしっかり遵守されているかどうかのレビューが必要です。しかし、これらの基準を拡大解釈して該当しない事柄に対しても保守的な判断をすることは大きな機会損失に繋がる可能性があります。
また、現場がイノベーションを起こせるかどうかは、評価者側の態度一つにかかっていることも忘れてはなりません。評価者側が保守的になれば、現場も先進的なものは上げてこなくなります。イノベーションを奨励するためには、多少のリスクは覚悟して、問題が起こったときの対処法を確認しておくなど、あくまでも前に進めること前提での対策を講じておくことがお薦めです。
＊
このように、トランスフォーメーションを成功させるには、実行者側、評価者側双方について前に進めるための仕掛けが必要であると、私も日々実感しています。
では、また！
この記事が気に入ったらサポートをしてみませんか？