はじめに
今回は社会人として意識すべきことを書き並べてみました。途中ちょっとだけエンジニアとしての心得もでてきますが、基本的にはどんな職種の人にも共通する話だと思います。
会社の文化によって必ずしも当てはまらないことも出てくると思います。なので全てを鵜呑みにせず、自分に必要なところだけ取り入れてください。
また、数多く当たり前のことも書いていますがあしからず。
態度、姿勢編
適宜進捗報告しましょう
順調なのか、詰まっているのか、別の方向に向かってしまっているのか。
進捗報告がないとこれらの状況の把握も、手助けもなかなかできません。場合によっては先輩から聞いてくることもありますが、聞くのを忘れてしまうこともあります。基本的には自分から進捗報告しましょう。進捗報告の頻度は作業内容や上司の考えによって違うので温度感は確認したほうがいいと思います。
報告内容としては 現在何の作業をやっているのか / あとどれくらいで終わりそうなのか or 予定通りに終わらなそうなのか / 困っていること、相談事はあるのか / 次にやる作業は何か などです。特に作業が遅れている場合はあとどれくらいかかるのか、対応策はどうするのか(残業でカバーできる範囲なのか、ヘルプが必要なのか等)を早めに報告したほうがいいです。
思い込みで進めないようにしましょう
よくわかんないけどたぶんこうだろう、と勝手に解釈して行動すると後処理が大変になることがあります。アブナイ時は確認しましょう。
情報を隠さないようにしましょう
「自分だけが知っている情報」は基本的になくすべきだと思います。「それ」を知らない人が「それ」を知らなかったがためにやらかしてしまう可能性がありますし、その人が休んでしまったときに困ります。情報の重要度やモノによりますが、口頭、メールで伝えたりissue、コード内コメントに書くなりなんなりをしましょう。
そのような意味で内容によっては例えばslackで会話する時は基本的に#generalを使い、DMは極力使わないという選択も出てくると思います。
ローカルだけに保持する情報は少なくしましょう
コミットでも、文書ファイルでも、自分のローカルだけにしか存在していないものだと、ある日突然パソコンが壊れた時にデータを復元することができなくなってしまいます。なくなると困る情報はリモートに適宜アップするようにしましょう。
メモを取りましょう
MTGや何か大事な話をした時にはメモを取りましょう。メモを取ると自分の頭に残ったり、文字データとして残すことができるのは当たり前ですが、社会人のマナーとしてもメモは取るべきだと思います。例えば大事な話なのに何もメモを取らなかったら話している方は不安になりますよね？なのでそのような意味でもやるべきだと思います。
礼儀正しくしましょう
私がここで言いたいのは言葉遣い等の話ではないです(それも大事だと思いますが)。会社で働いている以上、誰かのお世話になったり誰かに迷惑をかけています。その時は素直に感謝、謝罪の言葉が出てくるべきだと思います。
コーディング編
わからなかったら聞きましょう
最初はわからないことだらけなのは当然です。わからないことに対して負い目を感じたりせず、どんどん聞きましょう。
また、完全にわからないわけではないけどでももう20分くらい考えているのに解決しない、などという場合も聞きましょう。確かに自分で考えて、調べて解決するということも重要ですが、常にそれをやっていたのでは作業がなかなか進みません。「◯◯分経ってもわからなかったら聞く！」のように自分で決めて、あまり思い悩みすぎないようにしましょう。
最初のうちは「今話しかけていいんだろうか」とびくびくするかもしれませんが、たいていの人は聞かれたら快く答えてくれるはずなので怖がらずに話しかけましょう。先輩は使ってなんぼです。本当に話しかけてほしくない場合はきっと話しかけるなオーラが出ています。
聞くときは何がどこまでわかっていて、何がわからないのかを明確にして聞くようにしましょう。
この聞くという行為には副次的なメリットもあります。先輩は質問されることによって後輩の進捗具合がなんとなくわかったり、「あ、ここで躓くのか」という発見になることもあります。
知らない人が見てもわかるログを残しましょう
issueの発行は自分がして、実装は他の人が担当するということはよくあります。他の人が見てもわかりやすいよう、目的、実装すべき内容はしっかりと書くようにしましょう。バグが発生した時のissueは現象(スクショあると尚良し)、原因(もしわかるなら)、再現手順、再現機種及びOS(関係ありそうなら)などを書きましょう。バグのissueを自分が担当するときは調査過程や原因、対応方針を書くといいと思います。
また、コミットメッセージは変更内容とその理由がわかるように書きましょう。
信頼できる情報を使いましょう
基本的には公式の情報を頼るようにしましょう。ただ適切な公式の情報がなかなか見つからなかったり、そこまでおおごとではない場合は一般サイトを複数件当たって情報を引っ張ってきてもいいと思います。ただその時に気をつけなくてはならないこととしては、情報の鮮度です。IT業界は流れが早く、1年前の情報でも使えなくなっている場合もあります。新しい記事でも同じ解決方法が示されているか確認してからその情報を採用しましょう。
会社のコーディング規約に従いましょう
会社、もしくはプロジェクトごとにコーディング規約、もしくはそこまでいかなくてもなんとなくのルールはあると思います。例えばSwiftだと自クラスのメソッドを呼ぶときにselfをつけるか否か、などです。このようなルールに従っていないコードは間違いではないものの調和を乱すコードになります。基本的には郷に入っては郷に従うことを心がけ、周りのコードと合わせるようにしましょう(「公式」の規約とずれている、書く人によってばらばらになっている場合はどのようにしたらよいか相談してみましょう)。
ミーティング・参加編
以下、ミーティングはMTGと省略します。
MTG開始時間には着席してるようにしましょう
9時に設定されているなら9時には席についている状態にしましょう。自分が1分遅れることによって、他の人の1分を奪うことになります。
自分の意志を持ちましょう
MTGに参加している以上、自分がどう考えているのかは示すべきだと思います。しっかりと自分の意志を持ち発言しましょう(八方美人になってぶれることのないように！)。
人の意見に耳を傾けましょう
人それぞれ色々な意見を持っているわけで、当然自分とは正反対の意見が出てくることもあります。その時に自分とは違うからと言って一方的にはねのけるのではなくどのような根拠を持って主張しているのかに注目しましょう。それを聞いてもやはり正反対の考えを持つなら同じく根拠を述べて反論してください。
ミーティング・主催編
今度は自分でMTGを設定した時の話です。
そのMTGは本当に必要なのかを考えましょう
資料を読み上げるだけのMTGをするくらいならメールで資料を送ればいい話です。会社によってどこまでメール等で共有してどこまでMTGで共有するかは変わると思いますが、各人の時間をおさえて集める意味のあるMTGにしましょう。
時間を意識しましょう
時間ぴったりに始められるようにすることはもちろんですが、時間ぴったりに終えることができるようにしましょう。終了5分前にはまとめに入るつもりで。
必要に応じて事前共有資料を作ろう
議論のためのMTGであれば、その前提となる話、主張する意見を先に共有できるのであればその方が議論に時間を割けます。事前共有資料を用意した方が効果的なのであれば事前に共有するといいと思います(ただし必ずしも全員がその資料を読んでくれるとは限りませんし、むやみにそれを強要すべきではないですが)。
共有資料までいかなくても、事前準備は必ずしっかり行いましょう。他人の工数を使っているという意識を忘れずに。
どこまで到達したらゴールなのかを明確にしましょう
そのMTGは何が目的で何をやって、どこまで進めばゴールと言えるのかを定義し、共有しましょう。
例えばですが、自分のチームでは最近MTGの度にMission(今日やること、ゴール) / Done(やったこと) / Todo(次のアクション)の議事録を書くようにしているのですが、私は極力Missionの欄と事前共有資料をRedmineに掲載した上でMTGするようにしています。
味方を作っておきましょう
例えばの話、社長に対してプレゼンするとします。その場には社長、OJTの先輩、自分が参加する予定だとします。先輩に一度も見せずにいきなり本番を迎えたらどうでしょうか。場合によっては社長からだけでなく先輩からも指摘が入るかもしれません。社長：先輩、自分の構図のはずが社長、先輩：自分の構図になってしまいます。
こうならないためにも、事前に先輩にはプレゼン内容をすりあわせておきましょう。そうすればこの段階で指摘をもらうこともできます。きっと言葉足らずになっているところは事前すりあわせの場で先輩が質問してくれて主張の背景や根拠を理解してくれるので、社長とのプレゼンの時も自分がうまく伝えられなかったとしても先輩がフォローしてくれる可能性があります。
最後に
結構あたり前のことばかりだったと思います。でもこの当たり前の積み重ねが大事なので、この「当たり前のこと」をきっちりできるようにして「一緒に仕事したいな」と思われる人になれるように頑張ってください。