ホワイト500とは、「貴方の会社は健康的に働けていますね！」という経済産業省のお墨付きである健康経営優良法人2020のうち、大型法人の上位500位に認定された会社のことを言います。
つまり、国が認めた大手のホワイト企業という意味です。（てきとう）
世界は不条理で、エロゲタペストリーを部屋にべたべた飾るようなキモオタでも、何かの間違いでホワイト500に就職してしまったりします。
しかし、社会人2年目オタク、タイトルの通りホワイト500正社員でありながら非人道的な労働にブチ当たったので、起きたこと体験したことを反省も交えながら書いていこうと思います。
システムエンジニアっぽい内容に触れることがありますが、そこは普通の人にも分かりやすいように多少砕いた表現を使っていきます。あとなんとな～くボヤかして説明している部分もありますが許して
直近2か月の状況
2月に100時間、3月は130時間残業しました。社畜ちゃんも真っ青。
2月からほぼ毎週休日出勤しており、3月に至っては2連休すら無し。
2月は終電には乗れていたので良かったほうで、3月は終電後にタクシーで1万円かけて帰宅、酷い時は始発で家に帰って着替えたら即出勤。徹夜、24hぶっ続けが何度かありました。
健康状態は意外と問題がなく、多少腕がしびれたり目の前がチカチカしたりする程度でした。熱出たりもない。ご飯が毎日コンビニ飯だったので栄養面が心配だったかな。
体重は59kg→56kgに落ちた。いいダイエットですね。
帰宅してもシャワー浴びて寝る以外にする時間がないので、PCがガチの文鎮になっていました。せっかくモンスターハンターワールド：アイスボーン買ったのにまともに遊べないままモチベ消滅してしまった。
趣味に充てる時間がゼロどころか趣味が消滅しました。
仕事の内容
よくあるシステムリプレース作業。（古いシステムを新しいシステムに交換すること）
ウチはその中でデータの引越しをするためのプログラム開発を担当しました。
受注額はだいたい5000万円で、開発要員は3人。（これ俺が新米だからよく分かってないだけかもしれないけど、50m規模の案件で3人って普通なのかな？）
期間はだいたい1年間です。
なんでこんなことに？
新米ながら、ここがマズかったんじゃねえかなって点を挙げていきます。
1. 設計書の形骸化
プログラムを作る上ではまず設計書が必要になりますが、この設計書がゴミと化してしまったのが問題のひとつだと思った。
まぁ設計書のベース作ったの俺なんですけどね。
設計当初はプログラムを作る上で必要な事柄をキチンと整理・記載できていたので、初めのうちはよかったんですよ。
問題なのは、後々仕様変更による設計書の書き換えが多発したこと。
俺が作った設計書、初めのうちは良かったけど、仕様変更部分を記載するためにフォーマットが中途半端に変更になったり、文章をゴチャゴチャ書くハメになったりなどして、要は最終的に読みにくい分かりにくい設計書になってしまった。
イチから設計するということは人生で初めての経験だったので、ここまで仕様変更があることが想定できなかった。そのせいで基幹となる設計書がゴミになり、プログラムにしょーもないバグを潜ませる一因になってしまった。
設計書は上司のレビューを通したものなので俺が100%悪いとは言えないけど、可読性とメンテナンス性を考慮できなかったのは反省すべき点だと思っています。
2. 単体テストが適当
仕事で扱うプログラムってのは、基本1つじゃなくて複数個を組み合わせて動かします。なので、まずは全部組み合わせる前に、それぞれのプログラムがちゃんと動くかどうか、1つずつテストをするわけです。
そのテスト、3人で分担してやったんですけど、全員の意思疎通が取れておらず、全員がバラバラのテストケースを使ってテストしてたんですよね・・・。
Aさんはプログラムαのテストのためにテストケースを4種類用意、Bさんはプログラムαと同等のプログラムβのためにテストケースを128種用意するなど、同じプログラムにも関わらずテストする内容が統一できていなかったのです。
AさんとBさんがテストしてる間、俺は別作業を担当してたので、後からテスト作業に合流したんだけど、その時に上記に気づいて「ナンジャコリャ！」って思ったんすよね。
でもテストもだいぶ進んでて、今更覆すのも期限的にマズいよなぁ・・・ってことでAさんBさんのテストケースを模倣しながらしこしこテストしました。
そんなんだから結合テスト（全部のプログラム組み合わせてテストする）の時に単体テストレベルのバグが起きて、無駄に残業するハメになったりするワケです。
これは身をもって体験したので言える。単体テストで妥協は絶許。額縁に飾って反省します。
3. 属人化
防ごう！属人化！
社畜ちゃん漫画の120話、121話です！٩( 'ω' )و
— ビタワン🐕脱サラちゃん&社畜ちゃん連載中 (@vitaone_) 2017年3月19日
今回はいわゆる「属人化」のお話。
・自分の代わりが居ない職場
・自分の代わりが居る職場
皆さんはどっちで働きたいですか？ pic.twitter.com/5GR6Rj89YS
つまりそういうことです。
今回作ったプログラム、大きく2種類に分けられ、それぞれソードとシールドとします。（オタクに分かりやすい親切な説明）
俺はソードをメインに、Aさんはシールドをメインに作成。Bさんはソードとシールド両方を均等に補助し、どちらもある程度分かるという状態。
この頃は良かったんですよね。
リリース3か月前にBさんが退場しました。
で、新しく2人入って来ました。こうなります。
属人化の何がヤバいって、休めないんですよね。
俺がここで体調崩して潰れたらヤバイというプレッシャーが地味にキツイ。
あと属人化の弊害は、休みの日にも連絡が来ること。貴重な休日、彼女とのんびり過ごしている最中に
「オタク君、〇〇のプログラムってどこにあるっけ？」
「オタク君、△△ってどうやって動かしてるの？」
とか普通に連絡が来る。プライベートタイムブレイカーである。
いっそ休まないで出勤したほうがメンタル的にマシ。
そんなこんなで負担が傾いたせいでパフォーマンスが落ちて、しょーもないミスを見過ごしたまま先に進んじゃったりしたワケです。
これに関しては、マネジメントする側の問題だと思っているので内省すべき点はないのですが、俺ももう少しうまくやれたのではないかと考えたりもしてます。でも具体策が分からない。難しいねえ。
4. 仕様変更入りすぎ
仕方ないとは思うんですよ。大きいシステムを作る以上、作り込んでる最中に改修要件が出たりするのは仕方ないと思います。
でも、その頻度と時期がおかしいんじゃねえか？って思いました。
1週間単位どころか日単位でコロコロ仕様が変わり、その度に設計書修正。
リリース2か月前になっても基幹部分で変更入りました～とか連絡くるし、その度にプログラムも修正。
リリース2週間前に「やっぱりこうするべきじゃないか？」って言われて処理ロジック変更etc...。
おかげでツギハギ人形みたいな設計書とプログラムが完成。
ちゃんと整理できていないまま先に進んでしまったので、バグ起こしまくって終電じゃあのしました。
これは単に時間が足りなかった。焦り過ぎた。プログラム改修したなら、その影響範囲もキッチリ調べて、改修漏れがないようにすべきだった。
正直、今回ここまで残業するハメになった一番の原因はココだと思います。
責任転嫁、という訳ではないけれど、上がしっかりと検討し煮詰めきれていなかったため、自分たちが被害を被ったのかな、と。
当然それを受けての自分たちの対応が問題ありまくりだったワケですが、要はプロジェクト全体として甘い部分があったと思っています。
それともこれだけ仕様変更が入るのが普通なのかな？教えてドラえもん～
5. デグレ起きまくり
デグレとは、デグレード（アップグレードの対義語）の略で、要はプログラムを修正したはずなのに、前より悪化した&直す前に戻ってしまったことを指します。
これはね、もうほんとやばいよ。
IT業界に居ればデグレの深刻さは分かっていると思うので、当然その対策をとるべきです。gitをはじめとしたデグレ対策ツールはそのために存在します。（俺はgit使ったことないけど・・・）
で、うちの会社、そこそこ大きいので当然そこはしっかりしてるだろうと思ったら、なんと！
最新のプログラムは！
ただの共有化したフォルダにぶち込むだけ！ｗ
これでは誤操作で最新のプログラムをうっかり削除、上書きできるし、アクセス制限も特にかかってなかったので、ホントに誰でも触り放題みたいな環境に野ざらしにしてたということです。
こんなんだから
・最新のプログラムはどこにあるのかが曖昧
・誰がいつ何を修正したのかが全く分からない
・過去のバージョンの管理ができていない
という状況。「ｗ」とか付けてるけど笑い事じゃない。
そんで当然の如くデグレが発生しまくって、無駄に対応時間がかさむという結果。
これはなんだろう。俺たちがどうこうと言うより、バージョン管理するための環境を用意してもらえなかったのが敗因な気がする。自分たちにできることは細心の注意を払うくらいなので、起こるべくして起きたのかなぁ。運用ルールをガチガチに固めて管理すれば何とかなったかも。難しいね。
6. 連携力がない
リリース一か月前に別の機能を担当しているグループから「新しいシステム、半角文字使えないってこと言い忘れてた！ｗ」と。
(笑)。
至急対応しました。
似たようなことが何回かありました。他の機能担当との連携は俺らのすることじゃないので回避不可能でしたが、情報共有はしっかりしようと思う契機として受け止めておきます。
反省点
① 設計書は可読性、メンテナンス性を意識
② 単体テストは手を抜かない
③ #やめよう属人化
④ プログラム改修時は影響範囲をしっかり調査
⑤ バージョン管理は適切に行うべし
⑥ 情報共有を怠らず、認識相違を起こさない
こんなトコかな～。
仕事なので「特定の誰かが悪い」という考えはNGだし、今回だってそういう訳じゃない。
全体として問題があったので、その結果何百時間も残業することになってしまった。さっきも言ったけど起こるべくして起きたのかなって。
さいごに
俺が気になったのは"SIerとしてキャリアのある大手企業ですらこの有様である”という点。
大手 = ノウハウがある = 洗練化された働き方ができるモノだと思っていたけど、実態は泥臭いやり方だったりして何とも言えない気持ち。
自分は一番下っ端だったので上司や先輩が軸となり仕事していったわけですが、彼らが悪いというよりは企業としての体質的な問題？な気がします。
そういった状況で、じゃあ自分には何ができるか？ということを考えて、まずは個人で動かしていくパワーがないとダメだなと思いました。
とは言いつつも、ところは大手企業。腰の重さフットワークの鈍重さなら他の追随を許さない感があり、壁も感じています。
なので、ここは日本に生ける社畜として、大企業に飼われて安寧の一生を過ごすのが賢いかなと。
正直、理想と違った実態を見て失望はしていますが、じゃあ俺には何ができるか？と考えても答えは見えないので、俺はこのまま「ホワイト500」が作り出した濃い影の裏で残業代をすすろうと思います。
ということで残業いっぱいしたホワイト500社員の愚痴と反省でした。
長いのに最後まで見てくれてありがと～
おわり
