文系新卒Bizdevが42にハーフコミットしてみた
ここはどこ、私は誰？
こんにちは。 私は42Tokyoに通っている、いたって普通の文系新卒Bizdevです。このたび、「minishell」という課題をなんとかクリアしたので、この半年間を振り返ってみたいと思います。
『42Tokyoに通っている、いたって普通の文系新卒Bizdev』
「つまり誰だよ？」と言われそうなので、もう少し詳しく自己紹介してみます。
私は元々地方出身で、関西の大学に進学しました。その後、IT系の企業に24卒としてなんとか入社し（就職活動で内定をもらえたのは唯一ここだけでした！）、現在はB2CのサービスのPdM（プロダクトマネージャー）として日々奮闘しています。
もともと文系科目が得意で、大学では主に経営学を専攻していました。プログラミングについては、会計学や金融学の科目は履修していたものの、全く馴染みがありませんでした。ちなみに、実家は八百屋です。（本当にどうでもいい情報ですが）
ここで、42Tokyoについても軽く紹介しておきます。
42Tokyoは、学費が無料で教師がいないプログラミングスクールです。42の最も特徴的な点は、教師が不在であり、学生自身が与えられる課題を解決しながら学びを進めていくスタイルです。
課題を解けば解くほどレベルが上がり、次の課題に取り組めるようになるという、いわば「くもん式」のようなゲーミフィケーションが施されています。カリキュラムは非常に実践的で、問題解決能力や自律的な学習姿勢が求められます。
42Tokyoの学習環境は、学生同士の相互協力を大切にしており、ピア・ツー・ピアのレビューも特徴的です。そのため、コミュニケーションスキルも自然と磨かれます。私自身も、42Tokyoの友達の力を借りて、なんとか課題に取り組むことができました。
このnoteについては、自分自身がフルタイムで非エンジニアとして働いている中で、社会人として42と関わるモデルケースの1つとして見てもらえればと思います。42でフルコミットされている方は多いですが、逆にハーフコミットしている方の記事は少ないと感じており、こんな関わり方もあるよ！と参考にしてもらえれば幸いです。
こんなところで身の上話と42については終わりにして、これまで自分が42でどんなことをやってきたかを振り返ってみたいと思います
約半年の整理と棚卸し
ここからは、実際に42Tokyoでやってきたことを振り返ってみたいと思います。試験や課題の詳細については他の記事で触れられていると思うので、ここでは概要と自分が気づいたことをつれづれなるままに書いていきます。
そもそも自分が42Tokyoに入学したきっかけは、DMM.comの創業者である亀山会長のツイートでした。（亀山会長のツイート）調べていくうちに、42に出資していただいていることを知り、本当に頭が上がらないなぁと思っています。
42の入学式で亀山会長が42を設立した理由を聞いて個人的にはウケました。知りたい方は42で亀山会長がいるときに聞くと良いと思います。
それまでは42について全く知らなかったのですが、直感的に面白そうだと思い、以前に挫折したことのあるプログラミングにもう一度チャレンジしたいという気持ちが芽生えました。
そして、その一ヶ月後には一次試験を受けていました。本来はこんなにコミットするつもりはなかったのですが、人生は予測できないものだとこのnoteを書きながら改めて感じています。ありがとう、亀山会長〜〜！！！！！
Piscine
Piscineはフランス語で「プール」を意味し、42では4週間にわたる集中的な2次試験を指します。4週間何をするのかというと、それは受けてみてのお楽しみです。
ちなみに、文系新卒Bizdevと言った手前恐縮ですが、実は私は大学生最後の春休みを使ってPiscineに挑戦しました。この期間はフルコミットで毎日10〜12時間ほど校舎に滞在して学習に取り組みました。
Piscineに参加して良かったことは、普段出会うことがないようなさまざまなバックグラウンドを持つ人たちと、一つの目標に向かって共に努力することができた点です。
初めて東大の学生と話して彼らの頭の良さに驚いたり、大学を2回も留年して一発逆転を狙っている同い年の友達ができたり、研究所で働きながら開発をさらに学ぶために来た社会人の方と話したりしました。
これまで自分が属してきたコミュニティにはいなかったような人々との交流は、以降のキャリアの考え方を大きく変えるきっかけになりました。
Rank00
「libft」
42Tokyoに入学して初めての課題は、「Libft」でした。これは標準Cライブラリの一部を再実装して、静的ライブラリにする課題です。callocやatoiなど、各関数が自分が予期していなかった挙動を持っていて、当時は非常に戸惑いましたが、今振り返るとここでしっかり実装しておいてよかったと感じます。特に後の課題で大いに役立ちました。
ただし、strlen関数、お前は駄目だ。
（本家と同じ実装だとクラッシュしてしまうので、strlcatなどの利用先で対策が必要でした）
プライベートな話になりますが、「Libft」に取り組んでいた時期には、フルタイムで働いている会社の研修も終えて既に現場に配属されていました。42の学習と仕事の両立は、インプットが爆発しそうで非常に大変でしたが、平日夜と土日を中心に42の課題に取り組むようにしていました。
課題自体は関数を一つずつ作成していくだけなので、特に悩むことなく進められましたが、やはり仕事終わりに集中して取り組むのはなかなかの挑戦でした。
Rank 01
次のランクでは、3つの課題に取り組みました。先にプライベートな話をしておくと、GWを全て42に注ぐことでRank 01の課題全てをスピーディに提出することができました。
社会人として42に取り組む場合、いかに休日や祝日に42の時間を確保できるかが重要だと痛感しました。
特に始めの時期は全員が一斉に課題に取り掛かるので、同じ時間間隔で課題に取り組むほうが情報のキャッチアップや精神面でも楽です。
「printf」
C言語で初めにお世話になった人も多いであろう、printf関数の再実装を行いました。可変長引数を使用することで、実際のprintfのようにさまざまな引数に対応したft_printfを作成することができました。
この課題自体は標準出力にしかprintしませんが、後のminishellでも有効活用できるため、各関数で出力先を1と固定せず、ファイルディスクリプタ(fd)を持たせておき、複数のfdに対応できるようにしておくことをお勧めします。
この課題に関しては、YouTubeでの解説や豊富なドキュメントがあったおかげで、そこまで時間がかからずに実装することができました。
「get_next_line」
ファイルや標準入力から改行（もしくはEOFまで）を読み取って一行ずつ返す関数を作成しました。自分は、既存のgetc関数を再実装して、改行まで1文字ずつ取得していくアプローチを取りました。
メモリリークがどうしても解決できず四苦八苦しましたが、同じPiscineを受けていた同期に助けてもらい、非常に助かりました。
改行まで1文字ずつ取得していくアプローチをしたほうが、あとから「minishell」で簡単にHeredocを実装できるのでオススメです。
「born2beroot」
バーチャルマシンを用いて仮想環境（Debian）を構築する課題です。課題で指定された各種要件に沿って実際に設定していきました。正直先輩方が残していただいていた資料を参考に進めたので、とても助かりました。
レビューを受ける前にはできる限り準備しましたが、例えばcronを削除せずに止める方法がわからないなど、レビューは非常に難しかったです。
Rank 02
Rank 02では、次の4つの課題に取り組みました。ここからは一つ一つの課題が重たくなり、同期の学生でも進捗に差が生まれ始めました。この時期、私が心がけていたのは「インクリメンタルな開発」です。
インクリメンタルとは「漸進的」という意味で、インクリメンタルな開発とは、短い期間（イテレーション）ごとに機能的な部分を完成させ、積み重ねていくアプローチです。
つまり、小さく動くものを作ることで効果的な開発をする方法です。大きな修正を避け、小さな修正を繰り返していくことで、仕事と学習の両立ができました。
「push swap」
コマンドライン引数に与えられた数字列を、課題で指定されたシャッフル方法のみで昇順に整列させ、できるだけ少ない手数で出力する課題です。私はオーソドックスにクイックソートを選びましたが、再帰関数が苦手で、徹夜で取り組みなんとか完成させました。
解き終わったときの解放感は今でも覚えています。そしてその日、スキップして家に帰りました。自分は96点しか取れませんでしたが、周りは普通に100点を取っていて、かなり自信をなくした課題でもあります。
「fract'ol」
minilibxという42が開発したグラフィックライブラリを用いて、フラクタル図形を描写するプログラムを実装しました。フラクタル図形とは、全体の構造が、小さなスケールでも同様に繰り返される「自己相似性」を持つ図形のことです。具体的には、マンデルブロ集合とジュリア集合を描写しました。
フラクタル図形の描写には複素数という文系には全く馴染みのない概念が深く関わっており、正直他の課題に逃げようかと思いましたが、理系の同期から少しずつ教えてもらいながら進めることができました。
すげーキレイにできたんで良かったです。
「exam02」
42で一番大苦戦した課題はこれでした。3回も落第しました。Rank 02以降に進むと実際の試験形式の課題もあります。exam02ではランダムに問題が出されるのですが、ビット演算や連結リストの問題に大苦戦しました。
しかし、これらの問題の解法が後に、「minitalk」と「minishell」の課題で非常に役立つことになりました。
42のいやらしいところは、やるかやらないかを自分で決められる問題がいくつかある点で、後からやっておけばよかったと思うような問題が多いところです。難しくても何にでもチャレンジすることをおすすめします。絶対に次の課題で役に立ちます。
「minitalk」
シグナルを用いて、クライアントからサーバーに文字列を送信するプログラムを作成しました。シグナルの実装自体はそれほど難しくはなかったのですが、クライアントからサーバーにはSIGUSR1とSIGUSR2の2種類しか送信できないため、各文字を1byteの情報と捉え、1bitずつ送信する形にしました。
あるプロセスのクライアントから、異なるプロセスのサーバーに文字列を送受信する方法を実践的に学ぶことができました。
Rank03
「minishell」
直近最後に取り組んだ課題は「minishell」というbashの再実装でした。字句解析から構文解析、パイプ、リダイレクト、シグナル、ビルトインコマンドまで、bashの頭から尻尾までを再実装するというこの課題は、想像を超えて大変で、本当に泣きそうになりながら2ヶ月ほど取り組みました。
この課題はペア課題で、同期の友人と取り組みました。彼はフルコミットだったのですが、自分が仕事をしている間もbashの挙動を調べてくれるだけでなく、深夜からのペアプロを快諾してくれたりと、フルタイムの自分をサポートしながら進めていただきました。彼がいなければ、クオリティの高いプログラムを2ヶ月で提出することは間違いなく不可能だったので、感謝の念が絶えません。
自分自身が工夫した点としては、チーム開発にスクラムの概念を取り入れたことです。この課題に取り組む多くのチームでは、それぞれの領域を決めて後から組み合わせる進め方が多いのですが、自分たちは毎日デイリーで夕会を行い、「minishell」の核となる字句解析から構文解析までをペアプログラミングで実装するなど、一緒に進めていくことで手戻りを少なくし、インクリメンタルな開発を推進することができました。
また友人も、単にbashの挙動を真似するのではなく「なぜbashはこの挙動になるのか」を深く考えて実装していました。、特に構文解析の部分は実際のbashのソースコードも読んで設計思想に仮説を立てながら実装していったので、後から致命的なエラーや矛盾が発生することなく壊れにくいプログラムを実装することができました。
ペア課題では、相手と常にコミュニケーションを取りながら進めるので、一人で進めるよりもストレスは大きい部分もあります。しかし今振り返ってみると、深い理解を得ることができましたし、共に苦労し成功をお祝いできるすごい良い取り組みだったなぁと思います。
どんな学びがあったのか
Bizdev的な観点でいうと、プロダクト仕様を考える際の思考が非常に深まったと感じています。その理由は、42の課題では、プログラムが想定外の入力や挙動に直面してもクラッシュしないようにエラー処理を施す必要があるからです。プロダクトの仕様を考える際には、ユーザーが必ずしも正しい入力をしてくれるわけではないことを、想定する必要があります（来れが難しい）。42のカリキュラムは、そのような思考の土台となりましたし、この半年間で自分の成長を実感しています。
また、学びとして大きかったのは、「なぜ作るのか」と「どうやって作るのか」を絶えず考え続けることがすごい難しいことを理解したことです。これにより、Bizedevとしての視点が大いに広がりました。特に、「なぜ〇〇を作るのか」を言語化し、それを自分で開発に落とし込む能力は非常に貴重だと感じましたし、エンジニアとコミュニケーションを取りながら、要件を伝えていく力は間違いなく成長しました。
言われた要件を実装することと、要件そのものを作り出すことは全く異なります。この差を仕事と42の反復横跳びしていて、すごく感じました。なぜこの機能はほしいのか、機能の価値を深く考えていくのに対し、要件を実装する際には、どうやったら一番スマートか、綺麗で手戻りなく壊れにくいプロダクトになるか考えます。結論、どちらも大事な考え方だと思うのですが、だからこそプロダクトを作るうえでPdMと開発者で溝ができてしまいがちなんだろうなぁとは思いました。
そして、42の課題設計がいかに優れているかを実感しています。なぜかというと、課題が進むにつれ要件は曖昧になっていくからです。要件をどのように定義するかは学生に委ねられており、自分はこの要件どういうふうに捉えたのか、なぜこの実装にしたのかをレビューで説明していきます。この課題設計のお陰で、「なぜ作るのか」と「どうやって作るのか」を相互に深めながら実装することができます。
さらに、チーム課題に取り組むことで、自分が動くことと他人を動かすことの違いにも気づかされました。ただ実装すればいいのではなく、どうすればより密なコミュニケーションを取れるか、相手が理解しやすいコードは何なのか、どうすればコンフリクトを起こさずプログラムを合体していけるのか、プロダクトを生み出すためには、コーディングだけでなく、それ以外の知恵が必要だなと痛感しました。
これからも、Rankの高い課題ではチームでの取り組みが増えていきます。「minishell」の反省点を活かしながら、次のチーム課題にも取り組んでいけたらいいな、と思っています。なにより、やっぱり42の課題設計は素晴らしいなーと思います。
これからの42
これからの自分の42の進め方としては、引き続き寄り道せずにC、C++の課題を進めていこうと思います。今後、業務領域も広がり仕事も忙しくなっていくため、これまでのようにコミットできるかは不明ですが、それでも頑張ってやり抜きたいですね（できるできないではなく、やります）。
また、課題以外の活動としては、自分自身が業務としてスクラムマスターの職能を深めていることもあって、スクラムに関してできることがあれば42に還元していきたいと考えています。そして、スクラムの輪を42に広げていければ凄く面白いなーと思っています。
直近の夢は。コモンコアが終えて42の仲間と週末に面白いプロダクトを開発・リリースすることです。現在その仲間を大募集中です。
P.S
42には、42の学生だけが行くことができるForty2というリゾート施設があります。9月に遅めの夏休みを取って、フランスに行くことにしました。楽しみです〜！
この記事が気に入ったらサポートをしてみませんか？