技術的負債を減らす方法の一つとして

長く使われている製品や装置では、仕様変更や機能追加を繰り返すうちに、開発が少しずつ難しくなることがあります。

以前は簡単に変更できた機能でも、現在では影響範囲の調査に時間がかかる。

担当者でなければ処理内容が分からない。少し修正しただけでも、広い範囲の確認が必要になる。

このように、過去の開発によって積み重なった負担は、一般に「技術的負債」と呼ばれます。

段階的に整理していく方法が現実的

技術的負債が大きくなると、ソフトウェアやシステムを最初から作り直したくなることがあります。

しかし、既存のソフトウェアには、長年の不具合対策や、文書に残っていない細かな仕様が含まれている場合があります。

全面的な作り直しは、大きな費用とリスクを伴います。

そのため、現在の資産を残しながら、効果の大きい、あるいはリスクが少ない部分から段階的に整理していく方法が現実的です。

モデルを使って、複雑な部分を整理する

モデルベース開発では、制御ロジックや装置の動作、機器間の関係などをモデルとして表現し、設計や検証に活用します。

例えば、次のような部分からモデル化を始めることができます。

• 条件分岐が多く、処理を理解しにくい機能
• 状態遷移が複雑な制御
• 仕様変更が頻繁に発生する部分
• 不具合が繰り返し発生している機能
• 複数の装置やソフトウェアが連携する部分
• 実機がないと確認できなかった制御ロジック

モデルを使うことで、処理の流れや入出力の関係を確認しやすくなります。

また、モデル上で条件を変更しながらシミュレーションすることで、実機試験の前に動作を確かめられる場合があります。

既存のC言語を残したままでも始められます

モデルベース開発を始めるために、すべての既存ソフトウェアをモデルへ置き換える必要はありません。

既存のC言語を残し、その周囲の機械、センサ、通信などをモデル化する方法もあります。

また、新しく開発する機能や、特に変更が多い部分だけをモデル化することもできます。

重要なのは、モデル化すること自体ではなく、

現在の開発で何が負担になっているのかを確認し、その問題を減らすためにモデルを使うことです。

モデルそのものを技術的負債にしない

モデルベース開発を導入すれば、自動的に技術的負債がなくなるわけではありません。

スパゲティーコードをそのままモデル化すると、スパゲティーモデルが出来上がります。

モデルの構造や命名、インターフェース、テスト方法などのルールがなければ、

モデルそのものが複雑になり、新たな技術的負債になることもあります。

そのため、モデルを作るだけでなく、

• 現状の仕様を整理し、抽象化する
• モデル（機能、サブシステム）の役割を明確にする
• 適切な単位に分割する
• 接続ルールを決める
• モデルと要求、テストを関連付ける
• 継続的にレビューする

といった運用も必要です。

技術的負債が、モデルベース開発を始めるきっかけになる

既存の開発が複雑になり、仕様変更、保守、テスト、技術継承に時間がかかるようになったことをきっかけに、

モデルベース開発を検討する場合もあります。

最初から開発全体を変える必要はありません。

変更が多い一つの機能や、不具合が起きやすい一つの装置動作など、

小さな範囲からモデル化し、効果を確かめながら対象を広げることができます。

技術的負債をすべてなくすことは難しくても、現在の資産を生かしながら、

今後の変更や検証を行いやすい状態へ少しずつ改善することは可能です。

モデルベース開発は、そのための方法の一つになりえます。