【仕様書】最小構成のモデルベース開発事例 その1【背景、目的】

事例

バックナンバーはこちら

スポンサーリンク

はじめに

モデルベース開発と言っても対象によって手法や使うツールも様々。
とは言え、動機としては共通項があり、
おおよそ「早々に機能や品質を引き上げたい」になる。

まともに事例を書くと、とんでもないことになるが、ここでは考え得る最小構成のモデルベース開発事例を記載していこうと思う。

登場人物

博識フクロウのフクさん

イラスト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]のオートクルーズが可能な状態。
  • 急加速、急減速にならない程度の踏力を再現すること
フクさん
フクさん

うん。何をやりたいか、今後の狙いも良く分かるよ。
(まぁ「急加速、急減速にならない程度」が具体的になに?って感じではあるけど。)

太郎くん
太郎くん

よっしゃー!

太郎くん
太郎くん

次は「達成手順概要」になるのかな?

フクさん
フクさん

うん。それは次回説明するよ。

太郎くん
太郎くん

(やはり連載モノだったか。)

まとめ

フクさん
フクさん

まとめだよ。

  • 仕様書等の開発ドキュメントは大きい話から書いていく
    • 背景、経緯、目的など。
  • 背景、経緯、目的は形式的なものではなく、ドキュメントの誤認識を抑制する仕掛けの一つ。

バックナンバーはこちら

コメント

タイトルとURLをコピーしました