役割は当たり前？

プロコン塾14期生の長田真由美です。

欧州から帰国して5年半、日本と海外の混成チームでサプライチェーン関連のプロセス改革・新規サービス導入プロジェクトを担当して来ました。

サプライチェーンのプロセス改革の多くは、大なり小なりシステム開発を伴い、部分最適より全体最適を目指す方が効果が高いため、多くの関連部署を巻き込むものとなります。

各部署は異なるKPI (Key Performance Indicator) 、部分最適のプロセス・システムを持っているため、全ての関連部署間の利害を調整して、1冊のビジネスルールブック、プロセス定義書、ビジネス要件定義書にまとめ上げるのは相当な苦労を伴います。

その後、システム側に内容説明しシステム開発をしてもらうのですが、システムの方も調達・工場・本社経理・販売など異なるシステムを使っていたりしますから、すり合わせ作業が相当量に上ります。

そこまでは想定内の苦労なのですが、数年前に日本のビジネスチーム・海外のシステムチームの組合せで改革プロジェクトを遂行した時に、とんでもない事態が起こりました。

日本では、通常ビジネス側にはシステムが分かる人を置かず、社内のシステム担当部署又は社外のシステム会社がビジネス・システムの双方が分かるSEを揃え、ビジネス側から詳細なヒアリングをしてシステム要件定義をすることが殆どのようです。つまり、日本のビジネスユーザーは導入したい改革内容をビジネス用語で伝えるだけで、システム部隊が詳細な書類に落とし、開発・テストも完璧に終えて、ユーザーテスト時にはバグなど殆どなく、ユーザートレーニングの代わりとしてユーザーテストを行う、という役割分担が当たり前と思っています。

ところが海外では、ビジネス側にプロジェクト専任担当部隊や兼任でもプロジェクトのエキスパートを置いて、システムに詳しくないビジネスユーザーからの要件聞き取り及びシステム側に渡す詳細ドキュメント作成を、ビジネス側が担うことが多いのです。

数年前のとんでもない事態は、上記のギャップに加え、そのギャップを双方がなかなか認識できなかったことから起こりました。

日本のビジネス側は大枠の改革内容を伝えるだけで、後はシステム側が不明点をどんどん質問してきて詳細ドキュメントを作り、完璧な開発・テストをしてシステムを導入してくれると思い込んでいますし、海外のシステム側はビジネス側がシステムにも分かるような詳細要件ドキュメントを出してくれると思っています。ところが、いつまで待ってもビジネス側から詳細要件ドキュメントは出てきません。

システム側としては詳細が良く分からないものの、スケジュールが押しているので仕方なく自分たちの解釈で開発を行い、ユーザーテストの段階で何百個もの「バグ」が出てしまったのでした。

プロジェクトの最終工程で導入直前期であるユーザーテストの段階で何百個のバグが出る事態など見たこともない日本のビジネス側はパニックになり怒り心頭、システム側と不毛な大ゲンカの連続。更に、「バグを出すためにユーザーテストがあるのでしょ」という海外のシステム側の発言が火に油を注ぐ事に。。。

プロジェクトは1年も遅れ、挙句の果てに導入をあきらめて手仕舞いをすることになってしまったのでした。

要件定義・バグ出しなど、日本と海外ではビジネスとシステム側の役割・期待がかなり異なっていることに早々に気付いて手を打たなかったのが敗因。海外流の「アバウト」さが日本のビジネスユーザー側には許せなかった、という部分もありました。

 

このようなギャップは日本vs海外でなくても、日本国内でも大いに起こり得ます。私が数年前までいた本社と今働いている関連会社では組織の作り方も、各組織が何を担当するかの役割分担も全く違う。今でも毎日のように「え？」と思うことの連続です。

重要なのは、新たな人と新たな仕事をする時、①どういうタスクがあるか、②相手はどういう組織で誰がどこまでの役割・権限を担っているか、③相手がどこまでをやれるか、④自分がどこまでをやれるか、を毎回詳細に確認することなのですね。

その中で、相手の自分に対する期待・自分が想定する業務範囲と比べ抜け漏れがないか確認でき、不足するリソースを事前に探すか、そのタスクをあきらめることに合意しておくことが出来ます。

自分でもタスクリストのドラフトを作り、それを相手に提示後、本当に誤解や齟齬や抜け漏れがないか、「質問力」をもって徹底的に確認しておく。

誤解や齟齬が見つかると最初は相手との話が難しくなるかもしれませんが、最終的にはそれを乗り越えることが後悔のない仕事の完遂につながるのだと思います。

「当たり前と思うな」－　前回の講義での大切なポイントの一つでしたね。