はじめに

初心者エンジニアのあなたは、

**先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？
また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？
勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。

僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。

またエンジニア向けには書いていますが、どんな仕事にも普遍的に使える考え方だと思っているので参考になれば幸いです。

アジェンダ

以下のとおりです。どこから読んでもらっても大丈夫ですが、上から読んでいったほうが流れが分かりやすいと思います。
ツールはGithub, Slackを使う想定です。

<まずはじめに> Compassion(相手への思いやり)を持って仕事をしよう
まず仕様を把握しよう
仕様を把握したらタスク分解と見積りを細かく行おう
不確定要素がある場合は予めググって解決、解決できない場合は上長に相談しよう
ボトルネックになるところから実装を進めよう
見積もりより大幅にかかりそうな時は、上長に報告をしよう
PDCAサイクルを回して見積もりとのブレを小さくしていこう
はじめのうちは1h〜1.5h毎に上長に進捗を報告しよう
口頭、Slack、Github Issueをうまく使い分けよう
実装してて行き詰まったら口頭で相談またはWIPでPull Requestを出して上長に助けをもらおう
上長からメンションされたときは可能な限り即レスしよう
複数の選択肢がある場合はメリット、デメリットつきでどちらがいいか相談、提案しよう
Pull Requestを出すときは、確認して欲しい人にメンションを飛ばす&どこを確認してほしいか予め明記しておこう
一度レビューを受けた内容は自分でチェック項目を作って、同じ指摘を受けないようにしよう

<まずはじめに> Compassion(相手への思いやり)を持って仕事をしよう

さて初心者エンジニアのあなたは右も左もわからないはずです。
ということは技術的には素人なわけですから、出来る範囲で相手に 気を遣って業務を進めることが大事です。
気を遣うというのは消極的になることではなく、 上長への感謝の気持ちや思いやりを持って作業することです。
これを僕は(社内では) Compassionを持って仕事をしよう、とよく言っています。

例えば、Pull Requestを出した時には自分で怪しいと思っているコードに何の補足もなかったらどうでしょうか？
あなたが思っているレベルのコードを、レビュアーの人は間違いなく突っ込むでしょう。それなら突っ込まれる前に予めGithubのコメントで補足しておけばいいですね。小さいながらもこれもCompassionです。

また自分がわからない問題を解決している時に、何が分からないかを自分の中で少しも明確にしようとせずに先輩に丸投げして相談しようとしたことはないでしょうか？
丸投げされた先輩は1からあなたの問題を把握しなくてはいけないので、とても時間をとられます。先輩、上長の方の時給は安くないので迂闊にその時間を奪わないように、最低限自分で解決できるところはしてから(とはいえ、悩みすぎないほうがいいですが)、質問する姿勢を持って、何が分からないか、どこまでは分かったか、などを明確にしてから質問ができるようになると、Compassionがあるといえますね。これについては後述します。

以上Compassionについてです。こういった思いやりを持つのは業務以外でも大事だと思っているのではじめに書きました。

まず仕様を把握しよう

さて業務を振られたら、まず仕様書を読みます。
…といいつつもはじめから仕様書を読んでビジネスサイドの人と直接やり取りして確認するということは少ないかもしれません。
ですので、はじめのうちは上長から説明された仕様を把握すればOKです。

もし仕様を把握する場合になったときは、

目的
ユースケース（網羅性）
必要な機能

を確認して進めましょう。

仕様を把握したらタスク分解と見積りを細かく行おう

仕様を把握したからといって、 いきなりコードを書かないようにしましょう。
初心者エンジニアあるあるですが、見積もりや設計をしないで突っ込んで結局ほどんど1から書き直しとなってしまうことがしばしばあります。(僕も経験あります…恥ずかしい…)

それではどうすればいいでしょうか？
まずはじめに、 タスク分解、見積もりと設計を細かく行うことが大事です。
設計についてははじめのうちは上長や先輩エンジニアの人が大枠やってしまう場合もあるかと思うので、ここではタスク分解と見積りについて書きます。

例えば、Githubのissue内でメンション付きで以下のように報告します。

タスクA 1h
タスクB 2h
タスクC 2h
タスクD 1.5h
- タスクD-1 1h
- タスクD-2 0.5h
タスクE 1h

はじめのうちはもっと細かくてもいいと思います。まだ未経験の分野でどれくらい時間がかかるかわからない場合はどれくらいかかるか検討もつかないので、1時間は調べる時間とりたいです、と書いておいてもいいと思います。

タスク分解と見積をする目的について考えます。主に以下の3つだと思っています。

アウトプットの大枠が間違っていないかを擦りあわせるため
予めリスクを洗い出して不確定要素を潰すため
見積もりをすることで実際の作業時間のブレとを把握し、PDCAを回すため

はじめの２つは大きく見積もりからブレるのを避けるためですね。(不確定要素の潰し方については後述)

2015/12/2追記
タスク分解したものはSlackにプロジェクトのTODOチャンネルでメンションを飛ばすことで、今日のTODOをプロジェクトメンバーみんなが可視化できるようにしています。

PDCAサイクルを回して見積もりとのブレを小さくしていこう

さて、少し脱線してなぜPDCAを回すのかについて。

見積もりをすることで実際の作業時間のブレとを把握し、PDCAを回す(すぐ上のタスク分解と見積の目的参照)というのは、
日報でもissue内でもなんでもいいのですが、具体的に遅延してしまった原因を深掘りするということです。それを上長、先輩に見える形にしてフィードバックをもらいましょう。
ちなみに具体的じゃなくてふわっとした振り返りはNGです。 根性で徹夜でなんとかするようにするとか もっと意識高くいかないとだめだみたいなのはだめです。もっと具体的にしましょう。

なんでこんなことを行うかというと、結局遅延した原因が分かっていないと同じようなミスを繰り返してしまうからです。なので、日々改善していくのが大事です。そうすることで、簡単なissueには時間がかからなくなり、難しいissueになってもハマりにくくなります。

不確定要素がある場合は予めググって解決、解決できない場合は上長に相談しよう

さて見積もりをしたらはじめのうちはほぼ確実に不確定要素が出てきます。
もし、不確定要素が出てきたらどこが不確定なのかを潰す作業をしておきます。それで不確定なところは大抵ボトルネックになるところ(後述)なので、問題は何か、実装したいこと(ゴール)は何かを明確にしてググって解決しましょう。その上で実装面で不安なところがあったら先輩や上長に相談しましょう。

また相談する時ですが、はじめのうちは分かりにくい質問をしがちなので、フォーマットを決めて質問するのがおすすめです。
僕は、下記のフォーマットを使っています。

## 質問
// 質問の内容を書きます
## 背景
// その背景を書きます
## 目的
// 目的(やりたいこと)を書きます
## 該当箇所
// コードで該当箇所があれば書きます

詳しくはこちらのQiita - 初心者エンジニアがより効率的にコードを書くために必要な三つの力も参考になるかと思います。

ボトルネックになるところから実装を進めよう

さて、見積もりも完了してある程度不確定要素も潰せました。
さてどの作業から進めればいいでしょうか？
答えは、 時間がかかりそう、ボトルネックになりそうなところです。
なので見積もり段階で一番時間がかかるかつ重いと思ったところを先に進めればOKです。
この作業の優先順位を間違えると、締め切りが近づくにつれ首を絞められることになってしまいます。
ボトルネックになりそうなところは、見積もりとのブレが出やすいところなので先に進めてしまいましょう。

見積もりより大幅にかかりそうな時は、上長に報告をしよう

さて、自分の見積もりにブレがあって作業時間が大幅にかかってしまいそうな場合があるかと思います。
そんなときに **恥ずかしい、、**とか **怒られる、、**といったことを思わないように。
報連相という超基本を徹底するようにしましょう。悪いリスクははやめに共有することで、上長とも対策が練れます。
もしこれが締め切りギリギリになって報告されたら上長に全部巻き取ってもらう、最悪納期に間に合わないということになってしまいます。
上のボトルネックの話とも関連しますが、リスク共有、報告は早めに行うようにしましょう。

はじめのうちは1h〜1.5h毎に上長に進捗を報告しよう

これも報連相の話ですが、はじめのうちは1h〜1.5hくらいの細かい単位で進捗報告をするのをオススメします。ある程度の時間毎に進捗が見えていたほうが上長の確認の手間も省けますし、短い単位で自分の作業の見積もりのブレが分かってPDCAを回しやすくなるからです。

口頭、Slack、Github Issueをうまく使い分けよう

※ ストック型の情報はGithub Issueで管理されているとします

口頭、Slackをうまく使い分けることで、上長への負担を極力かけないようにしつつ疑問を解消しましょう。
ある程度調べて分からなかったら、まずはSlackで質問、Slackで解消できないまたは時間がかかりそうなことは口頭で質問するようにするといいと思います。
Viewのインタラクティブな動きでもいきなり口頭で相談するのではなく、Slackでgif画像を貼ってゆるく相談してみるのもいいでしょう。よく使うアプリにLICEcapがあります。

またSlackはすぐログが流れてしまうのでフロー型の情報を、ちゃんと記録として残したいなと思ったストック型の情報はGithub Issueでメンション付きで質問するといいでしょう。

実装してて行き詰まったら口頭で相談またはWIPでPull Requestを出して上長に助けをもらおう

これも報連相の話ですね。行き詰まったら口頭でもいいので相談しましょう。またWIPでPull Requestを出すことでコードレベルでの相談もしやすくなります。

上長からメンションされたときは可能な限り即レスしよう

※ メンションする側も本当に必要な時しかメンションを飛ばさない前提です。
※ 中級者〜上級者はこの限りではありません。

Slackでメンションが飛んできたら可能な限り即レスするといいとおもいます。反応が早いとコミュニケーションがとりやすいからです。もちろん作業に集中していて即レス出来ない場合もあると思いますのでそういう時は、「今すぐ返事できないです」と一言返事すればいいと思います。

複数の選択肢がある場合はメリット、デメリットつきでどちらがいいか相談、提案しよう

実装していると、これもいいけどあれもいいな、どちらのほうがいいかなという場面にしばしば遭遇すると思います。
こういう時に経験豊富な上長だと、「なんでこっちを採用しなかったの？」と聞いてくるかもしれません。

結構そういうことがあるなと思ったので、これもフォーマット付きで相談するようにしました。

## 質問
// AかBのどちらがいいか(Cもある場合はCも追加して書く)
## 採用
// 結論を先に書く
## A // 選択肢を書く
### メリット
### デメリット
## B
### メリット
### デメリット

自然と結論から話すようになるので、慣れないうちはこのフォーマットを使うといいでしょう。

Pull Requestを出すときは、確認して欲しい人にメンションを飛ばす&どこを確認してほしいか予め明記しておこう

さて、作業が完了したら(あるいはWIPで出したら)確認してもらいたいことをPull Requestに記述、確認して欲しい人にレビューを飛ばすようにしましょう。

自信がないところや特に確認して欲しいところはまとめてPull Requestに書いておくとレビュアーも確認しやすいでしょう。

一度レビューを受けた内容は自分でチェック項目を作って、同じ指摘を受けないようにしよう

さてPull Requestを出すと大量のレビューが返ってくると思います。
例えば、

命名がよくわからない
こうするとCSSはDRYに書ける
N+1問題発生している

のような具合ですね。
そうしたら次は同じミスをしないようにスプレッドシートに自分でチェック項目を作って毎回過去にレビューを受けた内容クリアしているかどうか確認するといいでしょう。いちいち確認するのは手間かもしれませんが、レビュアーに同じ指摘をされないためにも自分で仕組みづくりをしていくといいと思います。

終わりに

いかがでしたでしょうか。
最初に仕事のやり方をきちんとやっていくことが良いエンジニアへの近道です。
なにか不明点あったらコメントいただければと思います。
参考になりましたら幸いです！