bit Labs

はじめに

時代遅れのビジネスモデルを破壊する「デジタル・ディスラプター（創造的破壊者）」。彼らが展開する、革新的で魅惑的なサービスが次々とリリースされているいま、業種・業態を問わずさまざまな企業が、デジタルテクノロジーと既存の事業資産を組み合わせてビジネスモデルを変革する活動（デジタルトランスフォーメーション、DX）に資源を集中させています。本稿では、革新的なサービスを生み出すために企業がどのようなプロセスを「フレームワーク（枠組み）」として用意すべきかアウトラインを眺めた上で、また、その重要なパーツである「アジャイル」という開発手法を成功させるために、私たちが重要だと考える５つのポイントをご紹介します。

サービス開発は地道な「仮説検証」の繰り返し

この「潮目」の時代において、企業は新しいサービス、新しい価値を創り出す必要に迫られています。当たり前ですが、一朝一夕で、高い付加価値を持ったサービスを世に送り出すことは非常に困難です。なぜなら、この挑戦には「正解」が与えられていないので、試行錯誤やトライ＆エラーを繰り返しながら「解答」を自ら導き出すプロセスが必要だからです。まず出発点として、「新しいサービスの提供価値とは何か？」というテーマを、顧客＝人間中心にサービスや製品コンセプトを検討するデザインシンキングの手法を活用して検討します。デザインシンキングでは、要所要所で消費者インタビューやユーザテストを実施して、新しいアイデアの価値検証を繰り返して、コンセプトにブラッシュアップさせていきます。私たちは、この工程を「サービスデザイン」と呼んでいます。「これでいけそうだ」というレベルでコンセプトが固まったところで、それを今度は、スマホアプリやその裏側で動作するITシステムとして実装していきます。ここでも、少しずつ作っては、利用者や関係者に体験してもらって評価してもらうということを繰り返していきます。私たちは、この実装工程を、アイデアが少しずつ形になり繋がっていく姿を想像して、「インテグレーション」と呼んでいます。そして、次の段階。サービスを市場にリリースし、利用者の声や蓄積されるビッグデータから、フィードバックや示唆を得て、それを元に、次のサービスの改善や見直しに繋げます。この際、時にはコンセプトそのものの変更や撤退の選択肢も視野に入れつつ、サービスの提供価値を高めることに注力しています。この工程を表す表現としては、世の中ではよく「グロースハック」という言葉が使われていると思います。

以上の、ビジネス仮説検証サイクルの全体像をまとめると上記のようなかたちになります。このサイクルを意味ある形＝「成果」につながる形で回していくためには、「ビジネスオーナーと開発チームがサービスの価値を深いレベルで共有し、検証を繰り返すスピードを重視して機能開発を進めること」が、とても大切になります。従来型の事業開発や業務改革では、ビジネスサイドとシステム部門が明確に分離されていましたが、試行錯誤しながら、スピード感をもって「未知の問題」に挑むには、このような分離型は適しません。

私たちがアジャイルを採用する理由

アジャイルというプロセスは、このような仮説検証サイクルを回すために適していることは自明ですが、それだけでなく、アジャイルは投資評価という観点でも適していると言われています。従来の投資評価で用いられている「NPV（正味現在価値）」や「IRR（内部収益率）」は、その事業の「価値が変わらない」前提で、事業開始から一定期間の投資効果モデルで、事業価値を考えます。これには、業務プロセスやシステムの全体像を細部まで決定し、リリースまでを計画した上でものづくりに着手する、ウォーターフォール型の開発手法が適しています。一方で、市場の受容性や技術的な実現性がわからない新規サービスを開発するような場合は、勝手が異なります。不確実性の高い投資テーマに関する評価手法である、「リアルオプション」の考え方は、短期間でリリースを繰り返し、サービスの市場性確認、機能改善、ピボット、追加投資、早期撤退などの意思決定を、柔軟に行うことができるアジャイル開発手法が妥当であると言えます。

さらに、私たちは、アジャイル開発手法の中でも、世の中にもっとも普及している手法であるスクラムの採用をおすすめしています。その理由は、「透明性」、「検査」、「適応」というスクラムの３つの特徴が、先ほど挙げた仮説検証サイクルに必要な「ビジネスオーナーとシステム開発者がサービスの価値を深いレベルで共有し、検証を繰り返すスピードを重視して機能開発を進めること」と合致しているためです。

成功するアジャイルプロジェクトを支える５つのポイント

私たち自身も、スクラムの導入にはさまざまな苦労がありました。スクラムには細かいルールは存在しませんし、スクラム自体は、ソフトウェア開発に特化した枠組みでもないため、ソフトウェアエンジニアリングとしてどうあるべきか、という点について細かく言及されていません。例えば、プロジェクトマネジメントの基軸となるQCDS（Quality, Cost, Delivery, Service）の考え方や、日本のような発注者と受託開発が分離しているケースで現実的にどのような体制を組んで臨むべきか、といった内容は、実践者たちの経験とノウハウとして共有されている以上の情報がありません。そのため、そもそもステークホルダーがアジャイル開発を誤解しているために生じる失敗、メンバーのマインドセットが揃っていないために生じる失敗、エンジニアリングスキルの不足から生じる失敗、メンバー入れ替えに起因する失敗、スコープ調整不足による失敗など、私たちもさまざまな失敗を経験してきました。私たちは、このような成功・失敗の経験とノウハウを　「アジャイル・マネジメントガイド」　という形で集約しています。「アジャイル・マネジメントガイド」では、従来型のウォーターフォール開発でのマネジメント実績がある方を読者として想定し、下記のテーマについてPMBOK（Project Management Body of Knowledge）の知識エリアとも対比して解説しています。・プロジェクト開始前の入念な準備・QCDSのコントロールに対するマインドセット・計画的な体制構築・高頻度のステアリングコミッティ（プロジェクト運営委員会）・信頼関係の醸成

それぞれ、簡単にポイントを紹介します。

1. プロジェクト開始前の入念な準備

「プロジェクト開始前」と言っていますが、“初期Sprint”と言い換えられます。このプロジェクトで何をゴールとするのかを合意する、チームの生産性がどのくらいかを測定する、といった“初期Sprint”で実施すべき内容について記載しています。

2. QCDSのコントロールに対するマインドセット

ウォーターフォール型の開発と比較して、アジャイルの開発ではコストやスケジュールよりスコープの調整を行い、かつスコープ変更が頻繁に行われる旨を記載しています。

3. 計画的な体制構築

常にスコープ変更が行われるアジャイル開発では決裁権限者との関係構築が最重要であり、決裁権限者と密接なコミュニケーションが取れるような体制を構築したほうが良い旨や、メンバーの入れ替えはパフォーマンスの低下を招くため、なるべく固定にしたほうが良い旨を記載しています。

4. 高頻度のステアリングコミッティ

上記の決裁権限者を体制に巻き込んだ後は、週1、最低でも月1のステアリングコミッティを開催し、チームの成果、生産性や課題など、現状を嘘偽りなく伝えることが大切な旨を記載しています。

5. 信頼関係の醸成

関係者間での信頼関係がなければアジャイル開発は成立しない、という旨を記載しています。

さいごに

ここでご紹介したマネジメントガイドの内容は全体のごく一部です。読者の立場に合わせて、「ビジネスオーナー向け」「発注者向け」「受注者向け」など、それぞれご用意しています。また、bit Labsでは、「サービスデザイン」の工程、「インテグレーション」の工程、それぞれの導入や立ち上げを支援するプログラムもご用意しています。「概念や理想はわかるけど、現実解としてどう取り組めばいいのか？」　お悩みの方は、ぜひ、bit Labsまでお問い合わせください。

bit Labsのサービス