エンジニア視点で読む「入門 考える技術・書く技術」

はじめに

エンジニアとして働くというのは、ただコードを書いているだけではままならないことも多いような気がします。

Slackなどのチャットツールでやりとりをする、
メールを送る、
やるべきタスクを書きとめる、
議事録を書く、
仕様書をつくる、
見積もりの根拠を述べる、
機能説明をする、
エトセトラエトセトラ...。

何かしら文章を書くシーンに必ずぶつかります。
今回、そういったシーンに活用できそうな本を読んだので紹介します。

「入門 考える技術・書く技術」を読んだきっかけ

ある日、社長(営業タイプ)から前触れなく提供されたのが 「入門 考える技術・書く技術 日本人のロジカルシンキング実践法」でした。

• http://amzn.to/2npF9q3

せっかくの紙本の現物提供だったので毎朝10分くらいの間は読書時間にすることにしました。166ページと薄めの冊子なので気軽に読み進めることができました。読んだり読まなかったりの日がありましたが、2週間くらいで読破しました。

読んだなかでエンジニアの実践に役立ちそうな3点について紹介します。

• 読み手の立場になって考える
• あいまい言葉を使用禁止にする
• "感謝の言葉にPDF"を実践する

読み手の立場になって考える

こちらの本の中で繰り返し言及されているのが、「読み手の立場で考える」ということです。
自分は最近になってようやく意識できるようになった気がします。
"読み手"を主に"相手"と言い換えても良いです。

素直すぎるケース

営業サイド 「ねぇ、MAUが知りたいんだけど」
エンジニア 「MAUの値は....ですね」

"相手が本当に必要としているもの"を探るケース

営 「ねぇ、MAUが知りたいんだけど」
エ 「なるほど、営業先に聞かれたりしたんですか？」
営 「〇〇なユーザにアプローチしたくて、影響数が知りたいとのこと」

（´-`）.｡oO （あっ、単純なユーザ数だけじゃなくて、〇〇属性データを持つユーザ数を追加で伝えたほうがよさそう...）

OPQ分析

本の中では「OPQ分析」というキーワードで述べられています。
最適な回答を提供するには相手のQuestion(疑問)を明確にする必要があります。

最近やたらめったら「それって〇〇で使うんですか？なんて言われたんですか？」を繰り返すせいで、逆に話を持ってきてくれる時に「〜〜の数字が知りたいです。〜〜が目的なんですけど」と言われるケースが増えた気がします。ありがたい

あいまい言葉を使用禁止にする

あいまい言葉とは、たとえば、「見直し」「再構築」「問題」「適切な」...といったものです。

本によると、あいまい言葉は考えをクリアにしていくときの妨げになると言われています。

エンジニア業はそもそも色々クリアでないと手が動かせない場合もあったりします。
この"あいまい言葉を使用禁止にする"を意識しておくと大変助かります。
具体的な書き方をしておけば、将来の自分や他のメンバーにしっかり伝わります。

解決できないissue例

今 「むっ、この管理画面のラベルA表記がおかしいぞ。今度修正しよう」
今 「ていうか全体的に使い勝手がよろしくない」

〆(._.)ﾒﾓﾒﾓ...
"管理画面の表示の見直し"

3ヶ月後 「で、これ何をどーすればええんやったっけ...」

解決できるissue例

今 「むっ、この管理画面のラベルA表記がおかしいぞ。今度修正しよう」
今 「ていうか全体的に使い勝手がよろしくない」

〆(._.)ﾒﾓﾒﾓ...
"管理画面のラベルAにtypoがあるので修正する"
"管理画面のレイアウト修正の具体案を考えて〇〇さんに相談する"

3ヶ月後 「そういえばこういうissueもあったなぁ、やっとくか」

issue解決のためにひと手間を

問題点を発見した瞬間は忙しくしていたため、適当に書いちゃった結果、最終的に解決に至らないうえにそもそも詳細不明のタスクが増えるのは悲しいですね。(自分もやりがちですが...)

ひと手間ではありますが、その場で具体的な解決方法が思いつくようであれば、メモの中に入れ込むことでぐっとissue解決のハードルが下がります。
ただ、長期的視点で考えるべき問題はあえてふわっとした表現にしておくとかは、あるあるかもですね。

"感謝の言葉にPDF"を実践する

メールを書く時は、感謝の言葉を述べてから、
- P (Purpose Statement)...主メッセージ
- D (Detail)...詳細、箇条書きでよい
- F (Follow-Through)...次のアクションについて
を書くようにしましょうという実践です。

注: 拡張子の話ではありません。

本ではメールを書く際の実践として例があげられていますが、
Slack文化にどっぷり浸かっている自分にとって、日常的なメールの利用頻度は低いです。

ただ、チャットの短いやりとりのなかでも、
感謝の言葉は"挨拶"に置き換え、
PDFは意識しておくとスマートにやりとりができそうです。
少々極端ですが例を用意してみました。
(注: 内容は適当です)

まわりくどくなってしまう返事

「メールが届かないという問い合わせがきていますが...」

お疲れ様です。
調査したところ、対象ユーザさんへのメール送信はできているよう
なのですが、メール承認が未完了状態のようです。
メール承認が未完了ということは、
まだ弊社からのメールを確認した実績がないということなので、
迷惑メールフォルダに入ってしまい見落とされているのかもしれません。
マニュアルの返答例を見ながらの対応をお願いします。

PDFが意識された返事

「メールが届かないという問い合わせがきていますが...」

お疲れ様です。
問い合わせ内容の原因ですが、
迷惑メールに振り分けられてしまっている可能性が高いと思います。

以下、調査内容です。
・対象ユーザさんへのメール送信自体は完了していました。
・対象ユーザさんのメール認証フローは未完了状態です。

マニュアルに具体的な返答例があるので、
参照しつつ対応をお願いします。

日付も決めると良さそう

末尾のFollow-Through部分は、特に締め切りが決まっているタスクなどに関するやりとりでは、具体的な日付をあげると良さそうです。
（日付が決まらないと何事も進まない...。）

Slackあるあるにも効果？

相手が書いてる途中で送ってくる文頭が意味深だと、超ドキドキしませんか。
自分はします。

お疲れ様です。
調査したところ、対象ユーザさんへのメール送信はできているよう
なのですが、

(typing now...)

PDFのP(Purpose Statement/主メッセージ)がきちんとあるだけでも、ドキドキ感は多少軽減されるのではと思い、意識するようにしています。

お疲れ様です。
問い合わせ内容の原因ですが、
迷惑メールに振り分けられてしまっている可能性が高いと思います。

まとめ

本来はビジネス文書・メールの書き方に関する本です。
しかし、普段のちょっとした仕事中のやりとりに関して学べるところが多くあるなと感じました。

本の中にはもっと実践的な考える方法や具体例などがふんだんに掲載されていますので、面白そ
うだなと思った方は、ぜひ実際に読んでみていただければと思います！

「入門 考える技術・書く技術 日本人のロジカルシンキング実践法」
http://amzn.to/2npF9q3

（まだ読んでないけどスライド編もあるらしい...気になる）

「入門 考える技術・書く技術【スライド編】」
http://amzn.to/2n5s1cg

オマケ

本によると、文書を作るには図を描けとのことだったので描いてみた（まだまだ下手くそ）

＿人人人人人人＿
＞　字が汚い　＜
￣Y^Y^Y^Y^Y￣