モバイルコマ―ス事業部のエンジニアリングサービスの御紹介

開発プロセスのイメージ

1. モバイルコマ―ス事業部のエンジニアリングサービス

ナレーター
今回ブックウォーカー様の電子書籍サービスでご採用いただいたITソリューションエンジニアリングサービスについてご教示ください。
佐藤
3つの事業分野に分かれている「ITソリューションエンジニアリングサービス」ですが、今回特にブックウォーカー様で特徴的だったサービスの適用事例について説明いたします。
ナレーター
従来のSIと違う点と、更にモバイルコマース事業部ゆえの違いとはなんでしょうか?
佐藤
従来のSIと違う点は、各事業部でも説明させて頂いておりますが「顧客との立ち位置」でしょうか。いわゆるSI事業は非常にリスクの高い事業でもあります。それゆえにSierはどうしても重厚長大なウォータフォールプロセスに縛られがちでした。
ナレーター
きちんと見積もり立てて、計画を作って実行する。そのためには当然、要件はきちんと事前に決まっていなければならない……ですね。

2. 新サービスは発注者にも要件・仕様は、よくわからない!

佐藤
ええ。しかし、モバイルコマース事業部では、スマートフォンの
様ないわゆるアプリを中心としたデバイス系の開発や、ニュー
サービスの立ち上げにあたっての開発を依頼されることが多いの
です。結果、事前に要件を作り込む事が非常に困難です。なに
せ、最適なサービスの姿は、誰にも分かりません。発注者すら
知らないのです。

オープントーン高田のイメージ

ナレーター
新しいサービスでイノベーションを起こそうという
顧客なら当然の帰結ですね。
佐藤
その点、モバイルコマース事業部では、
特に「御客様も手探りである」という
前提で対応をしています。金融・業務
ソリューションに比較してより顧客の
求めるビジネスのスピードが速く、
先進的であるためです。
ナレーター
しかし、それではプロジェクトの発注のしようがありませんよね?できあがるものの姿が誰にも分からないなら、結果として、その費用も分からない。ビジネスとしては致命的では?
佐藤
従来のウォーターフォールだとそうですね。実はウォーターフォールはなによりSIベンダー側のリスク低減の仕組みであることをおわすれでしょうか? そこから抜け出してしまえば実は、顧客とってもよりよいサービスが提供できるのです。
ナレーター
従来の要件決め、見積もり、発注、受注、設計、開発、テスト、納品……の仕組みではないと?

3. 新サービスを生み出すための、新時代のIT開発支援サービス

佐藤
実際に開発する作業自体が変わるわけではありません。ただし、大枠を大きく変えています。具体的に今回の事例では「リソース供給契約」を締結しています。3人のチームならチームを維持する体制を提供すると言う契約です。
ナレーター
SES(システムエンジニアリングサービス)契約に近いでしょうか?
佐藤
そうですね。常駐はしていませんが。非常駐のSESに近いでしょうか。
ナレーター
そうすると顧客には、お金を払っているのにちゃんと成果を上げているか分からないという不安感と、最終的に完成するまで幾らかかるか分からないという問題がありませんか?
佐藤
そこなんです! まず、「お金を払っているのにちゃんと成果を上げているか?」ですがもともと月単位の契約です。長くても1Q単位の契約ですので、成果が納得できなければ解約は簡単です。
よく考えてみてください。1億の受発注を何度も何度も契約を見直して長い交渉を掛けて締結すると、リスクの上限は1億に限定されますが、実は下限も一億になってしまっています。
ところが、この「リソース供給契約」であれば「中止!」と思った時にはせいぜい数百万の出費になります。実はリスクは非常に小さく抑え込めているのです。
ナレーター
なるほど。「もともとイノベーションを起こしたい!」と顧客が思う以上「何を作ったらいいかはだれも分からない」わけですから、リスクを固定化してしまう方が実はリスクが高いということになる……というわけですか。

4. 失敗は成功の母。機能は、どんどん開発してどんどん捨てればいい。

佐藤
それだけではないのです。こうした、先進的なサービス開発を行うとする場合「機能を捨てる」事も大切な要素になります。ユーザーニーズが分からないところにリリースするわけですから結局「使われない機能」等は多々出てきます。 その際に、先に「こう作るんだ!これは1億だ!」と決めてしまっていると、その1億を捨てる事はできなくなります。結果、無理やり作って、誰も使わない機能を、使ってもらえるようにさらに御金をかけ開発を続ける……というジレンマに陥るのです。
ナレーター
ところが、元々数百万のリソースで「試しに作ったもの」であれば、さっさと響かなければやめて、次の響きそうな機能に着手すれば良い……となるのですね。
佐藤
はい。結局、そうしてユーザーの反応を見ながら、どんどんアプリケーションの姿を変えていく……それが、サービスの開発競争ということなのです。そして、サービスの開発競争が続く限り、どんどん機能追加……投資を続ける。そしてそれ以上に回収をする……事になります。
ナレーター
なるほど。つまり、最初に机上で設計し抜いて、1億でこのサービスを作って、10億稼ぐぞ! という考え方の方が間違っているということですね?
佐藤
ええ。その1億のサービスが10億稼ぐかは机上の空論です。実際そうなるかは、発注者にも分かりません。であれば、数百万ずつ機能を試しながら、10億稼ぐサービスを目指す方が、よほど現実的です。結果として、投資は2億になるかもしれません。逆に5000万で済むかもしれません。でも机上の空論だけで、サービスを構築するよりはよほど現実的です。それに、もしかしたら「やっぱりこのサービスダメだね」という決断も早ければ、ごくわずかな投資だけで済みます。
ナレーター
なるほど、しかも、リスクを固定化したはずの請負契約で1億で受発注したシステムが1億で済まないこともよくありますね。
佐藤
そうなんです! 300mずつ、目的地を確かめながら10km先の目標に向かうオリエンテーリングと、まず机の上で想像で、自分達で地形や主催者の性格を推し量り、そこで決めた目的地に一か八か最初に10km歩いてゴールを探すオリエンテーリングではどちらが結果として早くゴールに着きますかね。最初の10kmは真逆かもしれない。そしたら、最短でも20km歩かないといけないのです。
ナレーター
つまり「ちゃんと歩いているか分からないから、この10km先の地点まで歩いたら幾らね」と契約して開発するのが従来の方法ですね。逆に、目標に向かって一緒に300mずつ歩いては地図を確かめ、ヒントをさがして一緒にゴールに歩こうというのが「リソース供給契約」の形ということですね。しかし、それなら、常駐型のSESの方が情報共有という観点では早いのでは?
佐藤
それも意外に、そうではありません。一般的に、常駐型は実務に様々な制約が出ます。開発会社内は本番環境もなく、本番データも所有していないこともあり、開発の環境の柔軟性が非常に大きいのです。
つまり、サービスベンダーである顧客にとって、セキュリティやコンプライアンスリスクは非常に重要な要素です。ですから、社内でも使えるツール等が厳しく制限されていることが多いのです。それに、そもそもSIベンダーでもない顧客企業の中には様々な効率化ツールがありません。
ナレーター
なるほど。いわば、専門の会社でない顧客企業には、重機などが無くて、備え付けのスコップで作業しなければならないから概ね非効率になる……ということですか?
佐藤
はい。それに、当社には膨大なプロジェクトノウハウもあります。そうしたノウハウはそれこそ、御客様先では制限されてしまいます。似たようなプロジェクトの設計図書や、同じような事例の実装例など……
ナレーター
なるほど、それでリソース供給契約なのですね。
ブックウォーカーイメージ

5. これからのモバイルコマース事業部におけるソリューションエンジニアリング

佐藤
デバイスやWebの技術は更に加速度的に進化しています。今日全盛を極めるスマートフォン等は、もしかしたら2-3年後には全く違うデバイスに置き換わっているかもしれません。
そうした、スピードに対して、ベンチャー特有の機動力と技術力で顧客のサービスのイノベーションを支援していきたい次第です。どんな産業であれ、競争と競争に伴う技術革新は常に避けられません。
我々のIT技術力で顧客の皆さまの「まだ見たことない新しいサービス・機能」を形にしていけるように、更にノウハウの蓄積とスピード、そして最新技術の研鑽に努めていきます。

次へ進む

開発のご依頼・システム導入のお問合わせはこちらから

インタビュー企業様一覧

  • 日揮株式会社様
  • 楽天銀行株式会社様
  • フェリカポケットマーケティング株式会社様
  • 株式会社ブックウォーカー様
このページのトップへ

金融システムやさまざまな業務システム開発、ECサイトなどの各種Webサイト構築・開発、IC(RFID)を活用したシステム、技術者向けOJTやICタイムリコーダー等、システム開発に関わることならオープントーンにお任せください。