経験が浅いITエンジニアと一緒に仕事する際に注意すること

なんだかんだIT系のエンジニアとしてやってきてだいぶ経ち、そこそこの経験を積んできた私ですが、最近、経験が浅いエンジニアと一緒に仕事をする機会が多くあり、少しだけ思うところがあったので、一緒に仕事する際の注意点などを紹介したいと思います。

まず、今の仕事をする際、面談時に「若いエンジニアが多いが大丈夫か」みたいなことを訊かれました。

当時は、言葉の真意が分からず、年下のエンジニアと仕事したくらいの経験はあったので、「とくに問題ないですよ」と答えたのですが、実際に契約して、仕事を始め出すと、その言葉の本当の意味を知りました。

参加したプロジェクトは、開発メンバーの多くが20代前半で、サポート的な立ち位置に経験豊富なシステムアーキテクトがいる、といった構成だったのですが、若いエンジニアは自分のやっている作業が正しいのかどうか不安だったのか、なにをやるにしてもアーキテクトや開発にそこまで詳しくないPM（プロジェクトマネージャー）にお伺いを立て、そこで言われたことをなんでも鵜呑みにし、作業の優先度や、具体的な内容や状況を考慮していなかったので、結果、リリース日に間に合わなかったり、出来上がったものの品質が低かったりと、相手先の会社や、その他のシステムも関連していたので、他の会社にも迷惑をかけてしまう、といった状態でした。

入って間もなかった私は、このプロジェクトではこれが当たり前で、それでいいと思っている、と感じて、深入りせずに、最低限やるべきことをやって、次の仕事を探そうとしていたのですが、その前に当時の開発リーダが抜けてしまい、代わりにそのポジションをやるハメになりました。

正直、リーダ的なポジションには向いていないのですが、これもいい機会だと思って、ダメなら、それこそ次の仕事を探そうくらいの気持ちで、やっているのが現状です。

リーダ的なポジションにいると、プロジェクトのメンバーとのやりとりが自然と増えるのですが、そこで感じたのは、意外ときちんと仕事ができる人は少ない、ということ。

もちろん経験が浅いメンバーが多いせいもあるのですが、ある程度、経験を積んでいるメンバーであっても一長一短があったりと、リーダをやっていないと分からないことが多かったので、どういった人がいて、どういったことに気を付けないといけないのか、といったことを、ちょっとだけ紹介したいと思います。

プロジェクトを進める上で重要なスケジュール。とくに本番やステージング環境へのリリースは、相手先の会社を含めての作業になるので、決められたスケジュールを極力守るのは当然で、ある程度、経験を積んだエンジニアであれば、リリース日から逆算して、いつまでに何を終えていないと間に合わない、という感覚は持ち合わせていると思います。また、その重要度であったり、他の会社が関わっていれば、そちらの進捗も考慮して、リリースの予定日が厳守なのか様子見なのか、といったことはなんとなく分かるのですが、経験が浅いエンジニアはこれが分かりません。

当然といえば当然ですが、分からないことで何が起こるのか、というと、リリース日の直前くらいに、間に合わない、といったことを報告してきたり、予定通りにリリースしたとしても品質に問題があって、リリースしたアプリが正常に動作しない、といったことがよくあります。

リリースまでに必要な作業の把握や、それにかかる工数など、その辺りを想像できていないのは仕方がないのですが、それよりも問題なのは、自分の作業の遅れが他の作業にも影響があることを分かっていない、という点で、仮に問題があったとしても、そこまで責任を感じていない人が多く、平然と対応にあと〇日かかります、といったことを報告してきたり、さらによくよく尋ねると、それはすべてが上手くいった時の最短の日数だったりします。

人にもよると思いますが、総じて、経験が浅い人ほど、報告が端的だったり、問題があっても隠そうとする傾向があるので、一緒に仕事をする場合、上の立場であれば、まずは報告内容を信用せず、しつこいくらい内容を詳しく聞いたほうがいいです。

報告する側の立場も考えてくれないかな、と思ったのは、数知れません。

経験が浅いエンジニアは、分からないことがあっても、質問をしないことが多いです。

まったくの未経験の場合は、人によっては、なんでもかんでも質問してくる人がいたりしますが、少しでも経験があったりすると、逆に聞いてこない人が多く、MTGで全体に関わる話をしていても、その時は反応が薄くて、その後、必要に迫られた段階で、最終的に困った挙句、質問してくる、といった感じです。

たしかにある程度の経験を積むと、人に教えてもらうと作業の幅が狭くなったり、報告の義務が生まれたり、教えてもらったことと違った場合に再確認が必要だったりと、手間がかかることが多いので、基本的には訊かなくなるのですが、必要最低限のものについては、当然、確認します。

経験が浅いエンジニアは、この必要最低限のものについても確認せず、レビューの段階になって、仕様の勘違いや検討不足が発覚して、設計を土台から見直す必要があったりします。

開発リーダのポジションで複数のメンバーとやりとりして思ったのは、経験の年数に関わらず、仕事ができる人は、質問してくる内容が的確です。同じ仕事を1年間やっていた人よりも、3ヶ月前に入ってきた人の方が作業内容をより把握していることがあり、できる人はちゃんと資料を読み込んでいることが、質問の内容からうかがい知れます。

質問してくるべき人が質問してこないと逆に不安になり、大抵の場合、その不安は的中するので、質問をしやすい雰囲気づくり、というのが重要だと改めて思い知りました。

ただ、手間暇かけて必要なことを事前にすべて教えておいたり、レビューで細かく指摘していた場合、次の作業で似たようなことを訊かれることが多く、自分で調べてもらった時よりも応用が効かない状態になるので、傍から見ていたら、失敗すると事前に分かってはいても、クリティカルなもの以外は指摘はせず、あとは本人に任せてやってもらった方が、後々、経験として生きるようです。

正直なところ、今やっている仕事は、そこまで仕様的に難しいものではないので、油断していたのですが、経験が浅いエンジニアは意外と設計できない人が多いです。

設計書などのレビューに参加して内容を聞いていると、とりあえず、他の資料を参考に作ってみました、といったものが、他の資料のまんまで、今回の仕様に当てはまらない箇所がそのままで、なにを設計したのか、と疑わざるを得ないことが何度かあり、内部のMTGや客先との打合せの話を聞いてれば分かることであっても、話についていけていないのか、考慮が抜け落ちていることがザラにあります。

また中には、どうしてそういう設計をしているのか、ということを微塵も考えない人がいて、言われたことはできるけど、言われていないことは一切できず、応用がまったく効かないみたいな人もいました。

エージェントサービスを介した人員募集の条件に、設計ができる人だったり、スタンドアローンで動ける人、といった条件があったりして、さすがに最初からスタンドアローンで設計は厳しいのでは、と思っていたのですが、もしかしたら、もう少し、低いレベルの話をしているのではないか、と、最近は思い始めています。

これはどちらかといえば、外国人の方に多いので、日本語の細かいニュアンスが通じていないだけの可能性がありますが、ちょっと前に聞いた内容と違う答えが返ってくることがあります。

ただ、あの時、こう言ってませんでした、と聞くと、口籠った後に、そうじゃない、みたいな感じで紛らわしてやり過ごそうという感じが見え隠れするので、多分、分かっていると思います。

なので、外国の人と一緒に仕事する際は、同じ質問であっても何度も尋ねた方がよさそうです。

ちなみに日本と外国のITエンジニアを比較した場合、正直なところ、スキルが高いのは外国人の方で、とくに女性のエンジニアに優秀な人が沢山います。男性にも優秀な人はいますが、そういう人は、同じ職場に長居はせず、すぐに別の会社や国に移ってしまう印象。

経験が浅いエンジニアであっても、スキルが高い人はもちろんいます。ただ、そういった場合、チームでの開発経験が少ないため、他にもっといい方法があるのではないか、自分がやったことは合っているのか、といったような不安を抱えているのは他のメンバーと同じなので、レビュー時に相手から言われたことを鵜呑みにしてしまう傾向がありました。

傍から見ていた際、そこはもっと詳しい内容や状況を話して、より詳細を詰めてほしいといった時も、「はい。分かりました」みたいな感じで引き受けて、その後、一旦、持ち帰った後に、案の定、考慮が必要なケースが出てきて、再度、MTGをセッティングしては話をもう一度聞く、みたいなことを何度も繰り返していたので、いくら時間があっても足りない、みたいな感じになっていました。

結果、その人は当時の開発リーダで、その後、辞めてしまったわけですが、当時の私は、その人が、崖があると分かっている方に向かって、草むらを分け入る様が脳裏に浮かび、サポートで軌道修正したつもりでも、すぐに脱線して徒労感を何度も味わったので、経験というのは非常に大事なんだな、と、思い知りました。

経験が浅いエンジニアに対して、一番、改めた方がいいと思ったのが、質問をする際に「これでいいですか？」と、尋ねていたことです。

プロジェクトに参画して間もない頃は環境構築だったり、プロジェクトのやり方などが分からないので、上記のような質問もしますが、設計をした上で、この質問はNGです。

理由は逆に聞かれて見ると分かるのですが、設計の担当からこれを聞いた場合、聞かれた方は最終的な責任を丸投げされたように感じ、さらには『あなたが設計したんじゃないの？』と思われ、その人に対して不信感が募り、次のレビューでのチェックがより厳しくなり、最終的には、めちゃくちゃ細かいところにも指摘が入って、通るものも通らなくなります。

不安から答えが欲しくて「これでいいですか？」と聞いているのだと思いますが、せめて、「他に懸念点などありますか」くらいに留めておかないと、逆に自分の首を絞める結果となります。

仕事でやっている以上、責任を持ってやってほしいですが、20代前半の頃の自分のことを顧みると、同じような対応をしていた気がするので、やはり、経験というのは大事ですね。

今では、自分が作ったものに対して、文句があるなら言ってください、考慮の余地があれば、検討します。くらいの心持ちでいて、その方が自分はもちろん、周りも含めてうまく回ります。

上記のことを踏まえて、面談時に言われた「若いエンジニアが多いが大丈夫か」という言葉の真意を改めて考えると、つまり、経験が豊富なエンジニアがいないので、プロジェクトが上手く回っておらず、残業時間が多い傾向にある。今のところ、改善の予定はないので、しばらくその状況が続くと思われるが、それに付き合って貰えるだろうか。また、可能であれば、メンバーのとりまとめ役になってもらって、こちらはそろそろ手を放して楽をしたいと思っている、といった意味になるかと思います。

私の場合、面談の経験が少なかったので、残念ながら、その時は、言葉の真意を見抜けませんでしたが、この記事を読んだあなたであれば、同じ質問をされた際に、そういうことか、と勘付いてくれることでしょう。