エンジニアの不安と壁

このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。

よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。

振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。

• きれいなコードを書くにはどうしたらいいんだろう?
• 負荷分散って、どうやるんだろう?
• 溜め込んだデータをうまく活用するには、どうしたらいいんだろう?

などなど。

「きれいなコードを書くにはどうしたらいいんだろう」。プログラマになって誰もが一度は経験する壁なのかな、と思います。社会人一年目くらいに「そもそも綺麗なコードってどんなコードなんだ」というところに始まり、四苦八苦したのでした。覚えたてのオブジェクト指向で「おれおれオブジェクト指向」を遺憾なく発揮し、周囲に迷惑をかけた、なんて黒歴史もきっちりと刻んできました。

自分がまあまあ綺麗にコードを書けるようになったな、と思えるようになったのは、結構時間が経ってからでした。そうですね、はてなに入ってしばらく経った頃だから、社会人プログラマ経験的には4年くらいが過ぎた頃だったと思います。何が設計のセオリーか、どういうコードが見本なのかというのは、断片的にあちこちから得た知識/コードからなんとなくは分かっていたのですが。それらの点と点が繋がって線になった、と感じたのは、結城浩さんのデザインパターンの本を久しぶりに読んだときでした。

あの本を読んで、同じような感想を持った人がどれくらいいらっしゃるかは正直なところわからないのですが、自分は繰り返し繰り返し読むうちに、パターンの根底に通じるプログラミング設計の概念がおぼろげながら分かるようになったと感じました。ひとことで言うなら「インタフェースでプログラミングする」ということなんですが、その概念が中心軸になって、それまでに持っていた自分の知識が徐々に体系化されていったのを良く覚えています。

負荷分散。これはなかなか大きな壁でした。自社のシステムがサービス規模の拡大に追いつかず、また日々の対応がどうしても対症療法の繰り替えしに留まってしまう。正直、途方に暮れていた時期もありました。そんなとき、息抜きだったかどうか、もう忘れてしまったのですがたまたま手にとったのが、オライリーの Linux カーネルの本でした。その本には、今考えると当然なんですが、OS が動作する仕組みが解説されていました。プロセスとは何で、スレッドとはどう違っていて、仮想メモリはどういう働きをしていて、OS はどのようにデータをキャッシュするか。そんなことが書かれていました。

サービスの負荷分散を実行するのに OS の動作原理を知る必要がある。その紐付けに気付いたのは、それからすぐでした。OS は有限なリソースを効率的に利用するためにこれこれこういう動きをしている。逆に、こういう動きはしていない。それがわかれば、システム全体の系を、その OS の効率性を阻害しないように組み立ててやればよい。これが答えでした。一時期、このブログに Linux カーネルの話しをたくさん書いていたこともありましたね。

OSの動作原理を知るためには、カーネルの本を読むだけでなく、CPU の本や、時にはアセンブラの本を読む必要もありました。目的がはっきりしていましたから、その「負荷分散のためのOSの動作原理」という考え方が軸になって、それぞれの知識が自分の中で体系化されていきました。知識と知識を紐づけて構造化する。それが結果として、力になるんですね。すなわち、知識の体系化とは自分の脳内を編集することと思います。

データの活用。これはコンピュータサイエンスの分野にそのヒントがありました。情報検索やデータ圧縮、パターン認識や機械学習。それらの基礎を学ぶことで徐々に現実的な応用の道筋を立てられるようになりました。ここで苦手だった数学をいちからやり直す必要があって、腰をあげるのが大変だったのですが、数学は数学で面白いもので、高校・大学の授業はあんなに退屈だったのに、「あのアルゴリズムを理解するため」という目標がはっきりしてくると、その学習が面白く感じられるのでした。

数式を解くのが目的ではなく、なぜなに、を知るのが目的になったので、そもそも数学ってどういう学問なの? というところまで遡った入門書なんかも読んで、あー、学生の頃にこんな風に数学を教えてくれる人がいたらよかったのに、なんて感じたりもしたのでした。未だ現役の学生さんには全く叶わない程度の知識で留まっていますが、根本的なところからやりなおして徐々に積み上げていった結果、その分野を壁と感じることは、もうなくなりました。

こうして、一つ一つ壁を乗り越えるたび、自分の中で体系化された知識が構築されていったように思うのですが、こういう知識は時間が経っても陳腐化しないし幅広い場面で応用が効くんですね。それはエンジニアとしての大きな自信につながりました。

ずっと抱いていたエンジニアとしての不安 ― 自分はプログラマとして自分の技術を誇れる日が来るだろうか? という気持ち。 Web API を操作してああしてこうやればこんなアプリケーションが作れる。このデータとこのデータをあのライブラリに放り込めばこんな風に綺麗なグラフが描ける。そういう知識を次々と溜め込んでいけば、いつか不安は解消されるんじゃないか。そう思っていた時期もありました。でもそれを続けても、不安は解消されないばかりかなぜか益々大きくなっていくばかりでした。そんな不安を払拭するのに必要だったのが、ここまで述べたような道のりだったように感じます。

長く自分語りしすぎました。昔話はこの辺にしておきましょう。

さてさて、未だによくわかっていない大きな壁が

「ヒットサービスを作るにはどうしたらいいんだろう?」

ということですか。うーん、これはさすがに体系化していくのにはだいぶ苦労しそうですが･･･これからもいちサービス開発者として、その追求を忘れないよう気持ちを新たにがんばっていくとしましょう。