ITコンサルティングファームでシステムエンジニアやプロジェクトリーダーを担当していたなかつ（@takunaka1991）です。
システムエンジニアといっても、様々な使命や役割があります。
インフラエンジニア、データベースエンジニア、フロントエンジニアなどの種類の前に、もっと大切な「性格」から考えられるエンジニアのタイプがあります。
- なぜ仕事に対して取り組む姿勢が違うんだろう
- 適材適所に配置しているはずが、チームが機能しない
- いつも同じフレームワーク、技術でモチベーションが低下する
などの悩みをお持ちではありませんか？
当記事では、システムエンジニアやプロジェクトリーダーの現場経験を活かして、エンジニアのタイプ別に適材適所の見極め方を解説します。
具体的には、
- 研究者タイプ
- 製作者タイプ
- 要望重視タイプ
- 最適化タイプ
を紹介します。
10分程度で読めますし、チーム状況が劇的に改善される可能性が高いので、まずはご一読を。
※当記事は、エンジニアの方の自己分析にも活かせますし、他の職種でも応用できることがあると思います。
リンクで飛べる目次
エンジニアのタイプ別を紹介する前に、この記事の概要
エンジニア時代に人の役割を考えて、チームのどこに誰を配置するか考える機会が多かったので、そのとき感じていたことを書きます。
そこで記事を書くまえに「エンジニア タイプ」と調べました。
しかし、「これだ！」と来るものがありませんでした。ですので少しオピニオン的な感じになるのですが、そのときの感覚と経験を記事にしようと思い、筆をとりました。
記事中には、「こんな人いない！」という説明があるかもしれませんが、それも含めて楽しんでいただければと思います。
エンジニアのタイプ別紹介＜研究者タイプ編＞
研究者タイプの特徴は、「最新技術をいかに使えるか」ということを重要視している。
製品を作ること、要望に応えることよりも、最新技術を使いたくてしょうがないタイプである。
例えば、
- javaのバージョンが発表された瞬間に、システムのjavaのバージョンを上げようとする
- 時間がない時でも、あえて難しい最先端の技術で実装する
といった行動が見られる。（javaのバージョンは極端な例ですが...）
このタイプの配置は、一般の方では対応が難しい箇所の対応、もしくは技術アドバイザーといったポジションが良いと思う。
研究者タイプへの接し方は、以下の通りである。
- 「ここの機能が難しくて、アドバイスをもらえると嬉しいのですが。。。」
- 「お客さんの要望で、〇〇を△△にしたいんだけど、技術的に出来そうですか？」
では、研究者タイプには、どのような成果物を求めるのが良いか。
- 最新技術をチームに展開するための資料
- 最新技術をシステムに導入して、どういう効果を得たかの論文
といった知識共有を目的とした成果物を求めるのが、良いと考えている。
余談だが、優秀な研究者タイプに工数見積もりをさせると少なめになるため、スケジュールは多めに取るのが良いでしょう。
エンジニアのタイプ別紹介＜製作者タイプ編＞
製作者タイプの特徴は、「いかに良いモノ作るか？」ということを重要視している。
最新技術を使わなくても、要望が満たせなくても良いモノを作る傾向がある。
基本的にクライアントの要望に沿った上で、製品を作るエンジニアが多い。
しかし、中には、「要望がおかしいでしょ？それではいいシステムを作れないよ！」という話を蒸し返す人がいる。（蒸し返すのが悪いわけでは無いのだが。）
例えば、以下の行動がみられる。
- ソースが汚いと書き直しをさせる
- 要望を満たしているUIでも、良くないと感じれば直そうとする
このタイプの適所は、プロダクト管理、品質管理である。作らせると凝ってしまう傾向がある人の場合は、管理の方が良いと考えている。
それ以外は、製品を作る役目で問題ないだろう。（設計→コーディング→テスト等）
製作者タイプへの接し方は、以下の通りである。
- 「この部分は、システムとしてどうあるべき？」
- 「この問題は、どのように回避するべき？」
では、製作者タイプに、どのような成果物を求めるのが良いか？
- システムに関する設計書や仕様書
- コーディング規約やソースそのもの
といったシステムにまつわるルールや仕様が書いてあるモノがおすすめである。もしくはレビュー完了後のソースで問題ないだろう。
エンジニアのタイプ別紹介＜要望重視タイプ編＞
要望重視タイプの特徴は、「いかにクライアントを満足させるか？」ということを重要視している。
最新技術を使わなくても、ソースが多少汚くても、クライアントの要望に応えることができれば良いという傾向がある。そのため、クライアントの要望を安易に受けがちというのがある。
技術的に「できることなら、なんでもやります」となってしまう人も少なからずいる。
もちろんクライアントのいうことを聞くことは大切だが、それで将来的に業務が歪むようでは失敗になる。
例えば、以下の行動がみられる。
- クライアントが言ったから、こういう機能を作ろう
- クライアントがこのUI好きだから全部合わせよう
このタイプの適所は、クライアントの打ち合わせに参加する人、チーム管理だろう。クライアントの要望を把握することができるなら、議事録要員としても良い。
さらにこのタイプはクライアントから評価が高いので、資料の説明なども良いだろう。
チーム管理に関しては、要望を理解している以上チームの目的を設定し最短ルートを取ることができると考えたからである。（要望の背景を掴めないと正直厳しいとは思うが。）
要望重視タイプへの接し方は、以下の通りである。
- クライアントの要望はなんですか？
- 要望を解決するとどのような課題を解決できますか？
では、要望重視タイプに、どのような成果物を求めるのが良いか？
- セッション用の資料作成
- 要望一覧など、上流工程の成果物、もしくは課題管理一覧
といったクライアントに関する資料をまとめてもらおう。
要望に対応するかは、次章で説明する最適化タイプに決めてもらうのが良いだろう。
「クライアントが言ったから」などという人がいたら気をつけてほしい。要望の背景を掴めるようになっていないと修正を重ねることになるからだ。
エンジニアのタイプ別紹介＜最適化タイプ編＞
最適化タイプの特徴は、「その瞬間で最適解を出せる人」である。
上の３タイプの人をまとめ、チームでシステムを構築していける能力がある。このタイプはプロジェクトリーダー、マネージャーなどのポジションがあっている。
最新技術は手段と捉え、製品の良さは期間とコストが許す限り求める。
クライアントの要望は背景をつかんだ上で、システムを本当に改修するべきか判断できる。
しかし、完璧に見えるこのタイプにも弱点がある。基本的に仕事ができて結果が出せるので仕事が大量に振られる。
その結果、上の3タイプの人に怒ってしまったり、思い通りにならないことに苛立ちを覚えるだろう。またストレスが一番かかるのもこのタイプの人である。
それでも、このタイプが会社で一番重宝されるので、目指す価値はあるだろう。
システムエンジニアをタイプ別に理解する！性格と適所の見極め方を解説！のまとめ
僕が今まであってきたエンジニア達をタイプ別に分けてみました。
タイプを理解してあげることで、成果を上げてくれるかもしれません。自分のチームや周りを見渡して、確認してみましょう。
もちろん、現場では適材適所にヒトを配置できるわけではないです。それどころかやりたくない仕事をしている方が多いと認識しています。
この記事で説明したタイプを頭の片隅に置いておけば、チーム運営のマネジメントの際に役に立つでしょう。
それでも、IT業界の人間関係って厳しいときがありますよね。
僕はITコンサルティングファームに転職した後、すぐ辞めました。そのときの記事がこちらです。
ITエンジニアにおすすめの記事
＞＞レバテックフリーランスの評判と口コミを実際に使った現役フリーランスSEが語る
