「エンジニアなら、業務外でもコードを書くべきだ」
「最新技術をキャッチアップし続けないと、AIに仕事を奪われる」

技術の進化が加速する現代、エンジニアを取り巻く空気はどこか張り詰めている。好きで始めたはずのプログラミングが、いつしか義務や焦りに変わり、「自分はエンジニアに向いていないのではないか」と立ち止まってしまうーー。

今回は、そんな若手エンジニアの悩みを、プログラミング言語「Ruby」の生みの親・まつもとゆきひろさんにぶつけてみた。

仕事の「楽しさ」を見失いかけた時、私たちはどう働けばいいのか。変化の時代を長く、健やかに生き抜くためのコツを聞いた。

Rubyアソシエーション理事長
Ruby開発者
まつもと ゆきひろさん（@yukihiro_matz）

プログラミング言語Rubyの生みの親であり、一般財団法人Rubyアソシエーション理事長。株式会社ZOZOやLinkers株式会社、株式会社LIGなど複数社で技術顧問などを務めている。オープンソース、エンジニアのコミュニティ形成などを通じて、国内外のエンジニアの能力向上やモチベーションアップなどに貢献している。島根県松江市名誉市民

仕事が「100%楽しい」わけがない

ーー好きなことを仕事にしたはずなのに、いざやってみると楽しさよりも辛さが勝ってしまう。「自分はエンジニアに向いていないのでは」と自信をなくしてしまう人がいます。

それは、誰にでも起こる普通のことだと思いますよ。

何事も仕事にすると楽しくなくなるってことはあるんです。趣味でやっていた時は純粋に楽しかったけれど、対価を払うとか、責任が発生するとなると楽しくなくなるケースは頻繁に聞きますからね。

納期に間に合わせなきゃいけない、複雑な仕様の折衝をしなきゃいけない。そういう面倒なことがセットになるので、純粋な楽しさが減ってしまうのは当たり前なんです。

私だって、請求書を書く事務作業とか大嫌いですから（笑）。「誰かやってくれないかな」と思いながらやっています。

でも、仕事の中に楽しくない部分があるからといって、イコール「その仕事が向いていない」というわけではありません。むしろ、ソフトウェア開発を仕事にしている人の大半は、どこかに我慢している部分を抱えながら働いているんじゃないでしょうか。

ですから大切なのは、視点の切り替えです。

仕事の全部が楽しいわけじゃないけれど、我慢してやっている中にも、まだ数パーセントの楽しさが残っているはずなんです。そこに「わーい、楽しい！」と意識的にフォーカスして面白がれるかどうかですね。

ーーとはいえ、「それはまつもとさんが『Ruby』という自分の好きな言語を作っているからでは？」と思ってしまう自分もいます。

おっしゃる通り、私はちょっとズルい立場にいますね（笑）。お客さんのためのシステムを作っているわけではなく、自分が理想とするシステムを、自分の好きなようにデザインして作っているわけですから。その点では確かに恵まれています。

でも、私もRuby以外の仕事で、いわゆるクライアントワークのようなソフトウェア開発をした経験はたくさんありますよ。最初から「自分でこれを作ります」と言ったわけではない、人から依頼された仕事です。

じゃあ、その時はつまらなかったかと言うと、やっぱり「わーい、楽しい！」と言いながら作っていたんです。

ーー具体的に、どこに楽しさを見出していたんですか？

一言でいうと、パズルを解く楽しさです。

どんな仕事でも、バグは出ますよね。「頭の中ではこう動くはずなのに、実際には違う動きをしている」。この期待と現実のズレがどこにあるのかを探していく作業は、まさにパズルです。

バグを追い詰めていって、「あ、ここ間違ってた！」と原因を見つけた時の、「やった、解けた！」という快感。これは、作っているのが世界的な言語だろうが、地味な業務システムだろうが、エンジニアリングである以上、変わらない面白さだと思います。

仕事である以上、100%楽しいわけがありません。でも、どんな環境でもパズルを解く楽しさや、自分で解決策を決める裁量は残っています。「向いていない」と悩む前に、その数パーセントの楽しさを味わう工夫をしてみるといいと思いますよ。

「解く」楽しさから、「決める」楽しさへ

ーーAIが正確なコードを書くようになると、パズルを楽しむ機会さえも奪われてしまうのではないでしょうか？

AIの時代になると、人間が書くからこそ生まれていた単純なバグは減ります。ですから、AIにコードを作ってもらって自分はそれをレビューするという関係になると、デバッグのようなパズル的な楽しさは、確かにちょっと減ると思いますね。

ですが、今度はもっとクリエイティブな部分に時間を使えるようになります。「どういうソフトウェアを作るべきか」「どうやって問題を解決すべきか」、あるいは「AのデザインとBのデザイン、どっちの方がユーザーが喜ぶか」といったことですね。

そこには決める楽しみや、設計する楽しみがあります。AIは提案はしてくれますが、最後に決めるのは人間です。その裁量権がある限り、それはそれで楽しいと思いますよ。

ーーそこで疑問なのですが、AI任せで動くものが作れる時代に、技術の「原理原則」をどこまで理解しておくべきかが気になります。

先輩や上司が「仕組みを理解しろ」と言いたくなる気持ちは分かりますが、正直言って、50年前のプログラマーが知っていた知識を現在の私が知っているかというと、知らないことも多いです。

新しいツールの登場によって技術が抽象化され、詳しい中身を知らなくて済むようになるのは、技術の進化そのものです。だから、「先輩と同じ知識を持たなきゃいけない」「全部知らなきゃダメだ」というのは、今の時代には少し言い過ぎな気がしますね。

ーーでは、ブラックボックスのまま使っていても問題ないと？

基本的にはいいんですが、一つだけ落とし穴があります。それは「最新ツールを使っていても必ずトラブルが起きる」ということです。

平常時は良くても、何か問題が起きた時に、表面的な操作しか知らないと手も足も出なくなります。「なぜ動かないのか」「内部で何が起きているのか」を突き止めるためには、やっぱり中身の知識が必要になるんです。

ですから、最初から全てを網羅的に勉強する必要はありませんが、必要に応じてオンデマンドでインプットしていく必要はあるでしょうね。

トラブルが起きた時や、どうしても挙動を理解しなきゃいけない必要に迫られた時に、詳しく調べて勉強すればいい。「必要になったら学ぶ」という姿勢で十分だと思います。

「業務外も勉強すべき」という呪縛は捨ててもいい

ーーただ「必要になったら学ぶ」としても、変化の激しい業界です。「業務外でも勉強する人が勝つ」「休日もコードを書くのが本物のエンジニア」という風潮について、まつもとさんはどう思いますか？

私は「放っておいてもプログラミングします」みたいなタイプですけど、どちらが正しい・間違っているという話ではないと思っています。

「あくまでも仕事としてソフトウェア開発者をやっている」という姿勢も、何ら卑下されるものではありません。求められた仕事を、求められた時間の中できちんとこなせているのであれば、それは十分にプロフェッショナルだと思います。

業務時間外の取り組みをどう評価するかは会社次第ですが、そもそも時間内に完遂できない仕事を前提にしているのであれば、それは会社側の設計の問題でしょう。

私たちは会社と奴隷契約をしているわけではありません。自分の人生をすべて仕事に捧げる必要はありませんし、仕事との関わり方は自分で決めていいものだと思います。

ーーまつもとさんのようなタイプではなくても、エンジニアとして長くキャリアを描けるものでしょうか？

できると思います。ただ、工夫は必要でしょうね。

人は時間とともに、求められる役割が変わっていきます。ソフトウェア開発者としてキャリアを始めた人が、次第にマネジャーになったり、OSS開発をしていた人がプロダクトオーナーとしての役割を担うようになったりする。そういう変化は、ごく普通に起こります。

その変化に対応するためには、新しい立場に応じた学びが必要です。自分の役割が変わっているにもかかわらず、「もう学ばない」と決めてしまえば、環境の変化についていけなくなる可能性はありますね。

ただそのときに、「私はあくまでも仕事としてやっているので、仕事の時間内で学びます」と言うのであれば、それは何もおかしくありません。決して怠慢ではなく、筋が通ったプロフェッショナルのあり方とも言えます。

自分の人生を犠牲にする必要はありません。ですが、変化を拒絶せず、仕事の中で楽しみを見つけながら適応していくこと。そうやってしなやかに構えることが、この世界で生き残るための一番の戦略なんじゃないかと思います。

撮影／Kiiimon 岸本茂樹　取材・文／今中康達（編集部）