バックナンバーはこちら
https://www.simulationroom999.com/blog/model-based-of-minimum-backnumber/
はじめに
モデルベース開発と言っても対象によって手法や使うツールも様々。
とは言え、動機としては共通項があり、
おおよそ「早々に機能や品質を引き上げたい」になる。
まともに事例を書くと、とんでもないことになるが、ここでは考え得る最小構成のモデルベース開発事例を記載していこうと思う。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
悩む太郎くん
フクえも~ん!助けて~!
(これは・・・。「どうしたって言うんだいのび太郎くん?」って返すと理不尽にも怒られるパターンだな。)
ちょっと、
「どうしたって言うんだいのび太郎くん?」
って返すノリのところでしょ?!
(理不尽だ)
で、どうしたの?
上司が
「モデルベース開発の案件取ってきたぞ。あとは任せた!!」って・・・。
(相変わらずヒデー会社だな。)
で、どんな感じの案件なの?
うーん、
最終的には自動運転系の話になるらしいんだけど、
直近としては後付けのクルーズコントロールするような装置。
だったら、
PID制御あたりでうまく制御してあげればいんじゃない?
もう一個問題があって・・・。
なにさ?
これも上司に言われたんだけど。
上司『これからは上流シフトだ!外部委託先は選定しておいたからな!あとは任せた!!』
(ひでー)
僕も言ったんだよ。
『それって丸投げですよね』
って。
(ほぅ。ちゃんと言えたのか)
そしたら、
上司『丸投げでは無い!太郎もこれからリーダーとしてやっていけるよう教育も兼ねているんだ!』
って。
うーん、
ちゃんとフォローしてもらえるんだったら、
筋は通ってる気もするよ?
んなわけないじゃん!!
フォローなんかしてもらったことない!
(だろうな。大体困ったらこっちに聞いてきてるもんな。ヒデーな。)
というわけで今回もよろしく!!
(この会社の最大の犠牲者は私なのでは?)
仕様書作成
で、なにをどうしたらいいんだ?
とりあえずは委託先が作業できるように、
仕様書を作らないといけないんだけど。
まぁそうだろうね。
仕様書なんてほとんど書いたことないから、
よくわからないんだよね。
でも読んだことあるよね?
それを真似れば良いのでは?
んー、
そうなんだけど、
大体なんかのメモっぽいのが仕様ってことで渡ってく来てるんだけど、それで良いのかなー。
それダメ―!絶対ダメ―!!
あーやっぱりねー。
上司が言うには、
『モデルベース開発なんだからSimulinkでちょこちょこっと書いたの渡せば?』
とか言ってるんだけど。
それもダメ―!絶対ダメ―!!
というわけで、
ド基礎から教えてもらえると助かるんだけど。
(なんだろう。働く環境がいろんな意味で最悪だ。)
まぁ仕様書とは言ってもあまり形式ばる必要はないけど、
必要な考え方というのはあるね。
そうそう!そういうのでよろしく!
仕様書の基本的な考え方
仕様書に限らず、
ドキュメント関連は大きいことから書いた方が良い。
と言うと?
例としては以下かな。
- 背景、経緯
- 目的
- 達成手段概要
- 達成手段詳細
うーん、
いままでだと、背景とか目的みたいな形式的なものはいらないから、
「やることだけ書く」的にやってきたかなー。
「やることだけ書く」だと何か問題があるってこと?
文章と言うのは書き手と読み手が必ず同じ意味で捉える保証は無いんだよ。
局所的な回避手法としては、以下があるけど。
- 主語と目的語を明確に。
- 接続詞は極力使用せずに文章を分ける。
- 副詞、形容詞を多用せずに具体的に数値化
- 理由を記載する
確かに、主語が無くて、「たぶん前に続いてるんだろなぁ」と思っていたら全然違ったり。
ホント困るんだよなぁ。
その感じで、
自分がやられたら困ることをやってはいけないということだね。
う。確かに。
で、
背景、経緯、目的が必要の理由にはなっていないと思うだけど?
うん。
背景、経緯、目的が必要なのは、大きな意味で「理由を記載する」に該当する。
んー、
仕様一個一個に理由を書いていくってことじゃないの?
それでも良いが、
おおよそ一つの理由に複数の仕様が繋がっていることが多いんだ。
あ、
それで先に大きな理由を書いた方が良いってことか!
そういうこと。
当然、細かい理由は個別の方が良いことも有るが、
目的に相当するものや、
目的が生まれた背景に相当するものを毎回書くのも変な話だろう。
重要なものほど、真っ先に提示してしまった方が読む側の誤認識のリスクが大きく下がるんだ。
うーん、
いままでそれっぽいことをそれっぽく書いてたけど、
今の話だとかなり重要な部分だから気をつけないといけないな。
さぁ。これらを踏まえて、背景、経緯、目的は?
こんな感じかな。
■背景、経緯
昨今、自動運転推進が続いている。
研究開発も自動運転に対しするものが増えてきており、関わる技術者をそれに応じて増えている。
一方で、実験環境不足が問題となっている。
限られたコストで十分な試作車を手配できず、実験が停滞する技術者を出てきている。
これの対策として以下が考えられている。
従来の自動運転機能が付いてない車両に対し、後付けで「人の代わりに制御するデバイス」を取り付けて自動運転実験を実施できるようにする。
まずはアクセル制御を外部からの指令で動作するデバイスを作成する。
今後、これを元にブレーキ、ステアリング、シフトへ徐々に展開していく。
■目的
本開発は、アクセル制御を行うデバイスの開発となる。
水準としては以下とする。
- 平坦の道にて、事前に設定した30[km/h]~60[km/h]のオートクルーズが可能な状態。
- 急加速、急減速にならない程度の踏力を再現すること
うん。何をやりたいか、今後の狙いも良く分かるよ。
(まぁ「急加速、急減速にならない程度」が具体的になに?って感じではあるけど。)
よっしゃー!
次は「達成手順概要」になるのかな?
うん。それは次回説明するよ。
(やはり連載モノだったか。)
まとめ
まとめだよ。
- 仕様書等の開発ドキュメントは大きい話から書いていく。
- 背景、経緯、目的など。
- 背景、経緯、目的は形式的なものではなく、ドキュメントの誤認識を抑制する仕掛けの一つ。
バックナンバーはこちら
コメント