ウルシステムズは、企業の情報システム部門を強くする様々な取り組みを行っています。世界経済の急激な変化に対応し、攻めのIT投資で成長を実現する方法として提唱しているのが、「ユーザー主導開発（ULSD）」です。「ユーザー主導開発（ULSD）」は、ユーザー企業自らがさらなるスキルを身に付け積極的に関与することで、無駄のない適正なコストでのシステム開発と人材育成が可能となる新しい考え方です。「ユーザー主導開発（ULSD）」とは何か、その効果と今後の展望等について代表取締役社長 漆原茂に聞きました。
- 第1回 見えないコストの発生をなくす、「ユーザー主導開発（ULSD）」とは
- 第2回 「ユーザー主導開発」の効果と 取り組み方
- 第3回 魂の入った企業システムを創るために
現在の経済環境下で企業のIT投資のあり方はどうお考えですか？
戦略上重要なITに対して、発注額を抑えて投資していくために新しい工夫が必要だと考えています。
現状は、リーマンショックにはじまる世界経済の急激な変化に対応するために、多くの企業でIT投資を緊急避難的に絞った状態です。状況が落ち着いてきたところでは、どうしても必要なところから投資が復活してきています。しかし、この苦境を乗り越えて成長を実現するには、攻めの投資のほうも復活させなければ なりません。
その際には、当然のことですが発注額を抑えた投資がこれまで以上に求められます。これまで発注額を抑える方法としては、開発に関わる業務をアウトソースし て、発注先に対してコストダウンを要求するというものが主だったのですが、これはそろそろ限界です。このやり方でコストを下げさせた結果、できあがってく るシステムの品質が下がるという弊害が現れてきています。新しい方法が必要です。
ここで発想の転換として、自分たちが積極的に動くことによって、これまで見えていなかったコストを下げていくことが考えられます。システム開発の場合、コ ストを削減をするのは発注「先」の仕事と思いがちですが、そんなことはありません。ユーザー企業自身がスキルやノウハウを持つことで、「見えないコスト」 の発生をなくし全体的なコストを下げることが可能になります。
「見えないコスト」とはどういうコストなのでしょうか？
システムを発注したときにかかる費用とは別に、開発過程での無駄などによって追加でかかってくるコストのことです。
「見えないコスト」はいろいろな形で発生します。予算の都合で最初の開発で実現しきれなかった機能は、追加開発という形で行います。ここで最初の開発を請け負ったベンダーは、システムの設計情報を握っているので他社よりも圧倒的に有利になります。特に、ベンダー固有のハードウェアやミドルウェアを使っているような場合はなおさらです。こうした追加開発は、固有の知識が必要になるので通常の開発に比べて非常に割高なものになります。いわゆるベンダーロックインと言われるものです。
ベンダーロックインの構図があると、経営トップからは見えないコストが、ユーザー企業から定常的にベンダーに支払われていってしまうことになります。結局、これらの問題はベンダー側が主導して開発が行われているところに問題があります。
他にも、コストが安いだけのベンダーに発注してしまったことによるプロジェクト遅延によるコストや低い品質をリカバリーするためのコストなども「見えないコスト」となってのしかかってきます。
私は、ユーザー企業自らがスキルを身に付けることで、無駄のない適正なコストでの開発をするべきだと考えています。弊社では、この考え方のことを「ユーザー主導開発：ULSD（User Lead System Development）」と呼んでいます。
「ユーザー主導開発」というのはどのような開発なのでしょうか？
「ユーザー主導開発」というのは、一言で言うと「丸投げ」と正反対の開発の進め方です。開発自体を開発ベンダーが行うという点は変わらないのですが、ユーザー企業のキーとなるメンバー、たとえばCEO、CIO、情シスメンバーがそれぞれの立場で積極的にシステム開発に関わっていきます。「丸投げ」のように発注してしまった後はベンダーに任せて無関心になるのではなく、ベンダーの開発の進め方にも積極的に関与するという点が特徴です。
ユーザー企業はシステム開発を本業としていません。プロであるベンダーに一括で依頼することが望ましくないのはなぜでしょうか？家を建てるときに住宅メーカーに頼むのと同じことだと思うのですが。
家を建てる場合も、発注者である施主がやらなければならない重要な仕事があります。どんな家でどんな風に暮らしたいのかをしっかり決めて、それを家族みんなで共有することです。そして、それを業者に都度必要な時にきちんと伝えていくことです。今は2Fだが、将来は5Fまでにしたいとかそういった、要望が明確に伝わっていなければ求める家ができあがることはありません。
システム開発の場合も同じです。どんなシステムにしたいかが明確になっていて、それが関係者間で共有されていることが重要です。そのシステムを使ってどういうビジネスを目指すのか、どういう業務を支援するのか、そこをしっかりさせるのはユーザー企業の役割です。そしてそれを一貫した形で開発ベンダーに伝えることが大切です。関係者によって指示が違っているとちぐはぐなものができてしまいます。システム開発の場合、家と違って目に見えないこと、関係者も普通の家族よりも数が多いのでいっそう意識して行う必要があります。これが情シス部門やユーザー部門が担う仕事になります。
CEOやCIOといった経営トップも、システムのビジネス上の効果とそのコストという面だけでなく、その開発過程について関心を持ち続けることが大切です。家を建てる場合も週末には現場まで足を運んでどんな人が作っているのかを見に行くものです。何をしているのか詳しいことがわからないにしても、開発現場に対してユーザー企業の期待を伝えることは大切です。
システムを作っているのは人間です。開発ベンダーのメンバーも、発注してくれているユーザーの期待に応えることのできる良いものを作ろうというモチベーションが高くなれば、できあがるシステムの出来は変わってくるものです。