読者です 読者をやめる 読者になる 読者になる

ユアマイスター株式会社エンジニアブログ

ユアマイスター株式会社のエンジニアが日々徒然。

エンジニアブログ、はじめるよ!

このブログの目的

まだ試験的にですが、このブログを「ユアマイスター株式会社」のエンジニアブログとして立ち上げた目的は、下記の通りです。

  1. ユアマイスター株式会社で働くエンジニアについて知ってもらうこと
  2. エンジニア自身が、学んだことをアウトプットする機会を作り、嫌でも振り返りをしてもらうこと
  3. 人に読まれるものを書く=人に教えてあげられる状態にまで知識やスキルを定着させること

世の中にまだ全然知られていないこの会社が、すっごいチャレンジングですっごい楽しい職場だということを、 このブログを通して伝えられたらと思ってます。

要点をまとめて人に伝える練習

訓練がされていないと、とりとめもなく話してしまいます。 結論なのか、推測なのか、制約条件なのか、など、整理されていない状態で人に伝えるとだいたい事故につながりますw そのコミュニケーションに応じて変えていくのが、会話が上手い人だと思いますが、 迷ったら基本的には結論から伝えるのが一番安全でわかりやすい方法だと思います。

ブログとはちょっと違うかもしれませんが、PREP法と呼ばれる手法を簡単に紹介すると、

  • POINT(結論)
  • REASON(理由)
  • EXAMPLE(具体例・事例)
  • POINT(ポイント・結論)

という順番で説明をするというものです。 例えば、自分が書いたコードが動かないとか、どう手をつけたらいいかわからない、っていうときに

悪い例:「すみません、これ動きません」

良い例:

  • POINT(結論) – 作業が止まっているので、手を貸して欲しいです。
  • REASON(理由) – 検証を行っている最初の画面で、500エラーが発生していて、
  • EXAMPLE(具体例・事例) – このメソッドのxxx変数に値が入らないところまでは確認できているのですが。
  • POINT(ポイント・結論) – そんなこんなで、他のデバッグ方法があればアイディアありませんか?

こんなことを意識しながら、日々の会話とかチャットをやってみると、生産性が上がっていくと思います。

ブログ記事の場合は、

  • POINT(結論) – 問題解決方法を簡潔に
  • REASON(理由) – 問題点を簡潔に
  • EXAMPLE(具体例・事例) – 問題解決方法を詳細に、サンプルコードを交えながら
  • POINT(ポイント・結論) – まとめを2、3行の箇条書きで

っていうのが王道でしょう。

そして、うちのエンジニアたちへのメッセージを・・・

どこにもない情報を書いて欲しいわけじゃない

まだできたばかりのチームだし、全員が成熟しているわけではないので、いきなりすごいことが書けるわけじゃない。 でもきっと世界で同じレベルのエンジニアはたくさんいて、同じところでつまづきそうになっているエンジニアもいるかもしれない。

自分がググった先の記事に助けられたことがよくあればイメージがつきやすいと思うけど、(しばしば嘘が書いてあることもあるw) ただ1行だけで死ぬほどハマってたことを解決できるって罠みたいなイベントもしばしばある。

そんなときに、ひょっとしたら誰かのためになるかもしれない、っていうことも頭に入れておいて欲しい。

毎日1個ずつを目標に、リレー形式で書いていこう!