終わるSIerの底辺を見てきた - ミッションたぶんPossible

ご挨拶

　今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。

　3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。

はじめに

　さて、オレにとって、この震災はもうひとつ別の意味を持ちます。この日「代休を取っていた」と前述しましたが、正確には、2011年02月分の代休*1を3月1日からまとめて取得している最中でした。つまり、その直前にそれだけ代休が溜まるような事態があったのです。
　オレは、2011年1月〜2月、オレにとって人生最初の「デスマーチ」を体験した案件に参画していました。2月単月だけで勤務時間合計：377.5時間、徹夜回数：8回、当然休日は土日祝日全て出勤。東京マラソン2011の参加者が走っていくのを横目に、購入したコンビニ弁当を引き摺るようにオフィスに持ち帰ってきたのが、今では少し懐かしく感じます。当時の経験を生かして、休暇中に以下のようなエントリーも書いたりしました。

デスマーチから生還する為に習慣付けるべき7つのポイント - ミッションたぶんPossible

　オレの所属する会社は、二次請け以降の受託開発の会社で、SIerとは名ばかりの実質人材派遣業で成り立っています。従業員は120名程度、そのうち100名がSE・PGとして主に客先常駐で業務に従事しています。主に担当するのは、詳細設計〜結合テストまでの下流工程、プロジェクトのしわ寄せが最も来るフェーズを主戦場としており、事実、社内では常に「○○○のプロジェクトが炎上している」という噂が絶えません。現時点でオレが把握しているだけでも2案件20名近くがデスマーチプロジェクトに身を置き、日々心身をすり減らしています。自他ともに認める「IT土方」です。

　それはこうやって文章を書いているオレ自身も…、と言いたいところですが、何故かオレは社内でも極めて運が良く、そういったデスマーチプロジェクトに関わらずに2010年末までやってこれました。むしろ、先進的でエキサイティングな案件ばかりに配属される傾向にありました。外資系企業のユーザー部門の技術担当、ベンチャー企業でのグランドデザインからの参画、RIAの最高峰で非常に優秀な面々に囲まれながらの要件定義〜テストまでの一気通貫した開発。どれもオレにとっては得難い経験であり、決して手放せない貴重な財産です。こういったチャンスをくれたのは、今は会社から去ってしまった元上司なのですが、破天荒な人で色々問題を起こしてばかりだったのはさておき、彼のおかげで今のオレがあると思っています。今でも元上司はオレの目標ですし、恩人です。本当に感謝しています。

　だからこそ、2011年1〜2月に体験したあの仕事は、驚きと落胆を隠せない、オレにとって「他とは全く逆の意味で貴重で得難い体験をさせてくれた案件」になりました。あれから一年経ち、社内でもあの案件に従事している人間は1人もいなくなったそうなので、「時効成立」とみなし、守秘義務や会社に迷惑がかからない範囲で、当時オレが感じた「驚き」や「落胆」がなんだったのか、書き記してみたいと思います。

　本当は、震災丸一年経過の日に書きたかったのですが、ずるずると延びてしまい…。ちょうど3/11の前日に、都内であったSIerをテーマにしたイベントで「SIerは滅びる」「受託開発に未来はない」という意見が飛び出したようで、2〜3日くらいWebを席巻していました。ちなみにその時の良記事を以下に列挙しておきます。これらに比べるとオレがこれから書く内容は低次元で個の印象に拠るところが多いものばかりですが、一意見として読んでいただければ幸いです。

前提条件

　オレが参画したデスマーチプロジェクトは、大体以下のような感じでした。あまり詳しくは書けないのですが…。

依頼元は某大手グループ企業のSI系子会社
グループ企業で使用する金融・保険系業務の一部を執り行うシステムのリニューアルプロジェクト
受注元は某大手メーカー系SIer
開発の一部はさらにそこから3〜4社(うちの会社含む)に委託

　オレの参画フェーズは単体テストから。というより、単体テストフェーズのみのスポット参戦。いわゆる「火消し」です。オレが入る以前にはリーダーが1人、PGが1人、パートナーさんで管理専任の人とSEがそれぞれ1人という構成。2月末には単体テストが完了していなくてはいけないのに、まだ開発が完了していないという状態でした。詳細はもう覚えてませんが、1〜2の業務を請け負い、画面(JSP)からDBまでで100本くらいのPG(Java)を書く必要がありました。FWは発注元が開発・公開しているOSSのものを使用、我々は参画時点でこのFWでの開発経験が無い状態でした。

　オレが担当したのは、単体テスト設計書の作成と、単体テストをJUnitで書くこと。ひたすらテスト・テスト・テストです。ちなみにオレはこのプロジェクトにいる間、ビジネスロジックのテストばかり担当していたので、実際の業務画面を見たのはほんの2〜3度でした。

　金融・保険系業務のシステムなので、外部へのネットワーク接続は禁止(LAN内のみ)、PCは持込だが退出時に専用ツールを用いてデータ全削除、ノートPCでもワイヤーと錠でテーブルに固定して移動も持ち出しも禁止。まぁ金融・保険系の案件にはよくあることです。
　自社業務を行う際には、e-mobileカードを差した専用PCを持込み、LANに繋がず外部通信を行っていました。このPCも退出時には全消去*2。

　最終的には、オレの他に2月に若手2名*3を追加し、管理業務や方針決定・元請企業対応*4で取締役まで出てきて、何度か期限を延ばして貰った上で、なんとかギリギリ納品にこぎつけることができました。

　以下から、オレが驚いた・落胆を覚えたポイントを列挙していきたいと思います。

契約からしてデタラメだった

　この案件はうちの子会社の営業が取ってきたものでした。この営業がいいかげんな野郎で、業務システムに関する知識はゼロ、口だけは上手くて、結構大きな仕事が取れたとリーダーに振ってきたらしいんです。うちの会社もバカじゃないから、営業が持ってきた情報から、リーダー自身による見積と、別の人間がもう一回検証見積を行う形で検証し、まぁなんとか採算も取れそうだし、なにより初めてのお客さんだから販路拡大のチャンス、ぜひやってみよう、と話を進めたらしいんです。

　ところが、実際参画してみると話が全然違う。そもそも前提にあった工数が貰えない。契約時点で半分近くまで減らされました。実際に開発が始まって作業量を検証すると、明らかに営業が持ってきた話よりも倍以上あったんです。しかも営業は殆どを口約束だけで進めており、途中の作業量に関するやり取りのエビデンスが全く残ってない。元請は作業量が多くなることはなんとなく分かってたようなんですが、あえてそれを隠していた様子。契約が結んである以上、元請も超強気、「こちらはそんなこと聞いてない」「契約した以上はやってもらう」とばかりに突っぱねます。口約束だけで話を進めたのはこちらの営業の失策、作業量を暗に隠していたのは元請企業の策略。言葉を選ばず言えば、「完全に騙されて貧乏くじを引かされた状態」でした。ちなみに、その後この営業はバックれ＆知らんぷりを決め込み、社内ではこの案件を取ってきた手柄だけをアピールするようになったそうな。「仕事を取ってきたのは俺のおかげ、案件を炎上させたのはリーダーのせい」ってな感じだったらしいです。

　この辺の話は、オレもリーダーから聞かされただけなので、恨みつらみから誇張表現の混ざっている可能性も大いにあると思っていますが、彼からしたら腸が煮えくり返る思いだったのでしょうね。

　それに加味して、リーダーはこういった炎上案件であっても、利益をプラスに収めた経験を何度となく持つ百戦錬磨の男でした。プライドも高かったですし、負けず嫌いでした。正直こういったい経緯を受けて黙っていられるはずもなく、収益プラスで終わらすことで社内外の連中の鼻を明かしてやろうと思ったんじゃないでしょうか。勿論増員は要請したようですが、基本的には自分でなんとかしてやろう、と躍起になったのだと思います。

　もしこの段階でギブアップし、マイナス覚悟で初期から大幅増員できていたら、もしかしたらプロジェクトはあそこまで酷くならなかったのかもしれません*5。が、それは今となっては誰にもわかりません。

決まらない仕様、バグの多い共通部品

　上流フェーズ、つまり元請企業の担当分の作業に大幅に遅れが生じ、開発フェーズで、下位ベンダーに対して、そのしわ寄せが押し寄せていたようです。まぁよくある話ですね。共通部品にも完成しておらず、単体テストフェーズの最中でもモックを使っていたと記憶しています。実際出来上がった部品もバグだらけ、都度手が止まり、担当者へ問い合わせて修正してもらうという手続きが何度となく発生していました。この段階でリーダーは元請の担当者レベルとはかなり仲良くなっていたようで、申請手続き自体はかなりフランクに進められていたようです。管理票とか…無かったんじゃないかな？

悪化し続けた人間関係

　これ自体はデスマーチ発生の原因とは無縁なのですが、デスマーチが起因で引き起こされた事象として記しておきます。

　オレが参画した段階でプロジェクト自体は開始されてから3ヶ月以上が経過した状態だったのですが、この時点でチームの人間関係は既にかなり悪化した状態になっていました。人間なら誰しもあることですが、稼働が極端に高くなってみんなが披露困憊になってくると、どうしても口数も少なくなり、互いのコミュニケーションが減っていきます。ギスギスして、ミスが出ると他者を一方的に責めるシーンも多く見かけました。信頼関係は崩れ、チームとしての体が保てているのか、中からは既に分からなくなっていました。

　こういう時、リーダーなりキャリアのある人間なりが是正しようとして、努めてメンバーとコミュニケーションを取ろうという行動を取るのが常だと思うんですが、恐ろしいことにこのチームでは一切そういうことが起こらなかったんですね。リーダー自身がファシリテーションが致命的に苦手というのもありましたが、それにしてもちょっと異常です。正直空気悪くて居づらいし、気分だってよくない。なんでこんな状況でみんな平気なのか、オレにはさっぱり分かりません。…で、ちょっと考えてみました。

　みんなデスマに慣れ過ぎてて、こういうギスギスした状況に対する感度が麻痺しちゃってるんですね。

　オレ以外は、うちの会社のスタンダードである、デスマ上等案件ばっかりこなしてきてる人間です。だからこんな状況慣れっこ。ギスギスしてても「しょーがないよね」で済ませちゃう。空気を変えるための施策もないし、そんな元気もない。もちろんそれで精神が正常でいられるわけが無く、スパイラル的にストレスを内側に溜めていくことになるので、心身ともに負担は相当なものだったでしょう。オレ以外のみんなは、長年そんな状況下で仕事を続けてきていたのです。

　オレは普段、仕事中に全く喋らない人間*6なので、本来あまり他人に話しかけたりする方ではないんですが、さすがに重い空気に耐えられず、この案件に参画中は極力無駄話をするように心がけました。その結果、残念ながらオレに対するイメージに対し「人間としてはかなり軽薄で、テキトーなことばかり言ってる、決して真っ当な人間ではない人」というプロジェクト内共通認識が出来上がってしまったようでしたが、その大いなる犠牲の甲斐もあって、多少なりともチーム内の空気の改善に貢献できたと思います。
　ですが、そう心掛けていたオレでさえ、プロジェクト最後の一週間は全く心に余裕がなく、不用意な言葉から他者を傷つけてしまうことがありました。今更ながら、本当に申し訳ないことをしてしまったと、後悔するばかりです。

不必要に求められる膨大な量のエビデンス

　このプロジェクトでは単体テストでかなりの品質を求められ、それが成し得た証拠としてエビデンスを大量に取ることを義務付けられていました。テストにはJUitを使っていましたが、これ本当に必要なのか？と思えるほど厳しい内容でした。

オールグリーン
カバレッジ100%
デバッグログの出力とそのログの指す意味の解説レポートを作成
全ての分岐点において、eclipseのデバッグモードを使用してテストの最中に動作を一時停止し、分岐点の前後でスクリーンショットを取得する
超イレギュラーケース(筐体の破損レベル)においてのみ通過する分岐に関しては、「何故その分岐を通過せず、結果としてカバレッジが100%にならないか」を立証説明する
上記を全てExcelレポートにまとめる

　これを全テストケースに対して行う事を義務付けられていました。テストクラスには1万行を超えるトンデモテストクラスもいくつか存在し、そんなものにこれを適用してた際には時間がいくらあっても足りません。…まぁそうは言ってもやったんですが、気合で。

　しかもうちのリーダーが品質に煩くて、ちょっとでも指定の形から外れるとリジェクトするわけですよ。結果として大きなミスなく納品できたのは確かですが、逆に自分たちの首を絞めた部分も大いにありました。そもそもこのエビデンス基準も、実はうちのリーダーが元請に進言した、という噂も一部であったくらいだし。

　オレはけっこうズルしてて、というか真面目にやるのが馬鹿らしくなって、手抜きで一気に作ってしまい*7、全部作りきったあとで口で言い負かして無理やりそのまま通したことがありました*8。あれやってなかったら、終わんなかっただろうなぁ、きっと。

　ちなみにこのエビデンス、元請企業がちゃんとチェックしたかどうかは知りません。量が多すぎて全てをチェックするなんて絶対無理でしょうし、それらをやりきろうとするだけでデスマがもう一つ発生するはずなんですけどね。

前フェーズを全て無駄にしかねないテストの位置づけ

　ここまでやって出した単体テストのエビデンスが全てフイになる可能性が、このプロジェクトのスケジュールには仕込まれていました。単体テストの実施が「各層の疎通確認は不要」という条件で行われていたんです。このシステムは一般的なWebアプリケーション型で、

画面
プレゼン層
ビジネス層
- ユーティリティ機能
DB層

とレイヤーが分かれていました。当然それらが結合テストの際に正常に動作しない＝疎通できなければ、プログラムソースコードは修正、単体テストはやり直しになります。テスト自体は自動テストを既に記述済みなのでまぁ良いとして、エビデンスはそうはいきません。先ほど列挙した膨大な量のエビデンスを、もう一度取り直す必要があるのです。よしんば単体テスト工程まで無難に進められても、結合テスト工程で一回ミスるだけでデスマ確定！…って、なんの罠だそりゃ？

　この辺はリーダーが機転を利かせていて、単体テスト工程の段階で各層の疎通は完璧に終わらせていました。…まぁただ、そのしわ寄せで我々の単体テストのスケジュールはより一層タイトになったのはいうまでもありません。また、「スケジュールが大幅に遅れているのに、やらなくていい疎通テストをやっていた」などとバレると雷が落ちるどころの話ではなくなるので、こっそりバレないようにやってた、というどうでもいい裏話はあります*9。

　オレは単体テスト工程が完了時点でプロジェクトを抜けたので、この後の話はプロジェクトに残った人間に後から聞いたのですが、案の定、結合テスト工程で他のチームでは、オレらとは比較にならないような泥沼デスマに嵌っていったそうです。一方うちのチームだけは余裕を持って結合テストを完了、割と早い時間に帰宅できたそうな。オレがいなくなった後でプロジェクトが改善されてもなぁ…。

他者を蹴落とすことだけに長けたプロジェクトマネージャ

　このプロジェクトのプロジェクトマネージャ(以下、PM)は、本当に最悪の人間でした。今までこんなクズ野郎、見たことがなかった。

　このプロジェクトでは元請の人たちも開発工程に携わっていて、我々ほどではないにせよ、やっぱりデスマ状態にはあったんですね。ところがPMだけはきっちり定時で帰る。20時以降にPMの姿を見たことは一度もありません。休日出勤も当然しない。それどころか平日日中でさえ殆ど仕事をしていないんです。一回気になって慎重に様子を伺ってみたことがありましたが、…お前、どうみてもそれソリティアやってるだろ*10。たまにオフィスで大声で「○○ちゃん、頼むよ〜。」と電話を掛けてるときくらいしか仕事らしい仕事をしている姿は確認できず、実際に彼が本来やるべき仕事は、彼の下に就いた補佐のような人が殆どやっているようでした。PMがムスッとした顔で机に向かっているのを、元請会社の彼の部下が見て「○○○(PMの名前)さん、機嫌悪いね〜。」「昨日飲み過ぎたんじゃない？接待とか言ってたしｗ。」などと陰口を叩かれる始末。彼が仕事してないのは、周知の事実だったようです。

　中でも最悪だったのは、いよいよプロジェクトも佳境で、事態収拾のためうちの取締役が乗り出してきた時のこと。PMが補佐を連れてブラブラとオフィスを徘徊、その際、取締役が空いたデスクを借りて作業をしてたんですが、それをPMが目ざとく見つけると「おい、○○○(取締役の名前、呼び捨て)のヤツ、来てやがるぜ！」と大声で補佐に言うなりドカドカと大きな足音を立てて取締役に近づき、「○○○さ〜ん、ちょっとどうなってるの？」とその後20分余りネチネチネチネチと小言を言い続ける始末。これを、一番遅れていたうちのチームだけでなく、他のチームにも頻繁にやっていたそうです。その都度小言をぶつけられた相手は手を止めざるを得ない。精神的にもダメージを受けますから、当然その後の作業効率も落ちます。元々遅れていた作業は更に遅れていきました。プロジェクトを健全に遂行すべきPM自身が、プロジェクト運営を悪循環に陥れていたんです。

　噂ではこのPM、過去にプロジェクトの全体会議で突然ブチ切れ、1時間近く意味不明な事を喚き散らした挙句に会議の場を退席、その後、補佐の人から「…え〜、まぁ○○○(PMの名前)が訳の分からない事を申しておりましたが、気にせず会議を再開したいと…」といって一同を爆笑させた、なんて事もあったそうな。あとまぁ周囲をロクに確認もせず馬鹿でかい声で陰口(？)を叩くので、実は一島離れたデスクに悪口の対象となった当人がいて、根拠もない罵倒を直接耳にする、なんてことも日常茶飯事でした。空気は致命的に読めない…、いや、読まないことが特権だと思ってたのかもしれませんね。

　こんなトンデモなPMでしたが、彼の部下たちからはそこそこ人気があったようです。何故なら理由は簡単、「飲み代を全部出してくれる」から。

　このPM、はっきり言ってしまえば、社内政治にのみ圧倒的に長けていて、ただそれだけであの地位にまで上り詰めたのでしょう。他人を蹴落とし、下にプレッシャーをかけて自分の成果を良く見えるように仕立て上げる。それをなんの恥ずかしげもなく実行できる。オレの知っている「エンジニア」のあるべき姿とは真逆の存在でした。しかもどうやら彼の会社ではそれが常態化しており、社内政治に長けていなくては上に上がれない構造になっているようです。どこの会社でも少なからずそういう傾向はあるでしょうが、SIerのヒエラルキーのトップレベルの会社の一部では、そういう社内政治のみで評価する傾向が強いのかもしれません。だからこそ、みんなPMが仕事していないのに薄々感付いていながら、何も言わない・言えないのだと思います。一度波紋を起こせば、自分の立場が危うくなるから。彼らの会社がそういう人ばかりじゃないと祈りたいです*11が、少なくとも黙認される程度には力があるようです。

　オレがプロジェクトを抜けた後、つまり結合テスト工程の話ですが、リーダーとPMはずいぶんと仲良くなった、と聞きました。うちだけがスケジュールが順調に回せるようになったら掌を返したように好待遇になったそうです…あれだけの仕打ちをしておいて、よくもまぁ。

「あの時はあんなに陰で互いに罵り合ってたのになぁｗ。」

「なぁ、全くだよｗ。」

　後日リーダーとそんな会話を交わした覚えがあります。

ユーザビリティを全く考慮してない画面設計

　オレはこの案件参画中、ビジネスロジックの単体テストを主に担当していました。なので画面については殆ど見たことが無かったんですが、PGを担当する人間から画面を見せて貰う機会が何度かあり、そこで初めて自分の作っている*12システムの画面を拝むことができました。

　まぁ、ビックリしたね。唖然としたね。呆れたね。

　イマドキ小学生が授業で作るような簡単なHTMLで作られたレイアウトに、もしデザイナーがいたらそいつのセンスの泉の枯渇を憂うどころかダイナマイトで水源ごと爆破したくなるような大胆すぎる背景色の配色、文字色は全て黒で警告文のみ赤というCSSを欠片ほども使ってないことが一目で明白のフォント。今までオレが見てきた中で最も稚拙で何も思いが込められていない、それはそれは酷い画面でした。

　このプロジェクトは金融・保険業務のシステムなので、

健康保険一時控除者確認
健康保険一時控除者登録
障害保険一時控除者確認
障害保険一時先払者確認

みたいに、業務名に盛大に漢字が並ぶことになります。(上記はテキトーに書いたけど、ニュアンスは伝わるはず) パッと見でそれぞれの違いが分かりますか？書いたオレにも即時判別は出来ません。
　しかも、遷移後の画面に並んでいる入力項目もどのページもほぼ一緒、配置も殆ど変らないので、間違って画面遷移しても気付かず作業を続行しちゃうかもしれない危険があるんですね。

　だから、実際に業務で使用する際にこれらがパッと視認できるようにするために、

業務名の前にそれ専用のアイコンを付ける-
文字色やフォントを変える
業務ごとに画面背景色等を変えて画面遷移先が間違えてたらすぐ気付けるようにしておく
エトセトラエトセトラ…

ともかくデザイン面できちんと配慮しとかなくちゃいけない。かなり早期からデザイナーを入れて、「どうやったら業務生産性を高めてユーザーにストレスなく使ってもらえるようにするか」を検討しとかなくちゃ駄目なんです。駄目なんですが、そんな考慮が皆無であることは、画面を一目見ただけで明らかでした。

　発注元からすれば「自社の業務システムだし、見た目が汚くても安く上がればいいや」くらいに考えていたんでしょうね。しかも既存システムのリニューアル案件だからと、要件定義も、元のシステムの分析だけで終わらせているはず。おそらく業務従事者に対するヒアリングも行っていないでしょう。

　そもそも外部に発注している時点でおかしい。発注元だってSIerなんです。自社の業務システムの開発であれば、多少なりとも失敗してもリカバリーが可能なんですから、顧客に提案したことがない新技術や新要素を如何なく試用でき、かつ失敗しても対外的にリスクを負わずにすみます。言い換えれば、新しいジャンルにトライする為の格好のチャンスです。自分たちのところの新人や経験の不足している人たちのトレーニングの場として活用するにも最適の場でしょう。
　それを早く安く完成させることばかり優先し、外部のベンダーに丸投げしてしまうあたり、R&Dと教育の両方のメリットを放棄している事になります。はっきり言って、IT技術で飯を食ってく企業体としてどうかしてる。
　…まぁそもそもとして、この発注元の会社、自分で開発する気なんかサラサラ無いのかもしれませんね。全部下請けに丸投げして利ざやを稼ぐ。こんなのが受託開発業界のトップにいるんだから、そりゃ業界全体で歪みも出るわけだ。

　通常、最後のユーザー受入れテストであまりに使いにくいと、デザインレベルでの修正を要求される場合があります。この時指摘された箇所が、単に見栄えの話ではなく、デザインと機能が密接に関わり合っているような場合には、システム側にも改修が必要。そのせいでデスマおかわり！が発生する場合もあるようですが、今回の場合、発注元がSIerでその辺は了承済みで、リテイクにさせなかったんじゃないかと勝手に予想しています。ユーザーの負担は誰ぞ知る、って感じですが。

プロジェクトのその後

　プロジェクトは無事2011/02/28の早朝に納品を完了し、その翌日は撤収準備と、定時までの余った時間を近くのショッピングモール散策で潰しました。定時明けてオレともう一人のプロジェクト退出者で飲みに行ったビールとワインの味は、何物にも代えがたいほど格別でした。
　会社はその後もこれらの会社と取引があるようでしたが、オレ自身は金輪際関わることもないでしょう。オレは別のお客さんの依頼で、スマートデバイスを提案レベルからやらせて貰える、やっぱりエキサイティングな仕事に就き、その時の他のメンバーはやっぱり社内の別のデスマーチに巻き込まれているようです。オレとリーダーはあの後2度ほど偶然会って話をしたきりになっていますが、風の噂では本日付で実質退職するという話を耳にしました。それ以前から会社のあり方にかなり不満を持っていたようですから、むしろ長続きした方だと言ってしまってもよいでしょう。
　そういえば、DevLoveの勉強会(アジャイルサムライ道場だったかな？)に参加した際、たまたまこのプロジェクトに関わっていた別会社の方と偶然お会いする事がありました。いやぁ、人の縁ってのはどこにあるか分からんもんですね。

　プロジェクト自体の顛末は、既に書いた通りです。我々のチームの担当分は事前に各層の疎通を完了していたおかげで、その後の工程は極めてスムーズに進んだそうです。うちの新人の女の子はノンビリホンワカした印象を与えるからか、PMからずいぶん気に入られたと聞きました。一方で他のチームは更にひどい状況に陥り、散々な状況になりながら、なんとかプロジェクトを完遂させたとのこと。あのシステムは、今はきっとユーザーの非難を日々浴びながら稼働してるんじゃないでしょうか。現在ではうちの会社からあの案件に従事している人間は1人もおらず、その後どうなったのかは知る由もありません。

考察：SIerは本当に終わるのか？

　このプロジェクトの何が問題だったか、今までで書いてきた内容をもう一回まとめてみます。

契約を結ぶプロセスの証跡を残しておらず杜撰だった
契約時に提示された作業内容に誤りがあった
上流工程の作業遅延の影響を下流工程で吸収しようとした(リスケしなかった)
高稼働が人間関係の悪化とコミュニケーションロスを招いた
過剰なエビデンス作成を義務付けていた
手戻りが膨大になる順序でプロジェクトタスクが設定されていた
PMが利己的かつ独善的に動き正常なプロジェクト運営を妨げた
ユーザビリティを考慮してシステムを開発していなかった

　なんともまぁボロボロです。

　どれもこれも大問題なのは間違いなんですが、個人的には一番最後に列挙した「ユーザーがどのように使うか想定せずにシステムを開発していなかった」が一番心に引っ掛かりました。どんなに苦労しても結果ユーザーに良いものを使って貰え、喜んでもらえれば、それはひとつ報われたと思えるのですが、このプロジェクトで作ったものはおそらく誰からも感謝されないんじゃないかと思っています。オレ達があんなに苦労して、命まで削って作ったものは、いったいなんだったのでしょうか？　それを考えると、正直なところ「残念」とか「悲しい」とかそんなレベルじゃない失望感だけがあります。この気持ちを上手く表せる言葉が、オレには見つかりません。

　現在の受託開発ビジネスは、発注側企業の都合と請け負うSIerの利益追求の落としどころとして最適だからこそ、今まで続いてきた、という意見をよく聞きます。ユーザー側は小難しいことは考えたくないから作業は丸投げしたい、失敗した時のリスクは負いたくない。社内で稟議を通すために値段は先に決めておく。負荷をまるっとベンダーに押し付けることをユーザー企業が欲し、それを承知の上で構築されたビジネスモデルが、現在のSIというビジネスです。昔は今ほど開発期間を短くすることを求められなかった、と聞きますから、個別企業付担当として貼りついたSEがユーザー以上に業務を把握した状態で、ある程度じっくり取り組んだ上で相互利益の出るシステム開発が出来てたんじゃないかと思います。それが近年の人材流動化だったり、ビジネスの移り変わりが激しくシステム開発の期間が圧縮される傾向にあることから、失敗するプロジェクトが出てきたり、よしんば成功したとしても開発現場に携わった人員の多大な犠牲の上に成り立っている、という現実があるのではないでしょうか。

　ただ、正直なところ、前述のような「SI業界全体が抱える背景」は現場には伝わりません。要件定義に時間が掛かってて仕様がちっとも決まらない、そもそも予算が少ない、調達したいスキルの人員が補充できない、管理が破たんしてる、そんな目に見える「誰かのせい」が積み重なってデスマーチを形成しているように見えます。会社さえ変えればもっと楽になるかも、と退職していく人も、きっといるんでしょうね。

　身の丈に合わない話は一旦置いておくとして、我々があのプロジェクトから得たものはなんだったのかを振り返ってみます。

　前述の通り、オレはこのプロジェクトで単体テストしかやってません。実はオレは、非常に情けない話ですが、それまでちゃんとテストコードを書いた経験が無いというダメプログラマーっぷりだったので、このプロジェクトを通して書き方を覚えることができたところはあります。あんなプロジェクトでもきちんと成長点を見つけることができたのはオレのラッキーだったところでもあります。でも、もしユニットテストの書き方をマスターした状態でこの案件に参画していたら、オレ自身の知識・技術の向上は全くなかったでしょう。
　これはオレ以外のメンバーも同様で、おそらく自身の向上を実感できたメンバーは1人もいないんじゃないでしょうか。ただ仕事をいち早く終わらせる為に、細かく分担された各作業をひたす片づけていく。傍から見たら、さながら工場のベルトコンベヤーに備え付けられたロボット、もしくは養鶏場の雌鶏のように見えたでしょう。

　
　そういえばオレの今携わってる案件も、稼働だけで言ったらそれなりに多いんですよね。どうせ残業代出ない*13し、めんどくさいから月報には書いてないんですが、実質250-300hくらいは働いてると思います、大体いつも最終退出者だし。じゃあ辛いかというとそんなことは無い。お客さんの要望を叶えるために市場調査をしたり、トライアンドエラーでコード書いたり、技術や知識を習得する時間も含んでいます。自分が進んでいる・成長しているという感触と、お客さんとの対話の中で、感触を確かめながら一緒にひとつのモノを作っている、それが楽しいし面白いし、ポジティブに仕事ができているからか、あんまり疲れを感じてはいません。まぁ労働時間が少ないに越したことはありませんが、自身の成長と、労働に見合った対価、お客さんからの適切なリアクションがあれば、多少稼働が高かろうと「デスマーチ」などと悲観的な言葉を使わなくてもいいような仕事が出来るんじゃないでしょうか。

　あのプロジェクトはオレにとって最初のデスマーチでしたが、いわゆる巷で言われる「デスマーチ」の中では、どうも大したことない部類に入るようです。現に、うちの会社での最も酷かったプロジェクトでは、メンバー全員が400時間/月を超えたプロジェクトも存在したと聞きますし、500時間/月を記録した人物もいました。それに比べれば確かにオレの体験した「アレ」は、大したこと無いのかもしれません。これを読んでいる方でも「その程度で何を言ってるんだ甘っちょろい」と思われる方もいらっしゃるんじゃないでしょうか。ですが、通常160時間程度が一般的であるはずの勤務時間が2〜3倍に膨れ上がるというのは、やはり「異常」と言って差し支えないはずです。働く人間にとって優しくない環境を人が支えていくのは、どう考えたって無理がある。既に学生からはSEという職業は敬遠されているみたいですし。

　一方でそのSIerが作ったものを提供される側はどうでしょう？本当にユーザーの事を考え抜いて作られたものが、どのくらいあるんでしょうか？依頼する側が丸投げを希望し、請け負う側が想いを作る人全員に伝えようとせずむしろバラバラに切り刻んでしまう、そんなあり方で良いものが作れるはずがない。あんなものしか作れないなら、SIerなんて滅んでしまった方がいいんじゃないのか。率直にそう思いました。

　しかし、SIerが滅びようが滅びまいが、企業が活動を続ける上で、ITは無くてはならないものだという事実は変わりません。今後もSIerがやってきた仕事は必要とされ続ける。クラウドだろうがパッケージだろうが、形は変わっても、この分野のスペシャリストは、やっぱり必要です。
　また、社に来る大口案件を見ると、壮絶なデスマーチを繰り広げはしたものの、「では代替案は？」と問われると即答できない自分もいます。あれだけの規模、あれだけのスペックが要求されるシステムが、SaaSやパッケージなど、今流行りで聞こえのよい何かに置き換わるとは、到底思えないのです。
　この間自社の社長と飲み行ってきた時の話ですが、「メインフレームのお守りをできる人材がいなくなってきていて、COBOLやアセンブラの出来るヤツを探すのが難しい。需要はいっぱいあるんだ。出来るヤツがいない。」と言っていたのを記憶しています。レガシーなシステムはこれからも存在し続けるし、それを面倒見続ける人もいる。大企業であればあるほど、それらは外すことが出来ない大きな歯車として回り続けているんだと思います。それらが現行のSIビジネスで賄われている以上、5年や10年で「SIerが滅びる」と言われても、どうもピンと来ません。シュリンクはしていくでしょうし、中小規模の案件は確かにSIから遠のいてくとはオレも思います。が、金融や保険、政府・官公庁絡みといった大規模案件では、5年くらいのスパンであれば、現状とそんなに変わらないんじゃないかと勝手に思っています。「銀行ATMのシステムがSalesforce.comやAmazonで動くか？」と聞かれたら、オレなら「絶対無理だろ」って言いますね。

　要するに、SIが滅びるかどうかなんて、正直まったく分からんです。

　個人的な意見ですが、「SIが滅びる」「いや滅びない」という話は、してもしょうがないんじゃないかな、と思っています。企業単位で考えるならば、うちのような下請の会社は確かにSIビジネスが崩壊すれば仕事が来なくなるでしょう。潰れるところもたくさん出るはずです。でもまぁ前述の通り、企業活動が続いていく以上、企業にITは絶対に必要です。新しいSIビジネスを提供する会社も、ソニックガーデンさんの「納品しない受託開発」や、クラスメソッドさんの「サイクロン」のように出始めてきています。であるならば、将来に対して危機感を持って動いているエンジニアであれば、現行のSIビジネスが滅びたからといっても、困難の程度の差はあれ転職は可能じゃないかと思っています。危機感を持ってないエンジニアもどきの事はオレは知らない。

　ただ、SIerが必要とされてきた背景として「ITに関わりたくないユーザー企業」が存在したからこそ、現行のSIビジネスは存続してきました。でも「自分の欲しいものが何か分かっていない奴は、その欲しいものを手に入れることができない。」と村上龍も言っていたように、欲しいものがちゃんと分からない人たちだけでは、本当に必要な使い易いシステムは作れません。まず、ユーザー自身に積極的にシステム開発にかかわってもらう必要がある。

　であるならば、「ITが必要不可欠な存在である」「ユーザー自ら積極的に関わっていかなければ本当に欲しいものは作れない」ということを、IT業界以外の人たちに啓蒙していく必要があるのではないでしょうか。それこそ義務教育のレベルから教え込んで行くべきで、今は小学校でもかなりしっかりITの授業を行っているようですので、その時間の中に「企業でITがどのように使われているか」「そのシステムはどのように使われているか」を教えてもらう枠を1コマでも2コマでも入れて貰えればかなり改善するはず。いっそのこと、一週間くらいでチームで簡単なシステムを組む実習を小学生のうちにやってみてもいいんじゃないでしょうか？そうすれば、如何にシステムを作るのが難しいか、というのを体感してもらえますし、逆にITに興味を持ってくれる子供も増えるかもしれない。バグは当たり前に出るものだということも理解してもらえるだろうから、もしかしたら、「銀行ATMが不具合で動かなくなった」という事態でいちいち無駄に大騒ぎしなくなるという副次的効果も得られるかもしれません。なあんだ、イイコトづくめじゃない！ …まぁ「言うは易し行うは難し」ですけどね。

おわりに

　昔にも言ったことですが、デスマーチに巻き込まれるのはIT業界に置ける最大の不幸ながら、現時点では避けがたい事象であるのも確か。特に今月は多くの企業で期末に当たりますし、おそらくはデスマーチで犠牲に遭われている方が数えきれないほど出ているんじゃないかと思います。本当にお見舞い申し上げます。

　オレの先輩が以前「法律で有休や代休は取らなくちゃいけないものと定められているんだから、ちゃんと休ませてなかったら会社は訴えられるんだ。だから俺は会社の為に、別に取りたくもないのにちゃんと有休や代休を取ってやっているんだ。会社はもっと俺に感謝すべきだ！！」ってなことを言ってました。まぁ会社が感謝するかどうかは別として、休みを取るのは公然と認められた権利で義務ですので、彼くらいの勢いで堂々と休みを取って下さい。

　ちなみにオレは、「うちは人月商売なんやから代休とはいえ半月も働かないんなら今月の給料は無いで？」とか言ってきた社の取締役に対し、「好きにすりゃあいいじゃないですか！」と大喧嘩した上で堂々と代休を取りました。結果的に給料は減らされませんでしたからよいものの、オレの無計画な財布事情を考えると、かなり危険な橋を渡ったかもしれませんねぇ。

　オレはこの仕事が好きですし、非常にやりがいのある面白い仕事だと思っています。それが業界の一部の傾向で敬遠されたり卑下されたりする状況は、やっぱり非常に残念です。労働条件が、せめてデスマーチと呼ばれるものが無くなれば、学生からの受けもよくなるだろうし、業界の中の人たちもゆとりと自信を持って働けるんじゃないでしょうか。とりあえず「ああいうのも人生経験だから一回くらいやっといた方がいいよ」という人が近くにいたら、友人関係を清算することをオレはオススメしときます。

　最後に、エンジニア全てが、デスマーチとは無縁で、楽しくエキサイティングな開発に携われる業界になることを、心からお祈り申し上げます。