システムのイメージ

　資格を持っていても仕方がないという風潮はソフトウェア業界には少なからず
あります。でも本当にそうなのかもう一度考え直して見る必要があるように思い
ます。確かに情報処理関連の資格は必ずしもその技術者のパフォーマンスを
証明することにならないのは分るような気がしますが、簿記なんかはどうですか？
　現実の経理は伝票会計ですから必ずしもとは言えますが、その根本的な約束
は仕訳なんかそうですが一緒なんですよね。これが分らないと伝票会計が理解
できないんです。少なくともかなり困難が伴います。
　それと資格ではないですが、生産管理などは工場を実際に見る、在庫管理なら
物流センターや自動倉庫の実物を見ることがシステムを視覚的に捉えることに
とても役立ちます。秘匿性がもちろんあるのでユーザの諸事情から最近はSEに
こうしたものを見せる機会が減ってしまっているように思いますが、是非検討して
もらいたいなぁと私は思います。

経験の生かせないソフトウェア業界

　これは問題だなと思うのはソフトウェア業界というのは実は経験を生かすことの
あまりできない業界であるということに外部の人はもちろん業界の人も意外と
気がついていないように思うのです。今は昔話となった「バブル崩壊」と「ダウン
サイジング」により汎用機のSEやPGがかなりの数、リストラされたことがあります。
しかし、新しいことを覚えようとしない技術者はともかくとして、再教育することで
かなりの戦力になったのではと思うのです。少なくとも当時には一応のシステム
設計の方法論が完成しており、そうしたトレーニングを現場で重ねていたのは
他ならぬ汎用機の技術者だったように思います。要件定義や基本設計を十分
にこなせる人材を使い捨てにしてしまったように思えてなりません。
　私はこのときにホスト&COBOLの世界からVBに転向することができ、その後
SAPがここまで伸びるとは誰も考えていない時期にSAPに触れ、ABAPを覚える
機会にも恵まれ、生き延びてこれました。これはこれで有難いのですが、ホスト
時代のキャリアは全く評価されないのが実情です。かくして技術の主流が変わ
るたびに、本来は普遍的に通用するはずのスキルや過去の世代が積み上げた
ノウハウが全くあるいは表面的にしか継承されないというはなはだもったいない
結果になっているように思えてなりません。それともこれは単なる愚痴なのかも
しれませんが。

只今準備中

　実際の現場で学ぶスキルが最も良いのは言うまでもないことかもしれません。
しかし、今は守秘義務が厳しく問われる時代です。しかし、各人の持つノウハウを
大切にしつつも共有していかないと、SAPのような大きなパッケージでは対処が
難しくなるのも事実です。そこで少々バージョンが古いですが、海外文献や洋書の
翻訳をもとにメルマガをFIを中心として再発行していきたいと考え、現在準備して
います。今しばらくお待ちください。
　もっとも現在は病気療養中ですから、現場の技術もへったくれもないのが実情
ですけれど、仮にSAPの開発プロジェクトに復帰しても現場で知り得たことについ
ては口をつぐむより他はないでしょうしね。

モジュール内強度、モジュール間結合度

１つのモジュールは１つの機能で組み立てられていなければならず、かつ出入り口は１つでなければならないという趣旨のプログラム設計理論です。現在多くの開発を経験してますが、なかなかこの点が一般では理解されていません。むしろ汎用機全盛期にはこの考え方がきちんと採用されていたように感じています。
是非皆さん勉強してくださいね。

※只今家族が病気のため更新が滞ってます。メルマガも出せていません。お詫びいたします。

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

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

帰納と演繹

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

SEになるメソッド

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