人を動かすという本を読んでみて、また普段の仕事を振り返ってみて、仕事上でコミュニケーションをスムーズにするためによく使っている（もしくは使わないようにしている）言葉が割とパターン化されている気がしたので、語録的にまとめてみようと思います。
※ 全く技術的な内容ではないですが、プロジェクトの成否にも関わる技術者向けの内容ですのでQiitaに投稿しちゃいたいと思います。
依頼するとき
何かしら仕事をお願いする場合によく使う言葉です。
要件と「お願いいたします」だけでも問題はないのですが、何か一方的で事務的な感じがします。受け取る側も人間ですので、場合によっては「一方的な都合で仕事を押し付けられた」と受け取られてしまう危険性があります。
定型的な作業依頼であればこれでも問題はないのですが、依頼された側が初耳な内容の場合、いきなり言われてもやらされ感が出てしまいます。
というわけで以下のような言葉を使ってみます。
「この対応が完了すれば、○○ができるようになりますので」
誰だって、自分の仕事に何の意味があるのかは気になるものです（と思っています）。
例えば新機能の開発はユーザーがより便利に、より多くの情報を得ることができるようになる仕事ですし、またサーバーが安定稼働するよう監視・保守し続けるのは作ったサービスを常に安心して使ってもらうために必要な仕事です。
その作業が最終的にユーザー（もしくは社員）にどのような影響を与えるかを考え、依頼内容と一緒に一言添えるだけでも、依頼された側の仕事に向かう姿勢は全く違ったものになります。
（口頭で）「これってどのくらいで対応可能ですか？」
いきなり文章で依頼されると、どうしても一方的な感じがしてしまいます。
まずは、直接顔を合わせて依頼の概要と、それに対する相手のリアクションを確認しておくとスムーズです。もしかしたらちょろっとやれば終わる内容かもしれませんし、じっくり腰を据えて取り組まないといけない問題かもしれません。今は無理だけれどもちょっと期限や対応者を変えればできる、という場合もあるでしょう。
そこでだいたいの内容や温度感が共有できたらあとは「先ほど口頭でもご相談させていただきましたが」と依頼文に一言添えて送ってしまえば良いだけなので、あれこれ依頼メールの文面に悩むこともなくなります。
また、気分的な問題で、直接顔を見せるなり声を聞かせるなりアナログなコミュニケーションをすることで、文章からは伝わらない意図や態度を伝えることができ、作業中も「誰のためにやっているのか」が明確にイメージできてやる気が出る、というメリットがあります。
「依頼内容に不足や懸念点がありましたらご指摘ください」
ここまで説明してきた通り、誰かに作業を依頼する場合は得てして依頼する側 -> 依頼される側の一方的なお願いになってしまい、さらには依頼に対してネガティブな反応をしてしまうと「頼んだこともやってくれない嫌なやつ」というイメージを与えてしまうのではないかという懸念から、依頼された側が黙って従うしかない空気になることが少なからずあります。
そのため、「何かあったら言ってね」と意識して何か言い返す隙を与えることで、相手も気兼ねなく懸念点や「無理です」を言いやすい雰囲気を作ります。そこで何か意見が出てきたとしても、お互い対等な立場で「じゃあどうしようか」と前向きに議論を始めることができます。
その他、よく依頼メールに添える言葉
-
「急な依頼で申し訳ありませんが」
- 特に期限が短い場合（でも必要な場合）に有効です。「無理を言っているのは分かっていますが」感を出すことができます。
-
「お忙しい中とは思いますが」
- 「あなたも忙しいことは分かっている。分かっているけど、こちらもあなたが必要なんです。」感を伝えます。
-
「すみませんが、よろしくお願いいたします」
- 海外では簡単に謝ってはいけない！的な話はよく聞きますが、日本人同士のやりとりの場合、「すみませんが、」は相手のことも考えているんだよ感を出す一番シンプルな方法です。最終的に依頼した内容を対応してもらうのがゴールだということを意識し、積極的に使ってしまいましょう。
注意としては、「お忙しい中とは思いますが、この対応は可能でしょうか。」と、そもそも「やらなくても良い」という選択肢があるように相手に伝えてしまわないようにすることです。
依頼する以上、「この仕事は必要である」という前提で話さないと、「あ、この仕事ってやらなくても問題ないんだ」と受け取られて依頼する方が損をする可能性もありますし、「あ、この仕事ってやってもやらなくても変わらない（意味のない）仕事なんだ」と受け取られたら、依頼される方が気分を害してしまいます。
「絶対やってもらう必要があるんだけど、無理なお願いをしているのは分かっているよ」感がバランス良く伝わる言い回しが大事かと思います。
議論するとき
機能の仕様や実装方法を議論する場合です。
言いたいことを好き勝手言うのではなく、達成すべき目的（サービスのリリースだったり、売り上げの向上だったり）を達成するために、効率よく、より良い結論を出すことを意識した言葉選びです。
「と、言いますと？」
営業の方から教わった言い回しです。相手の発言の意図を確認したり、より詳しい内容を確認したりする場合にとても役にたち、多くの場面で使える良い言葉です。
しかし、営業の方がお客様に向かって使う言葉だけあって、普通にチーム内で使うととても固い印象を与えてしまいます。
使い方が難しいのですが、「こんな便利な言葉教えてもらったからちょっと使ってみるぜHAHAHA」くらいの軽い感じで発言してみるくらいが、チーム内で使うにはちょうど良いです。
あまり軽々しく使えない場面では、普通に「つまり、それってどういうことですか？」と聞けば良いでしょう。
「いずれにしても」
議論が進んでくると、どうしても「あの場合はこうで、こっちの場合はこんな事情があって」という些細な部分で話が膨らんでしまい、無駄に時間を費やしてしまう場合があります。
そんなとき、「いずれにしても」でまとめてから話を本筋にもどすことで、「そこを議論しても意味がないから本題に戻ろうぜ」感を出すと、無駄なくスムーズに議論を進めることができます。ただし、本当にその場合分けが今議論している内容にとって重要である場合は、強引にまとめてしまうと「話の中身が分かっていない」印象を与えてしまいますし、議論すべき点が議論できなくなってしまいますので、使うためには話にしっかり理解している必要があります。
「僕もよく分かっていないのですが」
特に後輩と議論するときによく使います。
基本的に、入社間もない新人ほど、「先輩はなんでも知っているすごい人。とりあえず従っておこう」という固定観念を多かれ少なかれ持っています。
そんな後輩と対等に議論したい場合に、「これはこう、あれはこう」と意見を言ってしまうと、後輩は「それが正解なんだ」と素直に従ってしまう場合があります。
実際に自分がその内容に詳しい場合はそれでも問題はありませんが、自分の専門外のことを話す場合は自分も推測で話しているのに後輩はそれも「正解なんだ」と受け取ってしまいます。そんな時、意識して「僕も良くわかっていないんだけど」を使うことで、「先輩が言うことが全てではない」感を伝え、後輩も意見を出しやすくする雰囲気を作ります。
また、後輩でなくても、この言葉を使うことで「あ、この人はこの分野は強いけどこの分野はあまり詳しくない人なんだ」と理解させることができ、自分の守備範囲を正確に伝えることができます。また、詳しくないことを伝えれば他の人に詳しい説明を求めやすくなるなど、様々な面でコミュニケーションがスムーズになります。
「〜べき」「〜じゃなきゃダメでしょ」を__使わない__
「〜すべき」という言葉を使ってしまうと、議論はそこで止まってしまいます。何を言っても「いや、だからここはこうすべきなんだってば」という話になってしまうからです。「そもそも」なんて言葉が前に着いたらもうサイアクです。
「〜すべき」というのは何か絶対的な正解があることが前提になっていますが、実際の仕事の場合で常に正解な選択肢があることなんて極めて稀です。プロジェクトの進捗状況や現在の実装状況、メンバーのスキルや人数など、その時の状況次第で最適な選択肢は常に変わりますし、そもそもどの選択肢にも必ずメリットとデメリットがあって「正解」を予測することが困難だからです。
「〜すべき」という言葉は特に経験がついて自信がつき始めたエンジニアが使ってしまいがちですが、経験は正解ではなく、少しでも多くの選択肢を持つためのひとつの要素でしかないと思っています。
プルリクのコメント
プルリクは基本的に文字ベースのやり取りであることと、チェックする側がどうしても「チェックして指摘する」という上から目線のやり取りになってしまいがちなので、割とこの時だけ意識して使う言葉、というのもあったりします。
「〇〇に修正してください。そうすれば、□□という点がより良くなります」
単に「ここをこう修正してください」だけではなく、そうすることでどのようなメリットがあるのかを伝えます。
記事の最初で説明した「この対応が完了すれば、○○ができるようになりますので」と同じように、そうすることによるメリットや意義を伝えることで、修正に対するモチベーションを高めることができます。
レビューされる側としても「そのメリットは検討した結果不要だと判断した（他に優先すべきメリットがあった）」ということであれば、そのようにコメントを返すことでレビュワーに今の実装になっている理由を伝えることができ、「じゃあそのままで良いか」と納得させることができて前向きです。
「細かいですが」
1行、2行のちょっとした修正だけれども、その修正が後になってじわじわ効いてくるような内容（勘違いしやすい変数名や、不要な処理）についての指摘をする場合に使います。「細かいんだけれども、修正するまで承認はできない」くらいの温度感の場合によく使う言い回しです。
「時間があれば修正していただければと思います」
修正した方が良さそうだけど、些細といえば些細な指摘の場合にくっつけます。「細かいですが」と違って、「時間がなければそのままでも良い」という逃げ道を示しているため、最悪そのままでも問題ない場合に使います。
「経緯を把握していないのでなんとも言えないのですが」
実装というより、プルリク以前のそもそもの設計に対してツッコミを入れたい場合に使います。
プルリクが出されるということは、すでに設計や実装方針は固まっていてもう簡単に変えられない場合ほとんどで、ストレートに「この作りはイケてないので考え直してください」と言ってしまうと、「もうそんなレベルからやり直してる暇なんてないよ！」とお互いの不満だけを生む結果となってしまいます。そのような場合でも「この設計はイケてない」ということをオブラートに包んで伝える表現です。
これで指摘して何かしらの考えが出てくればそれで良いですし、「いや、実は何も考えずに作っちゃいました」であれば少し強めに、「じゃあ指摘したようにしっかり設計してやり直してよ」と言いやすい状況が得られます。
書き出してみると結構いろいろな口癖があるな、という感じですが、共通しているのは「相手の事情を考慮し、でも目的は忘れない」「理由付けがモチベーションのために大事」という点になるかと思います。それによって、自分も相手も能動的に目標達成に向けて力を出すことができます。
自分本位で一方的に主張するだけではなく、相手の状況を考慮し（また考慮していることを相手にも示し）、表現や内容を変えることで、お互いの仕事が気持ち良くスムーズに進み、成果を出すことにつながるのではないかと思っています。
また、やる気の問題だったり気分の問題だったりと、アナログな要素が多いように感じるかもしれませんが、たとえITエンジニアとは言っても人間ですので、最終的には人間臭い部分でも仕事の成否が左右されるのだと考えています。
汎用的に使えるもの
「何が分かれば分かる？」
これは僕の上司がよく使っている言い回しです。
例えば、「これ、いつまでにできる？」と聞かれて正確に答えられない場合ってよくあると思います（というか言い切れる場合の方が少ないと思います）。そんな中即答できずにもごもごしていると、「なんで分からないの？」と責めるように言われてしまうことってあると思います。
そんな時、「なんでわからないの？」という責めるのではなく、「何が分かれば言い切れる？」と聞くことで、スケジュールの予測を困難にしている要因を洗い出し、それらに対する対策や決定を前向きに進めることができます。
「なんでできないの？」「なんで分からないの？」と言われても「できないからできないのです」、「分からないから分からないのです」、と反射的に返したくなってしまうのが人間だと思います。それではお互い気持ち良くないですし、話も前に進みませんので、「何が分かれば分かる？」のスタンスで質問することは仕事を先に進めることができるとても良い言い回しだと思います。
いろいろと思いつく限りに書いてみましたが、他にも「こんな言い回しもあるよ！」「こんな場合はどうしている？」等ありましたらコメントいただければと思います。
他にも思いついたものがあれば随時更新していきますので、興味のある方はストックしていただければ更新時に通知が届いて便利かと思います。