"エンタープライズモバイルならでは"の開発体制とは?

前回、エンタープライズモバイル開発における繰り返し型の開発プロセスやユーザーレビュー時のポイントなどについて紹介しました。それらを踏まえ、今回は外部の開発会社を含めた開発体制について説明します。

容易に複数社による分業体制がとれる

エンタープライズモバイルの開発プロジェクトでは、開発部分を外部の開発会社が複数社で分担するのはよくあることです。基本的には、「クライアント側を開発する企業」と「サーバ側を開発する企業」で分担するのがやりやすいと思います。なぜなら、エンタープライズモバイルの設計ではクライアント側はサーバ側のWeb APIを呼び出すことによって処理を行うアーキテクチャを採用するためです。これはネイティブアプリであっても、HTML5であっても変わりません。

つまり、Web APIを作る側（サーバ側）とそれを使う側（クライアント側）で責任の分界点が明確なアーキテクチャとなるため、それぞれを別の企業が開発していても責任の所在や作業範囲で問題が起きる可能性は限りなく低いのです。

責任の分界点が明確なので、それぞれを別の企業が開発することで問題が起きる可能性は低い

クライアント側の開発企業に求められるのは、アプリ開発のスキル、UI/UXデザインに関するスキル、デバイスに関するスキル、セキュリティ面の知識などでしょう。

一方、サーバ側の開発企業に求められる物は、大規模システムのアーキテクチャや業務システムの知識、非機能要件や運用関連の知識などです。加えて、すでに存在する企業独自のシステムに関する知識も必要になることがあります。例えば、既存の顧客管理システムと連携する必要があるのであれば、そのシステムを構築・運用している会社の協力は不可欠です。

現状、既存システムを構築・運用している企業がクライアント側の開発スキルを持っていないことが多く、逆にクライアント側の開発が得意な企業は企業システムを構成するサーバ側のスキルや経験が少ないといったケースが多く見られます。将来的には解決される問題だと思いますが、まだ数年はこの状態が続くでしょう。

「契約は1社にお任せ」の落とし穴

「開発依頼先は1社に集約しないと責任範囲が不明確になる。うちは1社としか契約しないので、ほかの企業はそのアンダーに入ってほしい」――などという考え方は、エンタープライズモバイルには向いていません。エンタープライズモバイル開発の体制を多段構成にした場合、デメリットとして次のようなことが考えられます。

無駄な工数が発生する

　エンタープライズモバイル開発の案件は、ERPや基幹システムほど開発規模が大きくないケースがほとんどです。にもかかわらず、多段構成にすると、それによって無駄に調整のための工数が発生することになります。

プロジェクトのスピード感が失われる

　ユーザーレビューでは、指摘事項に対して開発者やデザイナーとその場で議論し、迅速に修正の計画を立てる必要があります。そうした場で、「担当者に確認して後ほどご回答します」といったことが頻繁に起こると、プロジェクト全体のスピード感が損なわれ、解消し切れなかった課題がリスクとなって少しずつ溜まっていくことになります。

運用開始後の対応が鈍くなる

　エンタープライズモバイルの開発プロジェクトでは、運用開始後に改善要望が出てくるのはよくあることです。ただし、基幹システムの改善のように重厚長大なものではなく、クライアント側だけを数日で修正するような軽微なものが頻繁に上がってくるイメージです。これに対応するのに、階層構造の組織体では調整にも工数と時間がかかってしまいます。場合によっては修正にかかる工数よりも調整に工数がかかり、その結果「予算オーバーなのでやめておこう」ということにもなりかねません。いずれにしても、「良いシステム」とは程遠いものになってしまうでしょう。

*　*　*

エンタープライズモバイル開発の場合、サーバ側とクライアント側を明確に分離することができるため、「サーバ側は社内システムの開発実績が多いA社、クライアント側はアプリ開発の実績が多くデザインに強いB社」といった、各社の強みを生かした体制を組むことに非常に向いています。

筆者の場合、上述のB社の位置付けでA社に相当するSIerと一緒にプロジェクトを進めています。契約は依頼主がA社、B社とそれぞれ直接結ぶかたちです。依頼主とSIerには、前回解説した開発プロセスを含め、分業体制などについても説明しますが、大抵最初は「うまくできるのかなあ」という雰囲気が漂います。しかし、慣れればほぼ問題なく進められるようになるので、ぜひトライしてみてください。

次回は、エンタープライズモバイル活用を実現するための情報システム部門のあり方などについて説明する予定です。