【コミュニケーション】チャットを投稿する前に、受け取った相手がその後どう行動するか予測して、数手先を読んで返せるとカッコイイ
はじめに
対象
- 何故かチャットのやり取りが長引きがちな開発者向け。
- もう少し気の利いた返しをして欲しい開発者向け。
幹事より事例
幹事のお仕事
出欠確認・会場の用意・会費の精算など、地味な作業ですが大事です。別に立候補や推薦ではないのですが、特に大きな懸念事項がなければ流れで引き受けることが多いです。というか、本記事のテーマである数手先を読んだ行動により、誰よりも動くのが早いからかもしれません。
例えば飲み会であれば、
- 参加メンバーと予算・場所を協議する。
- 調整さんで日時を決定する。
- 会費の精算を行う。
のような具合です。旅行や企業絡みだともう少し複雑ですが、今回は簡単な例でいきます。
私も察してちゃんは嫌いなので、最低限の回答が返ってくれば良いと割り切っています。質問したこと以上を求めるのもおかしな話ですしね。それでも幹事をやっていて助かる返信と、その後の対応に悪影響がある返信もあるのは事実。
その返信の質を分けるポイントが「受け取った相手がその後どう行動するか予測して、数手先を読んで返せる」かです。
気の利いた返事
飲み会で店を決めるとき、参加メンバーの交通アクセスが良いこと、アレルギーや苦手などがあるかどうかは、最低限確認する事項です。会社や趣味の活動場所があるなら、幹事から最寄駅前を提示することはできます。これは幹事視点での先読みですね。
何もなしにただ「どこで飲もうか」と聞いてしまうと、無限大に発散して収集が付かなくなる恐れがあります。誘導尋問とまではいかなくとも、ある程度の制約を事前に適用し、選択肢を絞っておく方が参加メンバーも返信しやすくなります。
ただ住んでいる場所やアレルギーの話題を、幹事から振るのは少々勇気が要ります。というか現代日本では最早タブーでしょう。
活動場所がオンラインの場合、帰りの路線と方面が分かるだけでも大分違います。極端な話、全員が千葉県民なら東京に出る必要はないですし。逆に地方組がいる場合、新幹線や空港からのアクセスも考えなければいけませんし。
アレルギーであることが分かっていれば、店選びの段階で食物アレルギーに対応してくれる店を選ぶことも可能です。生モノが苦手なら魚料理だけの店は外すなど工夫できます。何店舗かに絞った後に「実は……」となるより遥かにマシです。幹事の二度手間や徒労を防げます。
困る返事
困る返事や話が進まない返事は、言ってみれば気の利いた返事の逆です。
多くのメンバーが相談をしているときは何も言わず、場所が決まった後で「そんな場所行けない」「住んでる方面すら開示したくない」「私肉嫌い」などと文句を付けるのは筋違いです。なら相談しているときに言え、という話でして。いわゆる情報の後出しですね。
また特定の店がいいとリクエストしたり、絶対食べたい物宣言などされると、調整が効きづらく困ってしまいます。絶対に食べたいものと他の誰かの苦手が衝突したら、冷徹と言われようが幹事がどちらかを優先しないといけなくなりますし。
これに限った話ではありませんが、このように幹事の身動きが取りづらくなるような、デバフをかけてくる返事は総じて困る返事です。味方にPvPをするメリットはありませんので、どうせ先読みするなら妨害ではなく支援という形で手番を進めましょう。
業務における数手先
なぜチャットで確認を取っているのか
GOサインが欲しくてチャットを送っているケースがあります。これに親指を上げた手の絵文字を付ける方がいますが、その解釈は人によって異なることがあるようです。ちなみにカナダでは「親指を立てる絵文字は同意にあたる」という判決が下されたそうです。
テキストメッセージで作物を注文した業者に対し、「親指の絵文字」で応えた農家が作物を納入しなかった問題で、カナダの裁判所が「親指を立てる絵文字は契約上の合意にあたる」として農家に金銭の支払いを命じました。
「親指を立てる絵文字は同意にあたる」との判決が下される - GIGAZINE
とはいえ、ここは日本です。しかも社内でのやり取りにおいて、いちいち裁判で訴えることもありませんし、仕事のやり直しが面倒になるだけです。
親指を上げた手の絵文字だけだと、GOサインなのかどうなのか判断できません。Teams勢この絵文字付けがち。それに絵文字は後から消すこともできてしまいます。できればきちんとテキストとして残る形でGOサインを出した方が良いでしょう。
判断できないなりに「ではこの方向で作業進めますね」と、追加で念押しした上で作業を進めることはできるのですが、最初からGOサイン出してくれてたらこのやり取り必要ないよね？という現象はあるあるです。
作業を前に進めるためのやり取り
業務上の仕様調整は、飲み会のセッティングよりはドライです。チャットであれチケットであれ、開発者側からコミュニケーションの必要が生じるのは、作業内容の確認か不足情報の催促です。
以下の記事でも軽く触れていますが、情報の不足については作業を進めるのに必要なヒアリング結果やデータは、なるべくまとめて最初に授受するのがよいでしょう。
それでも不足が生じた場合はヒアリングを行います。聞かれたことに答えるだけでなく、もしその返信を受けた開発者が更に質問しそうな項目があれば、合わせて回答できると捗ります。
一手先だけしか読まない回答では不十分です。例えば飲食店で、
客「カレーありますか？」
店員「はい、ございます」
客「じゃあカレーください」
店員「シーフードカレーとキーマカレーがございまして、セットで云々」
よりは、
客「カレーありますか？」
店員「はい、メニューのこのページです。各カレーにはセットで云々」
の方がスムーズです。お客様はカレーがあると知ったら、何らかのカレーを注文するのですから、種類があるのなら同時に答えれば話が早いです。
飲食店の例なので直ぐにレスポンスが返ってきますが、これがIT企業の現場と営業と客との間の折衝であれば、ラリー1回に1週間待ちが発生してもおかしくありません。
プロジェクト本来の目的を遂行
プロジェクトとしての本質的な目的は、機能改修や実装などの作業を進めることであって、問い合わせに回答することそのものではありません。作業の障害になっている「必要な情報がない」「詳細が分からない」「実装の方向性が決められない」状態の解消です。
だからただ回答するだけ・返信するだけではなく、数手先を予測した上で追加作業が発生しそうならば事前に策を打ち、開発者の次の作業がスムーズに進むように動けばよいのです。
前項の飲食店でのやり取りに似たチャットは、Webアプリを作る現場では珍しくありません。人と人との間のやり取りですから、AIで効率化を図るのは難しい部分でしょう。AIに作業をさせる開発者が業務を進めるための確認や情報が取れない状態ということですから。
この「作業を円滑に進めるためのやり取りである」ということを返事をする側が意識して行動を変えるだけで、プロジェクトの開発スピードや働きやすさは大きく向上すると考えています。業務遂行上の大きなボトルネックの一つなので。
おわりに
聞かれたことにそのまま答えるのは最低限ですが。それに加え「自分が書いたことによって、相手がどのように判断に困るか・次の行動を起こせるか」を考えて返信すると、話が進みやすくてとても助かると思います。
これを行うためには相手の作業をよく知っている必要がありますが、それは日々の勉強の積み重ねであり、互いの業務を理解しようとする意志の成せる技です。よりザックリ言ってしまえば、自分のことしか見えてないと、返信が自分本位になってしまうんですね。
コミュニケーションというのは、相手がいてこそのものですから。
Discussion