基幹システム税制変更対応

建設業向け基幹システム税制変更対応

イントロ

アプリケーション保守を行っているシステムの追加開発について伺ってきました。

「動いている既存システムに追加開発を行う」のは「派生開発」「差分開発」等と呼ばれ、それについて書かれた書籍・雑誌・Webページも多く存在します。
当然「既存機能をデグレードさせずに機能追加を行うには」が焦点となりますので、今回はその辺についてお話を伺いました。

さらに、お話の中でもうひとつ「法律の改正」という事についても伺う事が出来ました。
施行日や法解釈等、特有の事情を考慮する必要があるようです。

お話をして下さったのは、開発事業部Unit2の小林(真)さんです。

インタビュー内容

■今回の追加開発の開発期間を教えて下さい。

3ヵ月です。

■工数はどれくらいですか？

12人月です。4人ぐらいでやっていました。

■今回の機能追加の内容を教えて下さい。

「減価償却制度の変更対応」です。税制が変わって、減価償却の計算方法が変わったので、その対応です。

■減価償却というと、その企業が保有する資産のお話ですか？

そうです。今回はまさに「資産」というサブシステムの対応でした。
「どこの現場にどんな機械がある」という管理と、減価償却費の計算機能を持っているサブシステムです。「持っている資産の額」もわかります。

また、「損料」という考え方があって、100万円で購入した機械は、ある期間使うと90万円～80万円と資産価値が減っていくんです。
で、その減った額は、その機械をその期間使用した各プロジェクト(工事)に負担させます。その辺もこのサブシステムでやっています。

■その資産評価の計算式が今回の税制変更で変わったんですね。

変わりました。
その法律に従った計算式がJava内にコーディングされているのですが、それを変更しました。

でも、ただの変更ではなく、既存のロジックも残して、「法律の施行日までは旧計算式を使用」、「施行日になったら新計算式を使用」とする必要がありました。ただ、今回の処理は月次処理なので、そうシビアなタイミングではないんです。なので、3月末の資産評価を旧方式で行い、4月の同じ処理が新方式で行われるようにしました。

3月は決算の時期でもあるので、アプリケーションの入れ替えをその時期に行うのは危険なのでやりたくない、という事情があり、アプリケーションの入れ替えは決算処理が終わってから行いました。それでも4月末の資産評価の処理には間に合いますからね。

■法律の内容がどう変わるかということは、お客様から教えて頂けるのか、それともEC-Oneで調べるのですか？

お客様も調べてはいますが、EC-One側でも一通り調べました。お客様はシステムの内容は知らないので、エンジニア側で法律の内容とシステムの内容とを両方把握して対応する必要がありますから。

■その法律を調べるのは大変ではなかったですか？

今回は税制・会計方面のお話で、国から対応方針等が明確に示されていたので、さほど大変ではなかったです。

しかし、作り始めたり運用し始めたりしてから、その法律とお客さんの会社のやり方をすり合わせていくと、「こういう場合はどうするの」のイレギュラーケースが何点か見つかりました。そういうものに関しては、アプリケーションを変更して対応したものもありますし、今後国の方針や他の企業の対応や会計士さんの意見等が出てくるまで保留にしてある事項もあります。

実は、月次で資産評価をしているのはこの企業さんのルールであって、法律的には毎年度末に提示すればよいので、今回の場合は今年度末までに決まって対応できればいいんです。

■既に動いているシステムへの機能追加と言うことで、いわゆる「派生開発」と言われるものになりますが、苦労された点はありますか？

一番注力したのは「要件を聞きながら、変更すべき場所をお客さんと確認する」という作業ですね。「ここ変わるよね」「そこも変わるんだっけ」のような会話をしていました。

■現バージョンと新バージョンの並行管理はどうされていましたか？

Visual SourceSafe(以下 VSS)を使用しているのですが、現バージョンのフォルダの中身を新バージョンのフォルダに共有し、変更のあるファイルだけは共有をはずして新バージョンの為の編集を行いました。で、その状態でも、現バージョンを保守等で直す必要がありますよね。その場合、共有ファイルが対象なら、一方を直せばVSSの共有機能のおかげで両方に反映されます。

共有を外したファイルについては、仕方がないので両方を直しました。 VSSに複数ファイルの差異をマージする機能もありますが、今回はメンバー同士でコミュニケーションを取りながらやりました。画面で見るだけだと見落としもあるので、「同じファイルを編集している」という事実の共有をメンバー間で密に行っていました。現バージョン保守メンバと新バージョン開発メンバは重なっている人もいない人も居たので、そういったコミュニケーションは重要でした。

■納品が終わって新バージョンがその後の現バージョンになる時にどんな作業が発生しますか？

VSSの現バージョンのフォルダにVSSのマージ機能を使って新バージョンの変更を反映します。ただし、ファイルのマージが複雑になる場合にはVSSの機能＋人間の目で確認＆修正をしています。ここはけっこう手間がかかったのでもうちょっとうまい方法がないかなぁ、とは思いましたが。

■マージし損ねてデグレードになる等のトラブルはありましたか？

幸いなことになかったです。

■この開発で困ったのはどんなところですか？

先ほどのリリース前マージが力作業(？)になったのと、いまだに保留項目が残っているのと、実装フェーズ後半までお客さんの方針が決まらない箇所が残っていたところですね。

■他にどんな工夫がありますか？

コーディング時、既存のメソッドに手を入れて新たな分岐を追加する、という方法もあったと思いますが、それだとデグレードが心配されたので、全体がいびつにならない範囲で新メソッド(オーバーロード含む)追加を行う等、既存箇所に影響を与えないようなテクニックを使いました。 case文の嵐・if文の嵐が多くなるとソースも複雑になるし、既存部分のテストしなおしも発生してしまいますから。

これらの細かい工夫はプロジェクト内でみんなで相談しあって決めて行きました。メンバーがそういった工夫を自分で考えられる人たちでしたので。

こういった工夫のおかげで、納品後に目立ったバグは発生していません。

■既存部分のデグレードには気を使われたでしょうね。

結合テスト以降には、かなりの工数を割きました。既存機能がデグレードしていない事の確認も含めるようにし、たとえば月次処理を5年分ぐらい回す等、手厚い試験を行いました。
減価償却費計算の主な箇所はJavaで書かれたバッチで、それらを繰り返し起動するようなテストスクリプトをWindowsのbatファイルで組んで、帰るときに起動して、翌朝結果を確認したりしていましたね。ちなみにSwing画面側にも減価償却費の表示箇所があるのでそちらにも手を入れています。

また、例えばDBの区分コードが1～3までだったのが4も入るようになる、という変更があると、それを使っている箇所を全て洗い出す必要がありますよね。このシステムはOracle等のRDBではなく、ObjectStoreというODBを使っているので、Javaの中に各エンティティに対応するValueObjectクラスがたくさんあります。なので、「DBのこの項目を使っている箇所を探す」となったら「○○クラスのget△△メソッド」を探すことで全箇所の洗い出しが出来るわけです。 eclipseに「あるメソッドを使用している箇所」を全て検索する機能があるので、それを使用して全ての箇所をもれなく見つける事が出来ました。おかげで直しもれが発生しなかったので、eclipse様々ですね。(笑) RDBだと当該テーブルの当該カラムを使っているSQLを全て見つけ出すのが大変だったかもしれません。

インタビューを終えて

法改正の対応をするには、施行日前後で振る舞いを変えたり法律の条文の解釈に幅がある場合にどう対応するか等の考慮が必要なんですね。
差分開発を行う場合に、VSSの共有機能をうまく使うというアイディアはよさそうですね。