Links

システム開発に関して、たいへん興味深い内容を扱っているホームページに対しリンクを作成しました

System Creates Inc

システム開発のプロセスについてコンサルタントをされている会社のホームページです。システム開発のプロセスといえば、カーネギーメロン大学の研究機関であるソフトウェア工学研究所(SEI)の「ソフトウェアプロセス成熟度モデル」(CMM)が有名ですが、このモデルについて、作者の方の経験に則した意見を提示されています。

実は、「ピープルウェア」の著者でもあるトムデマルコはCMMに対してかなり批判的です。

トム・デマルコがちょっとした冗談で「SEIモデルに従っていたら、アップルコンピュータは存在できるはずがない」と私に語ったが、かなりそういった論争がある。

「ソフトウェア管理の落とし穴」 エドワード・ヨードン著 (76p)

ただし、「ピープルウェア」でも、作業の標準化が悪として語られているわけではありません。なぜならプロジェクトが会社という組織で行われている以上、コスト管理というものが絶対に必要であり、それに必要なのは適切な見積もりだからです。見積もりを行うのに経験者の勘ではなく、一定の客観的な値をはじき出すには作業の標準化や計測が必要でしょう。「ピープルウェア」ではあえてこれに対して挑戦的な内容が語られていますが、それは多くの組織で空虚になっていることを批判するためだと考えています。

作業の標準化について同じようなことがこのホームページでも語られています。

作業の標準化」という言葉は、実に人を引き付ける言葉のようです。それが実現すれば、全ての問題が片付くかのような誘惑に駆られます。しかしながら「標準化」は、その手続きが策定された瞬間から“過去のもの”になってしまうことを忘れてはなりません。

約束できない組織は、実際に作業を「標準化」出来ません。たとえ、「標準化」出来たように見えても、1年以上、その「手順」が機能していることは、全く稀なはずです。昔、ある雑誌の調査で、「標準」が数年続いた組織が2、3あったという報告が為されていましたが、それはスーパーマンが存在したからであって、「標準」そのものが機能したわけではありません。その証拠に数年後には、その「標準」は使われなくなったのですから。

「間違った「標準化」の取り組み」より

私も知らなかったのですが、ソフトウェアプロセスというのは、決して作業マニュアルのことではなく、開発組織そのものを表しているのだそうです。これは「ピープルウェア」の問題と同じです。ですから、このホームページの内容とは一致する部分もかなり多いように思います。

このホームページは長い間少しずつ内容が追加され、多くの文章が公開されています。なかでも私が一番好きな内容は、「SCだより」にある「ソフトウェア開発201の鉄則」という文献の紹介です。私のようなソフトウェア工学の基本がよくわからない人にとっては大変役に立つ内容です。ぜひここだけでも読んでみてください。そしてできればこの本をぜひ熟読してみてください。

「藤原博文の館」

「Cプログラミング診断室」や「Cプログラミング専門課程」などの著作をされている方のホームページです。このホームページもたいへん内容が豊富ですべてを見るのには何日もかかってしまうでしょう。

このホームページでは「Cプログラミング診断室」や「(コ)の業界の掟」などの著作の全文が公開されています。なんて太っ腹なのかとは思いますが、せっかくですから遠慮せずにどんどん読んでしまいましょう。

どちらの本も基本的なスタンスとして、プログラマのレベルの低さを問題にしています。例えば、以下のような記述です。

どうしようもない、いない方が助かるようなプログラマが多数いることは周知の事実である。彼等がいなくなれば、生産性が上がる。いない方が、総生産量も上がる。品質に至っては、飛躍的に向上する。
胸のうちは、こう思っている技術者が多い。でも、ここは日本であり、「皆で仲よく」を何よりの美徳とする風土である。しかし、そのために、どんなに無駄に資金が使われているか分かったものではない。
世のプログラマのレベルが実際にどのくらいのレベルなのかを世間が知らなければいけない。それがなければ、決してレベルアップなど、いくら叫んでも空しいだけである。

「(コ)の業界の掟」から「プログラミング診断室」の章より

はっきりいいましょう。これは真実です。まちがいありません。技術者の技術レベルが低いのは、ヒットが打てないプロの打者のようなもので、なんの価値もないどころか、プロジェクト全体を駄目にします。私達はこのことを胸によく刻んでおかなければなりません。

私はプログラマが嫌でした。定められたプログラム仕様書に基づいてただコーディングしていくだけの機械的な作業者というイメージしかなかったからです。だから経験が浅いうちはプログラマとしてやっても、将来的には設計者にならなければならないと考えていました。しかし、この本を読めばわかりますが、プログラマとはそんなに甘い職業ではありません。

どんなに優れた設計をしてもプログラムが駄目だったら駄目です(もちろん逆も真ですが)。そしてプログラムには設計と同じ位にレベルが存在します。それは一朝一夕に身につくものではなく、学習と経験が必要なのです。私が見る限りこの業界ではこのことが軽く見られすぎているのではないでしょうか。プログラムを単なる肉体労働だと思っている管理者が多すぎるような気がします。

こういった内容は「ピープルウェア」では触れられていません。技術よりもむしろ組織に重点をおいているからです。確かに、組織の技術レベルが低ければ個々の技術も低くなるとは述べています。しかし、技術自体のレベルをあげるためには勉強をしたり情報を収集する努力が必要です。技術レベルを高くするための方法やそれがどれほど重要なことかをこのホームページは教えてくれます。

RDB研究館

私の専門分野でもあるデータベースの技術情報を扱っているホームページです。RDBを扱う人なら絶対にすべて読んでおいてください。これらは必須の内容です。また、技術分野ごとに掲示板があり有用な情報が毎日書かれています。最近は回答を書くことは少なくなってしまいましたが、職場で毎日2回から3回は内容をチェックしています。

このホームページで面白いのは「現場のぼやき・ちょっといわせて」というタイトルの掲示板です。「ピープルウェア」で述べられているような内容について実際の職場からいろんなぼやきが書かれています。私はこのボードには何も書いたことはありませんが、じつは一番楽しみにしている掲示板だったりします。

リンク集も有用なリンクばかりです。上記の2つのサイトへのリンクもあり、さすがといわざるをえません。

Back Picture

SEO [PR] 爆速!無料ブログ 無料ホームページ開設 無料ライブ放送