20代で圧倒的に成長する人とパッとしない人の決定的な違い
2人の新入社員がいた。
同じ学歴レベル。
同じプログラミングの技術力。
同じ採用基準に合格。
それでも、入社から1年後、2年後、5年後になると、一人はバリバリ成長してチームリーダーを任されている一方、もうひとりはいつまで経っても大きな仕事を任せてもらえない…。
これはフィクションだが、こんなことはエンジニア業界に限らず日本中いたるところで発生している。
二人を分けた違いはなんだろうか?それは、、、
高い仕事の基準を自分に課していたかどうか。
君が20代で圧倒的に成長したいと本気で考えているなら、心して続きを読んで欲しい…。
仕事の基準を高く持つとは?
いきなり抽象的な精神論を繰り出しても仕方ないので、具体的なシチュエーションを置いてみる。
例えば、明日からあるタスクを先輩社員と一緒にペアプログラミングでやることになったとしよう。凡人はぶっつけ本番で先輩に教わりながらコードを書く。
(余談：ちなみにこれ↑は仕事をしているとは言えない…ただ先輩の生産能力と時間をいたずらに奪っているだけでなんの貢献も出してないからだ。まあ先輩の仕事は後輩の育成でもあるので全然教えるのはウェルカムだが、自分が教わる立場であればこのことは頭に入れておきたい。)
では、逆に仕事の基準を高く持ってる人は何をするだろう?
例えばこんなこと↓をその日の夜にやってくる。
- タスクの目的、やりたいことを明確にしておく
- 書くことになるであろう処理を順序立てて日本語で説明できるようにしておく
- 関連するテーブル定義を頭に叩き込む
- 「おそらくこうすれば実装できる」というイメージを明確に持てるようにしておく。わからないところは勉強する
- なんなら自分で実装までローカルリポジトリでやっておく
なんとなく「仕事の基準」のイメージが掴めたんじゃないだろうか?
ポイントは、現場でタスクに取り掛かる前に、すでに自分ひとりでも書ける状態にしておくこと。すると、開発中は「答え合わせ」の時間にすることができる。自分が書いたコードと、先輩に教えてもらったり書いてもらったりしたコードの何が違うのか。どこが足りていなかったのかがわかる。(もちろん、最初から全部ひとりで書ける状態にするのは難しいから、書けるところは書いて、書けないところはなぜ書けないのか言語化しておくところまでは最低やっておく。)
PDCAのうち、仕事の基準が低い人は(プランすら立てず)Doをやっている中で、高い基準を持っていれば君はすでにCからAを開発中に回せるということになる。さらに、技術への理解が進めば進むほど仕事そのものや先輩の指導から得られる知識の吸収率が高まっていく。
凡人が10を聞いて1を理解してる間に、君は10を聞いて8を理解して、家に帰ってからその知識を12くらいにしている。こう考えると、たった1日の仕事への取り組み方が、1週間、1ヶ月、1年とすれば天と地ほどの差を生むのは想像に難くない。
つまり、、、
明日のタスクで自分がどこまでアウトプットすれば合格なのか。その基準を決めて、できる限り高く設定する。
これが「主体的に働く」ということ。
自分で先に考えずに先輩に教えてもらったり、仕事時間中にググっているようでは遅い。
就活生を見ていると「学ばせてもらえる環境」を魅力に感じる人が多いように思う。でも、「学ばせて"もらえる”」と言っている時点ですでに遅れている。学ぶのは自分自身だ。環境や仕事を自分の成長に繋げられるかどうかは、その人にかかっている。
目標設定=最小の努力で最大の成果を得る方法
ここからはちょっと戦略的な話。というのも、努力の方向性を戦略的に決めないと、(それが無駄とはもちろん思わないけれど)最速で成長することは難しい。
例えば、フロントエンドエンジニアが毎日深夜まで頑張ってAWSの勉強をしても、仕事で成果を出せる確率は低い。これは極端な例だが、逆を言えば、毎日・毎週の小さな目標を設定することで、小さな努力で最大限の成果を得ることができる。
新人の頃でフロントエンドまわりのタスクが多いのであれば、直近の課題であるcssの仕組み/設計手法とか、javascriptやDOMの理解にフォーカスすべきだろう。BEでデータベースを操作するのにまだ慣れないなら、SQLの基礎や言語・フレームワークが提供している操作方法を勉強する。基本情報技術者試験に出てくる2進数の勉強なんかしている場合ではない(99%実務では使わない。それは勉強ではなく暇つぶしだ。)
大事なのは、「明日(来週)使えるスキルを身につけるために、今日(今週)何をするか?」という小さな目標を決めて、勉強すること。
すると、成果につながりやすいのはもちろんだが、学習面でも大きな効果がある。仕事で学んだ知識を実践できるからだ。仕事に直結しない勉強をするより、仕事に活かせる勉強をした方が成果と学習効果のどちらも得ることができる。お得。
そして、ある程度(半年くらい)頑張っていると、自然とチームに不足してるスキルに気づくことができるようになってくる。
「本ではもっと効率的な方法が書いてあったけど、現場のテスト弱いな…」
「オブジェクト指向言語なのに手続きを羅列しているぞ…まずくないか?」
「全然効果のないミーティングになってないか?昨日知ったフレームワークが使えるかもしれない」
といった具合。こういうチームの課題に気づけることは千載一遇のチャンスだ。自分が頑張れば改善できるレベルの課題なら、チーム全員に貢献することができる。そして、チームに貢献することは個人で成果を上げることよりはるかに価値が高い。
自分に足りないスキルにフォーカスして目標を立てる。
チームに足りないスキルにフォーカスして目標を立てる。
そうすることで、最短経路で個人で成果を出し、チームにも貢献できる。それによって、さらに大きな仕事が降ってくるようになる。スライム討伐クエストしか任せてもらえなかったのが、早々にメタルスライムの討伐を任せてもらえるようになる。
凄まじくレベルアップできるのは言うまでもないだろう。
本を読むだけで満足するのは三流
ここまで読んでくれたなら、タイトルの意味もわかるはず。レベルアップには経験が必要なので、本を読むだけでは全然足りない。『リーダブルコード』を読みきった直後に、ローカルブランチを切って自分の書いたコードをリーダブルに書き直すまでが勉強だ。
ラーニングピラミッドという概念を知っているだろうか?
(出典：キャリア教育ラボ https://career-ed-lab.mynavi.jp/)
アメリカ国立訓練研究所が提唱している学習定着率モデルで、このモデルによれば読書による定着率は10%しかなく、自ら体験することによって75%まで高まるという。このモデルの確からしさはこの際どうでもいい。重要なのは、ただ本を読むだけなのか実践するのかによって学習効果が大きく変わるということだ。(勉強した経験があれば「実際にやってみる」ことの効果は数値化せずとも直観できるはず)
とはいえ、仕事も勉強も楽しく夢中になれるのが一番
これまでさんざん脅して、ともすれば苦行のような仕事・勉強の取り組み方を勧めておいてアレだが…
大大大前提は、楽しくやっていることです。マジで。
(楽しみの感情とか知的興奮が学習に与える効果を科学的根拠を持って説明するのもやぶさかではないけれど、野暮なので書かないでおく。)
これまで、無理に頑張りすぎて燃え尽きて、消えていった人たちを山ほど見てきた…。特に頑張り屋だったり責任感が強い人ほど、自分の精神状態を顧みずに破滅しやすい。一時はがんばれても、持続可能でないやり方はいずれ大きな代償を伴うので、
「最近頑張り過ぎかな。ちょっとしんどいかも」と思ったら、しっかり休んで、遊んで、コンディションを整えるのもプロフェッショナルに必要なスキル。
では、君が楽しく充実した仕事人生を送れることを祈っているよ。
P.S.
偉そうなことを書いてきたけれど、自分も最初からできていたわけじゃないし、伸び悩んだ時期もあったし、しょうもない凡ミスや失敗をたくさんやらかしてきた^^;
「凡人」なんてひどい言葉を使っているが、実はこれは新人時代の僕だったりする。
おそらくほとんどの人は凡人スタートで、それが普通。最初から高い仕事の基準を持てている人は本当にごく少数なので、今仮にこの記事を読んで「自分の仕事の基準低いなあ...」と落ち込んだとしても、これからの頑張り次第でどうにでもなる。今日から頑張っていこう。