デスマ

今回のプロジェクトは、リーダー以上の管理職のレベルが今まで見たことなくハイレベルなので、平均的な負荷は高くてもデスマになることはないだろうと思っていたが、がっつりやられた。


管理の手法としては今まで見た中ではほぼベストかなと思える内容だし、元請社員の個々の能力はかなり高いのだが、それでもダメだった。


今まで参加したプロジェクトでデスマパターンになったのは、ほとんどはリーダークラス(5〜10人ぐらいブラ下げている主任級)の能力不足か、営業と現場の連携不足か、そもそも予算が足りてないだろってのか、複数のベンダー(元請企業)の間の綱引きで仕様決定の先送りやちゃぶ台返しがあるってヤツだった。


今回は複数ベンダーパターンに入るのかな一応。




今案件は大きなプロジェクトで、複数のベンダーが参加しているが、クライアントが要求してくる進捗と品質が厳しくて、パンクしてリヤイアしたベンダーが出てきて、残った他のベンダーにはシワ寄せが来た。


元がホスト系の古いシステムのリプレイス案件で、ホスト系にありがちなNoドキュメントで、ソースコードと作った人、使ってる人しか仕様が分らんってやつなので、まぁ苦戦するのは当然と言えば当然なのだが、ケツの割り方がどうなんだろう?って感じではある。


デスマの分析とか、プロジェクト運用はこうあるべきとかって本は色々あるが、どれもこれも個々の技術としては正しくても、実際に起きているリアルのデスマには適用出来んだろうって気はする。


なぜならデスマとは技術や経済の問題ではなく、政治だと思えるから。




あるベンダーが、本当は力不足だと思えても、旧システムを手がけているところだったら外すわけにはいかないし、グループ企業だとか、借りがある取引先だとか、縁故だとか、上からのお達しだとかとなると、ここはヤバイと分っていても使うしかない。


使ってみてダメだったら、ダメでしたという実績を盾にして外すことも可能だが、やる前から予測としてダメだと分析したから外しますとは言えない。


ホスト系と言われる昔のシステムは、ハードメーカーがホストコンピュータを作った時に、それ専用のOSも作成しましたというもので、UNIXやWindowsなどのオープンされたOSで動くコンピュータの性能が上がってくるまでは、専用ハード+専用OSじゃないと大規模な処理はやれなかったので、昔の大規模システムってのはホスト系になる。


そういうのを作っているのは、FとかHとかNとかOとかそういうとこで、半分財閥みたいなものだから、当然政治的なコネが重要になる。


かつホストコンピュータを入れるような億単位の予算がかかるシステムは、動く金の単位が違うので、これまた庶民感覚をはるかに外れた政治的な話になる。


正直FとかHの仕事で良い話は聞いたことがないし、実際関わって最悪だった仕事は、某大企業の合併で、元々がバラバラのFとOとIのシステムを統合する案件で、何につけても全てが最悪の典型的デスマだった。


統合合併に至るぐらいだから、派閥的とか歴史的に言ってそういう必然性があるお仲間内の企業ではあるのだろうけれど、実際には文化のレベルでバラバラなので、お互いにこれはAのことだよねと言っているのに、そのAがまったく一致しない。用語のレベルから、ファイル取り込みっていったら何のことなのか、辞書作って統一しないといけなかったという、ものすごい案件だった。




今回のはそこまでメタメタではないが、あるベンダーがやっていた作業を、そこがリタイヤしたから他のベンダーで分割して引き継ぎますとなった場合に、クライアントからヒアリングして、A社ではこういうニュアンスで設計しましたという部分が、B社が引き継いだらニュアンスが変わってしまって、クライアントからはクレームになり、クライアントとしては一旦時間と予算を割いて仕様出しはしたのだから、そっちで何とかしろって話になる。


エリートであらせられるお客様は分刻みの超ハードスケジュールだから、金は請けた側で持ちますと言っても、時間は捻出できないので、作業はどんどん遅れるみたいな。


論理的に書いてあるコンピュータシステムの設計書でさえも、企業というか、人を跨げばさっぱり伝わらない。


システム製造って仕事を、人間がやっている限り、政治による分断や不公平な受発注は避けられないし、文化の違いによるオーバーヘッドは不可避。
つまり一定以上に大きい案件では、どこかのタイミングでデスマが発生するのはほとんど当たり前であり、どんだけ頑張ってもデスマを完全に防ぐことは出来ないのではないかと思える。