What’s a senior engineer’s job?(Part 1)

シニアエンジニアとはー第１章です。

シニアエンジニアの仕事とは何なのでしょうか。今回はシニアエンジニアの仕事についての記事でです。２回に分けてお送りします。

John Allspaw氏による「シニアエンジニアであることについて」という素晴らしい記事があります。 私は約４年前に現在の仕事を始めたときにその記事を読みましたが、この記事は私の将来的な方向性に関してどう考えるべきかかに影響を与えました。

4年後再びこの記事を読んでいます。この記事でとても興味深いのは、共感に共感すること/チームの成功を手助けすることがシニアエンジニアであることの重要な部分であることを説明している部分です。私もまさにそれが正解だと思っています！

私が思うに、私が知っているほとんどの（すべての？）シニアエンジニアは、それぞれのプログラミングの作業に加えて、他の人を助けるかなりの量の仕事を引き受けています。 今日、私や同僚が苦労していて、「何?? 人と話をしないといけないの?? 信じられない。」というのと「待って、このリーダーとしての仕事と個人的な仕事/プログラミングの仕事のバランスをとりながらやっていくにはどうする必要があるの？」 という感じです。そこで、シニアエンジニアがAllspaw氏の投稿に書かれているシニアエンジニアが持つ「性格」についての話（私は完全に同意します）をするのではなく、その代わりにシニアエンジニアが行う「仕事」についてここで話したいと思います。

what this post is describing

「シニアエンジニアがやること」は大きなトピックです。

今からこの記事を読むときに留意すべきこと：

• これは、「シニアエンジニア」ができることの1つの可能性についての説明です。 働く方法はたくさんあり、これが決定的なものではありません。
• 私は基本的に1つの会社でしか働いていません。そのため、これは私の経験に基づくものであり、私の視点は明らかにかなり制限されています
• 明らかに「シニアエンジニア」のレベルはたくさんあります。 これは、Mozilla ladder（シニアエンジニア/スタッフエンジニア）のP3 / P4の周りのどこかを目的としており、もう少し「スタッフ」側にあるかもしれません。

What’s part of the job

これらの仕事は、主にシニアエンジニアの仕事であり、マネージャーの仕事ではないと考えるものです。 （ただし、管理者も間違いなくこの仕事の一部もやります。特に、新しいプロジェクトの作成/プロジェクトのビジネス上の優先事項への関連付けなどです。）

これをすべてまとめると、この作業のほとんどすべてが根本的に技術的であるということです。誰かが難しいプロジェクトに取り組んでいて失敗するのを助けることは明らかに人間ですが、私たちが一緒に取り組む問題は一般にコンピューターの問題です！ （「この仕組みを単純化しさえすれば、この方法でもっと早く終わらせるかもしれません！」）

• コードを書く (これは絶対！)
• コードのレビューをする (これも絶対！)
• 設計仕様書を書いたり、レビューをしたりする

他のレビュータスクと同様に、「設計仕様書のレビュー」を「仕様書の第2の目を持つということになり、設計仕様書の改善に役立つ」と考えています。

• チームメンバーが困っているときに役に立つ

プロジェクトで困ってしまってどうしていいか分からなくなる人も時にはいます。そこでその困っている人をサポートするために働くことが重要だと思っています！ それは「空からのパラシュートであなたの魔法の知識を人々に届ける」というよりも、「彼らが解決しようとしている問題を理解し、2人の方が1人より早く問題が解決するということを確認すること」だと考えています。 これはまた、誰かのために問題を解決するのではなく、誰か一緒にと問題を解決することを意味します。

• メンバーが高い品質基準を保つようにする

「品質」とは、人によって定義が異なります。（私のチームにとっては、「品質」とは信頼性/セキュリティ/使いやすさを意味します）。 通常、誰かが私に、私が間違っていると思っていることを決めるとき、それは私が彼らが知らない何かを知っているか、彼らが私が知らない何かを知っているからのどちらかです！ だから誰かに「これを間違ってやってしまったので、その代わりにXをやるべきだ」と言うのではなく、彼らが知らなかった追加の情報を与えようとしますが、結構それで問題が解決することがよくあります。そしてかなり頻繁に、私が何か情報が足りないことが判明し、実際に彼らの決断の方が完全に合理的だったということがよくありました！シニアエンジニアが自分の意見が正しいと考え、自分の意見を何度も繰り返し、そしてもっともっと自分の意見を強く主張することで品質基準を押し付けようとするのは以前は、あまりありませんでした。

• 新しいプロジェクトの作成 ソフトウェアエンジニアリングチームはゼロサムの場所ではありません！ 私が知っている最高のエンジニアは、自分にとって最も興味深い仕事を貯めこむことはなく、新しい面白い/重要な仕事を作り、会社の人間がその仕事をするためのスペースを作ります。例えば、私のチームの誰かが私たちのデプロイメントシステムの書き直しを指揮しましたが、これは非常に成功し、今ではチーム全体が書き直し後のビルドをより簡単にする新しい機能に取り組んでいます！
• プロジェクトの作業を計画する これは、作業中のプロジェクトのロードマップを書き留めたり、またはみんなに伝えたりして、人々が計画を理解できるようにすることです。
• プロジェクトのリスクを積極的に伝える 誰かが作業中に何かがうまいっていない時に、それを認識し、他のエンジニア/マネージャーにそれを伝え、何をすべきかを理解することは本当に重要です。
• 成功を伝える！
• チーム/会社に利益をもたらすサイドプロジェクトを行う 多くのシニアエンジニアが時折小さな高レバレッジプロジェクト（開発ツールの構築/ポリシーの設定の支援など）を開始し、多くの人々が仕事をより良く行えるよう支援することがあります。
• プロジェクトがビジネスの優先順位とどのように関連しているかに注意する
• プロジェクトの実行を停止するタイミングを決定する 何かの作業を停止するか開始しないかを判断するのは驚くほど難しいです:)

「コードを書く」ことを最初に置いたのは、ともすれば重要視されない業務だからです。

省略した業務は「見積もりを行う」ことです。 見積もりを作成することはまだあまり得意ではなく、あまりそういう機会も多くは（？）ありませんが、いつかもっと時間を費やす価値があると思います。

このリストの業務内容は非常に多く、常にこの業務をやろうとすると利用可能なすべての脳の機能を消費してしまうくらいたくさんあるように感じます。 一般的には、サブセットを切り分けて「今すぐX Y Zに集中します。AB Cも同時に実行しようとすると脳が爆発すると思います」と判断するのがおそらく理にかなっていると思います。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。