基幹系システムのプロジェクトが炎上する理由

多分、今まで散々語られてきた内容だと思うが、自分が中心人物として、またIT企業の一員としてプロジェクトにアサインされたのは今のプロジェクトが初であり、また絶賛炎上プロジェクトであるため、ちょっと冷静に振り返ってみたいと思う。
といっても、具体的に内容を書いてしまうと足が付くリスクもあるので、ぼかして書くことは了承頂きたい。

プロジェクトの背景

顧客の業務システムの刷新とアウトソーシングを合わせて請負う（システムと人的リソースのサービスを合わせて提供する）ためのシステム導入および業務設計が今回のプロジェクトの概要だ。
といっても初めてではなく、それでずっと食ってきている立派な事業だ。
そんな事業、なぜ今回炎上しているのか、そこをちょっと纏めてみたい。

前回のあらまし

実は今回の炎上、初めてではない。前回のプロジェクトも炎上している、去年自分が今の会社に入社してすぐ、前回のプロジェクト炎上に関しての振り返り会が実施されたので炎上の背景も知っている。
WBSも引き、ちゃんとプロジェクトは進んでいたが顧客からの再三のダメ出しと無茶な要求を呑んでしまったが為にリリースが延期したとのことだ。
また、それにより過労がたたりメンバーが次から次へと離脱、デスマーチとなった、とのこと。
うん、事実の振り返りだよねそれ。
なんか3時間ぐらいやってたけど、聴いてて苦笑いしか出なかった挙句、うんそりゃ炎上して当然、みたいなそれぞれの事実しか出てこず、次のプロジェクトではこうならないようにしようね、で終わり具体的な解決策が出ていなかった。

今回のプロジェクトの問題点を目次にして語っていきたいと思う

営業段階でプリセールスがついていない

システムと業務が一体となってプロダクトするサービスであるのに対して、顧客のシステムとの関係性やサービスの難易度、決めるべき分界点を定めるのに必要な判断が出来るプリセールスが一度も顧客とその点について話していない。
これは痛い。提供するシステムは基幹システムだ。つまりサービス先のシステムと連携することは必至。では相手のシステム群の構成を知っておき、それが自社のサービスにどう影響するかを知らなければならない。
なのに、システム営業とも呼ばれるプリセールスが行っていない。
プロジェクト締結まで、金額と請負う業務内容だけで決まってしまっている。無論見積を出す段階で、ある程度のカスタマイズは見込んで積んでいるが、システム構成なんて客先のコンサルが出してきた概要しかない。

メンバーがほとんど新人&メンターが居ない

前回の「メンバーが次から次へと離脱」、これが効いている。
アサインされたプロジェクトメンバーはPM/PMO/PL2名/TL2名/インフラ担当1名を除いて、10名ほど居るが、その10名はこの導入PJにあたり採用された新人だ。
当然、過去の導入経験や、その実務に関して、まず会社のやり方を知らない。
実務をやっていくうえで、メンターとなるべき人間がそもそもPLやTLとなっていて、主に顧客の所へ足を運び、社内にいない。
そこに何も知らない新人が置かれ、自分たちがこれからやっていく業務を調べながら学んでいかなければならない。
かつ、システムに対しての知識も持たなければいけないし、当然顧客のところに顔を出す場面もある。
そんな状況では実務がなかなか進まない。
当然だ、システムに対しても手探り、業務に対しても手探りである。
そんな状態でタスクが読めるわけがない。

兼任が多すぎる

PLがTLもやるのは当たり前、ちなみにシステム側のPL兼TLは自分とこの社長なのだが、社長という立場上このPJのみに注力できるわけもない。
結果自分がTLみたいなことをやっていた、が、自分もデータ移行の顧客・他チームとの折衝と実務、データチェックに投入、といったプレイングマネージャーをやりつつ、データ連携の設計担当者を兼務している。

仕様が決まらない

システムの仕様と業務仕様が噛み合わないと、システムを完成させても業務で必要な機能は満たせない、だが業務要件が定まらないとシステムが開発できないのでは足が遅い、その中でシステム間の連携を設計しなければならないし、データが入らないとテストもできない。
だがそのために入れる箱ができあがらない、そんなそれぞれの足並みがそろわないと仕事が進まない。
そんな状態が長く続いた。そしていきなりリリースされる新機能。
なんだそんな話いつ決まったんだ、いやむしろそこ誰が決めるべき話だったんだ。

責任の押し付けあい

それぞれのタスクが見えてない、つまり本来やらなければいけないことが洗い出せていない。
普通十年近く続いてきたサービスなら導入手順も固まっている。
だが、残念なのは全てクライアント別で縦割りになっていた構造が問題で、やり方がそれぞれバラバラ。社内での業務手順もクライアントによって違うというカオスっぷりだ。
当然、長年経験しているチームのTLやPLが、なぜそちらのチームの担当範囲が出来ていないんだ、と他チームに本来やるべきタスクをいう。
もう殴り合いだ。

顧客も相当カオス

顧客も、よくある一人社内SE状態だった。スクラッチで社内のシステムを作り上げ、二十数年にわたる歳月、カスタマイズにカスタマイズを重ねたレガシーシステム。
そしてその社内の業務から運用から、バッチ処理からデータ投入、システム設計もやっていたのはたった一人の人。
システムの全容を知っている人がその一人で、しかも運用で吸収できない部分をその人が裏から毎月手作業で補填している状態。
その人にヒアリングし、作業を依頼しなければ実態がつかめず、導入作業が進まない。
だが、その人と打合せを入れようにも定常業務を回さないと顧客の現状の実務が回らない、といった状態だ。
そうこうしているうちにヒアリングが完了しないまま半年が過ぎていた。

段階的導入の弊害

今回の顧客は複数子会社、系列会社を持つ顧客。ちなみにこの事業では初となる取り組みだ。
歴戦の経験者たちが望むならまだしも、ほとんどが新人で構成された体制で受けるような案件ではない。
系列会社を持つところ、というと基幹システムは大体親会社から始めることが多い。
大きなところから入れて、ギャップの少ない小さい会社を入れて行く。
そうすることでカスタマイズを最小限に抑える、まぁ中規模の会社を導入した経験があるのなら考えそうなことだ。
ただ今回は違っていた。
単体で見ても今まで導入したことがない規模の会社が連なっている。
それを段階的に導入しようとしても、ほぼ新規で取り込むのとなんら変わらない。
なんなら、各社に各担当がついている。同じことを違う相手に繰り返さなければならない。当然その分工数は掛かるが、期間はギャップ埋めなのでそんなにかからないだろう、という甘い考えをしがちだ。
それ故に、圧倒的に工数が足らず遅れまくる

守られないコンティンジェンシープラン

今回、１発目のリリース自体が半年近く延期された。そもそも９ヶ月程度で納品までもっていく想定だったのだが、そもそも顧客の準備体制（実務とPJメンバーが同じで、実務を止めないわけにもいかないので、依頼した業務が滞っている）にも問題があったために延期せざるを得なくなったのは言うまでもない。結果、プロジェクト開始まで１年余りかかった。
しかも、色々コンティジェンシープランが立っては居たのだが、ほとんどの条件は成立していた、がその際に担保する対処がされた覚えがない。
顧客側は問題を抱えたままでのリリースを強く要望し、結果的に中途半端な状態を是としてシステムはリリースされ、追加された新機能と、想定して投入していたデータに齟齬があり、大きくシステムトラブルを起こすことになる。
力技でなんとかするも、データとしてはかなり精度が悪い状態。
幸い、業務に大ダメージを与えるような状態にはならなかったのでサービス自体は開始できたが、当然修正の嵐。
その中、次の連結会社の導入もしなければならない。
どんどんリリースする対象の会社が増えつつも、そこで発生しうるリスクを全て顧客が是とすることで、こちらの苦労もあちらの苦労もしったこっちゃない、といった状況で現場は疲弊した。

まとめ

さて、まとめだ。今まで上げた問題点を洗い直してみよう。
営業段階でプリセールスが入り、顧客のシステム群をちゃんと洗い出していたら、顧客のシステム構成図はもっと複雑なことが理解できていた。
そしてステークホルダーがはっきりしていれば、自身のメンバーもそうだが顧客に対しヒアリングを出来る余力を要求できただろう。
また、顧客の各会社別の違いも、そこで洗い出せていた。
次に、メンバーが新人ばかり。これは言うまでもない、教育力と離職要因の防止だ。実際、今回自分と同時期に入った別チームの同期は、PJリリースとほぼ同時に転職先を決め、離脱したのだが、終始それを上司に伝え続けたものの、対策はなされなかった。マネジメントの問題だ。
兼任が多すぎる、これも当然メンバー構成の問題だ。相手の規模がはっきり見えていなかったからこそ、前回炎上したPJ並みに人が居ればいいだろうと思ったのかは分からないが、プロジェクトの中枢たる人間が兼務ばかりでは当然承認や判断のスピードの低下を招く。
挙句、仕様の足並みが揃わず責任の押し付け合いが始まる。二人三脚がうまくいかないときの子供の喧嘩だ。こうなるとお互いの認識の摺合わせをしなければならない。ついでにやり方もそろえないと動きは揃わない。
ただ、問題はお互いのやるべきことが明確でない事、それ故にやり方が揃わない、やるべきことを見落としていてはすぐに足並みが崩れてしまう。
故にWBSというものは、タスクが見えているから引けるものであって、タスクが見えないWBSなんてものはたんなるざっくりスケジュールでしかない。
あとはユーザー企業あるあるの問題だ。刷新しようとしているPJチーム自身が社内のことを全くわかっていない。
自分たちの業務は分かるが隣の事は隣に聞いてくれ、なのだ。
これだからサラリーマンというやつは、と言いたくはなるがこちらもサラリーマンだ、でも違うのは「人によって他の所の仕事を意識して出来る人とそうでない人がいる」ということだ。

ちなみに炎上するな、と見えていたのはプロジェクト開始後３ヶ月ぐらいだった。
ただ、あまりにも最初の頃はまだまだド素人である。大きな口は叩けない。
今も大きな口は叩けない。

なんせうちの社長が平謝りするタイプだからだ。身を守れない。そして私は自分を守れない人を尊敬できないし、自分自身を守ることを結構意識するタイプだ。
自己犠牲を支払いもするが、それは相手に対価を求め、それが満たされなければ平気で冷酷になる。それがサラリーマンだ。

にしても自分はよくやってきたと思う。周りが散々、力技ですれば早いのに、というが、だれでも使える機能が用意されているのにわざわざエンジニアでないと出来ない作業方法でやることを薦めてくる経験者たちを押しのけ、使える機能を使うことで、他の人でも作業ができるようになったし、その機能の特性も理解できた。
また、顧客のエンジニアに気に入られたことで、顧客のシステム構成図がかなり鮮明に描けたことで、システム連携の設計も非常にやりやすくなった。
また、それ故にこちらの機能の限界を悟ってもらい、不足分を顧客側機能で吸収してもらうなど、非常に顧客側エンジニアにも助けていただいた。
業務知識がなければ当然顧客と話が出来ないので、業務知識も身に付け、何よりシステムの基本設計をした人から怒られつつも多くを学ばせてもらいながらデータ移行として多くの人と関わった。
たった１年で顧客のPJのほとんどのメンバーと顔を合わせている。下手するとPJの中で一番顔が知れているかもしれない（うちの社長もといPLですら知らない人とも顔を合わせている）
体調不良で休むと、大体PMOから心配されるくらいのキーマンであることは誇りでもあるが、正直自分がキーマンになってしまうのならもっと給料をくれ、とも思っている。

世知辛いね、アーキテクト、社内SE（導入系）、プリセ、運用でどこかいいところあったらお声かけてください。経歴書送りますです。　

おしまい。