【プロマネ】適応型のプロジェクトと、改革を実現する実験する組織の作り方
こちらの記事ではアジャイル（適応型）の組織、プロジェクトづくりについて、リーンスタートアップを参考にした進め方を考察します。
事業環境は変化し、プロジェクトのアウトカムは陳腐化し得る
前回、ウォーターフォールモデルの成り立ちと、その代表的な問題点、それからウォーターフォールのような直線的な計画技法での手戻りリスクに対して、アジャイルの適応型アプローチでどう補完できるかという考え方を紹介しました。
ただし、大規模システム開発による問題点は、ウォーターフォールという手法ができたときから存在する、"手戻り"のリスクだけではありません。
おもにここで言っている"手戻り"は、元々、想定していたビジネス要件、システム要件の誤解や見落としに端を発しているケースを指しています。ここでハイライトする問題は、それに加えて、そもそもの想定自体が変化しうる、もしくは要件そのものが時間の経過でなくなってしまうというリスクもあるということです。
私が今までのコンサルタントしてのキャリアで携わってきたプロジェクトは、SAP製品を中心としたERPや、SalesforceプラットフォームでのCRMなどを利用した、グローバルでの業務改革とシステム導入がメインでした。
そういったプロジェクトでは数年から、構想策定まで含めると10年近くかけている企業もザラで、予算も数十億円から数百億円規模がほとんどになります。
それだけの時間が経過すれば、世の中も変わりますし、事業環境も変わります。もちろん凡その予測のもとに構想は策定し、必要に応じて出来る範囲のアジャストメントは行いながらプロジェクトを進めて行きます。それでも直線的な計画では工程が後ろに行けば行くほど、可能な適応の範囲は狭まっていきます。
プロジェクトが終盤に近付くタイミングで、環境が激変するようなことがあれば、プロジェクト中止も本来は視野に入ります。ですが、サンクコスト（埋没コスト: 回収できなくなった投資費用）として腹を括っての意思決定が必要な場面で、掛けたお金と関わってきた人、またその時間を考えると、その決断はかなり難しくなります。
企業によってはそれだけの時間がかかっていれば、プロジェクト期間中に経営者も代替わりしていることも珍しくないでしょう。
こうした状況を考えると、従来型の大規模プロジェクトの進め方が、多くの業界・業種の企業において、適用が難しくなっていくのはご理解頂けるのではないかと思います。
そして今後のプロジェクトマネジメント手法に取り入れられていくと予測され、主流になっていくのではないかと考えているのが、リーンスタートアップを取り入れたプロジェクト計画です。
リーン（Lean）とは何か？
まず、リーンスタートアップについて説明する前に、この派生元であるリーン生産方式について触れます。リーン生産方式はトヨタ生産方式をMIT（マサチューセッツ工科大学）の学者が研究し、定義づけたうえで発表された生産方式です。
リーン（Lean）とは「ぜい肉のない」とか「引き締まった」という意味から転じて、経営や生産管理における「無駄がない」「効率的な」という意味合いで使われるようになりました。
この意味でリーンという言葉を紹介したのは、Waymo（Googleの親会社Alphabet Inc傘下の自動運転技術開発企業）のCEOであるジョン・クラフシック（1961 - ）が、マサチューセッツ工科大学で研究していたころに発表した論文「リーン生産方式の勝利（1988 - "Triumph of the Lean Production System"）」だそうです。
その後、ジェームス・ウォマックとダニエル・ジョーンズによる共著「The Machine That Changed The World（1990）」 でリーンは定義され、一般用語となっていきました。以下、書籍の商品説明の抜粋になります。
本書は、より高品質で、コスト効率がよい製品、高い生産性、高い顧客忠実性を可能にした生産システムである「リーン生産方式」についての興味深い考察である。リーン生産の特徴はチームワーク、コミュニケーション、資源の効率的利用である。その効果は驚くべきものだ。欠陥は3分の1、工場のスペースと工数は2分の1になった。『The Machine That Changed the World』は、リーン生産とは何か、どのような仕組みなのかについて具体的に説明し、自動車業界に確実に広がっているこの方式が世界的に及ぼす重要な影響について論じている。
（「The Machine That Changed The World」解説からの抜粋）
The Machine That Changed The World（1990）
リーンスタートアップの生い立ち
リーンスタートアップもリーン生産方式と同様に、無駄を省き、効率化するための手法です。考え方として、企業のスタートアップ段階で、消費者からのフィードバックをもとに、消費者が望まない機能やサービスに、企業が必要以上の時間やリソースを費やさないことを目指します。
リーンスタートアップは、シリコンバレーの起業家からアカデミックに転じたスティーブ・ブランク（1953 - ）の顧客開発方法論に基づいています。ブランクはその著書『Four Steps to the Epiphany: Successful Strategies for Products that Win (2005)』におおいて、企業が製品開発に没頭する落とし穴について語り、「開発プロセスのできるだけ早い段階で、顧客と顧客が直面している課題について学ぶ」大切さを強調しました。
そして、この顧客開発方法論を発展させて、エリック・リース（1978 - ）の『リーンスタートアップ（"THE LEAN STARTUP" - 2011）』に繋がります。
THE LEAN STARTUP (2011)
リースは2004年にIMVUというオンラインソーシャルネットワークの企業を共同設立し、前述のブランクの顧客開発方法論を採用しました。同社では多額の初期投資は行わずに、半年でMVP（Minimum Viable Product: 最小限の製品）をリリースしました。（このMVPという考え方がリーンスタートアップの中核です。）
IMVUを去ったのち、リースはスタートアップのアドバイザリーを開始します。そして自身の経験を基にリーンスタートアップの方法論についてブログへの投稿を開始し、次第にリーンスタートアップ運動に専念し始め、2011年に前述の著書『THE LEAN STARTUP』を刊行しました。
リーンスタートアップのコア原則
リースはリーンスタートアップのコア原則を紹介していますが、その中でプロジェクト方法論の参考になるものを３つ抜粋します。
1. MVP（Minimum Viable Product: 最小限の製品）
2. スプリットテスティング
3. 構築-測定-学習のループ（Build-Measure-Learn）
1. MVPは、パイロット開発と考え方としてはほぼ同じです。最小限の製品によってビジネス要件をテストし、できるだけ早く顧客からのフィードバッグを受け、検証プロセスを開始することを目標とします。
著書の中でリースが例として挙げているのが、オンラインで靴などを販売するZapposという企業（現在はAmazonの子会社）です。
Zapposの創業者は、本格的なサイトを立ち上げる前に、オンラインで消費者が靴を買う需要があるかをテストしました。具体的には実店舗をもつ靴の小売店の在庫から写真撮影し、ウェブサイトに載せ、売れたら小売店から小売価格で買い取り、消費者に出荷していました。その試みによって消費者がオンラインで靴を買う需要があると判断した後に、Zapposでは本格的な投資を開始したそうです。
2. スプリットテスティングについては、A/Bテストとして理解されている方も多いのではないかと思います。私自身がリーンスタートアップに着目するきっかけとなったのも、ハーバードビジネスレビュー 2020年6月号でのA/Bテストの特集でした。
これは「異なるバージョンの製品やサービスを、同時に顧客に提供する」実験です。二つの製品・サービスの間で、それぞれ指標に対する実績を測定、比較し検証することが目標になります。
スプリットテスティング、A/Bテストの例。
ランダムに上記二つのバージョンのボタンを表示し、
どちらのクリックレートが高いか検証したもの。
最後に3. 構築 - 測定 - 学習のループですが、リースは顧客開発の重要性としてスピードを強調しています。企業やチームの効率性は、「アイデアを出す力」「MVPの素早い市場へのリリース」「市場でのMVPに対する反応の検証」「以上の経験からの学習」によって決まると言っています。
このループはIdeas（アイデア） -> Build（構築） -> Product（製品） -> Measure（測定） -> Data（データ） -> Learn（学習）からなります。
アジャイル型構想実現アプローチ
このリーンスタートアップの考え方にインスパイアされて、今後のプロジェクトを進めるうえでのアプローチをまとめたのが、昨年、私がSAP NOWで講演させて頂いた『アジャイル型構想実現アプローチ』でした。
私の講演はスタートアップ企業の方々が対象ではなく、ERPの中でも大企業を中心としたユーザを抱えるSAP社のユーザが集まるイベントでした。
そのため、リーンスタートアップを下敷きにしながら、既存の大企業が、その変革を長い年月、莫大な投資を一度にかけるのではなく、どのように適応型のアプローチで進められるかを考察したものとてまとめました。
まず、一つ目に考慮するべき点として挙げたのが、機能別・多重階層の組織から、改革テーマ別のプロジェクト中心とした組織への変革です。（この組織からは、市場調達可能なサービス、アウトソース可能なオペレーションは省いています）
これは前述のリーンスタートアップのコア原則を、実際に実行できる組織作りを目指しています。改革テーマごとにプロダクトオーナーに大胆な権限移譲を行い、そこでMVP、A/Bテスト、構築-測定-学習のループが行われているイメージです。
部・課のサイロ化を許し、既存ビジネスの維持を目的とするのではなく、改革テーマごとに継続的な変革を志向するチームを組成しています。
（図１）
二つ目は、この改革テーマ単位のチーム構成を可能にするための、企業プラットフォーム（ERPなど基幹システム）の構成について、整理を提案しました。
図２で定義されているTier1は、企業全体のプラットフォームを考えたときの、MVPとして捉えていました。
従来の考え方では、Tier1, Tier2, Tier3と分類されたすべてを包含したうえで、数年がかりで多額の投資をしてプラットフォームを構築してきていたと思います。そこでの弊害はこの記事の冒頭でも述べた通りです。
一方、ここでは、まず企業を構成する最小構成でプラットフォームのベースラインを素早く構築し、その上に変革を実現するための機能群を追加していく考え方を提示しました。
この考え方を基にしたときの利点としては、素早い構築以外に、ROIの明確化があります。
Tier1機能群では企業のコア業務のため、投資に対するリターンを明確にすることは本来不可能です。一方でTier2, Tier3の機能群ではROIをシビアにみる必要があります。今までのすべてをいっぺんに進めるウォーターフォール型の進め方では、投資に対するリターンが恣意的なものになりがちでした。
（図２）
次に、デプロイに対する考え方です。Tier1で分類した機能は最小限の構成なので随時ではなく一度にリリースしますが、その中でも企業の業務をWing to Wingでつなぐための機能と、そのバリエーションがあります。
一般的に例えば製造業を例にとると、前者は需給計画、調達、生産、販売、物流、会計・・と一連の流れをまず頭からお尻まで通すための機能です。
それに対して後者のバリエーションと言っているのは、例えば受注を受ける時にWebサイトで注文を受ける場合と、Eメールでの注文、電話注文、EDIなど複数あるとします。これらプロセスごとのバリエーションを網羅することを後者としています。
まずプロセスで代表的なバリエーションの機能を開発し、ユーザテストを行います。派生したバリエーションには手を出さず、頭からお尻まで一通り通せるようになるところまでを優先します。そこまででできたら、一回目の統合テストを行います。
次に、プロセスごとにすべてのバリエーションを網羅する形までいって、二回目の統合テストを行い、ここでリリースします。二回目の統合テストは、バリエーションの多さ、複雑さによっては分割を行う必要があります。
ただし、そのバリエーション自体が本当に必要かの検証は、強調しすぎることがないくらいに本当に重要です。
あるプロジェクト例では、発行する請求書への押印が、お客様によって拠点長印、ビジネスセンター長印なのか・・など細かい管理が行われていました。最初は意味があったのでしょうが、システム導入時にはなぜそうなっているのか、法的な根拠などあるのかなど、わからなくなっていました。
（図３）
Tier1機能群のリリースはここでは一回と置いていますが、機能をある程度のかたまりで分割リリースができるのであれば、ここでもフェーズドアプローチを積極的に採用するべきです。
ここまででTier1機能群のデプロイが完了したら、あとはTier2, Tier3の機能群は変革テーマごとのチームによって、定期的なデプロイメントを繰り返します。定期的なデプロイメントでは、全面稼働の前に複数回のパイロット運用により実用性の検証を必ず行います。
適応型アプローチへ収斂する未来予測
特に大規模システム導入におけるプロジェクト手法について、今は過渡期ではあります。ウォーターフォールとアジャイルが混在し、どっちつかずであればまだいいのですが、双方の悪い点だけをピックアップして推進しているようなプロジェクトも残念ながらあります。
現在の状況はウォーターフォールが良いとか、アジャイルが良いとか、そういう話ではなく、どう事業環境に適応した形でプロジェクトデリバリを推進できるのか、ビジネスとプロジェクトが一体となって考え、推進することが必要です。
むしろ前述のプロジェクトを中心とした組織においては、プロジェクトとビジネスのエグゼキューションは同じメンバーが行い、その検証を行うような形を発展形としてイメージしています。（DevOpsのビジネス版のような形）
唯一の解として提示したわけではないですが、いずれは特に新興の事業においては、適応型のアプローチに収斂していくものと思います。
この記事が気に入ったらサポートをしてみませんか？