システム要件定義における「普通」の罠

突然ですが、1＋１は、いくつでしょう？
「え？なに？そりゃ普通２でしょ？いちいち時間ないんだからそんなこと聞かないでよ！」
と思われた方もいるかもしれないですね。

でも、この「普通」という言葉が非常に罠に陥りやすいキーワードなのです。

ちなみに、先ほど問題に対する回答ですが、

答えは、「１０」です。

そう、この問題は二進数が前提でした。

「いや、問題に二進数って書いてないやん！」と思われたでしょう。

ただ、十進数とも書いてないですよね。

「普通は、十進数と思うじゃん！」

そういう反論もあるかもしれませんが、この会話している相手が、コンピュータ基礎学に関する講義であればその「普通」というのは一気に覆ります。

まぁ何が言いたいかというと相手が変われば「普通」というキーワードは意味をなさないということです。

相手が変われば「普通」は変わってくる

システム要件定義をする上では、「普通」というキーワードは完全にNGです。

顧客の業態に応じて、相手の「普通」は異なるからです。

自動車産業、不動産産業、生産業、広告業界、それぞれに応じて商習慣が異なる為、話の土台を合わせる必要があります。

それが「前提」を決めるということです。

相手と話す際に「前提」を決めておくべし

先程の例だと、「この問題は、二進数です」というように前提を決めておくことで、回答に誤りがなくなります。

ただ、システムの要件定義を決める際、質問してくる相手が必ず、「前提」を置いてくれるとは限りません。

したがってヒアリングする私たちが「前提」を置いていく必要があるのです。

「前提」を決める上で重要なことは２つあります。

１.相手の文化・商習慣を理解する。
2.これまでの成功体験を一般論化する。

相手の文化・商習慣を理解すること

相手はグローバル企業で、東南アジア、欧米だったり日本ではないかもしれません。そうなると商習慣は異なるし、相手の求めることは異なってきます。

それらの企業に対して、「今回の提案は日本企業向けを前提としています」などと言っても全くナンセンスです。

したがって、相手がどのような状況でビジネスを展開しているかを知っておくことは重要です。

これまでの成功体験を一般論化する

相手の文化・商習慣を捉えることができたら、それらに対してのベストプラクティスを提案します。

このベストプラクティスは、これまでの成功体験の積み重ねに応じて構築されたものですから、それらをベースに提案していくと良いでしょう。

逆にそれらにFixしない部分Gapに対して対応方針を考えていくと良いでしょう。

まとめ

今回は、システム要件定義において、自分の目線となる「普通」で検討していくことは危険であることを書きました。

ポイントは、以下のようにまとめておきます。

相手が変われば「普通」は変わってくる
相手と話す際に「前提」を決めておくべし
相手の文化・商習慣を理解すること
これまでの成功体験を一般論化する

★この記事が面白いと思っていただけたら「スキ」を押していただけると次の記事への励みになります!!!