モデルで作成しても品質が上がらない

あるお客様から「モデルで作成すると可読性が上がり、品質が良くなると思ったが、
そこまで品質が良くなった気がしない、モデルベース開発って本当に良いものなの？」
とお話を頂くことがあります

いくつかのケースが考えられるのですが、
実際にモデルを拝見させて頂くと、下記のようなモデルになっている事例が散見されます。

望ましくないモデリング例

例１.ロジック全体をStateflowのフローチャートで作成している

・ロジック全体をフローチャートで記載しているため、メリットである抽象化の概念がない
・構成が把握しづらく、変更作業に多大な工数が発生する
・既存のCソースやフローチャートを利用して、モデルベースに移行するときに起きやすい

例２. Simulinkブロックを使用して、複雑な状態遷移を作成している

・Stateflowの状態遷移図があるにも関わらず、なぜかSimulinkブロックで状態を記載している
・動作状態の設計を行わずに、「まずはSimulinkで動くものを作る」という考えだと陥りやすい
・開発規模が大きくなると、変更作業で不具合が発生し始めるため、
　リバースエンジニアリングして、結果的に状態遷移図のドキュメントを作成することになる

例３.Simukink上でFrom/Goto配線を多用している

・サブシステム間の関係が把握できなく、データの流れが可視化できていない
・複数名でサブシステムを作成して、From/Goで接続しているケースで陥りやすい
・ソフトウェアの依存関係が見えづらく、変更作業で不具合を発生しやすい

※　上記は比較的小さなロジック作成の懸念事項になります
　　From/Goのすべてを否定しているわけではありません

まとめ

上記は一例になりますが、ロジックとモデルには相性があるため、
それを活かしたモデリング手法を選択することが重要です

モデルのメリットでもデメリットでもありますが、シミュレーションで簡単に動くため、
「動く＝正解」で設計の妥当性を考えてしまうと、品質の悪いものになります
（機能要件を満たしても、非機能要件を満たしていない）

また、一度作り込んでしまうと、リファクタリングするモチベーションがない組織が多いため、
そのまま放置されているケースが多く、開発規模が大きくなると、徐々に不具合を発生させ、
負のスパイラルに陥りやすくなります（技術的負債が増加します）

そのような事態を避けるために、
事前にモデリングの特徴を把握してから、モデル作成に取り掛かりましょう

それが結果的に、手戻りの少ない開発を実現することにつながります