1ヶ月でバイトをやめた話

3月後半から4月の約1ヶ月あるIT系の会社でアルバイトをしていました。
ただ、途中でいろいろ察して辞めました。
その時オフィスで何が起こっていたか、それを時系列順で書いていこうと思います。 まだ、現場でそこまで働いたことがないので甘ったれた行動のように映るかもしれないので先に謝っておきます。

アルバイト入社前(面接編)

Web関連の仕事ができる企業をWantedlyなどを利用して検索。
見学に行ってみないとわからないことも多いと思ってとりあえずある会社に行ってみることに。
その会社はゲーム、Webなど幅広くやってる会社と書いてあったので、いろいろなことを学べると思っていました。

いざスキルシートと履歴書を持ってオフィスに行くと、ホテルの一室のような場所で数人が作業しているオフィスに通されました。
面接で聞かれたことは「Unityできる？」くらいですぐ明日からでも来て欲しいと言われました。
その時は速採用がうれしくて見逃してましたが、社員さんは目を合わせてくれず、Web系の仕事がしたいのにUnityのことしか聞かれなかったことをよく考えておくべきでした。

アルバイト入社後(1日目編)

アルバイト入社1日目に作業環境を教えてもらいました。

• OS : mac
• バージョン管理 : SourceTree + gitlab
• ツール : Unity2017
• 連絡 : chatwork + slack

また、そこでなぜかWeb系の仕事ができると思っていたのにゲームの方の仕事をするよう言われました。
現在取り組んでいるゲームの案件の進捗が芳しくないかららしいです。
その案件の内容は、既に他社がリリースしているアプリのアップデート+改修作業でした。
1日目はどんなアプリなのかの簡単な説明と環境構築で終わりました。
まだこの時は綿密な計画の元タスク表通りに作業が進んでいくだろう、という会社への幻想を抱いて安心していました。

作業開始(2日目編)

2日目は作業内容の説明を受ける予定でした。 僕が少なくとも欲しかったのは

• ゲーム画面の遷移図
• チームのコーディング規約
• クラスごとの役割が簡単にでも説明されているクラス図orコメント
• gitlabをチームでどう使っているのか
• 作業内容のドキュメント
• etc

【ゲーム画面の遷移図】
改修前の遷移図はあるものの、回収後の目標の遷移図は存在せず先輩も把握していない模様。
先輩曰く、「依頼元が作ってないんだからこっちは悪くないって言える」
いや、わかんなかったら聞いて作るなりしろよ( ｀ー´)ノ
これが後に「依頼元との認識の齟齬」を作り出しました。

【チームのコーディング規約】
ありませんでした( ;∀;)
Camel case も Pascal caseもバラバラ。
ラムダ式がたくさん使われているのに、チームのほとんどの人が理解できていない。
助けて…

【クラスごとの役割が簡単にでも説明されているクラス図orコメント】
まず、コメントはほとんどありませんでした。
また、機能ごとにパッケージ化等全くされておらず各クラス間が相互に参照しあっていた。
結果として、あるクラスの一部を変えると他の数十個の関係あるのか無いのか分からないクラスがエラー。
ほぼ全ての変数がpublicで宣言されているのを見たときはゾッとしました。
あっ、もちろんクラス図等の説明は全くありませんでした。

【gitlabをチームでどう使っているのか】
プルリクを出す際にどういった情報を記述すればいいか。
TODOやFIXMEやドキュメンテーションコメントでの説明でいいのか。
それに対する答えは
先輩「とりあえずできたらマージしといて」
僕「えっ、そうしたらgitをチームで使ってる意味あんまり無くないですか」
先輩「いいから、いい感じにやっといて」
僕「はい……(涙)」

【作業内容のドキュメント】
もうお察しだと思いますが、「あれをいい感じに直しといて」「あの機能をいい感じに追加しておいて」しか言われません。
仕様書のようなものは作らないのですか、と言うと笑いながら「今どきの開発でそんなの作るところないよww」
いやいや、作るでしょ。適当じゃねーか！

作業開始(3日目～1週間編)

2日目にいろいろ絶望しましたが、3日目になるともう作業が割り振られました。
先輩「このバグを直して」
僕「現状どの部分に問題が出ているかわかりますか？」
先輩「分からないけど、うまく動かないから直して」
僕「この問題が起きてるデータはどこにパッケージングされていますか？」
先輩「とりあえず、ブレークポイントはって試してみて」
僕「はい……(涙)」

そこからの僕はひたすらアクティビティ図を書きまくりました。
自分の作業内容とは関係ないところまで含めて、ゲーム全体の流れを掴むためにほぼすべてのコードを読んで。
1週間進捗はほとんど上げられませんでしたが、最初に僕が欲しかった情報はほぼすべて集めることができました。
その間に先輩が状況を悪化させているとは知らずに…。

作業中盤(2週間目～3週間目編)

ここにきて僕も全体の流れを理解できたこともあって進捗をあげられるようになってきました。
久しぶりにdevelopブランチをプルしてみたら大変なことになっていました。
なんと、プルリクが一度もされずに先輩たちは皆自分のブランチをdevelopにマージしまくっていたのです。
なんで皆作業しているのに全く進捗(プルリク)出さないんだろうと思っていたら…。
案の上、どのコミットに遡っていってもエラー残っているし、大量にグローバル変数や存在意義のないクラスが増えていました。
ある先輩にコードやgitの使い方のことで軽くそのことを指摘すると、
「俺は本来プランナーだからそういうのは向いてないんだよね。これがこの会社のやり方だよ」
と言われ察しました。
ここからは自分の進捗だけ挙げて、それにかかわらない部分については無視しようと決めました。

作業終盤(3週間目～最終日まで編)

ぼくは既に自分の中でゲームの流れやクラスの役割を確認していたので、かなりの進捗をあげられるようになっていました。
この時にはデバッグリストを依頼元が作成してそれを消化する段階に入っていました。
先輩たちは自分で作った大量のフラグや不吉なにおいのする関数や変数に悩まされて作業が止まったり、それによる体調不良で欠席したりしていました。
一方僕は1日当たり先輩たちの2～3倍のタスクを消化していました。
そして僕が担当できるタスクが無くなって先輩の作業を手伝おうとしたとき、それを嫌がった先輩からすごいことを言われました。

private int Method() {
    // メソッドの内容
}

を

private int Method()
{
    // メソッドの内容
}

に変えろと言われたのです。今更。
彼曰く、「君の書き方は好きじゃない」そうです。
これには僕も頭が痛くなってきたので、とうとう社長に個人チャットで辞める意思を伝えました。

最終日(社長と面談編)

社長1対1で僕が思っていたことを話しました。上に書いたこと以外にもたくさん。
改善するように体制を変えてみるとは言っていましたが、その後リリースされたゲームの評価を見る限り改善はされていないようです。
バグが残ったまま、起動すらできず、かなり重くなったゲームがリリースされていました。
今後どうなるんでしょうね。

振り返ってみて

僕が1ヶ月働いた会社はまずい点がいくつもありました。

• 働いた時間を自己申告できる(正社員、アルバイト問わず)
• ずっと仕事の文句を言っている
• いない人の文句を言って相対的に自己の評価を上げようとしてる
• よく休む or 遅刻する人が多い
• 人と話すのが苦手だから話さないorごまかす人が多い
• オフィス内のメンバーの交流を図らない
• 優先順位のつけ方が間違っている
• オフィスが途中から臭くなった
• 試しもせずにダメだと思い込む
• 人の話を聞かない

逆に学んだことは

• リーダブルコーディングの重要性
• 人間関係が仕事に与える効果
• リーダーの役割
• 作業環境の充実度の仕事への影響

良くも悪くも、いろいろ経験できた密度の濃い1ヶ月でした(心労)