今までに経験した中で最悪の開発環境について書く
なんとなく吐きだしてみる。老害の昔語りなので興味ない人はスルー推奨。
時は2000年代初頭、俺は最初に就職した独立系SIerから4次請けの派遣として某銀行の営業店システム開発に参加していた。
新卒で入社して、二つ目のプロジェクトだった。当時は最先端であったJavaでのプロジェクトということで、ずいぶんと喜んだことは記憶している。
1フロアが丸ごとプロジェクトルームとなっており、プロジェクト統括の事業部長が常に怒号をあげながらフロアを徘徊するなかで、15インチCRTディスプレイ(当然液晶なんかじゃない)がようやく置ける狭い机とパイプ椅子で、右も左もわからないまま、Excelで書かれた仕様書と向き合い、秀丸エディタ(当時はEclipseがまだ生まれていなかった)でジャバを書いていた。
デスマであったかというと、今思うとそこまでデスってはいなかったように思う。頻繁にリスケが行われていたのでプロジェクト自体の進捗は芳しくなかったようだが、それでも連徹や休出は多くなかった。それ以降に参加したデスに比べると、ずいぶんと人間的な生活ができていた。
まず、ソースコードの管理体制から話そう。よくある人間VCSだ。
毎日最新版のソースコードが共有フォルダに配置される(VCS? 何ソレおいしいの?)。
ソースコードのチェックインは、当然のごとく申請書が必要で、毎日決まった時刻までに提出すると、ソースコード管理チームが手動でマージ・チェックインするというアレだ(ちなみに提出はフロッピーディスクかなにかの物理媒体だったと思う)。
マージの際にコンフリクトが発生すると、その申請は差し戻される。
申請書にはdiffとともに、なぜそのような変更を行う必要があるのか自然言語で記述する必要があり、時にはExcelを駆使してシーケンス図などの図表を挿入することもあった。
コードを書くより、この申請書を作成するほうが大変だったと印象に残っている。
プロジェクトは、サブシステム毎にいくつものチームに分割されており、自分は営業店クライアントチーム(のまたさらに一部のサブシステム)に参加していた。
営業店の他には、勘定系や情報系などのサブシステム毎にサーバー・クライアントチームに分割されており、そのほかにも前述のソースコード管理チームやドキュメントチーム、画面定義体チームなどがあった。
そう、画面定義体という謎存在について言及せねばなるまい。
Javaでのクライアントアプリケーションにも関わらず、何故かGUIのレイアウトやコンポーネントを実装するチームは別チームになっており、画面にテキストフィールドやボタンを追加するためには、「画面定義体チーム」へ申請書を提出して依頼する必要があった(注: Javaアプリケーションです)。
そうして追加して貰ったボタンなどのイベントハンドラの実装が、自分の担当であった。
とんでもなく非効率なチーム分割だが、この「画面定義体」とはメインフレームの文化であり、それがそのまま引き継がれていたということを後で知ることになる。
「画面定義体チーム」へ依頼した変更は、前述のソースコード管理チームへの申請・チェックインを経由して日次で配布されるzipファイルでようやく自分の手元に届く。
それを待ってから、さあ動作確認という流れだ。依頼から1週間もかかってようやくボタンが追加されたこともあった。
当然、反映されたものが手元に届くのを待ってはいられないので、想像で先行してコードを書いていくことになる。
では、コンパイルや実行はどうなっていたか? 信じられないことに、自分が支給された作業マシン上では、実行はおろかコンパイルすらできなかった。
何故かというと、 依存関係にある他チームのjarを取得する権限がないので、手元のマシンでコンパイル可能な環境を構築できない。
コンパイルは、チームに数台支給されるビルド専用マシンに書いたコードを持って行ってコンパイルする。万全のセキュリティ!!
ただ、ビルド専用マシンではビルドできるだけで実行はできない。サーバーとの疎通ができないからだ。
当然、自動化されたunit testなどない。
サーバーも含めた実行環境として、ステージング環境が用意されていた(専用のハードウェアが必要だったということもある)。
チェックイン申請書を提出して取り込まれたものがステージング環境に提供されてから、Excelで書かれた単体試験仕様書を元に人力で動作確認していた。
当然、ステージング環境の利用にも申請書が(ry
このように申請書だらけの管理体制だったが、唯一の救いは、クラス名が連番ではなかったことだ。
世の中にはもっとヒドい現場もたくさんあるのだろうが、大規模プロジェクトで性悪説に基づいた管理体制が肥大化した一事例として、インターネットの片隅に放流しておこうと思った。
