読者です 読者をやめる 読者になる 読者になる

どこまで仕事を詰めてから人に確認してもらうか【雑記】

これは何

雑記です。
エンジニアとして仕事を可能な限り効率よく進めるために、仕事をどこまで仕上げてから他の人に最終確認してもらうか、という点について考える。 「チームとして」仕事を効率的に進めること、「個人として」効率的に進めることの二つの視点で見る。

背景

年末になり、諸々の仕事がたくさん降ってきた。締め切りが近い仕事が多い。 私は仕事を進めるにあたり、もともとできるだけ深く調べてやっていきたいタイプ。仕事は遅いが硬い仕事を好む。

何を優先しよう

チームとして効率的に進めること

エンジニア一人が仕事を進めることではなくて技術的興味からその仕事には不必要なまで技術調査をすると仕事は滞る。逆に難しいことは置いておいて、これで問題なく動くというところまでならそこまで労力はかからない。
例えば、プロダクトのappleのATS対応のために自サービスを全てhttps化したいシチュエーションがあるとする。ここでは詳しく述べないがATSの要件として必須となるCipher Suiteがある。インフラエンジニアが最低限仕事を進めるのに必要な知識としてはiOSクライアントがしゃべれるcipher suiteは何か、LBがしゃべれるcipher suiteは何か、という視点だけを持って”文字列”(例えば「ECDHE-RSA-AES256-SHA はクライアント、LBも両方とも使えるからOKだな」などと)の対応を見れば良いだけ。負荷については既に設定したものがどれくらい使っているかを見て、アクセス数で比を取れば大まかな値は見積もれる。
しかし、調べていくと例えば以下のような疑問が出てくる

  • Cipher Suiteってなんだ? 鍵交換の部分が楕円曲線暗号(ECDHE)を使えばRSAを使ったものと比べるとCPU処理が重くなるようだが、どういうアルゴリズムの違いがあるんだ? 比ではなくてLBのカタログ性能と見比べて数値的に見積もりできないの?とか。
  • LBのSSLをハードウェアで解く方法って裏で何やってるんだ? 

これらを深いレベルまで調べるのは大変に骨である。実際、今回限られた時間の中では本当にさわりしか学ぶことができなさそうだ。

さて、チームとして短期的に成果を上げるためには、上記のように概要を調べて => 大体こうだろうと文章を書いて => 詳しい人に聞いて大体OKを貰って => 上長の承認を得る(場合によっては情報不足によるやり直し) みたいな流れになる。
本当は次のようなプロセスを踏みたい(が、無限に時間がかかる) 概要を調べる => 疑問を満足するまで潰す => 詳しい人に聞いて裏取りして => 上長も一発承認。

前者のフローではその案件について詳しい人と上長には少し負荷はかかるが確認作業なので大きくない。私の作業量は小さいのでチームとしては割と小さな作業量で仕事を進めることができる。
後者のフローでは私個人の作業量は多いが、確認者の負担は小さい。しかしながら8割から10割に完成度を高めていく作業は0から8割にあげるのの5倍はかかる。

なので、チームとしては7〜8割の完成度の仕事まで自分で仕上げ、あとはうまく流していくという作戦がうまく行く。

個人として長期目線で見ると

上記のように、チーム目線で短期効率を求めて仕事を流していると絶対に自分は「詳しい人」にはなれない。 短期的には今ある仕事を回せばいいが、長期的に見れば会社としてもそれぞれがスキルアップした方が冗長化はできる。個人としても美味しい。裏の技術を知っているエンジニアは貴重だが、上辺だけなぞって仕事をそこそこ流せるエンジニアは割と沢山いる。 そうなると10割の完成度を目指し(実際には8〜9割の完成度だったとしても)満足いくまで裏の理解をした方が良い。とはいえ、あまりにも業務が進まないとお給金は上がらない。難しい。

まとめ

結局のところバランスを取るしかない。締め切りに追われている時には技術調査を少なめにして実験的手法が増えるのはしょうがない。時間があれば論理から攻めて深くまで理解して仕事をする。

コメント

めっちゃのんびり働きつつ、満足いくまで勉強しつつ、お給金も沢山もらいたいなあ、という話でした。家で無限に勉強時間をとることでこの問題を解決しているエンジニアもいるが、それは人生の浪費では、と個人的には思っている。人は仕事だけをするためだけに生きているわけではない。業務時間中には全力を出し、プライベートは可能なかぎり仕事から離れて楽しむのが良い。