はじめに
デフエンジニアの会アドベントカレンダー20日目に参加しています。
+++
クライアントワークでは、口頭での説明や打ち合わせを前提とした進行が一般的。
依頼内容のすり合わせや仕様調整は、会話の中で補足され、その場で方向性が決まっていく。
一方で、私の業務環境では少し前提が異なる。
クライアントは同じ組織内ではあるが別の課になることが多く、
依頼ごとに専用のチャットスペースを作成し、基本的なやり取りはすべてチャット上で行われる。
このチャットには、私だけでなく、きこえる担当者や関係者も参加する。
必要に応じて Google Meet などで補足説明を行うこともあるが、
あくまで主軸はテキストコミュニケーション。
本記事では、このような環境でクライアントワークを進める中で形成された、
クライアント向けドキュメントの考え方と役割について整理したい。
私のクライアントワークの進め方
ありがたいことに、私の職場では、
クライアントとのやり取りを始める前に、リーダーがあらかじめ
「依頼の進め方」や「やり取りの前提」をクライアントに説明してくれている。
このやり方はきこえない私にとって非常にありがたい。
そのうえで、実際の業務は次のような流れで進む。
-
クライアントと私の1対1での依頼内容ヒアリング
（基本は担当がクライアントとチャット上で話をするが、リーダーや他のメンバーも
見ることができるため、別のスペースで相談しやすいという利点もある） -
チャット上での認識合わせ
-
仕様の整理・確定
-
実装内容の提案
-
クライアントの承諾
-
開発・納品
この流れの中で、口頭での即時補足に頼る場面はほとんどない。
その代わり、ヒアリング内容、仕様、提案内容はすべてテキストとして残す。
（Googleチャットがあるため、自然とログが溜まるのでまとめやすいのも利点）
この進め方は、聞こえないエンジニアである私にとっては必然だが、
結果としてクライアントワーク全体を安定させる効果を持っていると感じる。
クライアントワークで起きがちな問題
一般的なクライアントワークでは、次のような問題が起こりやすい。
- 言った・聞いていないという認識の食い違い
- 想定していた仕様と違うと言われる
- どこまで対応すると思っていたかが曖昧になる
- 修正要望が後から際限なく増える
これらは、コミュニケーション能力の問題と捉えられがち。
しかし実際には、情報がどのような形で残されているかという構造の問題なことが多い。
口頭説明はその場では便利だが、
後から「何が決まっていたのか」を正確に振り返ることができない。
特に、単独で業務を進める場合、この曖昧さはそのままリスクになる。
（とはいえ、GoogleChatはGeminiの要約機能が出てきたおかげで、
文字起こしや要約が残るようになった。この点は歓迎したい。）
聞こえないエンジニアにとっての前提条件
きこえないエンジニアがクライアントワークを行う場合、
いくつかの前提条件がある。
- 音声での即時補足に頼れない
- 曖昧な表現をその場で確認できない
※上の２点は、文字起こし機能が発展してきたことでちょっと様相は変わってきたかも
※ただ、テキストを打つのに１テンポ遅れるのはまだあると思っている
- 後から確認できる形で情報が残っている必要がある
そのため、やり取りは必然的にテキスト中心になる。
ここで重要なのは、これは配慮の話ではなく、
業務を成立させるための現実的な要件であるという点である。
この前提のもとでは、
クライアント向けドキュメントは 「補助資料」 ではなく、
依頼内容を成立させるための中核的な存在になる。
クライアント向けドキュメントの役割を分解する
このような環境でクライアントワークを進める場合、
ドキュメントには明確な役割が求められる。
役割1：認識を揃える
最初に重要なのは、認識を揃えることである。
- 用語の定義
- 対象範囲
- 対応する内容と、対応しない内容
これらを明文化せずに進めると、
双方が異なる前提を持ったまま話が進んでしまう。
きこえない立場では、そのズレを口頭で微調整することができない。
そのため、最初に書いて揃えることが必須になる。
役割2：意思決定を固定する
クライアントワークでは、必ず何らかの意思決定が発生する。
- どの仕様を採用するか
- なぜその方法を選んだのか
- いつ決定したのか
これらをテキストとして残しておかないと、
後から認識が揺れ、「そんな話は聞いていない」という問題が起こる。
意思決定をドキュメントとして固定することで、
依頼内容のブレを最小限に抑えることができる。
役割3：期待値を調整する
クライアント向けドキュメントの重要な役割の一つが、期待値を調整することである。
役割１とも関連するが、
クライアントワークでは、「できること」だけでなく
「できないこと」「今回の範囲には含まれないこと」を
明確にする必要がある。
口頭でのやり取りでは、この部分が曖昧になりやすい。
「そこまで大変だとは思っていなかった」
「ついでに対応してもらえると思っていた」
といった認識のズレは、ここから生まれる。
きこえない立場では、その場のニュアンスや空気感で
期待値を調整することができない。
そのため、あらかじめドキュメント上で線を引く必要がある。
- 今回対応する内容
- 今回は対応しない内容
- 別途相談が必要な事項
- 技術的・運用的な制約
これらを文章として残すことで、
クライアントとの関係はむしろ健全になる。
役割4：後から振り返れる証跡を残す
クライアント向けドキュメントのもう一つの重要な役割が、
後から振り返れる証跡を残すことである。
業務の途中で、仕様変更や追加要望が発生することは珍しくない。
問題になるのは、それが「いつ」「どの前提で」決まったのかが
分からなくなることである。
- どの時点で仕様が確定したのか
- どの変更が追加対応なのか
- どこまでが当初の合意範囲だったのか
これらがドキュメントとして残っていれば、
不要な衝突や説明のやり直しを避けることができる。
きこえないエンジニアにとって、
証跡を残すことは自己防衛でもある。
しかし同時に、それはクライアントにとっても
安心材料として機能する。
「書きすぎ」に見えて、実はコストが低い理由
クライアント向けドキュメントについて、
「ここまで書く必要があるのか」と思われることもある。
確かに、最初に書く時間はかかる。
しかし、単独でクライアントワークを行う場合、
この初期コストは後工程で確実に回収される。
- 説明のやり直しが減る
- 認識ズレによる修正が減る
- 「言った・聞いていない」の確認が不要になる
- 判断の根拠を毎回説明しなくてよくなる
結果として、
やり取りの総量と精神的な負担は確実に減る。
特に、クライアントと1対1で進める業務では、
ドキュメントが事実上の「第三者」として機能する。
感情や印象ではなく、
書かれた内容を基準に話ができる点は大きい。
まとめ
きこえないエンジニアにとって、
クライアント向けドキュメントは単なる補足資料ではない。
音声による補足や、その場の調整に頼れないからこそ、
情報を構造化し、文章として残す必要がある。
その結果として生まれるドキュメント文化は、
認識のズレを防ぎ、期待値を調整し、
業務を安定させる役割を果たす。
本記事で述べた考え方は、
きこえないエンジニアに限らず、
単独でクライアントワークを行うすべてのエンジニアに
有効なものだと考えている。
もしエンジニアの方で、この考え方が今後の働き方の参考になれたら
幸いである。