2019年4月1日、新元号の発表がありました。いよいよ、2019年5月1日からは、新元号「令和」になります。
さて、新しい時代の始まりだ！と思ってるのもつかの間ですよ？
私は、かつて人事給与システムの開発に携わっていたので、新元号が変わることで、何かしらシステムに影響が出てくると思っています。
システムエンジニアやプログラマーには、どのような影響があるのか？そして、どう考えても修正が必要になる可能性が高いので、システムが受ける影響とどのような修正が発生するのか、そしてかかる工数はどのくらいか？見積もってみましょう！
システムが受ける影響って何？
人事給与システム開発を行っていた私が、真っ先に思い浮かんだのが、「帳票」です。
例えば、人事給与システムでは、従業員の給与明細を紙に印刷したり、WEB明細といって、従業員がいつでも社内システムにログインして、WEB上で自分の給与明細を確認することが出来るものがあります。
となると、その明細に、平成〇〇年5月度給与明細などの印字がしてある場合、2019年5月以降は、この「平成」の部分を、「令和」に変更しなければなりませんよね？これが、明細を印刷・表示するシステムへの影響です。
また、平成ではなく、アルファベット(平成＝H)と表示している場合も、令和のR変更をする必要性があります。
新元号になったのに、いつまで経っても平成とかHでは、おかしいですよね＾＾；
しかし、この問題、ちゃちゃっと直せばいいやろ！と思ってるかもしれませんが、これも微妙なところで、以下２つの意見に分かれると思います。
帳票の表示はどうするの？
※あくまで、月末締めの翌月給与支払いの場合を例にしています。
その2つの意見とはこれです。
①新元号の表示は、2019年6月からだ！
②新元号の表示は、2019年5月からだ！
ん？どういうことか順番に説明していきましょう
①令和の表示は、2019年6月からだ！
新元号に変わるのはあくまで5月です。
4月分の給与に関しては、まだ平成だった時であるため、4月度の給与明細を表示させる5月度の表示は「平成」のままで良い。
だから、令和を表示させるのは、元号が変わった5月分の給料(6月支給)から対応させるべきである。
という、ごもっともな意見。
②令和の表示は、2019年5月からだ！
いやいや、5月から新元号に変わってるんだから、令和にしておこうよ。
表示するのは2019年5月なんだし、この時点では、平成でなくなっているでしょう？だから、表示も令和にしておくべきだ！
と、意見がわかれるかもしれません。
ここは、単に表示の問題ですから、要件定義のときに、顧客と話し合い、決めるべきです。
※表示が西暦であれば、影響はないので、特に修正の必要はありません。
では、システムの影響調査をして、修正が必要になった場合、どのような修正内容になるのか見てみましょう。
修正する内容
では、実際に、どういう修正内容になるのか？見ていきましょう。
例として、先ほどの①案になった場合で考えてみましょう。
【修正内容】
西暦2019年6月以前の明細を表示する場合は、「平成」もしくは「H」※2019年5月までの表示
西暦2019年6月以降の明細を表示する場合は、「令和」もしくは「R」※2019年6月からの表示
という分岐条件をあらたに書き加えなければなりません。
※場合によっては、紙明細の場合は平成と新元号それぞれの帳票フォーマットを用意するかもしれません。
紙の明細でも、WEBの明細でも、過去の明細をもしかしたら印刷したり、表示させる場合があるので、2019年5月までは、平成で表示されるが、2019年6月以降の明細においては、新元号が表示されていなければなりません。
では、この修正を行い、本番環境に適用するまでの流れや工数を見てみましょう。
修正手順とかかる工数
※2人で調査や要件定義、資料作成、プログラミング、テスト、本番移管作業を行う場合を想定
①調査と資料作成
⇒要件定義に行く前に、新元号「令和」になることで、既存システムのどの部分に影響が出るのかを調査します。
また、修正しなければならないモジュール(機能)を洗い出します。
かかる工数⇒2人で1日。
②要件定義
①でまとめた資料を作成し、要件定義へ行きます。
システムが受ける影響、修正内容、工数の見積もり、スケジュールの確認などを提示して、GOサインをもらいましょう
かかる工数⇒2人で1日。
③基本設計書の作成
要件定義が終われば、あとは開発・修正作業に入っていきますが、ドキュメント作成も納品物なので、ちゃんと作成しましょう。
かかる工数⇒2人で0.5日。
④詳細設計書の作成
基本設計書が出来たら、レビューなどを行い、その後詳細設計書を作成しましょう。
修正内容が少ないので、詳細設計書もすぐに書き終わるでしょう。
かかる工数⇒2人で0.5日。
⑤プログラミング作業
さて、実際にプログラミングを行い、ソースコードを修正しましょう。
修正するモジュール数によって、工数は異なります。
２，３か所の修正だと想定して、
かかる工数⇒2人で1日
⑥単体テスト
プログラミングが終わったら、まずは単体テスト計画書の作成、データの準備、単体テストの実施を行います。
テストパターンとしては、
①2019年5月までの給与明細は、平成で表示されていること。
②2019年6月以降は、新元号が表示されていること。
③修正前後で、元号以外には影響がないことを確認する
で良いかなと思います。
ひとまず、修正を加えた部分の検証と、修正したことで、他の箇所に影響がないかの確認が出来ればよいかと思います。
かかる工数⇒2人で2日
これが終われば、実際の本番データを使って、テストをします。
⑦システムテスト
システムテストの環境というのは、本番実データが用意されている環境のことを指します。
本番稼働前のリハーサルですね。この環境は、後のユーザーテストでも使用します。
まずは、システム計画書を作成。かかる工数：2人で1日
環境・テストデータの準備⇒かかる工数：2人で1日
テスト実施、結果のまとめ、レビュー：2人で2日
さて、次は、ユーザーに確認をしてもらいます。
⑧ユーザー検証
ユーザー検証では、開発側で作った手順書などを見てもらいながら、実際の業務と同じ流れで確認をしてもらいます。
ユーザー検証計画書、実施手順書の作成⇒かかる工数：1日
ユーザー検証の実施⇒3日くらいは確保しておきましょう。ユーザーも普段の業務をしながらなので、〇〇日までに確認をお願いします。と前もって、メールや電話でお願いをしておきましょう。
テストデータは実データを使うので、環境が整っていればそのまま使用すればよいです。
さて、ユーザーから、オッケー(合格)を頂いたら、本番環境への移管作業を行います。
⑨本番移管作業
修正したモジュールの移管作業を行います。
やり方においては、各プロジェクトで決められているやり方で進めてください。
プロジェクトによっては、本番移管作業計画書・報告書を作成する場合があり、リーダーの承認を得てやる場合もあります。
無事に本番移管作業が終わったというエビデンスを取得する必要もあるので、作業のやり方においては、確認をしてから、慎重にやりましょう。
かかる工数⇒2人で0.5日
ここまでの作業で、2人で14.5日かかるであろうと想定しています。
だいぶ、余裕をもったスケジューリングをしてみましたが、急ぎの場合は、もっと前倒しになると思います。
納期があると思いますから、リーダーや顧客と話し合って、決めてくださいね。
まとめ
ということで、平成から令和に変わることで、システムが受ける影響と作業手順、修正にかかる工数の見積もりをお伝えしました。
既に、改修作業に取り掛かっているプロジェクトも多いと思います。
漏れがないように、影響範囲をしっかりと調査して、作業に手戻りがないように、慎重かつ迅速に作業していってくださいね。
