スマートデバイス向けのアプリを手早く開発し業務に役立てるうえで、ポイントとなるのは「プロトタイプ開発」「段階的な機能追加」「開発ドキュメント作成」「保守用端末の確保」「開発基盤の整備」の五つである。先行企業は試行錯誤の中、これらを実践し始めている。
まずは動くものを作る
一つめは、「プロトタイプ開発」。モックアップと呼ばれる、画面周りなど一部の機能だけを実装したプロトタイプをベースに、操作感などを確認しながら改善と機能追加を繰り返す、アジャイル開発の手法である。
スマートデバイスのアプリは、画面遷移やポップアップなどの動き、操作性が重視される。これらは「ユーザーエクスペリエンス（UX）」と呼ばれるが明文化が難しく、机上設計に限界がある。
そこで、ユーザーインタフェース（UI）については開発フェーズの早い段階でモックアップを作り、実際にアプリを利用する業務部門に試用してもらう。「スマホやタブレットの技術は成熟していないため、やってみなければ分からない部分もある。とにかく動くものを作るのが重要だ」と、カヤック HTMLファイ部の神代友行氏は指摘する。
一方で、基幹系システムやデータベースとの接続機能といったUIに関連しない機能は、従来のウォーターフォール型で開発する。テックファームの石立宏志プロフェッショナルサービス事業部長は、「開発体制を、UIとバックエンド機能の2チームに分けて作業を進める方法もある」と話す。
【プロトタイプ開発】
レンタルのニッケン要件をイメージで伝える
「この図を基にアプリを開発してもらった」。レンタルのニッケンで現在は常勤監査役を務める望叶太郎氏は、こう話しながらiPadの画面を指し示す。そこに映っているのは、2012年4月に取締役管理本部長兼コンプライアンス室長としてアプリ開発を依頼した際に作成した、手書きのメモデータである（図6）。同社はこの手書きメモを基に、プロトタイプ開発を進めた。
ニッケンは2012年6月末までに100台のiPadを社員に配布した。このうち約半数に当たる50人の営業担当者が使うための2種類のアプリを開発。同社がレンタルした建機などについて気づいた点をその場で報告するアプリ「通報くん」と、建機のレンタル前と後の状態を画像に残すアプリ「貸出・返却くん」だ。撮影した画像に手書きのコメントを加えて、サーバーに登録するために使う。
アプリ開発は、営業担当者などと話していたアイデアに基づき、開発を請け負ったドリーム・アーツの担当者と打ち合わせしながらイメージを固めた。ただ、「やはり実際に動くものを見てみないと、善しあしが分からない。そこでイメージを伝え、モックアップを作ってもらった」と望氏は話す。開発途中のアプリを現場で実際に使ってもらい、操作性や機能について修正点を洗い出した。
画面の色を変更したのに加えて、通報するデータをどの部門に送信するか、選択できるようにした。そのほうが、通報内容への対応が的確になるとの考えだ。「モックアップがあると、こんな機能が必要だという発想が生まれやすくなる」と、春一大志情報システム部長は話す。
【プロトタイプ開発】
日本調剤入力画面の設計を見直し
日本調剤も、プロトタイプを開発し、アプリの改善や機能強化に取り組む1社だ。新規事業で業務プロセスが定まってない領域で使うアプリについて、プロトタイプ開発を実践した。同社は調剤薬局の大手だが、新たに在宅調剤の事業化を目指す。その鍵を握るのがスマートデバイス向けアプリだ。「実際に使ってみて初めて分かった課題があった」と、河野文隆システム部長は話す
同社が7月に約50カ所の薬局で利用を開始した「在宅コミュニケーション支援システム」は、自宅や施設にいる患者を訪問して調剤する業務を支援するシステム。訪問先でiPadを使って調剤履歴や訪問時のやり取りなどを登録・参照できる。アプリは、アドバンスト・メディアの音声入力技術をベースに開発した。
開発を始めたのは2011年11月。プロトタイプを現場に試用してもらった。すると、従業員による入力ミスが頻発した。「画面上部のタブを切り替えて複数画面にまたがって情報を入力させていたが、分かりにくかったようだ。タブを10から5に半減させ、縦に画面をスクロールする方式にしたら、ミスは減った」（河野部長）。
通信状況が悪い場所での音声入力に対策が必要であることも分かった（図7）。日本調剤はこれらを改善し、全国の薬局442店舗で在宅調剤事業の展開を目指す。
【段階的な機能追加】【保守用端末の確保】
はるやま商事現場の改善要求を取り込む
二つめのポイントは、「段階的な機能追加」である。アプリに最初から100％の機能を搭載しようとせず、最低限必要な機能を先行して業務の現場に提供する。膨らみがちな機能要件を絞り込み、アプリの品質についてもある程度割り切る。問題があれば、修正版アプリを配信すればよい。
リリースを優先する理由は2点。早く使い始めることでアプリ導入の効果をいち早く得られることと、OSや端末のバージョンアップによる影響を避けることだ。
スマホやタブレット端末は次々と新機種が登場するうえに、OSのバージョンアップ周期も短い。例えばAndroidは2011年10月に4.0「Ice Cream Sandwich（開発コード）」が登場したが、12年6月には4.1「Jelly Bean（同）」が公開された。プラットフォームの変化に振り回される愚は避けたい。
このOSや端末の変遷の速さは、三つめのポイント「保守用端末の確保」に取り組む要因でもある。開発したアプリについても、OSや端末の変化への対策が必要。それが、保守用端末の確保だ。
端末やOSのバージョンが変わると、リリース済みアプリの動作に影響する恐れもある。動作検証のため、故障に備えた予備機とは別に、アプリ検証環境として保守用端末を確保しておくべきだ。
つまり、開発段階においては最低限の機能で手早くリリース。使用開始後は、OSや端末の変化に備えて保守用端末を確保しておく。はるやま商事の例を見よう。まずは基本機能を実装
はるやま商事は、開発当初に店舗担当者から寄せられた要件を絞り込み、複数のフェーズに分けて実装する手法を採用する（図8）。同社が開発したのは、店舗用POS（販売時点情報管理）システム「iPad-POS」の一部であるiPad用アプリだ。iPadから売り上げ情報の登録や在庫検索ができる。
開発を始めた2011年2月の段階では、POS端末機能に加えて、会員情報を手書きで入力する機能や、スーツの裾直しなどをタッチ操作で指定できる機能などを実装することが決まった。ただし「全ての機能を実装すると、ベンダーの負担が増し、開発期間も長くなる。まずは基本となるPOS端末機能を実装し、徐々に機能を強化することにした」（はるやま商事情報システム部の山本隆吾部長）。
さらに保守用端末の確保にも力を入れている。はるやま商事にとって想定外だったのは、OSのバージョンアップが頻繁に発生することだ。「マイナーバージョンアップであっても、文字入力フィールドでかな漢字入力にならなくなるなど、挙動が変わる」（山本部長）。
そのため、iOSのバーションが異なるiPadを複数確保した。iPadはハードウエアが3世代あるのでiOS4と5で、6機種だ。「iOS6がリリースされれば、さらに検証用端末を増やすことになる」（情報システム部の湯浅俊和氏）。
【開発ドキュメント作成】
カーセブンディベロプメントAndroidアプリをiPhoneに移植
四つめのポイントは「開発ドキュメント作成」だ。短期開発が多いアプリ開発では、従来の開発のようにしっかりとしたドキュメントを作成する時間を確保できないことが多い。まして業務システムの開発経験が乏しいITベンダーでは、なおざりになりがちだ。
しかし保守フェーズを考えると、最低限のドキュメントは確保しておくべきだ。OSのバージョンアップへの対応や、別OSへの移植作業が発生する可能性がある。開発ベンダーを変更する機会が生じるかもしれない。
ベンダー変更を可能に
カーセブンディベロプメントは2012年4月、Android端末を想定して開発した中古車査定システム「インスマートシステム」のクライアントアプリを、iOSに対応させた（図9）。その際に同社は、Android版アプリを開発したベンダーとは異なるベンダーに開発を依頼する決断をした。
Android版の開発を完了し、利用を開始したのは2011年7月のことだ。ただ、カーセブンの開発プロジェクトは当初予定よりも遅れが生じ、ベンダーとの意思疎通がうまく行かなかった。そこで、アプリの保守は別のベンダーに委託することにした。iOS版の開発もその保守ベンダーに委託した。
「開発が遅れたこともあり、前任のベンダーが残したドキュメントは十分とはいえなかった。ただ、ソースコードを解析するなどして何とか引き継がせることができた」と、井上貴之代表取締役社長は振り返る。「開発と保守のベンダーを別にしたことは、特定のベンダーに依存せずに済むという点でよかった」と井上社長は話す。iOS版を基に、ドキュメントも整備し直した。今後はAndroid版の改善に着手する予定だ。
本格開発には基盤整備を
最後に五つめのポイントとして検討すべきなのが、「開発基盤の整備」である。今後スマホやタブレット端末用アプリを継続的に開発し活用していくならば、開発手順や開発言語、開発ツールなどを絞り込み、ソフト部品の再利用などを推進する必要がある。
前述したリクルートのように自前で基盤を整備する企業もあるが、これから検討する企業には、ITベンダーが提供するソフトウエア製品やクラウドサービスを利用することが基盤整備の有効な選択肢になる。「開発基盤でスピードアップ」の章では、開発基盤向け製品やサービスの動向を見ていく。
スマートデバイス向けのアプリで、脆弱性が指摘されるケースが頻発している。IPA（情報処理推進機構）の調査では、2011年後半からAndroid端末向けアプリにおける脆弱性が増加しており、2012年5月末までで累計42件の脆弱性に関する通報があったという。
「セキュリティや脆弱性についての知識がないまま、スマホ向けアプリを気軽に開発し公開するエンジニアが増えた」と、日本スマートフォンセキュリティ協会（JSSEC）技術部会の松並勝氏は指摘する。
企業が社内業務で利用するアプリであっても、容易に脆弱性は生まれる。例えばSDカードに暗号化せずにデータを保存してしまうと、ほかのアプリから盗み見られる。このようなスマートフォンならではの脆弱性を、スマートデバイス向けアプリの開発経験が浅いエンジニアは見落としてしまいがちだ。
業界団体も対策に動いている。JSSECは6月、「Androidアプリのセキュア設計・セキュアコーディングガイド」を公表した（写真A）。スマートデバイス向けアプリならではの脆弱性が生まれないようにするポイントを、サンプルコードを示しながら指南する。「ITベンダーに開発を委託する際も、一度ガイドラインに目を通すことを契約の条件として盛り込むとよい」（松並氏）。
IPAは6月、「『Androidアプリの脆弱性』に関するレポート」を公表した。その文中に、脆弱性がないかを確認するための簡易チェックリストを掲載した（表A）。
