ロケットスタートという会社の頃、自分の言葉は話すことも書くことも、全く構造的ではありませんでした。

たとえば誰かに何か相談をしても、まず最初に要点の整理を相手にしてもらってから本題、みたいになり、相談内容へ行く前の事前整理にすごく時間を使ってしまっていました。 ここをもっとできると、そのぶんの時間を肝心の相談内容や解決法に時間を割けるのでは、と思い、構造を整理しながら話す、ということを意識し始めました。 話すときだけでなく、文章にアウトプットをする場合も同じで構造的になるようにしています。

構造的に文章が書けると、

  • 言いたいことが伝わりやすい
  • 相手に何をしてほしいか伝わりやすい
  • 記録に残しやすい(時間が経っても意味がわかる)
  • 結果自分も相手も時間が節約できる

みたいなメリットがあると思います。

個人的に、マークダウンで書かれた文章が一番理解しやすい。文章を整理するという意味ではマークアップとほぼ同じなので、デザイナーやエンジニアの人には馴染みがあるのかな。 文章が整理され、要点をしっかり抑えることができ非常に良いです。いまはそこそこ書けるようになってきたと思います。

構造的な文章を身につける手段としては、

  • マークダウンで議事録をとる
  • Slackでの文章も構造を意識して送る

の2点をやってます。

マークダウンで議事録をとる、は議事録じゃなくてもいいんですが「話を聴きながらマークダウンで構造の整理しながらメモる」をやりまくるとだんだん整理をしながら話を聞く癖がつきます。 カンファレンスへ行ったときに実践するとか。余談ですがnanapiはQiita:Teamを導入しており、Qiitaはマークダウンに対応しているので、そのまま議事録をアップできて便利。このブログもマークダウンに対応してます。

Slackで送るような短い文章も、構造を意識して書くようにしています。特に誰かに何かを依頼する場合。

xxxで使われているyyyに関して、zzzしたいと考えておりまして今プロトタイプを作成しております。そのプロトタイプに関してご確認いただきたいのですが、aaaa日の午前11時〜お時間をいただくことは可能でしょうか?プロトタイプの内容に関してはその打ち合わせ前日にはお送りするようにします

xxxで使われているyyyをzzzしたいと考えております。

プロトタイプを作成しましたので確認させてください。

確認いただきたいポイントは以下です。

  • ほげほげ
  • ふがふが
  • ぴよぴよ

mtgの日程は、aa日11:00はいかがでしょうか?

より詳細は追って前日にはお送りします。

みたいな感じでしょうか。

伝えたいことをだらだら書くのではなく、どうしたら簡潔にできるか。日々意識し積み重ねていくと、相手にも一層伝わりやすくなりますし、自身のトレーニングにもなり一石二鳥です。 nanapiチーム内でも、伝わらない文章だと相手の時間を無駄にしてしまうので、なるべくロスタイムを生まないような伝え方をしよう、と共有しています。

しかしながら、すべての会話を構造的に意識してしまうと、それはそれでchannelが殺伐としてしまうので、適材適所というのはある。 エモい気持ちを伝えたいとき、エモいコンテンツをつくるときは、逆になにも意識しない方が伝わったりする場合もあるので、構造的な文章のすべてが正義というわけではないかなと思います。

しょうもない失敗をしてメンバーに許してもらいたいときは、わざとバカな感じの発言をして許してもらってます!