今まさに、企業は、崖の恐怖とDXの流行でシステム刷新を推し進めようとしています。
まずシステム刷新がどういうものかを簡単に説明します。システム開発には、大きく分けて2種類あり、一つは、新業務や新たなビジネスモデルに対応するために新規にシステム開発を行うもの、もう一つが、既に稼働している現行システムの老朽化や業務変化に対応するためシステムを再構築するものです。この後者の既存システムを新しく作り変えることをシステム刷新と呼びます。
最近は、デジタル化に対応すべく、新規開発でも刷新でもDXを踏まえたシステム開発が主流です。2018年に経済産業省から出されたDXレポート「2025年の崖」で提言されたデジタル化に向けた基幹システム刷新の取組みも、まさに刷新の代表的なものです。
さて、ここで問題です。新規開発とシステム刷新と、どちらが難しいと思いますか？
DXレポートを読まれた方はわかるかもしれませんが、これまで20年以上のシステム開発の経験上、システム刷新の方が圧倒的に難しいです。
今回の記事では、実際にシステム刷新を行ううえでの難しさと、刷新プロジェクトの成否を握ると言っても過言ではないキーパーソン、さらにそのキーパーソンへの接し方について書いていきます。

かんたんイラスト（記事を読む時間のない人へ）

エンジニアによる考え方の違い

JUASが毎年発表している企業IT動向調査報告書によると、「既存ビジネスの維持・運営」のためのIT予算（いわゆる既存システムの維持管理）と「ビジネスの新しい施策展開」のためのIT予算（つまり、新規システム開発）の割合は、既存システムの維持管理が8割で、新規開発が2割です。徐々に新規開発が増えてはきているものの、この割合は、ここ10年大きく変化していません。これを単純換算すると、ITエンジニアの8割は既存システムに関する仕事をしているということになります。この２つの仕事に就くエンジニアには、考え方に違いがあります。極端に言ってしまうと、QCDの中で大切にするものが違います。当然プロジェクトの内容や状況によって異なりますが、既存システム維持管理のエンジニアはQ（品質）を、新規開発エンジニアはD（納期）をプライオリティ高く考える傾向にあると思います。システム刷新プロジェクトを進めるうえでは、この考え方の違いを認識したうえで、現行システムの担当者と関わりを持たないと危険です。

システム刷新が難しい理由

システム刷新プロジェクトは、単純に現行システムと同じものを新しい仕組みで作ることだけが目的ではありません。もちろん現行システム機能の再現も必要ですが、加えてコスト削減や業務効率化など＋αの付加機能も付けることが一般的です。システム刷新において必要となる「現行システムの再現」と「付加機能の開発」の2つの観点について、難しい理由を説明します。

１．「現行システムの再現」の難しさ
現行システムと同じにすればいいから簡単ということはありません。現行システムの規模や経過年数など状況によりシステム刷新で発生する作業量は大きく変わってきます。一般的に、規模が大きければ大きいほど、また運用期間が長ければ長いほど、大変です。なぜなら、下記のような状況が想定されるからです。
・設計書などドキュメントが残っていない（あるいは最新化されていない）
・運用期間に多くの変更が入っている
・初期開発時のエンジニアがいない
これは、「2025年の崖」でも課題として挙げられていますが、まさに、その通りで、設計書が残っておらずブラックボックス化している、また多くの変更が繰り返し入れられた結果、複雑な作りで肥大化してしまっているのです。「現行システムの再現」のためには、まず現行システムの仕様を明らかにしなければなりませんが、現行システムの設計書が無く、また仕様を詳しく把握しているエンジニアもいなければ、現行システムの動作をいちいち確認し、時には、プログラムソースコードの解析をしなければなりません。この現行システム調査によって仕様を漏れなく洗い出すことは非常に大変な作業となります。この作業には、現行システムを維持管理しているエンジニアの協力が不可欠ですが、エンジニアとして考え方の違いもあり、納期優先のシステム刷新の計画に対して現行システム担当者は、今の運用の方を優先度高く考えています。この現行システム担当者の作業が予定通りに進まない、漏れなく現行の仕様を明らかにできない、ということはよくあります。

２．「付加機能の開発」の難しさ
現行システムに+αの機能を付加する際、業務を変えずに利便性が上がるのであれば良いですが、業務の変更を伴う場合は、ユーザーの抵抗が考えられます。また、特に基幹システムなどカスタムメイドで作られていた現行システムをSAPなどパッケージ製品に置き換える場合は、見た目の変化にもアレルギー反応を示すユーザーは多いです。特に長い期間使ってきたユーザーにとっては、現行システムが体に染みついているので、その慣れも含めて、再構築するシステムへの要望が多くでる可能性はあります。その要望に対して、予算と納期を鑑みつつ、スコープ調整して進めていくことに難しさがあります。

「付加機能の開発」の難しさは、新規開発でも刷新でも必要であり、スコープ調整などでユーザーと戦うこともありつつ、基本的にはユーザー部門とうまくコミュニケーションして進めていくことが必要です。一方、システム刷新は二人の敵と戦わないといけないです。敵と戦うと言うと、言葉が悪いですが、ユーザー部門に加えて、現行システムを維持管理している担当者ともうまくコミュニケーションをしていくことがとても大切となります。

現行システム担当者の立場

現行システムを維持管理する担当者の本業は、現行の業務に支障がないように現行システムを運用していくことです。システム刷新プロジェクトが発足し、進みだしたとしても業務は毎日行われていくので、現行システム担当者は、現行の運用を行うのに加えて、システム刷新プロジェクトにも協力しなければならないです。当然、現行業務に支障があってはならないので、現行システム運用作業の方がプライオリティ高くなります。
また、現行システムの開発当初から関わった、あるいは長く運用している担当者にとっては、そのシステムは自分たちの努力で作り上げたかわいい我が子のような存在です。その現行システムを置き換えるとなれば、心の中では面白くないと思っている人もいます。また、現行システムだけを長くお守りしてきた担当者は、刷新によって自分の仕事がなくなってしまうかもしれないという不安もあると思います。一方、企業にとってシステム刷新は経営上の至上命題ともなり得る施策であり、現行システム担当者としても、協力する気持ちは少なからずあるはずです。現行システム担当者は、このような複雑な感情で、苦々しい気持ちを抱えて刷新プロジェクトに協力しなければならない立場でもあるのです。

システム刷新におけるキーパーソンは現行システムの重鎮

新たに作るシステムの仕組みや開発言語は現行システムと異なることが多いので、現行システムの仕様を明らかにするためには、維持管理にあたっている現行システム担当者に頼ることが多く、下記の場面で協力が必要となります。
・現行システムの仕様を教えて欲しい
・現行システムを使いたい（あるいは接続したい）
・現行システムからデータを抜いてほしい
・現行システムと比較検証をしたい
また、現行システム仕様の代弁者として、システム刷新の仕様検討会など多くのミーティングにも参加してもらうため、現行システムの運用をしながら、刷新プロジェクトにも関わることになり、これまでよりも格段に負荷が高まることになるのです。刷新プロジェクト側も当然計画があり、納期がある中で推進する必要があるため、現行システム担当者の協力の度合いは、推進に大きく関係します。
長く運用されてきたシステムは、維持管理のエンジニアも変わってきていることもあり、断片的な知識しかなかったりする場合もあるため、この状況で最も頼ることになるのは、現行システム担当者の中でも長く運用に携わっている重鎮のエンジニアです。詳細は、重鎮に聞かないとわからないということは良くあり、この重鎮こそ、刷新プロジェクトにおける最重要人物の一人なのです。
このような背景がある中で、刷新プロジェクトのメンバーが、協力して当然のような態度で現行システムの運用チームへ意気揚々と乗り込んでいくと、痛い目にあうことがあります。もちろん人によりますが、現行システムの重鎮が気難しい人であった場合、そのような態度や地雷ワードによってへそを曲げてしまい、非協力的になってしまったら、それこそ刷新プロジェクトは停滞しかねません。クライアント企業にとっては、「仕事なのだから協力して当然だ」、「そんなことは現場でうまくやってくれ」と、些細な問題に考えがちですが、現行システムの仕様を握っている重鎮は、まさにシステム刷新の成否を握っているのです。少なくともシステム刷新プロジェクトを請け負うプロジェクトマネージャーは、とても重要な課題として認識しておく必要があります。

重鎮への接し方

では、刷新プロジェクトとして、この重鎮に対してどのように接するのがよいのでしょうか。その対応のアイデアを、以下にあげますが、完璧な答えはなく、非常に気を使う問題というのが実際のところです。
・キーパーソン情報をプロジェクトで共有
これは、現行システムの重鎮に限った話ではありませんが、プロジェクトでは、クライアント側のIT担当者、業務ユーザーなども含めて、キーパーソンは必ずいます。ここで言うキーパーソンとは、プロジェクトの推進に影響を及ぼす可能性のある人です。そのようなキーパーソンの情報は、必ず事前に人柄性格も含め情報を収集しておき、プロジェクト内で共有しておくことが大切です。
・人たらしを充てる
世の中には、誰とでも仲良くなれる人たらしや、年配者の懐に入り込むのが上手い親父転がしが、男女を問わずいます。このような相手の懐に入るのが上手い人がプロジェクトメンバー内にいれば、重鎮のカウンターとして専任にしてしまうのも一つの手です。
・プロジェクト開始前に重鎮に挨拶
プロジェクト開始時点で現行システムの重鎮には、しっかりと挨拶をしましょう。ばかばかしいと思うかもしれませんが、これでプロジェクトが推進しやすくなるのであれば、した方が良いに決まっています。重鎮は年配者であることも多いため、このような礼儀を軽視すると後々まで良くない印象を持たれることもあるので、挨拶をして損することはありません。
・現行システム担当者をプロジェクトに引き込む
気難しい人と長い期間うまくやり続けることは大変ですし、リスクは変わりありません。重鎮の他に比較的若いエンジニアがいれば、その人を現行システム維持管理から剥がして、システム刷新プロジェクトに100%引き込んでしまうのも手です。現行システムのことは、その人にお願いする。その人が重鎮とやり取りすることで、多少の手間がかかることになるかもしれませんが、長い目で見るとリストは低減します。
・やらない方が良いアプローチ
会社員であれば、重鎮にも上司がいます。重鎮が協力的ではない場合に、重鎮の上司にアプローチして、上司から重鎮に指導してもらうこともやり方としてはありです。ただし、これは、経験的におすすめしません。より関係を悪化させる可能性もありますし、結局、重鎮が握っている情報や知識が鍵なので、それをうまく提供してもらうためには、強硬策はあまり得策ではないです。

まとめ

システム刷新は既存システムがあるからこそ難しいのです。現行システムの重鎮は刷新プロジェクトの成否を左右するキーパーソンの一人であることは確実で、システム刷新のプロジェクトマネージャーは、この重鎮にいかに協力的にプロジェクトに関わってもらうかを考えて、プロジェクトを推進することが大事です。重鎮とはいえ普通の人なので、一番大切なことは、重鎮の気持ちや立場を考えて、尊重しながら接していくということが結論なのかもしれません。

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！