こんにちは。
今日、ちょっと社内で話題になったことがありましたので、もうひとつ記事を書きたいと思います。
まさにITの話ですが、IT関係でない方もユーザの立場でお読み頂けたら嬉しいです。
さて、当社は、何々会社様向けというようなワンオフを作成するSIerさんではなくて、色々な会社で使われる製品を開発する、いわゆるパッケージベンダーさんとのお取引が多いのですが、パッケージ製品は特定の一社向けではなく、導入先も様々ですから、その様々な事情に合わせられるように、「設定で切り替えられる」という機能が色々とあります。
これって、一見すると便利なように思いますが、本当に便利なのでしょうか？
設定で切り替えられるという恩恵に預かれるのは誰なのでしょうか？
自社の状況やルールに応じて、臨機応変に対応できるのは嬉しい、だから使用者側にメリットをもたらすのではないか。
確かにそうかも知れません。でも、もし頻繁に設定を変更するということがないのであれば、最初から御社向けとして開発したらいかがでしょうか？まあ、それだとパッケージ製品に比べ者にならないほど高額になってしまいますね。であれば、例えば、パッケージ製品を御社向けにセットアップして納入してくれたら如何でしょうか？
自分であれこれ設定をしないので楽ですよね。実際、当社のお客様のところでも、実際に設定をしているのは、エンドユーザ企業（利用者）ではなくて、その製品販売側（代理店経由の場合もあります）です。
当社でも、勤怠管理システムを導入しているのですが、（現時点では残念ながら自社製品ではなくて他社製品です）クラウドで、すぐにはじめられるという触れ込みです。ま、確かに契約は数分ですが、勤務パターンを設定したり、社員を登録したりと、設定に時間がかかります。それもある程度は仕方ないことで、高額なお金を払えばオプションで設定代行サービスもあるようですが、まあ、設定代行に頼むための資料を作ったり、費用のことを考えればと、自分たちでチャレンジしたのですが・・・
とにかく設定が多く、例えば当社には縁のない、シフト勤務など、様々は変則勤務にも対応しているので、とても複雑です。
これをユーザビリティが良くないと言えば、そうなのかも知れませんが、そもそも、こちらに勤怠管理に関するリテラシーがそほどなく、一方で様々なことに対応しないとならないとすれば、多少なりとも使いやすくするような工夫ができるにしても、劇的な改善は望めないのではないでしょうか。喩えていうなら、その道の専門家しか理解できないような難解な理論を小学生が理解できないのは、教え方に問題がからだ！というには少々無理があるのと同じです。教え方の工夫はできても、やはりそこは小学生に理解させろという方が無理でなないかなと思います。
当社がこれまでお付き合いさせて頂いた経験から、パッケージベンダーさんは、一般的に、何々様向けバージョンのような個別管理を嫌うとことが多く、逆に設定による自由度を求めるところが多いように思います。でも、
これって、利用者側にメリットをもたらすのでしょうか？
と、私は疑問に思っています。そもそも先のように設定を代行してもらうなら設定画面なんていらないのではないか。（最低限で良いのではないか）まあ、例えば一般企業の情報システム部門にお勤めで、設定するのが私の仕事！とかいう人にとっては設定がなくなってしまうのは死活問題かも知れませんが、設定なんてしなくて済むならそのほうが楽ではないかと。個人で使うものであればオリジナリティを出したいとかもあるとは思いますが、業務アプリケーションとなると、まあ、できても害はないかも知れませんし、言っても使うのは人間だから、例えば、自分のお気に入りの見た目にカスタマイズできると嬉しいと思う人もいるかも知れませんが、残念ながら、それで売れるというような類のものではなさそうです。（本当の利用者が後回しなのは不本意ですが）
ちなみに、当社でも以前、ある製品を販売していたことがあるのですが、その製品は設定で、画面の背景画像を変えられるという機能がありました。開発者の想いとしては、販売先は、仕事とは言え楽しさを売る接客業をされている方ですから、売る側も少しでも楽しい気分になってもらいたいとの洒落た演出でしたが、実際には、ほぼ全てのユーザーが背景をなし（無地）に変更して使っていました。
つまり、利用者側から見れば、自分のところに合うように設定されていれば、頻繁に変えるものでない限り、設定画面は不要に思います。もっと言えば、料金が変わらないのであれば、ある１つの製品を設定で変えているのか、自分の会社用として用意された製品があるのかなどということはどうでも良いことではないでしょうか。
であれば設定で切り替えられるは誰のためのものか。
ちょっと乱暴な言い方をしてしまえば、設定で切り替えられるというのは、ソースコードを１本化できて管理が楽とか、よくよく考えなくても取り敢えず設定で切り替えられるようにしておけば後でなんとかなるとか、設定が多くバリエーションが豊富になれば、カバーできる顧客の数も増えるとか、そのような提供者側のメリットによるところが大きいのではないか、そんな風に思います。
それでも本当にそうであって、結果的に、例えば価格面などでユーザにメリットをもたらすのであれば、それも悪くはないのではないかと思いますが、
私はここに疑問を感じています。
まず、ユーザーで設定する必要がないのであれば、少なくとも設定画面は作らない。これで多少ですが開発工数は下げられると思います。それに開発費そのものは誤差程度であっても、ずっとメンテナンスをしていくことを考えれば、作るものが少なければ、動作検証のための工数も減ります。
そして、検証工数を少なくするという考え方で言えば、設定の数が多ければ多いほど、理論的にはその組み合わせの分だけ検証が必要になりますので検証ボリュームが増えてしまいますから、極力設定を減らす方が良いのではないでしょうか。ユーザーの利便性とトレードオフになってしまう可能性もありますが、そうであれば、いっそ設定をなくしてユーザ毎にソースコードを訳てしまえば良いのではないかと思います。
そんなことをしたら管理が大変だとか、ある修正をしようと思ったら対象になるソースコードがわけた分だけあって大変になるじゃないか、そんなご指摘がありそうです。確かにその通りだとは思いますが、でも、それこそ、そこはITを駆使して管理工数を下げる努力をするべきでないかと思います。
というのも設定で切り替えられるというのは、言い換えればパラメータが多いということで、人間の脳はそもそも、そんなに多くのパラメータを扱えるようにできてないため、パラメータが多くなれば開発（プログラミング）スピードそのものも遅くなって非効率的ではないかと思います。
それに、ソースコードが１つということで、１つの正しい修正で、全てのお客様の不具合が直る反面、１つの間違った修正が、特定のお客様だけでなく、他のお客様にも影響してしまうということが大きな問題で、それを懸念して、問題の起きているお客様以外にも別のお客様で影響がでないかを確認するために多くの時間と労力、すなわち工数を使ってしまうこと、また、それが故に、問題が起きているお客様へのリリースに時間がかかることの方が、ソースコード管理が煩雑になることよりも、よっぽど問題ではないかと思うからです。
もちろん、闇雲にソースを増やしていくのが得策だとは思いません。１本化できるところは積極的にすべきだと思います。ただ、１本化ありきとするのではなくて、社内の管理体制を整えた上で、パタメータを極力減らすことを優先した方が良いように、私は思います。