全5159文字
PR

 「ユーザーヒアリングのまんまシステムを作ってはいけない!」

 これは私の31年に及んだ、製造業の情報システム部門における活動の中で座右の銘の1つとしてきた言葉です。ある時、この言葉を思いつき、プロジェクトの経験を重ねるうちに確信するに至りました。情報システム部門長になってからは後輩たちにことあるごとに伝えてきました。

 もちろん、実際に仕事をする事業部門のユーザーからヒアリングするステップは企業情報システムを設計・構築するにあたって欠かせません。ただし、ヒアリングした結果からまっとうなシステムに仕上げるために設計者としてやるべきことがあります。

 「UI(ユーザーインターフェース)偏重で良いシステムはできない!」

 私の座右の銘はこう言い換えられます。近年のシステム開発において「UI偏重主義」がまかり通っていないでしょうか。

 直感的に分かり易いUIはユーザーレビューを動く画面を用いるスタイルに変えました。かつての紙芝居方式とは雲泥の差です。ユーザー部門と情報システム部門との距離が縮まりました。

 ですから見栄えの良いUIを否定するものではありません。私自身、2000年前後を境に、Javaを使うWeb型のUIに魅せられ、社内システムのオープン環境シフトにまい進しました。UIに重きを置いてフロント側のプログラムを量産できるようになったことも大きかった。DAO(データアクセスオブジェクト)によって、バック側へのデータアクセス処理を意識しなくてもよくなったからです。

 とはいえ、情報システムは表層のUIだけで動くものではありません。バックにあるデータベースがしっかりしている必要があります。ところが、UIに力を入れた半面、データベースに関する設計は一部のデータベーススペシャリストあるいはデータモデラーに託され、脚光を浴びることが減りました。この傾向が強まるにつれ、データベースの設計品質が粗悪な事例が増えてきました。

受発注システムになぜか10数種類のテーブル

 私が情報システム部門長を務めていたときに経験したことをアンチパターンとして紹介します。2000年を超えた頃、私の担当外の部門で受発注システム再構築プロジェクトが立ち上がりました。業務の内容がユニークであったことからパッケージ導入ではなくスクラッチ開発となり、大手システム開発会社に委託しました。

 凝りに凝ったUIが提案され、それに基づいてユーザーレビューを重ねる日々が続きました。入力画面を制御するプログラムはプロトタイプを経て本番用に切り替わり、単体テストを終え、システムテストに入ることになりました。

 入力画面は受注業務であれば受注入力から始まり、商品引当、出荷指図、出荷、売上計上と変遷していきます。発注業務であれば、発注入力、入荷予定、入荷、購入計上といったステータスに移ります。変遷ごとに入力画面プログラムがつくられ、それぞれにSEとプログラマーがはりつく、分業開発が進められました。