(注)「他人の褌(ふんどし)で相撲を取る」とは、本来は自分よりも強い力士のまわしを着けることによって相手に威圧感を与えることで、「虎の威を借る狐」のような意味であるが、ここでは「他人の成果を借用する」という俗解釈の意味で用いた。
システム開発の歴史は「他人のふんどし」の歴史!?
情マネ流マーフィーの法則その4
システム開発論の歴史は「他人のふんどし利用の高度化の歴史」である
部品化と再利用を重視したアプローチを「他人のふんどし指向アプローチ」という。システム開発論の歴史は、ふんどし利用の拡大の歴史だといえる。
プログラミング技術では、アセンブラやFortranの時代からサブルーチンが重視された。オブジェクト指向言語ではそれが一般的になった。サブルーチンでのパラメータ指定がオブジェクト指向でのメッセージになったともいえる。
事務処理の分野では、COBOLの時代から典型的なパターンを整理して標準化することが行われた。その可変部分の指定方法を工夫すれば簡易言語あるいはジェネレータになる。デザインパターンは論理的な発展形態だといえる。
開発アプローチでは、まずRDB(リレーショナルデータベース)の発展に伴い、データの部品化・再利用を重視したDOA(データ中心アプローチ)から始まり、データのアクセス方法も対象とするDOA(オブジェクト指向アプローチ)へと進んだ。さらには、業務レベルの要素機能までも対象にしたのが、SOA(サービス指向アーキテクチャ)である。
Web分野では、そもそも検索サイトが他人のふんどしで成立したものである。それが発展して、Webサービスになった。さらにWeb 2.0ではマッシュアップへと発展した。
情マネ流マーフィーの法則その5
ふんどしを貸してくれる人が多いと、誰のをどう使えばよいか分からなくなる
このように、システム開発とは、自分でソースコードを書くのではなく、他人が作った部品を組み合わせて構築するのが普通な時代になってきた(プログラマというよりもアセンブラという方が適切?)。
昔のサブルーチン時代でも、そのサブルーチンの存在を知らずに、あるいは探すのが面倒だとか、パラメータの与え方を調べるのが面倒だとの理由で、新規にコーディングすることが多かった。その部品が、ますます多くなってしまった。しかも、現在のアセンブラは、以前のプログラマーと比較して、自分でふんどしを作る能力が低下している。
情マネ流マーフィーの法則その6
借りたふんどしは、長過ぎたり短過ぎたり
使おうと思ったコンポーネントは、余計な機能が付いていたり、必要な機能がなかったりで使い物にならないことが多い。コンポーネント間の粒度が異なるのも厄介である。無理に使おうとしてインターフェイスを作るよりも、当初から自作した方が簡単なことが多い。
情マネ流マーフィーの法則その7
他人のふんどしは汚れていることもある
他人のふんどし指向アプローチは生産性の向上になる。ところが、関係している要素にバグがあったり機能がダウンしたりすると、システム全体に影響してしまう。しかも、他人のふんどしを勝手に洗うのは失礼だ。
情マネ流マーフィーの法則その8
誰が自分のふんどしをしているのか分からなくなる
洗い直そうと思っても、誰が自分のふんどしをしているのか分からない。仕方ないので、汚れたままにしておくしかない。その結果、みんなが汚れたままで使うことになる。
著者紹介
▼著者名 木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」(日科技連出版社)、「もうかる情報化、会社をつぶす情報化」(リックテレコム)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している
- 情マネ流マーフィーの妖誤集〜その3
- 情マネ流マーフィーの妖誤集〜その2
- 情マネ流マーフィーの妖誤集
- 情報科学の法則を復習しよう
- 社会科学法則の「情マネ流マーフィー」への適用
- 自然科学法則の「情マネ流マーフィー」への適用
- コンピュータが発展すると人間はバカになる
- バグとの長い長い付き合い
- なぜソフトウェアの部品化/再利用は進まないのか?
- “バカ・マジメ”をメンバーに入れるな!
- なぜIT部門は提案できない/しないのか?
- ユーザーニーズを基にシステムを作るな
- 成果の出ないIT戦略
- IT技術者、どう評価する?
- 何かが足りない日本のIT教育政策
- 電子政府の研究はIT推進の教科書として最適だ
- 日本にはびこる素人CIO
- IT部門の戦略部門化は矛盾だらけ
- なぜIT部門アウトソーシングがうまくいかないのか?
- IT部門の社内的地位が低い“本当の原因”は?
- 役に立たないグループウェア
- ユーザーの過度体裁愛好症が問題だ
- ユーザーの過度依存症とIT部門の没我的愛情症
- ああ、上司と部下の悲しいすれ違い
- IT系アンケート結果は信用できない
- “クラウドコンピューティング○×”の寿命
- 羊頭狗肉のIT用語、誇大表示を告発する
- そして、歴史は繰り返す − 2度目は喜劇として
- ITエンジニア今昔物語
- “リスク管理のリスク管理”が必要だ
- 納期とは遅れるものだ
- ITの効果とはプロジェクトの効果だ
- 費用対効果を追求することで出銭が増える愚かさ
- そもそも、IT計画が実現すること自体が奇跡だ
- 経営者にITの費用対効果を説明するのは難しい
- ERPパッケージの不思議あれこれ
- 合併時の代理戦争には気を付けろ!
- ないものねだりのRFP
- 標準化にメリットはあるのか?
- システム開発の可視化で何が見える?
- 「他人のふんどし指向アプローチ」を考える
- マーフィーの法則がIT版になって帰ってきた!
Copyright © ITmedia, Inc. All Rights Reserved.