本日は、いよいよ第四弾「コミュニケーション編」です。
大企業をはじめグローバルな組織やチームでコラボレーションを経験すればするほどやはり課題となるのは円滑なコミュニケーションです。
恥ずかしながら私、外資系企業でお仕事をさせていただきながら英語が大の苦手です。
もちろん、ソフトウェア企業に長年勤めてきましたので、専門用語やマニュアルの読解、業務上のメールのやりとりくらいならなんとかなります。
しかし、電話や会議で米国人とネイティブに会話となるとアウトです。
とは言っても、仕事は高い品質でこなすのがプロというものですので、ここは知恵を絞ってビジュアルに解決する方法を考えてみましょう。
今日は、リリース前のソフトウェア製品の品質を事前に確認し、必要に応じて開発部（米国）の担当者に状況を報告、解決をはかっていくシーンを取り上げます。
こういった場合、通常は把握した問題ごとにメール（英語）で報告、必要に応じて再現手順や画面ショットを添付する方法が一般的かと思います。
この時、問題となるのは、メールの受信者が言葉はもちろん、製品に関する知識やスキルまで同等のレベルでない限り情報は正しく伝わりにくいということです。
結果的に、その確認のためのメールが何通も飛び交うことになり、状況は複雑さと混沌に包まれていきます。
こんな時は、Catalyst上にビジュアルなマップを共有することで、コミュニケーション上の複雑さを取り除くことができます。
ビジュアルコミュニケーションは、「読んで理解する」コミュニケーションを「見て理解する」コミュニケーションへと変えることで、言葉の壁をぶち破ることができるのです。
以下に品質の検証者と開発担当者とのコラボレーション方法をご紹介しましょう。
1. 品質の検証者は、製品のコンセプトを理解しながら製品の機能構造をマッピングします。
2. 不具合や疑問が生じた箇所のトピックには、問題トピックを追加します。
3. 品質報告の凡例（Ledgend）を設定し、必要に応じてトピックに記号を付与します。
4. 必要に応じて、ノートに詳細情報や再現手順、添付ファイルとして画面キャプチャを添付します。
5. 開発者に、共有したマップと凡例を示し、確認と修正を要求するメールを送信します。
* この時、マップや詳細情報、画像ファイルをメールに添付する必要はもはやありません。
6. 開発者は、凡例にしたがってマップ上からすばやく問題となる情報へアクセス、状況を把握します。
7. 必要に応じて、ノートにコメントを追記したり、修正を完了したらあらたに記号を変更します。
8. 開発者からの修正報告に伴い、再度検証を実行し、品質の改善を確認します。
Catalyst上にあるマップは、常に最新状態が保持されているので、開発者、品質検証者はいつでも、どこからでも最新の情報を正しく、すばやく把握することができます。
蓄積された個別で複数のやりとりメールの中から、製品全体の品質の最新状況を把握することがどれほど難しく、労力がかかることが想像してみてください。
常に地図（マップ）を見ながら、全体像と現在地を把握し、次の行動へと移ることができる－これがビジュアルコラボレーションの本質なのです。
凡例記号の定義と品質確認状況 （色と記号、画像を使ったビジュアルコミュニケーション例）
投稿
0 件のコメント:
コメントを投稿