硬直しきったプロジェクトで働いた思い出

ふと昔いたプロジェクトについて思い出したので書く。

経歴

今日の話は中小SIer時代のこと。本エントリでは所属会社と呼ばせてもらう。

所属会社について

  • 社員30名くらいで、当時で設立8年目くらい。
  • 自称ベンチャー企業
  • 自社製品もあったが、基本客先に常駐するスタイル。いわゆるSES契約というやつ。月に一度、帰社日というやつがある。

プロジェクトジョインの経緯

  • 2008年当時、体力の無い所属会社はリーマン・ショックの影響で火の車。1・2年目社員の多くが社内失業者に。
  • 会社としては、社内失業者を何とか現場に出したい。3年目以降で会社の主力メンバーと共に、社内失業者がバーターでジョインできる現場が優先された。
  • 所属会社の1年目若手(自分の2つ下くらいだったと思うが)1人を自分が引き連れてプロジェクトに参画

プロジェクトの概要

  • 所属会社は商流的には3次請けくらい
  • 元請企業のそれなりの規模のフロアにプロジェクト全員が集結。たぶん広さは今の会社のワンフロアと同じくらいだけど、人口密度は5倍はくだらなかったと思われる。
  • オーソドックスなBtoC Webシステム。JavaでSpringだった。

チーム構成

サーバサイドはAction/View - Business Logic - Dao/DB のありがちな構成で、このレイヤーでチームが分けられていた。さらにそれぞれのレイヤーでもドメイン領域によってサブチームに分けられている縦割り組織である。

自分とその新人ははAction/Viewチームに放り込まれた。それまで自分はアーキテクチャとか基盤を担当したり、領域を制限せず働くことが多かったのでこの時みたいに特定の領域に位封されるのは初めてだった。新人のデビュー戦としてもってこいの案件かもしれないが、自分にとってはたまったもんじゃなかったのである。期間は2ヶ月の短期案件なので、とにかく耐え忍ぼうといった感じになった。

環境

既に述べたようにフロアは人口密度が凄くて🍣詰め状態だった。ちゃんとした席も一部にはあるのだが、与えられた席はおそらく増員に対応できなくて折り畳み用のテーブルにパイプ椅子という長時間作業するにはなかなかしんどい環境であった。インフルエンザ蔓延の時期だったのもあり、多くの人がバッタバッタと倒れ、毎日のように人の出入りがあった。

そしてスーツ必須である。何故ユーザー企業は作業者にスーツを強いるのか。

なによりもキツかったのはPCのスペックである。PCは持ち込みで間に入ってる会社の営業が用意したのだが、CPUがCeleronで512MBしかないThinkPadなのであった。eclipseを義務付けられたJava開発だったので、スワップしまくってまともに開発できないのである。でさっそく営業にアラート投げたのだが、この営業が本当にゴミ営業で増設メモリ持ってくるまで2週間かかって、その間は本当に地獄だった(これがきっかけで本気でVimを習得しようと思ったわけだが)。

進め方

こちらのチームにはエクセルで書かれた画面設計書と画面遷移図が降ってきた。あとはビジネスロジックチームが作ってるロジックのメソッド一覧である(ちなみにActionからDaoを呼び出すのは禁止)。これを材料にAction/Viewを作っていくわけである。

で、この手の開発で材料が完璧なことがあるわけもなく、当然足りないものをリクエストしないといけない。そのフローがなかなかクソで、要望を申請書に書いて提出しなければならないのである。その流れはこうだ。

  1. 要望を申請書に書く

  2. Action/Viewチームの上位メンバーがチェックする

  3. Action/Viewチームの上位メンバーに説明に呼び出される

  4. OKなら、上位メンバーがBusiness Logicチームに申請を投げる

  5. 同じことがBusiness Logic -> Dao/DBチーム間でも行われる

  6. OKならDaoチームで開発が行われる

  7. Dao開発完了後にBusiness Logicで開発が行われる

  8. Business Logic開発完了後にようやく自分のチームで開発できる

である。ちなみに提供されたものにバグがあった際も同じフローである(バグのときの方が再現するしないで堂々巡りがあってカオスになる)。で、だいたいこの手の申請が通って必要なものが用意されるまで2週間である。

最近ウチのプロジェクトではスクラムをやっていて、1スプリントを2週間で回すわけだが、これを彼らに当てはめると1スプリントで1メソッドしか用意できないのである。なんという素敵な生産性だろうか。

アプリケーションにレイヤーを定義することは良いが、ご丁寧にそれに引きずられた開発組織にするとは。組織的にガッチガチに縛ればエンジニアは本来の力を失い、ただの単純労働者になる。

まとめ

闇は深い。こんなプロジェクトが少しでも減って、IT業界に絶望する人が少しでも減ることを望む。