この記事は、業務中のチャットに数文字追加するあるいは変化させることで、情報量をぐっと増やそうという提案です。チャットではなくリアルの会話でも応用できるかもしれませんが、リアルであれば声のトーンや表情なども組み合わせてより正確に情報が伝わるはずです。それがないチャットだからこそのテクニックのお話です。
さらに自分はエンジニアなので、プログラムのコメントやテストラベルにも応用していきます。とはいえ、誰でも当てはめることができます。
- 記事の要約
- チャット例① エラーが500件になりました
- 改善例②の応用例
- 一旦休憩
- チャット例② エラーが5000件に増加しました
- 改善例④の応用例
- 補助動詞とは
- 副助詞と補助動詞のそれ以外の例
- まとめ
記事の要約
- エラーが500件になりました ⇒ エラーが500件だけになりました!
- エラーが5000件に増加しました ⇒ エラーが5000件にまで増加してしまいました...
- 副助詞と補助動詞を使って、他の人に事実だけでなく解釈も伝えたい
- プログラム中のコメントやテストのラベルにも応用できる
チャット例① エラーが500件になりました
障害発生が発生してバグ修正をデプロイしたあとに、エラー数の推移を確認したAさん。
改善前
A「エラー件数が500件になりました」 B(普段と障害発生時の両方のエラー数を覚えてない、これって問題ない数値なんだろうか?) B「500件というのはさっきよりも減ったんでしょうか?」 A「はい、減りました」 B「つまり問題ない?」 A「はい、問題は解決したように見えます」 B「であればよかったです」
この会話例はAさんの「エラー件数が500件になりました」という内容が、良いことなのか悪いことなのかが文章からだとわかりません。つまり事実しか伝えていません。Bさんはそのデータの解釈の仕方が気になり、Aさんに質問しています。
改善例① 正攻法
A「エラー件数が500件まで減りました。問題は解決しました。」 B(特に助太刀はいらなそうか。よかったよかった)
データの解釈の情報が足りないのであれば、単に補足すればいいという改善例がこちらです。これによってBさんはチャットをする手間が省けました。誰もがこの改善例のほうが適切であることに疑いはないと思います。
ここで終わりにはせず、さらに別で改善例をあげます。
改善例② 副助詞+ビックリマーク
A「エラー件数が500件だけになりました!」 B(特に助太刀はいらなそうか。よかったよかった)
「だけ」という副助詞を付けました。自分は現代文の授業で副助詞の授業が今でも印象的に残っています。当時の現代文の先生は副助詞のことを「ほかの文章が隠れている」として説明しました。つまり、「エラー件数が500件になった」という事実に加えて、「さっきよりもエラーが減った」という文章が暗に示されているのです。「だけ」という副助詞のおかげで、情報量が増えたんですね。
この例ではついでにビックリマークもつけています。そうすることによって、ポジティブなメッセージであることが伝わります。ここでは、問題が解決したのだろうと読み手は推測できますね。
もちろん改善例①のほうが直接的であり、より適切であると私も考えます。なので、改善前のメッセージを送信するくらいなら改善例②のほうがずっとマシ、意識できるなら改善例①にする。くらいの温度感になるでしょう。しかし、改善例②をメインで使う場面もありえます。
改善例②の応用例
作業ログスレ
例えば、自分が書き込んでいる作業ログスレです。Slackにはスレッド機能があります。そのスレッド機能を作業ログとしても使っている場合、メモ書き程度に文が雑になっているでしょう。「VSCodeをインストールする」「した」「次にsettings.jsonを編集する」などです。
雑は雑でも改善例②を意識することで、早期の問題解決につながる未来があるかもしれません。
A「発注数が500件になっている」
A「発注数が500件だけになっている...」
後者の方が副助詞「だけ」の効果によって何やら問題が起きていそうな匂いが漂い始めます。悪い内容なのでビックリマークではなく「...」にしてみました。もしあなたが新人の作業スレでこの文章を見たとき、声を掛けたくなりますか?
プログラム中のコメント
// 入力されたユーザー名をバリデーションする if (!userValidator.isValidate(user)) {
例えば、こんなコメントがあるとします。もしかして、userValidator はユーザー名以外の要素についてバリデーションはしてくれないのだろうか?と疑問に思いましたか。ではコードを追いかけてみましょう。
とならないため、副助詞「だけ」を挿入します。
// 入力されたユーザー名だけをバリデーションする if (!userValidator.isValidate(user)) {
これであれば、userValidator という名前のくせにユーザー名しかバリデーションしないのかい!とツッコミを入れることができ、コードを追いかける手間はなくなったと思います。あるいは、年齢もバリデーションしたいから userValidator を修正しようと早期にアクションを思い立つかもしれません。
テストのラベル
beforeEach(() => { /* うさぎレコードを2匹生成する */ }); test("うさぎの検索結果が1件になっている", () => { const result = searchRabbit(); expect(result).toHaveLength(1); });
よく見るテストラベルかと思います。副助詞「だけ」をつけたらどうなりますか。
beforeEach(() => { /* うさぎレコードを2件生成する */ }); test("うさぎの検索結果が1件だけになっている", () => { const result = searchRabbit(); expect(result).toHaveLength(1); });
一見「だけ」を付けてもたいして情報量が変わらないように見えます。しかし、読み手に「うさぎの検索結果が1件だけになっている」というラベルはテスト製作者がわざわざ「だけ」という副助詞を付けるほどには意図的であることが伝わります。もし「だけ」がないとき、「うさぎレコードが2件生成されているはずなのに、ここで1件しか返ってこないのは仕様なのか?それともテストラベルが間違っているのか?でもわざわざ toHaveLength(1) としているくらいだから、1件なのは仕様なのかもしれない。でもでも、toHaveLength(1) というテストだけみて、あとから他の誰かがテストラベルを読みやすいように書き換えただけで、テストが間違っているのかも?わからないから、コードを読むか...」となる可能性があります。
たった2文字でこの未来を避けられるのであれば、十分価値のある2文字だと思います。
一旦休憩
副助詞「だけ」の例だけでも、これだけ誰かの手間を省ける可能性があります。自分はこれを再発見してもらいたくてこの記事を書きました。
副助詞は他にもたくさんありますよ。
- は、
- ここには、何もない。(他と区別)
- も
- 会社に着くまで、1時間もかかる。(協調)
- でも
- コーヒーでも飲みましょう。(例示)
- しか
- 一つしかない。(限定)
- ばかり
- 着いたばかりだ。(完了)
- まで
- 学校まで歩く。(限度)
- のみ
- お支払いは、現金のみです。(限定)
チャット例② エラーが5000件に増加しました
エラーの増加を織り込み済みでリリースしたあとに、エラー数の推移を確認したAさん。
改善前
A「エラーが5000件に増加しました」 B(あれ?エラーが増えるとは聞いてたけどちょっと多すぎないか?) B「なんか思ったより多い気がするんですが、問題ないでしょうか」 A「いえ、問題あります。想定していたエラー数は500件程度でした」 B「ちょっと通話で相談しましょう」
チャット例①と同じように、Aさんの「エラーが5000件になりました」は事実しか伝えておらず、その解釈の仕方がBさんに伝わりませんでした。
改善例③ 正攻法
A「エラーが5000件に増加しました。これは想定の500件よりもずっと多くて、問題あります。どなたか一緒に原因箇所見てくれないでしょうか」 B「ちょっと通話で相談しましょう」
改善例①と同じように、すべてAさんが聞かれる前に伝える方法です。後述の改善例④よりも情報が正確です。それでもなお改善例④を見ていきましょう。
改善例④ 副助詞+補助動詞+...
A「エラーが5000件にまで増加してしまいました...」 B「ちょっと通話で相談しましょう」
今回は副助詞「まで」と補助動詞「しまった」を付け加えました。補助動詞については後ほど補足しますが、「しまった」はAさんの非意図を伝えます。これによって、5000件の増加がAさんの意図したものではないことが伝わります。おまけで「...」もつけてあげました。
改善例③とは違って、緊急事態感までは伝えることはできませんが、改善前と比べれば情報量が増えていて、Bさんが相談すべきだという判断の助けになったことは確かです。
改善例④の応用例
改善例②の応用例と似ているので、パパっと紹介します。
作業ログスレ
A「開発環境の管理画面がインターネットから見える」
A「開発環境の管理画面がインターネットから見えてしまっている」
後者には先輩によるヘルプが必要だとすぐにわかります。
プログラム中のコメント
# 簡易化のため、リスト全体をスキャンする
# 簡易化のため、リスト全体をスキャンしてしまった
後者の方が「いい方法思いついたら誰か直してほしい」という願いが読み取れます。
テストのラベル
describe("ユーザーが3桁の年齢を入力する", () => {
describe("ユーザーが3桁の年齢を入力してしまった", () => {
前者のラベルだと、読み手は「システムは3桁の年齢も考慮されているんだな」と思うでしょう。後者だと「システムは3桁の年齢は仕様にない」と思うでしょう。
補助動詞とは
もともと「てしまった」というノウハウだけ自分の中で持っていて、それを記事にするために ChatGPT と壁打ちして、補助動詞という言葉を知りました。なので補助動詞はこの記事の後付けです。
補助動詞とは、他の語について補助的な役割で使われる動詞
補助動詞(形式動詞)とは?使い方と通常の動詞との違いを一覧でわかりやすく解説!【例文で学ぶ 日本語文法】
他にも次のような表現があります。
- (して)いる
- (して)ある
- (して)おく
- (して)いく
- (して)くる
このあと紹介する補助動詞が、もし補助動詞でなかったらすみません...
副助詞と補助動詞のそれ以外の例
A「集計スクリプトは1分かかりました」
A「集計スクリプトは1分もかかりました」
A「クレカが決済方法に対応しています」
A「クレカのみが決済方法に対応しています」
A「バックアップを取りました」
A「バックアップを取っておきました」
後者の方が「Aさん自身がバックアップを取ることは予定ではなかった」ことが暗に伝わります。
A「バグは修正しません」
A「バグは修正しないでおきます」
後者の方が一旦修正しないというニュアンスが伝わります。
A「実装します」
A「実装してみます」
後者の方がチャレンジ感がでて、失敗する可能性を認識していることが伝わります。つまり、あとからヘルプがでる可能性を示唆します。
A「EC2インスタンスに終了保護が掛かっています」
A「EC2インスタンスに終了保護が掛けてあります」
後者の方が、終了保護の理由が忘れさられているわけではなく、現在も意図されているものであることが伝わります。
まとめ
文章のちょっとした語尾(補助動詞)や副助詞を変えるだけで、情報が正確になって無駄なやりとりや無駄な作業が減ります。 文章例①と文章例③のほうが適切な状況が多いことは念頭におきながら、ラフな場で使ってみるのはどうでしょう!