トランスレーターになろう！デジタル化プロジェクトのリーダーの役割とは

デジタル化プロジェクト増えていますよね。

デジタル化（システム化）プロジェクトの場合、プロジェクトリーダーは ユーザー部門から出すのが一般的です。

利用部署・受益部署になるので、当然だと思います。

そして、デジタル化プロジェクトの場合 プロジェクトリーダーには もうひとつ役割が追加されます。

それは、ユーザー部門とシステム部門を橋渡しするトランスレーターとしての役割です。

今回は、私の経験から デジタル化プロジェクトにおけるプロジェクトリーダーのトランスレーターとしての役割について 紹介したいと思います。

ユーザー部署のメンバーへのトランスレーターとしての役割

今回は、以下２つを紹介します。

• システムでできることを伝える
• 既存業務ではなく業務改革として実施することを伝える

順番に紹介します。

システムでできることを伝える

ユーザー部門のメンバーは、実務のことはわかります。
一方で、システムでできることには 知識が不足しています。

全く業務でシステムを利用していないことはないと思いますので、他のシステムでの知識はあると思います。

でも、処理の中身までは わかりませんよね。

多くは、「こんな画面があった」「こんな機能があった」というぐらいの知識だと思います。

なので、実際の自部署の業務に当てはめると どこまでできるのか・どこまで言っていいのか 不安に思っているのが普通なのです。

プロジェクトリーダーは、この不安を取り除く必要があります。

それには、システムでできることをアドバイスしてあげることです。

えっ、デジタル化プロジェクト初めてだし とても無理 と思うかもしれません。

でも心配はありません。

システムは、ロジックで動いています。

ユーザーのやりたいことを整理して、ロジカルに説明できるようにしてあげれば良いのです。

システム部門との打ち合わせの場でも構いません。

「あなたの言いたいことは こうしたらこういう動きをさせたいということだよね」と言い換えてあげれば良いのです。

そして、システム部門にできるか確認を取ります。

先ずは、ここから始めます。

慣れてこれば、他の処理との矛盾にも 気付くようになります。

矛盾が見つかれば、もっと広い範囲で考えることができるようになります。

アドバイス力、どんどん上がっていくものです。

私自身は、最初のデジタル化プロジェクトの際に 一部の設計書やプログラミングを実際に行いました。

自ら実践すれば、知識・ノウハウを取得できます。

これからデジタル化プロジェクト増えると思います。

試してみることをオススメします。

既存業務ではなく業務改革として実施することを伝える

既存業務を そのままシステムに載せることは 絶対にやめた方が良いです。

既存業務は、過去からのしがらみや 今では必要がなくなった業務も含んでいます。

それをそのまま載せれば、複雑な処理になり 開発費も上昇します。

また、デジタル化の目的も考えてください。

業務改革のためにやるのですよね。

もっといえば、ビジネスモデルを変えるためにやるのだと思います。

ユーザー部門のメンバーは、自分の業務を効率化したいという動機が強いです。
なので、現行業務基準で考えます。

そうではなくって、現行業務を改革し さらにデジタル化でもっと効率化することを プロジェクトリーダーは伝えるべきです。

そして、実際に 業務改革を率先してサポートします。

システム部署のメンバーへのトランスレーターとしての役割

今回は、以下２つを紹介します。

• ユーザー部署のビジネスを伝える
• システム検討後、ユーザーの意図を伝える

順番に紹介します。

ユーザー部署のビジネスを伝える

システム部門は、実務を知りません。
日本の場合、ほとんどシステムベンダーに依頼することになりますので 最初は全く知識ゼロです。

プロジェクトリーダーは、ユーザー部署のビジネスを伝える必要があります。

私の場合は、以下３つの機会で実践していました。

• プロジェクト開始時
• 現行業務分析時
• ベンダーからの疑問発生時

プロジェクト開始時

時期としては、システム構想を始める前です。

どんなビジネスをどのように行なっているか 概要を説明します。

ビジネスを体系的・構造的に説明します。
先ずは、大きな括りから順番に詳細化していきます。

システムベンダーのメンバーは、システムつまり体系で ものごとを捉えます。

彼らの考え方に合わせて説明するのです。

現行業務分析時

システム構想に入れば、現行業務の分析工程があります。

この際に、いわゆる5W1Hまで 業務を説明していきます。

特に、流れる情報を中心に 説明します。

情報を扱うので当たり前のことなのですが、意外とできていないことが多いです。

システムベンダーのメンバーは、情報を頼りにして業務を理解します。
ここでも彼らの考え方に合わせるのです。

ベンダーからの疑問発生時

プロジェクトが本格的に始まれば、プロジェクトルームに一緒にいる時間が長くなります。

システムベンダーのメンバーから、ここがわからないという質問も出てきます。
または、疑問を持っていそうなメンバーもいるでしょう。

ベンダーのメンバー間で話をしている声も聞こえます。

この機会 とても重要です。

多くの場合、メンバー全員が感じているものです。

メンバー全員に説明しましょう。

みんな注目！今から○○について説明します。
宣言して実施すれば、どんどん質問も出てきます。

疑問が発生した時の議論が 一番残ります。

そして意外とこんな重要なことを伝えていなかったんだと思う瞬間でもあります。

システム検討後、ユーザーの意図を伝える

システムの仕様検討段階になるとユーザー部門・システム部門のメンバーでの打ち合わせが始まります。

そして、徐々に仕様が決まっていきます。

この際にプロジェクトリーダーが行う大切なことは、打ち合わせ後の時間の使い方です。

ユーザー部門のメンバーは、もういなくなっていますよね。

この時間を使って、今行われた打ち合わせの振り返りを システム部門のメンバーと行うのです。

特に、ユーザー側の意図を プロジェクトリーダーが咀嚼して伝えます。

打ち合わせでは、ユーザー側の要求には順位付けが曖昧なことが多いです。
仕様を決めるのが主になるので、どうしてもこうした傾向にあります。

この優先順位について説明します。

例えば、○○の言っていたことは こういうこと。
システムの目的からして これは譲れない。

こうした話をします。

こうすることによって、目的から乖離しないシステムができるのです。

私が実践したデジタル化プロジェクトは、ほとんどこの時間で システムの仕様が決まっています。

まとめ

デジタル化プロジェクトの場合、プロジェクトリーダーには もうひとつ役割が追加されます。

それは、ユーザー部門とシステム部門を橋渡しするトランスレーターとしての役割です。

今回は、私の経験から デジタル化プロジェクトにおけるプロジェクトリーダーのトランスレーターとしての役割について 紹介しました。

ユーザー部署のメンバーへのトランスレーターとしての役割として、以下２つ紹介しました。

• システムでできることを伝える
• 既存業務ではなく業務改革として実施することを伝える

システム部署のメンバーへのトランスレーターとしての役割として、以下２つ紹介しました。

• ユーザー部署のビジネスを伝える
• システム検討後、ユーザーの意図を伝える

プロジェクトリーダーが ユーザー部門とシステム部門を橋渡しすることによって、当初のデジタル化の目的を達成するシステムができると考えています。

そして、デジタル化プロジェクトは 今後増えていきます。

プロジェクトリーダーのトランスレーターとしての役割 ますます重要になると思います。