Más contenido relacionado
La actualidad más candente (20)
Similar a 第1回SIA研究会(例会)プレゼン資料 (20)
第1回SIA研究会(例会)プレゼン資料
- 6. ユーザ企業の丸投げ
◆また・・・
変化することをしなかった。
→ 90年代後半のアウトソースブーム(?)は、
その当時の最善であった。
→ 常に、時代を見据えて変化することが
できなかった。
→ これが日本人の苦手なところか?
何故、変化を嫌う?
→ ソフトウェアが、ソフトでなかった。
→ 安定を望む。 しかし、安定って何?
Slide No. 6
- 7. ユーザ企業の丸投げ
◆安定とは?
→ 高速で回転する独楽
→ 常に変化を続けること
→ 常に、外からエネルギーが与えられること
→ 止まっている独楽を安定しているとは言わない
→ 頻繁にバージョンアップをしたり、
→ 業者を変更したり、
→ 安定すること=変化すること
Slide No. 7
- 13. 高コスト化
◆巨大なコンプレックスである情報システム。
→ 様々な専門家が必要
→ その専門家をマネージする人
◆プロジェクト会議は、20~30人
→ そして、そこにはプログラマはいない。
→ プロマネといわれる、調整者。
→ プロマネの人件費、一人一時間3万円
→ プロジェクト会議、1回100万円也
→ これも高コスト化の一因
Slide No. 13
- 16. ユーザ主導のコンペ
◆コンペを行う
生産性、コストで勝負すればよい。
→ 自由経済の原理が働く。
→ SIベンダーが、高生産性ツール、方法論を
積極的に使う可能性がある。
◆ベンダーの言い分
リスクを見込んで、見積書を作る。
しかし、コンペが進むと、それが徐々に減っていく。
→ ユーザ企業がリスクを保持しないと、ベンダーも
疲弊するだけ。
Slide No. 16
- 23. “ソフト”ウェア
◆ソフト=柔らかい
→ 今の“ソフト”ウェアは、柔らかくて、簡単に作り
変えられて、簡単にバージョンアップできて・・・
という存在だと感じますか?
→ 特にパッケージソフト
→ 数行の修正で100万円とか
→ “ハード”ウェアに近い
◆ハードウェアが柔らかい時代
→ 仮想化、クラウド
→ スケールアウトも簡単
Slide No. 23
- 27. 無駄といえば・・・
◆中国の事例でも・・・
→ 契約違反だ、そうでない、
→ 裁判したり、
→ 今後は、リスクを上乗せしておこう
→ こんなの、無駄な作業なだけ。
→ 価値を生む作業ではない。
◆日本でも・・・
→ 不透明なコスト構造
→ 値引で半額近くになったりする
→ 値引合戦のコンペ → 同じように、無駄。
Slide No. 27
- 29. とあるクラウドビジネス業者
◆クラウドサービスなのに・・・
→ 値引で半額以下に・・・
→ 初期費用が膨大
→ 月にどのくらいの費用がかかるか、不透明
◆最短で、5営業日でサービスイン!
→ 値引交渉に、1ヶ月とかかかる。
→ 従来型のビジネスのイナーシャ。
→ サービスというものの、本質を経営者が
わかっていない。
Slide No. 29
- 31. 当社の事例
◆前提
→ 自社の内製で実施
→ モデリング
→ プログラミング
→ 技術コンサルを採用
→ 成果責任なし
→ 瑕疵責任なし
→ リスクは、当社で保有する
Slide No. 31
- 33. 当社の事例
◆技術の獲得
優れたエンジニアとは?
→ 自ら進んで、技術を学び成長できる人間
そのような人材になるには?
→ 外に出て、優秀なエンジニアに会う。
→ 刺激を受け、自分とのギャップを感じる。
→ ギャップに対するフラストレーションが生じる。
→ これが、自ら学ぶ原動力になる。
Slide No. 33
- 34. 当社の事例
◆技術の獲得
エンジニアリングに注力
→ 技術は短く、原理は長い。
具体的には
→ モデリング
→ オブジェクト指向モデリング、UML
→ データモデリング
→ モデリングをやる意味
→ モデリングは、思考そのもの
SIベンダーも、エンジニアリング音痴が多い
→ 目利きになれる。
Slide No. 34
- 35. 当社の事例
◆技術の獲得
どのくらいの、時間とお金がかかるか?
→ 約3 年
→ フィージビリティ兼、技術習得で実施
→ お金は・・・かかります。
どこから予算を出したか?
→ いままで、ベンダーにジャブジャブ払っていた
お金の一部をまわす。
モチベーションが大事
→ 情報システム部員の気力、喜び、楽しさ。
Slide No. 35
- 36. 人材育成の原動力
◆仕事の楽しさ → 原動力
今、仕事がつまらないですか?
→ 昔は仕事が楽しかった・・・という話を良く聞く。
なぜつまらない?
→ 自分の世界が経験とともに拡大していくことを
実感できない。
今、仕事で求められていること
→ コスト削減、効率化・・・
→ 目標、夢、希望が無くなってきている?
人を育てることは、コストではなく、投資
→ 投資の気持ちで社外での活動を推進せよ
Slide No. 36
- 38. Agile開発
◆用語
→ 朝会
→ 毎日行う。30分程度。
→ 朝に、本日の仕事の確認、問題の共有。
→ チケット
→ 一つの仕事
→ 行うことが明確であるもの
→ 1枚のチケットは、約2~3時間が目安
◆チケットドリブン
→ これで、初めて、ソフトウェア開発の、
正しスケジューリングができる。
Slide No. 38
- 39. Agile開発
一枚のチケット→A5サイズ
余白(磁石エリア)
チケットのタイトル
担当者A 予想時間 実績時間
2h 3h
担当者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
- 46. モデリング
◆ ERモデル これがモデル。
エクセルの表で、データベースの
テーブル定義書を作るエンジニアはダメ。
Slide No. 46
- 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
- 54. カスタムクラウドの特徴
◆月額固定費
→ 価格体系は、3つ(強火、中火、弱火)
→ 成果物を、いつまでに納品、という契約ではない。
→ いつでも、要求を変更することができる。
◆クラウド環境で提供
◆プログラマのチームは固定する
◆技術 → Agile、RubyOnRails、AmazonWebServices
◆効果
→ 固定費で開発を依頼するので、ユーザが真剣に
考えないといけない。
→ 今一番必要な機能は?
→ この仕様でいいのか?
Slide No. 54
- 56. 将来像
◆従来型のSIベンダー、受託開発モデルの崩壊
→ ユーザ企業が変われば、ベンダーも
変わる。
→ 変わることは、怖くない。
→ 変わることは、成長そのもの。
◆ユーザ企業の情報システム部門も消滅
→ 現場と一体化したIT
→ いわば、情シス部門の拡散的消滅
Slide No. 56
- 57. 日本発イノベーション
◆日本発イノベーションを起こすには?
→ 失敗すること。
→ 失敗を認めること。
→ 日本には、失敗を、穢れと感じる文化
がある・・・
→ 失敗を許容すること。
→ 横断的知識の練り合わせ
→ 縦割り組織では厳しい
◆もの作り→ルール作り
→ プラットフォーム争奪戦
→ 日本は、もの作りは上手なのに・・・
Slide No. 57