改元に伴うシステム改修は難しい？1か月で完了するのに必要な事！

2018年5月21日 2018年5月21日

ライト

新元号の発表に伴うシステム改修をめぐり、各所で大きな話題を呼んでいる。

先日発表された改元の1ヶ月前を想定しているという発表について、システム屋界隈では「デスマーチ確定！」とか「もっと早く発表すべき！」といった声が上がり大きな波紋を呼んでいる。

しかし、システムに触れたことのない人たちにとっては、「そもそも文字を変えるだけ」といった声や「そもそも元号の変更を想定していないシステムが悪い。」「平成という文字を変えるだけでは？」といった声も聞かれます。

実際、筆者はエンジニアとして働いている身でもありますので、こういった声を聞くとどちらの気持ちも「わかるなぁ」といった感じなのですが、やはり1か月でのすべての変更は相当難しい。という結論をつけざるを得ない状況が現場では起こっています。

では、実際どんなことが問題となり、1か月は短いと言えるのでしょうか？また1か月で完遂するにはどうしたらいいのでしょうか？

1 平成から次の元号へ！変更するだけなら1か月で十分！しかしそこまでが長い。。。
2 実際に4月1日に元号が発表されたとしてのシミュレーション
3 変更が限定的というのは一部のシステム。またノウハウやメンバーが残っているか？という疑問も
4 1か月でシステム変更を完遂させるために必要なことは？
5 まとめ

平成から次の元号へ！変更するだけなら1か月で十分！しかしそこまでが長い。。。

システムの変更というと単純に平成という「文字」を書き換えるだけではないか？と思っている人が多くいらっしゃいます。

そう、確かに単純に「平成」という文字を書き換えるだけなのです。しかし、その単純に「平成」という文字を書き換えるだけという作業の為に多くの作業が発生します。

そもそも文字を変更するという作業はPGと呼ばれるプログラミングの作業となるのですが、それを行う前に設計を行うフェーズが存在します。さらに言うなれば「平成」という文字を新元号に置き換える「要件」を実現する方法を記載したり、変更することによる影響分析を行う必要があります。

そういった作業を行う前にそもそも発注を行わないといけないといったお金がらみの処理もあります。

そして「平成」という文字を新元号に置き換えるプログラミングを行った後は当然のようにテストがあります。例えば印刷して正常に文字が表示されるか？とか日付を変更しても問題なく稼働するか？といったテストです。

そういったテストを行ってようやく本番稼働を迎えてもOKという判定が下ります。もちろんそのあと2019年の4月30日から5月1日に向けて変更作業を行わないといけない可能性もあります。

ざっと記載しましたが順番を追って書くと以下の通りです。

作業見積⇒発注⇒要件定義や影響分析⇒設計書作成⇒プログラミング⇒システム的なテスト⇒業務運用テスト⇒本番稼働判定⇒本番稼働対応

細かい工程作業はあるのですが、わかりやすく書くと上記のようなところでしょう。

こうやって記載すると「うわっ！意外にやること多いな！」という人と「あれ？こんなもの？」という人とわかれると思いますが、ここにそれぞれどれぐらいかかるものか日付を入れてみると「時間かかるな」に変わると思います。

例えばすべてが1日で終わるとした場合でも以下のようになります。

作業見積(1日)
発注(1日)
要件定義や影響分析(1日)
設計書作成(1日)
プログラミング(1日)
システム的なテスト(1日)
業務運用テスト(1日)
本番稼働判定(1日)
本番稼働対応(1日)

これだけで合計9日かかります。実際1か月働く平日は20日間程度と考えたときには半分かかるのです。
実際には上記みたいに1日なんてことはありませんから、もっと日にちがかかることを想定しておくべきです。

しかし、この見積もりは現実的ではない部分がいくつかあります。次は実際に現実的なシミュレーションをしてみたいと思います。

実際に4月1日に元号が発表されたとしてのシミュレーション

上記ではおおまかにどういった作業があるか？を記載してみましたが、実際「発注」や「要件定義や影響分析」「設計書作成」といったものはもっと早いうちから着手しているでしょう。元号が発表される前に着手できる作業がいくつかあるのです。

例えば「要件定義や影響分析」は「平成」といった元号を改元することを要件として、「平成」という文字が置き換わることになりそうな個所を探し、分析していくことになるので元号が発表されていようがいないが関係ないです。

また設計書作成についても「平成」という文字を仮の文字で置き換えれば進めることはできますし、プログラミングも置き換えてある程度までは進めておくことができます。

上記のように作業を始めておいたとすると実質的に元号が発表されてからは以下の作業を行うことになります。

設計書修正
プログラミング
システム的なテスト
業務運用テスト
本番稼働判定
本番稼働対応

さて、上記のようになったところで見積もってみると結構少なくなるのでは？なんて声が聞こえてきそうですが、実は上記の中で見積もっておかなければならない重要な作業が抜けているのです。それはレビュー（確認）です。

レビューとは何ぞや？という人に簡単に説明すると「設計書やプログラム、テスト結果などを担当者間で確認し、その後上長やお客様に見せて問題ないと承認をもらう作業」です。

そういった承認を頂く作業をどこまでの方たちに行うかはシステム次第ですが、複数のレビュー会を開くとなると2日3日は見ておかないといけなくなります。だいたい上の方たちになればなるほど都合が合わなかったりするため、調整が難しかったりするわけです。

そうやって各作業に2日ずつ足し、計算すると以下のようになります。

設計書修正(3日)
プログラミング(3日)
システム的なテスト(3日)
業務運用テスト(3日)
本番稼働判定(3日)
本番稼働対応(3日)

合計18日！！もう1か月の平日稼働日なんてほぼほぼ埋まってしまいましたね。
実際には設計書の量やプログラムの量によっては1週間、2週間とかかることもあるでしょうから1か月という時間がいかに短いものかわかるかと思います。

上記のようなざっくりとした見積をしたとしても例えばプログラミングやテストをしているときに「変更点の見落とし」に気づいたり、手戻りが発生したとするととてもじゃないけど平日だけでは間に合いません。そうなると土日や深夜残業が入ってくるわけです。

いかに1か月という見積が甘いかおわかりになったのではないでしょうか？

変更が限定的というのは一部のシステム。またノウハウやメンバーが残っているか？という疑問も

日立やNTTデータといったベンダーがシステムの変更は限定的という声を上げているが、実際変更が限定的というのは一部のシステムというのが正解です。

またベンダーの立場と実際に業務に関わっている人たちの立場でものの見方が違う為、「システム変更」という立場でものを見ると限定的ですが、「業務に関わる変更」と捉えると大きく意味合いが変わってきます。

だいたいシステムベンダーの立場で仕事をしていると「システム変更」といった目線になってしまいがちなので、本当の意味で業務に影響が出ている個所まで見る機会が少ないです。そのため、「システム変更」という観点ですぐ変更できる！！となっていたとしても、いざシステムを変更したことによって業務が大きく変わってしまい多大な課題を抱えるなんてことも珍しくありません。

そういった意味で業務側のエンジニアからするとちょっと見積が甘くないかい？といった声も聞かれます。

よくお客さん側の立場でエンジニアをやっている人からするとベンダーはあくまでベンダーでしかなく、システム的な裏付けをとるといったところまでしかやってくれないことも多いという意見がよく聞かれます。

お客様がシステムを使って業務を実行してみると「今までと違う」だとか「使いにくい」なんていう要望が上がってきたりするのですが、ベンダーにはそこまでの声が上がってくることも少ないです。

例えば今回の改元についても、システム的な影響や変更箇所は局所的ですぐに対応できたとしても、「印刷物を印刷してみたら文字がつぶれてしまっていた。」では話にならないのです。

またシステムの変更箇所が限定できていない場合は限定するところから始まります。昭和から平成に変更した際のノウハウがしっかりと活かせればよいですが、中には当時システム開発をはじめておこなったところなんかは「改元」が考慮しきれていない場合もあるでしょう。

そうなると画面一つ一つを確認しなければならなかったり、膨大な設計書の変更箇所を0から洗い出さなければならなかったりといった途方もない作業が発生します。

綺麗なシステムばかりではない。

という大きな問題が立ちはだかっているのです。

そもそも前回の改元のノウハウがしっかりと残っているのか？というのも疑問が浮かびます。

前回の改元は30年前です。30年前20代だった人も今や50代。そもそもメンバーとして残っているのか？という疑問やシステムが新しくなったことによってノウハウが活かせない！！なんてことも十分にありえます。

また50代ともなれば現場におらず管理職になっている人も多数。そういった人たちが知らないシステムになっている可能性もありますので、話半分に聞かないといけないかもしれません。

1か月でシステム変更を完遂させるために必要なことは？

さて、ここまでは1か月という見積に対して難しいことを前提に述べてきましたが、ここからは1か月で完遂させようと思うとどういったことが必要になってくるのか？について述べたいと思います。

まず「要件定義と影響分析」「設計」については元号発表前に終わらせ、元号が発表されたら一括で文字置換できることが絶対条件です。あわよくばプログラミングを行ったコードや画面についても可能な限り一括で文字置換できるようにしておきましょう。

上記の準備を元号発表の前に行うことにより、元号発表した瞬間に置き換えツール発動！一気に置き換え完了させるのです。

よって置き換えツールの作成を設計段階で行っておくようにします。

また設計を行う際にはテスト設計は全て終わらせ、全ての関係課に展開してテスト対応を調整完了しておきます。できればテスト実施日程と時間、開始方法、終了方法、連絡方法もすべて決めて2019年3月末までに展開しておきます。

そうすることによって余計な調整が終わっているので2019年4月は作業とテストに集中できます。

そしてもう一つ重要なのがレビュー日程と関係者を事前に抑えておくことです。「元号対応です。急を要します。」という声とともに2019年3月末までにすべて抑えてしまうことでスケジュールを組んでしまうのです。できれば予備日を含めて各フェーズで2日ほど時間を抑えておきましょう。

ここまでの準備を2019年3月末までに実施しておけば、ほぼほぼ作業に集中することができるので2019年4月の平日のみで終わらせる可能性が高くなります。

それでもトラブルはつきものなので、何らかの変更ミスや漏れ、予想外のトラブルが発生した場合を想定し、普段より多くの人の予定を抑えておくように動けるのがベストです。どうしても通常の進行メンバーがトラブル対応に手をとられると大変なので、進行メンバーではないトラブル対応が得意な人をアサインできるといいでしょう。

こういった環境を整え準備万端で臨むことができれば対応もスムーズです。

しかし、上記のような体制は実際にはかなりハードルが高い（お金の問題や業務の問題、できる人は忙しいなどで）と思うので参考にしかならないかもしれませんが、案がないよりはマシですね。