ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略

コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。

ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略

こんにちは。白山@fushiroyamaと申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。

自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。

そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか? 考えてみると、次の4つの戦略で生き延びてきたようです。

  1. 自分だけの居場所を見つける
  2. 必要な知識を効率的に取捨選択する
  3. 他のエンジニアに差をつける
  4. モチベーションを下げない工夫とマインドセット

この戦略が、これからプログラマになりたい方や若手プログラマのみなさんに、少しでも何かを示唆するものになれば幸いです。

戦略1. 自分だけの居場所を見つける

僕のエンジニアとしての原点は、京都の小さなスタートアップです。当時、大学で学ぶ意味を見失って無為に過ごしていた僕は、友人であり恩人である先輩に誘われ、大学を中退してアルバイトとして参加。その後すぐに社員となって5年間働きました。

2000年代前半のWebの世界はおおらかで牧歌的であり、Ajaxも存在せず、基本的にはすべてがサーバサイドレンダリング。「動的なWebシステム」といえば、Perlで書かれたCGIという時代でした。

もちろんその当時からきちんと設計されたWebシステムも存在していたのでしょうが、僕が目にするようなソースコードはMVCを意識したものではなく、ビジネスロジックとともにViewのHTMLタグが直接コントローラの中に記述されたものばかり。データの永続化は、ロックファイルで排他処理をしながらファイルに追記しているものがほとんどでした。時間計算量なんて考えたこともありません。嗚呼、古き良き時代。

僕も学生時代は、趣味で簡単な掲示板をPerlで書いて自分のWebサイトで公開していたこともあり、「プログラマとしてなんとかやっていけるだろう」とたかをくくっていたのです。

しかし、入社後、プロダクトのソースコードを見て驚愕。まったく読めません。

その会社はもともと、国立大学の研究チームを中心とした産学官共同プロジェクトに端を発しており、創業者や社員はみんな信じられないほど優秀な人ばかり。システムは、WindowsでもLinuxでも1ソースで動くGUIアプリケーションとして、Java Swingで記述されたものでした。

多数の優秀な大学生や企業のプログラマによって、各コンポーネントは適切な単位で膨大な量のクラスに分割され、プロセス間通信や最適化のためのネイティブコードも複雑に関係し、とても当時の自分の手に負える代物ではありません。僕は即座に悟りました。

「このままではクビになる。」

このとき考えた生存戦略は

「そうだ。誰もやらない仕事をやろう。そうすれば誰も僕をクビにできないだろう。」

というシンプルなものでした。社内を見回すと、アプリケーションプログラマは充実している反面、サーバの設置や管理・メンテナンスを担当するインフラエンジニアが致命的に不足していました。サーバ室に入ると、社長が経営の片手間に、ひとりでルータの設定をしています。

「インフラで何か手伝えることはありませんか?」

僕がそう聞くと、社長は喜んですぐに仕事をいくつも割り振ってくれました。これが、僕の技術者としての出発点です。

趣味があなたの力になる

インフラエンジニアとして働くようになってから僕が始めたのが、自宅サーバの構築です。クラウド全盛の現在ではもはや死語かもしれませんが、自宅サーバとは、その名の通り自宅のネットワークインフラでサーバを運用することです。

お古のノートPCを引っ張り出し、会社と同じディストリビューションのLinuxをインストールして、NAPTとDDNSを設定してインターネット上にWebサーバを公開できたときには感動しました。2006年ごろ、まだ「クラウド」という言葉も日本であまり馴染みがなく、仮想化という技術が流行する前夜です。

その頃は、趣味と実益を兼ねて自宅サーバを立てる人が一定数いました。自分も業務の足しになればと軽い気持ちで始めた自宅サーバでしたが、運用を通じて、信じられないほどの知識を上積みできました。

例えば、XenやKVMといった仮想化ハイパーバイザが流行の兆しを見せはじめたときには、いち早く自宅サーバで試し、グローバルIPアドレスを自宅に8本(29ビットマスク)引いてインスタンスに割り当て、プログラマ仲間に有料で貸し出したりしていました1

会社の役員にこれを話したところ非常に興味を持たれ、最終的に会社の業務に投入することになりました。単なる趣味で始めたものが、新たな価値に結実したのです。これは、どれだけ真面目に業務をこなしていても身につけられなかった知識です。

その後のエンジニア人生でも、趣味で始めたものが大きな力となり、他者との違いを生むという経験が幾度となくありました。みなさんも、何か始めてみてはいかがでしょう?

戦略2. 必要な知識を効率的に取捨選択する

晴れてインフラエンジニアとしての居場所を得たころの話に戻ります。当時は、実のところネットワークやサーバ管理の知識が皆無でした。学校でもプライベートでも、サーバ管理やインフラ構築をした経験がなかったのです。

ネットワークに詳しくなるべく「OSI参照モデル」について調べてみるもまったくピンとこないし、サーバに使われているLinuxのディストリビューションが何なのかすらよくわかりません。

このような状況で「とりあえず前に進む」ために参考にしたのが、パラシュート勉強法です。

パラシュート勉強法とは

パラシュート勉強法とは、経済学者の野口悠紀雄氏が著書『「超」勉強法』で紹介した、「必要になったものを必要なだけ学ぶ」という学習の手法です。

例えば数学のように、ある単元がその前の単元の知識を前提とする積み上げ型の教科を学習する場合、「今の単元がわからないので『数I・A』からやり直そう!」と考えがちです。しかし、十中八九、わずかに進めるだけで、目的に到達する前に力尽きてしまいます。

そうではなく、バラシュートでまっすぐに目的地に降りるように目標を定め、目的地に至るまで、必要な最低限の知識だけを補いながら進んでいくのがこの勉強法です。

僕の場合、まず会社の業務として必要とされるインフラの知識を書き出しました。

  1. サーバに特定のLinuxディストリビューションをインストールし、ファイアウォールなどのセキュリティ設定をする
  2. アプリケーションを実行するためのミドルウェアをインストールし、デプロイ環境を整える
  3. 必要なサーバには会社で所有するグローバルIPアドレスを割り当て、インターネットから直接到達する必要のないホストはローカルネットワークに閉じ込める

すると、覚えなければならないことは実のところ以下の3項目に集約されることがわかりました。

  1. OSは、業務で使うディストリビューションの使い方、セットアップ方法に絞って学習する
  2. コマンドも、業務に必要な最低限のものだけを覚える(必要になったらその都度学習する)
  3. ネットワークに関しては、LANとそのルーティングの知識を必要とする程度だったので、L3スイッチを設定できる最低限のルーティング知識に絞って学習する

この項目に従ってできるだけ寄り道をせず、ゴールに向かって進んでいくよう心がけました。

重要なのは「実際にLinuxを触る前からコマンド一覧をひたすら眺める」とか、「単純なルーティングも設定したことがないのに『マスタリングTCP/IP』を読みはじめる」 というようなことを一切しないことです。

必要なピースを拾い集めながら、知識のマスを少しずつ埋めていきます。上記でカッコ書きしたようなことは、勉強の初期段階よりも、学習が進んでから全体の横串を通すときに行ったほうが効果的です。

Webエンジニアに転身してもパラシュート的に学習

インフラエンジニアとしての業務が順調に進むようになると、空き時間でWeb開発をするようになりました。

このときもパラシュート勉強法は大いに役に立ちました。Webエンジニアとしては、次の2点のみに絞って学習しています。

  1. HTTPの基本原理
  2. 業務で必要な技術スタックとその周辺知識

HTTPはWebの根幹技術であるため、1.に関しては言うまでもありません。2017年現在においても、Webアプリケーションは当然のこと、iOS/Androidなどのネイティブアプリケーションでも、サーバとの通信の主たるプロトコルはHTTPという状況が続いています。

  • ステートレスなプロトコルであるHTTPがどのような方法でユーザを特定したり、一連のトランザクションを実現するのか
  • ヘッダとは何で、どのようなものか
  • リクエストとレスポンスはどのような形式をしているのか

Webエンジニアである以上、こういった知識は必須です。

2.に関しては、かなり割り切って学習しました。

この世には、Webアプリケーションに利用できるプログラミング言語は数多く存在し、そのアプリケーションフレームワークや、バックエンドで利用するRDBMSもいくつも存在します。これらすべてを覚えようとするのは意味がないので、会社やプロジェクトで利用するものだけに集中しました。

幸い、Web技術には見た目や思想や新旧の違いこそあれ、その根底にある目的は、言ってみれば「HTTPリクエストを効率よく返すこと」で共通しています。

Webアプリケーションフレームワークのスタックを何かひとつ理解していれば、どんなWebサーバやアプリケーションフレームワーク、キャッシュサーバ、DBサーバを使おうと、大きな違いはありません。

新しい知識には遅延評価的勉強法で対応する

ここ数年のWeb技術の発展と、関連する技術スタックの隆盛は目覚ましく、毎年覚えきれないほどの新しい言語・概念・フレームワーク・ライブラリが誕生し、目も回らんばかりです。

その渦中にあって投資すべきものを見定めるのは困難を極めますが、我々の限られた時間を効率的に使うためにも、それを見抜く目を是非とも養いたいものです。

自分はその目を持っているわけではないのですが、知識を取捨選択する際にある程度有効に機能している「遅延評価的勉強法」を紹介したいと思います。

遅延評価的勉強法とは、天野仁史@amachangさんや小飼弾@dankogaiさんがブログで言及していた学習方法です。

パラシュート勉強法と共通していますが、自分の理解では次の2つがポイントです。

  • 必要になるまでやらないこと
  • 必要になったらやりきること

例えば、新しい本を開いて何かを学ぼうとするときに、前から順番に最後のページまで読んでいくのはなかなか骨が折れますし、つまらない! 僕の場合は全体を見渡しながら、欲しい情報をかいつまんで

  1. 即座に利用するにはどこを読めばいいか
  2. 面白そうな部分はどこか

を探し、美味しいところからつまみ食いしていくスタイルを採っています。

薄くでも全体的に概念を知っておきたい場合は、まったく知らない状態で本なりまとめサイトなりをサラッと眺めて「バズワードとして意味や用途、利点をふわっと理解している」ぐらいに留めておき、必要になるまではその状態でやり過ごします。

この勉強法で重要なのは、いざ必要になったときには、全力で取り組むことです。全力で取り組む対象としては、次のようなものが挙げられます。

  • デファクトスタンダードになった技術
  • 会社のプロジェクトとして正式に採用されることになった技術やフレームワーク

このとき僕が気を付けていることが、dankogaiさんのエントリにもあるように、原典にあたることです。僕は必ず、英語であっても公式サイトで最新の一次情報を参照するよう心がけています。

本屋で立ち読みしたりQiitaや技術ブログで見かけたりした情報は、公開された瞬間から時々刻々と鮮度が落ちていきます。楽をするつもりでまとめサイトを参照したのに、情報が古くなっていてビルドすら通らず、かえって時間を無駄にした経験をお持ちの方もいらっしゃるのではないでしょうか?

こういった二次的な情報源は、短時間でまとまった情報が得られる点で大いに価値がありますが、それは前述の「ふわっとした理解」の助け程度に留めておき、いざ全力で取り組む際には公式サイトを参照することが、遠回りに見えてかえって近道であることがよくあります。

参考記事:ハッカーと遅延評価勉強法 - Slow Dance9

真似て、盗む

もうひとつ、僕がプログラマとして成長する上で必要だったのが、人のコードをひたすら模倣して、テクニックを盗んでいくことです。

スティーブ・ジョブズはインタビューで、パブロ・ピカソの言葉を引用しています。

ピカソは言った「すぐれた芸術家は真似る、偉大な芸術家は盗む」。私たちはいつも偉大なアイデアを臆面もなく盗んできた。
(Picasso ... said good artists copy great artists steal. And we have always been shameless about stealing great ideas ...)

(1996年の番組「ナードの勝利(Triumph of the Nerds)」での発言、日本語訳はWikiquote

どんな巨匠も、いきなり自分だけのスタイルを確立したわけではなく、最初は他人の絵を真似して、描いて描いて描きまくったはずです。

プログラミングも同じです。僕も、初めて見る言語やパラダイムに触れたときは、とりあえず手を動かして、写経してみます。何回も書いて書いて書きまくっているうちに、手法やデザインパターンを吸収し、その場に応じて適切な形に書き換えるといった応用ができるようになります。

戦略3. 他のエンジニアに差をつける

ここまでは僕のエンジニア人生を振り返りながら、自分なりの生存戦略を紹介してきました。個人的には、必要なことを必要な場面で最低限こなしていれば、エンジニアとして生き残ることに何の不安も感じていません。

ここで言う「必要なことを最低限」とは、プログラマならば

  1. 意味のある単位でクラス、関数やメソッドの責務を分け、そのユニットテストを書く
  2. 自分の利用する技術スタックの最低限の知識をきちんと把握する

という程度のことです。総じて、技術に対して真摯でありさえすれば、おのずと達成できるようなことです。

それでは、プログラマとはそれだけの存在なのでしょうか。ただ漫然と、与えられたチケットを消化していればいいのでしょうか。

いいえ。僕の信じる限り、プログラマとは、いまこの世にない価値を生み出せる存在であるはずです。

ここからは、いまここにない価値を届けられるプログラマになるために、僕が必要だと考えていることを紹介します。ちょっとエモい内容になりますが、どうぞお付き合いください。

この便利なライブラリは誰が作ったのか

先ほども触れましたが、現在のWeb業界でプログラマとして禄を食み続けること自体は、さほど難しくないかもしれません。

例えば、ディレクターから「ボタンを押したら図形が大きさを変えながら回転するアニメーション」の開発を頼まれたとします。

実装方法がすぐに思いつかなくても、機能の概要をキーワードに、言語やフレームワークとあわせて検索すれば、たちまち目的を達成できそうなライブラリがいくつか見つかるでしょう。あとはこれを組み合わせるだけ。簡単!

では、このライブラリは誰が作ったのでしょう? 言うまでもなく、自分以外のどこかのプログラマが作ったのです。もしこのライブラリが存在しなければ、今回のタスクを完遂できたでしょうか……?

依頼されたアニメーションを実行するには、平面上の図形の回転座標を求めるために行列の計算や三角関数の知識が必要です。また、GUIアプリケーションの低レイヤな描画の仕組みへの理解が不可欠です。

これは一例にすぎませんが、Web、ひいてはITの世界で、いまここにない価値を生み出したければ、数学やコンピュータサイエンスに対する理解が必要不可欠なのです。

コンピュータサイエンスの基礎、アルゴリズム、データ構造を知る

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く