要件定義の必要性
明日のファクトリーオートメーションにようこそ、メインパーソナリティの高橋です。
クリスです。
よろしくお願いします。
よろしくお願いします。
ラジオネーム、たこ焼さんからいただきました。ありがとうございます。
ありがとうございます。
お疲れ様です。
プログラムを作成する前に、打ち合わせとか要件定義をやっていますか?
具体的な要件定義の手順とか教えていただきたいです。
ふわっとした質問で申し訳ないです。
クリスさん、プログラムを作る前に要件定義していますか?
まず要件定義について、日本語がちょっと難しくて、ちょっと待ってくださいね。
要は仕様を書いてますかって話ですね。超簡単に言うと。
えーと、書いてる時もある、書いてない時もあります。
最悪な仕事はほぼ書いてないです。
ざっくりのパワーポイントが、60枚のパワーポイント、それも仕様書を言えるかな。
こんなのやりたいんですって、ババババって並べて、これやってくださいというのが最近のスタンスですね。
これも要件定義されたって言いますか?
ふわっとは。
されたんですよね、一応。されたって言いますよね、一応。
これが結構多くて、
昔、前のエンジニアリング会社の時は、
要件定義はほぼしてない。
ほぼしてない。
こんな頃にやってください。
フォローシャードもらって、これももらって、それで作るのが、
昔のスタンスですね。
まあやっても、
なんて言うかな、
えーと、まあそうやって、これまでやってる仕事結構スタマッチ、
まあ結構、
普通の一般スタッフなので、そんなに決められる権利がないので、
あの時の私の先輩が調子とか、
例えばどういうIOを使うか、どういうものを使うか、
あとは周りどういう通信をするか、
あとプログラムもどう、
そもそも工程、
あとどんな制御をしたいのか、
インターフェースをどうするかとかは、
お客さんのやりましたね。やった頃見たことありますね。
自分があるときは実際に変わった頃ほぼないんですけど、
実際の要件定義の手順
今はまあ、そんなこともやり始めてて、
あの人たちの先輩力は大変だなとちょっと感じましたね。
はい。
巨大ビデオゲームの定員って言われたら、
だいたいエンドユーザー、
私のほうに依頼するので、
こんなものを作りたいんですって、
まっくりで教えてくるんですね。
機械はこんな機械ですけど、
こんなものを作りたいですとか、
制度が少なくても階層とかもそうだし、
この機械なんですけど、
こういう階層をしたいんですとか、
あとはまあ、
会議して、
それで今こんなネットワーク構成とか、
どういう構成になってますけど、
みたいな、
自宅で打ち合わせてソフトを作って、
という感じですね。
これも用金定義したと言えますか、高橋さん。
言えますよ。
言えますよ。
どこまでやるかって話ですよね。
そうですね。
用金定義にはいろいろあるわけですよね。
例えば設備自体の用金定義というのもありますし、
ソフトウェアの用金定義というのもやっぱりあるわけなので、
それでどこまでやりますかという話ですよね。
はい。
僕はかなりちゃんとやります、そこは。
高橋さんは。
はい。
なぜなら私は標準化マンだから。
標準化人間。
標準化人間だから、
この辺はちょっと詰めておくと思いますね、
この辺は。
はい。
そうですね、基本的にはライブで割り当てたりとか、
どういう構造でやるかっていうことを
決めていくにはある程度、
事前の話しかしっかりとしないと
そこができないので。
なるほどね。
これは例えばソフトウェア面では
どういう
用金定義とか
話が実際されるんですか。
高橋さんの場合はちょっと聞きたくて。
はい。
例えば、
例えば、
高橋さんの場合はちょっと聞きたくて。
うーん。
基本的にはフローですよね、
フローと異常と。
機械の
機械の仙台の流れと、
異常と
インターロックとか
という感じですかね。
そうですね。
基本的には設備の構成って
3つに分かれると思ってて、
まずは括弧操作ですよね。
あるボタンを押したら
こういう動作をします。
それはアクチュエーターごとにあります
というのがまず1つじゃないですか。
2つ目はモニターですよね。
設備がどういう状態に
ありますかというものを
定義する必要があります。
例えば、サーボ音中です。
とか、ワークあり状態です。
とか。
アクチュエーターから帰ってくる
信号もあれば、
帰ってきた信号を組み合わせて
作る以上もありますよね。
例えば、動作系の
状態もあります。
例えば、移動中であるとか。
指示をしたけど
動かないから異常にしますとか。
こういう状態が
ありますよね。
この状態を
仕様が決まらない影響
組み合わせたものが
インターロックになるわけですね。
そうですね。
状態を定義しなかったら
インターロックは定義できないわけです。
はい。
状態が決まってないからね。
1個目は
アクチュエーター、どういう
超限定だ、どういうスローラインかの
アクチュエーターの動作を定義する。
あとはどんなものを監視する。
監視するのを前代の定義をする。
そうですね。モニターの定義をする。
次は
動作のインターロックですね。
やっちゃいけないこと。
動いちゃいけないことを定義する。
なるほど。
これはインターロックに該当しますね。
最初にどういう動きを決めないと
次はどういうものを
モニター的に言うか分からないし
どんな状態を
モニター的に分からないと
インターロックは組めないということですね。
ここまでできれば
あとはどういう順番に動かすんですか
最後にサイクルが来る。
僕は
これをちゃんとやるには
一番最初の動作定義と
モニターの定義がちゃんとしないと
やれないと思っているので
ここまで結構ちゃんと書くって感じですね。
最初に。
動作。なるほどね。
そんなことされたことない。
見たことないですね。
やったことほぼないな。そんな
近い定義したものが。
これは僕が設計者だからですよ。
なるほど。
僕は設計者に近いからそういうことをやるだけであって
丸投げするんだったら
適当な処置を書けます。
なるほど。
高谷さんが
設計者の立場とそうじゃない立場と
そうですね。
なるほど。
品質をどこまで担保するかという考え方によると思うんで
はい。
ストップを作るのも
何か定義もするんですか
どういうものを
ソフトウェアの内部
変数どんどん使うか
そこまでは定義はしないんですか。
しないです。それ必要がないと思います。
なるほど。
基本はモニターの
モニターの動作定義
モニターの定義
インダロック定義されていければ
基本は大体組めるだろうと。
そこまで細かいものを
定義しても仕方ない
しても
する必要はないというんですよね。
そうですね。そこまで行くとソフトを作る話になるんで
書いたほうが早いですね。
自分が
自分が製造までやるんだったら
プログラムの設計までやるんだったら
変数定義とか
全部決めますけどね。
高谷さんの
職務範囲は
絡んでる範囲で
どこまでやるかによって
どこまで書くかですね。
なるほど。
なるほど。
ソフトウェアの
基本設計する
のって結局その前の
仕様が決まってないとやっぱできないじゃないですか。
できないですね。
例えば機械が全部決まってます。
動かし方が決まってますみたいな。
そういうことが決まってないと決まらないんで
決まってないときはもっと
あやふやな仕様を書きます。
こんなことはあろうかと。
そうそう。
だからやっぱり思うのは
前が
フワッとするほど
後ろはフワッとする。
確かに前の仕様決めないので後ろの仕様
決めるわけないじゃないですか。
みたいな感じですよね。
だから設計者の立場からすると
途中で変わるより
決まってないほうがやりにくいですね。
途中で変わるより
決まってないほうがやりにくい。
例えば
仕様はこれですと言っておいて
作った後にやっぱりこれになりました。
切片ですみたいなことより
これは
AかもしれないしBかもしれません。
もしかしたらCかもしれませんみたいなほうが困る。
困る。
困るなこれ。逆に言うとAだから
Bになりましたら修正のほうが困らない。
そういう理由で変わったならAかもしれない。
Bかもしれない。
何をコールしなきゃいけないの?
そこに
要件定義の重要性
だいたいのパーセンテージ聞くぐらいを
いつもやるかな。
これ60パーセントぐらいAですかねみたいな。
そんなこと。
我々
それぐらい仕事してますね。
そんな感じで。
それからもう決めにいくからですね。
これ決まらない理由
なんなんでしょうかみたいな話聞いて。
うん。
それだったらもうAでいいんじゃないですか?
なるほど。
他にも言うと
高橋さんしっかり決めてるんですね。
仕様が。
人によるかな。
人というかケースによるかな。
自分のとこまで範囲かですね。
あとは
お願いする人が優秀かどうかにも
よりますよね。
とか。
お願いする人が超優秀だったら
あんま決めないです。
よろしくお願いしますって。
決めてもらおう決めてもらいますって。
なるほどね。
ちょっと新人とかだったら
高橋さんがちゃんと枠決めて
そうですね。
やってあげた方がいいでしょうねっていう。
なるほどね。
なるほど。
ただ理想としては
ちゃんと決まってる方がいいと思います。
そうだよね。
設計のプロセス
この
要件定義
ストックウェア要件定義は
結構最後ですよね
プログラムの要件定義って。
高橋さんが入れると
機会決めないとたぶん
打ち合わせもできないでしょうね。
ぶっちゃけ最初ですけどね。
こういう話っていうと。
要件定義。
だって一番最初に決めたときには
ほぼやりたいことは確定してる
っていうのが生産済みなんで。
なるほどね。
だから一番最初に攻撃機械作りたいです
っていう仕様が決まった時点で
そんなにソフトウェアの仕様って
そこから変わることないでしょう。
あくまで
設計に時間がかかるだけであって
出来上がるものはたぶん変わんないと思うんですよ
そんなに。
ゴールが決まってるから。
決まってる。
となるとそれはただの作業なんで
ただの作業ずっとちょっと語弊ありますけど
一番最初の仕様を決めた時点で
ほぼほぼ最後のソフトウェアも
決まってるってことだと思いますよ。
厳しいね。
高橋さんそういうところ厳しい。
確かに。
そっか。
当然
1位に決まってるわけじゃないんで
それがね。
はい。
その人たちが
いらないって言ってるわけじゃないけど
ただその一番最初の仕様が決まった時点で
ソフトウェアでできることっていうのは
ほぼ決まってしまっている。
そうですね。
こんなことやりたいですって
そんなになんか
工夫するところはあんまないんじゃないかなって。
そこ。
なるほど。
そうですね。
変わってもたぶんハードウェアの方が変わるんですね。
どういうのを宣伝するか
いっぱい悩む違いがあるんですよね。
そうですね。
ハードウェアの方が悩むんですよね。
だと思いますね。
最初か最後かって議論
あんまりする必要ないかなって思いますね。
なるほど。
最初決まってる時点でも
最初決まってる時点でも
後半ほぼ決まったようなもんなんで。
なるほど。
ただそれが
導き出すにはそんなに時間がかかるよって
いうだけの話であって。
この定義。
そうですね。
一番最初にこういう設備を作ります
っていう定義を決めて
じゃあそれで
瞬時にそれが出てくるわけじゃなくて
最後のほうはだいたい
わかってるんですけど
それに導いていくためには
それなりの時間がかかる。
なるほど。
だから一番最初に
説明しようを聞いた時点で
だいたいなんとなく見えるじゃないですか。
見えますね。
だいたいこんな感じの仕様だねっていう。
ソフトはだいたいこんな感じに作るんだね
とかわかりますね。
自分に話せる状態まで
うまくまとめていくのにやっぱり時間がかかりますよね
それなりに。
調べないといけないこともあるし
こういうところの関係どうなったんだっけみたいなものあるし
保証どうするんですかって話もあるし
でもそれはやっぱり調べてるだけで
生み出してはないよなとは
思ってます僕は。
ゼロから出てるものではない。
あるものあるの
あるのどこらかで
洗い出すだけ
合理的に考えていったらこうなりますよね
っていうのをやってるっていう感じ
こういう定義になりますね
厳しい
確かにそうです
厳しいですけど
それ自体は誰にでもできることじゃないんで
仕事としてはちゃんと成立しているという
ソフトワーク経験とかないとできないですよね
誰でもそれが見えるわけでもないし
誰でもそれができるわけでもないけど
ある程度経験があれば
最初手を切ったらだいたいこんな感じだね
っていうのはわかるみたいな
厳しい
厳しいじゃないですか最後は
言い方が厳しい
そうですね
難しいよねって
難しいよねって話です
難しいよねって
難しいよね
交通認識を作るんですね
要件的に最初に
一応コールを
再認識決めるってことですよね
なるほど
これができないあれができない的論にやっぱ
なんないと思ってるんですよね
何ができるかって決めるから始めるんですね
これができないこれができない
そうじゃならないなそうじゃなりませんね
これやりたいこれやりたい
なんとなくうまくいくんだろうな
成立してるんだろうなっていうのはわかるけど
ミスは多いですよね
ミス
よくあることじゃないですか
やっぱりこれじゃないこれが違う
ヘゲンジですねやっぱり
今はそこのミスを
直すこと
なくすことっていうのが今の
FA業界の主体的なところなのかもしれませんね
そうですね
要件的に会議あんまり出たことないんだよ
最近
日本だと
海外はわからんけど
日本だとやっぱメカ設計がそれを担当することが多いと思いますよ
でも高橋さんも言ったもんな
最終的にはもう
西洋設計も今日メカ設計の
入手されるべきですと
そうですね
悲しい仕事はここで
同じ仕事はもう高橋さんだけでいいです
別に僕もいらないです
そうですか
悲しい仕事は高橋さんだけでいいです
僕はいらなくなってそのまま
収束するんで
仕組み作るやつは高橋さんだから
高橋さんが上手い仕事を
取って
仕組みを作ったら仕組みを作ったやつは生き残れる
仕事がなくなっても
残るとはもう仕方ないから
別に
厳しい
高橋さん悪い人だな
悪いやつです
というわけで
我々の考える要件的
ですねこれが
じゃあ高橋さんありがとうございました
ありがとうございました
