外資系コンサルタントのつぶやき 第21回
国内の大手ITベンダのスキルは低い？
三宅信光
2003/9/19
| 国内のITベンダは技術スキルが高いという信仰 |
以前から私は、国内のITベンダはシステム構築に関する高いスキルを持っており、“物づくり”（つまりシステムの構築の実装部分など）に関してはコンサルタント会社は勝てないと思っていました。私が知っている自分の会社のメンバーは、少数の例外を除き物づくりのスキルが高いとはいえません。
もちろん、いろいろなことをよく知ってはいます。IT関連の知識でも、現在どのような技術がはやっていて、どんな最新技術があるのか、そういうことはほかの会社の人に負けないでしょう。でも、システムを構築し、運用するのに必要な知識とは、それとは違うものだと思っています。コンサルタント会社というのは企業の性格としても、どうしてもうわべだけの知識を追いがちなものです。一方ITベンダというのは、実際のシステム構築、運用の面で、実践的な知識、ノウハウをしっかりと持っている会社である、と信じていました。しかし、ここ数カ月でこの私の信念（？）ともいえる思いが覆されようとしているのです。
| 引き継いだシステム |
最初のきっかけは、日本で最大手の1つであるITベンダのA社が構築したシステムの運用を、私のチームが引き継いだことです。それほど大きなシステムではなく、私の会社が構築したシステムと関連が深かったので、運用の効率を考えて私の会社が併せて面倒を見ることになったのです。
難しいシステムではありませんし、A社が構築したということで、システム運用を引き継ぐことにあまり不安は感じていませんでした（それどころか安心していました）。A社から引き継ぐことですし、クライアントの手前みっともないことにならないようにと、私のチームの中で最も技術に詳しく、信頼できるメンバーを引き継ぎ担当としました。
一通りの引き継ぎを受け、私の会社のメンバーが運用を開始する際に、A社から未解決の障害があることを知らされました。1年以上前から発生しており、最後まで解消に努めてきたが解消できなかったこと、それによってクライアントの業務にある程度影響が出るので、臨時の対応方法はこうしてほしい、などなど。
A社でも解消できなかったことであれば、かなり面倒なことなのだろう、ちょっと嫌な話だなあ、と思いながら、一応私の会社のメンバーに再調査と対応方法を検討するように、指示を出しました。
1週間後、引き継いだシステムを担当するメンバーから、その障害が解消したと知らされました。驚いて、「どんな障害だったのか」と聞いてみると、RDBMS関連の障害で、確かにあまり一般的ではないが、それほど悩むような障害でもなかった、という回答でした。このときは、まだ「A社でも基本的なところでつまずくこともあるんだな」程度の認識でした。しかし……。
| システムのパフォーマンス |
A社から引き継いだシステムを運用していると、すぐにパフォーマンスに問題が生じました。そのシステムと連携しているシステムへ、データを渡すタイミングを守れなくなってきたのです。急にシステムが遅くなった理由は、ユーザーがそれまでよりも積極的にそのシステムを使い始めたためで、逆にいえばそれまではなぜかあまり利用していなかったらしいのです。もちろん、それ自体は別にA社の責任ではありません。
ただ、そのシステムは以前もパフォーマンスに問題が生じたことがあり、A社はその段階で「できる限りのチューニングはした」といっていたので、ハードウェアスペックの見積もりが甘かったのでは、という疑問がよぎりました。そうはいってもすぐハードウェアを交換するわけにはいかないので、無駄かもしれませんが、さらなるチューニングが可能かどうかを調べるように、担当者に指示を出しました。
正直、このときもA社がチューニングをできる限り行ったプログラムを、私の会社がさらにチューニングできるなんてまったく考えていませんでした。が、速くなったのです。それも、数十分かかっていた処理が1分以内に終わるようになったのです。私は驚いて、担当者に「どうやって速くしたの？」と聞くと、担当者は「いや、一般的なチューニングをしただけですよ」と答えたのです。
では、A社がいっていた「できる限りのチューニング」とは、何だったのでしょうか。ここで初めてA社を、というよりはそのシステムを構築したA社の担当者のスキルを疑い始めたのです。
| さらに出来の悪いシステムを引き継ぐ |
それでもこれだけだったら、たまたま今回のA社の担当者が悪かったのだろう、で終わっていたと思います。事実私はそう思っていました。しかし、偶然なのですが、それからすぐ、これまた国内では最大手の1社であるB社の構築したシステム（会計系のシステム）を引き継ぐことになったのです。そしてそのシステムの出来は、A社が構築したものを上回る（下回る？）ほど悪いものでした。A社が担当していたシステムは、少なくとも機能要件は満たしていました。しかし、B社が構築したシステムは、それすらも「？」が付くものだったのです。
最初、引き継ぐ前からそのシステムを実際に利用しているユーザーさんから、「あのシステムでは、同じ名前の項目でも、なぜか数字が違うようになっているので、そのあたりは気を付けて引き継いでほしい」といわれました。
あまり好ましい話ではありませんが、異なる帳票であれば同じ名前の項目で、定義が違う項目が出ることはあります。もちろん、システム的な項目名は別々に定義し、分かるようにしておくのが普通です。そのため、あまり気にも留めていなかったのです。
| でたらめな項目、合わない数字 |
しかし、本当にまったく同じ項目であるにもかかわらず、帳票の種類によって数字が異なるのです。例えば、そのシステムでは日々のデータを集計したテーブルと、詳細なデータを保持するテーブルがあります（まあ、普通ありますが）。日々のデータを集計したテーブルのレコードは日報などに使われるもので、その日集計されると、後で修正はされない仕様になっていました。それに対して詳細データは、後で修正が入る可能性があります。実際修正されていました。すると、日々の集計データから月単位で集計したものと、詳細なデータを月単位で集計したものとでは、当たり前のことですが結果が異なります。
ところが、月次の集計を出力する帳票は、この2種類のテーブルを無秩序に使って作成されていたのです。B社が構築したシステムにはそうした例がごろごろしていました。一番驚いたのは、同じ帳票内で関連のある2つの項目で、抽出ロジックが異なっていたケースです。簡単に例えると、普通売上金額を計算する場合は「単価×売上個数」で計算できます。しかし、このシステムでは、売上個数と売上金額を別々に集計していたうえで、売上個数の集計ロジックと、売上金額の集計ロジックが異なっていたのです。その結果、その帳票上ではどうやっても「売上金額＝単価×売上個数」にならないようになっていました。
帳票上の数字のつじつまが合わないことを、いままでユーザーにどのように説明していたのか理解に苦しんだものです（いまも苦しんでいます）。そんなつくりになっているものですから、システムを利用しているユーザーから「この帳票とこの帳票の数字が合わないのですが」といった問い合わせがしょっちゅうです。なぜ私たちが、と思いながら冷や汗をかきながら説明しているありさまです。
それも、「もともとの仕様なのです」という説明にもならない説明をするのですから、つらいものがあります。さらに、パフォーマンスも最悪でした。せいぜい2000レコード程度のデータを処理するのに、1つの処理で1時間くらいかかるのです。別に複雑なデータでもありませんし、大きなマスターテーブルを使用しているわけでもありません。しかも特定のプログラムだけではなく、そんなプログラムがいくつもあるのです。
確かに2世代くらい前の基幹サーバですが、それにしても遅い。一応念のためと思い、システムの中身（ソースやSQLなど）を見たら簡単にチューニングができることはすぐに分かりました。このシステムも引き継ぐ前にB社から「これ以上のチューニングは難しい。夜間の処理時間が限界に近づいているので、そろそろハードウェアの見直しが必要かもしれない」といわれていたのです。しかし、あっさりとチューニングでき、いまでは当初引き継いだときよりもはるかに短い時間で処理が終わるようになりました。
| 最後のダメ出し |
さらに、今度は私の会社がメインで開発を行っているプロジェクトでのお話です。これまた、国内では最大手といわれるC社と共同で開発を行っていました。しかし、このC社の担当がちょっとパッとしません。そのシステムでは、Oracleをデータベースとして採用しています。C社の担当者（それもチームリーダー以下、チームメンバー4、5人全員が！）は、Oracleの実行モードの基礎的な知識（といってよいかは、多少ためらわれますが）に欠けていたようなのです。
まあ、それはOracleを使ったことがなければ普通かもしれませんが、プログラムのパフォーマンスが出なかったときに、どこで聞いてきたのかいきなり「アナライズという処理をすれば速くなるそうではないですか。すぐに全テーブルをアナライズしましょう」と叫ばれたのにはうんざりしました。確かにそのプロジェクトでOracleはコストベースでの運用（まあそもそもいまのOracleのデフォルトですし）を想定していました。
そのことだけで、「そうか、そんなことも知らないような人が担当者なのか」と、がっかりしたのはちょっと考えすぎかもしれません。しかし、ちょうどいき詰まっていたときであり、C社のメンバーのスキルに期待しよう、そんな状況であっただけに、そのC社のメンバーの一言はこちらの気力を萎えさせるものでした。その後もC社のメンバーからの技術面な貢献はほとんどなく、プロジェクトメンバーからの信頼は地に落ちました。
ここまでくると、そのプロジェクトでOracleを使うことは分かっていたのですから、担当の中にせめて1人くらいOracleを知っている人を入れてほしかったと思います。それは、ぜいたくな望みだったのでしょうか。
コンサルタント会社が技術を軽視しがちであることは、以前にお話ししたと思います。しかし、ITベンダまでもがそうした傾向があるとは思いませんでした。あまりのことに、日本のIT産業の将来に不安を覚えてしまったほどです。もちろん、ITベンダの中には優秀な方がおられるのは知っています。私の同僚が一緒に仕事をした中には、とても優秀な方がいると聞いていますし、私自身何人か存じ上げています。しかし、会社全体としての総合的な実力はどうなのでしょうか。私が近ごろ見た例が、不幸な例外であることを切に望みたい気持ちです。
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
