新卒エンジニアのきみに

エンジニア歴ももうすぐ30年になるんだけれども。

もともと趣味でプログラムを書いていたし、C言語さえ覚えればあとは一生勉強せずに食っていけると思っていたんだけれども、今ではそんな言語はほとんど見ることも無くて、新しい言語やフレームワークがものすごいペースで登場と退場を繰り返していて。

時を越えて役に立った、最初から知ってればよかったことを手紙にしておこうと思う。

読む：9割 / 書く：1割

職業エンジニアの仕事としては、プログラムを1から書く(フルスクラッチする)プロジェクトは少ない。
スタートアップ企業などで1から書くことももちろんあるが、オープンソースや外部ライブラリ・フレームワークを組み合わせてプログラムを作り、全て自分で作らないケースが大半である。

工夫して自分なりのコードを書くのがプログラミングの醍醐味であるし、達成感も大きいが、全く分からない巨大なスパゲッティーソースから必要な情報を探す能力を上げることも視野に入れよう。結果としてプログラミング上達の近道にもなるから。

そして、優れたオープンソースやライブラリの大半は海外製なので英語もGoogle翻訳を駆使して読めるようにしておこう。

写経

昔はプログラミングの勉強をしようと思ったら、数千円の書籍を購入する以外に方法がなかったが、今は便利な世の中で github などに優れたソースコードが大量に存在している。

手頃なサイズで興味のありそうなコードを探して、手で打って動くようにしよう。

退屈な教科書の様な書籍から得られる情報よりはるかに多くの情報が得られるはずだ。
英語の文法を何年も習ってるのに、英文を書けるようにならない理由はシンプルで、書いてないからだ。
if文が分からない、for文が分からないと悩むより、心を無にして写経をする方が救いがある。

自分で考えたコードは最高にカッコいいし、書いた達成感もあるが、それは自分のモノサシの中での最高だったりする。
世界の超絶にカッコいいコードをたくさん読んで、自分のモノサシと一般的なモノサシを近づけてほしい。

コーディングは外部設計の翻訳作業

PG（プログラマ）で数年間経験を積んだらSE（システムエンジニア）として外部設計を行うというキャリアパスは一般的だと思うが、コーディングと外部設計が全く別の工程と考えられているケースが多い様に思う。

「美しく、読みやすいプログラムは？」という問への一般的な回答は以下だと思う。

適切なコメントが書かれている
クラス名や関数名や変数名が分かりやすい
デザインパターンに沿って設計されている

ところでこの 「適切な」 とか 「分かりやすい] とかってなんだろう？
変数名のルールを分解すると「動詞」+「名詞」、キャメルケースなど体裁を整える方法はよく見かけると思うが、これは仕様書で言えば「体言止めで書こう」といったレベルのルールであり、仕様書全体の読みやすさには大きな影響はあるが本質ではないことが理解できると思う。

「分かりやすい」 仕様書は、 「ストーリーがきちんとできてる」 仕様書だと思う。粒度の粗い概要などの話題から始まり、章立てが正しく構成され、自然な流れで物事が説明されている仕様書が分かりやすいのではないだろうか？

業務プログラムのコーディング（主にビジネスロジック部分のコーディング）は、そのストーリーをそのままコンピューターが理解できる言語に翻訳する作業だと思う。

当然、それだけでモノができるのは「ローコード」「ノーコード」と言われているツールだけであって、外部設計以外にも莫大なコードが存在するが、「ある一定の断面」を切り取った時に、外部設計のストーリーが読み取れる様に書かれていると「分かりやすい」プログラムになると思う。
ソースを読む人間が持っている前提知識は、外部設計や要検定義など前工程の知識しかないはずだから。
言語を理解していれば読めるハズ、は、日本語が理解できれば、物理や科学の本を読めるハズと言っているのと変わらない。

この様に考えて作業をしていれば、外部設計も自然にできるようになっているはずなので、コーディング作業から外部設計へとキャリアを変えていく時の痛みが少ないと思う。

デザインパターンに従って、隙きのないクラス設計を行うのは尊いし価値もあるが、外部設計に従ってコーディングすることにも同じくらい価値があると思う。

プログラム以外のこともやる

わたしの場合、小さなゲーム屋にいたので割と何でもやっていた(画面デザインや簡単なアイコン作成、シナリオ、Webライティング、PM…)ので意識せずに視野を広げることができたと思う点がある。

業務プログラマーをやっているとプロジェクトのゴールは単一であることが多いと思う。
製造物がプログラムのみで、それが完成すれば試験して納品となるため、「バグの量」「完成までの時間」などが成果物に対する尺度であり、知覚できることが少ない。

一方、ゲームのプロジェクトはそうではない。
グラフィッカーは依頼された画像リソースを完成させるのが彼らのゴールであり、彼らのプロジェクトはそこで終わりである。
サウンドやシナリオも同様であるが、プログラマは、受け取ったリソースをゲーム上で動く形にするのがゴールである。最後にバトンを握って、リソースに不備があると修正依頼を出して嫌な顔をされながら直してもらうことになる。

マテリアルデザインが業務アプリの世界にも侵食しつつあり、ガチ業務エンジニアのあなた達も、リア充っぽいデザイナー達と仕事をするようになってくることが想像される。

ここで理解してほしいのは、誰がいいとか悪いとかではなく、自分と大きく価値観が異なる人間がプロジェクトに存在すること。
製品を開発するプロジェクトにおいて、**「プログラムを書くことはごく一部の工程」**であること、プロジェクトには色々な立場の人が参画していること。自分の立場のみを主張していると、製品の開発などできないということ。

「技術が分からないから管理をやる」は超高難易度

このようなことを考える方は割といると思う。

「管理」という仕事が仕事を右から左に流すだけの仕事であれば、可能かもしれないが、見積もりやwbsの作成、メンバーのサポートや教育など、どれを取っても基礎的な技術なしで簡単にできるものはないと思う。

**そもそも、右から左に流すだけの仕事は存在しない。**誰か特定の人間に頼む必要がある仕事ではないからだ。

新卒エンジニアのきみに

技術の遷移を見ていると勉強しなくてよくなる日はこなそうです。
最近のプログラム言語は昔の言語に比べると簡単だし楽しいですし、どうせやらなければいけないことであれば、楽しくやれるようにポジティブに色々なことに取り組んでもらえたらと思います。

よかったらこちらの記事も合わせてご参照ください：