8
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【駆け出しエンジニア向け】知らないと損するリモートワーク術11選

Last updated at Posted at 2023-01-22

お疲れ様です。
エンジニアになって二年目に突入しました。覚えることもたくさんあり、お仕事のお作法に慣れるのも業界の常識に慣れるのも一苦労しました。

とくに大変だったのはリモートワークです。初めて入った現場が週3〜4でリモートワーク、その次の現場はフルリモートでした。

PCを使った仕事は以前からやっていてZOOMで打ち合わせすることは慣れていたのですが、いざやってみるとかなり難しいです。

そこで今回の記事はフルリモートをやってみて、まだ仕事の要領をつかめていない新人だからこそこれは「やっておくといいよ!」というリモートワーク術を取り上げてみました。

ヘッドセットとマイクの準備はしておくこと

リモートワークをやっていると突発的にミーティングが入るときがあります。それは設計書の修正やお客さんから急なタスクの依頼があるからです。

突発的なミーティングは緊急性があるから呼びかけるものです。ヘッドセットの準備にモタモタしているとすぐに出ることができません。
この辺はお仕事をする上で相手への気遣いです。また一人ではなく複数の人で集まることがあるので準備が遅いと「他の人の時間を奪っていることになります。

ヘッドセット等はPCにつないでおき、すぐに対応できるようにしておきましょう。

即レスすること

リモートワークであれば、相手がPCの前にいることを想定して送っています。明らかにレスが返ってくるのが遅いとどうしたのだろう・・と思われますし体育会系の人であればイライラしてしまいます。

そう思われないためにも即レスは心がけましょう。1分、2分が目安です。どうしても返信が遅くなる場合や必要な資料を読んでいない場合は、そのことを伝えて「確認しますので〇〇までにお返事します」とだけ返しておきましょう。これなら相手がまだ読んでいないことを認識してくれます。

わたしはレスが早いので褒められました。

リモートでの関係構築とキャラ作り

実はこれがリモートでの一番重要な秘訣かもしれません。

対面の場合はちょっとした質問や雑談も可能ですがリモートだとそれはできません。

1回も対面コミュニケーションを取っていないと、どんな風にたち振るまわないといけないか迷うことがあります。

そこで重要になるのがチームのメンバーとの関係構築とキャラ作りです。

仕事の話を絡めた雑談や少しだけプライベートなことを話して自己開示をするなどをして関係構築をしてみましょう。あなたのことを知ることで相談しやすい関係構築ができます。

自分のことを話すのが苦手なら無理に頑張らなくても良いです。ただ最低限、自分が報連相するキャラを作りましょう。

「〇〇さん、お疲れ様です!〇〇の件について相談ですが・・」「〇〇について報告です!」とか頻繁にチャットを送るようにしましょう。

ちなみになんのタスクの件で相談したいのかどこのお客さんの案件なのか文章に入れておきましょう。

「ああ、〇〇さんはマメに報連相する人なのね」と相手に認識してもらえれば、今後、報連相しやすい関係ができます。

今までこういったことをやらないキャラの人が急にキャラを変更するのってちょっと難しいですよね・・

認識合わせと経過報告

仕事が早い人=仕事ができる人というイメージがついているからか早く終えたのはいいものの要件とは違うものを作ってやり直しというパターンはよくあります。

これを防ぐためには認識合わせと経過報告です。

タスクを進めていくうちに「あれ、これはこうやって作っていいのかな」とか調べていくうちに「上長から言われたこととは違うものになるんじゃないか?」と思うパターンがあります。

初めてタスクを受ける時は「このタスクは〇〇を〇〇に書き写すという認識であっていますか?」「〇〇という理解でよいですか?」と認識合わせすることは重要です。

必要なファイルや情報、作業を書き出してみましょう。目的に沿ったものが作れるよいならそのまま進める方が良いですが、もし違うなら改めて上長に目的を確認しましょう。

また進捗10%〜20%ほど進めたら経過報告をしてみましょう。そこで間違って進めていたならその場で修正できます。

質問のベストなタイミング

特に新人は遠慮しがちです。新人あるあるですが「メンバーが重要なタスクに忙しくしている中、自分がこんな小さな質問をしてもいいのかな・・」と心理的なストッパーがかかってしまいます。

とくにピリピリしている現場だとなおさら。

わからないことを溜め込んでしまい時間が流れると気づけば期限をオーバーしてしまいます。ただ期限間近になったところで質問をされても、質問された上長は対応するのに困ってしまいます。

「相手に迷惑をかけてしまう」

と思ったその時が質問をするベストなタイミングかもしれません。メンションをつけて質問のチャットを投げてみましょう。

先にチャットを出しておくことで記録がつきますし、記録がついていたのに質問の対応をしない場合はそれは上長の責任になります。

(もちろん気づいていない場合はメンションをつけてリマインドをかけてあげてください)

私がAWSの検証タスクを担当していた時の話ですが担当者になると一人で解決しようとしがちです。そのため調べて検証してを繰り返しているとあっという間に1日が終わってしまったことがあります。

20分〜30分ほど調べて前に進んでいないならすぐに質問を書いて送ったり、もしくはサポートに問い合わせてみましょう。

複数の質問をリストアップしておく

タスクを進めていく上でわからないことがあったら、すぐに質問をするのではなく他にも進められる箇所を進めてみて不明点を複数ピックアップして質問をしてみましょう。

質問を1つずつ応えるために打ち合わせを打診されると上長は大変です。

進めてわからないことがあればメモにリストアップしておき、3つ〜5つほど溜まった段階で上長のスケジュールを確認し「相談したいことが3つほどありまして〇〇時からお話できますでしょうか?」とチャットを投げてみましょう。

過去の成果物と照らし合わせ小さな“変”をリストアップする

インフラエンジニアの場合、設計・構築、設定の修正の作業は慎重にやらなければなりません。

1つのミスが大惨事につながります。そのためタスクを進めていく上で「あれ?なんかおかしいな・・」と思ったことがあればそれは上長に確認、質問すべきです。

「こんなこと聞かなくてもよいだろう」と思うのは絶対にダメです。自己判断で進めるのが一番の悪です。

未経験や経験が浅い人がこういった設定の作業で小さなミスや設定の間違いに気付くのはとても難しいでしょう。ではどうすればいいのか?過去の成果物と今やっている成果物を横に並べて1つずつ項目チェックをしましょう。

ほとんどの場合、割り振られていたタスクは前任者がいたはずです。前任者がやっていた過去の成果物を見てみましょう。もちろん引き継ぎを受ける時には、変更点は確認しておいてください。

過去の成果物と今やっている成果物を横に並べて項目名とそれに割り当てられている値をチェックすることで「これは〇〇だから〇〇の値が設定されている」と確認することができます。

確認する時もあえて指差し声出しで確認しましょう。そうすることでケアレスミスも防ぐことができます。

こうやって確認しながら進めていくと「あれ?おかしいな・・」と思う点が出てくると思います。「本来であれば〇〇の値が入るはずなのに・・」と感じることが出てきますのでそれらの資料名とシート名を控えておかしいと思うことをメモにリストアップしましょう。

そしてそれらを上長に確認・質問してください。

画面共有をして実例を出す

新人の時は、「わからないことがわからない・・」といった状況なので言語化する能力がまだ備わっていないのでチャットでうまく質問をすることができません。

だからと言ってただスクショを貼って「わかりません」「うまくいきません。」
これだけだと上長もどこで困っているのかわからずイライラさせてしまいます。どこまで調べたのか、タスクを進めようとするやる気があるのか腹を立ててしまいます。

ほとんどの場合、チャットで質問をするよりもミーティングを組んで画面共有をして見てもらった方が早く済むことがあります。
画面共有をしてどこで悩んでいるのかみてもらいましょう。

「〇〇の作業を進めていて確認したいことが3つほどあります。〇〇時から打ち合わせできますか?10分ほどで終わると思います。」と打診してみましょう。

画面共有してもどこで手詰まりになっているのか説明するのは自分です。その説明と質問力のレベルアップの方法として以下の4点を意識してみてください。

目的

目的とはあなたがやりたいこと、解決したいこと。つまりそのタスク、作業のゴールを説明しましょう
たとえば、、「CloudWatchのアラートがなる時間を指定して静観スケジュールを作りたいです。」などとやりたいことを提示しましょう。

調べた情報

目的を果たすためにどのような調査をしてどんな情報が出てきたのか説明しましょう。これは端的に説明してください。調べているときに箇条書きにしておくと良いですね。

たとえば、、「AWSの公式ドキュメントを読んでみたがCloudWatchのコンソール画面では対象のインスタンスやアラートの送信先の設定しかできなさそうでした」

※この時のポイントはミーティングをする前に調べたドキュメントはすぐに画面共有して出せるようにブラウザに開いておくかメモに残しておきましょう。記事タイトルと抜粋ワードも記載しておき、ショートカットキーのコントロール+Fで画面検索できるようにしておきましょう。

検証

調べた情報をもとに試したことがあればそれらも説明しましょう。そうするとどんなエラーが出たのか?エラーを翻訳をしてみるとどんなことでエラーになっていたのかを説明してください

仮説

なぜうまくいかないのか、どうやったら成功するのか?の仮説です。たとえば、、「CloudWatchだけでは難しそうなのでEventbridgeやAWSCLIと組み合わせて静観スケジュールをCloudWatchに設定できるのではないか?と考えています。」

などなど、、、

もちろん自分の知識が浅いことや調べる量が少ないなどの指摘をもらうことがあると思いますがそればかりは慣れるしかないでしょう。これらは質問のテンプレートだと思ってかまいませんのでチャットで質問をする時も同じように型を作るとよいです。

顧客業務最優先

現場に参画してしばらくするとお客さんへ納品する資料など、そういったタスクが割り振られると思います。顧客業務はどんな業務よりも最優先にしてください。それがたとえ期限までに余裕があったとしても優先すべきです。

仕事をしていると突発的に発生するタスクや管理業務、社内業務、進捗管理などのタスクに足を引っ張られることがあります。そのためお客さんに納品する仕事にも影響が出ることがあります。

特に他の部署と連携して納品する資料などは特にそうです。自分の責任に問われないように一度もらったボールはパスするようにしてください。

お客さんによっては「そんなに急がなくてもいいよ」と優しい方もいらっしゃいますが同じように優先してください。小さなミス、遅れは信頼の失墜となります。

アラートで通知を出すようにしておくこと

これも基本中の基本ですが打ち合わせや納品物する期日はアウトルック等でアラート設定しておきましょう。忘れるわけないと思っていても意外と人は忘れてしまいます。

またアウトルックは月次、週次のスケジュール設定ができます。第二月曜とか第三水曜とか、そういった細かい設定も可能です。

毎日予定表を確認することは必須です。

ロジックを理解する

なぜこの構成にしたのか?なぜこの設計の値を入れたのか?を説明できるようにしましょう。インフラエンジニアの場合、たった1つの設定ミスが大きな損失を出してしまいます。

どんな情報をもとにどんな考えでこのような作業をしたのか?説明する理由が必要になります。実際の設計・構築ではお客さんの情報を踏まえて公式のドキュメントを利用して説得材料を見つけておくのも良いですね。

いかがでしょうか?これらのことはやってみないとわかりませんし私も100%できているとは言えません。でも少し知っていて実践しておくだけでかなり仕事はラクになると思います。

他にもこんな記事書いています!

8
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?