はじめに
この記事では新人ITエンジニアがどのように技術を学習していくと良いかを 大雑把に 紹介します。
この手の記事は細かく書こうと思うと、無限に細かく書けるので、あくまでも大雑把な方針とか気をつけるべき落とし穴的なやつをざっくりと書いていきます。「具体的で細かいやつが欲しいよ」って人は他の記事を参考にしてください。
免責事項:
- 本記事は「技術」というスコープに絞ってまとめています。ITエンジニアにとって習得すべき重要な知識や技能は技術以外にもあることにご注意ください。
- あくまでも私個人の主観です。ここに書いてあることがご自身には当てはまらない、と感じたら別の指針を探しましょう。
想定読者
次のような読者を想定しています。
- IT業界の新人
- 業界に入ってから、あるいは入る直前からITを学び始めた
- 技術系のキャリアを目指している
技術習得のコツ
タッチタイプを習得しよう
他と比べてかなり具体的な項目なのですが、重要なので最初に挙げます。
タッチタイプとはキーボードを目視せずにキーボード入力する技能のことです。ITエンジニアはその業務全体の中でキーボード作業を必要とする業務がかなり多い職業です。つまりタッチタイプできるかどうかはそのITエンジニアの業務効率にそれなりの影響があります。
タッチタイプ習得の効果としてタイピングの精度とスピードの向上が挙げられることが多いです。確かにタッチタイプ習得によってこれらの能力が向上することは多いですが、これらはあくまでも副次的な効果です。タッチタイプを身につけることによる真の恩恵は「タイピングを無意識下の身体操作に追いやることで、脳のリソースをもっと本質的な作業により多く割り当てられる」ということです。ですからタッチタイプは必ず身につけましょう。
タッチタイプを身につける方法
タッチタイプを身につけるにはどうしたら良いでしょうか。
タッチタイプは知識というよりも「自転車に乗る」とか「楽器を弾く」のように、頭で理解するよりも体で覚えるタイプの技能です。体で覚えるタイプの技能を身につける上で重要なポイントは次のとおりです
- 体が覚えるまで多少時間はかかることを理解する
- 頭で理解しても、すぐに再現できるようなものではありません
- シンプルで簡単なことから始めて、少しずつ複雑な練習に変えていく
- 新しい課題が難しかったら、ひとつ前の課題に戻る
- 毎日少しづつ続ける（1週間に一度2時間練習するよりも、毎日10分練習するほうが効果があります）
- 練習中はアレコレ考えず、淡々と指示通りに課題をこなす
これらのポイントを踏まえた上で、タッチタイプ習得には プレイグラム タイピング のようなタイピング学習サイトでの練習をおすすめします。
もしこれまでにタッチタイプを身につけようとして挫折していたとしても、それほど悲観的になることはありません。タイピング学習サイトはタッチタイプを簡単に身につけるために設計されており、例えば次のような特徴があります:
- ホームポジションでの手の置き方や、どのキーをどの指で打つべきか、といった基本を丁寧に教えてくれる
- 「間違った場合でもキーボードを見ない」などの練習する上で重要なコツを教えてくれる
- 上記のプレイグラムタイピングはさらに進んでいて、練習画面にキーボードと手を表示してくれるので、「キーボードを見よう」という気持ちになりにくい設計になっています
- 特定のキーを集中して練習できる
- 新しいキーを少しずつ学べる
- カリキュラムの難易度勾配が緩やか
練習の場としてタイピング能力計測サイトを想像する人も多いかと思いますが、タイピング能力計測サイトはタッチタイプを簡単に身につけられるように設計されているわけではありません。タイピング能力計測サイトでのユーザが実施できることと言えば基本的に以下のようなことだけです:
- 難易度の選択
- タイピング課題の実施
- 結果の確認
タイピング学習にタイピング能力計測サイトを利用しようするのは自転車の乗り方を覚えるために自転車レースに出場するようなもので、身につけられる人がいないとは言いませんが万人向けではありません。タイピング能力計測サイトはタイピング能力の計測に使いましょう。
メンターを探そう
初心者のうちは見当違いな悩み方をしたり、無駄な努力をしてしまうことが多いものです。自分の力で走り続けられるようになるまでは、詳しい人に頼るのが短期間での効率的な成長につながります。
メンターの見つけ方
業務であればあなたの育成やオンボーディングを担当している先輩社員がメンターになってくれる / メンターを探してくれるはずです。
業務でない場合「こちらから気軽に口頭で質問でき、向こうも答えてくれる」あなたとそのような関係を築けているの人たちの中にITの専門家がいるのであれば、その人に教えてもらうのが良いでしょう。
適切なメンターを見つけることは、ITに限らずあなたがこれまで全く経験していない新しいジャンルのサムシングに挑戦するときにも役立ちます。
なお、環境やツールなどの選択はメンターが得意なものに合わせると効率的です。
例えば「プログラミング全然やったことなくて、まずPython勉強したいけど会社のメンターがRuby使いなんだよな〜」という場合、まずはRubyを勉強しましょう。あなたが全くの初心者の場合Rubyを勉強してからPythonを勉強してもさほど遠回りにはなりませんし、複数のプログラミング言語を経験しておくことは非常に重要です。
他にも「Vimを操れるようになりたいんだけどメンターはVSCode派なんだよな〜」みたいな場合も、まずはVSCodeをメンターと同様に操れるようになりましょう。エディタの操作を通して学べる熟練者の考え方やコツなどは将来Vimを操作するときにもきっと役に立ちます。
もちろん「メンターが愛用しているものと同じものを必ず選ばなければならない」なんてことはありません。普段VSCodeを使っているメンターが実はVimの操作にも詳しい、ということはよくありますから、まずはメンターに相談しましょう。
5分悩んだらメンターに聞こう
初心者のうちは「何がわからないのかわからない」みたいな状態になることが少なくありません。また、明後日の方向に努力してしまって、全くの徒労に終わる、なんてことも起こります。初心者のうちは下手に調べるよりも聞いたほうが早く解決することも多いので、メンターが居る場合にはある程度漠然とした質問でも良いので積極的に質問しましょう。
メンターに聞く vs 自分の力で解決する
5分というのはあくまで例ですが、特に業務においては、例えば次のようなケースだと同じ30分かけた仕事でも、Bさんのほうが圧倒的に評価が高いです。
- Aさん: 25分間かけて自分の力で悩みを解決して、5分間仕事を進める
- Bさん: 5分悩んだ時点でメンターに聞いて5分で教えてもらい、20分仕事を進める
もちろん全く同じことを何度も聞いてしまわないように注意は必要です。
また、何か業務を割り振られた場合は（自分から拾いに行く場合も）5〜10分程度でざっくりとした方針をまとめ、メンターにあらかじめその方針を共有してから作業するようにしましょう。方向性に大きな誤りがあればそこで修正してもらえるので、無駄な努力をしてしまうリスクを減らせます。
メンターが居ない場合について: 「メンターや育成担当なんて居ないよ！」という人はX(ツイッター)などのSNSでとりあえず疑問を呟いておく、というのもひとつの手です。運が良ければ誰か答えてくれるかもしれません。
ここで注意したいのは、「手を動かしてない人には誰も答えてくれない」「漠然とした質問には漠然とした回答が返ってくる」ということです。
例えば「Python勉強したいけどどうやったらいいですか？」みたいなのはかなり漠然とした問いですし、暗黙のうちに「私は『Python 勉強』でググることすらしていません」というメッセージを発信してしまっています。
逆に「現状Rubyはそこそこ書けるんだけど、Python入門のためにUdemyで××のコースやってみようと思ってる。もし他におすすめの入門コースや書籍があったら教えて」みたいなのは具体的なので答えてもらいやすいと思います。
最初は深く狭くよりも広く浅くを意識しよう
初心者のうちはITの知識や技術が非常に複雑で高度なものに見え、「自分がこれらのことを理解できる日はくるのだろうか？」と不安になることも多いと思います。しかし、高度な知識や技術は実際には単純な何かを少しずつ組み合わせた結果である、というケースはよくあります。
IT技術の学習を進めるうえでは、全くの初心者の場合は広く浅くを意識し、何度も同じところ（ただし、以前より少しだけ高度な内容）に戻ってきては、少しずつ知識や技術を深めていく、という進め方がおすすめです。
もちろん、すでに自分の興味の方向性が見つかっていてそれを深堀したいとか、やっていて面白いのでついついそればかり深堀してしまう、といった場合はそれに邁進するのもよいです。しかし、初心者のうちは一通り他のジャンルも見て回りつつ徐々に深く学ぶように意識すると良いです。
具体的なジャンルの例
シニアなITエンジニアの多くはITのあらゆる分野に対して一定のレベルの知識や技術を持っています。
おそらく業界経験が長いので仕事上自分でやったことがある/部下や同僚がやっていたということがあるだけでなく、自分で勉強していて気になって調べたとか、面白くてつい試しているうちに詳しくなった、みたいなケースも多いと思います。
以下には私の環境で新人に2〜3年のうちにひと通り通過しておいて欲しいな、と思っているジャンルを例として挙げます。当然他にもありますし、環境等で変わるのでメンターや身近な専門家に聞いてみましょう。
(有識者の人は以下の分類自体にもツッコみたい気持ちはあると思いますが、適当に流してください）
- ハードウェア
- CPU
- メモリ
- ストレージ
- GPU
- その他デバイス
- オペレーティングシステム
- 対話シェル(コマンドライン補完 / コマンドライン編集 / ヒストリ呼び出し / 設定ファイル)
- コマンド / オンラインマニュアル
- システム管理
- Unix哲学
- カーネル
- システムプログラミング
- ネットワーク
- L2 (MACアドレス、VLAN, スイッチ, STP)
- L3 (IPアドレス、ICMP, ルータ、ルーティング)
- L4 (ポート番号, 3wayハンドシェイク, Seq/Ack, 輻輳制御、TCP状態遷移)
- tcpdump / Wireshark / PCAP
- DNS
- HTTP
- TLS
- データベース
- SQL
- RDBMS
- KVS
- 汎用プログラミング言語（最低2言語以上）
- シンタックス
- セマンティクス(入出力、変数、条件分岐、繰り返し、関数、再帰、複合データ、例外、スコープ、クロージャ等々)
- パラダイム(オブジェクト指向、関数プログラミング)
- データ構造 / アルゴリズム
- テスト
- デバッグ / プロファイリング
- ドメイン固有言語
- シェルスクリプト
- HTML / CSS
- JSON
- YAML
- MarkDown
- 開発環境/ツール
- エディタ / IDE
- バージョン管理
- 各種SaaS / IaaS
- セキュリティ
- 運用上の基礎概念(脆弱性 / CVE / セキュリティ勧告 / CIA / CVSS 等)
- 攻撃手法と対策
- 暗号技術
- Web
- JavaScript
- Web API
脳内モデルの構築を意識しよう
ITには複雑な概念が数多く登場しますが、正確で解像度の高い一貫した脳内モデルを持っていると、未知の事象に対しても正確に予測できたり、新しい概念を素早く習得したりすることが可能になります。
新しく技術を学ぶときは、まずざっくりとした脳内モデルを作り、徐々に正確さを向上させると良いです。
脳内モデルとは
シニアなITエンジニアは複雑な概念に対し、正確で解像度の高い一貫した脳内モデルを持っていることが多いです。もちろん、初心者のうちはいきなり「正確な脳内モデルを構築しましょう」と言われても困難だと思います。そもそも脳内モデルが何なのかすら想像がつかないかもしれません。
脳内モデルとは、物理世界や仮想世界に存在するサムシングや論理的な概念に関して、あなたの理解に基づいて心の中に構築しているコピーのことです。「そんなもの持ってない」と思うかもしれませんが、多くの人は物理世界や仮想世界のあれこれを脳内モデルとして持っています。
例えばあなたの所有しているスマホを想像してください。
- あなたのスマホの形状を想像できますか？
- スマホの側面にボタンは付いていますか？そのうちのどれか一つを押すと何が起こりますか？他のボタンではどうですか？
- ロックを解除するにはどうしたらよいですか？
- カメラアプリはホーム画面のどこにありますか？
- カメラアプリのアイコンをタップするとどうなりますか？
- カメラアプリで写真を撮るにはカメラアプリの画面のどこを押せば良いですか？
- アプリで撮った過去の写真を見るにはどのような操作をしたらよいですか？
自分のスマホに慣れ親しんだ人であれば、実際のスマホを操作しなくても、これらの問いに正確に答えられると思います。答えられるのであれば、あなたはあなたのスマホの上記操作に関する正確な脳内モデルを持っています。
さて、脳内モデルがどういうものかについて、なんとなく理解できたでしょうか。
引き続きここではIT技術に関する脳内モデルの初心者向けの構築法をざっくりと紹介します。
それは実験です。
たとえば初めて触れる技術を習得しようとするとき、チュートリアルを読んだり写経したりすると思いますが、自分が写経して動かしてみたコードなどを眺めながら「ここをこう変えたら、どうなるだろう？」と想像し、実際に変更して予想通りになるか確かめてみましょう。ここで予想通りの挙動であればあなたはその変更箇所に関する正しい脳内モデルを構築できている可能性が高いです。逆に予想と外れた挙動になったのであれば、脳内モデルが誤っている可能性があります。自分の理解に誤りがないかチェックして、必要に応じて再実験しましょう。
このような進め方は時間がかかりますし、あまり気合を入れすぎると疲れてしまいます。また、変更結果の挙動を理解するための周辺知識が足りない場合、そこを頑張って解釈しようとしても無駄に時間を浪費してしまうことにもなりかねません。実験は気分が乗った時にだけやるようにする、適当なところでわからないものはわからないままとりあえず置いておいてチュートリアルを進める、というのも重要です。
また、特に仕事で業務を実施しているときには、タスクを素早く終わらせることを優先して詳細な脳内モデルは構築しない（おまじないとしてスルーする）のが最善となるケースもあります。このあたりはタスクを終わらせるのに要求されている締め切りや理解度などを考慮してバランスをとるようにしましょう。
アウトプットを意識しよう
新しい技術や知識を習得するときには、必要に応じてアウトプットをするように意識しましょう。
これは、例えば次のような行動のことです。
- プログラミング言語の知識をインプットしたら、実際にその知識を使ってプログラムを書いてみる
- ツールの使い方をインプットしたら、実際にそのツールを使ってみる
- 新しい概念をインプットしたら、その概念について自分の言葉で説明してみる（または説明資料を作る）
アウトプットについて有識者からフィードバックをもらえると、さらに効果的です。
例えば業務上の取り組みの場合はメンターや関係者にレビューして貰えばよいです。プライベートの取り組みであればOSSとして公表するとか、成果物をSNSに放流する、等で様々なフィードバックをもらえる場合があります。
また、仮にフィードバックをもらえない状況であっても、アウトプットを行う効果は高いです。
なぜアウトプットが必要なのか
なぜアウトプットが必要なのでしょうか？いくつか理由があります。
単純に記憶の定着度を上げるために効果的だ、という面もありますが、アウトプットを意識すべき大きな理由は、次のとおりです:
- アウトプットしようとするときになって初めて「実はわかってなかった」事柄が明らかになることが多い
- 「わかったつもり」になってしまうことを防げます
- 自分では完璧なアウトプットだと思っても、他者から、特に経験を積んだ有識者からみるとまだ改善点があることが多い
- 自分一人では到達が難しいレベルにまで成長が可能になります
IT関連技術において、ある技術を「知っている」ということと「使える」ということには大きな差があります。この差は単に作業効率の良し悪しとして現れることもありますし、問題解決の成否にまで関わってくることもあります。
もちろん全ての技術を「使える」状態にする必要はありません。例えばチームメイトの誰かが「使える」状態ならそれでいい、ということはよくあります。しかし、技術者としては業務上の必要があれば「知っている」状態から「使える」状態に効率よく持っていけたほうが良いでしょう。このときにはアウトプットする、という手法を利用すると良いです。
ドキュメントの種類を意識しよう
初心者のうちはメンターからたびたび「ドキュメントを参照しなさい」と指導されると思いますが、ドキュメントにはチュートリアルやリファレンスなど、いくつか種類があることを意識し、目的にあったドキュメントを参照できるようになっておくと効率的です。
詳細
以下にドキュメントの種類の例をあげます
- チュートリアル(Tutorial)
- 全く何も知らない人（初心者）向けに書かれたドキュメント
- 例が豊富で、いわゆる「写経」することにより、脳内モデル構築の助けになることが多い
- ステップバイステップで初歩的な内容から徐々に高度な内容へと進んでいく内容になっている
- ある程度以上高度な内容はカバーしていないことが多い
- 文書のタイトルには「チュートリアル」だけでなく「入門」「Getting Started」や「101」などのワードが付けられていることも多い
- 商業出版されている書籍は巨大なチュートリアルになっていることが多い
- リファレンス(Refarence) / 仕様書(Specification)
- できるだけ正確に、詳細がわかるように書かれたドキュメント
- ある程度知識のある人向け
- 初心者には理解が困難な場合が多い
- 以下のケースに便利
- 目的(何らかの調べたい事柄や達成したいこと)があって調べるとき
- 詳細な挙動を確認したいとき
- 自分で当該プログラム等を再実装する場合
- 高度な内容までカバーされている
- 目的に応じて必要な箇所だけをつまみ読みする前提で書かれていることが多い
- 特に有名な例として以下がある
- ネットワーク分野における RFC
- Linux/Unix 分野における man
- Q&A / FAQ
- よくある疑問や、つまづきやすい箇所をピンポイントで解説したドキュメント
- チュートリアルを一通り終わらせた初心者から熟練者まで、さまざまなレベルの人にとって役立つことが多い
- ガイド(Guide) / ベストプラクティス(Best Practice) / 勧告(Advisary)
- 「迷ったらとりあえずこれに従っておけば酷いことにはならない」という指針
- チュートリアルは卒業したけど、いざ自分で実践するときに選択肢が多すぎてリファレンスを見ても「結局どう選んだらいいの？」がわからないこともある。このようなときに頼りになる。
- 宣伝(Advertisement) / 紹介資料(Whitepaper)
- 技術文書っぽく見せているが、宣伝や紹介の場合もある
- 技術的詳細はわからないことが多い
- とはいえ、これらは悪いわけではない。むしろ時間をかけずに概要を把握したい、という場合には一番最適なドキュメントであるケースも多い
- 作業記録
- 著者が実施した作業のメモを公開しただけ、というタイプのドキュメントもある。
- 日付が新しい記事であれば役に立つことが多いが、古いものは残念ながらあまり役立たないこともある。
- 誤った手順が含まれていることもあるので注意が必要。
他にもあると思いますが、重要なのは「ドキュメント」と言っても色々なタイプがあることを理解しておくことです。
ドキュメントの信頼度を意識しよう
ITエンジニアにとって重要な情報源として各種ドキュメントがあります。しかし、ドキュメントと言ってもその信頼度、つまり内容を信じて良いかどうかの度合いは、実はドキュメントによって異なることを知っておきましょう。
詳細
ある程度の規模の利用実績のあるOSSプロジェクト等による公式ドキュメントや、編集者のチェックが入っている商業出版された書籍等は正確な記述であることが多いです。
一方、 Qiita や StackOverflow のような誰でもノーチェックで公開できるような場所に書かれている内容は完全な嘘とは言わなくとも不正確だったりすることがあります。これらは必ずしも信頼度が低いわけではなく、玉石混交というのが一番近いイメージです。モデレーションや「いいね」の数などがうまく機能しているケースもありますが、そうでないケースもあって判別が難しいところです。
例えば初心者向けの記事と有識者向けの記事があった場合、初心者向けの記事のほうが対象読者の絶対数が多いため、必然的に「いいね」がつく数は多い一方、「いいね」をつける側が初心者なのでその記事が正確なことを書いていると判断できる人の割合は相対的に低くなります。結果として10件の「いいね」がついた記事よりも1000件の「いいね」がついた記事のほうが、正確性においてかなり劣るということも起こり得ます。
原則としては専門家のレビューをしっかり受けている順に信頼度が高いといって良いです。
文書の種類で言うと、おおまかに信頼できる順に
公式ドキュメント/RFC > 商業出版物 > その他
ではありますが、どれについても例外はあるということを認識しておきましょう。
英語を勉強しよう
ITエンジニアにとって重要な公式ドキュメントが英語で書かれていることはよくあります。
有志が日本語のドキュメントを整備してくれていることもありますが、より高度でニッチな内容になるほど英語でドキュメントを読んでいく必要がありますから、英語はコツコツ勉強しておきましょう。
ITエンジニアにおすすめの英語勉強法
英語が得意な人は読み飛ばしてください。
ITエンジニアにおすすめの英語勉強法はリーディング能力を鍛えられる「多読」です。もちろんリーディングだけでなく、リスニング、ライティング、スピーキングも鍛えることは有用ですが、日本でITエンジニアとして働くうえではリーディングをまず鍛えることが効率的です。
そもそも英語圏におけるIT系の技術文書は、平易な英語で記述されていることが多いです。もちろん専門用語や技術的な概念は多数登場しますが、英文自体としてはシンプルなケースが多いです。
また、ITエンジニアは必要があれば比較的大量の英語ドキュメントを読み進めなければならないこともあります。このときに必要なのは日本語訳バージョンを作成できるほど一言一句正確に日本語へと頭の中で翻訳して内容を把握することではなく、その英文が指し示すイメージを直接脳内に構築しながらスピーディに読み進めることです。
この作業をするうえで重要なのは英語を英語のまま意味を把握する能力と、わからない単語に遭遇したときに周囲のコンテキストからその意味を推定する能力です。
こういった読み方を鍛錬するのに最適な方法は多読です。
多読を実践するには、Penguin ReadersやOxford Bookwormsのようにレベル分けされた比較的短い本を大量に読むのが最も簡単です。
https://www.penguinreaders.co.uk/
https://www.oupjapan.co.jp/ja/gradedreaders/bookworms.shtml
知らない単語がほとんど登場せず、「これは簡単にスイスイ読めるなぁ」くらいのレベルの本をたくさん読むのがコツです。また、読んでいるときは辞書を使ってはいけません。知らない単語に遭遇したら周辺のコンテキストから意味を推定するようにしましょう。詳細は「英語 多読」などでググって出てくる英語の多読に関する解説を参照してください。
もちろん、英語学習のすべてが多読だけで解決できるわけではありませんが、ITエンジニアの英語学習の第一歩としては有用です。
コンピュータにはコンピュータが得意なことをやらせよう
大量データの処理だったり単純作業の繰り返しだったり、コンピュータが得意なタスクを人間がやらないようにしましょう。人間はコンピュータがその能力を存分に発揮できるようサポートするつもりで作業すると良いです。
詳細
たとえば次のようなタスクはコンピュータが得意なことです。
- 速く正確に大量の計算をする
- 大量のデータから条件に合うものを検索する
- あらかじめ厳密に定義された形式のデータを大量に正確に読み取る
- 単純作業でも飽きたり疲れたりせず、ずっと一定のパフォーマンスで動き続ける
これらのタスクに関する人間との能力差は圧倒的で、人間がどんなに頑張ったり訓練したりしても絶対にコンピュータに勝つことはできません。
逆に、たとえば次のようなタスクはコンピュータは得意ではありません。
- 曖昧な状況下で多数の選択肢から最適なものを選び取る
- 未知の事象に対して適切に判断する
- 少ないデータから、人間の気持ちや行動を予測する
- 表記揺れや誤りのあるデータを自動的に修正して読み取る
- 誤りを修正して、自らの挙動を全く新しいものに変更する
これらのタスクであっても、もちろん特定の条件下ではうまくいったり、あらかじめ予測できてる範囲のものに限っては人間以上の能力を発揮することはあります。また、近年AIの目覚ましい発展により、これらのものもコンピュータは得意になり人間の能力を凌駕しつつありますが、その能力差は前者の得意なことに関する能力差ほどではありません。
重要なことは、コンピュータが得意なタスクをコンピュータにやらせて、人間が得意なタスクは人間がやる、ということです。具体例をあげましょう。
例えば、大量のログの中から " 200 " という文字列を含んだログエントリを見つけるというタスクがあったとき、ログをテキストエディタで開いてスクロールバーを動かしながら人間の目で " 200 " を探すようなことをしてはいけません。
では、エディタの検索機能を使えばよいでしょうか？ファイルが1〜２個であればそれでも良いのですが、例えば対象のファイルが100個あったらどうでしょう。例えば Linux であれば「ファイルのなかから指定した文字列を含む行を表示する」というそのものズバリな機能をもった grep コマンドがあるので、それを使うと100個程度のファイルであれば一気に検索が可能です。ファイルサイズが大きい場合は数十分動かすことになったりはしますが、コンピュータは休まずに動いてくれます。
巨人の肩に乗ろう
「巨人の肩に乗る」というのはIT業界（に限りませんが）でよく使われるメタファーです。
意味は「利用できるサムシングがすでに存在しているのなら、それを利用する（わざわざ自分で作ったりしない）」ということです。
詳細
IT関連技術は様々なコンポーネントからなるレイヤーを多数積み重ねて構築されていることがよくあります。
例えば Hello, World! と出力するプログラムはプログラミング言語入門の第一歩目の題材として非常によく使われますが、 print だとかあるいは printf, println, puts などのごくごく基本的な出力機能であっても、その背後にどのように複雑で巨大な仕組みが動作しているのかを隅々まで把握している人はあまり多くありません。（実際にはOS(オペレーティングシステム)のkernel(カーネル)と呼ばれるプログラムがこの複雑で巨大な仕組みの多くを担当しています）
このとき、そのような背後にある複雑で巨大な仕組みを隅から隅まで把握しなければならないとしたら、いつまで経ってもあなたが Hello, World! と出力できる日は来ないでしょう。裏にある複雑さをうまく隠蔽してくれる便利な道具があるのなら、積極的にそれを利用して自分の実現したいことを実現させましょう。
上で例に出したのはOSの話でしたが、例えば最近ではオンプレサーバにDBクラスタを構築して自力で運用するのではなく、クラウド上でマネージドDBサービスを利用する、というのも巨人の肩に乗る代表例です。
もちろん、背後にある複雑で巨大な仕組みを内部まで把握しておくことは有用です。自身の嗜好や興味がそちらに向いているのであれば、複雑で巨大な仕組みの世界に飛び込むのも良い学びになると思います。
なお、この話と同様の内容は「車輪の再発明」や「NIH症候群」などのワードとともに説明されることもあります。上に書いたとおり原則としてはこれらを避けるべきですが、学びのためにあえてやることが良い結果に繋がるケースもあります。
まとめ
本記事では新人ITエンジニア向け技術習得のコツとして、次のようなポイントを解説しました。
- タッチタイプを習得しよう
- メンターを探そう
- 5分悩んだらメンターに聞こう
- 最初は狭く深くよりも広く浅くを意識しよう
- 脳内モデルの構築を意識しよう
- アウトプットを意識しよう
- ドキュメントの種類を意識しよう
- ドキュメントの信頼度を意識しよう
- 英語を勉強しよう
- コンピュータにはコンピュータが得意なことをやらせよう
- 巨人の肩に乗ろう
さて、蛇足ですが最後にもう一つ付け加えます。
それは、自分のペースで毎日少しずつ成長しよう、ということです。
先輩社員やシニアエンジニアの姿を見て「どうやったら、あそこまでの技術者になれるのか全く想像もつかない」と焦ったり、半ば絶望した気持ちになることもあるかもしれませんが、その点について深刻に考える必要はありません。あまりに多くのことを一度にやろうとすると疲れてしまったり、燃え尽きてしまったりします。たとえばこの記事自体に書かれていることを全部一度にやっていこうとすることなどがそれにあたります。
自分にとって快適なペースで良いのです。昨日の自分から今日は少しだけだけど成長したな、という小さな繰り返しを積み重ねるようにしましょう。その積み重ねがあなたを素晴らしいエンジニアとしての境地に導くはずです。
以上です。