 |
「マイクロソフト社の製品は嫌いだから私は必ずJavaで開発する」と言う人を見かけることがある。逆に「開発するなら絶対に.NETだ」という人もいる。なぜ彼らは同じ製品を使い続けたいと思うのだろうか。
その理由が，個人の好き嫌いに由来しているとしたら問題だ。その好き嫌いが根拠のあるものならまだしも「何となく好き，何となく嫌い」といった漠然とした先入観によるものだとしたら，それはユーザーに対する背信行為となる。
マイクロソフト社の製品は何が何でも使わないという人々の中には，マイクロソフト社の販売戦略や，ただ単に巨大企業である，といった本来検討すべき製品とは全く関係のないところで毛嫌いしている人がいる。そのような人々に「具体的にどんな販売戦略で，そのどこが嫌いなのか？」と言った質問や「なぜ巨大企業だと嫌いなのか？トヨタやソニーも嫌いなのか？」といった質問を投げかけてみたことがあるが，明確な答えを返せる人は少ない。嫌いと言っている製品について，比較対象製品も含めた公正な検討を行い，その上で評価・判断を行っているわけではないのだ。それは重大な結果を招く。
同じ製品を選び続けると後で苦労する
筆者も同じ製品を使い続けたことによって大きな失敗をしたことがある。以前，筆者が某ユーザー企業の社内情報システム部門にいたころの話である。
90年代後半，システム開発はクライアント・サーバー（C/S）システムが全盛の時代から，Webを利用したシステム開発に移りつつあった。そのころの筆者は，システム開発を行う場合には常にクライアントはVisual Basic（VB），サーバーは○○○，データベースは□□□，と言った具合に決めつけ，VBによるC/Sシステムでのみ開発を行っていた。
あるとき筆者のもとに，日本全国に点在している複数の拠点で利用するシステム開発の話が舞い込んだ。そのシステムは，全国に点在する拠点から，本社で管理しているデータを参照するシステムであり，更新系は専ら本社で行い，各拠点からは参照を行うというのが主な機能であった。このシステム開発の話を受けて，すぐにVBによるC/Sシステム開発の設計に取りかかった。
Webによるシステム開発という選択肢もあった。しかし，筆者は全く検討しなかった。一部の技術者からは，今回の案件はVBを使ってC/Sシステムを構築するのではなくWebベースで開発すべきだとの声が届いていた。しかし，当時の筆者はただ“VBが好きだ”という理由からVBを選択した。
その後，システムは順調に完成し，無事稼働した。しかし，結果としてこのシステム開発は失敗だった。なぜなら，システム投資金額はWebベースによるシステム開発に比べ非常に大きなものとなり，稼働後の運用費用まで含めると数倍の規模となってしまったからだ。
C/Sシステムには，C/S間でのプログラム・DLL不一致や，煩雑な配信サーバーの管理，各拠点パソコンの資源（メモリー，HDD，OSバージョンなど）管理といった，C/Sシステムならではの問題がある。それらすべての問題が吹き出てしまったのだ。
プロジェクト・マネージャは技術者である
それぞれの製品/技術には，必ず得手不得手がある。プロジェクト・マネージャ（PM）は，受託したシステム開発に関して，どんな製品/技術を使えばユーザーの要望を具現化できるかということを，案件ごとに考えなければならない。
PMは，説明責任を果たさなければならない。説明責任を果たすために，PMは技術を理解していなければならない。筆者の例で言えば「なぜVBを使いたいのか？」「なぜWebによる開発ではダメなのか？」を論理的かつ技術的に説明できなければならなかった。それができてこそ真のPMと言える。自分の好き嫌いといった理由により常に同じ製品を使っていたのでは，そのシステム開発本来の目的を見失う。そういった例は意外に多い（表）。
| 好き嫌いのポイント | 結果 |
| 数百人が参照するシステムで，VBを使ったC/Sシステムを選択した（VBが好き！） | C/S間のバージョン管理，クライアントPCの資源管理といったC/Sシステム開発特有の問題が目立ちコストが増大した |
| モバイル系システム開発で，リアルタイム・オンライン照会が不要であるにもかかわらず，Javaによるオンライン型システム開発を行った（Javaが好き，マクロソフトが嫌い！） | リアルタイム・オンライン照会を実現するための通信インフラ整備を行い，膨大なコスト増となった |
| 1日数件程度のFAX送信を行うシステム開発で，サーバをWindowsからLinuxに変更し，Javaによるシステム開発を行った（Windowsが嫌い，パッケージを使いたくない！） | ミドルウエアの開発からすべて自社で行ったためコスト増大となった |
| 自社のノウハウが集積されている業務のシステム化に，使い慣れたSFAパッケージを選択した（とにかくパッケージを使いたい！） | 業務パッケージのカスタマイズが膨大となり，コストが予算金額の数倍となった |
| 基幹系業務の再構築で，すべてをホスト系からオープン系に変更した（ホストは嫌い！オープンが一番！） | 業務のすべてをオンライン化できなかった。大量データをバッチ処理するためのオープン環境構築に，想定以上の莫大なコストが必要となった |
システム開発はプロジェクトであり，未知への挑戦である。反面，結果がすべてという厳しい世界でもある。だからと言って，厳しいという理由だけでいつも同じ製品を使っていたのでは「ユーザーに必要とされるシステムを作る」という本来の目的を見失ってしまう。
新しいことに挑戦するのは勇気が必要である。ましてやシステム開発のPMともなれば，その製品選択には大きな責任とプレッシャーがつきまとう。どうしても，これまで使い慣れた製品を使いたくなり，それを使うために競合するほかの製品を評価せずに「何となく嫌い」になる，いわゆる「食わず嫌い」になるのは，分からないわけではない。
しかし，PMである以上，論理的な根拠も無く「食わず嫌い」になるのではなく，初めての製品であっても，チャレンジする姿勢が重要なのである。そのためには，まずは「口にくわえる」（製品を調べる），そして「咀嚼（そしゃく）する」（その製品技術を理解する・自分ものとする）ことが重要なのだ。そして，咀嚼した結果として「飲み込む」，すなわちどの製品が最もそのシステム開発にマッチするかを自分の頭で判断することが大事なのだ。
「嫌いだから詳しくない」というのは簡単である。しかし，PMならば「詳しいけれども○○○の部分が嫌いだから使わない」と言うべきである。日進月歩するIT業界では常に新しい技術に出会う機会は多い。PMたるもの，そういう場合であっても「食わず嫌い」せずに，まずは「口にくわえてみる」習慣を付けたい。
|
