作業をこなすだけで終わらせない――エンジニアが「プロジェクトを動かす実感」を得る方法

難しい実装や設計を任され、ときには顧客と直接話し、チームの判断にも関わる。忙しいけれど、不思議と前向きに働ける。一方で、指示された作業をこなすだけの日々が続くと、ふと「このままでいいのだろうか」と考え始める。

エンジニアが「成長できない環境だ」と感じるとき、原因は仕事の量や技術の古さだけではありません。私の経験では、エンジニアの気持ちが離れ始めるのは「先の成長が見えないとき」です。自分の仕事がプロジェクトを動かしている実感がなく、この先どうなれるのかも見えない。その状態が続くと、人は静かに離れていきます。

この記事では、アクセンチュアで12年、数百人規模のプロジェクトでPMOをしてきた経験から、「成長できない環境」と感じる現場に共通する3つの型と、管理する側・エンジニア本人の両方ができることをまとめます。

エンジニアが「成長できない環境」と感じ始めるとき

「成長できない」と感じている人に話を聞くと、意外なほど「忙しくて大変だから」という理由は出てきません。むしろ、責任が増えて忙しくなっている時期のほうが、前向きに取り組めていることが多いものです。

気持ちが離れ始めるのは、たとえばこんなときです。

• 渡される仕事が、いつも「この画面のこの部分を直して」という切り出された作業だけ
• 仕様は決まった状態で降りてきて、なぜそうなったのかは誰も説明しない
• 自分が作った機能がリリース後にどう使われ、誰の役に立ったのかが分からない
• 1年前と今とで、任されている仕事の中身がほとんど変わっていない

どれも、すぐに困るような問題ではありません。作業は進むし、評価が極端に下がるわけでもない。だからこそ周りは気づきにくく、本人の中でだけ「このままでいいのか」という気持ちが少しずつ大きくなっていきます。

成長が見えない現場に共通する3つの型

これまで多くの現場を見てきて、「先が見えない」状態にはおおよそ3つの型があると感じています。

型1：仕事の目的が見えない（作業だけが渡される）

いちばん多いのがこの型です。タスクは細かく切り出されて渡されるものの、そのタスクがプロジェクト全体の中でどんな意味を持つのか、何のためにやるのかが伝わっていない。

目的が見えないと、仕事の良し悪しを自分で判断できません。言われたとおりに作ることはできても、「もっと良いやり方はないか」と考える材料がない。結果として、言われたことだけをこなす状態が固定されてしまいます。

型2：判断に関わらない（決まったことをやるだけ）

設計の方針、優先順位、顧客への提案。こうした判断の場に呼ばれず、決まった結果だけが降りてくる型です。

判断に関わると、責任は増えます。でも同時に、「なぜその選択をしたのか」「別の案と比べて何が良かったのか」を考える機会が生まれる。この経験の差が、数年たつと大きな差になります。判断に一度も関わらないまま経験年数だけが増えていくと、本人も「自分は何ができるようになったのか」を説明できなくなっていきます。

型3：結果が返ってこない（役に立った実感がない）

作ったものがリリースされた後、どう使われ、誰が助かったのか。その結果が作った本人に返ってこない型です。

アクセンチュア時代を振り返ると、私がこの仕事を続けてこられた理由の一つは、自分の工夫で状況が変わる瞬間を何度も味わえたことでした。自分の提案したやり方で、不具合が一発で直った。会議で自分の一言をきっかけに議論がまとまった。用意した資料と説明で、お客さんの表情がふっと笑顔に変わった。こうした瞬間の「自分の仕事がプロジェクトを動かしている」という感覚は、忙しさや大変さを上回る力になります。

逆に言えば、結果が返ってこない現場では、どれだけ真面目に働いてもこの感覚が得られません。「人の役に立てている」「一人の人間として成長していける」という手応えは、何物にも代えがたいものだと思います。

管理する側にできること：作業ではなく「先」を見せる

PMOや管理職の立場からできることは、大がかりな制度づくりではありません。日々の仕事の渡し方を少し変えるだけで、メンバーの見えている景色は変わります。

目的を一緒に渡す

タスクを渡すときに、「この機能は、営業担当が外出先で在庫を確認できるようにするためのもの」のように、目的を一言添える。それだけで、メンバーは自分の仕事の良し悪しを自分で考えられるようになります。

判断の場に一度呼んでみる

設計レビューや顧客との打ち合わせに、まずは同席するだけでも構いません。判断がどう下されるのかを間近で見ることが、次に自分が判断する側に回る準備になります。

合わない仕事は「本人の問題」と決めつけない

パフォーマンスが出ていない人がいると、つい本人のやる気や能力の問題に見えてしまいます。でも実際には、割り当てたタスクが本人の特性に合っていないだけ、ということも少なくありません。私はそういうとき、「具体的にどうすれば活躍できるか」「私にできるサポートは何か」を本人と話し合うようにしてきました。役割が変わるだけで、表情が変わる人は少なくありません。

私自身は、メンバーの役割を決めるとき、スキルよりもコミュニケーションを見ることが多いです。スキルは、周りのメンバーへのヒアリングである程度カバーできます。一方でコミュニケーションは、本人が自発的に作り出すことが特に難しいものだからです。

なかでも特に意識しているのが報告ラインです。体制図を中心に、誰が誰に、何を、どのタイミングで報告するのかというコミュニケーションを前もって設計しておく。報告ラインがはっきりしていると、メンバーにとっても、自分の仕事がどこにつながっているのかが見えやすくなります。

エンジニア本人にできること：自分から「先」を取りに行く

環境が変わるのを待つだけでなく、エンジニア本人の側からできることもあります。どれも、明日から始められることです。

• タスクの「目的」を一度聞いてみる：「この機能は、誰のどんな困りごとを解決するためのものですか」と聞くだけで、仕事の見え方が変わります
• 判断の材料を出す：決まったことをやるだけでなく、「A案とB案ならこういう違いがあります」と材料を添えて返す。判断に関わる第一歩です
• リリース後の結果を聞きに行く：作った機能が使われているか、困りごとは減ったか。自分から聞きに行けば、結果は返ってきます
• 1年前の自分と比べて書き出す：任される範囲がどう変わったかを書き出すと、成長しているのか止まっているのかが見えてきます

それでも、仕事の範囲を広げる余地がまったくない現場もあります。そのときは、今の現場で得たい経験がまだあるのかを考えたうえで、次の現場を選ぶのも一つの道です。案件を選ぶときは、単価や技術だけでなく、任される役割や、顧客・チームの判断にどこまで関われるかを確かめておくと、「入ってみたら作業だけだった」を防ぎやすくなります。

まとめ：成長できない環境の正体は「先が見えない」こと

エンジニアが「成長できない環境だ」と感じるのは、仕事が楽だからでも、忙しいからでもありません。仕事の目的が見えない、判断に関われない、結果が返ってこない。この3つが重なって、「この先の自分」が見えなくなったときです。

管理する側は、作業ではなく「先」を見せる。エンジニア本人は、自分から「先」を取りに行く。その両方がそろうと、同じ現場でも見える景色は大きく変わります。自分の仕事がプロジェクトを動かしている実感は、どんな技術よりも長く、その人を支えてくれるはずです。

あわせて読みたい

• 「SESの案件が減っている」は本当？上流工程で選ばれるエンジニアの条件
• 伸びるエンジニアは「まだ伸びていない」と思っている――PMOが見てきた成長の差