Successfully reported this slideshow.
Your SlideShare is downloading. ×

ユーザ系システム会社での内製化(公開用)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 30 Ad
Advertisement

More Related Content

Similar to ユーザ系システム会社での内製化(公開用) (20)

Recently uploaded (20)

Advertisement

ユーザ系システム会社での内製化(公開用)

  1. 1. ユーザ系システム会社での内製化 @T0D0KEN
  2. 2. ユーザ系の会社は生ぬるい? <ul><li>よくあるイメージ </li></ul><ul><li>・ 何をしているかよくわからない? </li></ul><ul><li>・全部ベンダーにやらせて、自分たちは定時で帰っちゃう? </li></ul><ul><li>・適当な要件定義をしてくるので、仕様変更が多い? </li></ul><ul><li>・技術的なことが分かっていないから、話が通じない? </li></ul><ul><li>・自分たちは業務に詳しいと言っているが、そうでもない? </li></ul><ul><li>・納期とコストばかり気にしていて、口うるさい? </li></ul>ユーザ系って何なの!?
  3. 3. 一言にユーザ系とは言っても… <ul><li>パターン1. IT 戦略、要件定義等の上流工程を重視する </li></ul><ul><ul><li>開発工程は外部にアウトソーシングする </li></ul></ul><ul><ul><li>結果的に、運用・保守も外部にお願いすることになる </li></ul></ul><ul><ul><li>IT 戦略や要件定義だけで、本当に“良い”システムができるの? </li></ul></ul><ul><li>パターン2.運用と保守業務を重視する </li></ul><ul><ul><li>開発工程はアウトソーシングするが、運用・保守は自社で </li></ul></ul><ul><ul><li>結果的に、開発工程にも参画する必要が出てくる </li></ul></ul><ul><ul><li>今やシステムはもはやビジネスに欠くことのできない要素の一つ </li></ul></ul><ul><ul><li>それほどまでに重要な要素を第三者にアウトソースして良いものか? </li></ul></ul>
  4. 4. システム保守コスト <ul><li>ライフサイクル全体のうち3分の2のコストが保守で費やされる </li></ul>保守 テスト 実装 設計 要件定義 4年~ 1年 構築 2 億 保守 0.5 億 x 8 年 例えば…
  5. 5. <ul><li>IT コストを圧縮したいなら、 </li></ul><ul><li>運用・保守を効率化する </li></ul><ul><li>ほうが効果的 </li></ul>http://www.flickr.com/photos/thenovys/2838875961/
  6. 6. <ul><li>システムの運用・保守に力を入れる! </li></ul>http://www.flickr.com/photos/dirkjankraan/5267858365//
  7. 7. 技術トレンドの変化 <ul><li>メインフレームからサーバサイドへ </li></ul><ul><li>サーバサイド技術の標準化=技術的敷居を下げる </li></ul>
  8. 8. 正直、ついていけないよ http://www.flickr.com/photos/derposchist/3440590449/
  9. 9. <ul><li>社外から連れてくれば、良いじゃん! </li></ul>http://www.flickr.com/photos/locallifephoto/5267103742/ /
  10. 10. アクター <ul><li>プロパー(従業員) </li></ul><ul><li>弊社の社員。 </li></ul><ul><li>20 代の若手から 50 代の大ベテランまで色んな年齢層の人がいる。 </li></ul><ul><li>パートナー(常駐している BP の方) </li></ul><ul><li>BP (協力会社)の社員の方。 </li></ul><ul><li>戦略的に超長期( 20 年とか)のスパンでお付き合いしている。 </li></ul><ul><li>プロパーよりも詳しい知識を持っている方もいる。 </li></ul><ul><li>ベンダー(非常駐の BP の方) </li></ul><ul><li>BP (協力会社)の社員の方。 </li></ul><ul><li>基本的にはプロジェクト期間のみのお付き合い。 </li></ul><ul><li>規模にもよるが、要件定義からシステムテストまで行ってもらう。 </li></ul>
  11. 11. 役割分担 システム戦略 要件定義 基本設計 詳細・実装 単体・結合 システムテスト 運用・保守 プロパー パートナー ベンダー
  12. 12. 実際には・・・ システム戦略 要件定義 基本設計 詳細・実装 単体・結合 システムテスト 運用・保守 プロパー ベンダー パートナー
  13. 13. 結果的に・・・ <ul><li>開発技術力の空洞化 </li></ul>http://www.flickr.com/photos/saucydragonfly/3496230622/
  14. 14. ベンダー依存になってしまう構造 技術トレンドの変化 技術的な事が全然わからない (自分たちだけではシステムの 運用・保守ができない状態に) 技術的なことは外部に依頼 + 自分たちができる事をやる 業務の中心はエンドユーザとの 仕様調整や計画立案に
  15. 15. その結果・・・ <ul><li>ベンダーに依存する体質 = 運用コストが増大 </li></ul><ul><li>障害対応が遅くなる = 運用・保守できていない </li></ul><ul><li>運用・保守 -> 要件定義へのフィードバックができない </li></ul>http://www.flickr.com/photos/martincarlinphotography/5263266088/
  16. 16. <ul><li>自分たちに存在意義はあるのか? </li></ul>http://www.flickr.com/photos/nyssak/5234921767/
  17. 17. <ul><li>この悪循環を断ち切らなければならない </li></ul>http://www.flickr.com/photos/pirrandi_as/5159673790/
  18. 18. だったら・・・ <ul><li>主導権を取り戻せば良いじゃない! </li></ul><ul><li>自分たちでやってみようよ! </li></ul>http://www.flickr.com/photos/xinam/2984113610/
  19. 19. そこで・・・ <ul><li>“ 内製化” </li></ul><ul><li>言い換えると、外注費を削減する活動 </li></ul>http://www.flickr.com/photos/achew/4470234920//
  20. 20. <ul><li>自分たちでできることは自分たちでできるようにし、 </li></ul><ul><li>外部に委託していた業務を巻き取る </li></ul>http://www.flickr.com/photos/george_eastman_house/3334094680/
  21. 21. 悪循環から抜け出すために <ul><li>できるところからやってみる </li></ul><ul><li>= </li></ul><ul><li>自分たちでも対応できそうな案件から始めてみる </li></ul>
  22. 22. 背景(百貨店売上高推移) 億円 %
  23. 23. 言い換えれば… <ul><li>私たちの母体の危機 = 私たちの危機 </li></ul>http://www.flickr.com/photos/hugo/5247070081/
  24. 24. こういった状況下で利益を確保するには <ul><li>大雑把に言うと、以下の2つが考えられる </li></ul><ul><li>売上を増やす </li></ul><ul><ul><li>外部事業収益の拡大を目指す </li></ul></ul><ul><ul><li>-> とは言っても、今までぬるま湯に浸かってきたので、急な方向転換はなかなか難しい </li></ul></ul><ul><ul><li>本業の売上を伸ばす </li></ul></ul><ul><ul><li>-> システムを用いて流通チャネルの拡大など、新事業に発展させる </li></ul></ul><ul><li>経費を削減する </li></ul><ul><ul><li>外注コストを削減する </li></ul></ul><ul><ul><li>-> 自分たちの立ち位置をもう一度見直し、自分たちでできることは、自分たちでやるようにする </li></ul></ul><ul><ul><li>自分たちの経費を削減する </li></ul></ul><ul><ul><li>-> 既に努力している(ペーパーレス化、残業抑制など) </li></ul></ul>
  25. 25. その結果 見積もり工数 3人月 プロパーのみで 0.5人月 約83%のコスト削減効果 ※ この案件を消化するために、新しいヒトを雇ったわけではない(余力で実施) よって、実質100%のコスト削減効果 ベンダー提案内容 実際は …
  26. 26. 実現までのステップ 既存システム アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化 ノウハウの蓄積 + コスト削減効果 新規システム 実際の案件に内製化メンバー投入 アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化 ノウハウの蓄積 + コスト削減効果 アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化 実際の案件に内製化メンバー投入 ノウハウの蓄積 + コスト削減効果 アーキテクチャ勉強会実施 規模の小さい簡単な案件を内製化
  27. 27. 内製化はコスト削減以外の効果も生む できるところから内製化する 内製化できる範囲が拡大する + 技術力をベースとした提案へ 外部コストが削減される ノウハウが蓄積され、 開発技術力が徐々に高まる
  28. 28. 運用保守のあるべき姿 <ul><li>運用・保守に求められる役割 </li></ul><ul><ul><li>ログ分析等により、システムの使われ方を分析 </li></ul></ul><ul><ul><li>頻繁に使われる機能とそうでないものを分別(費用対効果の測定) </li></ul></ul><ul><ul><li>利用状況を元に、新機能の追加や改善の提案を行う </li></ul></ul>一般企業には真似できないサービスを提供する
  29. 29. <ul><li>システム全体を把握したものに </li></ul><ul><li>しかできないシステム構築 </li></ul>http://www.flickr.com/photos/mistishadows/5243297576/
  30. 30. <ul><li>ご清聴ありがとうございました </li></ul>

Editor's Notes

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

×