「伝言ゲーム」的なデータの流れで失敗 内製モバイルアプリ開発で考慮すべきこと：身近になったモバイルアプリ開発

モバイルアプリ開発は容易になったが、エンタープライズ統合には大きなリスクが伴う。従来の垂直統合型システムとは異なり、水平分散型のモバイル環境では、一カ所のサービス停止がシステム全体の崩壊を招きかねない。情シスが決裁すべきは「開発の容易さ」ではなく、分散した依存関係をどう管理し、データの即時性を守るかだ。

[Katie Fenton，TechTarget]

　近年、モバイル活用の取り組みは、アプリケーション開発を大きく変えた。開発者の業務は一部で容易になったが、同時に新たなリスクや課題も生んでいる。

　モバイルシステムは、従来のエンタープライズシステムよりもはるかに迅速に、あらゆる場所からイベントを捕捉できる。適切な判断を下せば、システムの正確性と機敏性は向上するだろう。しかし、判断を誤れば、モバイル開発特有の要因がITスタッフの負担になりかねない。

　『Truth in People's Hands』の著者であるブライアン・チャビス氏は、「IT担当者やデータベースプログラマーにとって、モバイルアプリケーション開発は非常に容易になった」と語る。一方で同氏は、「それらをSalesforceなどの基幹システムと連携し始めたとき、より慎重で厳格な対応が必要になる」と警鐘を鳴らす。

　チャビス氏は著書で、モバイル活用に取り組む前に組織が認識しておくべき落とし穴とベストプラクティスを説いている。同氏は50年にわたりアプリケーション開発に携わってきたが、モバイルプロジェクトに着手した際の劇的な変化に驚いたという。「プログラミング自体は似ているが、異なるシステム同士が相互に作用する方法が変わったのだ」と、チャビス氏はTechTargetに語った。

　本稿では、従来のシステムとモバイルエンタープライズシステムの最大の違いを浮き彫りにし、CIO（最高情報責任者）がモバイルアプリケーション開発にどう向き合うべきかを探る。

モバイルアプリ開発は身近なものに

　モバイルシステムと従来のシステムを分ける決定的な違いは、アクセスのしやすさにある。初心者でもモバイルアプリケーションを以前と比べより簡単かつ安価に構築できるようになった。

　数年前まで、アプリケーションを迅速に開発しようとすれば、外部の開発会社に外注し、リリースまでに何度もプロトタイプの修正を繰り返すのが通例だった。今日、モバイルプラットフォームは広く普及しており、操作も比較的容易だ。

　チャビス氏は、「自社のスタッフがプロジェクトを担えるため、コストを大幅に抑えられる。デザインや機能についての試行錯誤も効率化された」と指摘する。また、「『正常に動作させる』という段階に達するまでは、ドラッグ＆ドロップ感覚で進められる」とも述べた。

　その段階で、CIOやIT担当者は「タイミング」「べき等性（ある操作を何度繰り返しても結果が同じになる性質）」「自動化」といった要素を考慮しなければならない。

モバイルシステムで加速する「タイミング」

　タイミングはモバイルが利益をもたらす領域の1つだが、多くの企業はその価値に気付いていない。チャビス氏によれば、事象が発生した瞬間に記録できることは、システムのセキュリティと機能を維持する上で有利に働く。しかし、既存のエンタープライズシステムの多くは、モバイルユーザーにとって直感的なインタフェースを備えておらず、バックエンドのデータベースに直接情報を取り込める設計にもなっていないことが多い。

　「概念を理解するのは難しいかもしれない」とチャビス氏は言う。現場で何かが起きた「真実の瞬間」には、全ての情報が新鮮だ。しかし、大半の企業では現場の誰かがメールを送り、それを受け取った担当者がスプレッドシートに記入している。そして最終的に、その内容をシステムに入力しているのが実態だ。

　チャビス氏は著書で、この共通の課題を強調している。現場の観察結果が正規のシステムに登録される前に、テキストメッセージやスプレッドシートなどの非公式な経路で記録されてしまう問題だ。情報がこれらの経路を通過する時間が長くなればなるほど、文脈は失われる。チャビス氏はこれを「伝言ゲーム」に例え、最初の観察結果が時間の経過とともにゆがんでいくと指摘する。この問題を避けるには、データを即座にシステムへ入力させなければならない。

　技術的なアーキテクチャもモバイルデータの取得を遅らせる要因になる。大半のエンタープライズシステムでは、モバイルアプリケーションのデータはデータベースに直接書き込まれず、ミドルウェア（異なるソフトを仲介するソフト）を経由する。チャビス氏は、将来的にはCRM（顧客関係管理）などのシステムが、モバイルアプリケーションとデータベースの直接接続をよりサポートするようになると予測している。

モバイルシステムは「水平」である

　もう1つの大きな違いは、従来のシステムが「垂直型」であるのに対し、モバイルシステムは「水平型」である点だ。これがトラブルの原因になり得る。

　従来のアーキテクチャは、サーバ、データベース、ソフトウェアの全てが予測可能な環境で動作する垂直なスタック（積み重ね）だ。対してモバイルアーキテクチャは水平、つまり分散型だ。軽量なアプリケーションから自動化プラットフォーム、企業のデータベースまで、複数の独立したシステムにまたがっている。

　水平型のシステムでは、個々の動的な要素を制御し、一貫した実行を保証することが難しい。内部の小さなシステムの1つで不具合が起きれば、他のシステムに予期せぬ影響を与え、修正も困難になる。チャビス氏は、自動化サービスの支払いに使っていたクレジットカードの期限が切れたことで、パイプライン全体の実行が止まった例を挙げた。

　「昔は1つのシステム、1つのサーバ、1つの会社で全てが完結していた。しかし今では、利用しているサービスの1つでカード決済が失敗しただけで、システム全体がダウンしてしまう。水平型になると、前提条件が全て変わるのだ」とチャビス氏は語る。

　同氏によれば、これは組織がモバイルやノーコードの取り組みを始める際の最大の死角だという。水平型アーキテクチャでは、それぞれ特定の役割を持つ複数のベンダーと契約する必要がある。これがモバイル開発を容易にした要因でもあるが、同時に無数のサービスへの依存を生み、その1つが故障点になり得る。

　この課題に適応するために、CIOやIT担当者はワークフローを簡素化し、分散した責任を慎重に管理しなければならない。「モバイルアプリケーションは安価に開発できるようになった。だが、そこには踏み外しやすい落とし穴が幾つも存在している」とチャビス氏は結んだ。