退職エントリ(1/3)：こんなクソオフィスになんていられるか！ おれは辞めるぞ！

　社畜のみなさんおは無職。今日も運搬車に揺られて通勤してますか？　最近は遠隔労働力吸い上げ制度(テレワークと読みます)による搾労も流行しているそうですね。
　僕はこのたび6年勤めたSES*1を主業務とする会社を退職しました。直近一年は休職しておりまして、先月ようやくやってやるぞと勇ましく復職したものの、退職速度で差をつけろと復職して一ヶ月でスピード退職と相成りました。

*1 システムエンジニアリングサービス契約のこと。早い話が客先常駐。

　休職前から考えていたので退職自体は予定調和ですが、それでも三ヶ月くらいは勤めて、職務経歴書に書けるくらいの経験を得てから辞めるつもりではいたのです。だのにひと月で退職を決意したのは、もっといえば、初日でバックれたくなったのは、健康で文化的な最低限度の開発環境がなかったからにほかなりません。

　会社を辞めたら退職エントリを書くというインターネットの古式ゆかしい伝統に従い、世にも恐ろしいクソ現場オブザイヤー(当社比)の思い出をネットの海に供養いたします。

① 狭い！　三密！　仕切りなし！

「悪いけど今度の現場はリモートワークできないんだ。個人情報を扱うシステムだから」
　復職前に会社から事前に伝えられのはそんな情報。なるほどね、完全に理解した。たしかに公共系システムしかり防衛産業のシステムしかり、分野によってはリモートワーク不可のところはあるわね。
　でも縦長の部屋にエンジニアを寿司詰めにして向かい合わせに配置した挙げ句、パーテーションもないってどうなのよ？

開発現場イメージ図。
個人スペースは作業机周りを含めても1畳くらいしかない。

　厚生労働省が公開している「職場における新型コロナウイルス感染症の拡大を防止するためのチェックリスト」の3-(3)によれば、机には仕切りを置くことって書いてあるんですけどね。

　当開発現場、後述しますがネットもメールもチャットも封じられているので情報伝達は基本的に口頭でやらなきゃいけないのです。なのに前にも横にも一切仕切りはなし。
「リモートワークができないのはセキュリティの観点からしかたない、でもそれならコロナ対策は十分に行っているだろう……」
　幻想は初日にして見事に打ち砕かれました。
　別部署に常駐していたころから家畜小屋だと思っていましたが想定が甘かったです。家畜のほうが大事にされていますね。家畜は事業者の生活に直結していますが、末端のエンジニアはひとりふたり死んだところで経営に影響はほとんどないでしょうからね。

② 騒音　サーバーラックとお友達

　上図をもう一度ご覧ください。部屋の右奥隅にサーバーラックが見えますね？　このラックに収められたサーバーが常にグォングォンと音をがなりたてて集中力を阻害してくるのです。
　ためしに騒音計アプリ*1で音の大きさを計測してみたところ、平均して60デシベルほどでした。これは掃除機の稼働音と同じくらいのうるささ*2です。誰もしゃべっていないのにこれですからね。

*1「音メートル」というiOS用アプリ。Android用もある。
*2 日本騒音調査(ソーチョー)「騒音値の基準と目安」

　絵を描いたり作曲したりするときにこんな環境ではかどると思いますか？　システム開発もアートと同様、頭脳労働ですからエンジニアには思考力と創造力を十分発揮する環境が必要です。ソフトウェア工学の大家、トム・デマルコ先生もエンジニアには広くて静かな環境が必要*3と言っています。

*3 著:トム・デマルコ、ティモシー・リスター、訳:松原友夫・山浦恒央『ピープルウェア 第2版 ヤル気こそプロジェクト成功の鍵』日経BP社(2001年) P67
　 原著は1987年。全6部34章で構成され、うち1部7章分をまるまるオフィス環境と生産性についてあてている。人々が思っている以上に広くて静かな作業環境は重要なのだ。

　しかしどうやら当現場はエンジニアにデバフをかけるのが美徳らしいですね。そもそもどうしてサーバーラックが開発室に置いてあるんでしょう。サーバー室はあるのに。
　この拠点のインフラ管理は別の関連会社が行っており、そこと調整をつけるのを面倒臭がったか、あるいはネットワークの知識がなかったかもしくは両方でしょうね。

③ メールもチャットも利用不可　ネットなんてもってのほか！

　これは僕の考えがサッカリンよりも甘いことを露呈するようで大変恥ずかしいのですが、リモートワークはできなくてもインターネットは普通に使えるだろうと思っていました。
　すいません嘘です。そもそもインターネットが使えるのはあたり前のことで、使えない場所が存在するなんて発想がまったく浮かびませんでした。
　現代人が水・電気・ガスの使えない家を想像できますか？　僕はそんな文明の未発達なところに放り込まれたのです。

　この不便な環境は、開発現場が拠点の基幹ネットワークから分離されていることに起因しており、何をするにも情報伝達に余計な労力を強いられます。
　メールもチャットも封じられているために、情報共有や不明点の質問は基本的に口頭ベースでした。するのも、されるのも。
　高頻度で作業が中断されてしまうため、そのたびに集中を入れ直さなくてはならないのも難事でした。
　また、僕はテキストベースのコミュニケーションのほうが得意なので逐一口頭でやり取りしなければならないのがダルダルダルビッシュでしたし、口頭だけでは伝わりにくい内容(画面構成など)を質問する際は、スクショを送るのではなく僕の席に足を運んでもらって実際の画面を確認してもらわねばならず、コミュニケーションコストは膨れ上がるばかり。僕自身への負荷もさることながら、相手の時間を奪ってしまうという意味でもすこぶる非効率ですね。

　一応開発現場内で共有フォルダは存在するものの、プロジェクトリーダーは別場所で作業していることも多く、迅速に共有すべきドキュメント(障害報告書など)をリーダーに報告する際には、基幹LANへの接続権限のあるプロパー社員さん*4にお願いしてメールで送ってもらっていました。本当にだるい。

*4 元請け側の正社員を指すことが多い。

ネットワーク構成イメージ図。
一般メンバーは基幹LANにアクセスできないため、プロパーさん経由でPLにファイルを送っていた。

　情報伝達面での非効率性に加え、技術的な調べ物についても、ネットが使えないために自分のスマホやタブレットでぽちぽち調べなければならず、時間がかかりました。仕事の調べ物で自分のギガを減らされるの腹立つな。　
　ここで勘の良い方は違和感に気づいたかもしれません。PCはネット使えないのに自前の機器でネットするのはいいの？　いいんです。ここでは。許可を受けたプロパーさんしかBYOD*5が認められていないようなので厳密に判断するとアウトだと思いますが、特に注意を受けることはありませんでした。ここの環境の煩瑣ぶりをプロパーさんも感じてたからでしょうね。

*5 Bring Your Own Deviceの略。個人所有の機器を職場に持ち込み、業務で使うこと。

　本来、機密保持のためにネット利用を禁じるのであれば、スマホほかネットに接続できる私物機器はすべてロッカーに預けるなどしないと一貫性がありません(実際にそういう現場はあります)。
　むしろPCからネット利用を禁じていても私物スマホを持ち込めてしまうほうがよぽどセキュリティ的には問題ありです。
 拠点内の管理されたPCからのネット利用であれば、ファイアウォールやプロキシで通信に制限をかけることができます*6し、よしんば漏洩したとしてもログを追って問題点を追跡できますが、個人所有のスマホでこっそり写真を取られたり会話内容を録音されたりしてバラまかれたらどうしようもありません。

*6 接続可能なIPアドレスやドメインを指定したり、一部のプロトコル以外は通信を遮断するなど。

　環境が劣悪であればあるほど不正の動機は強まります*7し、実際にベネッセで起こった顧客情報流出事件は記憶に新しいところです。

*7 不正のトライアングルで調べてみよう。

　とどのつまり、PCでネットを封じているのにスマホの持ち込みがOKなのは、開発効率の面でもセキュリティの面でもいびつなのです。
　当開発部屋に限らずこの拠点は全般的にセキュリティがガバガバで規則が実態に追いついていないんですよね。あるいは追いつかせようという意識も知識もないのかもしれません。

④ システムの説明はほとんどなし！　仕様書の最新版はいずこ？

　新しい人が仕事場に入ってきたら、その部署で行っている仕事はなにで、どんなことをしていて、きみの担当はこれこれだよという説明は大なり小なりあると思います。
　ところが当現場ではシステムの大雑把な概要だけで、機能はおろか担当範囲すら曖昧にしか伝えられませんでした。

　たぶん改修かテストをやってもらうことになると思う……。その改修とかテストってどの機能について言ってます？　開発環境はどうなってるんですか？　データベースサーバーの接続先IPは？　どの機能がどのテーブルを参照してます？　システムログイン用のIDとパスワードは？　統合開発環境は何を使ってるんですか？　Eclipse？　VSCode？　STS？　一から環境構築しないといけないんですか？　手順書あります？　え、既存の環境がある？　それってどのショートカットですかね？　アプリケーション・サーバーは何を使ってるんです？　Apache？　Tomcat？　両方使ってる？　じゃあ設定ファイル確認しないと……　ゐ？普段はローカル環境のEclipseのプロジェクトファイルに含まれてるから別にいじらなくていい？　うおォン。
　仕様書はどこにあるのかな？……って共有ファイル汚い！　フォルダ多すぎ！　名前も適当！　古いファイルもごっちゃ混ぜ！　オイオイオイプロジェクトリーダーさん、仕様書どこにあるんですかね？　え？ちょっと待っていま探す？　(10分くらい経過)　あった、これだよ！ってあなたが先導してるプロジェクトじゃないんですかどうしてそんなに時間かかるんですか。まあいいや、ようやくシステムの画面や機能の仕様がわかるぞ……って、なんか実際の画面に表示されている機能と仕様書に書いてある機能の数や文言が違うんですけど？　あ、ごめんその仕様書古いやつだった？　ワッザ！？

　とまあこんな感じのすったもんだがありまして、実際に開発作業にとりかかるまで一週間くらいかかりました。
　新しく入ってきた人がシステム仕様や現場のルール、明文化されていない暗黙の了解を理解するため、ある程度の時間が必要*8なのは理解できます。ですが少なくとも開発環境に関してはすぐに動かせる状態にしておくか、必要な情報をまとめておくもんなんじゃないんですかね？

*8 このため、プロジェクトマネジメントの世界では「遅延しているプロジェクトへの要員追加はさらなる遅延を生む」という現象がたびたび発生する。
　 ブルックスの法則と呼ばれており、プロジェクトマネジメント本の古典『人月の神話』(原著は1975年)で提唱された。

　このプロジェクト、一定の区切りは入れつつも3年くらい続いているらしいんですけど、作業の再割り振り・作業環境の構築・教育・既存メンバーとのコミュニケーションなど、要員の入れ替わりに際して発生するもろもろのコストについて一切勘案してないっぽいんですよね。まともに開発させる気あります？
　ドキュメント管理も雑で、テストで想定した結果が出なくて何回か試してみたりソースコードを確認したりしてあーでもないこーでもないと悩んだ末に相談した結果、前回の改修で廃案になった機能がなぜかテスト仕様書に紛れ込んでいて実施する必要がなかったっていうオチで半日分の作業がドブに沈んだこともありました。あれはつらかった。

⑤ え？システム開発なのにバージョン管理ソフトの利用に制限があるんですか？

　システムはプログラムファイルの組み合わせによって構成されますから、システムの持つ機能の開発・修正には対応するプログラムファイルを編集することになります。
　問題が発生するのは複数人で開発するときです。AさんとBさんが同じファイルをそれぞれ編集し、保存したとき、そのファイルはAさんとBさんとどちらの作業内容を反映するでしょうか？
　答えは最後に保存した方の作業内容です。
　仮にAさんが最後にファイルを保存した場合、Bさんの作業内容は露と消えます。これでは困りますね。
　このような問題を回避するため、システム開発にはバージョン管理ソフトというものを使います。ファイルにバージョン番号を付加し、ファイルが更新されるとバージョン番号も更新し、更新内容を差分として保存します。
　上記の例でいえば、もともとのバージョンが1であったとすると、Bさんの作業内容はバージョン2、Aさんの作業内容はバージョン3として保存され、次回作業時にはそれぞれの作業内容を統合したファイルを扱うことができます。

　複数人で開発する現代のシステム開発ではバージョン管理ソフトは欠かせません。当現場でももちろん使っていました。しかし先述したようにネットワーク環境に制約があるため、開発室側と基幹LAN側とにそれぞれバージョン管理サーバーが分かれていました。
「開発メンバーは開発室側のサーバーでプログラムファイルをバージョン管理し、一定の区切りがついた段階でファイルをプロパーさんのメール経由でプロジェクトリーダーに送り、プロジェクトリーダーが受けとったファイルを基幹LAN側のサーバーに追加し、更新内容を反映した新しいモジュール(システムを構成するプログラムファイルの塊)をこれまたプロパーさん経由で開発室側に返送する」というとても手間のかかる手順を経ないと変更部分がメンバー全員に反映されない状態でした。実質的にバージョン管理ソフトの利用に制限がかかっているも同然です。
　そもそも開発室LANと基幹LANが直接通信できればバージョン管理サーバー2つ建てる必要ないんですけどね。言ってみれば、本来は水道で供給するべきはずの水を管理者の都合でバケツリレーさせられているようなものです。あと今どきGIT使わずにSubversion使っているのもイケてない*9。

*9 GITが便利すぎるだけでSubversionが悪いソフトというわけではありません。

⑥ 足並みの揃わないPCスペック　人権のないシングルモニター

　とても不思議なことに僕に支給されたノートPCのメモリーは16GBある一方、開発環境のアプリケーションサーバーPCは8GBしかありませんでした。どうしてサーバーPCのほうがスペックしょぼいんですか？　現場猫はそう言った。
　先輩のPCにいたってはたったの4GB。スペック不足でまともに開発用ソフトが動かないのでサーバーPCにリモートログインし、そこで開発ソフトを動かしていました。どうしてサーバーPCで開発作業してるんですか？　現場猫はまた言った。
　現代のシステム開発でスムーズに開発環境を動かすなら、最低でも16GB、できれば32GBはほしいところです。

　加えて無慈悲なことに、モニターはこちらから希望申告しないと支給されないのです。外部モニターは標準装備じゃないのです。
　あれですか？　50ゴールドと銅の剣はやるから鎧は自前でよろしくなって？　古代ギリシア市民か？
　コーディングにしろテストにしろたびたびドキュメントを確認する必要があるので、モニターが一つだといちいちウィンドウを切り替えなきゃいけなくなるんですよね。作業効率が落ちるし視認性も悪くなります。
　さすがにノートPC一台での作業は予後不良になるのがわかりきっていたため、初日に申し入れてモニターを2台追加してもらいました。複数ブラウザで画面テストするのでこれでも足りないくらいでしたけど。
　プロパーの人たち、ノートPC1台でドキュメントを作成していてとても気の毒でした。飲食店で例えると百均で売ってる包丁とまな板でキッチン回せって言われているようなもんですよ。
　デスクワークにシングルモニターは人権侵害。今日はこれだけ覚えて帰ってください。リピートアフターミー、デスクワークにシングルモニターは人権侵害！　いつかストライキが起こることを祈ってます。

⑦ ファイル分割おいしいの？　コピペ上等クソコード

　サラダにかけるドレッシングを作るとしたらどれくらいの分量を作りますか？　ある程度の量を一度に作って、お皿ごとにかけますよね？　お皿ごとに一回一回作るのはあまりにも非効率でバカバカしいことだとすぐおわかりだと思います。
　でもそれと同じことが当現場では平気で行われていました。いわゆるコピペコードというやつです。
　例えばA・B・Cそれぞれのページでほぼ同じ機能を使っているにも関わらず、その機能を別ファイルに切り出し、必要な箇所で呼び出して使う(サブルーチン化する)ことはせずに、A・B・Cそれぞれのファイルに処理をベタ書きしていたのです。
　プログラムの世界は物質性を帯びていないがゆえに容易にコピペで動かせてしまうのですが、これをやってしまうとテスト工程での工数がコピペした分だけかかってしまううえに、その機能の修正が必要となるとやはりコピペした箇所すべての修正が必要になります。なりました。
　つまり後々の保守性に多大な悪影響があるため、真面目に勉強したエンジニアか、保守・改修を担当した経験のあるエンジニアならコピペコードがご法度であることはわかるはずなのですが、当現場のプログラムを担当したエンジニアはよほど駆け出しであるか、後工程なんざ関係ねえ動けばいいだろという横着精神旺盛な人だったのでしょう。
　コードの記述も非常に可読性が悪く、if文が5つくらい平気でネストしていたり、必要のないところでtry-catchしていたり、NULL判定・空文字判定の記述がこなれてない*10などと枚挙にいとまがありません。あまりにも難点が多すぎるのでコーディング関連の指摘は次回に譲ります。

*10 例えばこんな感じ。StringUtils.isBlank()使って♥
　 if(str1.equals(str2) != null && str1.equals(str2) != ""){
	処理
　 }

　まあもっとも言葉を失うのは、システム開発の経験がほとんどない僕でもひと目でわかるクソコードをまったくレビューせずに検収してしまう元請けサイドの姿勢なんですけどね。

⑧ 上司はタニシ　僕はヤマメ

　このプロジェクトは僕の上司もスケジュール管理者として深く関わっていました。つまり当開発現場の状態は認知していたのです。にもかかわらず復職明けの人間をいきなり放り込んだんですね。この御仁。
　あそこしか案件がなかったともおっしゃっていましたが、あそこが陋習の続く場所だと認識していれば、別の案件が湧くまで待つという選択もできたと思うんですけどね。
　休職するようなヤワな社員を追い出すために意図的に劣悪な現場に放り込んだ、という話ならまだ良かった。悪意という知性を感じられる分だけ救いがありますから。
　しかし実際に上司に意図を尋ねてみたところ、特に環境が劣悪である認識はなかった、この業界ではよくあることだそうです。ごまかしで言ってる風ではなく本当にそう思っているようでした。
　ははァン？　この人なまじっかエネルギーがあるばかり、悪環境に適応してしまったな？　前々からどうも僕と上司氏とでは物事に対する感受性がだいぶ違うなと思っていましたけどさもありなんですね。宿っている生命が全然違います。かぶっているガワは人間なので見誤りました。
　上司氏は濁った水でも生きられるタニシみたいなもんですが、僕は清流でないと生きられないヤマメみたいなもんです。どちらが悪いという話ではありません。上等か下等かという話でもありません。
　適切な生息域が違うのです。
　むしろガワが似ているから同じ生物だろうと思って本質を見抜けなかった僕の観察眼の節穴ぶりを責めるべきでしょう。
　上司氏や会社としては僕の意思を尊重し、最大限努力を払ってくれてはいたのです。「今までインフラとヘルプデスクのちゃんぽん業務で疲弊したから今度は開発業務に専念したい」という僕の意思を。
　その結果が当現場なのはちょっと商売を見直しましょうよと提案したくなりますが、勉強にはなりました。誰に悪意がなくても、いや、誰にも悪意がないからこそこじれる事象っていうのはこうして出来上がるんですね。

　とまあここまで当開発現場の不満点をつらつらと挙げてきました。安全衛生の観点からも、作業環境や技術的な観点からも、ここから学べることはあまりにも少ない。そう判断し、脱出しました。おかげさまで今は立派な無職です。
　ちなみにここの拠点で長年フリーランスとして従事している先輩エンジニア(火消しに強いタイプ)によると、これでもまだ話の通じる方らしいです。まじで？
　でもたしかにみずほFGの報告書を読んだりすると胸が詰まってしまうので、僕のいたところは規模が小さい分だけマシだったのかもしれません。

　今回はこのへんで。次回は便器にサインをして芸術と言い張るようなダダイズム的なアレだよと言われたほうが納得するような芸術的クソコードを紹介します。