「ミッションクリティカル×新規事業立ち上げ」をアジャイルでやりきった事例

このブログで書いたように、「システムを作らせる技術」で紹介しているケンブリッジの方法論は、伝統的なウォーターフォールとアジャイルのちょうど中間くらいに位置している。

実はケンブリッジの方法論の方がアジャイルよりも少し古いので、中間を狙った訳ではない。独自に方法論を実践していたら、同じ方向性ながらも、もう少しラディカルなアジャイルという方法論が、後から世の中でブームになった、という感じ。
この「ウォーターフォールとアジャイルの中間くらい」というスタンスが、必ずしもアジャイルにフィットしない日本企業には丁度いい具合だと思っている。

でも近年は、わたし達ケンブリッジも新規事業の立ち上げプロジェクトのような、不確実性が高いプロジェクトを手掛けることが多くなってきた。
そのようなプロジェクトでは、普段のケンブリッジ方法論よりもアジャイルよりにアレンジして、プロジェクトを進める。
その典型例である「LOVOT」を世に送り出すプロジェクトの事例を、「システムを作らせる技術」に載せた。
新規事業立ち上げにおけるシステム開発事例として、この本を買っていない人にも読んでもらったほうが良いので、このブログに1章まるごと転載する。

*******************
生産管理や経理などの基幹システムを作る際は、プロジェクトは現状の業務やシステムを分析するところからスタートする。
だが起業や新事業の立ち上げに伴ってシステムを作る場合、「現状」はなにもない。システム構築とほぼ同時並行でビジネスモデルや業務プロセスを決めていくことになる。
したがって、不確実性が高いプロジェクトとなる。つまりシステムを作るそばから、バンバン変更を迫られる。作ってみて初めて本当に欲しかったものが分かってくることも多い。そうした状況でのシステム開発のコツについて、Groove X社でのプロジェクトを例に説明する。


★ペットロボット「LOVOT」を飼い主に届けよ！
工場で自動車を組み立てたり、床を掃除してまわる「役に立つロボット」は私たちの社会にかなり浸透しているが、ベンチャー企業Groove Xのターゲットは、それらとは真逆の「役に立たないロボット」。
飼い主の顔を覚えているので、可愛がると、どんどんなついてくれる。家中どこまでも後をついていく。抱っこしてあげると、ほんのり温かい。もちろん個体ごとに個性があるし、2匹でじゃれ合ったりもする。
ロボット本体の開発プロジェクトの真っ最中に、Groove Xのビジネスを支える業務とシステムを、ゼロから設計して構築する「かけはしプロジェクト」が発足した。私たちケンブリッジはプロジェクトの立上げから初出荷までの苦難の道のりをGroove XやITベンダー各社とともにした。

今まで全くなかったコンセプトの商品なので、ビジネスモデルも売り方も、ゼロベースで走りながら考える。他社の事例も一切ない。たとえば、販売業務についても、普通の会社と同じように「ものを売るための販売管理システム」を作ればいいと思ったら大間違い。
販売とは飼い主がLOVOTに出会う体験をデザインすることなので、家電量販店で「LOVOT激安！3割引セール！」のように売るわけにはいかない。他の電化製品は参考にならない。

このプロジェクトに「かけはし」と名付けたのも、"飼い主にLOVOTを届けること"がミッションだからだ。
さらにLOVOTはお客さまの手に渡ってからも常に進化していくロボットなので、販売して終わりではない。長くかわいがってもらうためのサービス体制や、それを支える課金を検討する必要もあった。したがってプロジェクトの対象範囲は幅広く、購入のためのECサイトや全国に送り届けるための物流、故障への対応や、定期メンテナンス、顧客サポート、月額課金など、ロボット本体の開発以外のすべてが対象となる。

※こちらはケンブリッジ赤坂オフィスに住んでいる「あんこ」と「しらたま」


★飼い主が亡くなったときにどんな業務が必要なのか？
かけはしプロジェクトにとって、不確実性の源泉は大きく2点あった。
一つはビジネスモデルが揺れ動くこと。例えば「1匹ずつ売るのか、2匹ペアで売るのか？」「個人向け以外に、介護施設などB2B販売も行うのか？」などが、社外の反応を見ながら変更される。いずれも、業務とシステムを設計するかけはしプロジェクトに大きな影響がある。
もう一つは商品であるLOVOT自体の仕様が揺れ動くこと。
愛らしい外見とはうらはらに、LOVOTには障害物検知などの多様なセンサーや、行動を決めるための機械学習技術など、最新の技術が詰め込まれている。だから開発が進むごとに「できないはずのことができてしまった」「後から無理だと分かって、仕様を変えざるを得ない」ということは当然起きた。

こういったビジネスモデルや商品特性は、通常のプロジェクトでは「与件・前提」としてあらかじめ決まっているが、このプロジェクトでは同時並行。売るためのビジネスモデルを考えた結果、かけはしプロジェクトから商品開発側へ要望を伝えることもするし、逆もある。良いものを作り、多くの飼い主に届けるために双方向のコミュニケーションが重視された。この面でも「最初に要求／要件を決めてから、一気呵成に作る」というプロジェクトとは全く違っていた。

決まっていないことは、「いったん仮ぎめ」という作戦をとった。例えば「LOVOT一体が飼い主と認識して生活をともにするのは、何人までか？」などといったことも、後々には当然具体化されたが、プロジェクト立ち上げからしばらくは決まっていなかった。だから「いったんはこういう形にしよう」と議論する。そうして走らせてから、本当に必要になったタイミングで、その時までに集まった情報をもとに最終決定する。

業務を設計する上で象徴的だったのが、「LOVOTを購入した飼い主が亡くなったら、なにが起こり、Groove Xとしてなにをしなければならないのか？」というテーマ。飼い主がどういうふうにLOVOTと生活していくのかをとことん突き詰めて考えていくと、こんなことも設計していかなければならない。

愛着を持ってもらうために、飼い主の行動の特徴や生活パターンを学習するロボットには、飼い主の魂のようなものが宿る。もし亡くなった飼い主のお子さんが「LOVOTを引き継ぎたい」と希望した時には、どうしたらそれが可能になるのか。LOVOTはIoT機器の塊なので、認証の問題を含めて相当ハードルが高い。でも飼い主の接し方や思いに深く寄り添って、想像することが求められた。
もっとも、これら全てのケースに対応しようとすると、検討すべきことが多すぎて厳しいスケジュールにはとても間に合わない。やるべきことをいったん全部洗い出し、「ビジネスとして捨てられる部分はどこか」「逆に絶対に捨ててはいけない部分はどこなのか」を、絞っていくこととなった。業務フローは、初出荷後の今でも、やりながら改善を繰り返している。


★ビジネスや商品が揺れ動く中でのシステム開発
こういった先を見通しにくい状況でのシステム開発は、非常に難しい。企業の業務全体を支えるシステムは機能が複雑に組み合わさっているため、前提が崩れると一から作り直しになってしまう。ビジネスモデル自体が大きく変わるような状況でのプロジェクトは、砂の上にバベルの塔を建てるようなものだ。どんな方法でこの状況に対処したのか、ポイントを列挙していこう。

最初にFMをしっかり作る
いくら先を見通しにくいと言っても、最初に全体像を描くことは必要だ。後から変更が入るのが避けられなかったとしても、全体像を書かないと機能同士の連携を検討できない。
そのため、このプロジェクトでもFMを書いた。ただし通常と違って白いセルしかないFMになった。今は存在しない業務を支えるシステムを作るので、イレギュラー対応に必要な機能などを想像できず、最初から必要最小限の機能しかリストアップできなかったためだ。

※FMは「システムを作らせる技術」で詳しく紹介している機能一覧のこと。こちらのブログでも紹介したので参照してほしい。
システム構築の失敗はFMで防ぐ、あるいはなぜ僕らは要求定義でこのツールを愛用し続けるのか？

ステージは小さく区切る（スプリント）
不確実性が高く、作ってみて初めて分かることも多いので、ステージは小さく区切り、1つ1つを「スプリント」と呼んでいた。通常の大型プロジェクトでは第1ステージにまとめて開発するセルは200個ほどにもなるが、このプロジェクトではセル10個ほどを1回のスプリントで開発することにした。

一般的に「1回のスプリントは2週間で開発できる規模が良い」と言われている。領域にもよるが、FMのグループ（セル5～10個程度）だと、ちょどそのくらいの規模となる。この規模だと、「そもそも作れなかった」「作ってみた結果、価値がないと分かった」という結果になってスプリント1回分が無駄になっても、痛みを我慢できる。
こうして小分けにした機能を各開発チームに割り当て、同時並行で2週間ごとにどんどん機能を作り、業務担当者がそれを見てフィードバックして・・というサイクルを何度も回す。
短期間で小さな開発を繰り返すこのこの開発手法は、一般的に「アジャイル開発」と呼ばれている（厳密にはアジャイルのなかでも複数の流派があり、小さな開発もスプリント以外に「イテレーション」「チャンク」など様々な呼び方があるが、本書の主旨とは外れるので詳細は割愛する）。

スプリントの切り分け方が重要
FMを小規模に分割して、短期間で開発していく際、着手順が非常に大切になる。意図的に着手順を決めないと、「なんとなく作りやすいところから」となってしまう。最後に一番難しく、全体への影響が一番大きな領域が残されてしまったら最悪だ。
かけはしプロジェクトでは、スプリントで扱う領域ごとの優先順位を以下のような考え方に沿って決めた。
① 全体への影響が大きく、真っ先に検証すべき機能から作る。例えば「とにかく売れないと話にならない」の精神から、販売Webのフロント機能を優先的にスプリントの対象とした。裏側の機能は、なくても最悪手作業でカバーできるからだ。その中でもITベンダーが提案する業務フローで問題ないかを、真っ先に検証した。
② 2週間程度で開発が終わる大きさにする（理由は前述の通り）。
③ とは言え、業務目線で価値を検証できる最低限の大きさは維持する。MVP（Minimum Viable Product）と呼ばれる考え方。これより小さい単位でスプリントをやっても、出来上がったものの良し悪しを「システムを作らせる人」の目線で議論できない。その意味でも、FMの1グループを1回のスプリントにするのは合理的。


同時並行でスプリントをするための工夫
スプリントを繰り返す開発手法は、1つのチームがすべて開発する方法が一番スムーズに進む。スプリントを何度も繰り返すということは、前回のスプリントまでに作った機能に、今回のスプリントで作った機能を継ぎ足していくことになる。それをスムーズにこなすためには、両方の機能を知っている人が一番うまく作れる。逆に複数のチームがあると、別チームが作った機能にうまく継ぎ足せず、開発が頓挫してしまう。

だがかけはしプロジェクトは幅広い機能を短期間で構築する必要があったために、複数のITベンダーからなる複数のチームで、同時並行でスプリントを走らせる必要があった。
このため、まずは最初にスプリントを切り分ける際、スプリント間の連携が複雑にならない切り分け方にかなり気を使った。切り分け方の検討には、こういったことを判断できるITベンダーの設計者の方々にも参加してもらった。
また、スプリントで作る機能間のI/F（インターフェイス）機能を重視した。具体的には各チームのエンジニアが集まってI/Fを議論する場を設定した。こういったチーム間のファシリテーションがプロジェクトの肝となるのは、アジャイル的な開発であっても同じだ。


プロトタイプは大事だが、闇雲に作っても無駄
かけはしプロジェクトでは、プロトタイピングも多用した。ECサイトやコンタクトセンターの仕組みについて、パッケージソフトの標準画面や仮に設定した画面を見ながら、検討していく手法だ（プロトタイプセッションについても「システムを作らせる技術」を参照）。
これらは「まだない業務に思いを馳せる」という意味で非常に有効だった。だが一度、プロトタイピングをストップせざるを得ない状況にも陥った。システムの前提となる業務ルールで未定のことがあまりに多く、プロトタイプ以前だと判断したからだ。
この時は一旦作業を中断し、検討すべき課題の全体像を示すマップを作り、領域ごとに致命的な未決事項を特定していった。それらをどんな順番で議論すべきかを決め、毎日、1つ1つ課題をつぶしていった。これらを経て、ようやくきちんとプロトタイピングを再開できた。

このあたりも、まだないビジネスを作る難しさだ。方法論について深く理解した上で、「今回のプロジェクトではどう方法論をアレンジすべきか？」を常に考え、軌道修正していかなければならない。


期限や品質を守るためのマネジメントはいつもと同じく大切
かけはしプロジェクトのような、期限が決まった大規模なシステムをアジャイル的に開発することは、一般的に非常に難易度が高いと言われている。
アジャイルには「意欲に満ちた優秀なエンジニアを集めたら、自主性に任せたほうがうまくいく」という思想的背景がある。顔の見える小規模チームでこの理想通りにいけば生産性はとても高いが、大規模プロジェクトでこのやり方を目指すとチーム任せになりすぎて品質が低かったり、スケジュールがグダグダになりやすい。

一方でかけはしプロジェクトでは、ベンチャーといえども納期や品質には強くこだわった。投資家に約束した出荷スケジュールは死守する必要があるし、ベンチャーだからといってお客様との決済金額が間違っていたら、会社として信用を失うからだ。
そこで、品質や進捗についてはプロジェクト管理チームがきちんと管理をした。このあたりは通常のプロジェクトとなにも変わらない。


優秀なITベンダーに火を付ける大切さ
先にも少し触れたように、アジャイル開発の前提は「優秀なエンジニアがものづくりをすること」。だからITベンダーの選定にはかなり苦労した。結果として、従来型のシステムインテグレーター1社にまるっとお任せするのではなく、SaaSを使いこなす複数のITベンダーに分業してもらうことになった。
SaaSベンダーの方がアジャイル的なプロジェクトに慣れていることもあるし、SaaSはGroove Xが成長してナンボ、というビジネスモデルなので、「伴にビジネスを作っていく同志」という関係を作りやすかったからだ。

最初にGroove XやLOVOTのコンセプトを伝え、「将来に向けて、こんなすてきなことを考えているから、大変だろうけど、一緒に夢を見て欲しい」と、こちらの思いを伝えるプレゼンも、彼らのハートに火を付けるためには欠かせない要素だった。結果として単なる契約関係を超えたプロジェクトチームを作ることができた。

どんなに工夫しても、ツライものはツライ
以上、本書でこれまで説明してきたFMを中心とした方法論に、アジャイルの要素を組み合わせたやり方の利点を説明してきた。しかしベンチャーに特有な、不確実性の大きさがある以上、どんなに工夫しても大変なことには変わりなかった。

例えば、スプリントで小さな機能を作って、業務目線で検討をすると、たしかに課題は早めに洗い出せる。後で致命的な欠陥が見つかるよりはずっとマシなのだが、それらを修正するための時間を確保するのには苦労した。次の2週間には別のスプリントが待ち構えているのだから。
でもそれらを放置して、ビジネスが死んでしまうよりはずっとマシだ。最後は根性も必要だったし、業務とシステムを最後に磨くために確保してあった期間は、ビジネスモデルの大きな変更に対応するために食いつぶしてしまったうなど、全体スケジュールの見直しは何度も行った。

すべてがきれいに進んだわけではないが、想定通りの予算と納期でプロジェクトを完了させ、無事にLOVOTを飼い主のもとに送り届けることができたのは、プロジェクトに参加したすべてのメンバーの情熱と、適切な方法論が噛み合って達成できた、大きな成果だった。

*************
このプロジェクトについては、すでにいくつか記事になっているので、興味を持った方はそちらもどうぞ。

かつてないロボット「LOVOT」が世に送り出されるまでの舞台裏　（ITメディアさんの記事）

人の愛する力を育む家族型ロボット「LOVOT[らぼっと]」の ビジネス基盤構築を支援（ケンブリッジのサイト）

LOVOTが入社して半年が経ちました。 （わが社のあんことしらたまの話）