5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

今後の自分のキャリアを考えるため、「スタッフエンジニアの道」を読みました。
https://www.amazon.co.jp/スタッフエンジニアの道-―優れた技術専門職になるためのガイド-Tanya-Reilly/dp/4814400861

私は技術を学ぶことが好きで、今後も技術が関わる仕事をしていきたいと思っていました。
なんとなくスタッフエンジニアは技術を極める職というイメージを持っていました。しかし、上司を見ていてもスタッフエンジニアとしての明確な業務が見えてきませんでした。
そのため、「スタッフエンジニアの道」を読んで学んだことをまとめることにしました。

スタッフエンジニアの業務

以下ページにて目次が紹介されており、一部スタッフエンジニアの業務について言及されています。

仕事の優先度を考える

4章 限りある時間
4.1 全部やる
4.2 時間
4.3 リソース制約
4.4 プロジェクトを選ぶ
4.5 まとめ

経験を積んでいくと、やることが多くなっていきます。
現在のプロジェクトを終え、新しいプロジェクトに参画するだけでなく、社内の管理業務に加わることやプロジェクトが拡大し並行して、並行して複数のプロジェクトに参画することも発生してきます。
自身により多くの仕事を任せられるのは自身の技術力や影響力が増した結果かもしれません。ただし、それらをすべて100%の時間・力でこなすことは難しいです。
そのため、スタッフエンジニアとして、どんな仕事を優先すべきか(どこに時間をかけるべきか)考えて動く必要があります。

プロジェクトの不確実性を受け止める

5章 大規模プロジェクトをリードする
5.1 プロジェクトのライフサイクル
5.2 プロジェクトの始まり
5.3 プロジェクトの推進
5.4 まとめ

私の場合、並行していくつかのことに取り組むことが多くなってきたため、自身に当てはまるところはどこか意識しながら読んでいました。
私は複数のプロジェクトを並行していると、プロジェクトの大まかな流れは理解できているものの、細かい問題や進捗が見えないような感覚に陥ることが多くなっていました。つい「私が手を動かせていたら」と考えてしまい、それと比べた現状に自信をなくすことがありました。
複数人でプロジェクトに挑んでいる際にも、限られた時間で充分な情報をメンバーに伝えられず「まだ自分には人をリードする能力はなく、手を動かすべきなんだ」と思うことがありました。
こういった現象は、「インポスター症候群」と呼ばれるようです。

「スタッフエンジニアの道」を読んで、プロジェクトのスタート時の不確実性を「そういうものだ」と捉えることもできるのだと考えるようになりました。
複数プロジェクトへの参画やリーダーとしてメンバーを率いることは、経験したことはあるもののまだ慣れていると言えるほど経験したことではありませんでした。慣れない状況であれば、進めることに不安を感じ、自信が持てないこともあります。
そういった現状を受け止め、自信のできることと問題への対策に目を向ける必要があります。

リーダーとして問題解決を目指す

6章 なぜ止まってしまったか?
6.1 プロジェクトが動いていない。動かすべき?
6.2 あなたは迷子
6.3 たどり着いた……どこに?
6.4 まとめ

プロジェクト内にて問題が起こり、プロジェクトが止まる場合があります。自分が開発者として参画しており、ソースコードに問題がある場合、起きた事象の詳細を把握することから始めます。そして、ソースコードを確認し、修正と今後同様の問題が起きないようにします。
しかし、リーダーとして参画している場合、注目すべきスコープが異なります。プロジェクトの進行を妨げる問題へ対処が必要となってきます。
原因に応じて対策を講じる必要がありますが、開発者ではなくリーダーとして行動する必要があります。「自分がやれば早い」という思いに負けず、ソースコードを修正するのではなく、プロジェクトを動かすために動きます。もしソースコードの修正をやってしまえば、リーダーと開発者を兼任することになり、チームとして機能しなくなるかもしれません。

ロールモデルを目指す

7章 今はあなたがロールモデル(お気の毒さまながら)
7.1 良い仕事をするとはどういう意味?
7.2 有能であること
7.3 責任ある行動を取ること
7.4 目的を忘れないこと
7.5 先を見据えること
7.6 まとめ

私がスタッフエンジニアになるにあたって、社内に自身がロールモデルに合うことを示す必要があります。そのために技術力があることや模範的であることが求められます。
これまで通りプロジェクトに取り組むだけでなく、普段の行動が模範的であるかを見直す必要があります。また、プロジェクトの内部にとどまらない広い視野を持つ必要があります。

影響力を広げる

8章 良い影響力を広げる
8.1 良い影響力
8.2 アドバイス
8.3 教育
8.4 ガードレール
8.5 機会
8.6 まとめ

ロールモデルとなることは社内に良い影響力を広げることが必要となります。アドバイスや教育などがその方法にあたります。
自身が学んできた技術や知見を周りに伝え、よりよいチームとなれるようにします。コミュニケーションが基本となりますが、親切でいるようにします。
以下の記事が「親切とは何か」を考えるのに役立ちました。

スタッフエンジニアより先のキャリアについて

「スタッフエンジニアの道」ではスタッフエンジニアになった後のキャリアについても言及されています。

自身の目標に近づいているか評価する

自身のキャリアや人生の目標を考える必要があります。現在の業務を見直し、自身のやりたいことができているか確認します。以下、仕事を辞める際の指標となるものが紹介されています。

影響力を広げるためにコミュニケーションスキルを磨く

さらに影響力を広めできることを増やしたい場合、以下、コミュニケーションスキルの磨くことが役立つかもしれません。

経験を積む

今後の目標のため自身にないスキルが必要な場合、学ぶ時間が必要です。
参考として、アメリカ土木学会のエンジニア等級が紹介されています。

まずは時間をかけて職位にふさわしくなるまでの経験を積む必要があるかもしれません。

おわりに

今回読んで、今まであいまいだったリーダーとしての心構えのイメージができたと思います。スタッフエンジニアという職位には標準的なものはありませんが、参考にできるものを知ることで自身の評価のされ方を知ることができてよかったと思いました。
自身ですぐできることは限られているので、少しずつ変えていければと思います。
これからも学んでいきます。

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?