スタートページ主張・講演 マーフィーの法則(vol.2)はじめに・目次

Murphyology on Information Technology (vol.2) 2000s

10 システムの実装

レガシー時代では、プログラミングが中心的な実装作業であり、膨大なマーフィーの法則が発見されてきた。オープン時代、クラウド時代になっても、この伝統は続くであろう。


部品化/再利用(2011/01/12)

ソフトウェア構築の生産性向上、品質向上のために、ソフトウェアを部品化して再利用することが重要なことは、コンピュータが出現した当初から指摘されてきた。それなのに、現在でもオブジェクト指向だのサービス指向だのと騒いでいる。なぜソフトウェアの部品化/再利用は進まないのか?

部品箱をごみ箱にするな
 工業分野では、部品の標準化は常識である。例えばボルトの寸法はJISで定められており、「M6」と指定すれば、頭部分の寸法やネジのピッチは周知であり、いちいち指定する必要はない。しかも、それに対応するナットや工具があることが保証されている。標準化が生産性向上やコストダウンに貢献することは明白である。
 IT分野でも、昔からサブルーチンや標準パターンなどの標準化が試みられてきた。ところが実際には、公式ライブラリの利用が少ない、統一管理ができない私有ライブラリが数多く存在しているなど、有効に活用されてこなかった。オブジェクト指向やサービス指向では、コンポーネントの部品化と再利用が必須になるが、現実にはライブラリは、体系化されていない再利用不能なコンポーネントのごみ箱になっているのだ。
 そのため、ライブラリから適切な部品を探して、その機能やインターフェイスを調べる労力が大変で、独自に新規開発する方が手間が掛からないような状態になる。これでは、部品化/再利用が進まないのは当然である。
「探す」労力が「作る」労力よりも大きければ、部品化は実現されない
 教科書では、このような事態を改善するために、標準化推進の担当組織を作れとか、意識変革のキャンペーンをせよと指摘する。それは正しいことではあるが、サブルーチン時代から言われており、実効が得られなかったのである。もっと原因にさかのぼる必要がある。
 独自のボルトを設計して製造するよりも、JISの表を探す方が簡単だし、独自の新規仕様部品を用いるために多方面を説得するよりも、既存仕様の部品をうまく利用する方が手間が掛からない。工業製品の部品にはこのような特徴があり、部品化(標準化)が進んだのだ。
 それに対して、ソフトウェアの生産技術は、部品化を行うにはあまりにも発展しすぎてしまった。ソフトウェア部品を探すよりも、作る(プログラミングする)労力の方が小さい。しかも、素人でもそれなりに自作することができる。
 昔、アセンブラプログラムを紙カードに穿孔してコンピュータの順番を待っていた時代の方が、部品化・再利用が盛んだった(思想的には幼稚であったが)。現在でも、科学技術計算アルゴリズムなど、自分では作成できない分野では、サブルーチンやパッケージが使われている。
 このようなことを考慮すると、部品化の対象を再検討する必要があることが分かる。
複雑な部品は使えない
 「作る労力が大きな対象を部品化対象にすべきだ」とするならば、部品の粒度を大きくすることが考えられる。プログラムの一部を部品化するのではなく、業務システム全体を対象にするならば「作る」労力は大きくなる。
 実際に、ITでの部品化では、サブルーチンからオブジェクト指向へと部品の粒度を大きくしてきた。その究極がERPパッケージである。
 しかし、粒度が大きくなると、仕様を指定するための複雑性が非常に増大する。ERPパッケージをユーザニーズに合わせるためには、膨大なカスタマイズ(仕様指定)が必要になり、独自仕様で構築するよりも大きくなることすらある(業務をパッケージに合わせよという議論はここでの対象外である)。
 さすがに、これは極端だというので、粒度を「サービス」のレベルまで小さくしようという動向になってきた。ところが、最も共通化されているはずの財務会計ですら、A社のアプリケーション部品で償却計算を行い、B社の部品で在庫評価を計算して、C社の部品で財務諸表を作成するというような部品化にはなっていない。
 この部品化が円滑にできない理由はデータにあると思う。単一データの処理仕様は単純であっても、対象となるデータが大量で、しかもその記録方法が多様なことが、サービスの分割を妨げているのではなかろうか。部品化技術として、これまでにハードウェアやプログラミング言語からの独立は達成されつつあるが、データベースからの独立は、これからの問題であろう。

バグとテスト(2011/03/10)

「過ちを犯すのは人の常」で「世にバグの種は尽きまじ」であり、プログラムにはバグがつきものだ。バグに関するマーフィ学は長い歴史があり、多くの研究成果があるが、ここでは、昔の良き時代を振り返って現状を嘆くことにする。
 往年は、納期にゆとりがあったし、プロジェクト管理も鷹揚だったので、プログラマは自分の関心に応じてデバッグに時間を割くことができた。当時のベテランプログラマにとって、デバッグは知的好奇心をくすぐり、後輩から驚嘆の目で見られ、達成感を味わえるので、テストは至福の工程だったのである。
 ところが近年は、納期が厳しく、テスト期間を短縮する傾向がある。しかも、テスト管理が重視され、テストツールが普及してきたため、デバッグが無味乾燥の作業になってしまった。至福の工程どころか苦痛の工程になったのは嘆かわしいことだ。

バグ(虫)は隠れる。バグは跳ねる(作者不詳)
 1970年代までのプログラマならば、プログラムのエラーをバグ(虫)といい表すことを直感的に納得できるが、若い人には連想できまい。
 「真空管式コンピュータに入り込んだ虫の死骸が、誤動作を引き起こしたこと」がバグの由来だそうだが、プログラムのバグについては明確ではない。おそらく、エラー個所を発見して修正すると、他の場所で新たにエラーが発生する。それがノミが跳ねることを連想させたのであろう。
 当時は、ソースプログラムを連続用紙という長い紙に印刷して床に広げ、這いつくばってプログラムのエラーを探していた。これがフンドシのノミ探しを連想させることから名付けられたという説もあるが、日本独特の地方伝説であろう。
 這いつくばる姿はエリートに不似合いである。そもそも構造化プログラミングは、GOTO命令により数メートル先まで這うのを避けるため、モジュール化は一つのソースプログラムの長さを1枚の紙に印刷できる行数(現在ではディスプレイ表示のためにその半分程度の行数)にするためであり、どちらも「机上デバッグ」を実現することが目的だった。
 なお、虫との比喩で重要なのは、冬の間は活動しないが、春になると成虫になり動き出すことである。日次処理や月次処理でのバグが治まったので安心していると、4月初めの期末処理で動き出して大騒ぎになるのが慣例である。
(昔)コンピュータは思ったようには動かない。指示したように動く(作者不詳)
(今)プログラムが期待した通りに動く保証はない。うまく動いたら神に感謝せよ
 レガシー時代のベテランプログラマは、オープン環境に移行する際に大きなカルチャーショックを受けた。その一つにコンピュータ無謬性信仰の崩壊がある。レガシー時代では、見習いプログラマから「先輩! コンピュータがエラーを起こしました!」と報告を受けたとき、「コンピュータはキミが思ったようには動かないさ。キミが指示したとおりに動くんだ」と言い、「COBOLコンパイラにエラーはない。キミのプログラムにエラーがあるんだ。マニュアルをよく読め」と諭していた。
 しかし、パソコンの世界では「思ったように動かない」だけでなく、「指示した通りにも動かない」ことはよくあることだ。OSやミドルソフトはマニュアル(もしあればだが)の通りに動かない。そこで、「プログラマを疑うな。コンピュータを疑え」の方が一般的になってきた。
 また、GUI環境で自動生成されたプログラムは、ソースコードの解読が事実上困難でプログラマのミスを指摘できない場合もある。思いがけない動作をするのは、コンピュータの「誤り」ではなく「仕様」だというベンダもいる。「どちらも疑うな。違う言語や開発環境で作り直せ」というのが正しい対処であると推奨されている。この対処でも、作り直したプログラムが期待した通りに動くかどうかは分からない。
言語は思考を規制する
 日本語は右脳を使うので情緒的、英語は左脳を使うので論理的なのだそうだが、最初に覚えた言語の影響は恐ろしい。
 COBOLをネイティブとする人は、ポインタが理解できない。FORTRAN屋は、「count」を「icount」としないと不安に感じる(整数変数名はIかJで始まる規則があった)。JavaやPHPで育った人は、システム設計をせず、ソースコードを書いて「実験」しようとする。
 昔は配列は1から始まったが、現在では0からである。「配列の5番目の要素」といったとき、X(5)を指すのだろうか、x[4]なのだろうか? 「重点は次の3つです。第0に……、第1に……、そして最後の第2は……」と話す連中との対話は疲れる。
 言語は字種にも影響する。昔は大文字だけが使用され、その後、小文字だけになり、現在では混在している。さらに、大文字と小文字を区別するようになった。しかし、男子学生をStudent、女子学生をstudentと命名するプログラマとは付き合いにくい。
 このような環境では、往年のベテランは、デバッグ能力を発揮できない。変な言動をして冷笑される。「老兵は死なず。ただ消え去るのみ」となる。
(脱線)多くの言語があるのに、少なくとも日本語対応言語ではYで始まる予約語を持つ言語はない(私の不勉強? あったら教えてください)。その理由は、JISキーボードでYは「ん」に対応しており、日本語に「ん」で始まる語がないからだというが。
バグ発見能力が低ければ、納期を厳守できる
(逆)納期を短縮したければバグを発見するな
 最近は品質と納期が重視される。プログラムの潜在バグを減らすことが品質向上には重要だが、それには十分なテスト期間が必要で納期が長くなる。また、潜在バグ量は測定できないので、バグの発見・修正の履歴を累積グラフにして、その傾きが水平に近くなっとときに打ち切ることになる。
 バグ発見能力が低ければ、早期に水平の状況になる。すなわち、プロジェクトメンバーの能力が低いほど、納期は短縮できるのである。
 また、納期を短縮するには、意図的にバグを発見しなければ良い。どうせバグがあることはユーザも承知しているので、問題をSLAの交渉時期にまで先延ばしするのは容易である。さらに、管理能力の低いユーザならば、後日、実際にエラーが発生しても気付かないかもしれないし、プログラムが原因だと特定できないかもしれない。発生確率を考慮することはリスクマネジメントの基本である。
 このような総合的判断ができないバカがテストを担当すると、ささいなバグまで発見し、スケジュールを乱してしまう。また、マジメな連中は、多様な状況を配慮してテストケースを増やしてしまう。納期遅延を防ぐ最良の手段は、このような連中をプロジェクトチームに参加させないことである。
テスト工程は、ユーザがベンダを最も信頼する工程である
 システムテスト以降のテストでは、ユーザがテストデータを作成し、主体になって行う必要がある。ところが実際には、旧システムの先月データファイルといくつかの出力結果を渡すだけというケースが多い。ベンダがもっと積極的になるように依頼しても、「オタクの管理能力を信じて委託したのだから」という始末。どうせ「後になってエラーが見つかったら、タダで直させれば良いさ」と思っているのだろう。テスト管理よりもSLAの交渉に関心が高い傾向がある。
 テスト軽視には伝統的な原因もある。昔は情報システムのトラブルに寛容だった。取引先と業務上のトラブルがあると、「すみません。コンピュータにトラブルがありまして~」と言えば、互いにキズがつかず円満に収拾できた(これがシステム化の最大の効果だとも言われた)。
 しかし、現在では、システムのトラブルは大きな社会問題に発展することすらあり、ユーザが責任を追及されるようになってきた。それにもかかわらず、いまだにテスト軽視の習慣が残っているのは困ったものだ。

他人のふんどし指向アプローチ(2006/10/09)

下品な表現で失礼。「他人のふんどしで相撲をとる」とは、本来は自分よりも強い力士のまわしをつけることにより、相手に威圧感を与えることで、「虎の威を借る狐」のような意味であるが、ここでは「他人の成果を借用する」という俗解釈の意味で用いた。

システム開発論の歴史は「他人のふんどし利用の高度化の歴史」である
 部品化と再利用を重視したアプローチを「他人のふんどし指向アプローチ」という。システム開発論の歴史は、ふんどし利用の拡大の歴史だといえる。
 プログラミング技術では、アセンブラやFortranの時代からサブルーチンが重視された。オブジェクト指向言語ではそれが一般的になった。サブルーチンでのパラメータ指定がオブジェクト指向でのメッセージになったともいえる。
 事務処理の分野では、COBOLの時代から典型的なパターンを整理して標準化することが行われた。その可変部分の指定方法を工夫すれば簡易言語あるいはジェネレータになる。デザインパターンは論理的な発展形態だといえる。
 開発アプローチでは、まずRDB(リレーショナルデータベース)の発展に伴い、データの部品化・再利用を重視したDOA(データ中心アプローチ)から始まり、データのアクセス方法も対象とするOOA(オブジェクト指向アプローチ)へと進んだ。さらには、業務レベルの要素機能までも対象にしたのが、SOA(サービス指向アーキテクチャ)である。
 Web分野では、そもそも検索サイトが他人のふんどしで成立したものである。それが発展して、Webサービスになった。さらにWeb 2.0ではマッシュアップへと発展した。
ふんどしを貸してくれる人が多いと、誰のをどう使えばよいか分からなくなる
 このように、システム開発とは、自分でソースコードを書くのではなく、他人が作った部品を組み合わせて構築するのが普通な時代になってきた(プログラマというよりもアセンブラという方が適切?)。
 昔のサブルーチン時代でも、そのサブルーチンの存在を知らずに、あるいは探すのが面倒だとか、パラメータの与え方を調べるのが面倒だとの理由で、新規にコーディングすることが多かった。その部品が、ますます多くなってしまった。しかも、現在のアセンブラは、以前のプログラマと比較して、自分でふんどしを作る能力が低下している。
借りたふんどしは、長過ぎたり短過ぎたり
 使おうと思ったコンポーネントは、余計な機能が付いていたり、必要な機能がなかったりで使い物にならないことが多い。コンポーネント間の粒度が異なるのも厄介である。無理に使おうとしてインターフェイスを作るよりも、当初から自作した方が簡単なことが多い。
他人のふんどしは汚れていることもある
 他人のふんどし指向アプローチは生産性の向上になる。ところが、借りたふんどしにバグがあったり機能に不備があったりしたりすると、システム全体に影響してしまう。しかも、他人のふんどしを勝手に洗うのは失礼だ。
誰が自分のふんどしをしているのか分からなくなる
 洗い直そうと思っても、誰が自分のふんどしをしているのか分からない。仕方ないので、汚れたままにしておくしかない。その結果、みんなが汚れたままで使うことになる。

ERPパッケージ考(2008/3/26)

システムは「作る」から「買う」時代になり、さらに「所有する」から「利用する」へと変わりつつある。
 いまとなってはERPパッケージは過去の話題となった。しかし、大型商品の普及戦略を検討するには、ERPパッケージは適切な題材であり、多くの教訓を残している。古い話で恐縮だが、温故知新でもある。ERPパッケージの初期ブームのころを振り返ってみよう。

ERPパッケージは、普及とともにキャッチフレーズがトーンダウンする
 ERPパッケージが日本に上陸した当初は、「ERPパッケージはベストプラクティスだ。ERPパッケージに合わせて業務を変えることが、BPR(Business Process Re-engineering)実現への秘訣(ひけつ)である」がキャッチフレーズだった。
 ところが日本には、製番管理や価格事後調整などの慣習がある。それを「グローバル時代だ。日本独自の因習を捨てて、国際標準に合わせよ」とはねつけた。
 しかし、国内メーカーがそれらの機能を持つパッケージを提供し始めると、海外パッケージも一転して「日本企業にマッチした~」をうたい文句にするようになった。さらに、「ベストプラクティス」を調べてみると、自社のコアコンピタンスの分野では、長年かけて改良してきた自社システムの方が優れていることが判明した。すると、いつのまにかキャッチフレーズから「ベストプラクティス」がなくなった。
 「環境変化、競争激化の時代ではスピードが重要だ。ERPパッケージで短期間に稼働できる」とも宣伝した。ところが、実際には自社仕様で開発するよりも時間がかかることが分かり、「スピード」もいわなくなった。
 「縦割り個別システムから全社統合システムへ」についても、後述のように怪しくなった。それで現在では、「多くの言語・通貨が使える」と「海外の減価償却法が組み込まれている」が主要なキャッチフレーズになっている。
自社では使うな。他社に売れ
 これは初期の話。 如才ない企業では、ERPパッケージの機能ではなく、将来の市場を考えた。それで、その市場に進出するための手段としてERPパッケージを導入した。ねずみ講と同じで、早期にこの戦略を採用した企業は成功したが、出遅れた企業は外部進出ができず、仕方なく自社業務に利用することになった。
小さく産んで小さく育てる
 「縦割りの個別システムでは、全社最適化は図れない。ERPパッケージによって、全分野の統合を図れ」という。それならば、全業務を対象にしてビッグバンを導入するべきだと思う。個別業務を逐次拡大するのでは、既存システムとのインターフェイスシステムが必要になるので不適切である。
 ところが、ベンダは会計分野しか業務を知らないので「小さく産んで」として会計システムに絞って適用した。ところが、会計だけで大変な作業になってしまい、ユーザは疲れてしまった。ベンダはパッケージを売るという初期の目的は達成したし、他業務への拡大はリスクを伴うことが分かった。それで、いつになっても大きく育てないのである。
ユーザニーズを抑え込むには経営者を担ぎ出せ
 ERPパッケージでの成功の秘訣は、アドオンをしないことだという。それでは、実際に業務をしている利用部門は困る。ベンダは、そのような利用部門の口を封じるために、「経営者が中心になって、経営の観点から」ERPパッケージを運営するべきだという手段を編み出した。
 利用部門の趣味的ニーズを抑えることができたならば、現行のシステムも複雑怪奇にならなかったし縦割りシステムにもならなかったのだが、IT部門はあまりにも無力であった。ERPパッケージは、経営者を「オーナー」として引き入れることにより、これを見事に解決したのである。
 もっとも、この工作は長続きしない。経営者が関心を失うと同時に、ユーザニーズが目を覚ます。そして、気付いてみればアドオンの山になっており、バージョンアップ時に大騒ぎになる。
昼と夜とでERPパッケージへの評価は逆転する
 講演会では多数の導入企業の担当者がERPパッケージ礼賛論を展開する。ところが、彼らとの酒席では、全員が2度とやりたくないという。
ある部分に苦労すると、その部分の達成だけが全体の目的になる
 システム構築で苦労しているうちに、ともかく稼働させることが唯一の目標になる。それには、機能を大幅に無視する必要があるし、情報システム以外の対応は無視される。そして、情報システムが稼働したことにより、ERPパッケージ導入プロジェクトが成功したとして、プロジェクトは解散する。もはや、BPRうんぬんを思い出す者は誰もいない。
アーミーナイフだけで仕事をするのは難しい
(アーミーナイフとは、ヤスリやドライバーなど多様な機能を1つにまとめた多機能ナイフのこと)
 カスタマイズ(アドオン)をしないことがERPパッケージ成功の秘訣だといわれる。
 しかし、ユーザニーズは多様であり、それを無視することはできない。ユーザニーズの多くは、データ入力や情報出力に関するものが多い。それらのすべての機能をERPパッケージに求めるとカスタマイズが増大するのだ。その部分をワークフロー管理システムや情報検索系システム(データウェアハウス)に回し、ERPパッケージは中核の機能だけに絞るべきである。
 ERPパッケージ導入時には、あれもこれもできることを宣伝したがるし、導入後はせっかく導入したのだからといって、なんでもERPパッケージにやらせようとする。その結果、ERPパッケージが複雑になり、バージョンアップで苦労する。
PCソフトがERPパッケージならば、トカゲもミミズも恐竜のうち
 ERPパッケージの価格は年商の1%未満が限度だという。それで、従来は大企業が対象であったが、飽和状態に達したので、中小企業を対象にした低価格のERPパッケージの開発・売り込み競争が激化している。
 ところが、PCの会計ソフトや給与計算ソフトもERPパッケージを名乗っている。それで、アンケートによると、中小企業の大部分がすでにERPパッケージを導入していることになっている。
セット販売がだめなら、バラ売りをせよ
 すでにERPパッケージは陳腐化した。ERPパッケージでは全機能を統合していることが売り物だったが、今後はいかにERPパッケージ離れをさせるかが戦略になる。それで「統合」をチョン切って、「個別」に提供することを思いついた。それがSOAあるいはSaaSである。

次へ進む