だから作ってくれ，っていきなりお願いされたらどうしますかー？
だいたいの人は（そうでもないか？）
ふつーのカレーライスを作ったりするんじゃないのかなーなんて思います．
＃ふつーってなんやねん，って話ですが...
それはお願いしている人との間で，
カレー＝カレーライス
って共通の認識ができているからなのです．
（本当か...（？）
だから，わざわざ，どんなカレーを作れば良いの？
なんて聞き返す人はあまりいないと思うのですよね．
このように，お願いする人が“ある用語に対して共通の認識”
をちゃんと持っていれば事故は起きないのですが...
よく知らない人にお願いされたらどうでしょ．
よく知らない人：カレーが食べたいです，作ってください
私：どんなカレーですか？
って聞き返しますよね（たぶん）．
だってカレーにはライス以外にも，
ナンで食べる人，パンで食べる人，うどんで食べる人，
いろいろいますものね．
ルーにも，グリーンとかレッドとかホワイトとか，
いろいろありますよね．
もしも聞き返さなかったら，相手が望んでいないモノを作ってしまうかもしれない．
＃まぁだいたいの人はカレーと言ったらカレーライスでしょうが．
＃ただ，共通の認識を相手も持っているだろう，と勝手に思い込むのが危険
----
以上は例え話で
...何が言いたいかと言うと．
モノを設計しているときに，
相手が自分と同じ認識を持っていると思っていたら，
相手の設計しているモノと，自分の設計しているモノを
組み合わせるときに，アレレ，となる場合があるかもよ，
ということです．
用語についても，実は同じ話をしていると思っていたら，
違う意味を指している可能性があるよ，ということです．
用語１つ取っても，例えば先日PDRが終わったようですが，
PDRって何をする場なの？と聞かれたら，みんな答えが違うかもしれません．
・現状の進捗を説明すれば良いんでしょ
・設計が妥当か確認してもらうんでしょ
・他系との調整を行う場でしょ
・発注前予定の物品が妥当かどうかチェックしてもらうんでしょ
＃まぁなんでも良いのです．おそらく...
＃そのプロジェクト内部で使う場合に限りますが…
＃ちゃんと国際的には定義があったと思います
何を言いたいかというと，
プロジェクトとして共通の認識/理解を持つことは大切だよーってことでして．
＃それを自分たちだけでなく，他者に説明するときには，
＃その他者にも言葉の定義を認識してもらう必要があります．
＃でないと全然関係がない指摘が来たりしますからねー．．
＃って意味合いでは，プロジェクトメンバだけが持っているだけでは，
＃不十分だったりする場合もある
今後はEMのフェーズに入っていくということで，
他系との調整が多く必要になってくると思います．
プロジェクト外部との調整もあるかもしれません．
I/F（系と系のつなぎ）もしっかりと決めないといけないと思います．
I/Fがあると言うことは，I/Fをつながないといけないです．
つなぐときに，お互いに本当に同じことを考えているのか，ってことを考えていきましょー．
そしてどんどんと物事を定義していくべきだと思います．
じゃないと毎回説明をしていかないといけなくなって，
変に時間を食ったりもします．
用語に付随して，蛇足になりますが．
スケジュールで，◯◯フェーズ，と良く書かれると思います．
それでも良いのですが，それだと具体的に何をするのかが分からないため，
スケジュールの妥当性が良く分からないし，
そもそも何をするのかが分からない場合すらありますよね．
だからアドバイスする側も，うーん，いいんじゃない？なんて言うしかありません．
なので，用語の定義と同じですが，
◯◯フェーズではAとBとCを達成したらOK．
Aと達成するためには，αとβを達成すればOK．
と定義していきましょー．
＃達成度を定量的に認識できるレベルまで分割することが大事だったりもする．
そして，それをどう達成したのか，と評価する方法も加えていくと，
検証計画になっていきます．
＃いや，そんな簡単なモノじゃないことは分かっておりますが...
他系の人でも分かるように書くことで，
あ，このフェーズでこんなことをするのなら，
ここでこんな試験を組み合わせてしませんか？
なんて話もでてきたりします．
そして，あれ，この工程抜けてるよ，って指摘できたりします．
＃外部の人にアドバイスをもらうときに，特にこういうことがあるかと...
…ブログなので（言い訳）
薄っぺらくダラダラ書きましたが
（薄っぺらくだらだらなのはいつもだろ，というツッコミは受け付けません），
面倒だなーと思いつつも，ちゃんと用語の定義とかスケジュールを立てる，
なんてところもやっていきましょ，なお話でした．
＃結果，出戻りが少なくなるので，結局効率はよかったりします．
ではではまたー．雑文をここまで読んでくださりありがとうございました．
以上，例え話が分かりにくいと定評のある田中康＠衛星部屋 東京支部でした．
追伸：39様，書くのが遅れてごめんなさい...
だいたいの人は（そうでもないか？）
ふつーのカレーライスを作ったりするんじゃないのかなーなんて思います．
＃ふつーってなんやねん，って話ですが...
ふつーと噂されるカレーfromうぃき
それはお願いしている人との間で，
カレー＝カレーライス
って共通の認識ができているからなのです．
（本当か...（？）
だから，わざわざ，どんなカレーを作れば良いの？
なんて聞き返す人はあまりいないと思うのですよね．
このように，お願いする人が“ある用語に対して共通の認識”
をちゃんと持っていれば事故は起きないのですが...
よく知らない人にお願いされたらどうでしょ．
よく知らない人：カレーが食べたいです，作ってください
私：どんなカレーですか？
って聞き返しますよね（たぶん）．
だってカレーにはライス以外にも，
ナンで食べる人，パンで食べる人，うどんで食べる人，
いろいろいますものね．
ルーにも，グリーンとかレッドとかホワイトとか，
いろいろありますよね．
もしも聞き返さなかったら，相手が望んでいないモノを作ってしまうかもしれない．
＃まぁだいたいの人はカレーと言ったらカレーライスでしょうが．
＃ただ，共通の認識を相手も持っているだろう，と勝手に思い込むのが危険
----
以上は例え話で
...何が言いたいかと言うと．
モノを設計しているときに，
相手が自分と同じ認識を持っていると思っていたら，
相手の設計しているモノと，自分の設計しているモノを
組み合わせるときに，アレレ，となる場合があるかもよ，
ということです．
用語についても，実は同じ話をしていると思っていたら，
違う意味を指している可能性があるよ，ということです．
用語１つ取っても，例えば先日PDRが終わったようですが，
PDRって何をする場なの？と聞かれたら，みんな答えが違うかもしれません．
・現状の進捗を説明すれば良いんでしょ
・設計が妥当か確認してもらうんでしょ
・他系との調整を行う場でしょ
・発注前予定の物品が妥当かどうかチェックしてもらうんでしょ
＃まぁなんでも良いのです．おそらく...
＃そのプロジェクト内部で使う場合に限りますが…
＃ちゃんと国際的には定義があったと思います
何を言いたいかというと，
プロジェクトとして共通の認識/理解を持つことは大切だよーってことでして．
＃それを自分たちだけでなく，他者に説明するときには，
＃その他者にも言葉の定義を認識してもらう必要があります．
＃でないと全然関係がない指摘が来たりしますからねー．．
＃って意味合いでは，プロジェクトメンバだけが持っているだけでは，
＃不十分だったりする場合もある
今後はEMのフェーズに入っていくということで，
他系との調整が多く必要になってくると思います．
プロジェクト外部との調整もあるかもしれません．
I/F（系と系のつなぎ）もしっかりと決めないといけないと思います．
I/Fがあると言うことは，I/Fをつながないといけないです．
つなぐときに，お互いに本当に同じことを考えているのか，ってことを考えていきましょー．
そしてどんどんと物事を定義していくべきだと思います．
じゃないと毎回説明をしていかないといけなくなって，
変に時間を食ったりもします．
用語に付随して，蛇足になりますが．
スケジュールで，◯◯フェーズ，と良く書かれると思います．
それでも良いのですが，それだと具体的に何をするのかが分からないため，
スケジュールの妥当性が良く分からないし，
そもそも何をするのかが分からない場合すらありますよね．
だからアドバイスする側も，うーん，いいんじゃない？なんて言うしかありません．
なので，用語の定義と同じですが，
◯◯フェーズではAとBとCを達成したらOK．
Aと達成するためには，αとβを達成すればOK．
と定義していきましょー．
＃達成度を定量的に認識できるレベルまで分割することが大事だったりもする．
そして，それをどう達成したのか，と評価する方法も加えていくと，
検証計画になっていきます．
＃いや，そんな簡単なモノじゃないことは分かっておりますが...
他系の人でも分かるように書くことで，
あ，このフェーズでこんなことをするのなら，
ここでこんな試験を組み合わせてしませんか？
なんて話もでてきたりします．
そして，あれ，この工程抜けてるよ，って指摘できたりします．
＃外部の人にアドバイスをもらうときに，特にこういうことがあるかと...
…ブログなので（言い訳）
薄っぺらくダラダラ書きましたが
（薄っぺらくだらだらなのはいつもだろ，というツッコミは受け付けません），
面倒だなーと思いつつも，ちゃんと用語の定義とかスケジュールを立てる，
なんてところもやっていきましょ，なお話でした．
＃結果，出戻りが少なくなるので，結局効率はよかったりします．
ではではまたー．雑文をここまで読んでくださりありがとうございました．
以上，例え話が分かりにくいと定評のある田中康＠衛星部屋 東京支部でした．
追伸：39様，書くのが遅れてごめんなさい...