6.「カスタム」コードの組み込み方に気をつける
アプリ開発の一部または全部で、コードジェネレータを使っている場合、アプリのコードをカスタマイズしたいときには、その内容が、コードジェネレータが提供しているカスタマイズ機能の範囲に収まるようにすべきだ。こうしておけば、作ったコードはコードジェネレータベンダーのサポート対象に収まる。また、カスタマイズの内容をベンダーのガイドラインとベストプラクティスの範囲内に収めることで、後日コードの強化やメンテナンスを行う場合の作業の複雑さが軽減される。
7.文書化
アプリケーションに関するドキュメント作成を自動化してくれるツールは数多くあるが、いまだに文書化はアプリケーション開発のもっとも弱い分野の1つだ。文書化が十分に行われていないと、後でアプリケーションのメンテナンスや強化を行うのも難しくなる。多くのIT企業では、システムやアプリケーションのメンテナンスに業務時間の50%以上を費やしている。この作業を効率化するためには、よいドキュメントが必要だ。
8.モバイルデバイスを標準化する
多くの企業がBYOD(個人デバイスの業務利用)ポリシを運用し始めており、企業のIT部門で、従業員がその企業内で使用してよいモバイルデバイスを標準化し、そのリストを作る必要が生じている。モバイルデバイス用アプリの開発ほど、この標準化が必要な分野はない。すべてのデバイスで使えるコードを書くことはできないのだ。デバイスとデバイスの構成を標準化すれば、アプリ開発のターゲットを設定できるため、結果もよくなる。
9.ヘルプデスクから学ぶ
多くのIT部門は、ヘルプデスクをIT部門の新人を置く場所だと考えている。ヘルプデスクは必要悪であり、アプリ開発に必要な人員を奪うものだと見なされていることが多い。しかし、IT部門がヘルプデスクにより積極的に関われば、ヘルプデスクの経験はアプリケーション開発にも生かすことができる。ヘルプデスクはアプリに関する情報の宝庫だ。例えば、どのアプリに最もトラブルの連絡が多く、どのアプリにはトラブルが少ないといったことも分かる。アプリケーション開発者がこれらのヘルプデスクの報告を分析すれば、おそらくそういった問題を避けるためのアプリの設計やコードが分かってくるはずだ。その結果、エンドユーザーの満足は大きくなり、トラブル報告は減るはずだ。
10.アプリケーションユーティリティを評価する
IT部門は普通、ハードウェアの利用状況を定期的に評価している(あるサーバは平常時には20%しか使用されていない、など)。この利用状況分析を、アプリに対しても行えるようにすべきだ。何年か前、筆者はあるシステムエンジニアと飼料配給アプリに取り組んでいた。その際、ユーザーに使われているのはアプリのわずか20%にすぎず、残りの80%(最も重要な部分)はまったく使われていないことが明らかになった。調べていくと、アプリの重要な部分のユーザーインターフェースが難解すぎて、ユーザーが操作できず、このためその機能も使われなくなっていた。その結果、会社は貴重な競争力を持った機能を生かせていなかったわけだ。もしIT部門がハードウェアと同じようにこのアプリを評価していれば、アプリの作り方や改善の仕方についての知見を得ることができ、最大の効果を上げられるだろう。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。