メソッドの話を前にしましたが

日本人の国民性というのでしょうか、例えば「習うより慣れろ」とか「人の技を盗め」といった
メンタリティーで仕事を覚えていくというのは以前からそう変わっていないように思います。
これは職人を育てていくにはある意味合理的なのですが、大量に人を育てるときは、それも
「極める」ではなく「一定の水準」に育てるにはどうしてもメソッドが必要になってきます。
以前、プロジェクトＸという番組があり、東京オリンピックの食事のプロジェクトで大量の料理人を
育成する必要に迫られたとき、帝国ホテルの料理長がすべてのレシピを公開したことが
番組になってました。当時の料理界ではおよそ考えられないことなんですよね。
ところが今でも多くの業界でかなりマニュアルは整備されたとはいえ、メンタリティーが
追いついてないと思います。われわれのソフト業界でもおそらく同じに感じてます。

帰納と演繹

まず、Wikiか何かで「帰納」と「演繹」という言葉を調べて見てください。
おそらは検索エンジンにWikiに限らず、引っかかると思います。
まず、これが我々のコンピュータソフト開発の基本理論です。
一般事象すなわち業務を抽象化＝モデルに置き換えること、
このモデルが実際の業務遂行に当たり、適用できるかを検証し、
その上で実際のプログラムとして実現できるわけです。
失敗しているシステムの特徴としてプログラム中に多くの例外条件や
エラー条件がハードコーディングされています。
これはメンテナンスの障害となるとともに入力エラーチェックとの
不整合に起因するデータ不整合や異常終了の原因にもなりえます。
ERPであろうがなかろうが、モデル化は不可欠な考え方です。

SEになるメソッド

これはコンサルでもPGでもそうですけれど、存在していないと思います。
小難しい理論やコンピュータ言語の教育はありますけれど。
どの工程に従事していても帰納と演繹の繰り返しなんですよね。
でも、これを行えるようになるメソッドを教育している会社とかは
正直知らないです。
一般的な事象からモデルが作れるようにならないと、
なかなか難しいですよ。

更新が遅れて申し訳ありません

家族が病気でその看病のため多忙で更新が遅れてしまいました。
今週末当たりからぼちぼちはじめて行きたいと思います。
しばし、お待ちをm(_ _)m

SAP CRMとABAPのメルマガも週末には出しますので･･･。

SAP CRM情報発信！

４月２２日(日)にメルマガを発行します。SAP CRMのアドオン開発のメルマガです。
よろしかったら是非登録してくださいね。よろしくお願いします。
ご登録はSAP Chipsまたはhttp://www.melma.com/backnumber_167838/

データの項目と流れを

まだ文章として固まっていないけれど、こんな感じでしょうか。

データ→ヘッダーと明細がある。
　　　　　マスターとトランザクション（取引）データがある。
　　　　　明細に対してサマリーデータがある。

一度もERPの仕事をしたことがない人はもし機会があったらチャレンジすると面白いと思います。
上記がどう実現されているのか。それはゼロから開発するときにきっと役に立ちます。ERPだけ
やっている人はDB設計のイロハから一度勉強する必要があるかもしれません。

うまくまとまんないですが。

設計書のレビュー

システム開発において設計書のレビューは重要である、ということに異論を差し挟む人はあまりいないように思います。でも効果的なレビューが実際行われているのでしょうか。よくユーザレビューは行われますが、私は上流工程の成果物を下流工程の担当者がレビューするプロセスがあっても良いのではないかと思います。要件定義書を見て基本設計書を書くのはユーザではありません。基本設計書を見て詳細設計書を書くのは？やはりユーザではないんですよね。詳細設計書を見てプログラムを書くのは？つまり次工程に回したときの疑問点がないようにそのドキュメントの情報だけで次工程が成立しうるかという問題があるように思います。下流工程ほど若い担当者になる傾向があるのでなかなか難しいですけれどね。でも以前も話ましたが、コンピュータの上で実行されるのはパワーポイントのドキュメントではなくプログラムであるということは何度も繰り返し申し上げたいことです。