自分では気がつかないけれども,他人からはよく見えることがあります。そのひとつが,「話し過ぎ」です。筆者は若いころ「話し過ぎ」でした。今ならそう自覚できますが,当時は「話し過ぎ」とは思っていませんでした。
このように,「話」には自分自身で見えにくいため,課題がよく自覚できないという非常に困った特徴があります。そして,これが非常に曲者なのです。
たとえば,文書なら,「書き過ぎ」かどうかは自分でも分かります。落ち着いて第三者的な立場で,自分の書いた文書を見れば,それが「書き過ぎ」かは分かるものです。
例えば,以下の文書を見てみましょう。
- いまだに,多くの問題が解消できていないところがあり,今後にも課題が残ります。
- この問題を解決するには,今のメンバーでは,かなり難しいとも思いますが,増員も厳しく,何とか,最善をつくす所存です。
- 東田部長には,いろいろ心配おかけして申し訳ありません。ご相談申し上げる局面もあると思いますのでよろしくお願いします。
- まずは,一歩一歩,課題を進めていくだけです。
- 課題も全て明らかになっているわけではございませんが,なんとか,頑張ります。
この文書を見て,どう思うでしょうか?
おそらく,何が言いたいのか分かりにくい,伝わりにくい文書になっていると感じるはずです。
結局,このような情緒的で整理できていないメッセージは,他人には伝わりません。そこで,文書では,「話を見せる」ために,加工する必要があります。無駄な書き過ぎの部分を消して,主張が明確で構造化されて文書に加工する…,それが結果的に「書き過ぎない」ことに繋がるのです。
現在,スケジュール比,課題解決の進捗度が70%の水準であり,現在の体制,推進方法では改善の見込みがありません。
したがって,以下の通り,メンバーの増員とタスクの完成期日変更を依頼したします。
2.詳細
a.変更内容
・タスクのうち,機能○○と△△は,2次開発にまわすよう交渉いたします。
・これらのタスクは,当初,当方で提案した機能であり,先方の必須機能ではないため2次開発にまわせる可能性が高いという理由に基づきます。
・ユーザー側の業務精通者を2名アサインする交渉を東田部長に依頼いたします。また,当方この業務に詳しいエンジニア××氏のアサインを依頼いたします。
b.見直しの理由
ビジネス対象領域が,当初予想よりも難しく,知識が足りないエンジニアが担当しており,今後も進捗の改善が期待できないため。
ここでの主張は「作業の見直し(タスクの減少,要員増加)」であり,以降はその具体的な内容です。これは,文章量は多いですが,「書き過ぎ」の文書ではありません。これなら,相手に何がしたいのかが明確に伝わります。