前提
6/16(金曜)、品川でseraのイベントが行われたのでオフラインで参加してきました。
ここではシステムオブシステムズに関連する内容や、サステナビリティについても言及されていたので共有いたします。
代表理事 内田さん「MBSE for A-SPICEについて」
ここではSysMLなどをもちいての簡単な説明がされました。
すでに既知の内容が多くあまり新たな発見はありませんでしたが、
読んだことある書籍にも出ていたものと重複またはリンクしていたもので印象深いものをここに残します。
ミスユースケース
端的に言うと悪意を持ったアクターが対象システムに対して良からぬことをするユースケース。
この考察がなされていないと、頻繁に不測の事態が多発するシステムが出来上がってしまい、
ユーザーから信用されず使われないシステムが完成してしまう。
結果的に莫大なコストかけて作ったのに使われず、初期投資コスト回収できずという事態に。
STAMP/STPA
あるユースケースに対して、特に何のリスク対策をしないと前述のミスユースケースに繋がってしまう。
そのため最悪の事態が起こっていないという前提での通常のユースケースに加えて、
各ユースケースに対して最悪の状況が起きているという状況を前提としたミスユースケース
を考察したうえで、
その中で影響度や考えられる発生頻度、法的に必ず満たさなくてはいけないという要因などから
優先順位付けが高いものに関してはSTAMP/STPA用いてリスク軽減・回避の非機能シナリオを考察する。
【主張】
個人的にはコスト軽減のため、優先順位付けが中くらいのものに関しては、
わざわざSTAMPを用いずとも、ラフスケッチなどを通してのリスク軽減分析で充分と考えている。
特に重要なリスクに対してと、中くらいのリスクに対して、まんべんなくリスク軽減ではなく、
重みづけをした上でのリスク軽減の注力の度合いの分配を顧客との対話なども通して上で行うことが重要であると考えている。
ステートマシン図
【事実】
ステートマシン図は、対象システム全体にどのような種類の状態があるのか？
そして状態の移り変わりが俯瞰して読み解けるため、描くことを推奨されていた。
【主張】
これは神崎さんの要件定義フレームワークRDRAでも必ず描いていたので、
システムオブシステムズでも定義すべきだと改めて感じた。
RDRAでは対象システムの理解向上にステートマシン図が一躍買っていた。
同時にDADCのフレームワークには、状態図がなかったのでこれは先方にお伝えすべき内容と感じた。
もしも小坂さんたちが問題ないよっていうのであれば、次回の対面時にそれとなしに
「状態図はこういう理由からあった方がいいですよ」とお伝えしてみようと思っています。
鷲崎さん「DX時代の IoT・ AI・サステナブル・ソフトウェアエンジニアリング ならびにリカレント教育 – スマートエスイー」
これからはシステムは連携するのが当たり前な時代のため、
セキュリティは第一級品質として当たり前なものになっている。
もともとは品質の１つであったが、必ずマストなため他の品質とは別扱いに変わっている。
(恐らくUAFでセキュリティビューがあるのはこれが理由)
アジャイルセキュリティプラクティスなるものもあり、
多くのIoTでは、【相互運用性】【セキュリティ】【保守性】をメインに扱う。
また動的な品質に関しては、積極的にAIを使用する。
機械学習システムのためのメタモルフィックテスティング入門 - Qiita
サステナビリティ
省エネ化には２種類あると述べられていた。
①ソフトウェア自体のの省エネ化
これは横断的関心事のように存在するため、アスペクト指向を用いて
低消費電力系のものをあとから差し込む形を取って実現する。
②ソフトウェア開発の省エネ化
リソースの再利用や自動生成等による開発作業の効率化と利用電力の削減。
ただし、最初から効率化を重視すると他の品質の多くが犠牲になることが品質パターンからわかっているため、
ここは電力削減と実現したいソフトウェアの特性とのトレードオフ分析が常に求められる。
萩本さん「SE4BSの価値駆動開発プロセスについて」
理論とかというよりも直感的で感覚で作成したフレームワークだと述べられている。
匠メソッドでは知情意という３つの観点が大切にされているが、
意をいきなり意識して始めると視野狭窄になりやすいため情から始めるのがオススメとのこと。
3. 価値駆動開発の基本 - SE4BS
このあとは匠メソッドの主要なモデルの解説に入ったので、その中で特に印象的だったものをここに残す。
価値デザインモデル
このモデルでは、自分たちのプロジェクトの強みを定義するのだが、この中でストーリーという項目がある。
ここでは、AsIsからToBeまでの道のりの説明を書き、これがプロジェクト境界になってくる。
このスコープの中で詳細化していくので、このスコープの中か外かが無関係な実現要素化を決める判断軸となる。
また、価値はストーリー形式で書くのが１番他人も分かりやすい。
どのような人がどんな時に、どういう手段によってどう嬉しいのか？というスタイルで記載する。
気づき
システムオブシステムズの案件に入っているからそこに関心が主に行きがちであったが、
特に意識したいと思ったポイントとして、レイヤーのレベルに応じてステークホルダーの粒度も変わってくることに気づいた。
上図を参考。
個人のレイヤーは１つ１つのリソース、つまり人含めた１つのシステムのレイヤー。
そこから上は下のレイヤーを１つのシステムと見立てた際のＳｏＳのレイヤーという関係になっている。
１番下の個人のレイヤーでは、どんな人に対しての価値なのか？という
より具体的な粒度のステークホルダーであるが、チームのレイヤーからはどんな人にとって価値があるのか？
という粒度は、あまりにも細かすぎる。
どんなチームに対しての価値なのか？という基準の粒度でステークホルダを出すべきである。
同様にして、企業のレイヤーではどんな企業に対しての価値なのか？という
この企業レベルの粒度のものがステークホルダとなり、
業界レイヤーでのステークホルダ分析では、どんな企業に対しての価値か？というのは
細かすぎるためどのような業界の人々に対する価値なのか？というステークホルダ粒度で定義することが求められる。