ゼリア新薬工業株式会社 熊野 憲辰 様

1. 丸投げ&ロックイン構造
からの脱却
ゼリア新薬工業 熊野
2011/4/25
Slide No. 1

2. 全体の流れ
前半
丸投げ、ロックインなどの、問題・事例・
考察など。
後半
では、どうすればいいか？
当社の事例も含めて考えてみます。
Slide No. 2

3. ユーザ企業の丸投げ
◆ユーザ企業の丸投げって？
→ 自社で考えなければならないことを、ベンダーに
任せてしまうこと。
◆結果どうなってしまう？
→ 自分で考えることができなくなる。
→ 考えなくてもやってくれるから。
→ ベンダーとユーザ間のメッセンジャー役
→ お金だけは、大量に出て行く。
Slide No. 3

4. ユーザ企業の丸投げ
◆思考停止
→ 要求を自分の言葉で語ることができない。
→ 自社の業務フローをまともに書けない。
(痺れを切らした)ベンダーが、“いくつか案を提示”
「この3つの案から、選んでください」
丸投げすると、こんな感じになります。
Slide No. 4

5. ユーザ企業の丸投げ
◆なぜこうなった？？
1990年代後半 → アウトソーシングブーム
上流の仕事が、上等な仕事。
プログラミングなどの、下流の仕事を軽視。
社員が、自社のコンピタンスに特化することと、
プログラミングをアウトソースすること、
これを、間違えた。
プログラムは、自社のコア・コンピタンスであった。
Slide No. 5

6. ユーザ企業の丸投げ
◆また・・・
変化することをしなかった。
→ 90年代後半のアウトソースブーム(？)は、
その当時の最善であった。
→ 常に、時代を見据えて変化することが
できなかった。
→ これが日本人の苦手なところか？
何故、変化を嫌う？
→ ソフトウェアが、ソフトでなかった。
→ 安定を望む。 しかし、安定って何？
Slide No. 6

7. ユーザ企業の丸投げ
◆安定とは？
→ 高速で回転する独楽
→ 常に変化を続けること
→ 常に、外からエネルギーが与えられること
→ 止まっている独楽を安定しているとは言わない
→ 頻繁にバージョンアップをしたり、
→ 業者を変更したり、
→ 安定すること＝変化すること
Slide No. 7

8. ベンダーのロックイン
◆ロックインって？
ベンダーの戦略
一度食らい付いたら離さない。
→ 経常的にお金を搾り取る。
沢山の人間を、べったり貼り付ける。
ユーザのマインド
お金を出して、問題が起きたときに責任を
押し付けられる。
Slide No. 8

9. ベンダーのロックイン
◆結果・・・・
ユーザ企業は、自社のシステムが、“どうやって”、
“なぜ”動いているかわからなくなる。
ベンダーへの依存度は、時間とともにアップ
→ 気がついたら身動き取れない。
そして・・・、一種の半癒着構造、共生関係が生まれる。
しかし、昨今の保守料の高騰、サービス化がこの環境
を変える。
Slide No. 9

10. ベンダーのロックイン
◆ベンダーは・・・
経常的に収入が入る
→ 楽チン
→ 怠けても、給料入ってくる。
→ 技術に力が入らない。
→ 技術に疎く、御用聞きSEが沢山
→ 国際競争力から大きく遅れを取る。
Slide No. 10

11. ベンダーも丸投げ
◆多重下請け（丸投げ）構造
元請ベンダーは、下請けベンダーに丸投げする
下請けベンダーは、孫請けに・・・・
孫請けは、オフショアに・・・・
壮大なる伝言ゲームの末、システムが作られる。
→ Fatなドキュメントが必要になる。
→ ユーザ企業と、プログラマは、はるかかなた。
Slide No. 11

12. 高コスト化
◆多重リスク（又は、バッファ）構造
元請、下請け、孫請け・・・全ての企業が、“リスク”
を見込む。（当然利益も）
リスク（バッファ）って？
→ ユーザ企業が、全てを語れない
→ 何が隠れているか、わからない。
→ 大抵隠れていて・・・、リスク代は消費される。
結果、膨大なコストに。
→ 億のオーダーの見積もりが常態化
→ しかし、誰も“大儲け”していない。
Slide No. 12

13. 高コスト化
◆巨大なコンプレックスである情報システム。
→ 様々な専門家が必要
→ その専門家をマネージする人
◆プロジェクト会議は、20～30人
→ そして、そこにはプログラマはいない。
→ プロマネといわれる、調整者。
→ プロマネの人件費、一人一時間3万円
→ プロジェクト会議、1回100万円也
→ これも高コスト化の一因
Slide No. 13

14. ユーザ企業の経営者
◆ユーザ企業の経営者は・・・
ITに疎い経営者も多い。
なんで、こんなにお金がかかるのか、不信感がつのる。
上述のような構造とは、露知らず。
→ 何故なら、ベンダーと自社のIT部門が
共生関係にあるから、知らされない。
子会社にしてしまえ？
→ これも、一種の解決策かも
Slide No. 14

15. ベンダーの自己矛盾
◆ラピッドなツール、方法論を使わない。
受託開発で、大量の人間を、人月単価で押し込む
ビジネスモデルは、おいしい。
自動化ツールなど使うと、人月減ってしまう。
方法論もしかり。
→ 知的にやったら、人月減ってしまう。
結果、技術力が低下する。
Slide No. 15

16. ユーザ主導のコンペ
◆コンペを行う
生産性、コストで勝負すればよい。
→ 自由経済の原理が働く。
→ SIベンダーが、高生産性ツール、方法論を
積極的に使う可能性がある。
◆ベンダーの言い分
リスクを見込んで、見積書を作る。
しかし、コンペが進むと、それが徐々に減っていく。
→ ユーザ企業がリスクを保持しないと、ベンダーも
疲弊するだけ。
Slide No. 16

17. 受託開発モデルの限界
◆受託開発モデルのイナーシャ
人間を、人月単価で商品化。
→ これが儲かった？
→ このビジネスモデルから、思考が脱却できない
◆限界
前述までの様々な問題の根源。
この、SIベンダーの受託開発モデルを、壊す。
→ これがシステム・イニシアティブ研究会の仕事。
Slide No. 17

18. 人月単価のモデル
◆本質的なジレンマ
人間を人月単価で、商品化
→ まるで消費財のような扱い。
人間は、そもそも生産財。
→ 生産財の需要は、一定でない。
→ 好景気の時は、需要が増え、
→ 不況の時は、需要が減る。
→ リストラ、賃下げ → 失業率上昇
→ さらに、不況に・・・。
Slide No. 18

19. IT企業ってなんなんだ？
◆そもそも
IT企業というのは、“情報”を主に扱う会社だろう。
今の、ITベンダーは、そうではない。
本当のIT企業は、情報やサービスの会社
→ 金融機関や、鉄道会社など。
→ これが、IT企業といっていいだろう。
今の、ITベンダーは？
→ 人材派遣企業？ 商社？ 保険業？
Slide No. 19

20. 日本発イノベーションが起きない
◆人材派遣会社、商社からは無理。
技術を磨くのではなく、お金を儲けることが大事。
技術者集団でなくなってしまった？
→ 縦割りな組織構造、管理・官僚主義
→ 利口な専門家の上に、
→ バカな政治家、という構造（国も企業も）
若くて優秀なエンジニアの芽が出ない。
→ 3K、7K、デスマーチ
→ 技術者の離反
→ 悪循環
Slide No. 20

21. ユーザ企業も無気力
◆情報システム部門の高齢化
年を取ると・・・
→ 新しいものに、（無意識に）抵抗感
→ 変化を嫌う。
◆技術屋＜事務方
事務方が、国や企業の主導権を握っている。
企業内の評価も事務方のほうが高いだろう。
→ やはり、若い優秀なエンジニアの芽が出ない。
Slide No. 21

22. パッケージソフト、SaaS
◆スクラッチ開発→パッケージ化というビジネス
→ パッケージソフトって・・・
→ 本質的な矛盾がある気がする。
◆本質的な矛盾
→ ソフトではない → 柔らかくないということ
→ 不特定多数の利用が前提
→ 最大公約数的な作り
→ アドオン、カスタマイズしても限界
→ 結果、靴に足を合わせることにも。。。
Slide No. 22

23. “ソフト”ウェア
◆ソフト＝柔らかい
→ 今の“ソフト”ウェアは、柔らかくて、簡単に作り
変えられて、簡単にバージョンアップできて・・・
という存在だと感じますか？
→ 特にパッケージソフト
→ 数行の修正で100万円とか
→ “ハード”ウェアに近い
◆ハードウェアが柔らかい時代
→ 仮想化、クラウド
→ スケールアウトも簡単
Slide No. 23

24. これでは、幸せになれない
◆なぜか？
一見、この癒着構造の中で、双方ハッピーに見えるけど？
このモデルでは、“賢い企業がバカをみる”
→ これで、産業が良くなるわけが無い。
Slide No. 24

25. 賢い企業がバカをみる
◆例えば・・・
前述のリスクの話。
ユーザ企業がまともに業務フローを書けない。
自社の要件を語れない。
だから、その肩代わりをすること、手戻りの可能性、
これらを、リスクとして、最初から乗せている。
→ 自社で要件を語れる、業務を語れる企業は、
損をするだけ。
Slide No. 25

26. 日本企業の中国への進出
◆日本企業が、中国に進出した当初
慣習の違い？
契約どおり、お金を回収できないことが多かった。
その後、日本の企業も学習して、そのリスクを上乗せ
するようになった。
中国のまじめな企業は損をしますね。
→ そもそも、無駄ばかりなんだが・・・・
Slide No. 26

27. 無駄といえば・・・
◆中国の事例でも・・・
→ 契約違反だ、そうでない、
→ 裁判したり、
→ 今後は、リスクを上乗せしておこう
→ こんなの、無駄な作業なだけ。
→ 価値を生む作業ではない。
◆日本でも・・・
→ 不透明なコスト構造
→ 値引で半額近くになったりする
→ 値引合戦のコンペ → 同じように、無駄。
Slide No. 27

28. 値引といえば・・・
◆日本のクラウドサービス
クラウドは、サービスです。
サービスとは、例えば、電車やバスや、電気、水道など。
基本的に、従量課金制となる。
そして、その体系は明確でシンプルである必要がある。
マイカーを買うなら、値引、オプションなど、時間をかける。
しかし、電車に乗るか、タクシーに乗るか・・・。
これが、サービス。
→ 明確な価格体系がオープンでなければ、
サービスの自由な選択はできない。
Slide No. 28

29. とあるクラウドビジネス業者
◆クラウドサービスなのに・・・
→ 値引で半額以下に・・・
→ 初期費用が膨大
→ 月にどのくらいの費用がかかるか、不透明
◆最短で、5営業日でサービスイン！
→ 値引交渉に、１ヶ月とかかかる。
→ 従来型のビジネスのイナーシャ。
→ サービスというものの、本質を経営者が
わかっていない。
Slide No. 29

30. では、どうすれば脱却できるか？
◆ユーザ企業の自社コンピタンス
知識領域別に考えてみる
ドメイン知識 → 自社のコア・コンピタンス
アプリケーションの知識 → 自社コンピタンス
データベース、クラス → 自社コンピタンス
プログラム → 自社コンピタンス
ミドルウェア → ある程度、アウトソースしても良い
ネットワーク → ある程度、アウトソースしても良い
ハードウェア → 自社で抱える必要は無い
Slide No. 30

31. 当社の事例
◆前提
→ 自社の内製で実施
→ モデリング
→ プログラミング
→ 技術コンサルを採用
→ 成果責任なし
→ 瑕疵責任なし
→ リスクは、当社で保有する
Slide No. 31

32. 当社の事例
◆技術の獲得
優秀なエンジニアを見つける。
→ 会社では無い。個人。
→ 外に積極的に出ること。
→ 優秀なエンジニアは、集まる。
→ 斥力に負けないようにする。
◆優秀なエンジニア
→ フリーランスにいる。
Slide No. 32

33. 当社の事例
◆技術の獲得
優れたエンジニアとは？
→ 自ら進んで、技術を学び成長できる人間
そのような人材になるには？
→ 外に出て、優秀なエンジニアに会う。
→ 刺激を受け、自分とのギャップを感じる。
→ ギャップに対するフラストレーションが生じる。
→ これが、自ら学ぶ原動力になる。
Slide No. 33

34. 当社の事例
◆技術の獲得
エンジニアリングに注力
→ 技術は短く、原理は長い。
具体的には
→ モデリング
→ オブジェクト指向モデリング、UML
→ データモデリング
→ モデリングをやる意味
→ モデリングは、思考そのもの
SIベンダーも、エンジニアリング音痴が多い
→ 目利きになれる。
Slide No. 34

35. 当社の事例
◆技術の獲得
どのくらいの、時間とお金がかかるか？
→ 約3 年
→ フィージビリティ兼、技術習得で実施
→ お金は・・・かかります。
どこから予算を出したか？
→ いままで、ベンダーにジャブジャブ払っていた
お金の一部をまわす。
モチベーションが大事
→ 情報システム部員の気力、喜び、楽しさ。
Slide No. 35

36. 人材育成の原動力
◆仕事の楽しさ → 原動力
今、仕事がつまらないですか？
→ 昔は仕事が楽しかった・・・という話を良く聞く。
なぜつまらない？
→ 自分の世界が経験とともに拡大していくことを
実感できない。
今、仕事で求められていること
→ コスト削減、効率化・・・
→ 目標、夢、希望が無くなってきている？
人を育てることは、コストではなく、投資
→ 投資の気持ちで社外での活動を推進せよ
Slide No. 36

37. Agile開発
◆Agile開発
Scrum＋XP＋カンバン方式のような形式
◆用語
→ スプリント
→ １ヶ月を単位とする。
→ 動くものを作る
→ イテレーション
→ １週間単位
→ フィードバックループ
→ レビューとブラッシュアップを繰り返す
Slide No. 37

38. Agile開発
◆用語
→ 朝会
→ 毎日行う。30分程度。
→ 朝に、本日の仕事の確認、問題の共有。
→ チケット
→ 一つの仕事
→ 行うことが明確であるもの
→ 1枚のチケットは、約2～3時間が目安
◆チケットドリブン
→ これで、初めて、ソフトウェア開発の、
正しスケジューリングができる。
Slide No. 38

39. Agile開発
一枚のチケット→A5サイズ
余白（磁石エリア）
チケットのタイトル
担当者A 予想時間 実績時間
2ｈ 3ｈ
担当者B
予定日 実施日
2011/04/02 2011/04/01
Slide No. 39

40. Agile開発
◆ペアプログラミング（ワーキング）
→ XP（eXtreme Programming）のプラクティス
→ レビューを一日中やろう！という精神
→ 一つのチケットを二人で担当
→ 毎日変わる。
◆狙い
→ メンタリング
→ 教えるもの、教わるもの
→ 二つの頭で考える。
→ ナレッジを流動化
→ メンバー間の風通しを良くする。
Slide No. 40

41. Agile開発
カンバン 色の付いた●は、磁石。色が担当者に対応 2台のキャビネット（のつもり）
↓ ↓
今週やること 今日やること 今日やったこと 今週やったこと
↑
チケット
（A5サイズ）
A5サイズ）
Slide No. 41

42. Agile開発
◆なぜAgileか？
→ ベンダー主導だとウォータフォールにしか
ならない
→ コストをFIXする必要があるから
→ 契約も問題になる
→ ユーザ企業主導だと、Agileと相性いい
Slide No. 42

43. Agile開発
◆Agile的な要件定義 ～ 家計簿の話。
あなたが友人から、家計簿をやりたいから相談に乗って欲しいと依頼された
とする。あなたはどうしますか？
その友人が、以前から帳面なりで家計簿をつけていた経験があるなら、話は
早い。“何がしたいか？”、“管理項目は？”などをヒアリングして、ソフトを作る
なり、アプリを紹介するなりすればよろしい。
しかし、初めて家計簿にトライするような場合、気をつける必要がある。
この時、“何がしたい？”と聞いた時点で失敗する可能性が高い。
なぜなら、その友人は、まだイメージが無い。しかし聞かれたら言葉を返すしか
ない。その後、「言ったじゃないか？」「こんなはずじゃなかった」・・・
正解は、「一緒に考えよう」だ。そして、反復とフィードバックの中で、要求を実現
すればよい。
Slide No. 43

44. モデリング
◆よくある社員マスター
社員マスタ このテーブルには、いくつかの間違いがあ
社員コード（主キー） ります。いくつあるかわかりますか？
氏名 このようなテーブル設計をするエンジニアが
沢山います。
性別
役職コード
所属コード
入社日
退職日
Slide No. 44

45. モデリング
◆よくある社員マスター
社員マスタ
社員コード（主キー）
氏名 → 間違い：社員の属性ではありません
性別 → 間違い：社員の属性ではありません
役職コード
所属コード → 間違い：関係で持つべき
入社日 → 間違い：Eventです。
退職日 → 間違い：Eventです。
Slide No. 45

46. モデリング
◆ ERモデル これがモデル。
エクセルの表で、データベースの
テーブル定義書を作るエンジニアはダメ。
Slide No. 46

47. モデリング
◆ モデリングの例（クラス図）
Slide No. 47

48. プログラミング
◆自社コンピタンスのレイヤー
→ モデル層
◆ある程度外部に出す、またはツールを使う
→ バウンダリー層
◆ツール
→ プログラミングにおける各種ツールは重要
→ Eclipse
→ Subversion
→ Tortoise
→ astah*
astah*以外は、OSS
Slide No. 48

49. テスト
◆ツール （全てOSS）
→ Selenium
→ TestNG
→ Jenkins
◆継続的インテグレーション
→ 上記のJenkinsを使う
→ テストを完全自動化
→ 各種バージョンアップにも有効
◆チケットとテスト
→ 2時間のプログラミングチケットの場合、
コードを書く時間は30分。後はテスト。
Slide No. 49

50. コスト
◆自己責任、自立
→ OSSを使う。
→ あくまで、利用が中心。
→ コンフィグレーションとかバージョンアップは、
結構面倒
→ このあたりは、（外部）技術者に任せる。
→ 大幅にコストダウン
◆具体的には
→ CentOS
→ MySQL
→ Apache/Tomcat
Slide No. 50

51. OSS
◆OSSの利用
→ スケールアウト型アーキテクチャ
→ クラウド（IaaS)で有利
→ 商用ソフトは、サーバを増設時に
ライセンス費用が、都度かかり俊敏でない
→ クラウドが、このあたりのライセンス環境を
変えるかも。
◆バージョンの選択
→ 安定したバージョンの最新版
→ バージョンアップテストの自動化
→ 継続的インテグレーションが有効
Slide No. 51

52. どこから始めるか？
◆といっても・・・プログラマを養成するには時間がかかる
→ サービスとしての、ソフトウェア開発の紹介
→ SonicGarden カスタムクラウド
Slide No. 52

53. カスタムクラウド
Slide No. 53

54. カスタムクラウドの特徴
◆月額固定費
→ 価格体系は、3つ（強火、中火、弱火）
→ 成果物を、いつまでに納品、という契約ではない。
→ いつでも、要求を変更することができる。
◆クラウド環境で提供
◆プログラマのチームは固定する
◆技術 → Agile、RubyOnRails、AmazonWebServices
◆効果
→ 固定費で開発を依頼するので、ユーザが真剣に
考えないといけない。
→ 今一番必要な機能は？
→ この仕様でいいのか？
Slide No. 54

55. モデリングから始める
◆モデリングの進め
ユーザ企業が、UMLやERを書く。
→ シンタックスはすぐに習得できる。
→ 意味のあるものを書くのは、頭を使う。
→ そもそも、ユーザ企業でしか書けない。
何を書くの？
→ 会社を書くことができます。
→ だれよりも、会社に詳しくなります。
Slide No. 55

56. 将来像
◆従来型のSIベンダー、受託開発モデルの崩壊
→ ユーザ企業が変われば、ベンダーも
変わる。
→ 変わることは、怖くない。
→ 変わることは、成長そのもの。
◆ユーザ企業の情報システム部門も消滅
→ 現場と一体化したIT
→ いわば、情シス部門の拡散的消滅
Slide No. 56

57. 日本発イノベーション
◆日本発イノベーションを起こすには？
→ 失敗すること。
→ 失敗を認めること。
→ 日本には、失敗を、穢れと感じる文化
がある・・・
→ 失敗を許容すること。
→ 横断的知識の練り合わせ
→ 縦割り組織では厳しい
◆もの作り→ルール作り
→ プラットフォーム争奪戦
→ 日本は、もの作りは上手なのに・・・
Slide No. 57

58. 以上です｡
ご清聴ありがとうございました
Slide No. 58