魂の入った企業システムを創るために

開発の進め方に口を出すとうまくいかなかったとき自分たちの責任になりませんか？

それはそのとおりです。ただ、丸投げしてもそれは同じです。よく考えてみて下さい。納期が遅れてサービス投入が遅延したときの機会損失、システムに不具合が生じて損失が出たとき、開発ベンダーがその責任を取ってくれますか？ベンダーだって馬鹿じゃありません。契約書を見ればわかりますが、必要以上の責任を負わないような契約になっています。システム開発がうまくいかないことによって生じるビジネストラブルの責任はユーザー企業が負うことには変わりないのです。 欧米ではユーザー企業が、インフラ、PKGソフト、インテグレーション、保守・運用、これらを分解して切り出して発注しています。それぞれで、必要な範囲の責任をとってもらえばよいのです。丸投げすることによって、システム開発が失敗したときの責任回避ができるということ自体が幻想で、その幻想に高いコストを払ってきたわけです。

複数のベンダーに切り分けて発注するということですか？

開発規模が小さければ必ずしも切り分けは必要ありませんが、開発規模が大きいときには、管理できる単位に切り分けて発注した方がよいですね。全体を丸投げにするから価格が高くなりますし、さまざまなロックインを起こす要素が入ってくることになります。 システム全体の構築責任を分解する必要があります。今は、この切り分けは一次請けのベンダーが行っています。部分に切り分けて二次受けのベンダーに発注しています。システムの構築の実作業を行っているのは二次請けベンダーなのです。この部分を発注側ですればよいだけです。こうした二次請けベンダーさんには非常にスキルの高い要員を揃えているところが結構あります。開発を切り分けることの出来る力があれば、そうしたスキルの高い人達を使って短期間に非常に良いシステムを作ることができます。

開発の切り分けはユーザー企業にできるのでしょうか？

切り分けに必要なスキルというものは確かにあります。まず、できる二次請けの業者を選ぶ「目利き」ができる必要があります。さらに、全体を管理するプロジェクト管理スキルも必要です。これらはこれまでずっと丸投げをしてきたユーザー企業には、最初のうちは難しいかも知れません。ただ、これらのいずれについても手伝ってくれるパートナーがいます。こうしたパートナーに、ユーザー側のプロジェクト管理の支援や、ベンダーの選定支援をお願いすればよいのです。 こうしたパートナーは、作る側のパートナーではなく、作らせる側のパートナーです。開発ベンダーを選んだり、管理することを行うのは発注側の視点に立って行う必要があります。開発ベンダーはその道のプロですから、専門知識を盾にされるとユーザー企業にはなかなか踏み込めないものです。発注側に頼りになるプロがいることで、良い緊張感が生まれ報告の精度もあがりますし、リスクを察知する能力が格段に変わってきます。そのためのコストはかかりますが、それを上回るだけの全体コストの削減効果があります。 また、最初のうちはそうしたパートナーに頼っていても、繰り返す中でユーザー企業のスキルが上がってきます。スキル移管もそのパートナーのミッションに加えることで、自社のシステム構築スキルのレベルアップを着実に進めることが出来ます。

既存のベンダーからの抵抗はありませんか？

これまで特定のベンダーに一括して仕事をお願いしているのだとすると、そこからの抵抗は当然あるでしょうね。そうでない場合でも、新しい開発の進め方やユーザー企業で決めたツールでやると品質が保証できないと行ったことを言ってくる開発ベンダーはいます。そういうところは、やはり長期的にはつきあい方を見直した方がよいのではないでしょうか。 家を建てる話でいえば、施主支給というものに相当します。トイレやキャビネットなど施主がこれを使ってくれといって渡せば、それを組み入れて家を建ててくれます。全て自前のものでないと家ができなかったときの責任は持てないという業者はいません。ユーザー側に合わせるのがプロというものです。 そもそもITの進歩は早いので、いつまでもひとつのツールやひとつの開発プロセスで仕事をするのが通用しているはずがありません。また、実際に開発の実作業を担っているのは、二次請け、三次請けの開発ベンダーの技術者です。彼らは、さまざまな一次請けのツールや開発プロセスに合わせて仕事をしていますから実質的に何も困りません。当然、自社のツールと開発プロセスでないと品質を保証できないといったことは言いません。困るのはロックインできなくなる一次請けベンダーだけです。

開発に使うツールや進め方をRFPに明記した上で、それを守ってくれる企業に発注しましょう。ときどき、提案書では従うと書いていたのに受注した後から、いろいろ難癖をつけてやはり自社のもののほうがよいと言い出すベンダーもいるので要注意です。ここは毅然とした態度が必要です。ユーザー主導型の開発について、理解してそれを尊重してくれる開発ベンダーを探しましょう。

自社の情シス部門から新しい仕事が増えると言うことで抵抗はないでしょうか？

これまでに慣れ親しんだやり方を変えるときには抵抗はあるものです。ユーザー主導開発を行う上で一番大切なことは、トップの強い意志を態度で示すことです。経営トップ以下の関係者全員が、システムを作るのは自分たちだという意識をしっかり持つことが何より大切です。それがなければ、どんなベンダーを選定してもユーザー主導開発はできません。 具体的には情シス部門の意識を高めることと、それに加えて必要な人材の投入も検討して下さい。開発会社と一緒にプロジェクトマネジメントを行うにはそれに見合うだけの社内調整力をもった人材が必要です。情シス部門を他の部門での活躍が期待できない管理職を任せているようでは、口先でいくら情シスの意識改革と言ったところで本気にしてもらえません。新しいフレッシュな人材を投入する、あるいは、外部から助っ人を入れてもいい。自分たちのシステムは自分たちで作るという気概を持てるようにするのが大切です。

そして大きな所ではなく、小さな所から少しずつ主体性を持って活動をすることです。大きな基幹システム全体を丸ごと対象にするのではなく、小さなところから少しずつはじめて経験を積んでいくようにします。 丸投げの場合は、システム開発に関わる様々な知識はすべてベンダーの方に残り、情報システム部門には何も残りません。要件定義ひとつとっても、システムを更新するために毎回、同じヒアリングが繰り返されます。情シス部門が主導することによって、システム開発に必要な知識やノウハウが情シス部門の方に残っていきます。 現在、開発プロジェクトの凍結で情シス部門の仕事が少なくなっている今がチャンスです。自社のための要員をスキルアップして新しい開発方法に取り組めるチャレンジを是非検討して下さい。ユーザー主導開発とは、これまで丸投げによってベンダーに流していた見えないコストを、自社の社員に投資することなのです。

最後にこれからのIT業界がどう変わっていくかについて、考えをお聞かせ下さい。

世の中は大きく変わっています。経済環境もそうですが、米国では「Change」の声と共に政権が交代し、この日本でも政権交代が起きました。IT の世界でもGoogleの台頭などによって、Microsoftの牙城だった領域が崩れつつあることはご存じの通りです。日本のシステム開発において、これまで中心的な役割を果たしていた大手開発会社がこの先も中心であり続けるはずがありません。システム開発の世界もそろそろ政権交代の時期なのです。 変化の激しいIT業界ですが、ユーザー企業の方はぜひ小さな変化ではなく大きな流れを意識して下さい。どんな機能であれ、汎用で誰でも必要としている機能はどんどん安くなり、組み合わせや設定によって簡単に使える方向へと進化しています。パッケージ化もそうですが、SaaSやクラウドという新しいトレンドも同じ流れにあります。

会計や人事など、込み入ってはいてもどの会社にも共通にある業務はどんどん汎用品で間に合うようになってきまました。これからも共通の業務部分の汎用化は進み組み合わせて作れるようになるので、一括で受けてどかんと作らなければならない開発はこれから少なくなっていくでしょう。人海戦術で作らなければならない巨大なシステムは、世界で最も安いグローバルなリソースを使って作られるようになるはずです。これがオフショア開発の先にある方向性です。 これからユーザー企業のトップが今後意識しなければならないのは、こうした汎用でも巨大でもないシステムです。つまり、競合との差別化に必要な、自社に固有のビジネスに合わせて作られる小粒のシステムです。こうしたシステムをどう作っていくかがこれからのIT戦略の要になります。最も進歩の早い金融分野のITでは、各企業のキラーシステムはほんの数名の優秀な技術者によって作られています。次々に登場する新規技術をいち早く投入して市場ニーズをリードするシステムを素早く開発しているのです。もちろん、こうした開発には発注側が主体に入り当事者として開発を進めています。 企業の魂の入ったシステムを作るための開発方法、それが「ユーザー主導開発（ULSD）」なのです。