みなさんこんばんは クモです。
今日も雑談になります。
MBSE立ち上げ支援にかかわらず
コンサルティングを仕事にしていると
他のコンサルティング会社と一緒に仕事をすることがあります。
コンサルティング会社によって作法が異なることがあり
そういった手法の違いが
お客様に混乱を与えることがあります、
という話を以前にしました。
今回は、その例をお話しようと思います。
私は、どちらのやり方が正しいというのではなくて
そういった違いがあるのだな。
ケースバイケースで手法を切り替えたり
自分のやり方に取り込んでいきたい。そういった立場です。
今回は、MBSE立ち上げ支援をしていて
お客様の新機能に対してコンテキスト図を作っている場面で生じたことです。
※コンテキスト図
対象とするシステム（機能）に対し
情報やエネルギーのやり取りを明確にすることで
（つまりはインターフェースを定義する）
要求やテストケースの漏れをなくすためのもの。
コンテキスト図は、ハードウェアの機能に対して有効だと、
そのコンサルタントの方は考えているようでした。
確かに、ハードウェアは、インターフェースを考えやすいですね。
ですが、ハードウェアの構成だけでなく
論理構成をコンテキスト図にすることもあります。
既存機能でしたら、ハードウェアの構成が明らかになっているので
ハードウェアの構成を、コンテキスト図として表すことができます。
ただ、全くの新機能の場合はどうでしょうか。
どんなセンサーが必要になるのか
センサー機能を、何に割り当てるのか
どんな情報を、どのように割り当てるのか
そういった検討が必要になります。
プログラミングに詳しい方でしたら、
関数を定義する感覚に近いのかもしれません。
要求を満たすためには
どんな関数が必要で、どういった入出力になるのか。
コンテキスト図では、そういったことを明らかにすることができるのです。
そして、論理構造のコンテキスト図を作成した後に
物理構造のコンテキスト図を検討するのです。
その際に、どういったセンサーを使用するのか
複数あるセンサーをへらすことができないのか（コストメリット）
要求を満たすために機能として、システムに必要な情報は
網羅されているのか
そういったことの検討をすることができるようになるのです。
今回の打ち合わせでは
他の会社のコンサルタントの方が主導で行ったため
会議中にそういったことを指摘しませんでした。
事前にすり合わせて置かなかった、自分の反省点であると同時に
今後の教訓になった場面でした。
最後までご覧いただき、ありがとうございました。
ご意見、ご感想ございましたら
お願いいたします。
