エンタープライズモバイルに必要なアプリの品質とは?―Think IT Mobile Developer Seminar 2016レポート
エンタープライズモバイル開発の落とし穴
まず登壇したのは日本DEC、日本HP、ラショナルソフトウェアなどを経て独立した株式会社ゼンアーキテクツのCEO、岡大勝氏。岡氏は「エンタープライズモバイル開発の『3つの落とし穴』」と題したプレゼンテーションで企業におけるモバイル端末の活用の必要性とモバイルに起因する難しさを紹介した。
これまでのウォーターフォール型の開発スタイルからモバイルに適したアプリケーション開発のスタイルに移行する際の3つの落とし穴として具体的に以下3つを解説した。
- 以前と同じ感覚で開発計画を立ててしまう
- (モバイルに適したテストプロセスが必要なのに)テストを甘く見てしまう
- アジャイル開発を支援するツールが全てを解決してくれると思ってしまう
その上でそれらの落とし穴を回避する方法論として「ガチガチのエンタープライズ企業がいきなり組織や方法論をまるごと変更してモバイルアプリケーションの開発に移行するのは危険」であるため、一度、モバイルアプリ開発チームを小さく独立させてから、開発を進める「登山道モデル」を推奨した。これはエンタープライズのIT部門からアジャイル開発を行うチームを独立させ、開発環境もルールも別枠でスタートさせて徐々に企業が持つ本来のコンプライアンスに統合していく方法論だ。
いわば、全くの別組織としてアジャイル開発を行いつつ、アプリのリリースなどのマイルストーンごとに本来の組織のルールをこの開発プロジェクトが求める目標に合わせていくというやり方だ。ウォーターフォールとアジャイル開発という2つの開発スタイルを如何にすり合わせていくのか? という岡氏のこれまでの経験則から生み出されたモデルといえるだろう。ウォーターフォールの開発が主な大企業のIT部門においては検討してみるに値するのではないだろうか。
モバイルアプリ開発における“複雑さ”と回避策
次に登壇したのは日本ヒューレット・パッカード株式会社ソフトウェア事業統括 シニアコンサルタントの藤井智弘氏。「エンタープライズモバイル開発管理の勘所」と題されたプレゼンテーションでモバイルアプリケーションを開発する際に遭遇するリスクとして「開発スタイルが混在することによる複雑さ」、「業務的な依存関係による複雑さ」、「システム間の依存関係による複雑さ」を紹介。特にモバイルアプリケーションを実装する際に必要となる様々なコンポーネントやビジネスロジックなどを分離する方法論として「API First」という発想を提案した。
API Firstとは「構成要素間のコラボレーションとAPI仕様を先に定義し、個々の要素の実装を並行して開発するプラクティス」だ。クラウドネイティブな外部サービスとの連携だけではなく、社内の他のシステムとの連携を分離するために応用出来るという。つまりバックエンドを受け持つサービスとフロントエンドのモバイルアプリにおいて如何にビジネスロジックやデータを分離するのか? に適応可能な発想になる。大元はラショナルソフトウェアのRational Unified Prosess(RUP)から出てきた業務プロセスを分析する方法としてBCE(バウンダリ・コントロール・エンティティ)モデルを使い、モバイルアプリのGUI、バックエンドとのやり取りをクリアにしたうえで、各システム間の接続ポイントをAPIとして定義することで設計の早期の段階で開発を並列化することが目的だという。
この方法を実施するポイントは、ユーザーエクスペリエンス的にストーリーを組み立てたうえで、あまり厳密に分析をせずに切り分けることだという。これによってウォーターフォール型の開発チームとアジャイル開発のチームがうまく開発スケジュールを合わせることも可能になるという。このあたりも従来のウォーターフォール開発を経験した上で具体的にアジャイル開発を指導するエキスパートらしい経験則といえるだろう。
プロセス連携とHPEが考えるモバイルテスト自動化
最後に登壇したのは、同じく日本ヒューレット・パッカード株式会社ソフトウェア事業統括 シニアコンサルタントの小宮山晃氏だ。小宮山氏は、モバイルアプリケーション開発における日本ヒューレット・パッカードの提供するソリューションとして、開発フェーズ、結合テスト、システムテストそれぞれの段階におけるテストの難しさと必要性、HPEのテストツールの連携などについて解説を行った。
特に各段階ごとのテストプロセスを自動化について、モバイル端末に特徴的な機能と操作によって向き不向きがあることをまず紹介。地図やチャットなどとの連携、通話機能の操作、センサー機能などモバイル端末であれば、普通に利用するような機能であってもテストプロセスを自動化する際には難しさが増す場合があるという。その際には人的な工数を考慮して、それ以外の部分を自動化すべきと解説した。また解像度やスクリーン大きさ、OSのバージョンなど多種多様に及ぶモバイル端末の管理にはHP Mobile Centerを活用することでデバイスとOSの管理さらにアプリケーションの管理が容易になるという。
日本ヒューレット・パッカードのソリューションの強みはDevOpsの観点で開発フェーズからテストの自動化、本番環境への継続的インテグレーション、さらに負荷テストの実行まで一貫して解決できるところだろう。欧米のコンサルティングファームのCapgeminiが行った調査(2015年10月発行、世界の1500名以上の開発者、テスターが参加)によれば2014年には企業内のテスト自動化率は28%だったものが2015年には45%まで上昇している。「モバイルファースト」の流れを受けてテストの自動化への投資がますます増えていることを表しているといえる。
最後のセッションはセミナールームからラウンジに場所を移して、岡氏、藤井氏、小宮山氏が参加者からの質問に回答するパネルディスカッションだ。ここで印象的だったのは、「アジャイル開発とウォーターフォール開発を直接比較すると最初はアジャイル開発は圧倒的に分が悪いので、ある程度、開発が継続して『このぐらいにはこれくらいのモノができるようになります』という予測が可能になる程度までは頑張る」という岡氏のコメントだ。さらに「アジャイル開発とウォーターフォール開発を比較すること自体がナンセンス。プロジェクトの成否とエンジニアの評価は分けて考えるべき」という藤井氏のコメントも、これからモバイルファーストを見据えたアジャイル開発に向かおうとするIT部門の参加者の方々には参考になったのではないだろうか。
セミナーURL:Think IT Mobile Developer Seminar 2016 失敗しないためのエンタープライズモバイル。チーム運用とテストの最適解
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- モバイルアプリのテスト時における5つの課題とHPEが考えるテスト自動化とその先
- アプリケーションライフサイクルの最適化がモバイルアプリの企業価値を高める
- HPが提唱するDevOps実現の確実な切り口はテストツールの革新から
- モバイルアプリの継続的テストフレームワーク、配信後のユーザー体験を測定―Think IT Mobile Developer Seminar 2015レポート
- 開発手法を徹底比較!アジャイル vs.ウォーターフォール
- クックパッドの開発体制、モバイルアプリを取り巻く環境と課題解決―Think IT Mobile Developer Seminar 2015レポート
- CNDT2021、大規模ウォーターフォール開発をクラウドネイティブにするためのヒントをNTTデータのエバンジェリストが解説
- ディシプリンド・アジャイル・デリバリーの基本モデル「方向付けフェーズ」を理解する
- アジャイル開発とは?プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説
- さまざまな開発手法