キミは,あゆみ活動を見たか!?

なんと私はこの本を持っています。1回通して読みました。

富士通における「あゆみ」活動

覚えておかなければならないのは,この本が,20世紀末の富士通さんの悲惨な状況よりもかなり以前に出版されたことです。もちろんインターネット世界以前です。ゴーレムIBMヤマタノオロチ富士通天上界で火花を散らしていてたような世界を思い浮かべて読まなければなりません。日立さんとかも忘れないでね^^

ある意味,「あの頃はよかった」的なものなのかもしれません。私はその頃のことはサッパリ知りませんのでどうでもええんです。

私はこういう活動を通じて創られたのであろう,「ドキュメントの書き方のドキュメントの抜粋」を見たことがあります。もちろんその中には「ドキュメントの書き進め方の決め方」みたいなものもあります。

全ての資料には番号が着いています。大グループ分けの番号で分けるだけで中規模以上のプロジェクト運営の切り分け作業は済んでしまいそうな勢いを感じることができる代物です。

しかし,それは勘定系だか基幹系のでっかいシステム開発,それもいわゆるウォーターフォールモデル(←語弊がある用語らしいですが)に限定されています。

近年ラッドだかアジャイルだか,アジャパーだかよくわからないことを言って煙に巻く連中がワンサカいますが,ある規模以上では,やはり秩序立てた軍隊式の管理がどうしても必要だと思います。

それはよく引き合いに出される建設関係と同じではないでしょうかね。

数をこなして,大規模な問題解決のための大規模な管理手法というのはビッグプレイヤーしか勝ち得ないのでしょうが,見ておいて損は無いと思います。

ちなみに,機械関係の設計者は便覧(例えばJIS便覧)という分厚い書籍を参照しながら設計するのが戦前からアタリマエです。まともな歴史のある企業なら,My便覧,My企業系列便覧があって然るべきです。だって,根拠の無い設計は許されませんからね。

電子回路の設計者は,デザインルールに則ってレイアウト決めます。アタリマエです。デザインルールを策定する委員会があったりします。さらに言えば,製作する工場の引き当てを変更したらルールを再確認します。設備の都合を無視して勝手に設計することはできないのです。

ソフトウェアシステムの業界は甘えているだけです。例えば,アルゴリズム事典のようなもの,12人月くらいあれば,My部署設計ルールくらい作ることが出来るはずです。継続してルールを更新していけばラットイヤーにも勝てるはず。だって,コーディング規約は委員会があったりするじゃないですか。どうしてそんな形式にだけこだわるんです?それじゃまるで昔「ドラフターで線を引くときには必ず鉛筆の先をけずってから」という規定があったのと同じじゃないですか。

どうして設計ルールを「コーディング規約」という形式で定義しようとするんです?だから設計の本質を伝承できないのではありませんか?結局は同じことだと言いますが,私は違うと思いますよ。

「形式を守れば本質が維持される」のだとしても形式しか見なければ本質に触れることはできないのです。目的は本質に触れさせ,理解させることではありませんか。形式を守ることとはあくまでも手段のひとつであると思うのです。

ごみためのランキングはこちら。