要求仕様の拾い方

この記事は約4分で読めます。

何ごとにも多面性があるし、ひとつのものごとも、視点によって全然見え方が違うという話。

DHMOって知ってますか。リンク先を読めば納得してもらえると思うのだが、ひとつの物を説明するときでも、言い方ひとつで、読み手の印象というものは好きなように操作できてしまうという、好例だ。

私たちは、そういったDHMOのような例に踊らされている。
情報過多になった現在、多くの人が情報に依存する社会になり、ものごとの本質が見えにくくなっている。

逆に、それを利用したプロパガンダやマーケティングが、昔よりも有効になっている。

こんなDHMOが蔓延した世の中だからこそ、真に要求を満たしていない製品でも、宣伝次第で満たしているようにみせかけられてしまう。

とくに日本において、要求仕様というものは言外に含まれているものが多くあるため、一字一句漏らさずに要求をRFPなどで出す文化の欧米系企業とのやり取りで、ずれが生じやすい。

ちょっと極端な例を使って説明してみよう。

たとえば、新しい携帯電話をつくるプロジェクトで、要求仕様が以下だったとする。

  • 電話で話ができる
  • 携帯メールができる

この場合、下手をすると以下のような製品ができあがる。

  • 電話で話ができる
  • 携帯メールができる
  • 携帯メール操作中は電話を受信できない

これは、欧米式に考えれば「要求を満たしている」と判断できてしまう。おそろしい。

この違いは、重要視している基準の違いから起きる。

欧米式の場合、要求仕様をバイブルにして作業がすすむ。
日本式の場合、想定される使用方法をバイブルにして作業がすすむ。

じつは日本企業でも、要求仕様のひとつひとつを単なる項目としてしか処理できない、欧米式な考え方のPMや開発者が増えているという悲しい事実がある。

たぶん第二次産業ではもっとマシなのだろう。
トヨタを頂点とした日本人のアドバンテージが世界中に認識されている。

しかし、国際プロジェクト(オフショアなど)において、欧米式の考え方をまったく理解しない(することができない)日本人側の問題も大いにある。
国際社会の重要性とかいう言葉が世に出てどれだけたったか分からないか、いまだに思想の国際化どころか、文化を比較して差分を認識することすらできない人間が日本の大企業にはガッカリするほど多いという事実にショックを覚える。

インドに話を限定すれば、日本とインドとはWin-Winの関係が持てるだけの多くの素地がある。だからこそマーケットシェアをもっと獲得してほしいものだが、日本人的なモノづくりの考え方が理解できなければ、決してうまくいかない。
もっと真剣にむかいあって、When you are in Rome, do as Romans do(郷に入れば郷に従え)の心を持って、努力を重ねていく必要がある。

でなければ、日本人たちの少ない言葉から最大限の要求仕様を拾うことができないのだ。

はっきりいって、開発が遠隔地で、言語の問題もあって、文化(企業文化、生活文化)の違いがあるような状況では、お互いの人的資産をうまく生かしてスパイラルモデルを組むことはできない。従って、最もポピュラーでレガシーな、ウォーターフォールモデルで進めるのが現実的だ。その場合、工程ごとに日本とインドのどちらで作業を行うか分担が決まることになる。

そして、工程移行の際には前工程からのインプットと、次工程で出されるべきアウトプットの定義がある。ここも要求仕様の拾い方と同様、拾い方を間違えるととんでもないことになる。

従って要求仕様のひとつひとつを、ことばの表面的なものだけ翻訳して、伝えたつもりになっていると、痛い目をみるどころか、プロジェクトは必ず失敗する。

いったい何がしたいのか、相手はどんなシチュエーションを想定してそんなことを要求しているのか、背景をしっかりとつかむことが必要だ。

そもそもこれがブリッジエンジニア(オンサイトコーディネーター)の行うべき作業かどうかという定義の問題もあるが、それはまた別の話。

そして、実はインドからチームの一部を日本に呼ぶより、日本の企業からインドに常駐者を派遣するほうが、なにかと上手くいくというのも、別の話にしよう。

なんだか書きたいことがまとまらないままに書いてしまったが、
このような差が起きるのは、会社が組織として個人に求めているものが、日本とインド(欧米)で違うという理由がある。

それも長くなるから別の話にしようw

コメント