Webエンジニアとして大事な仕事の進め方 ３選（社会人４年目を前に考えたこと）【雑記】
これは何
そろそろ社会人４年目になろうという３月半ばである。 主に、これからの自分のために今まで仕事をしてきて考えたことを記録しておく。
振り返った時に、ここに書いてあることが正しいと思うのか、後から振り返った時に間違っていると思うのか。 間違っていると思ったらなら、それはおそらくその時に成長しているということだと思う。
目次
はじめに
対象読者
以下のタイプの人にはこの記事は役に立たないと思われる。
- 常に限界突破できる
- 常にモティーベーションが高い
- 人生が楽しすぎて仕方がない
なんとかだましだまし仕事をしてそこそこ楽しく生きていきたい人にとっては少し役に立つかもしれない。 同じ労力をかけていても、信頼される人/されない人、仕事が進んでいるように見える人/見えない人 がいる。 楽をして楽しく仕事がしたいじゃないか。
背景
仕事辛い ＝＞ なんとかなる までの道のり
丸３年仕事をしてきて、今でこそ辛さはかなり減ってきた。 辛い時期も結構多かったので、軽くだけども辛かった時期について触れておきたいと思う。
今は主にインフラエンジニアとして、小さくないサービス（月間億単位のPVがある）の主インフラ担当として日々膨大なアクセスをさばくサーバたちを管理している。 物理マシンの調達依頼から始まり、OSやネットワークの設定、ミドルウェアのインストールや設定、必要ならアプリをデプロイしての動作確認までが私の仕事。
最初はHTTPのリクエストとレスポンスの違いもわからず、ほぼズブの初心者として入社した。研究室で書いていたのはクソPerlスクリプトとFortranの死ぬほど汚いコードのみ。 研修は通常は４ヶ月のところが、直属の上司が忙しく放置気味でさらに追加で５ヶ月くらいひたすら”研修資料を作る研修”を行っていた。
１年目の終わりごろに先輩からいくつかの細々としたタスクをもらってこなしていた。 楽、だけど自分でタスクコントロールしているわけじゃないし、お給料分働けていない。 しかし２年目に入る頃ぐらいに所属部署が解体された。インフラとしてまとまっていたチームメンバが各開発部に散り散りに。私も開発部へ放り込まれることに。その時点で、まともに仕事がこなせない素人である。
２年目の半ばには、やっとなんとか仕事が回せるようになった。しかしプルリクを出せばコメントが大量につき炎上状態、口頭で上司に話をしに行けば私の理解力の無さに上司がヒートアップしてしまう。辛い日々。 「いや、だって、先輩たちがドキュメントの一つも残していないのに、突然放り込まれた私の身にもなっておくれ」などと思っていた。
３年目に入ったころから信頼もされ始め、インフラ周りの仕事は作業は大量ではあるが大体どのように進めればスムーズにいくのか肌感覚でわかってきた。 お給料もやっとここら辺で上がり始める。よかった。 給料分の仕事をしている感。
３年目の終わりごろ、担当サービスのインフラのトラック係数を上げるために後輩と同期への技術共有をしなければならず、また奮闘中。 主インフラ担当が一人でタスクをこなすのはそこそこ仕事は早く進むが、私がトラックにはねられるとインフラ仕事の大幅鈍化が予想される状態。 教えることに時間を取られて辛い以外は、割と楽しく仕事をしている。
辛さをなくす方法
基本は、以下のことを考えていたように思える
- 必要な情報を自ら取りに行く
- キーパーソンに信頼されるためにはどうすればいいのかを考える
- 会社やチームに（最小労力で）提供できる価値は何か考える
重要なのはこれだけで、以下に書くことは各論でしかない。 パッと思いついたことを三つだけ載せておく（３選とは。別にタイトルに意味はない。）
１．期限を確認する
インフラの仕事は２種類あると思っている
- 期限のかっちりしたプロダクトリリースに密接に関連した仕事。新規サービスや機能拡張のためのインフラ仕事。
- 期限が比較的緩やかな冗長化や可用性の向上などのための改善業務。サーバ構築自動化やCacheやDBのクラスタリングを組むなど。
特に前者の仕事では期日に間に合うことが重要である。 仕事のクオリティや将来のことを考えても、”とりあえずこの期限までに仕上げたい” という仕事である。 この仕事のデットラインを超えてしまうことは信頼をなくしてしまうことにつながる。 最初から無茶な仕事は投げ返すか新たに人をもらうなどの対応をすべきだが、最初に「自分一人でこの日までにできる」と言ってしまったならその日までに終わらせることが重要。
インフラの世界では Infrastracture as a code の実践が最近当たり前だが、それをやることが最優先ではない。手段である。 コード化されてなくても、再利用性が低くても、重要なリリースに間に合わせるのが最重要だった場合には、そういった手段の部分は妥協する場合がある。 １０割構築自動化するのは手間がかかるので、８割自動化しておいて、２割は手作業で仕上げる。 しかし２割の部分も暗黙知にしてしまうのではなくてドキュメントに手順や懸念点を残しておくのは大切。 雑に作る予定の部分については上長にあらかじめ話を通しておき、リスク判断を自分だけの問題としない。 問題点が明らかになっていれば、期限を延ばしてその問題点を潰すべきか、無視できるならリリースするかは上長が判断できる。
２．進捗の報告はタスク内容で行う
よく 「その仕事はどこまで進んだのか？」と聞かれて「８割がた終わりました」などとざっくり答える人がいる。 大体そういう答え方をしている人の仕事は、実質５割までしか進んでいない（自分の中でも大体終わったなと思った仕事が長引くことも多い）。 エンジニアリングでは最後の詰めの部分で問題が発生することがよくある。詳細動作確認をしてみたら何かうまく動かないだとか、追加注文が入るだとか。 そういう場合に起こっている問題は解決に時間がかかるものだ。 よって、最初に見えていたタスクが８割終わっていても、２割の仕事がそこから増殖することになる。 はたから見ると、いつまでたっても仕事が終わらせられない人が出来上がる。
どこまで進んだかタスクの内容でチーム内で共有しておくと良い。 例えば
- これとこれは終わって、後のタスクはこれ、チケットの個数でいうと８分の６終わっている。
- だけど後のタスクで詰まるとしたらこういう可能性があるかもしれない
- スムーズにいったら後２日だけど、バッファとして後６日欲しい
仮にざっくりパーセントで言うと、その人が何で詰まっているかもわからないし、一人で抱え込んでいるので潜在的リスクも発見されない。 他の人が見えているが自分が見えていないタスクやリスクも見えない。 ある程度細かい粒度で共有しておけば、何か困った時にアドバイスももらえるし、「それは確かに時間がかかるのもしょうがないね」と納得感も出る。
３．情報は再利用しやすいようにする
できるだけ同じことはしない。
エンジニアはコードについてはモジュールの再利用を考えてうまくやる人が多い。 私は技術調査についても同じことをした方が良いと考えている。
社内でもう詳細調査をした人がいるのに情報が公開されていない、検証過程・思考過程が見えない。そういうことはよくある。 自分が調査をしたら、その思考過程や意図を含めてドキュメントに残しておくべき。 一般的な話なら外部公開をしても良いし、社内秘が含まれるなら社内ドキュメントでも良い。
最低限殴り書きでもいい。何も残さないよりマシ。 有用な文章を残していくと、会社全体に役に立つ。 未来の自分にも役に立つ。後輩指導にも役に立つ。ちゃんと情報を出す人は信頼される。
まとめ
楽して楽しく仕事をしたい。そのためには周りに信頼されること、協力を得ること、それが大事だと思う。 どうやったら周りに信頼されるのかな？ どうやったらもうちょっと少ない労力で仕事を進められるかな？ というのを考えながらやっていきたい。
