#SHIFT

欧米と日本の“いいとこ取り”でIT化を加速 ライフネット生命のCIOが取り組む、システム内製化への道(2/5 ページ)

» 2019年12月13日 08時00分 公開
[吉村哲樹ITmedia]

システムの内製化を進めるために超えるべきハードルとは

Photo

中野: もともとはSI企業で受託開発の仕事を手掛けていて、そこから事業会社へと移ったわけですが、それはどういう考えがあってのことだったのでしょうか。

馬場: 当時はとにかく「外資系で働く」というのが第一の目標でしたから、「SI企業か事業会社か」という点についてはあまりこだわりはありませんでした。ただ、当初、手掛けていた受託開発の仕事は二次受けだったので、自分たちが開発・納品したものがユーザーにどう使われているのかが、全く見えませんでした。

 この点について、ずっと違和感を覚えていたのですが、事業会社のIT部門は、自分たちが開発したものを実際に利用する社内ユーザーや社外ユーザーが身近にいるので、仕事の達成感がまったく違いましたね。

中野: ユーザーが近くにいると、構築したシステムが「現場でどう使われているか」が分かるので、対応しやすいですよね。その結果、システムが業務にもたらす効果も上がるので、評価につながりやすくなります。仕事の特色として、企画の色合いが強くなりますね。

 日本のシステム開発特有の「多重構造」の中で、二次受け以下の階層に位置している企業の立場は苦しいですよね。開発のデッドラインは決まっているけれど、お金は中抜きされてあまり入ってこない。

 また、一次受けの人たちが業務をきちんと理解しているとは限りませんから、二次受け以下の人たちにはときに、曖昧な情報しか降りてこないこともあります。

 もっと大きな開発・運用の現場では、元請けだけでも複数社、さらにその下に入る小さな開発会社までいれると相当な数の会社が関わることになります。そうやって縦横に複雑化した会社間の連携は、非常に難易度が高いものになる。

 それでも何とかシステムを作って納品するわけですが、果たしてそれがきちんと運用できているかどうかも、フィードバックが降りてこないので分からない。この時点で、開発と運用が完全に分断されてしまうんですね。

 多重化した環境下で、企画・開発・運用の一連の流れが分断されてしまうことが、企業のIT化が進まない原因になっています。

馬場: 金融の場合はプロジェクトの規模が大きくなることが多いので、特にそうした傾向が顕著ですね。

中野: ちなみにライフネット生命さんでは、システム開発は内製しているのですか?

馬場: いえ、基本的にはパートナーに外注しています。これも2020年度以降のトランスフォーメーションでは、内製率を高めていきたいと考えています。全てを内製しようと思っているわけではないのですが、少なくともわれわれが強みとしているコア部分に関しては、内製化していこうと考えています。

中野: パートナー企業は、金融系に特化したところが多いのですか?

馬場: そうですね。保険に関してはオペレーションが特殊なので、どうしても保険業務に特化したベンダーに頼むことが多くなります。それも、開発を丸投げするというよりは、SES(System Engineering Service:準委任契約)で当社に常駐してもらって、社員と一緒になって開発してもらうことが多いですね。

 この点に関しても今後は、要件や仕様を固めやすい案件に関しては、SESではなく、一括請負で発注していきたいと考えています。ただ、実際にはどの保険会社も事業部門の声が大きいため、どうしても要件を固められない部分が残ってしまいます。そうしたところに関しては、今後もSESでやっていかざるを得ないと思います。

中野: サービスがフロント寄りになればなるほど、なかなか要件は決まりませんから、そうした部分に関してはSESが向いているのでしょうね。

 ユーザーに価値を届け、売上を最大化することを求められるフロントのサービスは流れが速い領域ですから、正解がはっきりしない中で迅速に試行錯誤を繰り返すことが求められます。その結果、企画や開発、運用は可能な限り、柔軟かつ迅速な対応が必要になる。

 一方、バックオフィスの領域、いわゆる法律でプロセスが決まっているような領域は、要件が固めやすいので、開発は比較的、一括請負で出しやすくなる。自社の独自の強みを発揮する部分でもないのですが、業務の正確さや法律への追従が求められて、コスト圧縮の必要性が高くなる。この領域はできあがった仕組みをそのまま入れる方が効率的ですね。

馬場: そうですね。実際、保険会社のバックオフィス系システムはほとんどパッケージ製品が使われています。ただ、日本企業は現場現場に合わせてパッケージにかなりカスタマイズを施してしまいます。その結果、後になってバージョンアップが困難になったり、高額な費用が掛かってしまいがちだと言われています。

 これは技術の問題というよりは構造的な問題なのですが、文句ばかりを言っていてもらちが明かないので、テクノロジーを駆使して何とか切り抜ける方法を模索していかなければいけません。

中野: 内製するにしても、「そのための人材をどう確保するか」という問題もありますしね。

馬場: それは今、まさに痛感しているところです。アジャイル開発で内製できる人材を確保するには、社内で育成するか、もしくは外から連れて来るかの2通りの方法しかないのですが、どちらにせよ、そう簡単ではありません。

 それに、せっかく優秀な人材を確保できたとしても、自社の環境に魅力を感じてもらえなければ3、4年で辞めていってしまいます。従ってまずは、「内製の文化をいかに自社に定着させるか」が第一の関門になると思います。

中野: 内製文化が定着するまでの間は社内評価も安定しないでしょうから、最初に勇気をもって道を切りひらく人がどうしても必要になりますよね。

 最近では社員が知り合いのエンジニアを引っ張ってきたり、開発チームを丸ごと引き抜いたりすることで、こうした課題を解決するケースが多いようです。

 アジャイルの開発手法というのは、技術だけでなく、組織力が非常に強く影響します。そうなると、既に組織として出来上がっているチームを丸ごと引っ張ってくるのが最も合理的なのでしょうね。

 情報システムの仕事は、規模が大きくなればなるほど信頼関係が重要になりますし、チーム単位じゃないと成果を上げづらくなります。必要な技術やスキルも企業の成長フェーズによって違いますから、必要なとき、必要なチームごと他社に移籍するような人材の流れができると、社内ITの世界が変わっていくのではないかと思います。

Copyright © ITmedia, Inc. All Rights Reserved.