ニフティ株式会社でシニアエンジニアしています芦川です。
ニフティは他社と比べてトラブルが多いんじゃないか？とか、そういう話ではありません。
これまで「基幹システムグループ サービスインフラチームの紹介です」「目指せ、自己管理型チーム！ 役割分担の垣根を取っ払い、心理的安全性を高めるチームマネジメント手法の紹介」とチーム全体の話を書いてきましたが、今回はエンジニアの学習と成長について私の経験談を通して思っていることを書きます。（長文です。すいません！）
この記事を書いたきっかけ
社内では、これからどんなことを学習すればよいのか、どんなときに学習すれば良いのか、学習するモチベーションは何なのか、というような話がよく出ます。私自身はこれまで18年のエンジニア人生を送ってきました。今回のブログでは、どんなとき、どんな感じに私が学習してきたかということと、それらは成長のフレームワーク（コンフォートゾーン、ラーニングゾーン、パニックゾーン）にどんなふうに適合しているのかについて整理してみたいと思い、この記事を書くことにしました。
これからのエンジニア人生が長い人、これからエンジニアを目指す人が読んで、少しでも参考になればいいなと思います。
コンフォートゾーンとは、「居心地のいい場所」。居心地のいい場所に居続けると人間は成長しません。ラーニングゾーンに身を置いた方が人間は成長する、と言われています。
そもそもなぜ学習の必要があるのか？
日々、エンジニアは学習が必要であると言えます。メインのスクリプト言語の変遷でいうと、私が18年前に入社したときに学習したPerlはもう社内では廃れ、その後も、PHP、Rubyと続いてきましたが、今はPythonがメインになっています。しかし、このPythonもより便利で強力なものが出てくれば、いつの日か廃れることは間違いありません。こうした技術的な変遷がある限り学習の必要があります。
そうしたなか、気持ちはいつもポジティブ。学習した分、当然、開発効率があがり、明るい未来があることも経験を通して知っているためです。使いこなせるようになると単純に楽しいし。
余談ですが、「アンラーニング」という言葉がありますよね。これは、特に技術の移り変わりの激しいエンジニアには必要なことかもしれません。
「アンラーニング」（unlearning）とは、いったん学んだ知識や既存の価値観を批判的思考によって意識的に棄て去り、新たに学び直すこと。
引用：アンラーニング
私はいつ学習してきたのか？
私自身は、これまで業務の中で必要に迫られて学習をしてきました。次の業務で使う言語やフレームワーク、クラウドサービスなどについては、主として業務時間内に学習することが多かったです。稀に切羽詰まり、例えば、翌週の火曜日のプランニング（スクラムイベント）で必要なDjango REST Frameworkを知るために、土曜日をまる1日かけて本を完読するような学習をすることもありました。またAWS CDKの初期学習時は、AWS Documentationをスマホでずっと読んだりすることもありました。（スマホで読んだほうがなぜか私は公式ドキュメントが読みやすい。）
また思い返してみると、数多くの障害対応、トラブル対応を経験することで、都度、未知の事象を調べ解決していくプロセスが自分の成長に繋がってきたということがあります。前述の学習はある程度のゆとりがある中での学習になりますが、トラブル時は調べないといけない期限が迫っている状態であり、かつ、何を差し置いてもその調査時間をとることになるため、いわば強制的なラーニングゾーンになれる時間です。また、あとから振り返ると、通常での学習では気づけないようなことや観点が経験として学べる、ということが大きかったと思います。ただし、この状況はきつい状況であり、ずっと居続けていてはいけない状態です。幸いにも社風もあるのかこれまで1人でこの状況に居続けることはなく、誰かに相談できたり一緒に解決したり、ということができてきました。結果的に限りなくパニックゾーンに近いラーニングゾーンだったのでしょう。もし解決できないときは、本当にパニックゾーンであり、肉体的、精神的に支障をきたしてしまうのだと思います。
余談ですが、解決できない技術的なトラブルはないと思っています。なぜなら、技術は人の手によって生み出されたもの。なので人の手によって解決できると思っています。ので技術的な課題に対してパニックゾーンに陥る必要はありません。
一方で、業務として必要に迫られてないものや、ちょっと興味がある程度で書籍のみで勉強したことは実は続きませんでした。。。しかし、プライベートで何かアプリケーションやサービスを作ろうと思ったときはその気持ちを優先し、いろいろと作ってきました。このようなときは「学習したい」という気持ちではなく、「作りたい」が先行している状態です。実現したいものが先にある状態。作ることを繰り返していくと、あとから「あー、これを学習したのか」となり、同時に自分に満足なアウトプットが出せるのでハッピーです。こちらは、コンフォートゾーンに近いラーニングゾーンなのかな、と思います。ずっと居たいゾーンですね。
また、どの学習においても、いろいろ自分に取り入れたものを、知ったことを整理し、他者に伝えることで、改めて調べたり、理解が進んだりすることはよくあります。
（まさに、このブログ執筆などもそうです。）
成長のフレームワーク（コンフォートゾーン、ラーニングゾーン、パニックゾーン）に経験をあてはめる
人が成長するのは、３つのゾーンの中で、ラーニングゾーンと言われていますが、さらにラーニングゾーンの中にもレベルがあると言われています。
- 高ラーニングゾーン パニックゾーンに近いが、ストレス負荷が高めで高成長が期待できる
- 中ラーニングゾーン その真ん中
- 低ラーニングゾーン コンフォートゾーンに近いが、ストレス負荷、成長率共に低いが伸びている
ここで思ったのは、経験に照らし合わせると、各ラーニングゾーンに達するには、自分から行ける場合もあるし、業務上必要になり、ある意味、強制的に行かされる場合もあるのではないか、ということです。
言い換えれば、実は強制的に、必要に迫られて何かをするほうがが大きく学習できる、つまり身についていく、ということも言えるのではないでしょうか。さらに言うと、その個人が人から言われなくても、「それが業務上必要である、という認知がどれだけできるか」が、個人の成長スピードにかかっている、とも考えられます。ここは今回振り返ってみてはじめて気づいた点でした。（エンジニアに限らずとも、どんな職種でもおそらくそうなのでしょうね。）
また社内での勉強会や輪読への参加など、学習スケジュールが決められているものに関しても、周囲からの強制力という意味では、真ん中あたりに位置しているのではないかと思います。
つまり、私の経験したことをあてはめると以下のような図ができそうです。外側に行くほど、高成長が期待でき、かつ、（個人の認知の違いはありますが）周囲からの強制力があります。
若くてこれからの人へ
トラブルを起こそう、ということではありません。急成長するには、今ある業務を見渡し必要な学習はすでにやれ、と誰かに迫られていると思ったほうが早く成長できるようになる、ということだと思います。また、学習スケジュールが決められているものに参加をし自分にあえて強制をかけていく、ということも意識するとよいと思います。
で、トラブルが起きてしまったら、すすんでトラブル対応に関わり普段経験できないことを経験しましょう。ほかのプロジェクトであってもポストモーテムを読み、自身の経験値として取り入れていくことが大事だと思います。
そして、モチベーションがあるとき、何かを作りたいと思うときは、贅沢に思う存分プライベートの時間を使い、満足いくまで手を動かし作りましょう！
（これが一番楽しい。楽しい、と思う気持ちを大切にしてください。）
そして、それらは、すべて他者に何かしらの形で共有し、自身の理解度を高めていきましょう。
以上が、私の経験談を通して、これからの方へ伝えたいことでした！もっと書きたいことがありましたが、長くなりすぎそうだったので、やめておきます！参考になれば幸いです！
次回からは、成長という文脈において、時間の使い方にフォーカスをして開発生産性における「ゾーン状態」について触れてみたいと想います。
