こんにちは。

インフラエンジニアのさやみーです。

4月です。そう、新社会人の時期です。

2017年新卒入社の私も社会人2年目を迎えました。感情も一入です（え

社会人１年目、思い返すと大変な毎日でした。何が大変だったかはこの際置いておきますが、今回は４月ということもあって、以下のような記事を書きます。

「新社会人や新入社員へ届けたい、効率的な仕事の進め方のすゝめ」

２年目が何偉そうなことほざいてんだ？と思ったそこのあなた。今すぐブラウザバックでもしていただいて結構です。今回はあくまで新社会人の方や比較的入って間もなく仕事の進め方で悩んでいる方を対象にお話しさせていただければと考えていますので、そうでない方には当たり前のことかもしれません。お互いに時間の無駄になるようなことはやめましょう。

で、結論から言いますと

「5W1Hを意識して仕事しよう」

この一言が今回私が言いたかったことの全てです。

そもそも5W1Hってなんだっけ？？

って方はリンクから確認してください。

私はインフラエンジニアとして1年過ごしましたが、やる業務は基本的にクラウドサービスを使ったシステム設計と構築です。

っていってもよくわからないと思うので、簡単にいうと、一つのサービスを稼働するために必要となるシステムの構成を考え、その構成に必要となるミドルウェアの導入や設定をすること。

タスクを進めていく上で、大枠のフローとしては以下のようになります。

1. 会議（ここでタスクが振られます）
2. 設計（振られたタスクの設計案を考えます）
3. 設計レビュー（考えた設計案を提示します）
4. 修正（レビューを踏まえて設計を直します）
※Goサインが出るまで3. 4. を繰り返します
5. 構築（Goサインが出た設計で構築します）
6. 構築レビュー（構築したシステムに不備がないか第三者フィルターを通して確認します）
7. 修正（レビューを踏まえて構築を直します）
※Goサインが出るまで6. 7. を繰り返します
8. テスト（試験項目を用意して正しく動くかの確認）
9. リリース（ここまで特に問題がなければ本番に反映）

8. のテストに関しては構築の段階でテストをしながらやる場合もあるので一概にこのパターンとは言えないですが、基本はこれらのフローが必要となります。

ここまでで、なんとなくわかると思いますが、一つのタスクをこなすのにこれだけのフローを必要とします。ただ自分の好きなように作ればいい趣味でやるときとはわけが違います。

で、趣味でやるときと何が違うかといえば、

3. 4. 6. 7. のレビューと修正

が必要となることが一番だと思います。

私はこれらのフローを通して仕事をしていて感じたのですが、この「レビュー」と「修正」の機会が自分の思っていた以上に多かったんですね。正直うんざりするぐらい。自分では「動くんだからもうよくね？」っていう思いがありつつも仕事なので「ここ○○が足りないんじゃん」や「ここは△△の方法で入れてほしかったな」といちゃもんを付けられて、直すことになります。

なんとかこういうレビューと修正の回数を減らせないかと考えました。そして、一つの結論に達しました。

「5W1Hの”H”を最初の提示やレビュー時に意識できてなかったのではないか？」

HとはHowのことで、つまり「どうやって」の部分にあたるものです。

最初の提示の段階で

「○○を入れます。それは△△の理由から必要だからです。これを××までに終わらせます。」

↑の文は最初のレビュー会議などでほかの方にお伝えするのですが、ここだけ見ると

「○○を入れます。（What）それは△△の理由から必要だからです。（Why）これを××までに終わらせます。（When）」

3Wはあります。また、Whoの部分は基本的には自分なので入っています。Whereに関しては、作業をする場所なので、作業デスクですね。ここに関しては意識しなくてもよいことが多いです。Whoが変わる場面は、人に頼むというフローが必然的に発生するので勝手に変わるでしょうし、Whereが変わる場面というのもそう多くありません。

しかし、ここで私が失念していたHが泣いています。

インフラエンジニアとしてミドルウェアの導入を含む技術的な導入における方法は、実は複数あることがままあります。

例えばクラウドサービスとしてAWSを使っている場合、webサーバを作る方法はブラウザのマネジメントコンソールから作ることもできれば、Tera Termなどのツールからコマンドライン（CLI）で作ることもできます。このときに「▲▲の方法で○○を入れますが、よろしいでしょうか」という風に方法も踏まえて事前に伝えておかないと、「あれ？ ▲▲の方法でやってないのか」とかいうことを言われます。正直レビューした時点で、それ言っとけや！と言いたくなりますが、向こうからしても「最初に言っといてくれれば指摘したのに」となるだけ。はい、このやり取りが既に無駄なんですよね^^; 

向こうがこちら側のレビュー＋修正という工数が増えてしまうことまで考慮してくれるような神であればいいのですが、大抵はそこまで考えない凡俗ばかりで「あれやって、これやって」と言ってくるだけです。色々教えてくれる先輩社員といえどもこちらの都合が全てわかる神ではないので、そこはこちらから歩み寄って悪い芽を摘んであげる工夫をしていきましょう。そうすれば無駄にレビュー＋修正を強制されてイライラすることも減るかと思います。

で、それを実現する一つの要因として5W1Hがあるのではないかなと。なので、聞くときも伝えるときも5W1Hの要素が全て満たされているかを事前に考慮してください。で、足りないところはわからないか腑に落ちないところだと思うので、その場ですぐに確認を取るべきでしょう。5W1Hを最初から意識して動いたほうが後々の工数が増えずに楽になるだろういう所見でした。

最後にまとめますと、5W1HのHowは意外と見落としがちで意識しないで仕事を進めがちな部分だと思います。あと、今回の私の話の例とは異なりますが、意外とWhyを無視して話を進める人が多い気がします。要するに「なぜそれをやるのか？ やる必要があるのか？」ってところです。特別理由もないのに工数を使うのは無駄なのでやめたほうがいいですよね。

そういうわけで、仕事を効率的に後々に工数を増やさないためにも、この5W1Hを意識して仕事を進めてほしいと思います。

以上、最後までお付き合いくださってありがとうございます。お互いに効率よく仕事してワークライフバランスを充実させていきましょうb