検索
  • 平鍋健児

イノベーション創出では企画と開発を分離してはいけない

最終更新: 2019年6月4日

デジタルビジネスに活かすアジャイル開発(第1回)



デジタルビジネスに活かすアジャイル開発という連載シリーズ第一弾です。特にDX(Digital Transformation)の文脈で、顧客づくりと開発をどう回すか、というテーマを組織戦略視点で書いていきます。


※この記事はAgile Studio Fukuiの平鍋健児 JBPress に連載したものを加筆修正しています。


アジャイル手法の「スクラム」はラグビーが語源

これまでの組織構成と開発手法では、時代のスピード感に追いつけず戦略的なITを使った顧客創出ができない、特にイノベーションを扱うことは難しい──。多くの経営者がそのことに気付き始めている。


まず「企画」し、そして「開発」し、「品質保証」し、「出荷」し、「保守」するといった直線的なプロセスと、それぞれの機能を縦割りにしたこれまでの組織構成は、時代にそぐわなくなりつつあるのだ。


これまでの世界観が通用しないイノベーションの世界


例えばこれまでのシステム開発は、企画書が書かれ、市場調査から綿密な検討を経て大きな予算を確保し、その後でベンダーを選定して開発を依頼する、という定型的な流れに基づいて行われていた。一般にウォーターフォール型、と言われるこの種の開発は「システムは調達可能である」という前提に基づいており、「よい企画」が「うまく開発される」ことが成功とされる。


もしビジネスが失敗すれば、それは「企画が悪い」か「開発が悪い」か、つまり、「課題設定」が間違っていたのか「解決実施」がうまくいかなかったのか、どちらかだ。


だが本当にそうだろうか? この世界観は課題が「正しく定義できる」という前提がある。つまり「これを作れば必ず成功できる」という確信が持てる世界の話である。


今、話題になっているイノベーション、DXの世界では、残念ながらこの世界観は通用しない。


すべての産業においてDXの波が押し寄せ、サービス、それもソフトウエアを中心としたユーザーと繋がるシステムが多く企画・開発されるようになった。特に、コネクテッドカー、IoTとビッグデータ、AIを利用した消費者へのコンテキストアウエアなアプローチ、モバイル端末と連動した顧客体験、金融や保険業界の新サービスなどにおよんで、大きな流れを作ろうとしている。


では、DXの世界では、どのような製品開発の手法、組織構成が有効なのだろうか。


「鶏が先か卵が先か」問題


鶏(ニーズ=顧客)が先か卵(シーズ=製品)が先か

あるサービスを企画する。潜在ユーザーが特定され、インタビューを行う。こんなものがあれば売れそうだ、と。そのニーズ(企画)を元にモノを作る(開発)。しかし、ユーザーが実際の動くモノを見ると「これじゃない」という言葉が出る。ユーザのニーズを特定することは本当に難しい。一発では当たらないのだ。


モノがないとフィードバックが得られない。フィードバックを得るためには動くモノが必要だ。でも、作り手の思いだけで作ってもニーズにはフィットしない。モノは何も要求がないところからは作れない。「ニーズ」と「シーズ」はちょうど鶏と卵の関係になっている。さて、どちらが先なのか?


この問題に対するの私の答えは「その中間のものが先にあった」のである。「そしてそれが進化した」、のだ。


企画と開発を合体させ、同時に進める。



小さなMVPを成長させ、顧客と製品を形成する

システム企画開発の文脈では、その中間物、実験過程を「PoC」(Proof of Concept)と呼ぶ。最初は、解きたい課題とそれを解決するアイデアのセット。本当に紙一枚に書ける企画だ。そして想定顧客候補と話をし、「このアイデアを実装してみるとこうなる」という最小のモノ「MVP」(Minimum Viable Product:実用最小限の機能を備えた製品)を作る。さらに、できればこれを市場リリースしてしまう。これをもって、ユーザーの獲得、フィードバックを得て次の進化方向を決め、製品と顧客を同時に育てて行く。


つまり、「製品づくり」と「顧客づくり」を同一ループの中に入れてしまい、MVPを核とした機能追加をリリースすることを繰り返してシステムを成長させていく開発手法である。


2011年にエリック・リースが書いた『リーンスタートアップ』は大きな反響を呼んだ。シリコンバレーのスタートアップのやり方を体系的に書いたものだ。この手法が認知され、このようなやり方を「大企業の中でも」取り入れるにはどうしたらよいか、という流れが来ている。


そして、このような価値創造過程を支える企画開発手法として注目を浴びているのが、スクラムをはじめとする「アジャイル開発」と言われる分野だ。アジャイル開発は起源を1990年代後半に持つすでに歴史のある手法で、2001年にアジャイル宣言が書かれ、言葉として定着した。


アジャイルはあたかも「開発」だけの手法に受け取られがちだが、もはや開発だけではなく、先のリーンスタートアップの企業内適用やDevOps(デブオプス:開発担当者と運用担当者が連携して協力する開発手法)を引き合いに出すまでもなく、企画、開発、運用まで含めた、ビジネス駆動型のワンチームを作る手法として既存大企業からも注目を集めている。


伝言ゲームからの脱却


システム開発の文脈では、従来手法の大きな問題がもう1つ浮かび上がる。「正しい仕様を決めてから作り始める」ので、仕様や要求を決めて伝えるために、膨大な仕様書と、それを伝達する必要がある。これが大規模になると、システム開発は、「壮大な伝言ゲーム」になってしまう。大企業の情報システム部門にとって、RFPの作成から実際のシステム仕様に落とし込むことは大きな負担である。


また、受発注契約がそこに挟まると、さらにやっかいになる。請負契約のリスクがあるため、開発の見積もりも大きな安全係数を掛けたバッファをとり、ディフェンシブな開発がはじまる。「言った、言わない」をなくすためにしっかり議事録をとり、また、安易な回答を避けて「持ち帰って検討します」が始まる。質問リストや課題リストが積み上がり、その管理にまた時間がとられる、本当に必要なものではなく「仕様書に書かれた通りに」不要なものを作る──などなど。


戦略的な開発で、これを始めるとスピードが全く出ない。これを解決するには、ビジネスの意思決定ができる人と、腕の立つ開発者たちがワンチームになること。そして、そこで起こっていること(情報、感情)を共有すること。これがアジャイル開発の最初の一歩だ。


最初のPoCには大きなチームはいらない。「ツーピザ・チーム」(2枚のピザを分け合える程度の人数)という言葉があるが、10名程度にチームを抑えて、毎朝顔を合わせる。現在のタスクの進行状況をボードで共有する。やり方をふり返ってもっと効率的な工夫を毎週考える。


これが、アジャイルであり、その1つの兵器がスクラムである。次回はアジャイルの歴史から、現代のビジネスでの意味についてさらに詳しく見て行きたい。


次の記事

アジャイルスタジオ福井では、実際にアジャイル開発を行なっている現場見学を受け入れています。ご興味があれば、こちらへどうぞ。




304回の閲覧
ASF_logo_line.png
  • Facebook

 お電話でのお問い合わせはこちら

0776-25-8488

平日10:00~17:00まで。セールス目的のお電話はご遠慮ください。 

set-baseE_Y.png
ITS_logo_sign2.png

​株式会社永和システムマネジメント

​ITサービス事業部

 〒918-8231 福井県福井市問屋町3丁目111番地
 

© 2019 ESM, Inc.