組込みソフトウェア開発で、よく見かける現場課題を4つに分類してみました。
(1) 担当者の引継ぎが困難 ［ソースコードしかない］
(2) 品質問題がじわじわ増えている ［影響範囲が限定できない］
(3) 少しの変更でも時間がかかる ［作った人しか直せない］
(4) IoTシステムへの柔軟性がない ［仕様変更のたびに作り直し］
動くソースコードがあって、ここ数年、そのコードの部分的改修しか実施してこなかった。そのため、ソースコードが劣化していき（ソフトウェア疲労）、かつ、担当者は設計の経験がない、という現場が多いようです。
(1) は、頼るべきはソースコードのみ。設計ドキュメントはあてにならず、初期の作成者はすでに近くにいない。
その状況下で、現象を追いかけて、部分的に修正をして、影響範囲を（その都度）検索で調査する、という事の繰り返し。常に忙しいので、図面なんて書いている暇がない（そもそも図面の書き方は知らない）。それがさらに状況を悪化させているという悪循環。自分でブラックな職場を作り上げていますよね。
「検索」が最も便利な開発ツール、「検索」がないと開発できない、という方は、このような悪循環にはまっている危険性があります。
■解決策
やはり図面を作ることをお勧めします。
といっても、いきなり図面を書くことは敷居が高い場合が多いです。（多くの開発技法が、設計⇒プログラミング、という流れですが、現実問題として、いきなり手順を変えるのは難しい）
ですので、まずはソースコードを書いて、そのソースコードを図面化する、ということが現実的です。そして、モジュールの配置を替えることで、設計意図が見えてくる場合が多いです。（★AtScopeの基本的な活用方法です）
並行して、機能追加や不具合修正の前に、リファクタリングを行います。リファクタリングすることでモジュールが増えます、その上下関係（利用関係）を図面化することで、局所的な設計意図や影響範囲が徐々に明確になっていきます。（★AtScopeでは、配置を維持したまま、再度、ソースコードから図面を出すことができます）
まとめると、
・今のソースコードから設計図を作る
・プログラム改修時は、まずは図面を見る （コード中心から設計中心への体質変換）
・プログラム改修時は、その前にリファクタリングを行う
・モジュールを構造的に見ることで、設計意図を明確にする
でしょうか。
(2)以降は、次回コラムで。