システム開発プロジェクトが失敗したとき、その要因として、開発者と利用者の関係がどうであったか、両者が利用者業務のモデル化にどのように取り組んでいたかということが、いつも問題になります。
以前ある企業で、立て続けに３つの大きなシステム開発プロジェクトの失敗があり、企業活動に深刻な影響が及びました。その原因を分析し今後の対策を立てるため、プロジェクトの主要な当事者３０数名で長時間の討議を行ないました。延べ４０８項目の要因が抽出されましたが、そのうち３７％が組織運営・業務管理、２０％が能力開発、１６％が開発部門と利用部門との関係にそれぞれかかわるものでした。実際には、これら（および他の要因）が複合してプロジェクトの成否を決定していることが分かりました（菅野文友監修「ソフトウェア・プロジェクト管理」下巻）。
稼働後の情報システムに問題が発生したとき、現状では、一般的に開発部門が責任を回避し、利用部門の責任を問う声が上がる傾向があります。情報システムの専門家からさえ、十分な分析なしにそのような発言がなされることがあり、これは他の産業に見られない現象です。開発部門と利用部門の関係が、責任のあり方まで含めて真の意味では整理されていない、この分野の未熟さを示しています。
例えば東証で誤入力が起きたとき、取り消しができず大損害が発生したのは開発業者のプログラムミスが原因でしたが、当初開発業者の責任に対する言及には、「現場の志気がダウンする」「人間は神ではない。過ちを犯す存在だ」「賠償の恐れがあるのならシステム開発は請け負えない」など、感情的ともいえる反発が生じていました。
また、５０００万件の不明データを発生させた年金記録管理システム開発に関して政府の検証委員会報告書では、「調査結果」の中で開発業者の数々の問題点を列挙しているものの、結論と言える「責任の所在」と「今後の教訓」の中では、開発業者は不備データの処理について記録を残していないことが問われているだけです。
マンションで構造強度の問題が生じた場合、構造設計や施工にさかのぼり、回転ドアで事故が起きたとき、回転ドア設計技術の概念や歴史認識まで問われたのとは大きなちがいです（回転ドアの事故は、学問の４要件、概念、歴史、理論、方策のうち、前二者に原因が求められた注目すべきケースです）。
一連の東証問題が起きたとき情報関係のある学会は見解を発表し、ソフトウェアのバグやシステムの運用ミスは、建築物の施工ミスと同じ類の問題として認識すべきではないと、マスコミや社会に苦言を呈しましたが、どこがどのように異なるのか、はっきり示すべきでしょう。「人間は神ではない」と言ったのでは、建築も同様になります。
情報システムの専門家が利用部門の責任を問うのは、大きく２つの根拠にもとづくと考えられます。第１は、利用（発注）部門と開発（受注）部門の役割分担の標準化が、３０年以上前から、当初企業内、次いで国内、さらに国際的にまで明確になされてきたことです。第２に、そのような役割分担にもとづき、何をシステム化するのかという要求仕様定義をまとめて、承認を与え、システム完成後その定義にもとづいて検収を上げたのは利用部門ではないか、ということです。
第１の、役割分担の標準化について留意しなければならないことは、これら標準の検討と作成は、すべて情報システムの専門家によって行なわれてきたことです。利用部門にとっては、自分たちには思いもよらない、今まで必ずしもミッションとは考えていなかったむずかしい仕事を、さあ、これがあなた方のタスクですよ、と決められた形になっています。このような仕事が、主体的に、積極的に遂行される保証はありません。
第２の問題は、利用部門がまとめて、承認を与え、検収を上げた要求仕様定義の確度です。利用部門が、願望ではなく「定義」まで明確にしようとすると、次のような課題が出てきます。
（１）要求分析技法にはいくつかの種類がありますが、例えばこの連載の第７回で紹介した構造化分析技法に拠ると、システム化範囲の明確な定義は、将来論理モデルをもとに行ないます。現行物理→現行論理→将来論理のプロセスを情報システムの専門家の指導なしに進めていくのは、利用者にとって困難です。
（２）利用者は、利用者の職場の目的関数達成に必要な機能は提示することができます。しかし、その機能を実現するため、実は基礎となるトラッキング機能のシステム化が必要であったとしても、利用者にそれが提示できるとは限りません。
（３）同様に、利用者の職場の目的関数達成のためには、それに関わるＰＤＣＡサイクルの完結が必要ですが、利用者にサイクルのすべてを提示するスキルがあるとは限りません。オープンサイクルでも、目的が達成できるように見えることがあるからです。
（４）システム化範囲を確定するためには、その範囲がシステム化可能かというフィージビリティ・スタディが必要ですが、このタスクも一般的には利用者に実行が困難です。
したがって、要求仕様定義を明確にするプロセスも、情報システム専門家の積極的な指導がなければ円滑に進めることはむずかしいでしょう。
プロジェクトが失敗したとき、「利用者の要求があいまいだったから」「利用者も能力アップが必要」「オーナーシップ」などという言葉がよく聞かれますが、システム化に関する限り、利用者の能力を高めてその役割を果たさせるのは、情報システム専門家の責任という考え方に立たなければ、今後ともプロジェクトの失敗は回避できないと考えられます。
システム開発の設計、製作、テスト段階では、利用部門がその過程をガバナンスすることは、さらにむずかしくなります。一般的にいって、システムが複雑で大規模になればなるほど、その開発過程を利用部門がガバナンスすることは実質的に不可能になっていきます。ガバナンスには、ガバナンスとしてのキーとなるエンティティとプロセスが存在しますが、複雑で大規模なシステム開発の場合、それを見きわめることが利用部門の管理者にとってむずかしいからです。利用部門のガバナンスが可能になるのは、そのエンティティとプロセスおよび実行のタイミングを、開発部門が利用部門に懇切に説明し、管理者に理解させ実践させた場合に限られるとみてよいと思われます。
利用部門からだけではなくどの部門から見ても、情報システムの仕事は何をどうしているのか、分かりにくいものになっています。情報システムの専門家自体、専門外の人に分かるような平易な言葉で伝えられないことがその大きな要因です。外部の人に分からなければ、外部からのガバナンスが効きません。外部からのガバナンスが効かなければ、内部の人たちの間に、多くの恣意的な考え方を生み出すもとになります。グローバルな市場においてだけでなく、国内や企業内においてさえ、情報システム分野は「ガラパゴス化」する恐れがあります。情報システムの専門家にとって自戒すべきことです。
もしも、利用部門から出された方針や仕様が適切なものでないとき、開発部門はどのように対処すべきでしょうか。例えば、年金記録管理システムの場合、少なくとも次の３つの大きな問題があります。(1)大量の不良データがあることが分かっていて、そのまま移行している (2)キーとなるエンティティをまちがえている (3)ＰＤＣＡサイクルの完結しないシステム機能になっている。
(1)について開発部門は、利用部門から方針が出たのでそうしたと説明しています。 (2) (3)について、原案作成・ウォークスルー・承認の経緯は不明ですが、結果的にそのような不適切な設計が行なわれています。
専門家の仕事を律する規範として、技術者倫理があります。技術者倫理は、国際的な技術者資格を得るための要件になっているため、近年多くの大学・企業で教育が推進されています。もちろん、倫理はモラルが原点ですから、資格や教育にかかわりなく順守すべき事項です。
技術者倫理の基本的規範で第１に挙げられているのは、「公衆の安全、健康、福利を最優先にする」ということです。顧客・利用者のために誠実な受託者として行動することは、わが国の技術者倫理のお手本になっている米国の規範の場合、４番目に挙げられています。
技術者倫理の行動規範の中で最も重要な項目は、リスク分析義務です。したがって、年金記録管理システムの設計責任者は、上記(1) (2) (3)を実施したとき、国民に被害が出ないかどうかということを第１に考えて行動すべきでした。
技術者倫理はきわめて重要で順守すべきことですが、強制力をもたないため、すべての人を律することは不可能です。このため、建築、放射線、薬品、医療など、公衆の安全、健康、福利に影響の大きい分野では、法律による規制が行なわれています。
情報システムも、東証問題、年金記録管理システム問題などに典型的に現れているように、社会的な影響の非常に大きなものになってきました。そこで次に、情報システム開発業務にどのように法規制がかけられるか、可能性を考えていきたいと思います。
まず、現実に法規制のかけられている商品で、情報システムにきわめて類似の商品を考えます。情報システムの特徴は、抽象的な存在で、近年とみに複雑性が増し、販売者（開発者）と購入者（利用者）の間に、リスク情報など、大きな知識格差があることです。
類似の商品として、金融商品が考えられます。金融商品は、もちろん抽象的な存在ですが、商品の投資先がさらに次々と投資を重ね、その先にサブプライムローンが組み込まれていたりするなど、きわめて複雑なものが増えてきています。販売する金融機関側と購入する顧客側に、リスク情報など、大きな知識格差があります。
それでは、金融商品の取引には、どのように法規制がかけられているでしょうか。
従来、成人が申込書に印鑑を押して金融商品を購入し損失がでた場合、自己責任が当たり前でした。しかし、金融商品の複雑化にともない、取引の知識・経験などに乏しい人が、リスクの高い商品を購入し、大きな損失をこうむる可能性がでてきました。そこで取引法が改正されて、自己責任原則の前提として適合性原則が適用され、販売業者側に厳しい責任が課せられるようになりました。
ウィキペディアに、次のように説明されています。
「適合性原則とは、金融商品販売業者の側に、投資家の知識・経験・財産力・投資目的等に適合した形での勧誘・販売を求めるものである。これは販売商品のリスク内容について、投資家よりも販売業者の側が知悉していることから、販売業者の側に顧客の諸事情に適合した商品を販売する責任を求めるものと解釈できる。販売業者の側に金融取引の倫理を求めているものともいえる。金融商品に複雑な仕組みのものも増えており、投資家のリスクの理解力や受容できるリスク程度にもさまざまな場合があることからも、販売業者側により多くの責任を求めているものといえる。一般の商品やサービスではすでに常識化していることであるが、金融商品の販売においても、販売者側に顧客の立場に立った顧客志向の商品の開発・セールスを求めている、その象徴が適合性原則だともいえる。」
すなわち金融商品取引法では、リスク情報を多くもっている販売業者側に、顧客の知識・経験・財産力（予算）、投資目的などをよく調べ、必要な説明・教育なども行なって、顧客に適合する形で取引を進めることを求めています。
情報システム開発において、役割分担にもとづき要求仕様定義をまとめて、承認を与え、システム完成後その定義にもとづいて検収を上げたのは利用部門だから、以後のトラブルも利用者責任だというのは、ちょうど金融商品で、納得して書類に印鑑を押し購入したのは顧客なのだから自己責任だ、というのに相当します。
一方、情報システム開発における利用部門の役割に関し、企業内、国内、国際的な標準を検討し整備したのは、すべて情報システムの専門家であったことは先述しました。したがって、利用者側の役割についても、そのリスク情報は、情報システムの専門家のほうが豊富にもっています。そうすると、利用者部門の役割遂行に関してさえ、所期の通りなされるかどうかは、情報システムの専門家の側に責任があるということができます。開発者には、利用者の知識・経験・予算・目的などをよく調べ、必要な説明・教育なども行なって、利用者に適合する形で開発を進めていく責任があります。
適合性原則に立つと、利用者側から例えば年金記録管理システムの(1) (2) (3)のようなまちがった方針や仕様が出されても、それは利用者の考え方に問題があるのだから、説得し改善しなければいけないことになります。このような進め方は、適合性原則という名称こそ用いませんでしたが、利用部門に重要な役割や責任を果たしてもらうためのメタ的な役割と責任が開発者側にあるという逆説的な構造として、優れたプロジェクト管理ではつねに考慮されてきました。分析や設計段階終了時の、利用者・開発者合同のウォークスルー会議も、適合性原則を実現するための重要なイベントになっています。
９０年代後半米国からはいってきたPMBOK（Project Management Body of Knowledge）には、さすがと思うプロセスがいくつかありましたが、そのうちの１つが、組織（人的資源）に関する実行段階のプロセスです。このプロセスは、ただ１項目のみ定義されていて「チーム能力の向上」となっていました。この「チーム」は、ステークホルダすべてを意味していて、もちろん利用者がはいります。
適合性原則をキーワードに、今後どのように法制化が進められるか、法原則に詳しい人にも参加頂き、学会として研究ができればと考えています。
この連載では、情報と情報システムの本質に関わるトピックを取り上げていきます。
皆様からもご意見を頂ければ幸いです。