同時並行型PJの難しさについて

投稿日: 2025-05-05 | カテゴリ: SIer

今日は、同時並行型PJについて話していこうと思います。同時並行型PJとは、古いシステム（旧）と新しいシステム（新）を同時に動かしながら、開発や運用を進めていくプロジェクトとなります。例としては、MicrosoftのOutlookが分かりやすいかもしれません。 2025年5月現在、OutlookはOffice2016、Office2019のどちらもサポート対象となっており、ユーザーは好きな方を選んで使えます。

Microsoftのような大手企業であれば、こういったやり方でもうまく進められるのかもしれませんが、今日はSIerの立場から、同時並行型でシステムを開発する難しさについて語っていきたいと思います。

旧システムチームと新システムチームの連携の難しさ

最もヒューマンエラーが起きやすいのが、旧システムと新システムで足並みをそろえて進めることの難しさです。

ユーザーからすると、旧システム・新システムどちらを使っても同じような操作で、同じような処理が行われることを期待します。特に基幹システムともなると、それぞれのシステムで別の処理がされてしまうと、顧客に大きな損害を与えてしまいかねません。

しかし、例えば新システムだけ先に新機能をリリースしてしまった場合、旧システムがそれに追いついていないと「デグレード（機能が落ちる）」状態になります。逆のパターンでも同じです。

「そんなミス起こるの？」と思うかもしれませんが、システムの規模が大きくなると、こういったことは十分に起こりえます。特に、旧システムと新システムの担当部署が違う場合には、さらに起こりやすくなります。

なぜこういった問題が起こるのか

根本的な原因は、「自分の担当外のことには責任を持たない体制」になっていることだと思います。例えば、旧システムを担当するリーダーにとっては、新システムがどうなろうと関係ないですし、その逆も同じです。こういった意識のまま開発を進めていけば、当然、連携ミスは起こり続けると思います。もしマネジメントだけではこの意識を変えられないのであれば、「同じ部署（それでも解決しない場合、同じチーム）」で新旧システムを開発・運用するしかないのかなと感じます。

保守費用が二倍になる

こちらは開発者というより経営者の視点になりますが、システムを同時に稼働させるということは、保守費用が単純に2倍になるということでもあります。

業務システムなどでは、法改正などがあるたびにシステムの修正が必要になりますが、通常なら1つのシステムだけを直せばいいところ、同時稼働の場合は2つとも改修しなければなりません。

その結果、サーバー代や人件費も2倍になります。この辺りは、プロジェクトを始める段階で予想できていることだとは思いますが、とても重要な点なのであえて書いておきます。

顧客の立場では、いきなりシステムが変わると困るので「並行稼働してほしい」となるのですが、経営側としては、その裏にあるコストやリスクもしっかり考えたうえで判断すべきだと思います。

また、もし新旧システムの仕様が違っていた場合には、それだけで大きなユーザー被害につながる恐れもあります。

まあ、とはいえ、SIerとして「同時並行PJは難しいから、うちでは無理です」なんて言ったら、「この会社、PM力がないのか」と思われかねないので、なかなか正直には言えないのが現実ですね…。

まとめ

最初に書いておくべきだったかもしれませんが、私自身も実際に同時並行型PJに参加した経験があるので、今回この内容を書いてみました。

そのプロジェクトでは、部署間の連携がうまくいっておらず、私のような下っ端が別部署の偉い人に色々言っても、正直、聞いてもらえるとは思えず、身動きが取れませんでした。

自分にもいろいろ反省点はあるのですが、ひとまず今回はここまでにしておこうと思います。

以上です。お読みいただき、ありがとうございました！