良品計画に見る、ビジネス部門主導のAPIベース開発がもたらした効果と教訓：「7割主義」でスマホアプリ開発期間を5カ月に圧縮（2/3 ページ）

従来型アプリケーション開発における3つの課題とAPIベースの開発による効果

　今回、APIベースで新たな開発プロジェクトが進められたことには、もう1つ背景があった。それは、従来のアプリケーション開発が持つ課題を解決することだった。

　濱野氏が、従来のアプリケーション開発でありがちな問題としてまず挙げるのは、これまでさまざまなシステムの開発プロジェクトを主導してきた情報システム部と、経営トップやマーケティング部、あるいは業務部門との間に存在する認識のギャップである。

　例えば、経営トップは「攻めのITだ！」と安易に号令を掛けがちだが、情報システム部からすれば、「実際に何をしてほしいのか分からない」という言い分がある。また、マーケティング部は「何で、こんなことに時間もコストも掛かるのか？」と言うことがあるが、情報システム部からすれば「安定性を確保することも重要だ」という言い分がある。

　さらに、商品部や販売部、カスタマーサポートなどの業務部門も「実現が遅い！」「思った通りじゃない！」「PC壊れた！」といった苦情を言うことがあるが、情報システム部からすれば、「きちんと要件を提示してくれないからそうなってしまうし、そもそも情報システム部はPCのサポート部門ではない」という言い分がある。

　こうしたギャップは、なぜ生まれてくるのか。濱野氏は、従来型のアプリケーション開発のアプローチには、一般的に「スピード」「コスト」「技術的負債」の3つの課題があると指摘する。

スピード

　まずスピードに関しては、最初から100％の完成度を求めてしまうことが、遅れが生じる原因になるだけではなく、業務現場の要件を言語化できないまま開発を開始することも、手戻りを発生させ、遅れが生じる原因になる。これでは、たとえアジャイルといった新しい開発手法を採用しようとしても、なかなか要件を確定させることができず開発に着手するまでに時間がかかってしまう。

　新システムに関しても、濱野氏は「良品計画は回転が速くて安価な商品を数多く扱う小売業であり、システム開発のための時間も予算も限られていたため、開発にはかなりのスピード感が求められた」と当時を振り返る。

　ところがAPIベースの開発によって、基本設計からわずか5カ月という短期間でMUJI Passportアプリ開発を完了し、リリースにこぎ着けた他、既存のネットストア会員とMUJI Card会員をアプリ提供のタイミングで即座にMUJIマイルサービスへスムーズに移行することに成功した。また、APIによるポイントの外部連携を実現し、ポイントの外販を2カ月程度で実現している。

　具体的には、MUJIマイルサービスのうちトランザクション処理系システムと、MUJI Passportアプリの開発を開始したのは2013年1月のことであり、わずか5カ月後の5月にはMUJI Passportアプリのver1.0をリリースし、MUJIマイルサービスの運用開始にこぎ着けている。その後、サービスの運用を行いながら同時に画面系の改修を進め、2014年9月にはMUJI Passportアプリのver2.0をリリースしている。

　一方、MUJIマイルサービスのうち分析処理系のシステムの開発を開始したのは2013年6月と、こちらも7カ月で導入を完了している。その進捗を詳しく見ると、分析基盤のPOC（Proof of Concept：検証）は2013年6月に開始して2週間で終了。Amazon Redshiftを使ったDWH基盤は、9月に開発を開始して1カ月で導入。Tableauを使ったアドホック分析とTreasure Dataを使ったデータ管理は、10月に開発を開始して1カ月で導入、データモデルの改良とダッシュボードの作成は10月に開始し2カ月で完了している。

分析処理系システム構成（濱野氏の講演資料より）

コスト

　コストに関しては、費用対効果に見合うかどうかを的確に判断できないまま開発に着手してしまうと、「アプリケーション開発の見積もりが正しいかどうか」を判断することができず、コストが膨らむ原因になる。

　濱野氏は、「APIベースの開発アプローチの採用によって、新システムの構築コストは、一般的なポイントカードシステムに比べてかなり低く抑えることができた」と胸を張る。また最近では、店舗で購入する顧客のうちMUJI Passportアプリを提示する割合が3割に達するようになるなど、投資対効果のアップにも貢献できているとしている。

技術的負債

　技術的負債に関しては、一度作ってしまったアプリケーションが後で刷新することが困難になり、そのまま使われなくなって放置されてしまったり、老朽化してしまったりして、負債化するケースも見られるという。

　これについても、APIベースの開発を採用した結果、例えば、MUJI Passportアプリをリリースして1年後にUI（User Interface）の全面改修を断行した際に、サービスに影響を与えることなく改修作業をスムーズに進めることができた。また、サービスを追加・改修・削除する作業に関しても、API単位で容易に行うことが可能になった他、システム構成をAWSを併用できる環境に容易に移行できたという。