IT未経験が42tokyoに3ヶ月フルコミットした記録

dai65527

2020年の10月から謎のエンジニア養成機関42tokyoで学んでいます。

入学から約3ヶ月経ちました。そこで、3ヶ月間で一体何が学べたのか、というところをまとめておこうと思います。約1ヶ月にもわたるつらーいPiscine（入学試験）を乗り越えた先に何が待ち受けているのか気になる方の参考になると幸いです。

ちなみに、プログラミング経験は大学のとき（非ITの理系学部）に授業、研究、趣味でMatlabとかC++、後Arduinoなんかを触ったことがある程度です。Web開発やコンピュータサイエンスについては全くやってませんでした。（詳しい自己紹介はまた書きます。）

コミット具合

3ヶ月間平均すると1日10時間以上42の課題に取り組んでいたと思います。フルコミットですね。ほぼ休みなくやっていました。

おかげで他の生徒の平均と比べると期間あたりの進捗具合は相当早いペースです。入学の直前くらいに仕事を辞め、時間はたっぷりあったので、42を存分に堪能することができました。（早く再就職したい。）

技術的にできるようになったこと

技術的な面とそれ以外の面での成長の2点を語りたいと思いますが、まずは技術的な面から。

C言語のおかげでコンピュータがどんなものか少しずつわかってきた

42のカリキュラムはC言語の標準関数ライブラリ（libc）の主要な関数の再実装からスタートします。使っていいのはread、write、malloc、freeのみです。かなり細かい仕様まで満たさないと合格はもらえないので、文字列操作、メモリ操作、型、ビット、n進数などの基礎をしっかり理解しないと前には進めません。

printfやatofを再実装したときには1週間くらい浮動小数点のことしか考えていませんでした。（その軌跡をQiitaにまとめたりしました。）

また、この後に、readやwriteなんかもアセンブリで再実装する課題があります。ここまでやると、CPUやメモリといった概念と直接触れ合い、なんとなくコンピュータというものを理解することができるようなってきた気がします。

たまに42のカリキュラムはC言語だけど需要あるの？という意見を聞きます。なんでC言語からスタートするかということを考えたとき、「コンピュータ」について理解を深める、という大きい目的のための手段に過ぎないことが、3ヶ月学習を続けたのちに腑に落ちました。（なお、他の言語もこの後の課題で学べます）

シェルの再実装によるさらなる理解

個人的に印象に残っているのは、シェルの再実装です。シェルの主要な機能（コマンドの実行、環境変数、パイプ、リダイレクトなど）をフルスクラッチで開発しました。（使用したのは基本的にシステムコールと上の自作ライブラリのみ）

初学者の敵（？）であるあの黒い画面を自分で実装したのはかなり自信がつきました。

文字列のパース、プロセス、プロセス間通信、ファイル入出力、シグナルハンドリング、システムコールなどのコンピュータ/プログラミングの幅広い知識がつきました。

ネットワーク/サーバー

ネットワークやサーバーに関する知識もつきました。

基礎的なネットワークの知識（OSIモデル、TCP/IPプロトコルなど）の知識を問う課題を終わらせたあとは、DockerでLEMP環境を構築する課題と、Kubernetesでマイクロサービス環境を構築する課題をこなしました。

IPアドレスってなんですか？な状態から、Kubernetesでマイクロサービス環境を立ち上げるところまで一通りこなすのは結構大変でしたが、実務で使われることの多いDockerやnginx、現在注目されているKubernetesなどの技術を身に着けることができました。（技術が身についたというと、各方面から怒られそうですが、少なくとも「ちんぷんかんぷん」という状態ではなくなったと思います。）

また、Dockerイメージに関してはalpine/debianのまっさらなイメージから各コンテナのDockerfileやentrypoint用のシェルスクリプトなどを書かないといけなかったので、純粋にLinuxについての知識（ユーザ管理やパーミッション、バージョン管理システムなどなど）も深まったと思います。

グラフィック

変わり種の課題としてはCのフルスクラッチでやるグラフィックの課題があります。簡単なレイトレーサの実装か、レイキャスティングによる3Dゲームの実装かを選び取り組みます。

私はレイトレーサを選択しました。基本図形の描画、光と反射の計算、カメラの回転など実装しなくてはいけません。ベクトルと三角関数の知識が必要になります。理系学部出身なのでこの辺の知識は問題ありませんでしたが、非理系の生徒も同じ課題をこなさなくてはいけないのはなかなか大変だと思います。

画像1

フルスクラッチで、リアルな画像を書き出せるというのは結構感動ですね。

技術的な面以外での成長

技術的な面以外での成長も結構あったと思います。42では講師、メンターの類がいないので、生徒同士のコミニュケーションで学びが成り立っています。ここから学ぶことはとても多かったです。

コードを理解する力、させる力

これに関しては、42の特徴の最たるものかもしれません。課題の評価は生徒同士で行うコードレビューで決定されます。

同じ課題でもやり方は人それぞれなので、都度相手のコードを理解する/させる必要があります。また、評価者の方がレベル（エンジニアとしてのレベルではなく、進捗状況）が低い場合もあるので、未知の課題を理解する/させる必要があります。これがとても勉強になります。

なんとなくで実装したコードだと説明がうまくできなくて、それで1度課題を落としてしまったこともあります。課題を提出する際はどういう風に説明すればいいかな、というのはとてもよく考えるようになりました。

ただ、このレビューですが、おざなりになってしまう方も多少います。この辺りは生徒一人一人の自覚が求められるところですが、個人的には少しでも互いの学びになるレビューになるように引き続き心がけて行きたいところです。

チーム開発

先ほど紹介したシェルの再実装についてはチーム開発課題でした。githubのプルリクエスト機能、issue機能などを用いて、タスクの分担、管理をしながら、互いのコードレビューをしてコードの質を高めていくという手法を取りました。githubの差分管理って便利ですね、、、非ITでも積極的に使えばいいのに、、、

42の標準のコード規約に加えて、さらに独自のコード規約を設定してみたり、コミットメッセージのルールを決めたり、わかりにくい処理には詳細にコメントを書いたりと、1人でやる課題ではできない学びが多くありました。

一方で、使うツールなどは違えど、進捗確認や打ち合わせの頻度、連絡のとり方など、ITエンジニアもそれ以外の仕事も重要なことはあまり変わらないのだなという気づきもありました。

今回は一緒に取り組んでいただいた方が、IT未経験ながら実装力もコミュニケーション能力も高い素晴らしい方だったので、スムーズに課題を進めることができました。ただし、コミュニケーションのとり方も人によって異なるかと思います。今後のチーム課題でもいろいろな方と取り組みながらいいコミニュケーションの取り方を学んでいきたいです。

何もわからないことに慣れた

42の課題は結構難しい（と私は感じる）のですが、課題のPDFには要件のみ書いてあって、やり方は全くと言っていいほど書いてないんですね。というわけで、自分で確認しなきゃいけない。

最初は何もわからなくて絶望することもしばしばなのですが、なんとかわかりそうなところの糸を手繰り寄せて、調べて、調べて、どうしてもわからなければ他の人に聞いて、ってやってなんとか解決します。

で、課題をクリアして、次の課題にいくとまた何もわからない。

これを繰り返していった結果、何もわからない、ということに慣れました。そして、何もわからないところから、「完全に理解した()」という状態への持って行き方が身につきました。公式DocでもQiita記事でもなんでも調べてコードを書いてみる。情報が全然なければ関連情報を集めてなんとかつなぎ合わせてみる、といったことが割と早くできるようになってきた気がします。

またすぐに、何もわからなくて絶望するだろうけど、大丈夫という自負。これは強いです。

最後に

この他にも42で学んだことやいいなと思うことはあるのですが、話がそれてしまいそうなのでこのくらいにしておこうと思います。

最初から最後まで完全に無料なので気になる方は是非入学試験を受けてみましょう。

元々違う分野のエンジニアでしたが、この分野は面白いですね！完全にハマってしまいました。少し遅咲きかもしれませんが、社会にいい価値を提供できるエンジニアになれるよう今後も頑張りたいと思います！

この記事が気に入ったらサポートをしてみませんか？