エンジニアは、もしくはエンジニアを目指している人の中には、意識的かどうかはともかく、エンジニアとしてより活躍するために日々なにかを学んでいる方が多くいます。
学んでいる人の多くは、最新の技術や新しい設計のトレンドを追ったりしながら、いつかは「〜のスペシャリスト」もしくは「フルスタックエンジニア」と呼ばれるような人物像を目指すことが多いのではないでしょうか。
これは素晴らしいことです。目標を持たないよりは持っているほうが好ましいですし、そのモチベーションによって様々なスキルが向上することでしょう。
しかしこのエントリでは視点を変えてみて、上記のような目標に関心が薄かったり、周りの技術力の高さにくじけそうになってしまっていたりする人に焦点を当てて、様々な種類のプロダクト開発・プロジェクトにおいて重宝されるような「ふつうのエンジニア」になるための戦略を、個人の経験則から考えてみたいと思います。
「ふつうのエンジニア」とは
上記で書いた「ふつうのエンジニア」とは完全に造語です。
イメージとしては、IT業界において特殊なスキルや経験を持っている「替えの効かないエンジニア」ではなく、むしろ「替えの効くエンジニア」を指しています。
これは「価値を発揮しないエンジニアから替えが効く」ではなく「いろいろな種類のプロダクト開発・プロジェクトのどれに交わったとしても一定度の活躍ができるから替えが効く」ことが背景にあります。
言い換えれば「パッと見は気が付かれないけど、その人がいるといないとでは仕事のスムーズさがまったく違う」ようなエンジニアを表現しようとしています。結局「替えの効かないエンジニア」ではありますね。
それでは、あらためてその作戦を考えてみます。
「開発が上手い」より「仕事が上手い」を優先する
難しい設計手法や最新のテクノロジーを知らずともバリューを発揮するためには、「開発」という言葉を一歩引いて「仕事」として捉えなおすことが重要です。
とくに経験の浅いエンジニアの場合、開発スキルよりも「仕事術」と呼ばれるような一般的な社会人のスキルが必要な場面も結構あるように思います。
もし「自分は〜して仕事を進めるのが得意・好きで、それを周りも評価してくれている」というような自己認識がまだなければ、先に「どう仕事をすると上手く進むか」を考え、日々試してみるとかなり効果があるはずです。
計画、計画、そして計画
仕事術には万能なものはなく、個人のキャラクタによって合うかどうかもありますが、ひとつ具体例を挙げてみます。
私が重要視するのは、計画です。
たとえば仕事を開始する前に10分、仕事を終わる前に10分でもよいので、1日を想像したりふりかえったりする時間を確保する。
始業前であれば、今日必ず終わらせたいこと、どんな進捗が出ていたら嬉しいかを確認しつつ、タイムスケジュールやTODOリストを整理する。
始業後であれば、今日の目標は達成できたかをふりかえりつつ、明日の自分へ引き継がないといけないことはないか整理する。
この少しの時間がさまざまな規模で効いてくることを、計画好きの人は知っています。好き嫌いはあると思いますが、ぜひ一度試してみてほしいです。
朝会前にひとりで計画する
ちなみに似たようなことをチーム単位で朝会やデイリーとして行っている組織やメンバーは多いでしょう。
しかしこれに加えて、朝会前にまず一人でデイリーのための準備をしてみることを強くオススメします。
その後にデイリーに参加すると、計画の解像度ははるかに上がりますし、チームの計画の「穴」を見つけたりすることもできます。
ここまで一切エンジニアリングスキルの話は出てきませんでした。しかしこのような形での貢献は、チームに対してもエンジニアとしての自身の業務にも、大きく意味があるはずです。
「開発が上手い」より「コミュニケーションが上手い」を優先する
エンジニアになった理由として「もくもくとパソコンでプログラミングしていればいいから」というのは私だけでしょうか。正直、必要な仕様だけもらってあとはひたすら集中してプロダクトを作るのはもっとも楽しい時間です。
しかし「コードを書く」以外でバリューを発揮しようと思うと、避けては通れないのがコミュニケーションです。
というかコミュニケーションが面倒だからエンジニアになったのに、ややもすれば他の職種以上にコミュニケーションが重要かもしれないのが、エンジニアのジレンマのひとつだとよく思っています。
「ふつうのエンジニア」を目指すのであれば、孤高の存在は諦めて、自身のできる範囲でコミュニケーションも頑張る必要はあるでしょう。
とにかく発言を増やす
あなたが年がら年中まくしたてているエンジニアでなければ、シンプルに発言の量が倍になるよう意識してみるのは良い工夫のはずです。
とくに「発言するタイミングを見計らっている」ことが多いようであれば、そのフィルターをもうすこし緩くして気軽に話をしてみると、意外と効果があります。
フィルターを緩めようとする直前、「この話題には明るくないから」「無駄なことを言って恥を書きたくない」「みんなの時間を無駄にしたくない」など、色々な言い訳も出てくることでしょう。
しかしそのデメリットは、たいてい「自分が話をしてみたことがキッカケで話が円滑に進んだ」というメリットで上書きされるはずです。
ミーティングの結論を想像しておく
もうひとつ、ちょっとの準備で大きく効果の出ることに「ミーティングの準備」があります。結局計画の話をしてますね。
準備といっても難しいことはなく、ミーティング前（もしくは最初の2,3分)で「このミーティングはどのような結論に落ち着くだろうか」ということを考えるだけです。
これが想像できていれば、議論はスムーズに理解できるでしょう。あるいはそんなあなたが議事録を書いてあげれば、とても整理されたドキュメントが書けるはずです。さらには議論のファシリテーションだって行えるでしょう。
もし結論がまったく見えなくても、それもひとつの成果です。「なぜ想像できなかったか」がわかっていれば、そのミーティングで理解したり質問したりすべきことが明確になるはずですし、もしかするとミーティングを開催する意味が無いかもしれません。
ここでもコーディングは一切登場しません。しかしこのミーティングは、おそらく正しい設計やアジャイルな開発においてポジティブな影響を与えていることでしょう。
まとめ
なるべく具体的なtipsとあわせて書いてみましたが、あらためて「エンジニアリングスキルよりも大切なものがあるかも」という観点を持ったときの考えを載せてみました。
エンジニアリングが楽しい人にとってこれらのスキルは、最新の技術を追うよりも地味でつまらないものかもしれません。
ただ「バリューを発揮する」という観点では、一度考えてみたり取り組んでみたりする価値はあるはずです。
ほか「ふつうのエンジニア」の人からのコメントもお待ちしています。
こんな記事も書いています
ミーティングにはサプライズを持ち込まない
コミュニケーションに関して。「ミーティングの結論を想像しておく」というテーマをさらに書き直したものです。