ユーザーは複雑なものを使いたいのだろうか？

いくつかの例外を除いて、複雑なものを使いたい、という人は居ないのではないか、と自分は考えているのだが、いかがだろうか？

もちろん、複雑なものを使えるようになった先が、その人にとって大きなバリューを得られる、というのならそこは別。きっと徹夜して勉強してでも使えるようになろう、とするだろう。

でも、それが業務そのもの、であったり、業務システムであったら、どうだろうか？

（今はそういう仕事から離れているが）自分が社内コンサルのようなことをやっていた時はそこを念頭に置いて仕事をしていた。

もちろん、失敗もある。失敗、というのは、思ったような使い方をしてもらえていなかったり、逆に思いもよらないような使い方をされた結果、利用者にとって手戻りする必要が発生するようなケースだ。全体を自分が見ている場合じゃないケースで連携部分で、というのがほとんどなのだが、連帯責任、という意味では自分にも非がある、と思う。

自分の関連するシステムの開発の場合、まず、ユーザーである代理店スタッフに対して業務を主管する施策担当部門の新業務なり現業務の改訂なり新たなキャンペーンを打ちたい、といった業務ありきで、それに対応するシステムづくりをする際から自分達の仕事が始まる。

たいてい、「今のシステムにはこういう機能が足りない」、「こういう新機能があればもっと業務で使えるはず」というシステム機能ありきでものを語られるので、「何を実現したい、と思っているの？」というヒアリングからスタートすることになる。

その上で、他の業務領域との整合性を確認する、とか、過去の踏襲をどこまでするか、とか考えていくことになるのだが、そこを「整合性」だけを重視して、非常に複雑な業務ルールを作ってしまったり、逆に、「整合性」や「過去の踏襲」とかを嫌って、ごく狭い範囲での要件化をして単機能で見れば簡単だが、全体で見た時の理解し易さが欠けているとか・・・。

自分は恵まれていたのでそういう仕事の仕方をせずに済んだが、他の担当は結構そういった所で苦労していたようだ。

もちろん、納期の関係上、しぼらなきゃいけない場合もあるし、予算の関係上、手を出せなくなっている場合もある。

でも、どこまで本気でユーザーに使ってもらおう、という意欲を持つか、また、そのユーザーの使い勝手のために、本来はもちろん知っておくべき施策担当部門の人間が仮にユーザーの現状、業務システムの現状を知らなかったとしても、ユーザーのために、施策担当部門を非難するのではなく突き動かす力を持てるか、そういった所が自分達の存在のバリューなのではないか、と自分は今も信じて疑わない。

こういうことを書こう、としたきっかけは全然違うところにあったのだけれども、文脈の都合上書けなくなってしまった。とりとめの無い文章ですみません。きっかけ部分はまた独立して書きます。