さてエンジニアについてもその3に到達。その2に続いて、現代のエンジニアについてです。
現代のエンジニアは、科学的な態度での仕事の進め方を以てエンジニアと称しています。すなわち、エンジニアリングプロセスを以て仕事をするのでエンジニアであるとします。
私は、けして「自ら称するからエンジニア」では無いと考えます。
では、そのエンジニアリングプロセスとはどういったものかと言いますと、世の中にはいろいろ定義がありますが大筋以下:
- まず目的を定めよう!もしくは問題の記述をしよう!制約なども忘れずに。
- しからば事を解決するような対応した領域のモデル(仮説)を構築しよう!
- モデルから目的に対応した目標値を決めよう!
- モデルの妥当性の検証のための指標目標も定めよう!
- モデルに基づいて設計モデルを起こし、試作製作をしよう!
- 試作品で実験をして結果をもとにモデル妥当性検証の分析をしよう!
- 分析をもとに必要なら設計モデルや大元のモデルを修正しよう!
- しからば 2 もしくは 4 からやり直そう!
- 2 や 3 で定めた目標値をクリアしていれば、目的を達成する代物を手に入れられているだろう!
※9でどうしてもクリアできないときは1の設定が無茶だった可能性はあります。
2, 4, 6, 7 の辺りが科学的なところでしょう。ただし、科学と異なるのは、妥当性の因って立つところが現実の自然現象などでは必ずしもなく、「こうなっていると都合が良い」といったところの要求、要望などが主たるところです。自然現象などはむしろモデル中の制約として表れるところかもしれません。
それと2についていは今ここではサラッと流していますけれど多くの場合、発明などが絡むので実はここがミソで大事になります。NASA の定めた engineering design process † では、ここのボリュームが最大になってます。そして世の中のengineering (工学)の方法論の多くもここの解説のボリュームが大きい。
それはまあ、ここができなければ一切最初の目的、問題解決ができないので後のプロセスも無意味ではあるので要(かなめ)であることは確かです。ここの部分をその1で話をしています。ようするに使えるものは何でも使えということ。そのために NASA ではブレインストーミングその他を織り込んでいたりする。
ちなみにNASA の engineering design process では step 1~8 まであり、そのうち step 1~7(の前半分) までが上の 1, 2 に相当し、step 7(の後ろ半分), 8 が上の 3~9 に当たります。
なんで私の方はこんなに後半にボリュームかけているかというと、この辺がいいかげんすぎる人たちがようさんおるからです。教育の結果なのか何なのか・・・やりっぱなしで済ます人たちが多すぎる。フォローや見直しによる修正、磨き上げが重要なのに、そこをしないで済ましてしまう。もちろん失敗や間違いは、そのまま流れていってしまう。いつまでたっても直らないわけです。
適用対象の違いを置いておけば、おおよそ世の中の仕事の仕方の大筋は大体似通ってます。このエンジニアリングプロセスも然り、トヨタさんのカイゼン然り。
カイゼンの場合は、その源泉はデミングサイクル(いわゆるPDCAサイクルと云われている代物)です。デミングサイクルでは、P は Plan で、D は Do、C は Check で、A は Action。
さて、1, 2 はおおよそ要求仕様の作成辺りに相当しますし、2, 3, 4 は設計諸元の作成辺りでしょうか。
不祥事が後を絶たない企業などは、ちょうど 6, 7, 8 あたりがぶっ壊れたシステムでまわしている組織なんでしょう。現状よりマシになっていくようには見えませんよね。逆にここがちゃんとしていれば、現状がダメダメでも将来的にはマシになっていく可能性がある。
† see http://www.nasa.gov/audience/foreducators/plantgrowth/reference/Eng_Design_5-12.html
>教育の結果なのか
教育は効くでしょうね、良いほうにも悪いほうにも。
やったところを見られちゃうことはあるわけだが、「あんなんでいいんだ」と思われたくないなぁ。
悪い教育になっちゃうことがある。
小学生、中学生相手じゃないから、反面教師という・・・(苦が笑)
上のようなことを書いておいて、私も諸事情(プロジェクトの時間制約やらコスト制約やら・・・)によって満足にプロセスをまわせないことの方が多かった。とはいえ、それで現実と理想は違うのだからしかたないとは言いたくはないけど、反面教師かなぁ・・・