Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie 第1回SIA研究会（例会）プレゼン資料
Ähnlich wie 第1回SIA研究会（例会）プレゼン資料 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
第1回SIA研究会（例会）プレゼン資料
- 1. 丸投げ&ロックイン構造 からの脱却 ゼリア新薬工業 熊野 2011/4/25 Slide No. 1
- 2. 全体の流れ 前半 丸投げ、ロックインなどの、問題・事例・ 考察など。 後半 では、どうすればいいか？ 当社の事例も含めて考えてみます。 Slide No. 2
- 3. ユーザ企業の丸投げ ◆ユーザ企業の丸投げって？ → 自社で考えなければならないことを、ベンダーに 任せてしまうこと。 ◆結果どうなってしまう？ → 自分で考えることができなくなる。 → 考えなくてもやってくれるから。 → ベンダーとユーザ間のメッセンジャー役 → お金だけは、大量に出て行く。 Slide No. 3
- 4. ユーザ企業の丸投げ ◆思考停止 → 要求を自分の言葉で語ることができない。 → 自社の業務フローをまともに書けない。 (痺れを切らした)ベンダーが、“いくつか案を提示” 「この3つの案から、選んでください」 丸投げすると、こんな感じになります。 Slide No. 4
- 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
- 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