How To Work Better For Beginners-よりよい仕事の進め方
（これは２年ほど前にFiNC社内エンジニア向けに書いた仕事の進め方に関するドキュメントです。アップデートも兼ねて公開してみることにしました。）
エンジニアとして仕事をする上でおそらく重要だろうと個人的に思うことを。新人エンジニア向け。
目次
- 手を動かす前に
- スピード＆クオリティを同時にあげるために
- 差がつく３つのコミュニケーション力
- PDCAを回す人/回らない人/回さない人
1. 手を動かす前に
仕事としてのエンジニアリングは、コードを書くところからはじまるのは稀で、きっちりやっておくべきことがある。
1–1. ゴールの確認
当たり前だが、ゴールを確認すること。間違った方向に実装を進めることは時間の無駄と心得る。
仕様を詳細に確認すること
- 目的
- ユースケース
- 必要な機能の要件
- 具体的なアウトプットイメージ
重要なのは、表面的な実装内容の裏にある、目的やユースケースの確認をすること。
コードを書くことはあくまで目的を達成するための手段であるとすれば、達成するべきゴールを把握する必要がある。またそのゴールとコードを紐付ける、仕様を正しく把握することが重要。
Tips: 慣れてきたら、必ず1個以上企画者に質問すること
完璧な実装が一発でできないのと同様に、穴のない完璧な仕様書は(めったに)ない。少なくとも自分はお目にかかったことはない。
また企画者と開発者とは大抵違うパラダイムでものを考えているので、ドキュメントのみで完璧に認識を正しくする合わせるには双方の一定のレベルを必要とする。
もっとも簡単な解決策が質問をすること。コミュニケーションを取る癖をつければ手戻りを未然に防げるし、コミュニケーションが増えて相手への理解度もあがり、今後も意思疎通がスムーズになる。
1–2. 工数見積り
プロジェクトに期日がある限り、工数見積もりは必ずエンジニアがやる仕事であり、難易度の高い仕事の一つだ。見積もりの際には
- ゴールの確認をして仕様を詳細に把握すること
- なるべくタスクを細分化し、必要な工数を最小単位で考える
- リスク(不確定要素)を洗い出す
を意識する。３つ目はわりと盲点で、実装内容全て事前に把握することができないケースもあるが、不確定であることを知れば対策が取れる。
2. スピード&クオリティをあげるために
地味だがあまり教えてもらえないことを。
2–1. 手戻りを防ぐ
ある程度、仕様の把握/見積りができたら、上長かビジネスサイドの関係者などになるべく早くレビューを入れる。大枠が決まった段階でゴールの再確認をして、手戻りを防ぐ。
良いコードを書く能力と、正しい方向に向かって仕事をする能力は別物と考えて、前者のために後者も身につける。
2–2. ハマる時間を最小限にする
初心者を抜けるために、大はまりする時間をまずはなくす。
そのために
- 30分膠着したら誰かに相談（できれば口頭で）
さらにそのために
- 自分の力でやることにこだわらない
- できないことを恥ずかしがらない
を意識する。
不思議なことに、誰かに相談すると、その言語化のプロセスで自然と情報が自分の中で整理され、問題の理解が進むことが度々ある。
自力でやることも大事だが、ビギナーのころこそプロ意識をもち、手段よりも結果を優先する。
参考：小野和俊のブログ:プログラマーの開発速度は「はまる」時間の長さで決まる
Tips: アプローチ方法の間違いに目を向けよう
あなたの質問した優秀な先輩は、あなたよりハマらない/ハマりにくいアプローチをとっている。単純な知識差だけでなく、そういった思考プロセスを盗むとよい。応用がきき、質問の回数も減っていき、評判も上がる。
2–3. セルフレビューをする
最初から一発で品質の高いコードを書くことは難しい。
本来考えるべきすべてのケースを見据えてコードを書くには、経験はもちろん、プロジェクト・ドメインへの深い理解も必要になる。
誰でもちょっとの時間でできる対策は、自分で自分のコード(Pull-Request)をレビューすること、そして自分でQA(debug)してみること。
第三者の目線で自分のつくったものを見直すことで、コードを書くときに足りなかった視点が見つかる。今日見つかった視点が多いほど、明日から書くコードがより多面的な視点から書かれることになり、品質も上っていく。
3. 差がつく３つのコミュニケーション力
エンジニアリングを ”仕事として” 行う上ではこの論点はとても重要。
3–1. 結論→理由の順で話す。
開発者は、開発の効率は口酸っぱく教育されるが、コミュニケーションの効率は教育されない傾向にある。
しかしこれは基本的にすべての同僚、上司が望んでいることだと思う。身につけておいて損はない。
「だからどうしたの？(so what?)」と言われないために、結論から話す癖をつける。
キレイに抽象化され、設計された、スマートなコードをかけるエンジニアでも、コミュニケーションがスマートでない場合は多い。雑談以外では、お互いのコードを書く時間を奪わないためにも、要点を掴んだやりとりをできるようにする。
3–2. 見積り能力を高める
見積もりを正しく伝える。これはプロジェクトにおいてエンジニアが担う最も重要なコミュニケーションの一つ。
個人的な経験則だが、自分のできること・できないことをしっかり理解して正確にコミュニケーションできる、そんな高い見積能力があるだけで、初心者エンジニアから頭一つ抜けられるように思う。
逆に言えば、思っている以上に見積りは難しい。
- 日々見積りをする習慣を付ける（タスクを細かく分解し、期日を意識して仕事をする）
- 見積りのブレの原因分析（PDCA）をする
と、明日からやるべきことはとてもシンプル。スプリントタスクも、今日やるタスクも、見積もりを作って仕事に取りかかる。
そしてスプリントの終わり、その日の終りに全部思った通りにおわったか確認する。
Tips: 見積りがずれることに悲観的になり過ぎないこと
大前提として、どんなエンジニアでも完璧な見積もりを継続することは難しい。完璧を目指さず、でも見積もりのブレをなるべく小さくする努力をすること。
3–3. “バッドニュース”をなるべく早く伝える
プロジェクトに入って一番やっては行けないのは、リスクを隠すこと、共有しないこと。バッドニュースの扱いだ。
開発はチームプレーなので、リスクを隠すことは、チームメンバー全員への不利益につながる。
見積り通りに実装ができない可能性がある/サーバーのデータを誤って消してしまった/カジュアルにpush -fしてしまった等、まずいことを、ちゃんと気づいた時点で伝える。
伝えればチームで対策を打って解決できることも多いし、そういう人は信頼されるので失敗してもチャンスをまたもらえる。
これもスキルがなくても気持ち次第で今からできる、なのに差がつきやすい部分だ。チームのために、リスクを共有する勇気を持つ。
4. PDCAを回す人/回らない人/回さない人
上記３つも重要だが、最後のこの項目が一番重要だ。
小さな改善を積み重ねずに優れたプログラマーにはなれない。上記のような点を意識しながら、PDCA＝改善サイクルを回していく必要がある。（PDCAサイクル — Wikipedia)
特に初級者のフェーズでは、このPDCAが回す人/回らない人/回さない人で大きな差が開く。
よくある落とし穴にはまらないために、以下に注意する。
4–1. PDCAでよくある失敗
多くの場合、CとAができていないことが多いのでその点を詳細に。
Check(評価)不足になるのは…
[機会不足]振り返りの時間が不十分
そもそも時間をしっかり取れておらず、自分の今の本当の課題を認識できていない＝改善できない。忙しいチームであればなおさら。
帰宅前に一日10分でいいので、自分のために時間を取る。
[分析不足]解くべき課題を発見できていない
原因の因数分解・深掘りができてない。
原因の優先度・インパクトが正しく評価ができず、根本原因を認識できていない。
Act(改善)不足になるのは…
[具体度不足]抽象的で行動に落ちていないor根性論になってる
「もっと意識を上げてがんばろうと思う」
回らない人は、これを書いて満足してしまう。
「がんばるってなにを？」「いつから？」「どうやって？」「何のために？」「どうチェックする？」
まで落とせてない。ツッコミどころ満載の反省文であることが多い。
[実行力不足]Actを次の日にやってない
言いっぱなし。時間をかけて振り返っているので、その時間が無駄になり、これが一番よくない。
意思が弱いのは誰もがそうなので、工夫ををする。メモを残す、上司・同僚に宣言する、リマインダーをかける、など。
4–2. PDCAが 回る人になるために
ロジカルシンキングを学ぶ
PDCA不全は、そもそもロジカルシンキングができていないことが問題なことも多い。
よいアドバイスを貰える先輩がいなければ、以下のような本を読み、日々のPDCAの精度をあげる。原因の深掘り、対策の優先度づけ、および具体化の精度が上がればPDCAがうまく回り出す。
- 世界一やさしい問題解決の授業―自分で考え、行動する力が身につく
- 自分の答えのつくりかた―INDEPENDENT MIND
上司との面談で相談する。
1on1などで、具体的なアドバイスをもらう。これが最も効果的(ただしあなたの上司が幸運にも部下の育成に熱心であった場合)。尊敬するエンジニアの先輩がいたら、メンターになってもらえないかお願いする。
日報などで原因の深掘り＆対策を共有する。
初学者フェーズでは可能な限りこれをオススメしている。
考えているがpublicな場で具体的にあえて書かない、という意見もあるだろうが、それはもったいない。思考を見える化＆共有すると、経験者からフィードバックがもらえて基本的に得しかない。
オープンソースソフトウェアと基本的に同じだ。向上心と熱意をもって、中身や過程をオープンにすれば、善意のフィードバックをくれる人は意外と現れる。
終わりに
復習になるが、ポイントは以下の4つだった。
- 手を動かす前に
- スピード＆クオリティを同時にあげるために
- 差がつく３つのコミュニケーション力
- PDCAを回す人/回らない人/回さない人
上から1個ずつ、確実にできるようになるとよいと思う。ここに書いてあることがすべてでは全くないが、エンジニアとしての仕事を今後楽しむためにも、技術書を読む合間にたまに目を通してもらい、なにかの手引になるとうれしい。
