絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。
当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。
目次
はじめに
これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。
それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の１つにでもなればという感じです。
インプットする理由
技術力を求める
なぜインプットをする必要があるかと問われれば、『メシを食っていくため』です。IT業界は業種・時代・所属部署が変わるたびに、必要とする技術力も変わるため、一芸に秀でていれば一生食えるなんてことはまずなく、環境に適応していく必要があります。逆に、環境に適応することこそが一芸である、と表現してもよいです。前に エンジニアの勉強と技術力と育児 | 外道父の匠 という記事を書きました。インプットは『勉強』とも言い換えられますが、『勉強』単体で考えてもたいした意味はなく、実際に手を動かす『構築・運用』を経て『経験』となり、【技術力】へと昇華していくことに意味があります。
技術力が高いということは、選択肢が多い・判断が早い・処理速度が速い・コストが安い・運用しやすい、など色々考えられ、ザックリ言うと『成果が早く高品質である』ことを実現するパワーがあるということです。
ちょうどこういう記事 「頭の回転が速い」を科学する｜宮脇 啓輔 / 株式会社unname がありましたが、エンジニアにおいてはインプットの量とアウトプットによる経験量がおよそ半々くらいが思考速度に影響するイメージで、技術力が高くなると、成果が早く品質が上がり、ユーザーが喜び、収入も上がりやすく、さらに難しいタスクを手掛けられ── と良い循環になっていきます。
そのため、根本的にはやはり継続的なインプットが重要で、少しずつでも向上することと、停滞することは天地ほどの差があるので、向上心というか習慣として長く気楽にインプットし続けるのがよろしいかと思います。
自身のコントロール
しかしながら、定期的にこういう悪い意味でのネットミームが湧くじゃないですか。こういうのに踊らされる状況って、おそらく自身のコントロールができていなかったり、自信がない状態だと思うんですよね。眼の前のタスクを高品質に仕上げるという目的がブレなければ、ただひたすらサイクルを回すだけなので、こんなことを考える必要性など起きないからです。
継続的なインプットと言っても、別に毎日ガリ勉するわけでもなし、マイペースかつ必要に応じて取り組めむだけで十分です。あくまでも技術力へと昇華することが目的なので、インプット偏重になることは良くありませんし、なによりエンジニアとしての生活に疲れやすくなってしまいます。経験則だと、勉強だけしていても、研究だけしていても、運用だけしていても、遠くないうちに飽き疲れしてしまいます。
また、インプットの内容や進み具合によっては、得意分野や難易度で相対的に辛く感じる時期もあります。自分も新しいタスクやインプットを始める時は、理解度が一定量を超えるまでの最初の数日はマジでダラつく悪癖があり、それを超えれば早くなるしと割り切ってダラついたりもします。
己を知り制御する。どんな時に調子が良い悪いとか、インプットからアウトプットへのサイクル間隔は程よいか、ってのを定期的に意識してモチベーションを自身でコントロールできると、変な闇に落ちづらくなるかもですね。意味もなく有給を取るのも効果的だったりするし、あまり堅く考えない方がイィです。
アートとしての技術力
インプットによって最低限に実現したいことは、必要とする機能を正常に動作させる成果です。多くは業務として役割やタスクを割り当てられ、その通りに構築したり運用をできれば、それでメシを食っていくことができます。指示されたモノやコトをキッチリ仕上げられる── それだけで十分に素晴らしいですが、システムの品質にはその”先”があると考えます。
この業界には【技術力】というふんわりとした雰囲気の単語が存在し、なかなか定量的に表現できるモノではないため、人事評価ですったもんだすることもしばしばあります。また、【高品質】も定量化することが難しい言葉です。
そのため、あるタスクに対して【技術力】をもって【高品質】に仕上げるように、というような指示や依頼は発生しません。しかし、エンジニアの端くれならば、より良く仕上げたい、矜持を持って最高のシステムを提供したい、という想いは少なからずあるはずです。
その時に活躍するのが、常日頃から積み上げたインプットです。ただ動くだけではない、早く・速く・安く・安定して・堅牢で・運用しやすく・手間も少ない、高品質なシステムとするために、一見は余計・過剰とも思える範囲の情報にまで手を出す価値がそこにあります。
もちろん品質はテストによってある程度を保証しようとします。それでも、結果がボロボロで大半に改善を必要とするか、少ない改善で済むか。テストが通ってもいざ本番運用では、障害対応や調整にどれくらい手間をかける必要があるか、はテストで洗い出せない部分も多いです。
そういう見えない部分で、実はハナから総じて楽に扱いやすく運用できていますよ、という結果をもたらしてくれる技術力って、もはや【アート】の領域ではないか、と思うことがあります。
身近に何年も変わらず安定して稼働し続けているシステムや、初見で１つも文句が出ず気に入られている機能とかありませんか。それって当たり前ではなくて、有能なエンジニアの技術力が生んだアートといっても過言ではなく、それはやはり膨大なインプットとそれから生まれる経験によるものなんだと思います。
インプットの方向
さて、技術力が伸びていく過程で色々インプットしますが、その情報源にはどのようなモノがあるでしょうか、ってのを考えてみます。- インターネット
- ドキュメント
- ブログ
- 掲示板
- SNS
- 社内情報
- グループチャット
- 情報共有サービス
- 同僚・師弟
- 業務そのもの
- 書籍
- 研修・資格取得
- 技術系イベント
──など色々な手段があり、どれも有用になり得ることでしょう。
とりわけ、自身の意思で自発的に PULL してくる情報は身につく可能性が高いです。それと同等の時間をかけたとしても、他者から PUSH されたテイの情報は、欠片が残るかどうか程度の薄さになりやすいです。
誰にでも経験があるだろう事象だと── 他者の講義を聴くにしても、後ろの席に座るのか、前の方の席に座るのか、それだけでもその情報の濃さが変わります。時間・費用・吸収する意思、の認識が明確であれば、講師の話を聞き取りやすく質問もしやすい、近くに行くのが自然です。
小学生がヤル気アピールしたら成績に影響するようなチャチな話ではないのですから、講義を PUSH されに行ってンのか、コスパ・タイパを最高にすべく PULL しに行ってンのか。子どもを諭すような話ですが、そういう基本的な部分── ”モチベーション”と言い換えるとわかりやすいでしょうか。
やはりそれを自身でコントロールできる、している気になるのはかなり重要な要素であると考えます。仮に半強制的にインプットさせられる PUSH 状況だとしても、その時間を有効なモノにしようとしたり、どんな知識にも意味があると捉えられれば、それは何倍も効果的な PULL 型のインプットになるのです。
深いインプット
PULL 型のインプットが効果的であり、その意思があるとした場合に、自然とその形になる手段が文字を読むことです。──となると、技術書を読むことが１つあります。これは人や目的によっては有効な手段になることは言うまでもないですが、私はあまり書籍に頼らずに進行してきました。
私が常に主軸とする情報はドキュメントです。なぜドキュメントなのかというと、それがエンジニアとしての武器・メインウェポンの攻撃力に直結するからです。
エンジニアならば何かしらの設計・構築・運用をするはずで、そのタスクを最低限にこなした状態は、言われた通りに機能を動かせたとか、ただツールを使えるようになったとか、達成感のわりに実は眼の前の積み木を積み上げただけに過ぎないだけの時期もあったりします。
その狭い視野を広げ、より深い考察の可能性を知るには、扱うシステムのドキュメントを全て読み込むのが最も確実です。
『アナタが現在、最も好む・得意なソフトウェアはなんですか？』
『そのソフトウェアのドキュメントを全て読みましたか？』
※プログラミング言語・ミドルウェア・マネージドサービスなど全て含む
と問われて、「YES!!」と即答できる人はどれくらいいるでしょうか。自分が扱うシステムの仕様全容を把握していないのに使っているとしたら、その制作物の品質が最高に近い可能性は限りなく低いと思いませんか。
ドキュメントには機能面ではほぼ全てが記載されているはずなので、薄く広くでも網羅することで、便利で効率的な機能や設定を知らずに進行してしまい、時間・費用の無駄や、技術的負債の積み上げを避ける可能性を高めることができます。
品質に自信のない状態── 品質の判断すらできない状態は不安なはずです。まずは自信もって高品質ですと提示するための、メインとなる武器を磨くために、最初は理解が難しい部分があったとしても、ドキュメントに目を通すべきです。そのうち、必要に応じて深堀りしたり、理解できるようになっていくので、少なくともその広さを体感しておくとよいです。
１つの深堀りを体感しておけば、他の技術知識も何をどれくらい掘り下げれば十分なのか、効率的な取捨選択をしてよいのか、を判断できるようになっていきます。そのためにもまずは１本軸を確固たるものにし、その土台に大小様々な２本目以降の柱を立てていくイメージで流れを作り上げましょう。
広げるインプット
ドキュメントを読み進めていると、知らない単語や知識に遭遇することがあります。これは、ドキュメントが機能説明を果たしているだけで、その場では知っていて当然とされる知識や、その意図や効果については懇切丁寧に説明してくれることはほぼないため、自力で解決する必要があります。前記事 WEBサーバーのレスポンス圧縮でコスト削減 | 外道父の匠 を例に出すと、WEBサーバーや CDN のドキュメントを見ていると、コンテンツの圧縮ができることと、その設定方法が書かれています。しかし、なぜ圧縮する機能がついていて、どのような効果があるのか、が併記されていることはまずないでしょう。
これに遭遇した場合、少なくとも何のためにそれが存在するのか、程度は調べて理解しておくことをオススメします。その効果の度合いについてはすぐ見つからなく、自分で検証する必要がある場合は、その必要性が強まってからで大丈夫です。
──というように、ドキュメントを軸に知らない知識を広めていく行為は非常に重要です。IT業界には基礎知識や常識みたいなものが山程あり、誰しも最初は知らんモンは知らんので、１つ１つ理解を積み上げる必要があります。
基礎ではない専門的な部分も同様ですが、そういう知識には深さがあります。圧縮ひとつとっても、圧縮形式が多くあり、それぞれ効果が異なり、それはアルゴリズムが異なるからである── と踏み込んでいくことは可能です。
──可能ですが、その使い方や効果までで十分であり、実務において詳細な中身を知る必要はほぼありません。Linux を扱うのに Kernel を、プログラミングするのにその言語がどうやってできているのか、を知る必要がないようにIT技術は蓄積されているからです。
もちろん、知ろうとするのは自由ですし意味を見出すことも可能です。しかし、持ち得る時間に対して、全てを掘り下げ続けることは不可能です。
ITエンジニアには色んなレイヤー・役割があります。下はハードウェアから上のアプリケーションまで幾層もあり、自身から遠いレイヤーほど知識が薄くともその役目を果たすことが可能です。ちょうど、念能力の系統修得％に近い話です。
ただ、知識が浅いことと、全く知らないことには天地ほどの差があるため、浅くでも広げておくことはやはり品質に繋がります。また、組織の規模が大きいほど専門的な深さを、規模が小さいほど守備範囲の広さを求められがちで、環境によって効果的な広げ方が異なることになります。
そのため広すぎる技術知識の海原においては、１つ決めたドキュメントを軸に、基本は浅く広く手を広げ肉付けしていくのが、関連事項という意味で将来的に無駄の少ないインプットとなることでしょう。
その土台が固くなるほどに、言語が変わったり、ミドルウェアやクラウドが変わっても、素早く適応していける。最適化の選択肢を網羅的に考察できる。ような戦力となっていけるはずです。
設定からインプット
ドキュメントに含まれる大きな部分の１つに『設定』があります。設定とは、その値を変更するだけで、対象機能の挙動を変更できることを意味します。そして設定が存在しないソフトウェアはほぼ存在しません。何かを作ればすぐわかることですが、ある１つのソフトウェアの塊は、全て同じ内容で、どこでも最良な状態で動くとは限りません。また、環境ごとに気軽に変更したい項目も次々に出てきます。そのため、少しでも気の利いた制作者は、可能な限り可変可能なシステムにできるよう、設定値として丁寧に切り出していきます。
すなわち、それがそのシステムにおけるソフトウェアとしての最適に向かうための基本選択肢の全て、といっても過言ではありません。ドキュメント全体は１つ１つ機能を理解するための説明となっており、設定単体としての説明は、また全く異なる味のするインプットとなることでしょう。
設定値にはまずデフォルト値があるということ。そして変更できる値と、その意味が書かれていること。ただし、その詳細な効果はそこまで書かれておらず、実際に検証しないとわからないことが多い。あたりが特徴となるため、続きはブログや掲示板に委ね、それでも確信が得られない場合は自身で検証することになります。
ソフトウェアの設定ファイル的なものがメインの話ですが、コマンドのオプション、コンパイル時のオプション、など色々なところに存在します。それらは１つ追加したり変更するだけで、扱いが楽になったり、品質が向上したり、障害の原因を取り除いたり緩和できることがあり、そのインプット・コストに対して非常に高い効果をもたらしてくれる可能性を秘めています。
私がクラウドの機能を組み上げていく場合は、そういった可能性を逃さないためにも、Terraform ドキュメントを軸に全選択肢の存在を把握することもあり、設定はシステムを修得するための頼もしい存在という立ち位置となっています。
役立つインプットを
未熟なペーペーの時代からドキュメントを読み込んできて、こういう姿勢でインプットしてきたと整理してみました。しかし、人によって・時代／状況によっても、取り組みやすい・身に付きやすい方法が異なるのは当然なので、色々模索してみたら良いと思います。ただ、その中でも１つ推奨したい軸があります。それは、実際に自分で動かして使うシステムに関連するインプットにすることです。実際に使うかわからないとか、動かしてみないようなインプット一辺倒では必ず飽きに繋がりますが、手を動かすアウトプットへ都度反映することで、その数値や見た目の変化が確信や体得となり、それが形になるまでの継続力が段違いとなります。
そういう意味では人によってはドキュメントより兎にも角にも動かしてみるって手順もありかもしれません。ただしその場合は、動いて満足して早めに切り上げすぎないように注意し、あくまでそれは慣らしの段階であって、キッチリ詳細に仕上げる段階とは切り替えて考えた方がよいかもしれません。
また、そうやってたくさん読んで知識を積んでも、次々に必要とされる技術が入れ替わり、技術が枯れたり不要になっていくという寂しさ虚しさは少なからず存在します。
しかし、地力として残り役立つ知識も多く存在しますし、新しいシステムのドキュメントを読み進める力強さや、英語を読む力はそう衰えることはないため、必ずしも無駄になるわけではありません。そしてそれは、アウトプットを経由して変換された【技術力】も同様です。
今自分が何をしていて、何を知れば役に立ちそうで、どのくらいの早さで進めれば成果と負担のバランスが取れるのか。漠然としたインプットにはせず、そういった役立つ目的に向かって、少しでも整えようとすると長続きしやすいはずです。
おわりに
ITのシステムは、あえて軽い言い方をすれば、所詮、理解して組み立てるだけです。業務の多くは、何かを完全なゼロから作り上げるなんて偉業はほぼ存在しなく、ちょっとしたアイディアを実現するために、既存のシステムや知識をかき集めて形にしているに過ぎません。しかし、その形がイビツだとかパーツが足りていないとか、綺麗だとか手触りが良いといった、どのような評価になるかの基本はインプットの量がモノをいいます。
業務としてのアウトプット、勉強としてのアウトプットはもちろん大事で、その循環も意識していきたいところですが、アウトプットも実際のところは大量のインプットのうちの何分の一 程度しかできないはずで、やはりインプットの量と効率が成長全体の質へと繋がるのではないでしょうか。
誰も彼もが大量にインプットする必要はないとは思いますが、自身が目指したいエンジニア像というか技術力、生み出したい成果物の品質、をイメージしつつ、その大きさと必要性に沿って長く継続できれば、たいていは引退まで楽しく満足して過ごせるような気がします:-)
