オジサンになってもずっと勉強が必要だよね、外的要因を加味したキャリア形成が必要だよね、とかそんな話です。

もっと優れたソリューションが登場する

この数年は特に、「今まで技術者がやってきたノウハウ」が不要になるソリューションが多かった感じます。

具体的に挙げると、

  • サーバ運用の経験が、AWS のマネージドサービスで不要になる
  • 負荷分散のノウハウが、Spanner で代替可能になる

などです。

以前取り上げた GS2 もその一つですね。

話題のサーバエンジン GS2 をはじめてみた
ゲームサーバエンジンのサービス、GS2で公開されているサンプルをやってみました。
atuweb 開発ブログ

このように IT エンジニアを取り巻く環境は進歩が早く、「今の技術トレンド」が、数年のうちに過ぎ去っていくという大きな流れのうねりを実感したことが、私にも何度かあります。

その度に「 実務経験を積み上げて多くのノウハウを獲得したとしても、それがいつまでも通用するということは、まあないよね 」そして「 やっぱり定期的な勉強は欠かせないよね 」ということを再確認するわけです。

そして、大規模化や AI 技術の普及により、これからの変化はより振れ幅が大きくなるのではないか、という気がしています。
単に理解力、適用力が落ちているだけかもしれませんけどね。

シャーディングが負債になる

優れたソリューションによって、それまで強みであった技術、ノウハウが不要になる という例として「シャーディング」を例に挙げます。

シャーディングとは、全体の応答速度を向上させることを目的として行われるもので、データを複数のパーティションにわけて格納することで、データベースへのリクエストを分散させることがねらいです。


かつてソーシャルゲームが台頭した頃は、大量のアクセスを捌くため、さまざまな対策を施してきましたが、「シャーディング」もその一つです。

シャーディングに対応するにあたっては、

  • 複数パーティションにアクセスする処理
  • 「どのようなルールでデータを分散するか」というロジック
  • 複数パーティションをまたいだデータを結合する処理

などを行います。

「シンプルでわかりやすいコード」が良いことに疑いの余地はありませんが、素直なコードは読み手に優しい反面、パフォーマンスに課題が残ってしまいます。

最初は問題なく動いていたプログラムも、負荷が一定を超えると急激に劣化して、想定外の不具合が多発します。
これは、当時ソーシャルゲームに関わっていた多くの方が経験したことですね。

この圧倒的多数の負荷を捌くために、シャーディングなどを施し、改修を重ねていくと、シンプルなコードは維持できず、コードベースの複雑化を招いてしまうものです。

一方では、ある程度のアクセスが見込まれるプロジェクトには、シャーディングなどの負荷分散の仕組みを最初から組み込むことをしてきました。
これはユーザのデータが入ったあとで組み込むこと画に大きなコストがかかる、ということもあります。

当時から動いているゲームなどは、そのほとんどが現在も「シャーディング」が組み込まている状態だと思います。

また、このような負荷分散のノウハウやパフォーマンスチューニングができることは、当時から大きな強みとなっていました。


ところが、優れたソリューションの登場によってこの状況が変わりました。

そもそもとして負荷に耐えられるのならば、シャーディングのような複雑なことを、コストをかけて行う必要はまったくないのですね。

そして、「シンプルでわかりやすいコード」で十分な性能を見込めるようになったことで、面倒で複雑な実装は不要となり、実装工数を抑えられれますし、保守も楽になります。
いいことばかりです。

逆に、シャーディングのよう複雑なコードが負債となってプロジェクトに残り続けてしまうことがデメリットになってしまいます。

スタックが変わる

新しいソリューションの登場で、一夜にして仕事がなくなる、ということはないかもしれませんが、このような大きな外的要因の変化は、もちろん無視できません。

「プログラミングは前提を積み上げる (スタックする) 作業」という面があります。

インフラやミドルウェアも当然これに含まれますが、そのスタックが新しいソリューションに置き換わることでそれまでのノウハウが使えなくなり、また新しく知見を積み上げていく必要が生じます。

これは、 新規参入者とスタートラインが同じになってしまう ことを意味します。

ところが、スタートラインは同じでも、「それまでの常識」を下手に持っていることで、新しい仕組みの理解を阻害してしまうこともあり、逆に出遅れてしまうということもありえますよね。

「使えること」と「技術を理解すること」の大きな差

それまでのノウハウも、決して無駄になることはありませんが、必要になる母数は減ってしまうのではないかと考えています。

たとえば USB や Bluetooth は、これは 「本当は複雑なことが、とてもかんたんにできる」ソリューション ですよね。
私もこの恩恵に預かっているわけですが、専門外ですし仕組みは全く理解していません。

そして、「仕組みを理解していなくても便利に使える」ソリューションの前では、「仕組みを考える」ことすら、一般の人から見たら野暮、みたいなことにもなり得ると感じます。


このように、

  • 仕組みを使うだけの人
  • 仕組みを使って組み立てができる人
  • 仕組みそのものを構築できる人

は、次第に差が大きくなり、分断すら生むのではないかと考えます。

重宝されるのはもちろん「 仕組みそのものを構築できる人 」であり、そこを目指すことが技術者としての 1 つの目標になりそうです。

けれども、そこにたどり着くこと自体が非常に困難であり、さらにはたどり着いたとしても、実際仕事になるかどうかも別の話になってくるという、時代にゆっくり変わっていくのではないかと考えます。

ちょっと飛躍しましたね。

若者の声に耳を傾けることができる、オッサン

技術者としての寿命を伸ばしていくために、今後何をやっていけばよいか。

1 つは「しぼみやすい興味の範囲」を広げ、積極的に新しい技術をキャッチアップしていくこと。

1 つは「最新の技術を勉強している若い技術者さん」の言うことも、一理あるよねと受け止めること。
または「オッサンでも、自分がチームで一番下手」という意識で周囲から学ぶ姿勢を持ち続けること。

[情熱プログラマ]「チームで一番の下手くそ」でいる勇気
書籍「情熱プログラマ」には「一番の下手くそでいよう」というお話があります。下手はネイティブワードですが、なぜ下手でいることが良いのでしょうか。勇気を出して私が実際にそのような立場に飛び込んだことから感じたことを述べます。
atuweb 開発ブログ

最後に、長くパフォーマンスを発揮できるように、生活を整え、心身を整えていくこと。

疲労をマネジメントして集中力を高めよう
「集中力」はプログラマが良いプロダクトを作りあげる上で重要となる要素の一つです。集中力を維持するために生活習慣を改善して「疲れすぎない」ようマネジメントすることが効果的です。全ては良いコードのために。
atuweb 開発ブログ

そんなことを、新年を迎えて考えていました。