プロジェクト掛け持ちするときの考え方 - Hacking My Way 〜 itogのhack日記

プロジェクト掛け持ちだとうまくいかない、みたいなブログを見かけたんだけど、ちょうどそういう人たちに向けて発信したいなーと思ってたのでいい機会ってことで。

自分自身の経験から言うと仕事は掛け持ちした方がより成果を出せていると思う。

ただし、それは最初からそうだったわけではなく、いくつかの仕事をする中でうまくい方法を試行錯誤した結果なので、参考にしてもらえれば。

たとえば実働週2日で、という風に仕事を受けた場合、ざっくり半日*4で作業に使うのはうち3コマにして残り1コマ分は細かいタスクとかやる。

急ぎのタスクだと言われても急いでやったら他が遅れて待ち時間が発生なんてときに2日フル稼働とかって時間取っちゃってたりするとロスになる。依存タスクを見極めて環境が揃ってる状態で集中して作業して短い時間でちゃんとアウトプットを残そう。

プロジェクト特有の知識は覚えるしかないが、その他を標準化することで切り替えコストをなくす。

一番わかり易いのがプログラマーならgit/github flow.

導入してないプロジェクトであればまずは導入する。導入されていたとしてもうまく運用されていない場合は運用ルールを教える。もちろんこれも仕事として。

複数プロジェクトにいると、いろんなツールや運用を試したり出来るのでそれぞれいいところ、悪いところがわかってノウハウが溜まっていく。そうすると次別のプロジェクトに入る時も事前にどういう状況かだいたいわかって、新規プロジェクトにジョインした直後でも結果出せる。

今は次々に新しいモノやテクノロジーがリリースされてて、趣味でやってるとなかなか追いつけないし、趣味だと自分のお金や時間を消費してしまうし、なかなか世の中に出せるような成果には繋がりにくい。

それを仕事でやると、なんと人から感謝された上にお金までもらえちゃう。エンジニア冥利につきるとは、まさにこの事なんじゃないだろうか。

エンジニアとしては興味のある技術にキャッチアップ出来ないというのはとてもストレスになるので、お客さんに必要とされているというのは前提になるけど、自分にとっても興味があって新しい領域に触れられる仕事を選ぼう。

こういうことを言うと、それは特殊能力があるから出来るんだと思われるかもしれない。

でもそうじゃない。

人間の能力というのは一朝一夕で変わるものじゃない。今の自分に出来る範囲で、最大限プロジェクトの成功に貢献していくしかない。

自分がバリバリコード書いてサービスが動いたら「俺がつくった」って言えてそれはそれでもちろん嬉しいんだけど、それよりもプロジェクト全体の成果に繋がるようにちまちまドキュメント作ったり、曖昧なタスクを実行可能な単位に分割したり、必要があれば自分自身の成果には直接つながらないことでも率先してやる。

大切なのはこうした仕事への取り組み方であって、特殊能力を持っていることじゃない。一部の天才は最初から圧倒的な能力を持ってるのかも知れないけど、ほとんどの人にとっては能力というのは真摯に取り組んだ結果のご褒美として後からついてくるもの。

そんな地味な仕事でも、効率良くして組み合わせると、魔法のように見えることもあるんだよね。

※ウチでこんな働き方を一緒にしてくれる方を随時募集中ですw