前回の動かないコンピュータ・フォーラムで「未熟な業界だから動かないコンピュータが増えるのか」と題して，動かないコンピュータを減らすための取り組みについて募集したところ，170人を超える方からをご意見をいただきました。
今回は，これらのご意見を中心にして，動かないコンピュータの撲滅のために業界としてどのような取り組みが有効なのか，あるいは既存のどのような考え方や基準を生かすべきなのかについて考えていきたいと思います。
業界で取り組めることが三つある
まず，「動かないコンピュータを減らすためにユーザー，ベンダーを含め業界全体で取り組めることがあると思いますか」という設問に対する回答ですが，「あると思う」が70.8％，「思わない」が12.3％，「分からない」が16.9％でした（有効回答数171）。多くの方が業界全体での取り組みに期待されています。
具体的に，どのような取り組みをすれば動かないコンピュータを減らすことができるのかというご意見は，大きく三つのパターンに分かれました。
一つは，業界全体で開発や契約についての標準を作るべきというものです。二つ目は失敗事例のデータベースの構築で，三つ目はトラブル発生後の仲裁機関を設けるべきではないか，というものでした。これらのご意見を順にご紹介したいと思います。
まず標準や枠組みとなるものを作るべきだというご意見です。こういったご意見の背景にある感情は以下のようなものでしょう。
実現性という観点では夢物語だが・・・ 実践的な共通フレームワークがないことではないか？ 計画レベルでは｢そもそもの無理の排除｣ 実行レベルでは意識・認識の共有化 よく，｢ガラス張り｣という表現が使われるがこれを実現したケースが本当にあるのだろうか？ 結局は全ステークホルダーの人間力の高さが問題かもしれない・・・夢物語でしょ？
違う視点からのご意見もありました。
ノウハウを共通化・共有化することに尽きると思う。とくに「2007 年問題」を控えた今，それは急務だ。オープンソースなどの仕組みもその解決策の一つになるだろう。
一口に標準や枠組みといっても，さまざまなものを対象としたご意見をいただいています。まず，開発の上流工程に属するドキュメントの共通化を望む声がありました。上流工程を進めていく力が弱かったため，プロジェクトが大混乱に陥ることは少なくありません。
ユーザー/ベンダー間における各種ドキュメント（要件設計/基本設計）の規格化と仕様変更時の取り決めの規格化
見えないソフトを作る上での問題点の多くは上流工程に潜んでいます。しかし，1社だけの力で開発の上流工程における力を向上させるのは簡単ではありません。ご指摘のように，ドキュメントの共通化は，上流工程における誤解を減らして，失敗の確率を下げる可能性があります。
開発に関する標準作りに関するご意見はいくつもいただきましたが，記者の印象に残ったのは，あるベンダーの方からの以下のものです。
設計等の開発書類の標準化。超大手ベンダーは独自で標準を作成しているが普通大手以下のベンダーは標準がないのが実情だと思う。用意する設計図書も各SEでばらばらになっている。
このベンダーの方がご指摘のように超大手と呼ばれるようなベンダーは独自の開発標準を持っています。ですが実際には，こうした標準があってもシステム開発の失敗がなかなか減りません。実際の開発を進めるのが，こういった超大手ベンダーではなく，その下請け企業であることが多いからです。
こうした問題を自覚している超大手ベンダーは，最近では，下請け企業にこうした標準を習得するように進めています。開発標準が1社内の企業秘密であり，それがそのまま競争力を左右するのならともかく，実際は外部の企業にも内容を知らせているわけです。実現することはまずないのでしょうが，いっそのこと超大手ベンダーの持つ標準を全面公開して，日本のソフト産業全体の向上を狙うといった選択肢があってもよいのではないかと記者は考えます。
言葉や契約も標準化の対象に
ほかには開発の標準作りについて以下のようなご意見をいただいています。当然，上流工程だけでなく開発や運用についての標準化が有効ではないかとの声がありました。
開発，運用手法の標準化（ベストプラクテスの集約）で，ある程度の品質は確保できると考える。
・作業工程，用語の標準化・コストの可視化。ベンダーの常識は，ユーザ経営層には理解できないため，分かりやすい基準の作成と順守が無いと問題は無くならない
システム統合の際に，統合する企業同士が同じことを別の言葉で表していたり，同じ言葉で別のことを示しているために，プロジェクトの進行が妨げられることもあります。より大きな意味で，用語の標準化が進めばシステム開発の効率が高まることは間違いないでしょう。言葉に関連したご意見として，以下も併せて紹介します。
海外製品ならマニュアル，取扱説明書，リリース・ノートなどを直訳でも構わないのですべて日本語化すること。日本で販売される海外製品（車，家具，アクセサリ等）はほとんど取扱説明書が日本語化されているのに，IT関連機器やソフトは取扱説明書を英語のまま出荷するのはおかしいことと理解するべきです。ITベンダーは，IT関連で働く人はすべて「英語が堪能である」と考えてはいけないです。
横文字の多用についてのご批判はその通りだと思います。横文字を広めている立場の人間として胸に響くご意見です。
開発そのものではなく，その前提となる契約にモデルを確立すべきだというご意見もありました。
契約書や，納入基準を明確にする
新しい契約モデルの確立が必要と思います。日本では「請負」「派遣」の２種類しか存在しないが，例えば米国の政府調達などでは褒賞付契約等の複数の契約モデルが存在する。大規模高リスクのプロジェクトの場合は見積もりを超えてかかった費用もすべて支払うという契約など。私は「システム開発当初から要求仕様が定まっていることなんてありえない」し，いくら見積もり技術が上がってもこのリスクを100％回避できないと思います。現状では開発側にリスクが偏った契約がほとんどなのではないかと思いますので，まずユーザー側も開発側も相応にリスクを分け合える契約モデルを確立する必要があると思います。これによって，ユーザー側も丸投げでなく，真剣に開発に参画してくれる効果が出てくるのではないかと思うのですが。
業界全体で開発請負契約時の規約を作る。設計／開発／導入適用の3段階に分けて見積もり契約する。契約前に時間とコストを掛けて要件確認を行なえば問題発生の可能性は低減できると思うが，ユーザ企業側にしっかりした要件定義ができる人が存在しない場合には，コンサル利用しか無く，コスト的に難しい。
特に後段の二つの意見については，具体的な指摘があり示唆に富んだものだと思います。請負契約，派遣契約，あるいは準委任といわれる契約が，システム開発に最適なのか，あるいは現実に順守できる形態なのかという問題提起は重要だと思います。
