ITから社会を映すNEWSを追う

<ITから社会を映すNEWSを追う>イージス艦事故にみるITの死角

2008/03/10 16:04

週刊BCN 2008年03月10日vol.1226掲載

規則も知識も役に立たない

システム開発の現場も

 2月19日午前4時ごろ、千葉・房総半島沖で起こった海上自衛隊イージス艦「あたご」と勝浦漁協所属のマグロはえ縄漁船「清徳丸」の衝突事故。防衛省の説明は二転三転し、事故発生から10日たっても全容が明らかにされない。テレビや新聞は官僚機構の「隠蔽体質」を指摘し、世論は苛立つばかりだ。卑近な事例だが、システムコンサルタントの加藤貞行氏は「システム開発の現場でも同じことが起こっている」という。規則があっても従わず、知識があっても行動に結びつかない。日本が危ない。(佃均(ITジャーナリスト)●取材/文)

■総員で救助活動をしたのか

 国民の生命と財産を守るはずの自衛隊。最新鋭のITを駆使したイージス艦。それがたった一隻の漁船を避け切れなかった。しかも防衛相に情報が伝えられたのは発生から90分後、首相が知ったのは2時間後。行方不明の2人の救出を最優先するのは当然として、直後、「もしそれが自爆テロの船だったらどうするんだ」と渡辺行革相が語ったのは正鵠を射たコメントだった。ITの死角だ。

 防衛省の最初の発表では、「当直員が清徳丸の灯火を確認したのは衝突の2分前」だった。それが翌日には「12分前」に訂正され、にもかかわらず自動操縦を解除しなかったこと、艦長は休憩(就寝)中だったこと、漁業関係者にマスコミと話をしないよう指示していたこと、当直士官が艦載ヘリで防衛省に急行して報告したこと、その場に防衛相も同席していたこと等々、首を傾げたくなる情報がボロボロと明らかになった。

 事故が発生した直後、「あたご」に乗り組んでいた300人がどのような行動を取ったのか、総力をあげて救助活動をしたのかどうか、そういう情報も出てこない。レーダーのデータも指示命令記録も明らかにされないのは、最新鋭のITを満載しているのに不思議な話だ。「海上保安庁が捜査しているさなかだから」という説明は、自分たちに都合がいいように情報を操作しているのではないか、官僚の隠蔽体質そのものではないかと勘ぐられる。

■頭デッカチのワガママ

 度重なる食品偽装事件や粉飾決算疑惑の会見をみても、情報を小出しにすれば最悪の事態を招くことは周知の事実だ。それが分かっていても同じことを繰り返すのは、情報伝達ルートのどこかに栓が詰まっているのではあるまいか。緊急事態が発生したときいち早く責任者に情報を伝えるのは常識中の常識で、規則もへったくれもない。ところが規則があっても従わず、知識があっても行動に結びつかない。

 本紙読者の身近なシステム開発でも同じようなことが起こっている。「これを何とかしないと、日本のITは全滅してしまいます」と言うのは、システムコンサルタントの加藤貞行氏だ。

 加藤氏はITシステム構築におけるプロジェクト管理のプロで、情報処理学会の企画運営委員を務め、『失敗のないシステム開発入門~良いシステムは良い設計から~』の著書もある。1960年代末からシステム開発業務に従事し、90年代にプロジェクト管理を専門に引き受けるようになった。DOA(Data Oriented Approach)に基づくマネジメント手腕が評価され、「最近は、失敗一歩手前のヘタレプロジェクトの立て直しを依頼されることが少なくない」という。

 「ヘタレプロジェクトに共通するのは、要求仕様があいまいなことと、机上の空論で作られた開発計画」と加藤氏は断言する。

 続きを聞こう。

 「PMBOK(Project Management Body of Knowledge)の考え方が普及するにつれ、WBS(Work Breakdown Structure)によるプロジェクト管理が行われるようになりました。WBSはプロジェクトの目的を定め、最終的な成果物(製品、サービス、結果など)を具体的に決定し、その成果物を要素や中間成果物に分割・定義することで作成され、そのWBSがプロジェクトでのアクティビティ(実際の作業)となるわけです。

 ところが現実には、開発手順の最終成果物を列挙してWBSを定義することで事足れりとしている。私が立て直しを依頼されたプロジェクトでも、成果物の定義が曖昧なままプロジェクトが進行し、結局はデスマーチ(死の行軍)状態を呈していました」

 どういうことかというと、要するに現場を知らない頭デッカチが机上で組み立てた開発計画が、現場でソフト技術者の消耗戦を生み出しているわけだ。PMBOK、WBSに限らず、DOA、UML(Unified Modeling Language)、VDM(Vienna Development Method)といったシステム設計手法は、いずれも実践から編み出されたものだが、それを絶対の方程式としてすべてに当てはめようとするので無理が生じる。

 その無理を生み出すのは、おおむね頭デッカチの口先理論家だ。彼らはそうした知識を書籍から得ていることが少なくない。口先理論家は学歴偏重の組織においてはエリートとされ、プロジェクトリーダーになる。そういう人たちはワガママで責任回避能力に長けている点で共通している。

 実践の修羅場からDOA、PMBOKに到達した加藤氏からすると、そのような口先理論家が大きな顔をしているのが許し難いのに違いない。その思いが「このままでは、日本のITは全滅する」という言葉になっている。

 理論や規則(理屈)は実践の失敗から生まれる。「辞書にこう書いてある」は一つの論拠に過ぎず、現場での判断には、辞書の表記が間違っている(かもしれない)というリスク予測も織り込まれなければならない。何か事件が起こると法制度を改め、ガイドラインや審査を厳しくして、あとはIT任せという風潮は、現場との乖離をさらに加速することにほかならない。

 今回の海難事故について、テレビや新聞は「イージス艦に回避義務があった」と責め立てる。艦長や当直士官の判断なしでも自動操縦を解除する当直員がいなかったのは、何事もなければ責任を問われるだけだからやむを得なかったのだろうか。目的は「衝突しないこと」だったはずである。もしどこかから攻撃を受けたとき、「命令がないから」で戦えるか。失敗できる仕組み、失敗を許す組織というものを、そろそろ真剣に考えなければならないようだ。

ズームアップ
PMBOKとWBS
 
 PMBOKはプロジェクトマネジメントに必要な知識を体系的に整理したもの。(1)目的と範囲(2)時間(期間)(3)コスト(4)品質(5)人的資源(6)コミュニケーション(7)リスク(8)調達(9)統合管理の観点を設定している。米国の非営利団体Project Management Institute(PMI)が策定し、広く普及している。PMBOKに準拠した国際認定資格が「PMP」(Project Management Professional)だ。
 WBSはプロジェクト全体を個々の目標(成果)に細分化し、目標達成のための作業を関連付けて階層型に整理する手法。作業を遂行するのに必要な人員や資材・機器を配置することでプロジェクト推進組織が形成され、これに時間軸を加えることで作業進捗の管理に援用できる。
  • 1