伸びるエンジニアは「まだ伸びていない」と思っている――PMOが見てきた成長の差

同じくらいの経験年数なのに、案件を重ねるたびに目に見えて伸びていく人がいます。一方で、経験は長いはずなのに、同じような問題で何度も炎上してしまう人もいます。

この差は、才能や学歴で決まっているわけではありません。アクセンチュアで12年、数百人規模のプロジェクトでPMOをしてきて私が思うのは、違いは「ただ経験したかどうか」ではなく、「経験を振り返り、分析できているか」だということです。

この記事では、仕事で伸びる人と伸びない人の違いを3つに整理し、経験を「成長」に変えるための振り返りのやり方をまとめます。これから上流工程やPMOに進みたいエンジニアの方にも、そのまま使える話です。

経験年数が長いのに、同じところでつまずく人がいる

プロジェクトの現場では、経験年数と成長は必ずしも比例しません。

ある人は、案件のたびに少しずつ仕事の進め方が変わっていき、同じ原因で失敗することがなくなっていきます。別の人は、10年近い経験があるのに、要件の認識ずれ、確認漏れ、直前になっての「間に合いません」と、毎回似たようなところでつまずきます。

本人たちの能力に大きな差があるわけではありません。どちらも真面目に働いていて、どちらも大変な現場をくぐってきています。違うのは、終わった経験をそのまま置いておくか、振り返って次に持ち越すかです。

経験というのは、ただ積むだけでは資産になりません。活かして初めて資産になります。

伸びる人と伸びない人を分ける3つの違い

これまで多くのコンサルタントやPMO、エンジニアと一緒に仕事をしてきて、伸びる人と伸びない人の違いは、おおむね次の3つに集約できると感じています。

1. 「自分はまだ伸びていない」と思えるか

意外に思われるかもしれませんが、伸びる人は「自分はまだ伸びていない」と思っている人、もしくは「伸びていない」という事実に向き合える人です。

プロジェクトは、毎回内容が変わります。たとえるなら、毎回セーブデータが消されて、また最初から始めるようなものです。誰もが「よく分からない状態」からスタートします。そのなかで、よく分からない自分を受け入れて、自分なりに考えて動き続ける。それを繰り返している人ほど、大きく伸びていきます。

経験を積み、立場が上がっても、「少しでも伸びてやろう」という一兵卒の気持ちを持ち続けられるかどうか。ここが最初の分かれ目です。

2. 分かったふりをしないか

反対に、あまり伸びないのは「分かっていないのに、分かっているふりをする」「分かったと決めつけてしまう」人です。

分かったふりをすると、その場はやり過ごせます。けれども、分からないことを分からないまま進めるので、あとで認識のずれや手戻りとなって返ってきます。しかも、本人の中では「分かったこと」になっているので、なぜつまずいたのかを振り返ることもできません。

恥ずかしさをこらえて「ここが分かっていません」と言える人は、その場では格好悪く見えても、確実に前に進みます。

3. 経験を振り返り、言葉にしているか

3つ目が、いちばん差がつくところです。伸びる人は、案件や工程が一区切りつくたびに、次のようなことを考えています。

• うまくいった理由は何だったのか
• 失敗の原因は何だったのか
• 次に活かすなら、何を変えるのか

ここまで考えて初めて、経験は「知見」に変わり、価値になります。逆に言えば、どれだけ大変な案件をくぐり抜けても、ここを考えなければ「大変だった」という記憶が残るだけです。同じ原因の失敗を繰り返してしまうのは、能力の問題というより、原因を言葉にしないまま次の案件に進んでいることが多いのです。

「前と似た案件」と「この人なら大丈夫」が落とし穴になる

経験を積んだ人ほど気をつけたい落とし穴が2つあります。

前と似た案件で、あぐらをかいてしまう

プロジェクトには「前と似ている部分がある案件」もあります。以前のやり方を流用できるのは、それ自体はとてもよいことです。

ただ、うまく流用できたことで「自分は伸びている」と錯覚し、あぐらをかいてしまう人は少なくありません。似ている部分に目が行くあまり、今回だけ違う部分――関係者、前提、制約――を見落とします。伸びていない自分に目が向かなくなったときが、いちばん危ないタイミングです。

「この人なら大丈夫」と思われている人ほど、確認が抜ける

アクセンチュア時代にたくさん見てきたのですが、意外と危ないのは「この人なら大丈夫」と思われている人です。

優秀だから任される。説明しなくても伝わると思われる。だから途中で確認されません。ところが、できる人ほど前提の擦り合わせや認識合わせを飛ばして進めてしまうことがあります。私が見てきたトラブルも、能力不足より確認不足が原因のことが多かったように思います。

どんなに安心感のある相手でも、あえて立ち止まって前提を言葉にしてもらう。多く任せるほど、確認する。これは任せる側だけでなく、任される側が自分に向けて持っておきたい視点でもあります。

私自身にも、振り返ってやり方を変えた経験があります。あるプロジェクトで、障害の改修を「とにかくどんどん直していく」スタイルで進めていたことがありました。ところが、直したはずの箇所の周りで別の不具合が出るデグレードや、同じ原因の不具合をほかの箇所で直し漏らす改修漏れが、何度も起きるようになりました。

振り返ってみると、問題は改修のスピードではなく、一つひとつの障害について「同じ原因の不具合がほかにもないか（横展開）」「この改修がほかの機能に影響しないか（影響調査）」を十分に確かめないまま、次の改修に進んでいたことでした。それからは、改修の件数よりも、障害ごとに横展開と影響調査ができているかのチェックを重点的に行うようにしていきました。

経験を「資産」に変える振り返りのやり方

振り返りというと、立派な報告書や反省会を思い浮かべるかもしれませんが、大げさなものでなくて構いません。大事なのは、続けられる形にすることです。

区切りごとに「3つの問い」を書き出す

工程の区切りや、大きな会議・リリースが終わったタイミングで、先ほどの3つの問い（うまくいった理由／失敗の原因／次に変えること）を数行ずつ書き出します。ノートでもメモアプリでも構いません。頭の中で考えるだけでなく、言葉にして残すことで、次の案件の最初に読み返せます。

「何が起きたか」ではなく「なぜ起きたか」まで書く

「仕様の認識がずれていた」で止めると、次も同じことが起きます。「誰と誰の間で、どの言葉の意味がずれていたのか」「なぜその時点で気づけなかったのか」まで掘り下げると、次に打つ手が具体的になります。

分からないことは、恥を忍んで人に聞く

振り返っても原因が分からないときは、一人で抱え込まずに周りに聞きます。私自身、開発設計からプロジェクト管理に移った頃は、会議で大勢から質問され続け、「あなたは結局、何をしたかったのですか？」と言われたこともあります。そこから少しずつ物事を解決できるようになったのは、恥を忍んで人に聞き、100の課題があるなら100の工夫を重ねてきたからです。

開発メンバーにもできること

この話は、PMOやマネージャーだけのものではありません。開発メンバーの立場でも、今日から始められることがあります。

• タスクが終わったら「想定より時間がかかった理由」を1行メモする
• 不具合を直したら、直し方だけでなく「なぜ作り込んでしまったか」も残す
• 分からない用語や前提は、その場で「〇〇はこういう意味で合っていますか」と確認する
• 前の案件と似ていると感じたときほど、「今回だけ違うところ」を書き出してみる

どれも小さなことですが、続けると「同じところでつまずかない人」になっていきます。そしてそれは、上流工程やPMOに進んだときに、そのまま周りから信頼される力になります。

まとめ：伸びる人は、経験を「次の現場」に持ち越している

• 経験年数と成長は比例しない。差がつくのは「経験を振り返り、分析できているか」
• 伸びる人は「自分はまだ伸びていない」と思え、分かったふりをしない
• 前と似た案件や「この人なら大丈夫」という評価は、確認が抜ける落とし穴になる
• 区切りごとに「うまくいった理由／失敗の原因／次に変えること」を言葉にして残す

特別な才能がなくても、振り返りは誰にでもできます。今の現場での経験を、次の現場で活きる資産に変えていきましょう。

あわせて読みたい

• PMOに向いていない人とは？「いると疲れるPMO」と「助かるPMO」の違い
• 「SESの案件が減っている」は本当？上流工程で選ばれるエンジニアの条件