Más contenido relacionado
Similar a ユーザ系システム会社での内製化(公開用) (20)
ユーザ系システム会社での内製化(公開用)
- 26. 実現までのステップ 既存システム アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化 ノウハウの蓄積 + コスト削減効果 新規システム 実際の案件に内製化メンバー投入 アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化 ノウハウの蓄積 + コスト削減効果 アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化 実際の案件に内製化メンバー投入 ノウハウの蓄積 + コスト削減効果 アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化
Notas del editor
- ユーザ系のシステム会社について、話をしてほしいということでしたので、現在最もホットな話題の一つである「内製化」というキーワードから、ユーザ系のシステム会社について見ていきたいと思います。 正直、たいしたお話はできませんが、ここでお話しする内容が少しでも皆さまのお役にたてれば幸いです。
- ユーザ系と言うと、次のようなイメージを持たれる方が多いと思います。 (箇条書きの部分を読み上げる) つまりは、適当な人たちが適当なことをやっているよくわからない会社であると。 存在意義すら感じないと思われる人が結構います。 一部は真実であり、一部は嘘です。 今日の発表で、現在どういう課題感を持っていて、それに対してどのような取り組みをしているのか、ということが少しでも伝われば幸いです。
- ユーザ系のシステム会社と言っても、次の2つの分類ができると思います。 (それぞれ読み上げる) 全体としては、パターン1の形態をとる企業の方が多いです。 パターン2の形態だと、システムを動作させるために、非常に多くの従業員が必要となるからです。 ユーザ系と言われるシステム会社を持っている場合は、パターン2の形態の事が非常に多いです。 私のいる会社では、(太字を読み上げる)などの課題感があるために、運用と保守の業務は自社のグループ内で行うという戦略を取っています。
- ライフサイクルコストについては、皆さんご存知かと思います。 システムが開発されてから再構築されるか、使われなくなるまでの間にかかるトータルコストのことです。 皆さんご存知の通り、システムのライフサイクルという視点から見ると、システム開発に要するコストはごく一部にしか過ぎません。 開発は1年足らずかもしれませんが、開発されたシステムというのは5年10年と使われる事になるからです。 当然、開発することにかかったコストよりも、それを維持管理するコストの方が上回ることの方が多いです。 システムを運用する間にはパフォーマンスの劣化や障害対応など様々なトラブルに見舞われますし、機能追加も行わなければなりません。 システムを構築後、それを維持管理し、 IT サービスとして提供するだけでも、多大なコストがかかるということです。
- このような理由から、私の会社では、先ほどのスライドにあった「パターン2」の戦略を採用しています。 新規のシステムを構築する際も、「いかに保守をしやすくするか」を一番に考えて設計を行います。 常に、保守ありきの思想であるということです。 余談になりますが、保守がしにくいシステムというのは最悪です。 例えば、夜間バッチが走る深夜3時とかにバッチが異常終了すると、担当者は電話で叩き起こされます。 昼間普通に働いていたにも関わらず、です。 大抵のシステムは、家からもログが見られるようになっているため、モニタの前に座り、ログを見ます。 こういうことを前提に考えられていないシステムの場合、ログを見ても何故異常終了したのか、放置して良いのかもわからないわけです。 仕方ないので、そのまま会社に出勤して、実際のマシンを操作するなどして、詳細を調査するわけです。 でも、その間はシステムが止まったままであり、翌日に色んな人から怒られる、という構図です。
- しかし、近年、技術のトレンドが大きく変化しました。 技術が大幅に進歩し、コストダウンを狙って、システムの主流はメインフレーム系からオープン系へとシフトしました。 これは非常に大きなパラダイムシフトと言えます。 今まで数十年に渡って蓄積してきたノウハウが一気に使い物にならなくなるわけですから。 そして、最近ではこの変化に付いていけなくなる企業が非常に多いというのが実感としてあります。 私の会社では、この事態に対処するために、採用技術の標準化を押し進めました。 具体的には、開発言語を Java に統一し、データベースは Oracle 、アプリケーションサーバは WebLogic に一本化したわけです。
- しかし、 COBOL 等の手続き型言語から Java などのオブジェクト指向言語への変更というのはあまりにインパクトが大きすぎたと思います。 残念ながら、ホスト時代の人のほとんどは、この変化に対応できなかった、というのが現状だと思います。 (当然、中には柔軟に対応する人もいるんだけど、多くの人はダメだったと。)
- で、どうしたのか? 答えは、単純明快です。 社外から、オープン系に強い人を連れてきました。 つまり、外注に頼ったわけです。
- では、現在の従業員の構成はどうなっているでしょうか? 私の会社では、ざっくり言うと、次の3つの雇用形態の人が働いています。 (資料を読む)
- (この図が見やすいかどうかはさておき・・・) 横軸に開発工程、縦軸は関与の深さをとって、プロパー、ベンダー、パートナーがそれぞれどの部分に関与すべきかを示しました。 本来であれば、システム戦略や要件定義、最下流となる実際の運用・保守については、プロパー主導で行っていくべきです。 私たちだけでは人手の足りない、実装部分周辺については、ベンダーにお任せする、というのが望ましい形だと考えています。 ベンダーの方は、様々な会社のシステムを開発しているわけで、我々とは比べ物にならないほど、深いノウハウを持っているはずだからです。 時には、運用・保守のフェーズであっても、自分たちだけでは人手不足になることもあります。 そういった時には、ベンダーの方に手伝ってもらったり、パートナーの方に手伝ってもらう等、社外のリソースを有効活用することで乗り切ります。 そもそも、大企業になればなるほど、自社の社員を削りづらくなりますので、これは有効な対策であると思います。
- しかし、これは理想の姿です。 実際には、この図のような形になってしまっています。 時代の流れについてこれなかった一部のシステムにおいては、プロパーだけでは運用・保守を回せない状況に陥っています。 つまり、開発当初から関わっていたベンダーの力なくしては、その後の業務をうまく回せない状態になっています。 赤丸で囲った部分、つまり私たちが主導権を握り、作業を進めていかなければならない部分までベンダー側に握られるようになってしまったということです。 この問題の中でも特に問題なのは、「自分たちではできないからベンダーにお願いする」という構造が根付いてしまっていることです。 これにより、「できないからやらない」->「やらないからできない」という悪循環に陥り、本来自分たちが強みとしている部分までも、ベンダーに奪われてしまっているのです。
- つまり、このドーナツのように、システム開発の中心にある開発技術力が空洞化してしまったわけです。
- 今まで話しましたベンダー依存になってしまう構造をまとめたものが、この図です。 技術トレンドの変化に対応できなくなったため、技術的なことは外部のベンダーに依頼するようになり、自分たちは、自分たちができる事をやるようになりました。 自分たちができる事は、ユーザに最も近い位置にいるために、エンドユーザとの仕様調整や計画立案がメインの業務になっていきました。 これを繰り返していると、技術的な話に全く付いていけない状態に陥り、自分たちだけではシステムの運用・保守ができない状態になってしまいます。 まさに、変化に対応できなかった、ということです。
- その結果、 ・ベンダーに依存する体質が根付いてしまいました。外部の企業に頼っている訳ですから、運用コストが増大します。 ・間にベンダーを介さないと何もわからないわけですから、障害や改善要望等への対応も遅くなります。 ・もっと悪い事に、運用・保守がよくわからないわけですから、これらから得られる情報を上流工程にフィードバックできなくなります。
- いきなり、内製化するぞ!と言ったところで、初めは何もできません。 結局のところ、小さなところからコツコツとやってみるより他にない。 いきなり大きいものができないのであれば、小さなところから地道に積み重ねていけば良いじゃないか。 というわけで、簡単な画面の修正や簡単な改善案件から取り組んでいきました。 (システムもいきなり大きな基幹システムやマーチャンダイジングのシステムではなく、小さなシステムから)
- なぜ、今になって、このような取り組みが始まったのでしょうか? このグラフを見てもらえれば、お分かり頂けるように、百貨店業界自体の業績が芳しくない、ということがあります。 特に、1998年以降は、13年連続で売上高が前年を下回っているような状況です。 そこへきて、昨年のリーマンショックですから、非常に打撃が大きいというわけです。 当然、グループの本業の業績がよくないわけですから、コスト削減圧力が高まります。 IT は特にシビアです。コストのかかるものですから、その圧力も強いというわけです。
- で、話を戻しましょう。 小さなところからコツコツと内製化に取り組んだため、このスライドのように、約83%のコスト削減に成功しました。 もっと言うと、今いる人の空き時間を使って、内製化ができたわけなので、外部流出コストはゼロです。 つまり、100%のコスト削減効果が出た、ということが言えます。
- この結果を得るために、何をしてきたのか。 個人的には、技術が Java, Oracle, WebLogic に標準化されていたことが非常に大きなポイントであったと思います。 特に、 WebLogic については、 EJB などの機能を用いず、単なるサーブレットコンテナとして使っていたため、アプリケーション自体が非常にシンプルなアーキテクチャになっています。 これにより、新入社員の時点から教育すべき内容が絞り込まれていました。 Java と Servlet の知識を叩き込み、 DB の操作は保守や新規開発案件を新入社員に体験させることにより、身につけさせました。 この前提があった上での話にはなりますが、 内製化対象のシステムのアーキテクチャ勉強会をベンダーに協力してもらって開催しました。 その後は、実際にやってみる、ということの繰り返しです。
- これは定量的に効果測定することができませんが、内製化の取り組みには、コスト削減以外の副次的効果も秘めています。 つまり、内製化を繰り返す事により、課題であった「開発技術力の空洞化」が解決できるということです。 面白いエピソードとしては、内製化に関わっているプロジェクトでは、ベンダーをうまく使えるようになってきたことがあります。 ベンダー側見れば、とても厄介な話ですが、「この程度の改修で、この見積もりはおかしい!」と突き返すことが増えているのです。 実際に、どのような改修が行われるかがイメージできているから、言える事でしょう。
- これにより、運用・保守をあるべき姿に持っていく事ができます。 運用・保守のあるべき姿とは、 ・システムの利用状況を分析したり、 ・費用対効果を計測して、次の案件にフィードバックしたり、 ・これらの情報をもとに、新機能の提案などを、技術視点から行うことができることです。 運用・保守という、我々にしか得られない情報を使って、これを有効活用することが、私たちがやらなければならないことです。 これにより、他の企業には真似のできないシステムを作り上げ、本業(つまり、百貨店)の業績に貢献できるようなシステムを構築できるようにすることが、我々の存在意義と言えます。
- 究極的には、 百貨店システム全体を俯瞰し、システム間連携を強めたり、それらを組み合わせることにより相乗効果を生み出せるようなシステムを提案することができるようになるのではないか、と。 まさに、ユーザ系にしか成し得ない提案をしなければ、我々も生き残る事はできない、と考えています。 危機感が自分たちの変化を助長するのだ、というのが正直な感想です。 実際のところ、まだ内製化は始まったばかりです。 今後は、こういう動きがより強くなるものと思われますし、スピード感も今以上に求められるようになってきます。 自分としては、その変化の渦中にいる訳で、今後の展開が楽しみだったりします。
- と、最後は感想になってしまいましたが、以上で私の発表を終わらせて頂きます。 どうも、ご清聴ありがとうございました。