新人エンジニアに知っておいてほしい8のこと

f:id:khei-fuji:20140129234041j:plain

photo credit: Tom & Katrien via photopin cc


下の内容を思うがままに書き出してみます。

  • 時間で成果は計れない
  • テクノロジーとプロセスのどっちも大事
  • 知らないと知っているは違う
  • 知っているとできるは違う
  • 見返りの少ない仕事もある
  • 技量は年齢に比例しない
  • 世の中は広い
  • 読む習慣を身につけよう


時間で成果は計れない

製造工場の作業やコンビニバイトでは、生み出す成果は費やした時間でほとんど決まるでしょう。
初心者と熟練者ではせいぜい 3 倍くらいの成果の違いにとどまると思います。
しかしシステム開発のエンジニアでは 10倍以上の違いは珍しくありません。
(そもそも成果を測るのが困難ですが・・・)


何かの本に載っていた乱暴な考えですが、
「センスのないプログラマを業界から一掃し、
優秀なプログラマだけで世のシステムを作っていったほうが効率的では?」
という考えもあるほどです。


残念ながら時間と成果は比例すると考える管理者はあちこちに見受けられます。
大抵の場合、この管理者は非エンジニアです。


プログラマーは画家やミュージシャンのように、
リエーターの部類で考えるべきでは?」
という考えが、少しずつ世の中で広まっているのを最近感じます。


テクノロジーとプロセスのどっちも大事

成果をあげるためには、テクノロジー(技術力)を身につける必要があります。
しかしそれだけでは開発はうまくいきません。
システム開発は複数人で行うため、どのように開発するかが大事だからです。
これは管理者がどうにかするべきだ、という考えももちろんありますが、
開発者もマネジメント、特に開発プロセスへの理解を示す必要があります。


例を挙げればスクラム
メンバーがバラバラに開発していれば一つの機能はなかなか仕上がらず、
開発途中の機能だらけのプロダクトが生まれることでしょう。
それをユーザが望むとは思えません。


知らないと知っているは違う

ただ違うレベルではなく、全然違います。
たとえば、「マイグレーション」といった、
新人でわかるか微妙なラインのキーワードを挙げたとします。
これを知らない人に説明するのにはコストがかかります。
これが日常で積み重なっていくとバカには出来ません。


すべてのものごとを知ることは不可能ですが、
薄く広く知識を仕入れることは、自身の糧になることでしょう。


知っているとできるは違う

これも全然違います。
知ってるレベルの技術は所詮そのレベル。
経験者がいれば優先的にアサインするので、
知っているレベルの人に出番はなかなか回ってきません。


その技術を使ってプロダクトを作れる能力がなければ、
ユーザに価値をできませんからね。


見返りの少ない仕事もある

少しネガティブな話です。
所属する会社にもよりますが、必ずしも常に自分が望む仕事にアサインできるとは限りません。
誰も触りたくないようなスパゲッティコードの修正など、
あまりやりたくない仕事をするときもあるでしょう。
ここで意気込んで
「テストコードを作ってリファクタリングしまくろう!」
とするのは、無謀なときもあります。


仕事には新たな知見や知識などの何らかの見返りがあるものですが、
それが少ないこともあります。
そういうこともあると見切りをつけて対応し、
次の仕事に早くアサインできるようにするのも手だと思います。


逆に、その場では役立つと思えなかった知識が後で役立つことがあります。
「点と点が繋がる」というやつです。


スティーブ・ジョブズの点と点 - YouTube

この瞬間はなかなかありませんが、なかなかいいものです。


技量は年齢に比例しない

エンジニアとしての技量の差は「プログラミングを始めた年齢」だけではありません。
もし10人が未経験の大卒で一斉にスタートしようが、
どのように取り組んできたかによって技量に大きく違いが出ることでしょう。


日進月歩でさまざまな技術や思想が生まれては消える業界です。
何もしなければ時代に置いて行かれます。


自発的な学習が伴う人
他発的?に学習する人
何も学習しない人
3者の差は明らかです。


一度学習の習慣を失った人が遅れを取り戻すのには非常にコストがかかり、
ますます学習しなくなります。


一方、学習の習慣を身につけた人はいいことばかりです。
後発の技術は先発の技術の少しの積み上げであることが多いため、学習コストが少なく済みます。
集団の中で差をつけた人は、挑戦的な仕事にアサインされやすくなるため、
さらにその中で新たな学びを得るチャンスに出会えることでしょう。


世の中は広い

会社に所属すると、
「世の中の全体から見れば間違った判断でもその判断に従わざるをえない」
というようなことがあります。


また、会社の人と接する機会が多くなることで、
世の中のトレンドと逆行した行動をとっていることに気づかない
ということもあります。
(その会社自体が業界のトレンドをつくっていくよう立ち位置かもしれませんが)


社畜の話がしたいわけではありません。
一つのコミュニティから得られる情報だけを頼りにしてはならないということです。
IT業界全体、Web業界、オープンソースのコミュニティ、標準化団体、著名なエンジニアなどなど。


さまざまな立ち位置からものごとを考えられるようにすることで、 よりよいプロダクトづくりにつながります。


読む習慣を身につけよう

できれば書籍が望ましいですが、厳しければブログやネットの記事でもいいです。
そこからだんだんと書籍を読めるようになるのが理想です。


リソース配分を
プロダクト:100% よりも、
プロダクト:90% + 読書:10% とするほうが
高品質なプロダクトが作れると感じます。


目的のプロダクトのプログラミングに専念しているときよりも、
少し違う分野に頭を働かせているほうがアイデアにつながり、
プロダクトへのフィードバックが生まれるものです。
(遅くまで残業するよりも、さっさと帰ってシャワーを浴びてるときに閃いたり。)


最後に

知っておいて欲しいものを伝えるのはいいのですが、 伝わった状態にするのがなかなか厳しいです。


こういう話をまともにできる人≒理解してる人で、
こういう話をできない人≒理解しようとしない人なので、
このギャップに悩まされます。


プログラマが知るべき97のこと

プログラマが知るべき97のこと