システム統合のトラブルや，動かないシステムの事例が後を絶たない。システム開発のどこにどんな問題があるかを明確にし，改善することが急務になっている。事故や失敗から教訓を学び取る「失敗学」の提唱者である畑村洋太郎氏に，日本的なシステム開発の問題点や改善の方針などを聞いた。
失敗学のプロジェクトでは最近，システム開発の失敗に関しても研究されているようですね。
このところ，主に経営トップ層の方々から，システム開発の失敗をテーマに話を聞かせてくださいと言われる機会が増えています。それだけ不安感や危機感があるのだと思います。
システム開発では「流用設計」「付加設計」で失敗するケースが多いようです。例えば，みずほ銀行のシステム統合でのトラブルは，主に付加設計（既存のシステムに，付加的に要求された設計を加える）が原因でした。
そのほか，よく言われていることですが，関係者間でシステムについての概念を共有できていないとトラブルが起こりやすくなります。また，一見無関係に見えるけれど，複数の部署に実は深い関係があるといった「見えないリンク」も危険要因です。
こうした要因を抱えてしまう理由の一つは，システム開発が下請け，孫請けといった具合に縦方向に分割されているので，全体像が見えにくくなっていることです。
ホスト・コンピュータが中心だったころのシステム開発では，全体像を把握しているリーダーがいました。今はそういう能力を持つ人をあまり見かけません。失礼な言い方ですが，プロとは呼べない，素人集団が開発を行っているように見えます。日本のシステム開発は，20年ぐらい縮退しているような気がしてなりません。
そうした失敗要因を抱えないようするには，どうすればいいのでしょうか。
一つは，人間とシステムの関係が変わっていることに注意しなければなりません。機械やシステムの発達で，人間がやるべき守備範囲が狭くなってきています。また，条件を変えたときに何が起こるかを頭の中でよく考えることが大切です。これを「仮想演習」と呼んでいます。仮想演習をたくさん行えば，実際に開発に着手したときに失敗する可能性が低くなりますし，これまで気づかなかった新しい視点に気づくことができます。
もう一つ，いくらきちんとやろうとしても，定められた式やシナリオ通りにものを考えて解を出す「順演算の思考」だけでは，失敗や事故を防ぐことはできません。現在の事象，または起こりうる事象から逆算し，どこにまずさがあるかを見抜いていく「逆演算の思考」も必要です。
ある自動車会社では，設計の全体像と内容が決まったとき，デザイン・レビューという設計の見直しを設計者以外のメンバーで行っています。その際，順演算だけでなく，逆演算の思考で問題点をあぶり出しているわけです。
システム開発は，ほかのものづくりとは違う部分があるのでは。
そうですね。例えば，システム開発では，何を作り出すのかといった課題設定が難しく，多くの場合，制約条件は構築の途中で見えてきます。つまり，スペックを全部決めてからではなく，作りながらスペックを決めていくやり方が多いようです。そのため能率が悪く，手戻りが頻繁に発生します。
次々に細かい要求が出てくるのも，システム開発の特徴でしょう。現場の開発者は常に忙しく，何かまずいことに気づいても，それを全員で共有していこうという動きになかなかつながりません。
しかし，こうした話は何も新しいことではなく，昔から指摘されてきたことばかりです。皆気づいていながら改善しなかったわけです。二十数年前は，世界のソフトウエアの半分以上を日本が作っていたのに，今や数パーセントになってしまった，と嘆いているIT系企業の経営者がいます。しかし，それはこれまで改善に取り組んでこなかったせいで，当然の結果だと私には思えます。
一番の問題は，全体像をとらえることができなくなっていることでしょう。末端にいる人たちが懸命に仕事をしても全体像をとらえることはできません。全体像をとらえられる人が，きちんとした概念を持って見ていないとうまくいかないのです。数十億円，何百億円といった巨大システムでは，高い能力を持つ，システム開発のプロフェッショナルが絶対に必要です。
