カフェでぼーっとしてた時、ふと、自分が今年35歳になるにあたり、
最近エンジニア30歳限界説的な話を聞かなくなったなーと思い、
世の中の風潮はどうなっているんだろうと、ちょっとネットで簡単にググってみた。
そうすると、もうあんまり限界を唱える説の考察記事は出てこなかった。
どうやら、昔はIT界隈の労働環境がブラック過ぎて、「体力的な限界の意味で」30歳や35歳定年説があったのではないか、的な考察がされており、
確かになーと思った。
実際、筆者も35歳になるが、業務委託として外部でバリバリコードを書いているし、
筆者が歳を取っているという事は、周りも同様に歳をとっているわけで、
友人や先輩や上司達は、管理職になったりして現場作業している人もいなくなってはいるが、
現場でバリバリコードを書き続けている人も居るので、
体感的にも事実的にも、年齢的なハンディキャップで、エンジニアの業務ができなくなると言ったことは無さそうである。
では、当時35歳定年説を感じていた10年前の25歳の時の筆者と、今の筆者は、
プログラミングする際にどんな思考の違いがあるのか、ちょっと振り返ってみた。
予め言っておくと、記憶とは曖昧な物であるし、記憶とは都合よく書き換えられる一面があるらしいので、
全てが正確とは限らないので、その点は予めご了承いただきたい。
〇25歳の時の筆者とは
確か、某ハートフルMMOで、メインフロントエンジニアの先輩から引継ぎをして、
バリバリ機能アップデートのコーディングをしていた時期だった気がする。
じゃあ、35歳の筆者先輩が、25歳の筆者後輩を見て、どのような評価を下すかというと、
簡単に言えば、経験不足・知識不足だなーと感じる。
以下、その理由を記載する。
〇フレームワークの設計意図を汲み取れない・推測できない・疑問に思えない
35歳先輩は、現在ある開発現場のフロントエンジニアとして、量産部分のコーディングを任されているわけだが、
そこで使用している、プロパー先輩が作ったフレームワークの上で作業を行っている。
勿論、使うだけなら誰でも出来るわけだが、そのフレームワークが、どういった思想で、どういう使われ方を望まれているのか、見れば大体理解できるようになっている。
これに対し25歳後輩は、当時の上司や先輩が作ったフレームワークや実装物を、保守しながら追加実装を行っているわけだが、
当時、そのフレームワークがどういった思想で、どういう使われ方を望まれているのかなど、全く理解できていなかった。
前述した「使うだけなら誰でもできる」状態で、ただ使っていただけであった。
では、なぜ当時の25歳後輩が出来なかったというと、単純に知識量・現場経験量の差だと思っている。
例えば、ある実装に対して、デザインパターンの知識が有れば、問題と解決の理由が見えてくるが、知識が無いと、問題を問題と認識するのも、解決方法の妥当性も判断が難しい(知識)
また、ある実装に対して、既に先人が解決していた場合、その問題点と解決に至るまでのフローが抜け落ちるので、
類似の問題に直面した時に、自分自身でトラブルシューティングが出来ない状態になってしまう(経験)
〇実装物の「テスト」に対する取り組み方・考え方の違い
35歳先輩は、実装した物に対して、「こういったテストをして、こういう結果になりました」と、
デバッグの一環で、自分でテストケースを作ってテストを行い、マージリクエスト（プルリクエスト）に張り付けている。
これは、後でバグが発生した時に、
「そもそもテストしてない項目なのか」「テストしてたけど、テストケースが間違っていたのか」「テストもテストケースもあってて、自分の作業外の影響なのか」
など、問題の棲み分けをスムーズに行えるようにする為である。
少なくても、35歳先輩が仕様書に記載されている事に対しての理解で、その時点では問題が出ていない事を証明する事を目的として行っており、
製品の正確性を担保する為の目的では、テストを行っていない。
テストの目的も、自分で定義出来ている状態である。
これに対し25歳後輩は、そもそも「テスト」なんて物は概念として存在しておらず、
適当に流れ動作チェックをしてみて、問題が有るか無いかだけを確認しており、
正常パターンしか確認していない状態であった。
これも、単純に知識の差であり、現場経験によって「テスト」という概念が掘り起こされた結果、
35歳になって、ようやくテストをうまく行うにはどうすればいいのかと考えられるようになったのである。
〇自動化・体系化・効率化の概念・手法に対する、理解・発想の違い
35歳先輩は、繰り返し行われる手作業については、どうにか自動化出来ないか、という発想に至る。
例えば、毎日定時に行われるZoom会議については、スケジューラツールを入れて、Zoomを起動するコマンドを用意し、
定時に実行されるように組み込んだりする。
また、同じようなコードを生成する必要がある場合は、コードジェネレータ生成を検討する。
コードジェネレータ生成方法についても、Unity+C#だけでなく、Python等の別の言語を検討する。
これに対して25歳後輩は、そもそも手作業で繰り返し作業を行う事について、問題だと認識すら出来ていない状況であった。
MMO開発だったので、インストーラをパッケージする作業があるが、それをどうにかコマンドで出来ないかとかいう発想は無いし、
アップデートの作業も、コマンドでまとめて出来ないかとか、そういった体系化を行うという発想がなかった。
当然、発想が無いので行動も起こせない。
これができるようになったのは、20台後半の時、サーバーとフロントの通信プロトコルの定義ファイルを、
メタデータからサーバー・フロントの両方のソースファイルをジェネレートする先輩を見たり、
Python言語を使って、大量のファイルのテキスト置換という、手作業では煩わしい繰り返し作業を、
1コマンドで実践した同僚を見て、初めて解決できる問題なのだ、という理解に至ったからだと思われる。
これについては、どうやったらできるようになるか、というのは結構難しい。
なぜなら、問題を問題と認識するには、自分だけの力ではどうにも難しいからだ。
また、他人に対して、自分以外の他人の考えも検討に値するのだ、という
謙虚な姿勢、みたいな物の捉え方が出来ないと、いくら外部に知識を求めに行ったとしても、気づきにくい。
筆者の場合、先輩も同僚も尊敬に値し、実際に直面していた問題を解決してくれたため、この出来事は一考に値すると、素直に受け入れられたのだと思う。
つまるところ、運が良かった。
〇作業を行うにあたり、必要になるタスクの理解の差
例えば、Unityでオンラインソーシャルゲームを作ろうと思った場合、
35歳先輩は、必要になるであろうタスクや機能の全容が何となく理解できる。
なぜなら、1から作り始めて、リリースまでこぎつけた事があるからだ。
・フロント側で必要になる機能のリスト（シーン制御、リソース制御、アセットバンドル、デバッグモード、通信機構、マスターデータ機構、各種コントロール実装、命名規則などなど）
なので、現場に投入されたばかりでも、説明されていない機能については、
自分で作るのではなく、どこかで用意されているはずだから、聞いてしまった方が早い、みたいな感じで、
作業をスムーズに行えるようになる。
これに対して25歳後輩は、1からフレームワークを作った事が無い為、
必要になる基本機能の不足分について、実装を始めてから気づく事が多々出てきてしまい、苦労をするのである（実話）
これについては、自分の個人開発などで、1からフレームワークを作ってみる以外に実感する方法はないだろう。
CSVファイルを読み取ってデータクラスに埋め込む作業一つとっても、
スプリットや改行文字列の扱いで頭を悩ませるはずである。
また、会社で既に用意されているフレームワークについて、それが完全な物と思わず、
自分ならこうするだろうなーと、問題点や改善点を指摘できるようなる事を意識すると良いと思う。
〇この振り返りから推測する、10年後の自分の姿
きっと、45歳の筆者が35歳に筆者を見ても、経験不足・知識不足という評価を下すのだろうなと感じている。
では、具体的にどういった部分の指摘が入るのかを推測してみる。
〇新しい概念に積極的に触れに行っていない結果、それがトレンドになった際に出遅れる
これは、実際にMVPモデルの理解を、出向先の現場で理解した事から、恐らく同様な事が発生すると見込まれる。
MVPモデルの存在自体は5年前から知っていたが、それがどう有用なのかをちゃんと理解しようとしなかった為、理解に5年かかってしまった。
また、これは自覚があるのだが、CEDEC等の勉強会への参加、情報へ触れると言ったことが、ほぼ全くと言っていい程無くなってしまっている。
恐らく、これが10年後の自分にハンディキャップとして現れるのだろうなと感じている。
具体的には、AI、ブロックチェーン、3D、大規模開発の処理負荷軽減辺りが、
触れていないかつ、今後トレンドになりそうな気がしている。
〇デザインパターン等の座学的な理解の乏しさが足を引っ張る
仕事を行う上では、実は言語の知識とかツールの使い方とかの理解は、あんまり重要ではない。
なぜなら、必要になった時に調べれば良く、調べられるという事は、もっと抽象的な、必要となる概念の理解があるからだ。
例えば、ゲームとは、「入力・更新・出力の繰り返しである」という概念の理解があれば、初めて触れる言語であっても、
・ボタンやタップ入力等、ユーザー入力を受け付ける機構はあるだろうから、方法を調べる
・毎フレーム呼び出される処理を書くところがあるだろうから、方法を調べる
・画像表示、文字表示等、出力の方法を調べる
と言った理解になり、それは必要になった時に調べれば済む問題だ。
この発想に当てはめられる抽象的な概念が、まだ筆者が見えてこない領域に存在しており、
そして、それらは、本来であれば大学などで、ソフトウェア工学としてきちんと理解しておくべき内容の知識があれば、簡単に見えてくるものな気がしており、
そこがハンディキャップになるような気がしている。
〇コーディングをツールに任せるという概念
あまり詳しくないが、ただでさえ、ビジュアルスクリプティング等、コーディングをしなくてもゲームが作れるような環境が増えてきており、IDEはもっと高性能になっていくであろう。
恐らくだが、適当にコードを書いても、IDE側がよしなに、かつ、適切な校正を入れてくれるようになるのも時間の問題だと思うし、
何なら筆者が知らないだけで、すでに実現されているとすら思っている。
このような状況で、コーディングを効率良く行う為に「技術を高める」、と言った概念はもう古くなっていき、
コーディングを効率よく行うために「いかにIDEを効率よく使うか、選定するか」、といった概念にとってかわられるのではないかと感じている。
もちろん、エディターを扱う能力は、コーディング以外にも流用が効くので、無駄になる事ではないと思っているが、
IDE界隈の情報ももう少し目を向けて行った方がいいのだろう。
