共通言語を使用することの留意点

Toshiki Okada/t-okada

今回は私が管理をしているプロジェクトで起こったことをメモ書き&考察したく記事をかいてみました。

基本的な部分も含まれますので、PM業に慣れている方でも、初心を振り返る意味で活用いただけると幸いです。

この記事を読んでもらいたい方

・現在業務でPMをやられている方

・プロジェクトで開発外注を行う可能性のあるPM

・これから開発外注を行う、もしくは検討している方

とあるプロジェクトで・・

「この件、あとは任せるからよろしく頼むね」

同じプロジェクト内で別の機能を担当していた社内の人が取りまとめていた事項をそのまま投げられたため、私は請け負いました。

その社内の方は私よりも実務経験が長いため、あまり考えず信用して引き継いだですが、仕様について担当の顧客とすり合わせを行った結果、お客さんと弊社側の想定していた仕様と全く別のものを想像していたことが発覚しました。

原因としては

  • そもそも仕様や議事録を記録としてまとめていない(これはPMとしては基本はありえないことですが、経験や業務が慣れてくると口頭合意で進めてしまいがち)
  • 機能に関する説明が不十分

などが考えられましたが、意外なことに「共通言語」を使用することの落とし穴もあるのではないかと思いました。

普段から私も私以外のメンバーも「共通言語」を使用し、互いの認識相違の発生を防いでいたつもりではありましたが、今回の件を私なりに考察した結果

共通言語における認識相違」ということも起こり得たのではないかと考えています。

共通言語を使用する際の落とし穴

PM業をしている上ではよく「共通言語を使用しましょう」ということを耳にするかと思います。

この理由としては、チーム内の認識齟齬を減らし、各メンバーの共通認識を持つためかと思います。

上記の「共通言語を使用する」という部分は私も同意だと考えますが、

私はさらに「その使用している共通言語の定義が本当に自分以外の人にとっても定義が同じなのか?

ということを強調したいです。

今や新しい技術や言葉が次々と出ている今日この頃かと思いますが、例えばみなさんは「ゼロトラスト」を説明してくださいと言われた際はどのように説明しますか?

上記の言葉を検索しますと例えば下記のような説明がありえるかと思います。

最近流行りの認証方式で社内のネットワークでさえ疑いをかけ、認証する

すべてのトラフィックを信頼しないことを前提とし、検査、ログ取得を行うこと

厳しい ID 検証プロセスに基づいたネットワーク・セキュリティ・モデル」etc…

あるいはゼロトラスト自体をネットワークのことを指している記事も見かけました。

上記のように言葉の捉え方や各個人の回答が異なるかと思います。

共通言語における定義の認識齟齬

先述した個人の発する言葉の定義の違いが起きてしまったことについて自分の仮説を下記にまとめてみました。

  1. 良くも悪くも、今や新しい技術や難しい言葉もgoogle検索すればすぐに知りたい情報が得られる。
  2. 1.に関しては、悪く言えば「間違った意味や言葉の定義」で理解してしまう可能性もある。(もちろん自分も相手も含む)
  3. 自分と相手との言葉の意味&定義の差が生まれてしまい、例え共通言語を意識して使用したとしても互いの認識に齟齬が生じる可能性ある。

これ以外も例えば、相手と自分の言葉の理解度による差や説明における解釈の差も、ありえるかと思います。

言葉の認識齟齬を防ぐには?

今回私が感じたことは、昨今のPM業において共通言語を活用するだけでは、足りず「互いの使用する共通言語の定義の確認」も必要ではないかと思います。

特にオンライン上では相手の表情や雰囲気もわからないため、少ししつこいぐらいに確認したほうが良いかなとも思います。

例えば、「〇〇って言葉の意味ってどうゆう意味で使ってます?」だったり「今の〇〇は▲▲を指してますよね?」と適宜確認することも有効かと思います。

(もちろんやりすぎは、相手に不快な思いもさせてしまうこともあるため、注意が必要かと思います)

まとめ:専門用語は使わない方がよいのか?

言葉の認識齟齬が起きるケースが多いのは個々の理解に差が出やすい専門用語が多いかと思います。

かといって、ITに関わる以上は全く使用しないのは難しいかと思います。

結局は今後、プロジェクト内でも適切に使用するために自分が使用している言葉の定義を正確に伝え、活用していくのが手かと思います。

オンラインでの業務が続く中、少しでも参考になれば幸いです。

追伸:slack着信音、所属している会社のチャンネルで設定している音は「Wow」です。

いいね!
この記事を書いたPM
Toshiki Okada/t-okada
@t-okada
  • Twitter

大学卒業後、金融機関に所属し、個人渉外を担当。その後、ブロックチェーン、DLTを提供しているITスタートアップに所属し、バックエンドエンジニアを経験後、プロジェクトマネージャーに転向。
主にDLTの技術を使用した決済のプロジェクトに従事し、複数のQR決済サービス案件を担当。現在は、別のブロックチェーンスタートアップに転向し、ブロックチェーンをベースとしたスマートコントラクト領域の案件をプロジェクトマネジャーとして担当。
金融機関 -> スタートアップ プロジェクトマネジャーなので、様々な視点で記事を発信できればと思います。