開発に転生したら未経験は俺だけだった件 2話「Tug Your God Out」

 # はじめに
**この記事は　[1話「goodbye halcyon days.」](https://qiita.com/saitoooooooo/items/31baa23c21453c9771ec) の続きです。**
弊社の研修内容と、そこで得た経験を備忘録的に書いていきます。

# 入社~研修開始

「うお～ほんとに来たｗ」

入社初日、私を雇った張本人のグループ長から出た言葉です。
彼はそのあとすぐ退社してしまったので本意を推し量ることは難しいのですが、
おそらく彼なりに未経験者を雇ったことへの不安があったのでしょう。

一方そのころ
私は呑気に社用PCセットアップやアカウントの準備、開発環境の構築を行っていました。
入社を後押ししてくれたY氏と雑談しながら、営業部署の雰囲気と違いすぎる雰囲気を心地よく感じ
穏やかな空気のなか束の間の平穏を味わっていました。

その後、激動の三か月が来ることも知らずに・・・

# 研修のはじまり
## 研修について
弊社の研修は以下の4ステップに分けて行われています。
基本的にはPythonでの開発がメインなので以下の研修は全てPythonで行っています。

1. AtCoderっぽい問題で、動くものを作ろう(Pythonのチュートリアル)
2. AtCoderっぽい問題で、簡単な設計とテストを学ぼう(簡単な設計とテスト)
3. 図書館システムを作ってオブジェクト指向を学ぼう(中規模のOOP設計開発)
4. 自動販売機を要件定義からテスト駆動開発で作ってみよう(要件定義、仕様作成、TDD)


と、順を追って開発部で求められる能力を養うことが出来るカリキュラムになっています。

研修中はメンターが付き、主なやり取りはgithub上で行われます。
実際の開発工程に沿って研修を進めるため、各研修では以下のようなフローで行っていきます。

メンターから課題(issue)が与えられる
↓
issueで実装方針を相談
↓

PR
↓↑
レビュー

↓
マージ

__さて、この説明は研修開始時に私が受けた説明を要約したものになりますが、
未経験者の私がつまずいたポイントが既に大量にあります。__

- Git?
- issue?
- PR?
- 仕様って？
- 要件って？
- 設計？
- テスト？
- TDD？

もちろん言葉の意味から類推したり、書籍で読んでなんとなく知っていることも多くありました。
が、実際に「それをやれ」と言われれば何をすればいいのか分からない 程度には何も知りませんでした。

開発部に中途入社する人間にこれらの言葉を説明できないことは本来ありえないので、部のメンバーからは
「ヤバい奴が来た」と思われていた事でしょう。
（他のメンバーからは、Y氏が連れてきたこともあり、Y氏の愛人だと思われていたことも後ほど明らかになりました。)

明らかにステップ１を上ることが出来ない貧弱な脚で研修に挑んだ私の足跡を追っていきましょう。


## ステップ① AtCoderっぽい問題で動くものを作ろう
[Atcoder Beginner Contest](https://kenkoooo.com/atcoder/#/table/) のB問題程度の難易度の問題です。
ちなみに私はこの入社前にこのレベルの問題を100問ほど解いてからこの研修を受けています。
そうして生まれたPRのConversation数
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2748021/1db9524a-344f-34e6-bc07-5b0e1a0c9d8d.png)
__見たことがありますか？__

少なくとも私はPRでこの物量は実務で見たことが無いです。
ちなみにこれ以上大きくなるとこいつが出てきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2748021/298624a6-2323-52d8-51af-48e5a5261c8c.png)

こいつは普段Githubが落ちてる時しか表示されないので
「いつでもgithubユニコーンが見たいよ～」って方はクッソ重いPRを作るとよいでしょう。

指摘の内容はそのほとんどが命名に対するものです。
事前に『リーダブルコード』を読みましたが、実際に書いた経験が無いとアウトプットに結びつかない。
エンジニアであれば __普通こう命名する__ の __普通__ が分からない。
コーディング規約の意図が分からない。

ListやTupleは複数形で命名する。
システムハンガリアンは避ける。
関数は動詞、classや変数は名詞。

こんな基本的なことから丁寧に説明してもらいました。

## ステップ② AtCoderっぽい問題で簡単な設計とテストを学ぼう

Pytestの使い方をレクチャーしてもらい、ステップ①で書いたコードを適切な粒度の関数に切り分けながらテストを書いていきます。

ここではテストカバレッジについての指摘や、
やはり命名についての指摘が多くありました。

弊社のテスト命名規則は

`def Test_{結果}_{条件}`

ですが、英文で言語化することに苦戦した記憶です。(いまだに苦手意識が強い)

ここも小さいmoduleを５つ分テスト書くだけだったんですけど
レビューで200conversationくらいやり取りしてました。

主に
- テストカバレッジの話
- 様々なテスト手法の話

他には

「まずは日本語で関数の動作を説明できるようにしろ」
「テストも条件と結果をまずは日本語で説明できるようにしよう」
「日本語で説明できるようになってから伝わる英語を探せ」
「頼むから日本語で説明(略」

ってな感じの指摘を大量に貰っていて
徐々に自分の言語能力に自信を失っていたのを覚えています。

（今見返すとメンターの胃に穴空いてもおかしくなかったなって思います）

## ステップ③ 図書館のシステムを作ってオブジェクト指向を学ぼう
ここから、本格的にオブジェクト指向型プログラミング(以下: OOP)に触れていくことになります。
実質今回の研修のメインコンテンツがこいつです。

簡単に内容を説明すると
__本が10万冊ある図書館で本の貸し出しと返却、予約機能がある図書館用のシステムを作る__
というちょっとめんどくさいかなくらいの難易度のものです。

そこで初学者の私が初めに考えた設計はこんな感じでした


__10万冊分__ の本のIDを生成
__10万人分__ のユーザIDを生成
それを本棚にある本、貸し出し中の本、予約されている本に分けて
それぞれ10万のdict内でユーザーIDと管理してくというものでした。

当然ですがメモリリークして動かないです。

ここら辺から私の脳内でもメモリリークが起こっていてその後にメンターと話して
再設計した図書館システムは要件を満たせないものになっていました。

新しい知識の洪水に頭が真っ白になっていて、正常な思考が出来ない状態になっていました。

そこで私を救ってくれたのがこの本とメンター達です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2748021/883455ef-d624-91d3-f190-7f50745ef883.png)

『オブジェクト指向でなぜつくるのか』

__この手詰まりに近い状況(研修者の脳がストップ、メンターのストレスマッハ)__ を打破するため
丸二日かけて、この本の読み合わせを慣行することにしました。

メンター陣二人と1ページ1ページ解説付きで読み合わせを進めていきます。
普段めったに残業しない方たちでしたが、この二日間は22時まで残業して研修に付き合ってくれました。

その甲斐あってか、その後はそれなりの設計になって
二週間程度でテストの完成までこぎつけました。

この段階で当初予定されていた40営業日の研修期間が終了し、
+10営業日の延長戦に突入します。


## ステップ④ 自動販売機を要件定義からテスト駆動開発で作ってみよう
ここでは要件定義、設計、TDDについて自動販売機開発を通して学んでいきます。

以下の手順で進めていきます。

1. 自動販売機に必要な要件を洗い出し、メンターと共有
2. 設計する
3. TDDなのでRedのテストを書く
4. RedをGreenにしていく(気持ちがいい)

要件定義については研修者各々が定めていいことになっていました。
私が考えた自動販売機に必要な機能は以下の通りです。

- コインを受け取る
- 受け取った金額が一定以上になったらドリンクが購入可能になる
- 購入されたドリンク名を標準出力
- お釣りを吐き出す

上記のフローに加えて、
自販機内のドリンク在庫が無い時と釣り切れ時にドリンクが購入不可能になる分岐を入れました。

Coinクラス、Drinkクラスを作ることは問題を出されたときに決まっていたため、
そこにVenderクラスを追加し、必要な機能をその中に実装していきました。

ここで大きく躓きます。
釣り切れの実装が予想以上に難しかったのです。

Venderクラスでは、
- 自販機内のCoin枚数
- 自販機内のDrink数

を管理する必要があり、投入された金額によって大きい順にお釣りを払い出す必要があります。

この部分のロジックがどうしても複雑化してしまい、
ドリンクの購入可否を判定する関数との結合度が高まってしまいました。
その結果可読性が損なわれ、動作する頃には保守困難なスパゲッティコードが出来上がりました。

今となってはvenderクラスの責任過剰が原因だとすぐわかりますが、当時は研修の終わりが近いこともあり、設計変更する工数を取ることよりも、「早く終わりたい」という感情が先走りそのままPRを出しました。

この時のメンターのでかいタメ息が忘れられません。
書籍の読み合わせ時のフィードバックや、OOPに関する理解度を都度質問されおり、
その際の回答がそれなりに的を得ていたことも有り、まさか __読めないコード__ が提出されるとは思ってもいなかったでしょう。


## その後
研修期間が50営業日に迫っていたことも有り、メンターと一緒に再設計を行い
それを基に再度TDDを行うといった具合に駆け足で研修を無理やり終了させました。

業務に入ってからも、メンター陣に常にライブコーディングで書いているコードを公開しながら
簡単な保守作業を行っていました。

1か月も経つと簡単な保守はある程度一人でできるようになり、
開発タスクももらえるようになりました。

そんな感じでちまちま開発を3か月ほど続けていたある日、
グループ長からこんなことを言われます。

__「PjMやってみませんか？」__


## 次回予告
次回、涼宮ハルヒの憂鬱、第五話
違う。次回、涼宮ハルヒの憂鬱、第十三話
『涼宮ハルヒの憂鬱Ⅴ』
来週は超能力が凄いんだって？
テレビの前にスプーンを用意して下さい
ではいきますよ
マッガーレ
凄っ！