ツッコんだ仕様説明でコミュニケーション

このドロップダウンリストは、このテーブルから読み込んで、この条件で出します。ただし、権限によって出る内容が違います。権限別に出る内容はこの資料のこれです。

ってな感じで、資料片手に仕様の伝達をしているのですが、ほぼ仕様書に仕様は書き表せているので、読み進めやすいような概要の説明と、理解が難しかしそうだった所を説明しています。

しかし、今日はもっとツッコんだ説明をしています。日本語の全てを覚えていない人もいるので、今日の説明の仕方は…このドロップダウンリストはXxxクラスのyyyメソッドを呼び出して取得し、エラーメッセージはXxxクラスのyyyメソッドにzzzを渡すとaaaが返ってきます。

のようにホワイトボードに図を書きながら、仕様・処理手順・具体的なクラスの使い方・作り方を説明しています。そんな順番で説明すると、これから作るべきプログラムの全体像がうかぶようで、あーあーとよくうなづいています。というより、私の頭の中にある完成予想図をトップダウンで伝達している感じかな。とにかく全ての言葉が通じるとは限らないので、わかりやすく、伝える事に重点を置いています。

日本語ぺらぺらの人も同席しているので、内部で質疑応答は可能だと思いますが、できるだけ直接伝えたい。これが後々のコミュニケーションに影響してくるので。ここで親近感を持っておかないと、日本と中国で離れた時に質問が上がりづらくなってしまいます。技術的な説明もしておくと、技術的に分からない所も質問してくれるので助かります。

技術的説明をしないと、この人には技術的質問はできないと思われてしまいます。どうすれば技術的にも頼ってもらえるか。とにかく実績を見せるしかありません。サンプルを作ったり、設計の思想を伝えたり、かっこつけたってなんにも伝わりません。だから、とにかく作る・見せる・説明する。それで何かを感じあえれば、コミュニケーションの開始です。仕様的な質問でも技術的な質問でもあげてきてくれるようになります。あの人に質問をすれば間違いない。そういう存在になっておかないと質問の投げ先が内部だけになってしまったり、自分の思いで作ってしまう事もあるので後々のテストに響きます。全員が全員仕様を間違いなく理解しているというのは考えにくいですから。その仕様理解のズレがなるべくないように、質問は直接投げて欲しい。投げやすい雰囲気・インフラを作る。

コミュニケーションはオフショア開発においてとても重要です。