今、とある大手企業のプロジェクトでクラウド移行案件に携わっています。

要件定義の後半から参画し、今は基本設計フェーズ。インフラ担当ではありますが、詳細設計以降は開発にも携わる予定です。

 

実は今年の3月15日で会社（零細ですが）を退職したのですが、前職では10年ほど自社プロダクトの設計、開発、テスト、運用・保守をやってきました。

インフラ（AWS）も自分たちで構築し、SaaS形式のサービスを提供してきました。

お客様は直エンド。お客様はシステムの事は分からないので、いわば自分たちのやりたいようにプロダクトを作れてきました。

 

しかし、今携わっているプロジェクトは、自分のやりたいように出来ない。

なぜなら、色んなステークホルダーがいるから。

自分ではこの方が良い、と思っていても、相手にとって受け入れがたい事もたくさんあります。

 

そして、私が今一番苦労しているのが、認識の相違。同じ用語を使っていたとしても、人によって受け取り方が違います。

認識の相違を無くすためには、コミュニケーションで解消していく必要があるとはよく聞きますが、

コミュニケーションはあくまで手段でしかありません。

それでは、認識の相違を無くすためにはどうすれば良いか。

 

認識の相違は、相手とのベクトルの向き先が違う事によって生じます。

それをコミュニケーションで解消していく形が多いのですが、始めから向かっているベクトルが全く違うと、

いくらコミュニケーションを取っても解消に時間がかかるでしょう。

では、同じベクトルを向くにはどうすれば良いか。

 

それは相手を知る事です。

システム開発は、必ず現状分析から入ります。これは相手の業務、いわば、ヒト、モノ、カネ、そして情報の「流れ」を知る事です。

私が参画したのは要件定義から。つまり現状分析を知らないのです。だから相手の事をよく理解できていない。

確かに要件定義で何をするかは決まった。次に仕様化していくにあたり、具体的にどのように要件を実現していくかを設計として落とし込んでいく。

ですがその過程で、「これってそういう事だったの？」とか、「これってどこから出てきたの？」という場面に度々直面します。

「そういう事だったのなら、こんな設計しないのに・・・」とかも。まさに点と点が繋がらない状態です。

なるべく時間を取って現状分析の資料に目を通していってますが、文面だけだと、現状分析した人、された人の当時の意図が抜け落ちてる事がよくありますね。

はぁ…相手を知るってほんと大変…

 

今の時代、情報は与えられるモノでは無く、自分から掴みにいかないといけません。

皆様も、ただ単にシステム作りに邁進するのではなく、相手を知り、相手の意図をくみ取った上で、システム開発に臨んでみては如何でしょうか。

自戒の意味も込めて、私自身も相手を知る努力を惜しまずやっていけたらと思います。