トップ «前の日記(2023-06-11) 最新 次の日記(2023-06-13)» 編集

Mano Blog

Health | MISC | NPO | PC | インターネット | 仕事 | | 電波 |

2023-06-12 Discourse on Method 

_ [仕事] Discourse on Method 

  仕事柄、さまざまな仕様書とか企画書とか提案書とかを、共同で策定することが多い。ところが、最近はの自称技術者というかSEという人達からくるのが、パワーポイントだったり、文章だとしてもやたらとボリュームの大きいのがいきなり出てくる。

  ところが、どうしても論点が整理できてなかったり、構造が体系化されてなくて、まぁ論理思考的でないことが多い。こういうのって、なんでなんだろうとつくづく思っている。

  最近ちょっと気づいたのは、スクラッチからものを考えたり、作ったりする経験がないことが、こういう思考体系の欠如の要因なのではということだ。

  僕は、電気、電子の設計を長年してきたけど、新製品を開発する時にいきなり回路図を書くことなんてない。普通は、コンセプトまとめて、要件定めて、ブロックダイアグラム書いて、回路図書いてとだんだん詳細に落ちていく。詰まるところ、設計はトップダウン手法だ。

  これに対して、実装はというと、小さな要素部品を実装して、評価して、要素部品を繋いで全体評価してというように、ボトムアップ手法だ。

  これは、ソフトウェアの開発も全く一緒で、設計は最初にデータ構造とアリゴリズムありきだった。

  でも、最近はアジャイルという言葉の濫用なのか、コンパイルなどのターンアラウンドが早くなったからなのか、いきなり実装からはいって全体の構造が意識されてないことが多い気がする。

  なので、いろいろな資料でも、問題の整理の仕方でも、もうちょっと論理思考で整理してよと言いたくなる。

  この話をする時に、いつも思うのは、昔の偉い人はすごいなということで、デカルトの以下の方法序説が普遍的に適用できるんだよなということだ。

Discourse on Method 4 rules

 Rule 1: Accept nothing as true.

 Rule 2: Divide into simple parts.

 Rule 3: Move from simple to complex.

 Rule 4: Test the reasons.

  特に、Rule2とRule3は、いつも気にかけて欲しいな思うんだけど、こういうの工学部とか情報学部では教えないのだろうか。

  そんなわけで、標準化とかでも、この辺りを良く説明してるんだけどなぁ...


この日記は、FaceBookにフィードしているので、ツッコミはそちらだけで受け付けることにしました。
過去の日記
2023年
6月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30