三井 英樹

　システム構築者とは，長い間そのプログラミング可能なシステムの部分のプロフェッショナルと思われてきました。様々な分類の仕方がありますが，代表的なものでは，システムを三層に分けて考え，人間に近いほうから，「フロント」「ミドル(ウエア)」「バックエンド」などと呼び，それぞれのプロフェッショナルが実装を行います。

　それぞれの「層」で技術は深化していますので，当然高度な技術スキルが要求されます。各担当者は，まさに技術の粋を集めて，このシステムの「性能」を引き上げようとします。

　しかし最適化できるのは，この「フロント」までです。データベースやミドルウエアを最適化できたとしても，最後に一つだけ想定外になる可能性の高い要素が残ります。人間です。操作するオペレータと言っても良いかもしれません。

　こうした問題はここ数年，徐々に取り上げられるようになってきています。キーパンチャーが操作するシステムをクライアント/サーバー（C/S）からWebに置き直した企業で，HTMLのレスポンスの悪さから全体の生産性が落ちたというのが代表例でしょうか。いずれも本番運用（本当なら設計）前に現場の人に試してもらっていたなら，事前に察知できた問題ですが，驚くほど頻繁に起こっているようです。

なぜ問題が出るのか

　なぜ，このような問題が起こるのでしょうか。理由は少なくとも二つあります。一つは，ユーザーの側で，もう一つは開発者の側です。

　ユーザーの側の問題は，その範囲が様々な意味で拡大していることです。まず，パソコンそのものが特殊な道具ではなくなりつつあります。価格も下がり，家庭に複数台あってもおかしくない状況になっています。そして，慣れの問題もあります。普通の存在になったパソコンのモニターから，様々な情報の操作をすることも特別なことではなくなり，様々な慣れが生まれてきています。「慣れ」は，ユーザーの癖にマッチすればパフォーマンスを向上させる方向に作用しますが，異なる「習慣」に対しては大きなブレーキになります。その辺りのユーザーのITリテラシの見積りが，数年前より格段に難しくなっているのです。

　開発者側の問題は，主に意識の問題です。企業（クライアント）は，従来型の三層に分けて考えられているシステムに投資しているのではなく，それを操作する人間も含んだシステム全体の効果に投資していることを忘れてはいないかとという問題です。少し酷な言い方をすれば，システム開発者が，利用者を置き去りにして暴走していないか，ということです。

　どんなにシステムの結合テストでよい数字が出ても，企業は喜びません。その高パフォーマンスが，実務でも達成できたときに喜んでくれます。そして，技術が様々な意味で成熟期に入っている現状では，大抵の場合のボトルネックは，人間なのです。

　人間は機械ではないので，プログラミングできません。新しいシステムを使いこなすには，慣れと教育が必要です。それを支えるサポートもです。そして，感情も持っていますし，良くも悪くも経験もあります。そして，そうした「人間が直接かかわる部分」に一番コストがかかる時代に入っています。

　それなのに，人との接点ではなく，優秀なツールが次々と生まれているバックエンドの部分の「開発時生産性」だけを追い求めていては，顧客が本当に求めている「利用時生産性」を高めることは難しいといえるでしょう。

何が必要なのか

　では，何が必要なのでしょう。端的に言ってしまえば，「書を捨て街に出よ」だと思います。プログラミングの技術書を脇に置き，開発者自身が単なる一ユーザーとして，そのシステムに向き合ってみることです。配偶者や家族ならどう操作するかを考えてみることです。何にイライラし，何を喜ぶのかを考えることです。ここまでパソコンが普及している状況で，「これは業務アプリケーションなので，使う者が習得すれば良い」というのは，開発者の怠慢でしかありません。どんなシステムであっても，使いやすく習得しやすいモノに越したことはないのですから。

　最後に，これが何を意味しているか留守番電話を例に考えてみます。下図は，一般的な留守番電話の機能を模式化したものです（文字が小さくて読めないかもしれませんが，機能の数がどれほど多いかだけに注目してください）。

　大別すると五つの機能（基本機能/電話機能/留守録機能/便利機能/子機機能）があります。開発中は，最低でもこの次の段階の合計35個の機能がタスクとして管理されているはずです。それぞれの機能の実装に開発者は心血を注ぐでしょう。

　しかし，これだけの機能をコントロールするのは，電話番号をプッシュするものと兼用の限定されたボタンです。これらのボタンを通してでないと，各種の設定や確認ができません。しかし，自慢ではありませんが，我家ではここに列挙している機能の半分も使えていません。理由は簡単です。操作方法が複雑すぎてわからないのです，覚えられないのです。

　その結果，開発者が心血注いだ機能は用いられず，私は使いもしない機能のためにお金を払ったことになります。我家の電話も不幸ですが，私自身もハッピーな経験をしていません。さらにいえば頑張った開発者も笑えない話です。

　フロント（ユーザー・インタフェース）の部分でできることは限られています。その設計が，開発コスト全体に占める割合は，それほど大きくはないでしょう。しかし，その出来次第で，苦労して実装した機能が使われるかどうかが決まるのです。

チェックシート

　前回の最後の絵は，実はここでもチェックシートとして使えます。自分たちが実装した機能がどのような状態にあるかを，これを用いて見てみましょう。

　これからの情報システム開発者は，自分の担当した機能実装だけに目を向けるのではなく，システム全体として担当機能が，「使い易い状態」にあるかどうかを，一般のエンドユーザーの視点で見つめられるスキルも要求されていくでしょう。しかし，このスキルは，エンジニアとして目を捨て，普通の利用者の気持ちになってみるというだけなのですが。

PS. もしも留守番電話の開発者が読者の中におられましたら申し訳ありません。


三井 英樹（みつい ひでき）
1963年大阪生まれ。日本DEC，日本総合研究所，野村総合研究所，などを経て，現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と，エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や，RIAコンソーシアム，日刊デジタルクリエイターズ等で活動中。Webサイトとして，深く大きくかかわったのは，Visaモール（Phase1）とJAL（Flash版：簡単窓口モード/クイックモード）など。