3月13日付の本欄で，増える「動かないコンピュータ」と題した記事を書いた。情報システムの構築プロジェクトを巡るトラブルが増えているという内容である。有り難いことに，かなりの方から反応があった。
旧知の方々から電話をもらったり，メールを送ってもらったので，こちらも直接返信した。さらに，IT Proのサイトにコメントを書き込んで下さった方もあった。こちらについても返信するのが筋である。そこで，お送りいただいた全コメントに返事を書こうと思い立った。
以下，いただいたコメントのうち，IT Proで公開してかまわないと指定され，実際に公開されたものについて，コメント本文（IT Prpのフォーマットに体裁を整えさせていただいたものもある）と筆者の返事を列挙する。さらに，公開の了解がないもので，重要と思えるコメントについてはその主旨をまとめ，返事を書いた。
15年間記者をやっているが，Webサイトに送られた全コメントに返事を書くのは初めてである。面白い読み物になるかどうかは分からないが，とにかくやってみることにする。「3月のコメントになぜ今ごろ返信するのか」と問われると答えに窮するので，その質問だけは勘弁していただきたい。
（谷島 宣之＝日経コンピュータ副編集長）“動かない”の意味がわからない
“動かない”の意味がわかりません。開発者は動作テストを行い納品するのが普通です。この過程をはしょった開発は開発とはいえません。また，発注元はそれなりの納品基準を設け，受入検査をするものでしょう。この検査をサボった場合，発注元とはいえません。“動かない”というのは発注者も受注者も存在しない架空の世界でのことでしょう。 納品後，動かなくなることはよくあります。これは不可能であり，別契約といえるでしょう
筆者は両方の意味で“動かない”を使っています。一つは，テストをして納品し，受入検査をして検収したにもかかわらず，トラブルが起きる場合。もう一つは，おっしゃるように架空の世界の出来事のようですが，テストをせず，受入検査もしなかった場合です。現在でも，こうした事例は存在しています。
一番の問題は，システム部門が現場にコミットしていないこと
「情報システム部門を外してプロジェクトを進める企業」。これは部門が縦割りで交わりがないから。何が必要で何をすれば良いかをわかる人が情報システム部門にいないから。で，部門ごとに「勝手に」始めてしまう。情報システム部門がエンド・ユーザーの業務にコミットしていないのが一番の問題だと思います。
公開の了承がなかった別の方のコメントにも，情報システム部門への厳しい批判が述べられ，「経営者が信用しないのはもっとも」と書かれていました。筆者は3月13日の記事で，「情報システム部門を外したプロジェクトに失敗が多い」，「情報システムの再構築は，その企業のことを相当にわかった人が参画しないとうまくいかない」と，「別々に」書きました。「すべての情報システム部門が自分の企業のことを相当わかっている」とまで筆者は断言できません。しかし，「自分の企業のことを相当わかっている情報システム部門は存在している」と思います。現在，情報システム部門への風当たりは非常に強いですが，各部門を横断的に見られる可能性がある部門として，頑張ってほしいと考えます。
記者は5～6年遅れている
この記事にはセキュリティの観点がない。この記者自身，5～6年遅れている。
ご指摘の通り，セキュリティについて触れていませんでした。実際，「誤算の検証」の企画を始めて見ると，情報漏洩のトラブルがかなり多いことが分かりました。5～6年遅れているとの指摘は，前回の記事で上げた論点に目新しいものがないという意味でしょうか。だとすれば，それは確信犯で書いています。情報システムのトラブルの原因の9割以上は，5～6年前，いやもっと前からある原因ばかりです。
大学の講義でも使用していた
コラム「動かないコンピュータ」は大学の講義で使用していました。現在，システム・インテグレータに勤めているので，あのコラムの事例を学ぶことは非常によい経験だった，と思っています。新コラム「誤算の検証」も，現場の人間こそが「あ痛！」と思えるような，突っ込んだ内容であれば，と期待しています。
誤算の検証も将来，講義に使っていただけるくらいの内容にすべく努力します。
状況を謙虚に受け止めよう
皆さんのコメントを読むと，数日前に掲載された「バグで悩まない・・・」のコメントと似ていることがわかります。今回のコメントで「原因はわかったとして，無い物ねだりをしてもしかたがない」というのがありました。まったく同感です。これから経営者になる人・システム開発の統括をする人・SEやプログラマを目指す人はそれぞれの立場でこの状況を謙虚に受け止め，自分にできることは何かをさぐるべきでしょう。（もちろん私も含めて）
おっしゃる通りです。筆者も，記者という立場でこの状況を受け止め，自分にできることは何かを考えて仕事をする所存です。その一つが誤算の検証ですが，これだけではありません。
データによる裏付けに期待する
データによる検証を是非期待しています。 「IT」という言葉に翻弄され，かつ「IT民度」（勝手な造語ですが）の低い経営者層とその経営者層に振り回されがちのシステム開発者，運用者とのギャップを少しでも埋められるような切り口の記事を期待しています。 個人的には，御社ECグランプリで企業向けEC部門賞を受賞された「ニ六製作所」のような優秀な事例とその他大勢の企業との差が，データで浮き彫りになり，経営者層への刺激になればよいなぁ，などと思います。
データによる検証は鋭意準備中です。勝手に宣言してしまうと，なんとか今年やりたいと思っています。
早速読ませていただきます
かつての連載記事「動かないコンピュータ」は，私の好きな記事で，たいへん勉強になったと思います。いつごろかから載らなくなり，（それだけが理由ではないのですが）日経コンピュータそのものもあまり読まなくなったので，これが復活しているとは知りませんでした。早速読ませて頂きます。
よろしくお願いします。今度は挫折しないようにします
「偽」システム屋が横行している
「システム屋」が増えたようで結局は水増し。企画だけでは売れない企画屋が，「IT」を組み込むことで，なんとなく「IT革命」に対応できるような気にさせててしまう。記事にあったように，確かにクライアントの問題もあるけれど，「モラルハザード」とも言われる「偽」システム屋の横行が大問題じゃないのかな。「万人のためのインターネット」は，なんだか「万人を何でもできるような気にさせてしまう」状態になっているように思う。
このコメントを読んで，自分の書いた記事を読み直してみると，確かにクライアント（ユーザー）側の問題ばかり列挙していました。ご指摘の通り，あやしいシステム屋の問題もあります。
「もうそっとしといてくれ」
『誤算の検証』。「もうそっとしといてくれ」と言いたくなる様なタイトルです ね。
すいません。
原因の分析や対策の提示に期待する
新コラム「誤算の検証」は非常に興味深いといえる。我々SIerとしては，注目すべきは誤算の原因であり，繰り返さないための対策である。 原因の傾向分析や対策案の提示に期待したい。
誤算の検証はなんとか10回を超えましたが，取材力不足のところがあり，原因不明のケースが数回ありました。「ちっとも検証していないではないか」という抗議の電話も頂戴しております。ご期待に沿うべく，なんとか努力します。
参画意識こそが失敗しないための第一歩
動かない原因としては目新しさに欠けると思う。物分りの良いTOP，何でもこなすIS部門，潤沢なコスト，優秀なSI・・・こんな無いものねだりが失敗の原因と判っても実際にはどうしようもない。複雑に絡まる失敗原因の一面を明日の糧には出来ないと感ずる。要はITを絡めたプロジェクトへそれだけの想いと責任を持てるかどうか，参画意識こそが失敗しないための第一歩ではないのか，と考える。
ご指摘の通り，こうしたことは筆者が記者になった15年前から何度も指摘されていました。現実には理想的なスタートを切れるプロジェクトはゼロに近いでしょうし，参画意識についてもおっしゃる通りと思います。ただ，同じような原因で失敗が続いている以上，しつこく報道したいと考えます。
『動かせないコンピュータ』もある
あれもこれも出来ますと言っておいて後から条件をつけられるのもかないません。これは，『動かせないコンピュータ』です。
「なんでもできる」という提案については疑ってかかるしかないようです。難しいですが。
“NoといえるSIベンダ”が少ない
経営層の目的がはっきりしないまま，パッケージの導入だけ先に決まっているような場合も多いと思う。トップの大号令がない限り，エンド・ユーザーは「使い勝手」のみを優先して延々と仕様変更を要求し，それに“No”といえるコンサル（SIベンダ）は少ない。顧客，業者ともにまだまだ大きな問題を抱えている。
「顧客のためにあえてNoという」ことは，インテグレータ業界にとって，緊急のひょっとして永遠の課題です。
経営者に苦言を呈したい
率直に言って「記者の眼」としては少々的外れのように思う。私の経験では，失敗する事例は必ずといっていいほど，目的があいまいであり，ひどい時には目的と手段が入れ換わっている。特に，最近のインターネット関連の失敗事例は，Webサーバーを立ち上げることが優先で，目的を達成するためのシステムであることが忘れ去られているように感じる。私は経営者ではないが，もっとシッカリと物事を見据える目が必要なのではないか，と経営者には苦言を呈したい。
おっしゃる通りです。筆者としては，「経営者が『とにかくITだ』と号令をかける」という文章で，手段であるITが目的になってしまう問題を指摘したつもりでした。
技術の進歩が速すぎる？
私は1959年から計算機のハード，ソフト，システムの開発に従事し，5年前からさる大学の非常勤講師を務めています。実務からは遠ざかって5年以上立ちますが，後輩達の話を聞いていると，私がたどった道と同じ道を歩いているようで吃驚（びっくり）します。システム開発の手法やツールが昔とは比較にならないほど進歩しているように思いますが，未だにトラブルの原因が依頼者側の要求と開発者側の思いがすれ違うのが主要な要因とは信じられませんね。それだけ技術の進歩が早すぎて，実体が追いつかないと言うことなのでしょうか。
筆者も15年前から，それほど変わっていないことに時々驚きます。人間がからむ以上，どんなに技術が進歩しても常に問題が起きる可能性があるのでしょう。
単に開発案件が増えただけ，という可能性は？
「動かないコンピュータ」が増えたのは，単に全体のシステム開発案件が増えたからという可能性はないですか？(「誤算の検証」は毎回楽しみにしてます)
もちろん，それもあると思います。開発案件数のデータもなんとか調べてみたいです。
業界を変えていく必要がある
最近，動かないシステムの話は，よく耳にします。記事になさっている内容はまさに仰るとおりで，踊らされている人々がいるのも事実です。経営者の素養の問題はもちろんですが，ベンダー側の責任もあると考えています。商売の決め手が，技術力よりも営業力，しかも営業力がコンサルができるといったものではなく，体育会系の営業で仕事をとっていくという形態が中小企業向けの市場にはあるようです。そうした企業では，売上高も上がり，さも実績があるように見えるようですが，その仕事内容には疑問を抱いています。中小企業ではベンダーの選別などできないので，営業力の差になるようですが，こうした業態にシェアを食われ続けることは，国民からの我々全体への失望に繋がりかねません。今の不景気の中でも，我々の業界に期待をして投資をしてくださる方々の期待に添えられるよう，我々の業界自身も変えていく必要があると考えています。
15年前，筆者が記者になった時は，オフコン・ブームなるものが，さめつつある時でした。オフコン・ディーラ（これは死語ですね）が力任せにオフコンを顧客に押し込んで，リースがかかったらアプリケーションが完成しようがしまいが顧客を訪問しない，という事例があちこちでありました。システム・プロバイダ業界の進化を期待します。
マスコミの責任も大きい
最近の「動かないコンピュータ」は，システム管理者がマスコミやベンダーに踊らされ，実現不可能な魔法の小箱を信じてしまうことに起因するのではないでしょうか。曰く「Javaでコンポーネント化すれば生産性が大幅に向上する」，曰く「APサーバーを導入すれば，短納期でWeb化できる」，曰く「ERPパッケージを導入すれば，開発は不要」。魔法の小箱なんて存在せず，やっぱりそれなりの設計，テスト工程と開発期間，システム構築に関わるノウハウが必要なことが，ちゃんと管理者に理解されていない。マスコミの責任もあると思います。御誌の新企画に期待します。
マスコミの責任は当事者として痛感します，本当に。したがって，基本的なことをしつこく報道しようと思っております。唐突ですが，設計，テスト工程と開発期間など，システム構築プロジェクトに関わる基本的なことは，学校で教えてはどうかと思います。ちゃんと説明すれば，小学生であっても分かるのではないでしょうか。
失敗にこそ学ぶべき点がある
「動かないコンピュータ」復活ですか。連載当時，大手鉄鋼メーカのシステム部門にいた私は，毎回楽しみにしていました。具体的な事例だけに，自分の業務に役立つ点がいくつもありました。やはり，失敗にこそ学ぶべき点がいくつもあると思います。今回の連載にも期待しています。
ありがとうございます。ご期待に沿うよう，特別取材班一同頑張ります。
失敗例を教訓に，よりよい提案を行いたい
誤算の検証・動かないコンピュータは今までは他山の石のように受け止めていた。特に，ベンダーの立場としては自社のユーザーでの記事が無いことを正直祈っていた。しかし，情報システム部門から経営企画部門に検討窓口が変わってきているなか，その落とし穴をよく学び同じ失敗をしないため，また，失敗例をそれを生かした提案を行うためにも参考にさせていただきたい。それは決して他人事ではないのだ。
確かに，同一企業でも，部署が変わると，まったく同じ失敗を繰り返すこということがあります。理想論をいえば，自社の歴史をひもといて，失敗プロジェクト（これはシステムに限らず）の検証をするといいと思うのですが。
実力以上の安請け合いはするな
昔は，ソフトウエアが比較的に柔軟に仕様をいじれるため，あちらこちらをいじってしまい，挙句の果てに，バグ多発，納期遅延というケースが「動かないコンピュータ」に多かったように思う。最近では，見かけのやすいオープン系製品を使った案件が多いが，安いが故に，安易に短納期，低価格受注を行ない，トラブルを起こすケースが多いように感じている。まあ，どのような反省が飛び出すか，「動かないコンピュータ」ファンには楽しみである。 やっている身からすれば，技術的にそんなに変わっていないのだから，実力以上の安請け合いなどできるわけがないと思うのだが。
筆者は，安定していれば，オープンでない製品でもかまわないと思っており，ダウンサインジング（これも死語）ブームのときは，「中堅企業にはオフコンで十分」などと主張して，あきれられました。
やっぱりタイトルは「動かないコンピュータ」がいい
新コラムは「誤算の検証」ですか。最近，日経コンピュータをあまり読んでないので申し訳ありませんが，個人的には「動かないコンピュータ」のタイトルで復活させて欲しかったですねぇ。以前，とても興味深く読ませていただいておりました。
実は編集部では激論があり，「新・動かないコンピュータ」という案も有力でした。しかし，一度止めた以上，名前は変えたいと考えました。「誤算の検証」にすると，ユーザー事例にとどまらず，ベンダーの誤算も書けるということもあります。
システムの“ディフェンダー”にもっと光を
「中途半端に情報化に積極的になった」経営者が，e-businessやらCRMやらのきらびやかなキーワードに躍らされている陰では，不正アクセス対策やパフォーマンスの維持，適切な運用によるシステムの信頼性向上，といった守りを担う方々が多くの汗を流しているはずです。ところが，こうした方々は，えてして「うまく動いて当たり前。失敗すれば責任をとらされる」という損な役回りを押し付けられがち。サッカーで言えばFW（フォワード）ばかりに光が当たり，DF（ディフェンダー）がまるっきり評価されない，という構図でしょうか（もちろん，すべてのプロジェクトがこうだと言うつもりはありませんが）。“動かないコンピュータ”が増える背景には，システムのディフェンダー達が（人事評価を含めて）正当な評価を受けていない，という構図があるような気がします。
システムのディフェンダーというと，ユーザー側では情報システム部門，ベンダー側では実際の開発と運用を担っている中堅・中小ソフト会社となるのでしょうか。この間の記事で書き忘れましたが，こうした中堅・中小ソフト会社のキーパーソンが最近，転職するようになり，そのとたん，その人が担当していた企業のシステムがガタガタになるケースが見られます。ちなみに彼らの転職先は，外資系ソフト・ベンダーやコンサルタント会社が多いです。話を戻すと，こうしたディフェンダーがどんなプレッシャのもと，どういう仕事をしているかは，意外なほど知られていません。日経コンピュータは誤算の検証ばかりではなく，プロジェクトのルポもやっており，こうした方々の奮闘を伝えようとしています。
開発を行う側にも問題はある
システム開発を行う側にも問題はあると感じる。必要な手順（工程・スケジュール管理など）を踏んでいない場合も多々見受けられる。またシステム構築の専門家として，受け身ではなく，ユーザーをリードしていく姿勢にも欠如している。
特にWeb系のシステムは手順を踏む暇もなく，開発に突撃することが多いそうです。このあいだ，あるベテランのプロジェクト・マネジャの講演を聞いたところ，「3カ月のWeb系プロジェクトであっても，その3カ月の間は，極論すればメインフレーム上の開発と同じように順をおって進めるべき」とおっしゃっていました。
「ほったらかしのWebサイト」が散見される
「経営とITの位置付け」は，重要な観点だと思います。企業のウェブ開設においても同様の事例が散見されているようです。動かないコンピュータならぬ「放ったらかしのウェブサイト」とでも言うのでしょうか。 経営とITの位置付けについての成功事例なりモデル事例の集中特集は有益だと思います。日本のIT戦略が掛け声倒れにならないために，是非宜しくお願い申し上げます。
頑張ります。そういえば，あるコンサルタントから，「Webサイトの開発・運用基準を作っている企業がない」という指摘を受けました。これは，ITの基準だけではなく，経営の基準も含めてのことです。Webサイト上で商品を売ろうとすると，各種の法律に準拠しているかどうかとか，その会社のビジネス・ルールにあっているかどうかまで確認すべきです。ところが，そうしたことをまとめた開発・運用基準がないという指摘です。つまり，Webサイトは，経営からも，情報システム部門からもずれた，治外法権を持つ存在になりかねません。
問題は要件定義があいまいなこと
「誤算の検証」，おもしろそうな記事ですね。 読んでみたいと思いました。あと，失敗するシステム開発案件に多いのは開発着手前の要件定義が曖昧でベンダーが作るシステムが顧客が思ったのと違う，とか作ってもらいながらその都度仕様を考えるというやつですね。私は要件定義が曖昧でベンダー/ユーザーとも気持ちよい取引のできた案件を見た事がありません。
どうしても何をやるかが曖昧なまま，突撃してしまうことがあります。またまた唐突ですが，情報システムを作るためのニーズの整理の仕方とか，データ・モデリングの基本を学校で教えたらいいと思います。特定メーカーのOSや表計算ソフトの操作方法を教えるより，はるかに有益でしょう。
これからも“動かない”事例は増える
システム化要求の増大，工数不足，経験不足，スピード化の要求等々，これからもどんどん動かない例は増えるでしょう。
残念ですが，増えざるをえません。
