Special
» 2016年03月31日 10時00分 UPDATE

クラウドインフラがコモディティ化した今:フツーのWeb系受託企業がB2Bで急成長を遂げた秘訣に見る、業務アプリエンジニアの生存戦略

クラウドを活用したシステム受託開発を中心に業績を伸ばす注目の企業、フレクトの事業戦略から「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方や、手法をITアーキテクトの視点で考察したい。

[PR/@IT]
PR

UIデザインからバックエンドまで全て受託することを強みにできた理由

 クラウドによって誰しもが大量のコンピューティングリソースをすぐに使える時代になり、開発・運用エンジニアにおいても「技術を実際のビジネスサイクルの中でどう効率良く、かつスピーディに生かすか」が重要視されている。そのために必要な技術や手法にも目を向けることによって、エンタープライズにおける、あるべきアーキテクチャ設計が見えてくる。

 本稿では、クラウドを活用したシステム受託開発を中心に業績を伸ばす注目の企業、フレクトの事業戦略から「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方や、手法をITアーキテクトの視点で考察したい。

CRMやSFAをスクラッチで開発するには多大なコストが掛かる

 システム受託開発というと、よく聞くのは全体のアーキテクチャ設計だけ行い、プログラミングやデザインは下請けに任せる企業だ。フレクトは、B2B、B2C向けアプリケーションのバックエンドをクラウドベースで開発する他、B2C向けWebサービスのUIデザイン、さらにこれらを内包するシステム全体のアーキテクチャ設計も手掛け、最近はIoT分野に挑戦の幅を広げている。

sfdc2_1.jpg フレクト 取締役 クラウド事業部長 大橋正興氏

 2005年に創業した当時はリクルートに常駐してWebサイトの開発に携わっていたが、自分たちのカラーが出る仕事をしたいと模索する中で出会ったのが、セールスフォース・ドットコムのForce.comだった。

 刻一刻とニーズが変化するWebサービスにおいて、その裏で動くCRMやSFAをスクラッチで開発することは大きなコストが掛かる。これについて、フレクト 取締役 クラウド事業部長の大橋正興氏は次のように述べる。「例えば、現在は売上を見られるが、来月からは利益を、再来月には顧客の行動や満足度を見られるようにしてほしいといったニーズに対し、スクラッチで迅速かつ臨機応変に対応するのは厳しい。どんなにシンプルで小さいサービスであっても、CRMやSFAは最低限必要となり、大規模サービスと同様の機能を一通り用意する必要がある」。

インフラやミドルウェアなどの非機能要件にはパワーを割かず“付加価値”を重視

 同社は、既にCRMやSFA向けに多数のコンポーネントが用意されているForce.comをうまく活用している。足りないところはAWSやHerokuなどのクラウドの組み合わせでカバーし、さらにエンドユーザー向けUIデザインの開発も含め自社で対応。これらを一括受注できる付加価値を打ち出した結果、一気に業績が伸びた。この“付加価値”は特に事業展開が速い企業や新規事業と相性が良く、そういう案件を意識して「選択した」という。例えば、グリーの業務システムやシックス・アパートの新事業などForce.comによるシステム構築の事例を持つ。

 「UIデザインからバックエンドまで全て引き受けるからこそ、作業負担を軽減するために、インフラやミドルウェアなどの非機能要件にはパワーを割かない方針を採った。Force.comは、業務システムの権限管理やセキュリティなど各種機能がそろっている。その活用で工数が削減できる分、UIデザインや、実装する機能によりAWSやHerokuなどの他のクラウドと組み合わせることで、他社と差別化できる」(大橋氏)。

sfdc2_2.jpg CloudMix+Designがフレクトの強み

業務システム開発に必要な学習コストを削減するためには

 また、フレクト クラウド事業部 チームマネージャーの佐伯葉介氏は「Web系で開発していた人間にとって、業務アプリを開発する際のツールはForce.comがとっつきやすかった」と明かす。

 「業務システムにおける権限管理やアクセス権管理、ワークフローなどの要件定義は難しくなりがちで、通常、要件定義に必要な知識を得るだけでも数年かかる。RubyやJavaScriptといったネット系の技術に精通してきたエンジニアにとっては、業務システム開発に必要な知識を一から学習するのは容易ではない。その面を簡素化できるという意味で、アプリケーションエンジニアとしてのファーストステップとして、Force.comは最適なプラットフォームだと思う」(佐伯氏)

進化が加速した分野と隣り合う分野の“境界”に商機あり

コモディティ化した分野間のボトルネックとは

 フレクトの事業開発ポリシーは、「名前が付いた分野の進化は加速する」という考えが裏にある。例えば、「JavaScriptを極めたい」という人はいても、「使いやすいUIを極めたい」という人はかなりの少数派。「信頼性、安定性、セキュリティを維持して、開発、テスト、運用のサイクルを速く実現できるエンジニアを目指してほしい」と言われても何だかピンと来ないが、そこに「DevOps」という名前が付いた瞬間、「DevOpsエンジニア」を目指したくなる。

 つまり、名前が付いた瞬間、誰にとっても分かりやすくなり、そこには人が集まり、進化を極め、コモディティ化は加速する。コモディティ化の加速は、該当分野における生産性の向上などの大きなメリットをもたらす一方、コモディティ化した分野と隣り合う分野の“境界”に新たな問題を発生させる。

 例えば、オンプレミスが主流だった頃、Webアプリケーションの開発はフレームワークが登場したことで非常にアジリティが高くなった。一方で隣り合うインフラのアジリティは低いままなので、アプリケーション側でブレーキを踏むことになり、期待しているスピードでWebサービスを手に入れることができないという問題が発生していた。クラウド技術の登場により、アプリケーションを作るスピード、インフラを作るスピードの両方が格段に向上したため、双方の間に存在するスピード格差の問題が解決されたのである。

sfdc2_3.jpg フレクト クラウド事業部 チームマネージャーの佐伯葉介氏

 そうなると、次に問題になるのはデザインとクラウドの境界にあるスピード格差であることは容易に予想できる。そこで、フレクトでは自社内にデザインも取り込み、通常発生するデザイン会社との調整や契約といった面倒な手続きを取り除き、一気通貫でアジリティの高いサービスを顧客に提供できるようにした。

 それは、顧客が価値と感じるところの変化にも呼応した。「例えば、これまでのシステム開発企業は従来の業務フローをトレースしただけのシステム環境を構築するのでも十分だった。しかし、クラウドのプラットフォームが普及したことでシステム環境を構築は当たり前の価値となり、デザイン性も含めてサービスを構築できるとか、顧客と一緒にサービス企画の試行錯誤ができるとか、その先にある、ビジネス拡大という価値を提供することが求められるようになった」(佐伯氏)

将来のITビジネス拡大にはプラットフォームの選択が重要

 こうした新しい“境界”への取り組みを継続していくフレクトにとって、システム構築の基盤として活用するプラットフォームは何でもいいというわけではない。

 「将来のビジネス拡大を考えたとき、将来性がないプラットフォームを使ってはダメだ。将来も確実に進化し続け、デファクトになり得る、進化し続けるプラットフォームを選ぶこと。われわれが新しい分野へトライをしていったときに、過去に選んだプラットフォームが将来の足かせになることは好ましくない」(大橋氏)

 そんなデフォルトとなるプラットフォームでB2B向けなのは、「今のところForce.com一択」と大橋氏は断言する。「Force.comの魅力は、アプリケーションレイヤーからデータ、ランタイム、OSまで、PaaSの全てを網羅している点だ。またセールスフォース・ドットコムが、『クラウドの未来は。こうあるべきだ』というビジョンに基づきPaaSのビジネスを進めていると感じ、とても共感した」。このビジョンが「将来性があるかどうか」の判断基準の1つだったという。

 佐伯氏も「オンプレミス製品をクラウドに載せただけのサービスがコモディティ化していく中で、Force.comはその先に必要になると予想される機能を徹底的に強化しており、エンジニアとしても啓蒙されるところがあった」と明かす。

IoTサービスといえども、重要なのは技術の選定と全体の設計、そして顧客価値の提供

 コモディティ化した分野と隣り合う分野の“境界”における格差を埋めるべくフレクトは最近、注目が集まるIoT分野にも目を付けた。しかも、受託開発ではなく自社サービスとしてだ。これにも、Force.comとHerokuというプラットフォームを選択したことが功を奏しているという。

 同社が最近提供を開始した「Cariot」は、自動車の位置情報や速度、燃費、エンジン負荷、速度、累積走行距離、燃料残量レベルといった情報をクラウドに収集し、これらを利用したアプリケーション開発に役立てることができる。「Cariotアプリケーションは、営業車両日報を自動作成するものや、位置情報から荷物の積み下ろし状況や法令順守を可視化、管理するものなど、用途が幅広い」(大橋氏)。

 IoTサービスを開発する際に重要になるのが、センサーを搭載するデバイスの選択、センサーから吸い上げたデータの収集基盤の構築、収集したデータを分析する基盤、分析したデータを基にした迅速なアプリケーション開発、それら全体のアーキテクチャ設計だ。

Force.comとHerokuの使い分けとAPIで柔軟なサービス化のステップを実現

 データの収集は、SIMを搭載したOBD2(On Board Diagnostics second generation:自己故障診断)デバイスを車両に挿すだけだ。バックエンド部分はAWS上にデータ収集・分析基盤が動いていて、CariotアプリケーションからAPIでさまざまなデータを取得できる。

 フロント部分のCariotアプリケーションの構築には、Force.comを使っている。それは、やはり「あまりプログラミングしなくても、むしろプログラミングしなくても顧客体験の部分を構築できるから」という前述した理由からだ。実際Cariotでは、「2週間だけのシャトルバス運行管理アプリケーションを短期で構築したい」といった案件も既にあると大橋氏は言う。

sfdc2_4.jpg API+Salesforceでバス運行管理システムを短期構築

 また、このバス運行管理アプリケーションは、リアルタイムナビゲーションやユーザーがバスを予約する部分、いわばコンシューマー向けの部分にHerokuを活用している。Cariotに限らず、B2Bの部分はForce.com、B2Cの部分ではHeroku、と柔軟に使い分けるのが、同社の典型パターンだ。

 大橋氏はHerokuについて「大量データをさばくのが得意で、コンピュータ処理能力が求められるサービスでは採用している。また、性能監視や稼働監視、CDN、メールやプッシュ通知など、コンシューマー向けサービスに必要な、しかもかなりハイレベルなアドオンが充実しているので、特に手を加えなくても組み合わせだけで良いアプリが開発できる」とし、B2Cサービスに最適と評価する。

IoT開発で最も重要なのは、集めたデータを基に「どのような価値を顧客に提供するか」

 このような技術やアーキテクチャで開発されたCariotだが、そこで重視しているのは「どのような価値を顧客に提供するか」だ。

 そのために同社は、簡単な紙芝居レベルのプレサービスを構築、展示会などでセールスする。その後、展示会で興味を示してくれた顧客の協力の下、実車で最小限のサービスを構築、実験。納得できてから本番サービスとして実展開する。いわばリーンスタートアップを実践している。

sfdc2_5.jpg サービス化に向けたステップ

 またIoTシステムの構築というと、デバイスが持つ機能を基に提供するサービスを考えてしまい、「これも入れられる」「あれも入れておいた方がいいかも」となって、結局は全て盛り込んだ重厚長大なシステムができてしまう危険性がある。しかし、IoT開発で最も重要なのは、データを集めることではなく、集めたデータを基に「どのような価値を顧客に提供するか」だろう。

 その点Cariotの場合は、例えば、シートベルトの装着有無や急ハンドルに関するデータも取得可能な高機能なデバイスも検討していたが、顧客のニーズの少なさから判断して不要とし、シンプルなデバイスを選択。アプリケーション機能の開発工数削減につなげ、しかも顧客価値の提供につながっている。

これからのエンジニアに求められること、あるいは生存戦略

 ITシステムやサービスによって顧客価値の提供を続けていくには、技術力があり顧客が求める価値を提供できる人員をそろえることも重要なのは言うまでもない。機敏性と柔軟性が魅力のフレクトが求めるエンジニアは、「1人につき最低限2つの能力を備えている人物」と大橋氏は言う。

技術しかできないのは、不十分

 「まだ今後のアイデアレベルの話だが、Force.com、AWS/Heroku系、先端技術、ファシリテーション、マネジメントのうち2つ、ないしは3つを満たせることをエンジニアの目標指標にしようと考えている。例えば、機械学習とForce.comをマスターするならば顧客との対話に参加しなくてもいいが、AWSやForce.comだけであればファシリテーションかマネジメントのどちらかをやるといった具合だ」(大橋氏)

 技術しかできないのは、不十分と考える。それは薬品や手術器具に詳しいが、どこを切除すれば病気が治るか分からない手術医のようなものだと大橋氏は例える。「全てを一人で網羅できるわけではないが、コンパクトなチーム体制を是としているので、最低限2つの能力を身に付けながら、互いを支えて強化できるのが理想だ」

技術知識は確実に身に付けて、ブラッシュアップ

 一方で、技術知識は確実に身に付けて、ブラッシュアップすることは必須だ。これは「単にIT企業だから」という理由だけではない。要件を出す顧客側には十分な技術知識がないのは当たり前で、開発側が技術知識をきちんと担保できなければ最適なシステム開発が実現しないからだ。「例えば家を建てるとき、発注側が細かく設計を指示できないのと一緒だ。発注側が、よく分からずに要望を出し、それに対して何も説明せずに建てられた家は、発注側が希望するトイレが運び込めない構造だったと後から発覚して取り返しがつかないこともあるだろう」(大橋氏)

 同様に、顧客はIoTというキーワードは知っており、ビジネスで生かしたいと考えているが、車とSIMの関係が分かっていなかったり、クラウドの知識がなかったりする。その不足部分を丁寧に説明し、実現可能なことを示すことができるエンジニアは、それを教える責任があると大橋氏は言う。

 「今は、クラウドなどのデジタル技術を周知しているエンジニアが顧客をリードできる世界となった。だからこそ、勇気を持ってリードしてほしい」。

Copyright© 2017 ITmedia, Inc. All Rights Reserved.


提供:株式会社セールスフォース・ドットコム
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2016年4月30日

特集

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。