原発の新設、検討するみたいです

さっき、節電の話で「原発が動きそうにもないので」って書いたら、
「みてたんかい！」というタイミングで、こんなニュースが・・・

原発の新設、エネルギー情勢踏まえ腰を据えて検討＝首相
http://headlines.yahoo.co.jp/hl?a=20130131-00000067-reut-bus_all


「稼動」じゃないですよ「新設」するんだそうです。
・・・できるんでしょうか？
・・・「稼動」ですら、難しいと思うのですが・・・

また、夏、節電らしいんですけど・・・

結局、電気って、供給量、増えそうもないですよね。
原発が動きそうにもないので・・・
一方、消費量は、増えていくだろう・・・
ってすると、自衛して、
自分で使いたい電力は自家発電とかするしか、
道はないのかもしれない。
とくに、大企業やデータセンターなどでは・・・


＜節電＞今夏の要請、政府が検討　再稼働困難と判断
http://headlines.yahoo.co.jp/hl?a=20130131-00000006-mai-bus_all

国会図書館の蔵書、無料配信へ

　大日本印刷側は電子書籍ファイルを作り、紀伊国屋書店が自社の電子書籍ストア上で無料で一般に配信。利用者は電子書籍閲覧ソフトを使い、紙の本のような感覚でページをめくれる。一部の書籍は全文対象の検索もできる予定だ。


ってことらしいけど、どういう本が対象になるんでしょうね。

国会図書館の蔵書、無料配信へ　企業と提携、電子書籍化
http://headlines.yahoo.co.jp/hl?a=20130129-00000018-asahi-ent

（このエントリ内の太字は、上記サイトより引用）

ＳＤＮ／Openflowとビッグデータ分析で、運用自動化が最近の話題らしい

昨日、

Enterprise Cloud Management Forum
ネットワーク仮想化が切り開くクラウドの未来
～OpenFlow／SDNの最新情報をキャッチアップしよう～

に行ってきた！
その内容をメモメモ

---

■SDN／OpenFlowが創るネットワーキングの将来
IBM

・OpenFlow　Networkingの意義

SDNという言葉のブームの中で
　よくあるうわさ
　　OpenFlowは通過点？役割終わった？
　どうして？
　　　SDNはV(ベンダー）DNだ！
　　　キラーアプリがない
　　　技術的に大変そう
　　　商用目的では課題も多い？
　　　固有の独自価値の正しい理解！
　意義を考える

OpenFlowのおさらい
　CD分離
　　　経路・管理をコントローラーに
　　　標準化されたプロトコル
　集中制御
　　　いままでのをゼロクリア
　　　パラメーターの組み合わせ

意義
　管理の側面：
　　　管理手法の標準化－抽象化、プール管理
　　　管理の集約、一元化：グローバルビュー
　　　トラフィックごとの動的で柔軟な制御
　　　プログラム化・自動化
　OpenFlowでないとできないこと
　　　ネットワーク：トラフィックの質によるコネクション
　　　　→ネットワークサービスの差別化

・OpenFlow NetworkingとOverlayソリューションの必要性
運用の課題
　　可用性の問題
　　スケーラビリティ（フローテーブルサイズ）
　　パフォーマンス（問い合わせに対して）
　　　　→冗長性、相互連携

　　実績：利用できるソリューションとか・・

Openflow　ネットワーキング適用上のガイドライン
　L2,L3の全面置換では、まだない
　有効なところ：動的最適化、プール管理(クラウド）

ネットワークの様態
　島みたいに浮かんでいる
　　→既存のものとの相互接続
　　　　→オーバーレイ

分散型オーバーレイソリューション
　IP網の有効活用
　延伸できる、マルチテナントのソリューション
　　→オーバーレイ型ネットワーク
　　→エコシステムとして稼動

オーバーレイ技術
　データーセンターの巨大化
　サーバの動的仮想化：ポートプロファイルの移動
　　　IEEE802.10ｂｇEVB
　複数の仮想ネットワーク、

SDN／Openflowが創るネットワーキング
データセンター
　ノースサウス型トラフィックから
　イーストウエスト型トラフィックに
　　　オーバーレイ型
サービスとしてのネットワーク
　　管理や走査の容易性
　　ビジネス価値のネットワーキング実装への体現化
　　ソリューション選択上の容易性
　　高可用性
　　高スケーラビリティ
　　高パフォーマンス
　→SDNの要件
何が必要？
　標準化

　　ネットワーク
　　　　ノースバンドAPI
　　コントローラー
　　　　サウスバンドAPI
　　デバイス

　イーストウェストAPIの統一
　　他社との連携？

　サービスとのAPI

異なる管理体系
　異なるネットワークモデルの統合
　単一のインターフェースで抽象化
　　→エコシステム

IBMとしては
　SDNコントローラ－リリース
　　　ネイティブスイッチ
　　　オーバーレイ
　　　OpenFlow
　　→抽象化
　　→フレームワークとして提供

ソリューションか
　ONF：２０１２年１２月８７社参加
　　　→ビジョンを定義、エコシステム化
　実績あるオープンソース資産
　商用のコントローラー
　テクニカル・アドバイザリー・グループの結集
　　ソリューションを具体的資産として管理

・まとめ
　OpenFlow　Networkingは、他にはない固有の価値がある
　SDNは、Openflowネットワークとオーバーレイネットワークの２本柱
　　　→ハイブリッド
　IBMは、標準化とソリューションの共有化を目指す

---

■SDNへの現実的な進化の方法とは？
～クラウドに最適化されたネットワーキングを
実現するために今はじめられること～
ブロケード

会社紹介
　データセンター・ネットワークでNo2

SDNが求められる背景
　コンピューティングを支えるインフラとしてのネットワーク
　投資対効果、投資リスク軽減
　
　ビジネスシステムを、より沢山早く動的に→SDN
　　ラピッドデプロイ＋運用

データセンターインフラ構築における重要事項
　　管理・運用のシンプルさ
　　拡張性(リミットレス）

今までのレイや２ネットワーク環境
　　アクティブスタンバイ、ループしないように
　　　→むだがある
　　ネットワークの設定が多い：
　　　　プロフェッショナルサービス、保守サービス
　　　　入れてつなぐだけにしたい。自動で
　　プロビジョニングするのに、時間かかる

ネットワークをシンプルに
　　オペレーションフリーなネットワーク
　　　→完全自動化：SDN

オペレーションフリーを実現する
　データセンターネットワーク

　　イーサネットファブリック
　　　VCSファブリック
　　　複数のスイッチを任意の結び方でOK！
　　　　ID振れば、ループでもOK、自動的に
　　いままでのスイッチとかｖLAG
　　　　他社のものでもOK
　　仮想マシンの移動設定

解決すべき課題は

　ファブリックが解決
　　　フラットネットワーク／スケーラビリティ
　　　仮想化、クラウド、LAN／SAN連携

DCサービス管理フレームワーク
　　TMNによるアナロジー

ネットワークマネジメント
エレメントマネージメント
ネットワークエレメントマネージメント

OpenStackの場合
Computeファブリック
　実現すると・・
　　OpenStuck　Vセンターからファブリックでネットワーク設定
　　　→自動化される
　　　　ループの心配ない
　ミャンマーでIT管理するとしたら：自動化したほうが・・・

SDNの効果
　　ムダの削除
　　スモールスタート（いままでのはそのままでもいい）

イーサネットファブリックの国内時r亭
　　１５０社以上

Brocade One
　シンプルさ
　投資保護
　無停止

ブロケードのビジョンとSDN

究極的なITサービス
　サービスを動的（ダイナミックインサーション）に
　それだけじゃない！
　　自動的に運用する→コントローラーに
　　PDCAを自動的に

DC内情報のDIK階層モデルとビッグデータ
　　Data
　　　・個別の要素からのデータ群
　　Infomation

　　Knowlage

個別情報のコンテクスト化
　　Data
　　　全イベント、性能データ
　　Information
　　　分析
　　Knowlage
　　　QOS担当者などに

今
　　モニター
　　　→自動的に設定する方法がなかった

SDDC（ソフトウェア・デファインド・データセンター）
　　自動判別と自動チューニング
　　ネットワークアナリティクス自信が価値

目指す方向
　　複数台のバーチャルマシン群を統合的に：SDDC
　　　LAN,SAN

運用のオートメーション
　　リアルタイムのビッグデータ解析

まとめ
　SDNへの現実的な進化の方法
　　　VCSファブリック　日本が一番高い
　　　　　＋
　　　　SDN（ファブリックがOpenFlowしゃべってもいい）

　　オペレーションフリーへ

---

■Openflow／SDNに対する通信事業者としての期待

取り組み事例
（１）商用サービス

　　BizホスティングEnterprise Cloud

　　　SDN（Openflow)
　　グローバルデータセンター

（１）アプライアンス機能（DC内）
　OpenFlowを使うことで、VM単位でアプライアンス経路を制御
　　　→オンデマンドでできる
　　　Openflowにプラス何かしないといけない

（２）データセンターの間をつなぐ
　OpenFlowにより、グローバルデータセンター間でのリソース連携を実現
　データ量にあわせて、リアルタイムに回線帯域をコントロール制御
　　　→QoSにOpenFlow

カスタマポータルのデモ

いま８カ国９拠点

コントローラー：拠点ごとと、全世界で使い分け
　　データセンター間：全世界
　　DC内：拠点ごと

なぜ、Openflow／SDNを使ったのか
　スケーラびりティーの問題などなど

　解
　　・インターネットの拡張
　　・Openflow

NECのpflowを使っている

メリット
　ループフリー、設計容易に
　自動化
　VLAN４０００制限の壁を越えた
　　　→期待通り

OpenFlowの仕様不足→NECのpflowは対応
　なので、問題ないけど、
　ベンダーフリーという点は・・・

課題解決に向けて、独自の技術検討

OpeenFlowコントローラー開発
　コントローラーを自社でもつ
　　コントローラー：オープンソースのRyuを採用
　　びっぐぽすと？

ネットワーク仮想化
　　VPNエッジ
　　境界自動化

BGP　Free　Edge
　外部からIP-VPNに見せる

クラウドDC-VPNの境界
　設定を自動化→人為故障を削減

OAM（保守・管理機能）まだ標準化されていない
　必要な機能
　　　故障検出
　　　通知
　　　自動切換え・・・

Pingの機能開発

Openflow／SDN普及に向けた取り組み

ONFについて・体制図

ONF 2nd PlugFest

Openflow／SDNへの期待と課題
　高速・大容量化：ハードウェアの進化
　スピード、柔軟性：ソフト→SDN

期待
　　Time to Marketの短縮
　　サービスの差別化
　　投資・運用コストの削減

課題
　　ハードウェアSW　V1.0のサポート
　　ソフトウェアSW　パケット転送性能に限界

バージョン
　　１．３でほぼ落ち着いてきた？

今後
　　チップベンダー
　　ODMベンダー
　　WANへの適用に興味

　　新技術であることを理解したうえで
　　　技術的なフィー時ビリティの確認を行う段階

まとめ
　さらなるフレキシブル
　　１）適用領域の拡大
　　　　トランスポートNW
　　２）スケーラビリティの拡大
　　３）OpenFlow１．２／１．。３の実装
　　４）マルチベンダーの相互接続

---

■仮想化・クラウド環境下におけるパフォーマンス最適化テクノロジー

リバーベッド

・ITインフラのパフォーマンス企業
・製品
　　WAN高速化など
　　　Riverbed　７０％の地位

なぜ、パフォーマンスが必要か
　スピード
　ROI
　コントロール

課題に対して
　　ユーザーフローの高速化
　　データセンターの円滑化
　　高速なビジネス展開

グローバル電力の１．５％がデータセンターが使ってる
安いとことにデータセンター；距離遅延
インターネットSYNを送ってAckが返ってくるまでまつ
　→１００M送っても、１００Mにならない

重複排除
　データストリームライニング
　トランスポートストリームライニング
　アプリケーションストリームライニング（CIFS)
　VDIの高速化
　SaaSサービスの高速化：アカマイとのアライアンス

---

このほかにも、金沢大学のOpenflowを入れた事例紹介や、
その他の会社さんのお話もあったのだけれど、省略。

ブロケードの

ＳＤＮとビッグデータ分析で、オペレーションフリー

っていうのが、今後のトレンドなんでしょうかね。

ＳＤＮというよりは、マルチベンダー対応のOpenflowをしゃべって、
コントローラーがリアルタイムでデータ収集、
その結果をOpenflowコントローラーに伝えて、自動制御
あーんど、オペレーターにも伝える

その結果、基本的には、線をつなげば、設定なしに通信でき
（ブロケードでは、この程度までは、既に達成しているらしい）
遠隔で集中監視、操作ができるという感じですかね・・・

オープンソースのOpenflow コントローラー Ryu

ほ～、
Openflowのコントローラーまでも、オープンソースとして、
無料で手に入る時代になったんですね！

Ｒｙｕというのがあるそうです。

くわしくは

Ryu
http://osrg.github.com/ryu/


Openstack上でうごくみたい。

Githubは、

https://github.com/osrg/ryu

で、ここにbinとか、いろいろある
・・けど、インストールは、http://osrg.github.com/ryu/
のＱｕｉｃｋ　Ｓｔａｒｔにあるけど、

　　pip install ryu

でいいみたいよ。

リショアリングが、日経情報ストラテジーにも出ているけど、爆速に触れてないのは残念！

前に

中国から国内へ　理由：安いから　- By アメリカ
http://blog.goo.ne.jp/xmldtp/e/df31f149fc68c8bf26f912955ca802a2

というエントリを書いて、そこで、「リショアリング」という概念について
説明したけど、
日経情報ストラテジー２０１３年３月号の１９ページ、３分間キーワードの上段
にも、出てますね。ＢＰＯリショアリングとして。

ＢＰＯ（ビジネス・プロセス・アウトソーシング）という言葉がついてますが、
話の本題は、リショア、つまり中国・インドから、国内に開発、製造を戻す
ということです。

ただし、理由の説明で、一番大事なことが抜けていると思います。
上記のエントリで参照している、ＮＹの遊び方の記事の中には書いて
あるんだけど・・・

一番大事なのは、スピードだと思います。
外国に出すと、コミュニケーションや
ものの移動のために、時間が取られる。思いのほか・・・

これが、ビジネスチャンスを失わせ、このチャンスロスによる、逸失利益（＝機会損失）
のほうが、オフショアによるコスト削減金額よりも大きいことから、
リショアの波が生まれているんだと思います。

要するに、コスト削減よりも、爆速開発による、売上追求に時代が変わりつつあると・・・

Lean Startup(リーンスタートアップ）

リーンカンファレンス２０１３に行ってきた！
http://blog.goo.ne.jp/xmldtp/e/8dcad73ae8fc00d76fdcb6b15281fc69

のつづき。招待講演の

アイデアを事業に進化させる起業のサイエンス
Lean Startup

について。

実は、「リーンカンファレンス２０１３に行ってきた！」の後、
この話の前に、教育の話があったのだけど、
あんまり、Leanに関係ないので、今回は省略します。

---

■アイデアを事業に進化させる起業のサイエンス

ベンチャー；秩序ない。はじめると決めたらはじめる
　→Leanで成功する可能性のあるやつが出てきた

何を作ればいいか：予知できない→分かる人はいない

Leanの起源
２００２　スティーブ　ブランク
　大学の講義テキスト
　　The Four Steps to the epiphamy

　　　↓メンター　　　　　imvu（いみゅう）

　エリックリース

２００８年にブログ　Startup Lessons Learned
　　そこの記事にLean Startupが出てくる

２０１１年　The Lean Startupという本を出す


日本
　　The Four Steps to the epiphamy
　　　　→アントレプレナーの教科書

２０１２　リーンスタートアップの本、日経ＢＰから

日本の起業
　まず、事業計画書→失敗する典型的パターン

　そうではなく
　　喜んでくれるのは誰なんだから考える
　　Plan→product
　　　　設計図からは見えないReality

実験に落としていく；ライトウェイト
　　→学びを得る

フィードバックループ

　　　　　ＩＤＥＡＳ

ＬＥＡＲＮ　　　　　ＢＵＩＬＤ


ＤＡＴＡ　　　　　　ＰＲＯＤＵＣＴ

　　　　ＭＥＳＵＲＥ

製品というより実験
ＭＶＰ　Minimum viable product

ピボット；方向転換

　　技術を軸にピボット
　　　マーケットはどこ？
　　ユーザーサイドの課題
　　　はまるソリューションは？

　　軸をどこにおき、マーケットを探すのか、組織を捜すのか

何を学ぶんだっけ？
　　検証を繰り返していく
　　イノベーションは、積み重ねしかない
　　事業は一発勝負ではない

会社
　　　Ｍｏｔｉｖａｔｉｏｎ；大事
　　　Ｓｕｐｐｏｒｔ
　　　Ｍｏｎｅｙ

起業はアートではなく、サイエンスマネジメント
　　学べます。実践できます
　　アイデア一発勝負はギャンブル

　新規事業はリスクだらけ
　でも、得意分野もリスクある
　　　過去の成功パターン
　　　　　↓
　　　マニュアル・評価基準
　　　　　↓
　　　常識化；リスク高い
　　例）コジマ　成功パターンをひきづって、立ち直りが遅れた
　　　　コダック　固執
　　　　　→「脱皮しない蛇は死ぬ」

決めた計画の実行より、想定外の変化への対応力が必要
　　→変化につよい
　　→アイデアを試すのはただ。


ゲームチェンジャー；どこからとも無く出るけど、
　　出現兆候；→カテゴリー名が変わるとき
　　　例）　ケータイ→スマホ
　　　　　　自動車→ＥＶ
　　カテゴリー名が変わるとき、
　　　　後続製品を生み出す持続的イノベーションではなく
　　　　破壊的イノベーションが起きている

Lean 7 wastes
　　無駄の見極めこそが、リーンの本質

４つのポイント
　　小さくはじめる
　　　　バッチサイズが大きくないか
　　繰り返す
　　　　一発勝負しない
　　仮説からはじめる
　　　　タスクがんとチャートからはじめない
　　　　Ｔｏｄｏからはじめる
　　常識をかえる

新規事業を立ち上げろ
　　＜問題点＞
　　　　新しすぎて理解できない
　　　　報告書を要求
　　　　リスクを回避すると賞賛される

たった1つのツイートが世界のニュースに・・・Googleの戦略?!

ニューヨークの地下鉄3番線車内で、偶然、撮影されたグーグル・メガネ（Google Glass）をかけたセルゲイ・ブリン（Sergey Brin）さん。


彼とお話したよ！っていうツイートが世界中に流れまわって、ニュースになっているらしい。
おおお～
Ｇｏｏｇｌｅめがねは、やっぱり、話題なんですかね・・・

でも・・・偶然なんでしょうか（＾＾；）

たった1つのツイートが世界のニュースに・・・Googleの戦略?!
http://nyliberty.exblog.jp/19892079/

(太字は上記サイトからの引用）

リーンカンファレンス２０１３に行ってきた！

リーンカンファレンス２０１３に行ってきた。
そのときのメモメモ　前半

---

■アジャイルからリーンそしてリーンスタートアップに
　　　　平鍋さん

ソフトのひと：圧倒的に多い
今日の人の紹介
　バリューストリーム

作ったものがお客さんに届くのか

なぜ今アジャイルか

ミッション・リスク分割型ビジネスと
　ウォーターフォール型開発（従来型）
　　→永和システムでもまだ半分ウォーターフォール

　　　　市場⇔　　ビジネス　　⇔IT
　（ユーザー⇔情報システム部門⇔ベンダー）

従来型の問題＝要求の劣化
　　Stundishのデータ
　　６０％くらい使われない
　　
ミッションリスク共有型ビジネスと
　アジャイル型開発
　　市場にミートする製品

短いサイクル（２週間とか）でテストまでやってしまう

分割の仕方
　ホールケーキでなくショートケーキを作る
　　ソフトウェア工学のおかげ
　　　IDE：リファクタリング
　　　クラウド・開発環境
　　　→在庫もたなくていいけど、むずかしい
　Webを使っている場合、ケータイアプリでは普通にできる
　契約がむずかし

スクラム
　製品バックログ：上から並んでいること
　１週間で作れるものを抜き出す

タスクカンバン
　Todo
　Done
　成果物→ハードディスクにある
　　　　→とまっているところ指がさせない
　　　　→させるようにする

アジャイルの現在位置
　　XP,　　　　　　　　→Agile→Lean
　　野中・竹内、Scurum
　Leanの言葉でアジャイルを語る
　TPS、デミングの思想をいれる：Lean

　いま
　　大規模
　　組織改革
　　Lean／Agile
　　Agile／UX

　　kanban
　　Lean Startup：少量の投資で

スクラム
　　The new new product development game
ハーバードビジネスレビュー、野中先生が言っている

Lean　Startup
　　製品バックログはどこからきて、どこへいくのか
　　　→LeanStartupの入り口
　　　　　顧客開発：作らなくてもいいから、どうみつけるか

アジャイルとスクラムの本

---

■リーンが製品開発を革新する

リーン、TOCとのかかわり

リーンの系譜
　リーン：MITのベンチマーキング
　　　日本の生産圧倒的高い

　ウォーマック：リーンシンキング

　ザ・トヨタウェイ

別の系譜
　トヨタ生産方式

もうひとつの流れ（ソフト）
　リーンソフトウェア開発
　KANBAN
　リーンスタートアップ

共通点
　　小さな「仮説→検証」サイクルを繰り返す
　　安価で早い知識獲得方法
　　　　組み立てラインで普及：スバル３６０

日本の製造業が生き残るには
　　ダントツ商品
　　　→顧客価値の理解
　　　　→顧客価値実現のための技術的知識
　　　　　→日本型イノベーション：リーン製品開発

リーン製品開発の発見
　アレン・フォード博士
　　セットベース開発
　　　トヨタだけが特別な設計
　２００４年に博士がなくなる
　　勢い弱まる：リーン生産より小さい
　成功事例
　　ハーレーダビッドソン

リーン製品開発
　　　　　　　　セットベース開発
　　　　　　　　　　　　|
　チーフエンジニア制度　-------　リズム・流れ
　---------------------------------------------------
　　　A3プロセス（A3：１枚にすべてを書く）

顧客価値を理解していないと
　　→恐怖心から競合製品に入っている機能を全部入れる
　使いにくい
　高すぎる
　不要な機能が入っている

顧客価値を理解していれば
・iPhone
　　楽しい
　　使いやすい
　　感動する

Dyson
　　美しい
　　吸引力落ちない

OXOけいりょうカップ
　　上からメモリ見える

これらの製品はいずれも顧客に何がほしいと聞いても出てこなかっただろう

チーフエンジニア
・起業家的システム設計者
　　顧客価値を深く理解

顧客価値を深く理解する方法
　方法
　　体験法（自分が体験する）
　　観察法
　　　主婦の調理の様子を観察
　　面接法
　　　どんな問題を解決したいか
　　　いつ幸せを感じるかを聞き出す
　注意点
　　細かいことを見逃さない
　　旺盛な好奇心を持つ
　　脱思い込み思想
　　顧客の身になって考える（自己移入）
　　常に仮説を立てる
　　顧客の感情上のマイナスやプラスに敏感
　　　マイナス：不快感、不満、問題
　　　プラス　：高揚感、幸福感

セットベース開発

ライト兄弟の驚くべき成果
　　サミュエル・ラングリー　１４年間：１度も成功せず
　　ライト兄弟：趣味で４年で、最初の設計で（２回目の実験）で成功
　アマチュア発明家がなぜ？

知識を獲得・記録してから設計
　　ライト兄弟：死にたくなかった
　　　→革新を盛ってから設計
　　風洞実験：数表、グラフに
　　設計
　航空工学の発明

間違いだらけの製品開発改善
　昔：構想設計
　　競争激化→効率化、LT短縮：CAD、フェースゲート：構想設計に適していない
　今：詳細設計

　構想設計段階を軽視、手戻り増える

ポイントベース開発とセットベース開発
ポイントベース
　希望的観測によるキメうち

セットベース開発
　代替案を考えていく。急がば回れ

セットベース開発の効果
・イノベーションを系統的に生み出す
・詳細設計期間・コスト激減
・開発効率が向上

セットベース開発に必要な知識
　　トレードオフ曲線
　　因果関係図

設計空間の領域を序所に狭める

製品開発での最大のムダは
　　開発中に獲得した知識を使い捨てにすること
　　図面以外の知識は暗黙知識化

リーンj開発学習システム
・知識ギャップ発見
・知識獲得
・文書化

・知識整理

・再利用のために一般化、承認

A3で知識ベースを作る

知識バリューストリームと製品バリューストリーム


安価に知識を獲得する
　　安価、部分的、低精度
　　スケッチ、モックアップ
　　　↓
　　シミュレーション
　　ラピッドプロトタイプ
　　部分試作品
　　バラックセット
　　　↓
　　技術試作品
　　量産試作品

流れ、リズム、プル
　　インテグレーション・イベント
　　代替案絞込、次段階学習計画
　計画スパン：次のインテグレーションイベントまでしか立てない　
　遅れが出たら、上司がサポート

リーン製品開発でダントツクラブを開発したピン
　　マーケティングギミック

因果関係図

トレードオフ曲線を利用してダントツグラフ

まとめ
・ダントツ商品を確実に開発する鍵は
　　顧客価値知識
　　技術知識
リーン製品開発の効果
　　チーフエンジニア
　　　顧客価値知識獲得
　　セットベース開発
　　　技術知識獲得・再利用


顧客価値知識獲得
　　　　｜
　　　　｜
　　　　｜
---------------------------
　　　　｜　　技術知識獲得
知識の　｜
再利用　｜

---

■リーンTOCによるヒット商品開発　

制約条件の理論
CCPM

TOC（成約条件の理論）の発展の歴史
・ザ・ゴール　日本２００１年　アメリカ1983年

ゴールドラット
　　市場に対して、社内に対してどのように合意を得るか
　　クリティカルチェーンマネジメント

リーンとTOC
　ゴールドラット：巨人の肩の上に立って　（ダイアモンド）
　　→ニュートンの言葉
　　２人：ヘンリーフォード、おおのたいち
　とよたTOCとは異なるが
根本同じ(共通）
　　ムラをなくす
　　過剰生産を防ぐ
　　全体最適
　　継続的改善
TOC（制約条件の理論）とは
　鎖の強度：ゴール
　最も弱い鎖：制約条件
　　制約条件を徹底的に管理する
計画のリスク：DBR／CCPM／DBM
合意形成のリスク：TOC執行プロセス

製造：DBR関係　たくさんある
開発：CCPM関係　（クリティカルチェーン）多く発表

CCPM活用の留意点
・売れない商品をCCPMを活用して早く開発しても意味がない
・FullKit：準備（要求・仕様の確定）ができないプロジェクトに
　　　　　　CCPMを適用しても成功させることが難しい
　CCPMは実行時間のばらつきをヘッジする方法
　フルキットになってから実行
　　　アジャイル、リーンでできてから

売れないとは：製品ライフサイクル
　　よい製品だが売りにくい、ほとんどの製品は消滅していく
　　　　キャズム
　　　　アントレプレナーの教科書：キャズム前（ジャングル）
　　商品のメリットについて合意形成するための営業マンによる提案営業

営業の現場
　　お客さんは強い疑いを持っており提案を簡単には信用しない
　　　カタログX
　　　御用聞き
　　　　買い手の立場に立って問題を説明し、信頼を取り付けてから提案する
　　　
売り方を開発する
　　断れないほど魅力的な提案＝マフィアオファー

抵抗の６段階に対するマフィアオファーシート

１．問題に合意する
２．解決の方向性に合意
３．われわれの製品で解決できる
４．懸念事項
５．上司、関係者にも説明
６．言い表せない恐怖

A3一枚にまとめる
　営業・商品企画・開発のいろいろな観点から

　　　特徴的な機能３つをあげる
　　　　　２０もあげちゃX
　　　お客様にどういう良い状態を与えるか
　　　これをひっくり返した悪い状態を作る

企業全体にどういう影響を与えるか合意
　　株主
　　従業員
　　お客様
　重大問題

仮説→検証する（すぐ行く）
　　反応をまとめる
　　　１：その問題はない
　　　２：問題の存在不明
　　　３：問題に対して受動的
　　　４：能動的
　　　５：

仮説検証を繰り返し、売り方を開発させる

マフィアオファーシート作成での学びを次期開発のインプットとする
１．特徴的機能は競合に対してダントツか
２．本当に重要な問題を解決できているか
３．懸念事項をなくす

BufferManagementのブログにいろいろ書いている

---

■VALUE STREAM & KANBAN FOR BUSINESS AGILITY


ビジネス価値を形にすることに、ソフトウェア開発は
どのように貢献するか
　　→Lean Agile

Agile２０１２

このセッションが扱う課題
　　企画と開発の分断
　　　　企画が開発にわたったら、あとはおまかせ
　　　　来た玉を打つ的に、要求を実装する

取り上げるセッション
　　２つバリューストリーム（あらん）
　　　　かんばん

あらんのはなし
　　アジャイルジャパン２０１０で話している
　　　　ソフトウェアバリューストリーム

バリューストリーム
　　お客様からはじまって、
　　　要求が、ビジネス、開発をとおり
　　　　お客様にもどろまでの流れ

　ビジネスディスカバリー
　　優先順位
　　計画作り（MMFユーザーにとって価値がある必要最小限の要求）
　　開発に引き渡す準備
　　開発チームに渡せる状態
　ビジネスデリバリー
　　出荷可能な状態
　
各ステップをアクションに落とし込む
　　どこに時間をかけるか

流れを滞らせているのはなにか
　　多くのことを同時に仕掛ける
　　ほかとの待ち合わせ
　　遅れのコストを評価していない
　　対象大きすぎ／複雑すぎ
　→特定の人に偏り

解決する手段
　　役割分担
　　　プロダクトマネージャー：ビジネスのプロデューサー
　　　プロダクトオーナー：システムプロデューサー
　　　　→コミュニケーションの問題：共有できる仕組み

なぜ、バリューストリーム
　　改善する箇所を検討できる
　　現状に対するToBeをかく機会
　　バリューストリームマップ

お話の世界？→ヘンリックへ

ヘンリック
　　ソフトウェアカンバン
　　　　Todo
　　　　doing
done
ヘンリックの話
　　フィーチャーがわかる
　　ひとつのカンバンですべてあらわす
　　役割に関わらず１枚のカンバンを共有する
　　プロジェクト全体とチーム固有
　　何度でも書き直す

Value Streamとは何か
　　自分が顧客の要求になったつもり
　　組織内を歩き回って自分で発見する。人に聞かない

　　「リーンソフトウェア開発」「リーン開発の本質」の本に出てる

ケントベック
　　マップ作るのは３０分

顧客に始まり、顧客に終わる」
マップ自体には価値はない


ValueStreaｍは、自分たちで書く
振り返れば、カンバンがある　楽天　及部氏
お話と日常をつなげる仕組みは必要

---

つづく・・・

DevOpsに役立つツール：７ジャンル－日経System2013年2月号より

日経System2013年2月号にDevOps４２ページ～４５ページ
に役立つツールとして
ジャンルごと（７ジャンル）にツールが載っていたので、
メモメモ

---

１．バージョン管理ツール
　subversion
　Git

２．ＣＩツール
　Jenkins
　Travis CI

３．デプロイツール
　Apache Maven
　Capistrano
　Fabric
　ＤＢ変更：マイグレーションツール
　　　dbdeploy
　　　Doctrine
　　　migration

４．環境構築ツール
　Kickstart
　Chef
　Puppet

５．監視ツール
　Ngios
　Zabbix

６．情報共有ツール
　Redmine
　Trac

７．出力情報の集約ツール
　IRC→ツールのサーバーにチャット形式で報告させる

ScalaをEclipseにいれてみた（２）－HelloWorldまで

シリーズScalaをEclipseにいれてみた
前回はインストールしたので、今回は、インストール後、起動して、Ｈｅｌｌｏ　Ｗｏｒｌｄを出すまで。

---

■起動

ふつうにScalaをインストールしたeclipseを起動する。

---

■プロジェクトを作る

File→New→をみると、

なふうに、Scala Projectがある人は、それを選ぶ。
ない人は、Projectを選ぶと

というダイアログがでるので、Scala Projectをえらぶ。

どの道、Scala Projectを選ぶと、下のダイアログが出るはず。

Project nameに適当に名前を入れると、Finishボタンが
おせるようになるので、クリック
今回はscaletest1というプロジェクト名にした。
（scalatest1にしようとおもって、打ち間違えた）

---

■scalaオブジェクトを作る

そうすると、左側に、scaletest1という、プロジェクトができる
もしプロジェクト名の左側が＋になっていたら、＋をクリックして、
中身を表示する。

中身を表示すると、srcというのがあるので、それを選択して、
右ボタンクリックすると、こんなかんじになるので

New→Scala Objectを選択。以下のダイアログが表示される

nameにHelloWorldといれてFinishボタンをクリック

ふつうにソースが書けるようになる。

---

■Hello Worldを作成

そうしたら、

http://d.hatena.ne.jp/unageanu/20080422/1208863069

に書かれているHelloWorldのソースコードをコピペする。
保存して

Run→Run as→Scala Applicationを選択

なかんじで、実行される

ハッカーと積極交流を＝サイバー犯罪対策で警察庁

いや、交流するよりも、ラックやネットエージェントに外注しちゃったほうが、
早くないか（＾＾；）


＜A HREF="http://headlines.yahoo.co.jp/hl?a=20130124-00000049-jij-soci">
ハッカーと積極交流を＝サイバー犯罪対策で警察庁
http://headlines.yahoo.co.jp/hl?a=20130124-00000049-jij-soci

ScalaをEclipseにいれてみた（１）－インストールまで

さっき、Scala、インストールとか、むずかしそうとか書いたけど、
そんなことなかった。

インストール方法を簡単に書いておきます。

■前提条件
（１）Java入ってる
（２）Eclipseもはいってる

■Scalaプラグインのインストール
Eclipseの
Help→Install New Software
を開くと、新しいプラグインが入れられるダイアログが
ひらく。

そこで、addボタンクリック（まるで囲んだところクリック）
すると、ダイアログがあらわれる。
下のLocationのところに、

http://download.scala-ide.org/sdk/e37/scala29/stable/site/

といれると、こんなかんじになる

上の３つをチェックしてNextにいった。

で、ふつうにインストールしていく。
（Nextとか、acceptしたり、テキトーに）

インストール中

なダイアログでたらＯＫ

終わったら（ダイアログで聞いてくるけど）
Eclipseを終了させ、再起動する。

再起動すると

なダイアログがでる。ＹＥＳをクリック

なダイアログでる。ＯＫ

Newとかでみると、ScalaのWizardsがでている。

---

つぎは、プロジェクト作成・・

Scalaが”ポストJavaの最有力候補”なんですって・・・

またまた日経ＳＹＳＴＥＭの２０１３年２月号にかいてあります。５４ページ

・テストしやすい
　　副作用がないプログラムを書けるから
　　副作用のあるコードもかける

・少ないコード量

・型宣言不要
　　コンパイラによる型チェックをする
　　型推論するので、宣言はいらない

・直感的に判りやすくも書ける
　　手続き型みたいにも書けるから

・オブジェクト指向開発もできる

ってことが、メリットらしいですね。

でも、インストールのしかたが

scalajp / scalajp.github.com
https://github.com/scalajp/scalajp.github.com/wiki/scala-develop-environment

に載ってるんですけど・・・めんどくさいんですけど（－＿－；）

なんか、フレームワークがあって

Ｌｉｆｔ
http://oss.infoscience.co.jp/scala/liftweb.net/

とかいうやつ。
あしたの研で取り上げてた

ORACLEの「実行計画に関わる困った問題を解決する」ＳＰＭ

って書いてある。

日経ＳＹＳＴＥＭ　２０１３年２月号　１６ページ
ＯｒａｃｌｅＤＢの実行計画管理「ＳＰＭ」

の３段目に・・・

ＳＰＭとは、要するに、

オプティマイザーがテキトーにうごいて、おかしな実行計画を
行い、ＳＱＬの実行速度がとても遅くなることを防ぐために、

実行計画をいくつももっておいて、

承認したものだけ実行させる仕組みらしい・・・


う～ん、
「実行計画に関わる困った問題を解決する」
う～ん、
場合によっては、そうだけどお・・・（＾＾；）