Mark's MIC :  開発手法の「アジャイル化」が作り出す、優れたカスタマージャーニー

こんにちは、マネーツリーのマーク・マクダッドです。今回は弊社のスマホアプリ(スマートフォンアプリケーション)「Moneytree」の開発にまつわる話をさせてもらおうと思います。

話は2012年にさかのぼりますが、当時はMoneytreeのサービスをリリースするまでのタイムライン(予定表)があり、2013年6月リリースを予定していました。しかし、実際にローンチしたのは予定より早い4月25日でした。皆さんは「開発が早く終わった」と思うかもしれませんが、実際には、当時実装予定だった機能を見送ってリリースしました。

このリリースを早めた理由は多岐にわたりますが、その1つが資金調達です。ベンチャーキャピタルから投資を受ける際は、一定の仮説を用意し、検証結果を提示して出資してもらうのが常です。我々は、開発中のMoneytreeのデモ版で金融機関を登録し、口座情報を表示する様子を投資家に見せましたが、「日本人は、このサービスは使わないのでは」といった悲観的なコメントを頂きました。

しかし、我々には自信がありましたし、実際に使われるかどうかは「リリースしてみないと分からない」と考えていました。そこで前回の資金調達で投資してもらったお金があるうちに、予定を前倒しにしてアプリをリリースするという判断に至りました。リリースすれば、「ほら、これだけの人がMoneytreeを使ってくれています。なので追加の投資を」と言うことができるという極めてシンプルな理由からでした。

スケジュールが神のようになり、誰もソフトウェアに愛を持てなくなる

このような早期リリースが何故可能だったのでしょうか。それは、開発の手法にあると思っています。要件定義から設計、開発と進める「ウォーターフォール型」ではなく、我々は事前に最小限の機能だけを厳しめのスケジュール設定をして開発する「アジャイル型」の開発手法を採用していました。

この際に感じたのが、ウォーターフォールだと目的と手段が逆になりかねないという点です。ウォーターフォールの場合、基本的に仕様書の通りに作っていくので、途中で仕様を変更した方が良いと気づいても、誰も否定できなくなります。スケジュールが神のようになってしまうのです。スケジュールを優先するあまり、開発プロジェクトの参加者もソフトウェアや個別の機能に愛を持てなくなります。

あくまでも個人的見解ですが、これは多くのウォーターフォール型開発が陥る状況と言えるのではないでしょうか。もちろんウォーターフォール＝悪ではありません。金融機関関係者とお話していると、堅牢(けんろう)なシステムに対する気配りや用意周到さなど、素晴らしい部分も多く、いつも勉強させてもらっています。

綺麗な仕様書ではなく、ユーザーにとっての価値や本意を組み上げることが重要

しかし、金融機関が開発するものがソフトウェアであった場合は、この従来の開発手法は適切でないと感じます。例えば、リリースタイミングを決める際の判定基準について考えてみます。アジャイル型開発ではステークホルダー(利害関係者)の判断となりますが、ウォーターフォール型開発では、デザイン一つを取っても、顧客の声を直接聞かない「関係者」が多く介在します。表現を変えれば「調整者」でしょうか。すると連絡網が増え、確認作業に従事しなければならず、リリースタイミングを決めるのが難しくなります。

他方でアジャイルは小さな仮説(機能)の検証サイクルを短期間で回す開発手法です。部分的には反復型開発とも呼ばれています。綺麗な仕様書を作成するのではなく、本当にユーザーにとって価値あるものは何なのか、そして使いやすさなども含めたユーザーの意見をくみ上げることがアジャイル型開発の本質です。

アジャイルの歴史を少し説明すると、90年代に登場した、迅速かつ適応的にソフトウェア開発を行う手法を指すエクストリーム・プログラミング（XP）から始まっていると思います。難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法で、事前計画よりも柔軟性を重視するのが特徴です。ケント・ベック氏が提唱し、書籍（エクストリームプログラミング）を発表しています。ベック氏は、アメリカの自動車メーカーで新しい給与システムのソフトウェアを作っていましたが、何年経っても開発されなかった経験からエクストリーム・プログラミングを作り出したと言われています。

話を我々の創業当時に戻しますが、Moneytreeではアジャイル型開発に不可欠な仮説の検証を行うため、ローンチ前に50名ほどのテスターに集まって頂き、ベータテストを行いました。現在はベータテストを行うのに、するという特別な手法でベータアプリを試して頂きました。

ベータテスト中、僕は無言でテスターのアプリの使い方を観察し、場合によっては録画することもありました。今でも印象に残っているのが、テスターに、頭に思い浮かんだことを発言してもらうテストです。「次の操作が分からない」「これを押してみるとどうなる?」といったテスターの声をフィードバックとして取得し、UX(ユーザー体験)が想定通りに実現しているかを判断します。ベータテストの結果は、商品開発チームと共有し、デザインの修正・開発を行いました。

‍

顧客の意図や要求の断片を組む「ユーザーストーリー」の作成

世間でよく言われるのが「アジャイル＝中途半端」です。金銭を扱う金融機関用アプリが中途半端であってはなりません。

けれど、コスト削減には、MVP(Minimum Viable Product: 実用最小限の製品)的手法を用い、数カ月や半年など限られた期間で顧客の需要に基づく機能を構築する必要があります。多くの機能を備えた立派なサービスを1年後に提供するというような方法は、日本人の良さが悪い方向に出ていると言わざるを得ません。

マネーツリーでもウォーターフォール型開発の案件をいただく時もあります。その場合、弊社の開発者は要件定義書に沿って開発に取り組めば済みます。しかし、そのような状況でも、弊社の開発者が最初にやるのは、顧客の意図や要求の断片を汲み取り、「ユーザーストーリー」を作成することです。例えば、アプリ利用者が目的を達成するために新規登録を行うといったストーリーを作成し、達成するまでにどのような体験をするかを考え、それに基づいて実装を行なっていきます。

一般的にウォーターフォールは、利用者の目的に応じた画面単位で設計を行いますが、アジャイルはそうではありません。アジャイルに慣れていない人は、画面がないと理解できないという人もいます。しかし、ソフトウェアの目的はアプリやサービスを通じた利用者の目標達成であることを忘れてはいけません。画面ではなく、利用者がアプリで何をしたいのかを想像すればいいのです。そう考えれば、利用者が目的を達成するには何をしないといけないのか、そしてその為に必要な機能は何なのかが自ずと見えてくると思います。このような方法で要件定義をすればウォーターフォール型開発のままでも、アジャイルの最も重要なエッセンスである「ユーザーストーリー」を組み合わせ、ウォーターフォール型開発の欠点を補うことが可能になるでしょう。

顧客の需要に基づく機能を作る具体的な方法としては、問題がある場合に、5回ほど何故を繰り返し要因を突き詰めていく方法があります。これは新しい開発手法である「リーンスタートアップ (Lean Startup）」にも記載があります。日本語でいうと「なぜなぜ分析」のようなものでしょうか。この方法で機能を突き詰めていくと、特定の機能がないとユーザーが離脱する、とかこれがないとお金が入らないなど、利用者メリットではなく、関係者の事情によるものも多くあることに気づくでしょう。また、ソフトウェアでは、何かを作る前に、どうしてこれを作るのかを自問自答しながら始めるべきだという考え方を、どこかで読んだこともあります。

‍

変化や競争が激しい環境で、ウォーターフォールでは競合他社に追従できない

開発手法を完全にアジャイル化すると、常にPDCA(計画・実行・評価・改善)サイクルを回すことになるため、開発に終わりはありません。経営層としてはリソース投資の判断を常に求められます。

ウォーターフォールの場合は「初期投資はいくら、開発・運用費用はいくら」という考えになりますので、仕様書レベルで見積もりが可能ですが、リリース後の仕様変更は難しくなります。もちろん勘定系システムなら構いません。しかし、スマホアプリの場合はOSのバージョンアップに対応したり、新機能を月1単位で実装したりするのは珍しくありません。変化や競争が激しいソフトウェアの世界で、ウォーターフォール型の開発をしていては競合他社に追従できないでしょう。

ウォーターフォールの弱点は工数をあらかじめ設定していることです。仮に予定した工数で要件を満たせなかった場合、予算追加やスケジュールの延期は避けて通れません。しかし、金融機関にとって当初設定した予算を超えることは非現実的です。SIer(システムインテグレーター)はそのリスクをあらかじめ理解していますので、その分も見積もりに含まれることになります。なので、初期投資を抑えながら、ユーザーの反応を見てPDCAサイクルを回し、適切な工数で柔軟に開発を進めていくアジャイル型は金融機関にも合っているのではないでしょうか。

また、ウォーターフォールで落とし穴となるのが、発注するタイミングでしょう。仕様書が大まかに固まった時点で、SIerは人的リソースを投資し、金融機関側も行員が時間を割いて仕様書をブラッシュアップさせます。つまり、未発注の段階でも人的・金銭的リソースを割いているのです。他方でアジャイルの場合、あくまでも顧客需要に沿った最小限の単位で開発が進むため、時給ベースで開発が始まり、いつでも終結させて構わないという立ち位置で進みます。ここが日本の金融機関にはないアジャイル独自の考え方ではないでしょうか。

ただ、金融機関のソフトウェア開発予算は7割が保守に回り、3割が新規事業に割り当てられます。となるとウォーターフォールの大型チャネル開発も容易ではありません。しかし、パブリッククラウドの浸透によって、新規ビジネスを試行する環境が整いつつあります。既に大手銀行はソフトウェア開発企業を傘下に持ち、挑戦を重ねてきました。非銀行系企業が金融機関の基幹システムを借りて業務を行うようなプレーヤーが参入する流れは今後も加速します。

‍

技術環境が整うことで、「優れたカスタマージャーニー」の実現は可能

1つ感じるのは、日本のソフトウェア業界自体が市場性を意識した構造を備えていない点です。金融業はマーケティングを切り離していた時期があり、企業の意思決定基準を顧客に置けていないことが多々あります。つまり、非カスタマーセントリック(非顧客中心主義）なのです。顧客視点に立って「顧客にどのような体験をしてもらいたいのか」を突き詰めると、必要なサービスやマーケティングターゲットが見えてくるのではないでしょうか。

これまでは、どこも"金太郎アメ"的に右を見ても左を見ても同じようなサービスを提供しているため、顧客は「近ければどのサービスでも良い」という判断に至らざるを得ませんでした。しかし、現在のように技術環境が整ったことで、「優れたカスタマージャーニー」の実現は可能でしょう。従来の金融機関の枠組みとは異なる視点で見てみると、銀行と顧客のタッチポイントとなるところはまだまだ多いと感じます。銀行APIを使うことで、我々が新たなタッチポイントを開拓できると感じています。

私事ですが、最近Echo Show(ディスプレイ付きAmazon Alexa)を購入しました。以前のスマートスピーカーも使っていましたが、ディスプレイが追加されたことで、できることの幅が広がりました。あくまでもアイデアレベルですが、例えば金融機関が口座維持に年1万円の費用を利用者に請求し、その1万円でEcho Showを顧客先に届け、Echo Showでも預金残高通知や振り込みができる機能を提供するなら顧客も喜ぶのではないでしょうか。

行員の方とお話しすると「アイデアが出ない」と言われます。身の回りに目を向けるとアイデアは多数存在し、それを自行の金融サービスに適用できる方法は枚挙に暇がありません。そして、今はそれを考え、試すことが可能になった時代と言えるでしょう。マネーツリーは多数のアイデアを持っており、金融機関のソフトウェア開発支援が可能なチームです。是非ご相談ください。