「今週のタスク消化」を確認しながら進めるチーム（協力：永和システムマネジメント HIKKOSHI クラウドチーム）

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

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

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

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

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

今、話題になっているDX（デジタルトランスフォーメーション）の世界では、残念ながらこの世界観は通用しない。

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

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

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

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

ニーズとシーズ、どっちが先？

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

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

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

小さなMVPが成長して、顧客と製品を形成した

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

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

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

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

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

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

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

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

＊文：平鍋 健児
＊本記事は 2017年11月30日 JBpress に掲載されたコンテンツを転載したものです