ユーザーと要件を固めていっているときに、始めは特に制約を設けることなくヒアリングをしたりします。
こうすることで、ユーザーの要望が次々と出てくるのですが、どうしても工数やコストの関係からその中で取捨選択していかなくてはなりません。
ただ、その制約なき要件定義の場においてユーザーがやりたいことと実際に出来ることへのギャップというものが出てきます。
そういったものを無視してプロジェクトを進めていくと、後で大きな問題になることが多々出てきたり。
反射神経的に「YES」というユーザーの心理
特にITにあまり詳しくないユーザーとヒアリングしていると、ある機能を実装するかどうかを決める段階で、「この機能を使えばこういう便利なことができますよ」とこちらから提案すれば、ユーザーはだいたい「YES」の答えを出してきたりします。
実際にその便利な機能を使うかどうかはその時点でイメージできてなくても、「あれば使うだろう」とか「付けれるというんだから取り合えず付けておこう」というような感じで、出来るんならお願いしますというような感じで反射神経的に「YES」と応えているケースもあり注意が必要になります。
まぁ、これはそれによって工数や必要な機材が変わってきたりして、それはつまりコストに関わるわけですから、作り手側から見れば当初の話で納期に比較的余裕があればあまり痛くもありません。
しかし、納期がそれなりにきつい状況になっていたり、プロジェクト開始後にユーザー要望として出てきたのなら話は別になります。
それが、本当に必要なものなのか、この人は取り合えず「YES」と言っているだけではないのか、という点を見破って説得していかないと、キリ無くユーザーの要望は増大していきます。
得てして業務要件に直接関わりの無い便利機能というのはあまり使われてなかったりもします。
使うときは効率よく利用できる機能なんですが、そもそもその利用する機会が圧倒的に少ないわけですから、その機能を実装するコストさえペイできていないということもあったりします。
そして、そのコスト意識というのはユーザー側はあまり持っていません。
まぁ、追加要件の開発費の見積もり見せればコロッと意見を変えたりもしますが。
こういったことにならないためにも、予め選択肢を絞って提案するというのも必要になります。
これは、これ以上の工数を増加するとプロジェクトが破綻するとか裏の意図もあったりもするんですが、ユーザーに選択権を持たせると要望が増加の一途を辿るのであれば、「こういう実装にします」という設計をしてしまってそれを納得してもらうということも必要です。
そして、不便な部分を補うための代替案（特にこの場合は業務的な回避策になるでしょうけど）を用意して納得してもらうための材料にしておく必要もあるでしょう。
どうしてもそういった機能を付けたいというのであれば、後はスケジュールの調整やコストの増加、その他に実装する機能とのトレードオフを選択してもらうしかないでしょうけど。
何れにせよ要件を決める段階では、ユーザーの思いつきに振り回されることなく、ユーザーの思い付きかどうかを見極める必要がでてきます。
あえてシステムに制約を持たせることの意味
「自由に操作できるシステムがよいですか？それとも制約があるシステムがよいですか？」という質問には、だいたい前者をとるでしょう。
ただ、システム化というのは自由度が下がるものだったりします。
そして、あえて自由度を下げる必要もでてきます。
システム化は処理やフローを効率化できますが、そもそも自由度は下がります。
ペーパレス化をするシステムがあったとして、ワークフローとして承認の手続きを決めれたりもしますが、その操作は面倒なものであったり、承認者が不在の場合にどうするんだとか、急いで手続きをしたいという場合にどうするんだとか、細かいところではあるものの不都合が生じます。
こうしたことを、一番自由に処理させるには紙で業務をまわしてしまうことです。
これはもちろん時代に反していることではありますけど、承認のフローは組織図と一致したりするため、各々が頭の中にあり、急ぐ場合もその紙をそれぞれの担当者に持っていって承認を得ることで対応できます。
しかし、業務が妨げられるとかいちいち手で持ちまわすのが面倒ということで、ほとんどの人は嫌うでしょうけど、嫌うから導入したシステムに対して、その自由度の低さにまた別の嫌いが生じているわけです。
システムは、業務の一部をモデル化しただけであって、その全てをモデル化できているわけではありません。
なので、当然自由度は下がります。
その全てをシステム化するには膨大な工数がかかりますし、その例外のように取り扱われるケースというのは、ごく一部だったりもしますので、先ほど書いたような工数に見合わないケースも多々あります。
しかし、システム化というとその処理効率だけでなく自由化というキーワードも付いて回るイメージを持っている人も多いわけです。
また、自由度が高くなると業務的にも利用シーンが多岐にわたって現場が混乱することもあります。
自由になるというのは色んな使い方が出来るということです。
しかし、その色んな使い方をされれば、自分たちが困るということも当然あります。
システムを自由にして、業務をルールで縛るという本末転倒な使い方をしようとしている場合さえあります。
これでは、システムによって効率化することが水の泡になるでしょう。
なので、あえて制約を持たせることが必要になってきますが、ユーザーの要件としては自由な使い方が出来る方向に進みがちです。
システム化することで制約を持たせるのは、業務を統制する働きもあります。
自由が利きすぎると色々な不正や権限の乱用にもつながるわけで、統制するにはそれしか出来ないという制限を持たせることにが必要になってきます。
そういった自由化することへのリスクと業務的な不都合を天秤にかけた場合、後者の方を選択されがちなので、注意が必要になるわけです。
ユーザーの要件を聞く際には不自由にすることの意味というものをきちんと説明して納得してもらうことも重要になってくると感じます。
