新規サービス開発のためのアジャイル
新規サービス開発に必要なことは？
この記事では新規ビジネス発想のためのビジネスフレームワークといった内容には触れません。
新規サービスのコアアイデアが固まっていて、自社・個人・スタートアップでシステム開発を開始する際の内容となっています。
新規サービス立ち上げて軌道に乗り始めるまでの間にシステム開発に必要なことはなんでしょうか。
それは、柔軟性と素早さです。
なぜアジャイル開発なのか？
よくウォーターフォールとアジャイルが比較されます。
どちらもシステム構築やソフトウェア開発を伴うサービス開発を行う上での開発プロセス・方法論です。
ウォーターフォール開発は上から下に各工程を後戻りしない前提で進めていく手法で、アジャイル開発は機能単位で小さくすばやく開発を繰り返していく手法です。
ウォーターフォールは「要件定義 -> 設計 -> プログラミング -> テスト -> リリース」という流れで行い、 仕様が決まっていて開発途中に仕様変更が起きづらいシステムの開発 に適しています。
アジャイルは、 要件が定まっておらず仕様変更が起きやすいシステムの開発 に適しています。
昨今、アジャイル開発に注目が集まっていますが、それはなぜなのでしょうか？
現代社会はテクノロジーの進化によって、あらゆるものを取り巻く環境が複雑さを増し、将来の予測が困難な状況にあることから、「VUCA（ブーカ）時代」と呼ばれています。
VUCAは、Volatility（変動性）・Uncertainty（不確実性）・Complexity（複雑性）・Ambiguity（曖昧性）の頭文字をとった造語です。
このVUCA時代にはさまざまなことが起こります。
例えば、様々な国の政治の混乱や国家間の争い、伝染病の広がりやそれに伴う経済の低迷など、今までスタンダードが一気に崩れるような 想定外の出来事が次々と発生します 。
このような事態に備えることは難しいでしょう。
また、 Uber や Airbnb といった 業界の概念を覆すサービス が突如登場し、既存の市場が消えそうになったり、思わぬ競合となったりします。
こんな時代に我々は何をすべきなのでしょうか？
それは不測の事態に対応する様々な準備をするのではなく、 不測の事態に素早く対応する能力 を身に付けることです。
予測の難しいことに想像で対応するのは時間もお金も無駄というものです。
システム開発ではどのようにすればよいでしょうか。
1 つの方法としては、アジャイル開発を行うことです。
一般的にウォーターフォール開発は、よく吟味された多くの機能を一度に開発するため、大規模で長期のプロジェクトになります。
アジャイル開発は、 MVP（Minimum Viable Product）と呼ばれる、ビジネスのコアコンセプトのみの必要最低限の機能を備えたプロダクトを開発・リリースして、市場の反応を見ながら追加開発をしてサービスを育てていく、 小規模で短期のプロジェクトを反服的に 行います。
不測の事態に対して、ウォーターフォールとアジャイル、どちらのほうが対応力が高いでしょうか？
まずは何をするのか？
前節で「アジャイルが万能」ともとれる内容を記載してしまいまいたが、 決してそうではありません 。
仕様が決まっていて開発途中に仕様変更が起きづらいのであればウォーターフォールのほうが効率がいい です。
ですので、 MVP をリリースするまではウォーターフォール開発という選択も問題ありません。
ただし、 ビジネスのコアコンセプト部分＝必要最低限の機能 の開発だけです。
本節のタイトルは「まずは何をするのか？」です。
システム開発方法を ウォーターフォールにするのかアジャイルにするのか選ぶことではありません 。
正直申し上げて、 MVP を早くリリースできるのであれば、どちらでもその他でもかまいません。
ビジネスのコアコンセプトが定まっている前提ですが、まず最初にやることは ビジネスモデルを数値で評価する方法を決定すること です。
MVP リリース後は、アジャイル開発で 仮説と検証 を繰り返すことになります。
何らか評価する方法がなければ、 仮説を検証できない のです。
ここまで読んでいただいた方はお気づきかもしれませんが、アジャイルのことをあまり書いていません。
そして以降もあまり書くつもりもありません。アジャイル開発自体について調査されている方、誠に申し訳ありません。
新規サービス開発において大切なことは、 アジャイルか否かではない ということです。
アジャイルの代表的なプラクティスであるスクラムについては以下の記事を参照してください。
KPIの設定
KPI は、 Key Performance Indicator の略で、重要業績評価指標と訳されます。
ここでは、 「目標を達成するための重要な評価指標」 ととらえてください。
どの KPI を利用するのか・どう収集するのか、をまず検討・決定してください。
何らか評価する指標がなければ、せっかく MVP をリリースしても そのサービスが成功しているのか失敗しているのかわかりません 。
さらに 次にどのような機能を追加すればよいのか打ち手を考えることもできません 。
直接的に売上がたつようなサービスであればまだよいのですが、何らか別にコアビジネス・サービスがあって、それを補助するようなサービスであればなお KPI が重要になります。
例を挙げます。
あなたは何らかのブログをやっています。基本的に Google などの Web 検索から読者が流入しています。
読者を増やすために Twitter でブログを紹介することにしました。
その後読者が増えたのか減ったのか、増えたとして Twitter の効果があったのか検索からの流入が増えたのか分かりません。
どちらの方が流入が多いでしょう？今後どちらに力をいれましょう？止めるのか続けるのか？
もし、 Twitter からの流入数、 Web 検索からの流入数を KPI として設定して収集・観測できていたらどうでしょうか。
クラウド人材必須、最少人数で
なにかシステムを開発するには IT 人材が必要です。
どのような人材が必要でしょうか？
サーバーの調達が必要なサービスの場合、ずばり クラウド人材は必須 です。
なぜクラウドなのでしょうか？
ここでいうクラウドとは、 Amazon Web Services ( AWS )・Google Cloud・Microsoft Azure などの パブリッククラウド を指します。
なぜパブリッククラウドをお勧めするのかといいますと、以下のようなメリットがあるからです。
- オンライン申込で調達期間無くすぐに利用を開始できる
- サーバーリソースの追加・削除をリードタイム無しで実施できる
- サービスの規模に応じた投資額となるので費用を削減できる
- マネージドサービス（機器やソフトの維持・運用をサービス側に任せられる）によりシステム管理者の労力を削減できる
つまり、 すぐに利用開始・終了できて管理も楽 ということです。利用しない手はありません。
数多くあるパブリッククラウドからどれを選ぶか決め手に欠ける方は AWS で問題無いと思います。
最も多くのサービスがあるので開発を削減でき、業界最大なのでスキル保有しているエンジニアの数も多いです。
また、開発者の人数は最小限にしましょう。 開発者だけでなくビジネス・サービス企画のメンバも です。
あまりに多いとアジリティが低く、いつまで経っても MVP を作成してリリースすることができません。
MVP をリリースしてからが本当のスタートです。
さいごに
いかがだったでしょうか。
「タイトルは釣りです」と思われるような内容だったでしょうか。
一見しごく当たり前のことを書いているように思われるかもしれません。
しかし本当に多くのプロジェクトでサービス開発に集中するあまりに忘れられています。
ある時は、 MVP を絞り込めず非常に多くの機能を盛り込んでしまう。。。
またある時は、プロジェクトの体制を非常に大きくしてしまう。。。優秀な PM ほどやりがちです。
そしてまたある時は、 KPI を決めずに開発のみ突っ走ってしまう。。。
DX への焦りからか非常に多くの企業が新規サービス開発に乗り出しています。
成功事例が少ない（？）理由は、 DX が非常に難しいというわけではなく、意外と初歩的な部分でつまずいているだけなのかもしれません。
Discussion