日経コンピュータの谷島です。またしても「動かないコンピュータ」をテーマに「記者の眼」を書かせていただく。動かないコンピュータとは,「当初計画通りに動かないシステム」のこと,つまりシステムがらみのトラブルを指す。このテーマで書くのは,前々回(3月13日)前回(5月8日)に続き,3度目である。

 ありがたいことに過去2回はいずれも読者の方々から反響がたくさんあったし,IT Pro編集部からも「また動かないネタで書いてくれ」と言われたので,堂々と同じ話題を書くことにする。

 最初にお断りしておくが,今回は非常に長い。おそらく過去の記者の眼で最長であろう。IT Pro編集部の意向もあって,2回に分けて掲載する。それでも,1回分は結構な分量になった。多忙の方は夜にでも,ゆっくり読んでいただければと思う(家で読みたくない話題かもしれないが)。

 次に唐突だが,前回(5月8日)記事について意見を書き込んで下さった読者の方々に厚くお礼を申し上げる。記者になって16年,あれほど誉められたのは初めてだった。筆者は今でも深夜,前回の書き込みを時々ながめる。

 41歳本厄ど真ん中であるせいか,徹夜で原稿と格闘しているとさすがに気弱になる時がある。そうなったら皆様の書き込みを見る。絶賛である。「敬意を表します」とまで書いて下さっている人がいる。寝ている場合ではない,と気を取り直し,仕事に戻る。馬鹿もおだてればなんとか,というのは本当だと思う。

 前回あれほどの評価を受けた理由は,なんといっても前々回の書き込みに対して,すべて返事を書いたことに尽きるだろう。インターネットは双方向と言われつつ,書きっぱなし・言いっぱなしが多く,一回ああいうことをやってみたいと思っていた。

 反省もある。下記のような意見があった。



[2001/05/08]
(前略)この記事は何を訴えたいのでしょうか?キャンペーンとしての内輪話なのか、読者に何か提案されているのか、従来の一方通行記載の改善案なのか判然としません。報道していただき、考察を加えられた内容に対する議論の場を提案されているのなら歓迎しますが・・・

谷島確かに前回の記事だけを見られた方がこう思うのは無理もない。思いつきでやっただけであるので深い意味はなかったのだが,「議論の場」というのは重要である。IT Proのロゴにも「Workplace」と書いてある。実際,「場」を求める意見はかなりあった。



[2001/05/08]
この記事自体は、読者と記者の両方で得る物が大きい。できれば、定期的に載せて欲しいものである。(中略)「システムが動かない原因はこれだ」などと特定はできる訳がないが、多くのケース・考え方を公開することで、少しでも現状が改善されることを望む。

[2001/05/11]
記者の方と双方向で、問題意識を共有し掘りさげていく、こんな企画はとても面白いですね!! (後略)

[2001/05/08]
面白い読み物になったと思います。掲示板等での議論にはない、静的ではあるが無駄のない内容で、すらすらと読みました。(中略)話題を絞りコメントを求め今後このような記事を書いていただきたい。

[2001/05/08]
(前略)「記者の目」BBS を立ち上げると面白いのにとは思いますが、あれるのがわかっているのでむずかしいですね。

谷島読者の要望にこたえ,増える「動かないコンピュータ」の目的を下記のように勝手に定義したい。

●記者と読者が相互に意見を出し合い,「動かないコンピュータ」問題について議論を深める。
●やり方としては,記事の中でいくつかテーマを上げ,皆様から意見を書き込んでいただき,再度それらを記事にしていく。

 掲示板は掲示板で面白いが,ご指摘の通り,一歩間違えると公衆便所の落書きとなってしまう危険があるので,ここでは「静的な議論」を重ねることにしたい(必ずしも落書きが悪いといっているわけではない)。

 こういう内容にすると,もはや「記者の眼」ではなくなってしまうという大きな問題に今,気付いたが,それは無視する。情報化の現場で奮闘されているプロフェッショナルの方々は,本欄に登場されるにあたって,「記者(書き手)」となっていただければと思う。

原因を探り,対策を考える

 ここまではさっと書けたが,実際に問題を提起しようとなると,とたんに筆がにぶった。困ったときは読者の書き込みに戻るに限る。再読した結果,意見は次の3点に集約できると考える。

●動かないコンピュータ発生の原因
●動かないコンピュータを避けるための現場の知恵や工夫
●動かないコンピュータを根本的に減らすために国全体で底上げすべき点

 今回の記事は3点について,これまで寄せられた交通整理をするにとどめたい。いきなり具体的なテーマを出して,「みなさん,これについて書いて下さい」と言って,書き込みが減っても困ると考えた。膨大な文を読んで思ったことを今まで通り,書いていただければと思う。

 動かないコンピュータの原因は一見,さまざまである。だが,煎じ詰めれば,ユーザー(発注者)とベンダー(開発者)のあいだで,「要件をちゃんと伝えられない」ことにつきるだろう。本質的には,技術の問題ではない。



[2001/05/23]
今まで超大企業から中小企業に至るまで数百社のシステム、システム部門、プロジェクトを見てきた。「動かないコンピュータ」の根本は人の問題だ。システムを作る人、頼む人、使う人のいずれかに、「相手の役に立ちたい」「相手に理解させようと努力する」「相手の立場にたって考える、また一緒に考える」といったハートがなければ駄目だろう。

[2001/05/08]
私も15年ほど前に社内の在庫管理システムの設計に携わりましたが、1年の運用で廃棄した経験があります。(中略)コメントを読ませていただいて、時間が経過した今でも、同じ問題が存在することに驚くとともに、人間が設計する以上、”動かないコンピュータ”はなくならないと実感した次第です。

谷島悲しい話として,「そもそもユーザーに要件がない(目的が曖昧)」という指摘もあった。



[2001/03/13]
経営層の目的がはっきりしないまま、パッケージの導入だけ先に決まっているような場合も多いと思う。トップの大号令がない限り、エンドユーザは「使い勝手」のみを優先して延々と仕様変更を要求し、それにNoといえるコンサル(SIベンダ)は少ない。顧客、業者ともにまだまだ大きな問題を抱えている。

[2001/03/13]
(前略)私の経験では、失敗する事例は必ずといっていいほど、目的があいまいであり、ひどい時には目的と手段が入れ換わっている。特に、最近のインターネット関連の失敗事例は、Webサーバーを立ち上げることが優先で、目的を達成するためのシステムであることが忘れ去られているように感じる。(中略)もっとしっかりと物事を見据える目が必要なのではないか、と経営者には苦言を呈したい。

谷島目的が曖昧なユーザーを正しい方向に向けることこそ,プロの役目であるとする意見もあった。



[2001/05/08]
(前略)私は、この問題の主要な責任は、売る側(作る側)にあると考えています。企業倫理の問題だと思います。(中略)できないとわかっていても、わかっていなくても,作ると言って完成しない責任は、売る(作る)側に決まっています。自己責任は、情報が共有されているときのみに生じるものです。明らかに、システム自体の完成見通しの情報は、作る側が持っています。

[2001/03/13]
「システム屋」が増えたようで結局は水増し。企画だけでは売れない企画屋が、「IT」を組み込むことで、なんとなく「IT革命」に対応できるような気にさせててしまう。 (中略)「偽」システム屋の横行が大問題じゃないのかな。「万人のためのインターネット」は、なんだか「万人を何でもできるような気にさせてしまう」状態になっているように思う。

[2001/03/13]
(前略)踊らされている人々がいるのも事実です。経営者の素養の問題はもちろんですが、ベンダー側の責任もあると考えています。(中略)体育会系の営業で仕事をとっていくという形態が中小企業向けの市場にはあるようです。(中略)こうした業態にシェアを食われ続けることは、国民からの我々全体への失望に繋がりかねません。今の不景気の中でも、我々の業界に期待をして投資をしてくださる方々の期待に添えられるよう、我々の業界自身も変えていく必要があると考えています。

谷島先の方の書き込みにあった,「Noといえるコンサル(SIベンダ)」は,動かないコンピュータ問題についての重要なキーワードと言える。「Noといえるプロフェッショナル」というテーマで一度,議論してみるのもよいかもしれない。



[2001/05/08]
(前略)ベンダー側の人間として、昨今のお客様の要件は、「漠然としたシステムを既に決まったスケジュールで構築したい」というものが多くなったと思います。一方、ベンダー側も、シェア獲得目標と価格競争の中で無理がある事を承知で受けることも多くなりました。(中略)本当にシステムのことを考え"No"と言えば「さよなら」と言われるのが現状だと思われます。これでは互いに力を出し合っていいシステムを構築することはできないでしょう。流行に惑わされず、流行を上手く取り込んでいく方法を互いに考えられる場が欲しいと思います。

谷島ユーザーとベンダーの関係の基本がぐらついているところに,相次いで登場する新技術の問題がからみ,問題がさらに深刻になっていく。



トラブルをなくす現場の知恵
[2001/05/09]
(前略)当時はOSやネットワークについてそれほど知らなくても、COBOLさえ知っていれば良かったわけですし、ちょっとSQL文を変えるだけで、パフォーマンスが100倍・1000倍に変わることも無かったのですから。体感的には、オープン系は、COBOL時代の3倍の負荷が、システム担当者にかかるようにさえ感じます。

谷島動かないコンピュータはコンピュータの誕生以来の鬼子であり,その対策は実はほぼ出て尽くしている。非常に基本的なことを徹底できるかどうかである。だが,それが難しい。



[2001/05/23]
(前略)ものごとには定石というか理想系がある。システム構築だと,「要求まとめでは、経営者の意図や、現場ニーズを適切に吸い上げるキーパーソンをアサインする」,「技術的には、実績のあるものをできるだけ使い、実績無いものは早めにテストする、また出来るだけ部品化する」,「管理的には、プロジェクト初期段階できちんと準備する、シュミレーションする」,「見積もりは軽視しない」,「能力的に不可能なものを安請け合いしない」など、きちんとあげていけば1000項目くらいにはなるだろう。理想系をきちんと理解し、実際のプロジェクトで、どこにギャップ(理想系とのずれ)があるか、わきまえて当たることが重要だ。

谷島筆者は11年前,日経コンピュータ1990年10月8日号の「動かないコンピュータ特集」で「動かないコンピュータ撲滅のための10カ条」というものを作った。その後も,同じ10カ条をたびたび記事で引用した。10カ条とは次のようなものである。

●自社のシステム構築に関する力を見極め,無理のない計画を立てる
●複数のインテグレータを比較し,最も自社の業務に精通している業者を選ぶ
●経営トップが先頭に立って,システム導入の指揮をとり,全社の理解を得ながら社員をプロジェクトに巻き込む
●要件定義や設計など上流工程に時間をかけ,要件が確定後はみだりに変更しない
●開発の進み具合を自社で把握できる力を身に付ける
●検収とテストに時間をかけ,安易に検収しない
●インテグレータとやりとりする社内の責任者を明確に決める
●システムが稼働するまであきらめず,あらゆる手段を講じる
●インテグレータと有償のアフター・サービス契約を結び,保守体制を整える
●インテグレータを下請け扱いしたり,開発費をむやみに値切ったりしない

 1996年9月16日号の「動かないコンピュータ特集」で10カ条を再録した際,「付け加えるとすれば,最新技術にむやみに飛びつくな,という項目だろう」と記した。これまた現在でも通用する注意点である。

 ただし,現場の知恵だけでは限界もある。我が国全体の「情報化力」とでもいうべきものの底上げが欠かせない。現場の知恵は悪くすると,原因の裏返しに過ぎない面がある。先の10カ条の文を否定形に直せば,動かないコンピュータの原因10個になってしまう。

 原因として「要件定義が曖昧」があり,対策として,「要件定義を時間と金をかけてちゃんとやろう。それには・・・」となる。だが,要件定義の重要性と難しさを理解していないユーザーに,「金をかけろ」と言っても無い物ねだりに終わりかねない。



動かないコンピュータの抜本的対策
[2001/03/14]
(前略)コメントで「原因はわかったとして、無い物ねだりをしてもしかたがない」というのがありました。まったく同感です。これから経営者になる人・システム開発の統括をする人・SEやプログラマを目指す人はそれぞれの立場でこの状況を謙虚に受け止め、自分にできることは何かをさぐるべきでしょう。(もちろん私も含めて)

[2001/03/13]
(前略)物分りの良いTOP、何でもこなすIS部門、潤沢なコスト、優秀なSI…こんな無いものねだりが失敗の原因と判っても実際にはどうしようもない。複雑に絡まる失敗原因の一面を明日の糧には出来ないと感ずる。要はITを絡めたプロジェクトへそれだけの想いと責任を持てるかどうか、参画意識こそが失敗しないための第一歩ではないのか、と考える。

谷島おっしゃる通りであり,記者は原稿を書くことしかできないので,黙々と書くわけである。そして,究極の無い物ねだりとして,全体の底上げになる方策を空想することも重要と考える。今回は二つの指摘をしてみたい。

 まず,ユーザー側については,情報システムの構築とはなにかについて,常識をもってもらえるようになんとかすべきである。これは教育の範疇だろう。前回の返事のなかでこう書いた。「設計,テスト工程で何をするのかとかシステム構築プロジェクトに関わる基本的なことは,学校で教えてはどうかと思います。ちゃんと説明すれば,小学生であっても分かるのではないでしょうか」。これについて,賛同者を得られたので,意を強くした。



[2001/05/08]
『システム構築…は,学校で教えてはどうか』という発想、まったくその通りだと考えます。

[2001/05/08]
私は情報系の専門学校にいましたが、本当に現場で使うのかと思うような高等技術ばかりを教えており、プロジェクトに関わる事は殆ど教えていない状況でした。ここで、プロジェクト開発の一連作業を経験させておけば、もっと現場に入った時に理解しやすく、作業も進むのではないかと考えています。(後略)

谷島2番目の方は,ベンダーになられる方の教育をさしているが,筆者はさらに,ユーザーになる人,つまりすべての社会人にプロジェクトの基礎を教えたらよいと思う。「要件定義とはどう作業で,稼働直前になって要件を変更すると,いかなるインパクトがプロジェクトに出るか」といったことを学生の時から教えておくのである。



[2001/05/08]
(前略)「出来ること」と「出来ないこと」が不明瞭なまま爆発的に普及し結局、「出来ないこと」に阻まれ「動かないコンピュータ」が誕生しているように思われます。そして「出来ないこと」の説明、解説や「出来ること」の条件付けがなされないまま済し崩しになっているような気がします。

谷島できることとできないことを教えるのが教育である。ここで教育といっているときの対象は,社会人や大学生だけではない。まじめな話,小学生から教えてはどうか。筆者の取材先には,「小学生にプロジェクトマネジメントを教えるためのCD-ROM」を作った人や,「息子にデータモデリングを教える。必ずマスターできるはず」というコンサルタントがいる。今度,その成果を聞いてみたい。

 次にベンダー側の課題として,IT産業の社会的地位をもっと高める努力が必要になる。そうしないと若い人が入ってこないし,現場のやる気は下がる一方である。顧客の要望や問題を整理し,解決策を考え,必要なシステムを作り運用し,顧客の改革を支援する,という仕事のやりがいと重要性をもっともっと認知させなければならない。



[2001/03/13]
(前略)不正アクセス対策やパフォーマンスの維持,適切な運用によるシステムの信頼性向上,といった守りを担う方々が多くの汗を流しているはずです。ところが,こうした方々は,えてして「うまく動いて当たり前。失敗すれば責任をとらされる」という損な役回りを押し付けられがち。(中略)“動かないコンピュータ”が増える背景には,システムのディフェンダー達が(人事評価を含めて)正当な評価を受けていない,という構図があるような気がします。

[2001/05/08]
(前略)背景には、おまけ意識(ハードが安くなった分ソフトも安くなるでしょう)と,3K(きつい、帰宅できない、気が休まない)の仲間入りをしてしまった事が有ると思います。優秀な人材で長期に渡りデートする時間が持てなくてソフト業界をやめたという,嘘とも冗談ともとれる理由で辞めた若者がいました。人材が育たず、経験者は辞めてしまう、自己啓発をする余裕が無くでは、IT立国としてやっていけるのでしょうか。

[2001/05/08]
(前略)このままでは、IT業界は、駄目になってしまうのではないかと思います。 IT業界を包括した、情報処理技術の格付けが必要なのではないでしょうか?システム技術者の個々の技量の明確な物差しが無いこと、また、情報システム構築プロジェクトにおける発注側の責任範囲の明確化(法制化)が皆無であることが、問題であると思います。

谷島 宣之=日経コンピュータ副編集長)

(以下,明日に続く)