全1865文字

 システム構築において発注者であるユーザー企業とITベンダーはともに同じゴールを目指すパートナーであると同時に、利害が反することもある取引相手でもある。システム構築プロジェクトが順調に進めば良好な関係のパートナーとしてお互いを称賛するが、プロジェクトが遅延しコスト増加が発生すればお互いの仲は急速に冷え込む。

 最悪の場合、プロジェクトがとん挫し、泥沼の訴訟に発展するケースさえある。さすがにそこまでのトラブルになることはまれであろうが、システム構築に両者の小競り合いはつきものである。原因はいろいろあるが、ユーザーの業務システムの開発の主流がWebベースとなって増えているのが、UI(ユーザーインターフェース)に起因するものだ。

 このUIの問題、実に厄介なのだ。厄介な理由はいくつかある。

  • 業務フォローの通りにシステム設計されていても、UIが気に入らないとユーザーは容赦なくダメ出しする。
  • UIは個人の感覚や好みによって評価が分かれる。ユーザーだけでなく開発側のエンジニアにも同様の個人差がある。
  • 現場のプログラマーやSEはUIに関する専門知識を持っていない。そしてUIの専門家は業務系システムのプロジェクトにはめったに参加しない。
  • インターネット上では新たなUIやUX(ユーザーエクスペリエンス)が次々と生まれ、それを体験したユーザーはますます業務システムのUIが陳腐に見える。

 従来の業務システムであれば、要件定義で業務要件や業務フローを定め、決められた手順を守り、正しく計算がなされ、データが登録・表示されればよかったが、最近はそれだけでは不足なのだ。より快適で使いやすく、が重要な要件となったのである。

 それならば要件定義できっちり決めればよいだろうとなるが、現実には簡単なことではない。要件定義をドキュメントだけで行うとUIの問題が必ず発生することはベンダーも分かってきているので、モックを作って確認を取る手法も普及しつつある。ベンダーとしてはモックでUIを確認したからこの仕様で確定と考える。ところが受け入れテストの段階でユーザーからダメ出しがでる。

 ベンダーとしては「要件定義で合意したでしょう」となるが、ユーザーとしては「モックでは、大体こんな感じ、と曖昧な説明だった。それに説明されたことと実装されたUIは大きく違うから設計ミスでしょ」となる。これはベンダーの不手際なのか、それともユーザーのわがままなのだろうか。