複雑に絡まったレガシーシステムを紐解いていく 派生開発の効率化に貢献する「Lacat」
左から、システム研究開発センター永澤 敦彦さん、津村 耕司さん、岩崎 瑶平さん（所属は取材時点のものです）
多くの企業は、次の時代の生き残りを賭け、ビジネスプロセス・ビジネスモデルの改革を迫られています。そのためには、新しい開発や投資だけではなく、既存の基幹システムを時代に合わせて段階的にアップデートしていくことが大変重要です。しかし、その実施には様々なハードルがあり、担当エンジニアは大きな苦労を背負っています。このような状況を改善しようと、当社のシステム研究開発センター（以下、シス研）では、2013年より事業部と連携しながら研究開発を行い、ソースコード解析技術をベースとしたソリューション「Lacat（ラキャット）」を開発。開発に携わる、永澤 敦彦さん、岩崎 瑶平さん、津村 耕司さんに話をお聞きしました。
20～30年使い続けている大規模システムを時代に即してアップデート
――既存システムの段階的なアップデートとは、どういうことを指しているのでしょうか？
永澤：当社はこれまで、数多くの企業の基幹システムを構築してきました。当社の親会社である、日本製鉄の製鉄事業におけるシステムもあれば、流通・旅行業界のお客様においては、ネット上での注文からサービスを完結するようなシステムもあります。あるいはバックヤードの間接業務を効率化するようなものもあります。
これらのシステムは企業のビジネスの根幹かつ大規模なものが多く、20～30年使われているものも少なくありません。いわゆる成熟したシステムで、COBOLやJavaといったプログラミング言語で組まれている場合が大半です。
岩崎：現在も動いている重要なシステムであるからこそ、全てを一から刷新することは難しい。でも、時代の変化に合わせたアップデートは必要です。新しい機能を追加するといったビジネス的な対応もありますし、法務やセキュリティの観点からシステムを強化するための仕様の追加や変更などもあります。
そこで私たちは、既存ソースコードの変更や修正、追加、削除などを行い、対応しています。このようなシステムにおけるソフトウェアの改善を、小規模改善と言います。保守、派生開発、エンハンスとも呼ばれています。
成熟したシステムであればあるほど膨らむ維持コスト
――派生開発は難しく、かつ、苦労も多いと聞きます。それはなぜでしょう。
永澤：まず解きたいのは、派生開発は簡単、といった誤解です。特にユーザー側には、「わずか1行を改善するだけなんだから、時間もお金も、それほど必要ないだろう」と思われがち。このように、派生開発業務が軽視されている場合が少なくありません。
しかし実情はまったく異なっています。わずか1行や1画面を変えるといった小規模改善であっても、既存のシステムの機能を正確に維持しながら、トラブルやエラーなく派生開発を完璧に行おうとすると、予算は数百万円から数千万円、場合によっては億を超え、工期も数カ月から1年を超えるような場合があるからです。
――仕様を少し変えるだけなのに、数千万円に及び場合もあるというのは驚きです。なぜ、そんなにかかってしまうのでしょうか。
岩崎：派生開発のコストは主に3つあります。1つは一般的な開発コストであり、同コストは、新規にシステム開発する場合と、特に変わりありません。ただそこから先、新規のシステム開発では発生しない、「既存機能維持」「技術的負債」といったコストが加わってくることが、派生開発の費用を大きくしている要因です。
特に既存機能維持のための作業が高コストです。言葉どおり、新しい機能を追加しても、既存システムに問題が生じないようにする作業です。事前に行う「影響調査」、実装後に行う「回帰テスト」に分かれ、どちらも大変手間のかかる作業です。
津村：30年前のシステムともなれば、仕様書や設計書といったシステムの開発や運用に必要なドキュメントが揃っていないケースが少なくありません。あるいは存在していたとしても、内容が正しくない場合もあります。つまり、ソースコードと手元にあるドキュメントが、乖離しているわけです。そのため既存システムの機能を精密に維持するためには、稼働しているシステムを構築している実際のソースコードをしっかりと調べ動作を確認しきることが、必要になってきます。そのため、必然的にコストが膨らんでしまうのです。
――なるほど。ところで、もう一つのコスト「技術的負債」とはどういったものなのですか。
永澤：これも、派生開発の業務を難しくしている問題のひとつです。簡単に言ってしまうと、ソースコードの整理整頓がされているかどうか、ということです。
最初は綺麗に整っているものですが、細かな手入れを繰り返していくと、全体のバランスがおかしくなっていきます。言ってみれば、増改築を繰り返した住宅のようなものです。1つひとつのソースコードは問題なく動いていますが、それぞれがどう影響し合っているのか、関係性がより分かりづらくなり、開発や保守作業時のミスも増え、結果としてコストが増えます。技術的負債が膨らむと、何らかのきっかけで大きな障害を発生する危険性を秘めてしまうのです。
岩崎：技術的負債は、派生開発を行うたびにかさんでいくコストです。ただ「やりづらさ」といったタイプのコストであり、定量的には見えません。そのため技術的負債をいくらかけて解消すべきか投資判断が難しい、という問題もあります。
苦労の多い業務のためエンジニアの負担が多く、かつ、業務が属人化していることが多い
――聞いているだけで、苦労の多い業務であることが伝わってきます。コストが大幅にかかるというのも、理解できますね。
永澤：ええ。お客様にはしっかり説明してご納得いただけるよう努めています。しかし一方で、レガシーシステムにそこまでの予算をかけづらいという現実もあり、対応を保留する選択をされるケースもあります。ただそうなると、最悪の場合システムが正常に稼働できなくなってしまうこともあります。
岩崎：そうならないために、熟練されたエンジニアが影響を受ける可能性の高い特定箇所のソースコードをピックアップするなど、過去の経験に頼りながら保守対応をしているというのが現実です。またCOBOLなど多くのレガシーシステムで使用されている技術を扱える若いエンジニアが少ない、という問題もあります。
属人的な知識やノウハウに依存している状態では、熟練層の退職後は、誰も手もつけられなくなってしまう。実際、長年保守を務めてきたエンジニアが退職してしまったために、システム構成も分からないまま、綱渡りで動いているようなブラックボックス的なシステムもありますからね。
津村：また、そうやって属人的な対応をしていると、どうしてもミスが生じることがあります。そもそも修正やテストを施すべき箇所が間違っていたり、同じく修正やテスト箇所に漏れがあったり、あるいは修正方法が違っていたり。その結果、派生開発後のシステムが正しく機能しない。場合によっては、システムに壊滅的な障害が生じてしまう可能性も、ゼロとは言い切れません。
適切な例えでないかもしれませんが「寝室の電球を交換したら、玄関の扉が消失してしまった」といったことが、システムの派生開発では起こり得るのです。当然ですが、お客様へのビジネスへの影響は計り知れません。
永澤：だからこそ繰り返しになりますが、気になる箇所はすべてチェックするのがベストな対策なのです。
ソースコードを分析し「CRUD表」を自動で正確に作成する
永澤：このような厳しい開発環境のなか、派生開発に携わるエンジニアは、最大限のパフォーマンスを発揮しようと、若手に知識を共有できるよう定期的に勉強会を開催したり、できる限り作業を体系化することで効率化を図るなどの、努力を続けてきました。
このような現場の努力は大変すばらしいものだと思っています。ただどうしても、現場個別の工夫にとどまりがちです。それを会社全体として支えるべきです。シス研がこれまで培ってきた技術でカバーすることで、派生開発の現場で苦しんできたエンジニアの負担やストレスを軽減できないか。このような想いからシス研では、事業部で派生開発を行うエンジニアと連携しながら、派生開発を効率化するソリューションの開発に努めてきました。そうして完成したのが「Lacat（ラキャット）」です。
津村：まさにLacatのロゴにある猫が絡まった糸をほぐすように、複雑化したソースコードを解きほぐしていきたいという想いが込められています。
岩崎：Lacatは、以前からシス研で研究していたソースコード解析技術をベースに、2013年より研究開発に着手したソリューションで、COBOL版を2016年に。そして2019年にはJava版を発表。社内でPoCをいくつか実施中の段階です。
――Lacatを使うと、具体的にどのように作業が効率化され、エンジニアの苦労が軽減するのでしょう。
永澤：ソースコードには、それぞれ役割がありますよね。その役割ごとにソースコードを分類する「CRUD表」と呼ばれる機能表を、Lacatは自動で正確に作成します。CRUD表は、ソースコードの4機能である登録機能（Create）、参照機能（Read）、更新機能（Update）、削除機能（Delete）を一覧にした表です。
本来、システムを構築した段階でこのCRUD表を作成しておけば、その後の派生開発が楽になるわけです。ただこのCRUD表を作成すること自体がかなりのハードワークですし、メンテナンスも困難なため、その正確さも問われます。これらの課題を、Lacatは解決します。
岩崎：CRUD表自体も、システムの大きさに伴いかなりのボリュームになりますが、Lacatのフィルター機能などを使えば、派生開発で影響を受けるソースコードが、一発で分かります。その結果、影響を受けると考えられる箇所のみをチェックすればよいことになり、事前・事後どちらにおいても、チェックやテストの大幅な時間削減を実現します。
津村：エラーが起こり得る箇所の判断の正確性についても、Lacatは力を発揮します。従来の、熟練エンジニアの経験ではなく、客観的なCRUD表を根拠にした判定のため、テストの量が減ったとしても、エラー発生率が減ることになります。
NSSOLの次世代開発環境「Tetralink（テトラリンク）」での提供を予定
――「Lacat」の開発状況ならびに今後について、お聞かせください。
岩崎：COBOL版の他、現在はJava版の開発に注力しています。CRUD表生成以外の機能を追加していくことに加え、現場のエンジニアがひと目見ただけで問題の起きそうな箇所が分かるような、グラフィカルなUI仕様にしたいと考えています。あと、対応するフレームワークやライブラリーを増やしていこうとしています。
――実際に「Lacat」を使っているエンジニアからの評価はどうですか。
永澤：Lacatを使うことで、今まで経験に頼っていた部分を定量的に目視でき、安心感がある、業務が効率化された、との声が届いています。また、当社の新しい社内開発環境「Tetralink（テトラリンク）」上での提供も予定しています。今後はより多くのエンジニアがLacatを使うことで、派生開発業務の苦労やストレスから解放されると、期待しています。
そしてその先には、冒頭で説明したように、結果としてこれまで派生開発にかかっていたコストが攻めの領域に投資されるようになることで、お客様のさらなるビジネスの発展に寄与できれば、と考えています。
――まさに多くの大企業が直面している課題にヒットする技術ですね。期待しています！
