オンラインジャーナル/部会、SIG、P2Mクラブ

先号　　　次号

「こんなにひどいシステム開発が行われているとは！」

　先日下記のような新聞記事を読んで愕然とした。まずは記事の紹介から。

朝日新聞　2011年10月12日(水曜)朝刊
――――――記事(原文どおり)―――――――――――――――――――――――――
　新型インフル対策
　記録システム不備
　検査院指摘　開発に1億円
　新型インフルエンザの水際対策として、厚生労働省が導入した健康監視の記録システムに不備があり、これを備えた全国の港の検疫所31ケ所すべてで全く活用されていないことが、検査院の調べでわかった開発には約1億円かかったという。システムを改善すると新たな費用が発生するため、検査院は厚労省に対し、港の31カ所では運用の中止を求めるとみられる。
　不備があったのは、感染症が流行する国から飛行機や船が到着した際に、飛行機や船、人数などを入力する記録システム。新型インフルが世界的に流行した2009年に導入され、全国の空港や港にある検疫所51カ所に順次配備した。これらの記録を集計した日報や月報を厚労省に送り、調査・分析などに使用する。
　しかしこのシステムでは、便名を入力するスペースにアルファベットと数字の7文字しか入らず、名称が長い船の便名を正確に入力できない。このため、31力所の港の検疫所では使用せず、以前から使っていた表計算ソフトなどを利用しているという。
　一方、空港の検疫所では便名を7文字で入力できるため、このシステムを利用している。
――――――――――――――――――――――――――――――――――――――――
　システム開発を行わない方から見れば単なる1億円の税金の無駄遣いとしか思えないかもしれませんが、システム開発を職業としている筆者のようなものからすると、税金1億円の無駄遣い以上に、日本のシステム開発力がここまで落ちたのかと思わせる記事でした。
　システム開発業界では「業務要件は顧客からヒアリングし、顧客の確認承認を得ることこと」とよく言われ、そのように教育されている。一見正しいようですが、このことはほんとうに正しいのでしょうか？業務要件の1から100まで全て顧客から聞き出すことが正しいことでしょうか？
　筆者はシステム開発のプロジェクト・マネジメントを指導しているが、業務要件のすべてを顧客から聞き出し、SEの知見を加えると思っていない技術者が非常に多い。極端な例だが、性別は男女の2種のみであることは一般的には正しいが、業界によっては服飾業界では性別といっても、男物、女物、ユニセックスの3種が存在してしまう。業界によっては同じ性別でも2種類の場合も3種類の場合も存在する。システム開発を行う技術者は対象とするシステムの業界に興味を持ち、技術者自身の知識とあわせ顧客と話し合い業務要件を決めなければならない、基本的なコードの桁数、種類などを間違うとそのシステムの存否にかかわってしまう。では今回の記事のトラブルがなぜ生じたか想像してみよう。

1．	システム開発技術者から顧客(厚労省)への要件に関する質問
	・	検疫所はどこにあり、何をしているのでしょうか？
		Ans )	小樽港、塩釜港、成田国際空港、東京港、横浜港、新潟港、名古屋港、大阪港、関西国際空港、神戸港、広島港、博多港、那覇港に検疫所を設け、検疫法・感染症法・食品衛生法などに基づき、渡航者や輸出入食品に対する検疫業務を行う。所管課は健康局結核感染症課および医薬食品局食品安全部企画情報課。
	・	今回のシステム開発で管理するのは輸入する航空機、船舶の単位とした場合管理する名称、コードはどのようにすべきでしょうか？
		Ans )	航空機にあっては便名7ケタとします。筆者コメント航空機の便名にはスリーレターコードとツーレターコードがあり：Wikipediaによれば。「各空港や都市名などの名前をアルファベットや数字の組み合わせ3文字で表した略号。東京はTYO、パリはPAR、ニューヨークはNYC。成田空港はNRT、関西空港はKIX、ロンドンのヒースロー空港はLHR。香港は都市も空港もHKG。航空会社にもスリーレターコードはあるが、国際的にはツーレターコードのほうがより一般的。(例)日本航空　JAL(3レター)→JL(2レター)全日空ANA(3レター)→NH(2レター)、ユナイテッド航空　UAL(3レター)→UA(2レター)　ノースウェスト航空　NWA(3レター)→NW(2レター)」とある。上記のようにWikipedia程度で裏付けができる場合もあるが、正式文書、法令等の調査を行う必要もある。
		船舶の場合下記のような数例の答えが考えられる。
		Ans 1)	船舶にあっては調査後返事します。その後調査結果を督促しなかった？
		Ans 2)	船舶にあっては船名とします。桁数、字種(全角・半角)を確認しなかった？
		Ans 3)	船舶にあっては船名、30桁とします。ヒアリング結果を議事録に記載せず、失念してしまった？入国するのは航空機のみと思いこみ確認するのを忘れてしまった？
		結果からすると、SE側の確認行為に大きな誤りがあったのは確実のようだ。本原稿を書いていて分かったのだが船舶の名称の特定には「船舶識別符号」を名称として採用することを検討する余地があったような気がするが、「船舶識別符号」は厚労省管轄ではないようなので、開発側の技術者が調査し提案しないと検討もされなかったであろう。　官公庁のシステム開発では発注主の原課以外のことは業務内容であっても省内でも省外でも、開発側が主体的に調査しないと、発注主の原課の要求仕様自体が誤っていることもある。又ITの先進的技術については入札仕様書に実現不可能な記述がある場合もあり、開発側が積極的に調査提案しないと動かないシステムを開発しかねないこともある。官公庁では、システム化するに必要な業務知識がキャリアとノンキャリアで分断され、業務全体のマクロ的視点からシステム化するに必要な業務の詳細を一気通貫で理解している人員・組織を持っていないことが問題の根源にある。
2．	発注者側の仕様確認能力　今回の事例は厚労省という国家公務員の身分制度特有の問題がある。実務に詳しいノンキャリアと承認行為を行うキャリアとの間には根深い身分上の問題があり、要件定義の内容をレビュー出来るノンキャリアは仕様の誤りに気がついても、キャリアは誤りに気付かず承認してしまうことがよくある。キャリアは実務を知ったかぶりし、ノンキャリアは承認の責任はキャリアにあるので誤りを指摘しないで逃げてしまう問題もある。ノンキャリアは日ごろの処遇の低さを、キャリアに誤りを教えないなどという低レベルの底意地の悪いしっぺ返しを行うことがよくある、実際に目にしたこともあった。　新人のキャリアに業務の基本的なことを教えない、退庁時間を待ってキャリアに翌日までに解答の必要な課題を投げてノンキャリアは退庁してしまうなどといういじめは、新人キャリアの誰もが会う洗礼のようだ。官公庁のシステム開発ではこのキャリアとノンキャリアの壁は、仕様決定、プロジェクト・マネジマント上の最大のネックになっている。より良いシステムを作ろうという姿勢が民間に比べて著しく低くシステム開発の効率は異常に低いものとなっている。
3．	顧客側に責任があるのか、開発側に責任があるのか？　業務要件が極度に専門的で、顧客特有のものであれば顧客側に責任があると言えるだろうが、この事例のように一般常識として船舶の入港を管理するのに船名が7桁で不足するのはシステム開発に関係の無い素人にも分かる、素人にも分かるようなことだからこそ会計検査院でも分かったとも言えるが、このようにシステム開発を行うプロでなくとも容易にわかるよう場合、顧客の確認・承認の有無に関係無く、顧客の責任を問うことは難しいだろう。SEとしての常識力が問われる典型的な例で、船名は「クイーン・エリザベスⅡ」などだれでも思いつくものであり、どう考えても7桁足りないことは明白である。　開発側の力量不足と呼ぶにもいたらないほどの低いレベルの開発力であり、この程度の力量で一億円ものシステム開発行ってはいけない。一億円のシステム開発なので名のある開発会社が元受だが、元受は設計仕様にタッチせず下請けに丸投げし、その先でまた丸投げ、下請けを繰り返し責任ある開発体制をとらなかったことがその原因の背景にあると思われる。　このように新聞に出てしまった事例で稀に発生したかのように思われてしまうかもしれないが、氷山の一角と思った方が良い。システム開発の至る所に本事例のような間抜けな事故は発生している。
4．	顧客の受け入れ体制　この事例のようにメインキーに誤りがあるようなシステムの納品を受け、検収するような場合、受け入れ検査自体を行っていないか、受け入れ検査を顧客側が行う能力がないか、受け入れ検査をシステム開発会社に丸投げしたかのいずれかで、顧客である厚労省が受け入れ者としての責任を果たしていなかったのも事実である。厚労省は年金のシステム開発でも致命的トラブルが発生に遭遇しており、厚労省のシステム開発力には大きな疑問がある。

　筆者はシステム開発プロジェクトのプロジェクト・マネジメントを現場で指導しているが、プロジェクト・マネジメントの指導以前に、要件定義の文章表現方法、理解出来る基本設計の記述方法等システム開発の指導に多くの時間を取られることが多く、この2、3年システム開発能力が発注者側、受託者側の双方で格段に低下している印象を持っていた。本事例は筆者の印象を残念ながら裏付けることとなってしまった。
　システム開発に関与するすべてのステークホルダー、特に開発業者の経営者・技術者、発注主の能力の低下は如何ともしがたい状態である。このような状況ではPMPの資格取得者をいくら増やしてもシステム開発のトラブルは無くならない、その結果システム開発業界ではプロジェクト・マネジメントへの情熱は下がる一方のようだ。
　今回の事例は日本のシステム開発プロジェクトにおいてあまりにも多くのトラブルの発生していることを想起させるだけでなく、日本のシステム開発は、民間、官公庁を問わず、あまりにも多くの根深い問題を抱えているかを改めて考えさせられる問題であった。

以上