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

Murphyology on Information Technology (vol.2) 2000s

08 システム要件

「役に立つシステムにするには、開発の初期段階であるシステム要件定義を的確に行うことが重要だ。それには利用部門が真剣に取り組む必要がある。」といわれるが、どうも、うまくいかないものだ。


可視化(2006/11/19)

「昔、文書化。今、可視化(見える化)」であるが、見えないシステムを見せることの重要性は綿々といわれてきた。ところが、なかなかうまくいかないものだ。
 ところで「システム開発の可視化」って、何を誰に見せること?

すべての文書化は本番移行後に作成される
 教科書では、外部仕様書、内部仕様書、操作仕様書などの文書の確認を得てから次のステップに進むことになっているが、実際には本番移行完了以降で作られる(もし、作られるとしたらであるが)。
 しかも、その順序は逆で、操作仕様書、内部仕様書、外部仕様書の順に作成される。
 なぜなら、まず利用者に使わせるには操作仕様書が必要である。そして、操作をすると、新しいニーズが起こる。それが可能かどうかを内部仕様書でチェックする。その後、明確になった外部仕様書を作成する。こうすれば「手戻りが発生しない」というのが、その最たる理由だ。
ソースプログラムこそ真実を示す唯一の文書
 「ドキュメントはありますよ。5年前のものですがね」
 同じ名称の文書が5つもあったなどというのは、そうまれなことではない。そのうちの3つには「最終版」と書いてある。仕方がないので、ソースプログラムを調べようとするのだが、ロードプログラムは存在するがソースプログラムはどこにあるか分からない。見つかったにせよ、バージョンが正しいかどうか分からない……。
 西暦2000年問題のときは大変でしたねえ。内部統制でも?
文書化するな。リバースエンジニアリングツールを使え
 合理性を重視する組織では一切の文書を保持しない。
 必要に応じてリバースツールにより、現行プログラムからUMLの図表を出力して内部仕様書だとする。オブジェクト名などを日本語(業務用語)に変換するために用語対応表により変換したものを外部仕様書だとすればよい。それが文書として適切かどうかを気にすることはない。どうせ、「文書がある」ことだけで満足するのだから。
図表化しやすいものだけが現実である
あるいは、例外無視の原則
 実際の業務は複雑系だから、DED(Data Flow Diagram:データフロー図)を描いたら縦横無尽な線が必要になる。そこで、作図者が重要だと思う線だけにする。しかし、実際には消した線で業務が動いているかもしれない。
 DMM(Diamond Mandala Matrix:機能構成図)では8つのサブ業務に分割するが、そのうち、計画とモニタリングは固定されているので、サブ業務は6つに決められる。7つあれば、1つは存在しないことにする。5つしかないときは、もう一つのサブ業務をデッチあげる。
 CRUD(Create、Read、Update、Delete)では、縦にエンティティやイベント、横にファンクションを取った2次元表にする。イベント独特のファンクションがあったり、ファンクションが少ないイベントがあったりすると、表が巨大になり空白の要素が多くなる。それを避けるために、そのような例外は存在しないことにすればよい。
 情報システム機能構成図では、システムごとに機能を記入するが、あるシステムでの機能が多いと所定の枠内に書き切れない。それで「など」と記述するが、その「など」の項目を参照されることはない。例外項目は別紙にすることになるが、その別紙は決して人の目に触れることはない。
「見える」ためには見る人の目が必要である
系:三角図法では素人は分からない。見取り図では制作できない
 可視化は関係者の理解を得るためにあるが、理解させたい相手(経営者など)は、このような判じ絵のようなものを見ようとはしない。分かりやすくするためには、厳密性を欠くことになる。厳密性を欠いた文書では、システム設計ができない。
 それで、複数の図表を作る必要が生じる。ステークホルダーが多様になるに伴い、多数の図表が求められるようになる。当然、それらの図表間には矛盾がある。それで、経営者が壁に飾られた図表(黄ばんでいる)をうっとりと眺めているときに、それとは無関係の業務や情報システムが動いているのである。
人間は左右同時には見えない
 これらの図表は、全体をある視点で切り取ったものであり、象の一部をある角度から見ているだけである。例えばDFDでは、物理モデルと論理モデルを別のDFDにする必要があるし、コントロールやタイミングを記述できない。それで、全体を理解するには、多数の図表を関連付けて理解しなければならない。それができるのは、よほどの専門家か暇人に限られる。
 図表間の整合性を管理するためのツールもあるが、そのようなツールを使には、上述の「例外無視の原則」をますます強固にする必要がある。
可視化は関係者すべての満足につながる
 そのうちに、可視化基準がISO化され、「可視化適合性評価制度」ができ、審査員試験やマーク授与など新しいNPOや特定法人が設立されるであろう。
 IT部門は、図表を作成したことで、仕事をしているように見せかけることができるし、経営者の理解が得られているという免罪符を得ることができる。経営者は、自分が理解できないにせよ、金文字背表紙に製本して、社長室の本棚に飾り、ITガバナンスが確立していることを訪問者に示すことができる。監査法人やコンサルタントは、図表の枚数により収入を得ることができる。可視化が困難なほど、ツールメーカーの利益になる。誰もがその内容を見ることは少ないが。

システム要件(2010/12/15)

プロジェクトを成功させるには、開発ライフサイクルの最初のプロセスである要件定義が重要である。特に、ユーザニーズを明確にすることが重要だ。ところが「ニーズ」と「趣味」を区別するのは難しい。

「バカ・マジメ」をメンバーに入れるな
この法則は、オペレーションズリサーチの初期の名著にあったと記憶している。
 将兵は「リコウかバカ」「マジメとズボラ」に区分できるが、
・「リコウ・ズボラ」は将校にせよ
・「リコウ・マジメ」は下士官にせよ
・「バカ・ズボラ」は炊事当番にせよ
・「バカ・マジメ」は絶対にメンバーに入れてはならない!
というのだ。
 「バカ」というのは気が引けるので、以降「BM」という。
 情報システムの開発や保守にかかわる費用は、ブルックスの法則により、規模の指数乗に比例して増大する(右下に凸)。それに対して、情報システムの効果はパレートの法則により、機能(規模)の対数に比例して増大する(左上に凸)。このことから、「利益=効果-費用」が最大になる規模(最適規模)が存在することが証明される。
 「ユーザが必要なニーズを上げてこない」と嘆いたのは昔の話だ。現在では、ユーザが多様な要求をしてくるし、IT部門はそれを至上命令として受け入れる傾向がある。そのために、規模は最適規模を超えて利益は下がる。なかには、費用が効果を上回る過剰規模になることもある。
 このような状況にさせる元凶が、ユーザ部門からプロジェクトに参加したBMである。マジメなので新システムに取り組むべき機能を真剣に考える。利用部門の仲間に聞くだけでなく、他社の調査も行い、マスコミで取り上げた事例も研究する。なかには自分でニーズを「発明」したりする。そして、分厚い要件リストを作成する。
 教科書では、ユーザニーズに優先順位のランクを付けるべきだという。ところがBMは、バカなので自社の置かれている状況、利用者のレベル、費用対効果などの認識がない。しかも、マジメなので、これらのニーズはすべて自社にとって重要なランクであると主張する。そして、IT部門からのメンバーもBMだと、そのニーズを完全に実現することがプロジェクトの任務だと考える。
 ときには、BMでないメンバーもいるので、反対意見が出ることがある。ところが、BMは、プロジェクト内で反対に合うと、猛烈に抗議するだけでなく、所属部門の部長にも実現をするよう圧力をかけるように依頼するし、トップに直訴して「いかにこの機能が重要なのか?」を他社の成功例なども引用して説得する。部長やトップは、彼らは改善に真剣に取り組んでいるように見えるので、その意見を支持する。
 これにより、開発規模は過剰になってしまう。つまり、このようなメンバーが参加した時点で、プロジェクトの失敗は保証されるのである。
カスタマイズ・シンドローム
 ERPパッケージの導入で成功する秘訣は、カスタマイズ(アドオン)を抑えることである。ところが、趣味に基づくカスタマイズが好きなのはユーザの本能なのである。
 導入当初は経営者の眼があるのでおとなしくしているが、経営者の関心が低下するのに従い、カスタマイズへの誘惑を抑えきれなくなる。そして数年後には、カスタマイズの多いシステムになっていることが多い。このカスタマイズ要求の首謀者が、BMであることはいうまでもない。
 逆に、カスタマイズ排除への異常な伝道者になることがある。自社のコアコンピタンス業務ですら、パッケージに合わせべきだと主張し、反対者を非国民だと決めつける。
エンドレススパイラル・シンドローム
 近年は、スパイラルモデルやプロトタイプモデルのように、システム開発のライフサイクルを繰り返して行う方法が普及してきた。ユーザーが満足するレベルに達したら打ち切ることができるので、手戻りを少なくして開発期間を短縮するのに適した方法だとされている。
 ところが、BMな完全主義者がいると、「画面のフォントを変えたい」「棒グラフに影を付けたい」など多様な要求をする(その要求の大部分は入出力デザインなど非機能要件で個人の趣味に基づくので反論が困難である)。さらには、「前回変更したものを以前のものに戻せ」などともいう。この結果、このシステムは永久に完成しない。
 しかも、並行しているほかのサブシステムにもBMがいると、ばらばらなシステムになってしまう。さらに、それを統一せよといい出すようになると、スケジュールは絶望的になる。
本管と蛇口を分離せよ
BMでないメンバーは、最適規模での開発を主張するであろう。ところが、ユーザの立場は多様である。全体的には優先順位が低くても、そのユーザにとっては重要かもしれない。あるいは、将来的には価値のある機能かもしれない。それらをむげに否定するのは不適切である。
 これを解決するのが、データウェアハウスのような情報検索系の普及である。すなわち、このプロジェクトでは、必要となる情報を得るためのデータの収集と整理までは行うが、それからの検索抽出・集計加工などは、EUC(エンドユーザーコンピューティング)に任せるのである。
 このような対策により、ユーザー要求の多くを取り下げさせることができる。
系:軒を貸して母屋を乗っ取られるな
 ユーザーが過剰体裁愛好症に罹っているとEUCでもトラブルの種になる。
 EUCの適用分野は、自分あるいは自部門に限定した蛇口部分に限定すべきなのだが、それに飽き足らず、あるいは、要件定義で却下された自分の意見を実現するために、本管に関係する分野にまで侵略する。
 内部統制におけるExcelシステムが問題になっているが、これが原因であることが多い。

外注システム開発(2008/01/08)

システム開発の外注では、RFP(Request For Proposal)の作成やベンダの選定から納入、アフターフォローにいたるまで、いろいろな局面で留意すべきことがある。

ないものねだりのRFP
 システム外注を円滑に行うには、適切なRFPを作成することが重要だという。
 IT成熟度が未熟な中小企業にもそれを求めている。しかし、適切なRFPを作る能力はIT技術者の最高能力の一つであり、素人にそれができるはずがない。ないものねだりの典型例である。  それで、RFP策定にコンサルタントを使えというが、そのコンサルタントにも適切に説明できない。そこで、コンサルタントの質問に答える形式になるが、コンサルタントが適切な質問をしないので、ますます思っていることと異なる方向へいってしまう。
コンサルタントの食い逃げ。ベンダの我田引水
 RFP作成あるいは外部仕様書作成までの工程と、具体的なシステム構築の工程を切り離して契約せよという。
 ところが、前者でのコンサルタントは、絵に描いた餅、机上の空論に終始した分厚い文書を残して去ってしまう。後者のベンダは、それを読んで「これでは構築ができない」といい、結局は自分勝手な仕様書に作り直してしまう。
提案の評価は、RFPの内容とは無関係である
提案書の説明会は、PowerPoint(最近はタブレットと動画に移ってきた)のテクニック競技会の様相になる。かなりの準備をしたと感心する初心者もいるが、他社から転職してきたベテランIT部員は、先の職場でも全く同じ画面を見たことに気付く。もっとも、これを揶揄するべきではない。ベンダの情報共有化や、部品再利用の成熟度を示す尺度になる。
 当然、経営者はそのような表面的なことには惑わされず、提案内容を重視する。ところが、その内容がRFPの要求をどのように解決しているかには関心を持たない。関心を持つのは「貴社を取り巻く経営環境」とか「競争に打ち勝つには」など、提案の枕言葉の部分だけである(経営者が理解できるのはこの部分だけなので)。
 これを理解しているベンダは、その枕言葉に大部分を割き、提案内容は「ですから、弊社にお任せいただくことが最適なのです」の1行だけにする。当然、この枕言葉はベンダが調査・理解したものではなく、業界誌の記事をPowerPointで編集しただけである。
ベンダ選定は提案書の1行だけで決まる
 多くの場合は、上のような冗長な評価方法は採用しない。
 経営者にベンダ選択の提案をするとき、最安候補以外の候補を推薦するには、かなり面倒である。それで、提案書の「見積金額」だけがベンダ決定の要因になる。
 最安ベンダに見積金額(いくばくかの値下げをするのがマナーである)で契約し、その後の交渉によりRFPと提案内容の摺り合わせを行い、合意した内容で正式のRFPと正式の提案書が作成される。
2423の法則(作者不詳)
 当初は、2の機能のシステムを2の料金で契約する。作業を進めている間に多様な追加要求が出てくる。ベンダは追加機能だとして4の料金を求めるが、発注側は仕様解釈のうちだとして2の料金に固執する。結局のところ、ベンダは2の料金で3の機能を持つシステムを開発する。
 ベンダは2の料金で3の機能を作らされたとして、1の不満を持つ。発注側は4の機能を求めたのに3の機能になってしまったとして、1の不満を持つ。これが公平な取り引きというものだ。
管理を強化すれば裏取引が増加する
 仕様変更のトラブルを避けるために、双方が責任者を決めて、ささいな変更であっても署名捺印する仕組みにするべきだといわれる。
 ところが、発注側の担当者は責任者に報告説明するのが面倒だし、ベンダ側の担当者はプロジェクトリーダーに報告説明するのが面倒である。ここで、担当者間での裏取引が成立する。担当者間の取引は、交際費を用いて一杯やることで決済が終結する。
ベンダの数だけ「標準」が作られる
サーバの数は、ベンダの数に比例する
 判断基準を見積金額だけにすると、案件ごとに異なるベンダになる。
 ベンダは、それぞれ自社のシステム開発の標準を持っている。提案書にはその標準を用いることが書いてあるが、そのようなさまつなことを重視する経営者はいない。その結果、社内には多数の「標準」が乱立することになる。多様なOSやミドルウェアが存在するのも同様な理由である。
 また、システム構築のときに既存のサーバを用いると、他社が開発した既存システムとの調整が面倒である。そこで、開発用として臨時に新しいサーバを設置する。実施後は撤去されるはずなのに、その開発用サーバをそのまま(グレードアップして)本番用にするのが通常である。その結果、多数のサーバが林立してしまう。
ユーザがベンダを最も信用するのはテスト段階である
 ユーザが真剣にテストデータを準備することはまれである。
 前月データを渡してその結果をチェックするだけである。そのために、誤りデータのチェックをすることはほとんどない。テストのときだけは、ベンダは間違いを犯すようなヘマはしないと信じている。
 信じているからこそ、エラーは裏切りだと思う。それでSLAの条件を厳しくして、ペナルティ条項を主張するのである。

次へ進む