発信する顧客は優良顧客か？－eオピニオンリーダーほどネットで発信する

昨日のマーケティング関係の授業、後半が興味深かったのでメモメモ

●口コミ「発信」行動の規定要因（映画の場合：浜岡、里村 2009）
　　発信者の心理
　　　　一般的な口コミ：社会関係資本、映画への知識、コミュニケーションの楽しさ、ポジ感情の解放・・
　　　　ネットの口コミ：アイデンティティ、自己効力感、経済的報酬、eコミュニケーションの楽しさ・・
　→リアルでの口コミとネットでの口コミは、規定要因が異なる
　　（本来この調査は、映画への苦情の話だが、その部分は、面白くないので省略）

●口コミの「受け手」の影響（渋谷2011a 2011b）
　　リアルの場合
　　　　コミュニケーションの信頼性＝信用性＋専門性

　　ネットの場合
　　　　ネット口コミの信頼性＝信用性＋専門性＋類似性

　　　　目的関連性類似性が重視される


●コミュニティ
　　リアルなコミュニティ
　　　　社会的相互作用、共通の紐帯（絆）、地域性を持ったもの

　　ネットコミュニティ
　　　　地域性はない：地縁・血縁→情報縁
　　　　社会的相互作用、共通の紐帯
　　　　　　情報を読むだけのメンバー（ＲＯＭ）も

　　ネットコミュニティでの発言者の特徴
　　　　eオピニオンリーダーほどネットで発信する（浜岡、里村2009）
　　　　発信する顧客は優良顧客か？（山本2005：アットコスメの研究）

●マーケティングコミュニケーションツールとしてのネットコミュニティ
　　インフォーマルなパーソナルコミュニケーション
　　　　　→コントロールしにくい口コミ中心

　　ネットコミュニティはＲＯＭだけでは成立せず、
　　参加者がどれだけ積極的に発言するかがカギ

＜＜参考文献＞＞
浜岡、里村2009　濱岡豊・里村卓也　消費者間の相互作用についての基礎研究　慶應義塾大学出版会 2009
渋谷2011a　渋谷覚　「クチコミの有用性：購買シミュレーションとしてのネットクチコミ」，日経広告研究所報257
渋谷2011b　渋谷覚　「クチコミによる推論：現代の他者から将来の自己を予測する過程」，流通研究 Vol13 No3
山本2005 山本晶「発信する顧客は優良顧客化？」消費者行動研究Vol11 No1/2

Facebookの「外部アプリ・広告へ、ユーザーの名前や顔写真を使用する許可？」について話題

これ、「許可を与えることはありません。」と明言されているが、その後の、「将来的にこれが可能になった場合・・・」以下云々が話題になっているらしい（いや、私の「友達」の一部の人が書いてるだけかもしれないんだけど）

たとえば、こんなブログ

Facebookが名前や写真を広告に使用？
http://atasinti.chu.jp/dad3/archives/6788

にその話が書いてある。

というのも、Facebookのホームの横にある▼で、
「アカウント設定」を選択すると、「一般」というのが出る。
ここの「facebook広告」を選択すると、以下の画面が出る。

ここに、明示的に、「許可を与えない」と書いてあるが、「将来的には・・・」と書いてある。
？？？

で、ここで話題になっているのは、その先の画面「外部広告の設定を編集」をクリックすると・・・



「将来的にこれが可能になった場合、以下に情報を公開する」
・・・って、おいおい、許可を与えないつもりなら、
そんなことを聞かないだろう（＾＾；）

ってことで・・・この設定、昔からあったんだろうか、最近できたんだろうか・・・

とにかく、念には念を入れたい人にとって、今のうちから、設定しておくのに、越したことはない。

Ｐ．Ｓ　あくまでもうわさです。信憑性はわかりません。

5月30日(水)のつぶやき

23:04 from web
”「x=3ならばy=5、あるいは、y=5ならばz=8」が言える”をブログった。 plaza.rakuten.co.jp/struts/diary/2…

by xmldtp on Twitter

ITエンジニア派遣の「人月0円セール」が行われている？

コスト０、何人やとってもフリーなら、自由にペアプロできますね。
タダなら、プログラミングさせないで、お茶くみとして雇ってもいい。

・・・って、そういう問題ではない（＾＾；）


ITエンジニア派遣の「人月0円セール」が行われている？
http://slashdot.jp/story/12/05/30/0820248/

ＣＲＭレベルのビッグデータ利用は、淘汰されていくんでしょうね・・・

　マーケティングの世界では、昔は、新規顧客開拓より、リピーター顧客に何度も買わせたほうが、儲かった。
　この時代は、上顧客を分析して、何度も買わせることで、利益が出た。
　そのため、上顧客を分析するＣＲＭがはやった。
　例えば、どのくらいの頻度、金額、いつ買った・・などを調べることによって、上顧客を明確にする
　ＲＦＭ分析、また、他の方法としては、購買データと、いろんなデータを組み合わせて、どのような顧客が購入するか
を分析するような、データマイニング的手法などが流行った。

　これらの分析を、ビッグデータでもできるけど、例えば、機械学習や重回帰を使って、どのような人たちが買うかとかいうことは調べられるけど、そういう、ビッグデータ利用は、淘汰されていくんでしょうね・・・



　マーケティングはその後(＝現在）買うという局面を超えて、どのように消費され、また購買に結び付くかという商品のライフサイクル全般を捕らえるようになってきた。さらに、買わない人たちを分析するようになってきた。
　これには、購入後の追跡調査や、購入しない人、競合商品を買う人の調査がいる。
　しかし、購入後の追跡調査って、買ったあと、尾行していったら、これは、ストーカーになってしまう（＾＾；）

　もちろん、そんなことをするんじゃなくって、ブログやＴｗｉｔｔｅｒから、その商品が出てきているものを探し、買った後の感想や、商品を使った後の話などを分析することになる。また、競合商品に関しても、購入時、購入後の話を調べ、競合商品は、どう思われていて、自社の製品はどう思われているか、とかを分析しないといけない。こういうときに、ビッグデータを使った分析が生きて来るんだと思う。

　そして、競合会社によって、このようにどんどん分析されてくると、他社は、ＣＲＭをやっても、顧客を取られていってしまうと・・


　そんなわけで、ビッグデータ分析でも、ＣＲＭどまりだと、ちょっと厳しいものがあるんじゃないかなって思う。
　そもそも、そのレベルなら、今のデータマイニング、テラデータとかビジネスオブジェクトを使って・・でいいわけだし。


　そうそう、ＣＲＭっていうと、コールセンターでよく使われるけど、
　最近は、コールセンターに電話するより、ＴｗｉｔｔｅｒやＦａｃｅｂｏｏｋに書き込んで、拡散しちゃうほうが、はやいもんね。こういう意味でも、ＣＲＭは時代遅れになりつつある。

Windows XPのサポートコストはWindows 7の5倍

ここまでは、まだ、・・・そうなの？という気がするが・・・


　Microsoftのマーケティングディレクター、アーウィン・ビサー氏は公式ブログで、「IDCの調査によると、Windows XPからWindows 7に移行した企業では、3年間で投資回収率（ROI）が130％以上向上した。


いや、それは違うでしょ（＾＾）
Windows７に移行できるような企業は、景気がいいから、ＲＯＩが上がったのであって、
ＸＰから７に移行するだけで、どんな商売でもＲＯＩが上がるわけ・・・ないよね・・・

・・・上がるのか？

Windows XPのサポートコストはWindows 7の5倍――Microsoftが移行を呼び掛け
http://headlines.yahoo.co.jp/hl?a=20120528-00000063-zdn_n-inet


（本エントリー内の太字部分は、上記記事より引用）

NHK技研公開２０１２

きのう、NHK技研公開２０１２にいってきた。
そのメモメモ


＜＜展示内容＞＞
Hybrid Cast（ハイブリッド・キャスト）
　　HTML5アプリをダウンロードしてテレビで見る
　　放送と通信の同期合成
　　マルチビュー
　　手話CGを天気予報と合成
ソーシャルテレビ
telda-API
TVML,TVML+Telda-API
字幕作成のための音声認識
易しい日本語変換
番組推薦


スーパーハイビジョン関係
　　スーパーハイビジョン＋グローバルIP
　　１４５インチスーパーハイビジョン
　　　　→パブリックビューイングとか

３次元残響
３次元ミキシングコンソール
２２．２マルチチャンネル

その他
　　ラジオマイク
　　大震災のアーカイブのためのメタデータ自動付加
　　ホログラム
　　触覚ディスプレイ
　　CG操作
　　視線検知

＜＜所感＞＞
　スーパーハイビジョンは、みんなでみる方向と、個人で見る方向に行っていると思う。みんなで見る方向（パブリックビューイング）は、今の時代、力道山とかいないから（そういう問題か　＾＾；）まだ、広まっていないが、これが広まれば、超大型液晶ディスプレイの需要などで、契機効果は大きいと思う。

CakePHPでの「Railsっぽい」手順－bakeを使った場合

CakePHPでの「Railsっぽい」手順
http://blog.goo.ne.jp/xmldtp/e/11ea5caad23f267b8cb832ad5f27ee8f

の続きの話。そのときには、bakeを使わなかったけど、今回は、bakeを使って、
自動生成するはなし。


bakeを使わないときと、前提～４までは同じ

---

■手順

Ａｐａｃｈｅ，DB(MySQL),PHPは動作しているものとする。
[確認]httpd.confで、リライトモードがコメントになっていないで、実行できること
LoadModule rewrite_module modules/mod_rewrite.so
<Directory />
Options All
AllowOverride All
</Directory>

●１．ダウンロードしてくる
http://cakephp.jp/から

●２．解凍して、フォルダの名前を変える
　　myappとか

●３．そのフォルダをapacheのhtdocsの下にいれる

●４．この段階で、ブラウザで確認
　　http://localhost/myapp
　　ブラウザから、Cake PHPが確認できればＯＫ
　　　→この段階では、ＤＢに繋がっていないので、ＤＢのエラーが出てＯＫ

--------------ここから違う------------------------

●５．Windowsにもどって、コマンドプロンプトを立ち上げて、
　　　コマンドプロンプトから、上記４で作成したフォルダの下の
　　　（例では、apacheのホーム/htdoc/myappの下の）
cake/console
のフォルダにcdする
　
●６．以下のコマンドをコマンドラインから打つ
　　　　　cake bake
　　　すると、データベースについて聞いてくる。
　　　mysqlの場合、デフォルトでいいので、はじめのうちは、リターンのみ
　　　終わりのほうで、ユーザー名、パスワード、データベース名を聞いてくる
　　　そこを入力する。

●７．この段階で、ブラウザで確認
　　http://localhost/myapp
　　ブラウザから、Cake PHPが確認でき、ＤＢに繋がっていればＯＫ
　　　→いなかったら、app/config/database.phpを確認

●８．もう一度、以下のコマンドをコマンドラインから打つ
　　　　　cake bake
　　　すると、前回とは違い、メニューが出る

　　　●８－１．はじめに、モデルを作るので、mを入力
　　　　　→プライマリーキーなどを聞いてくる。適当に答えて作成する

　　　●８－２．次に、コントローラーを作るので、cを入力
　　　　　→クラスメソッドを作るかなど聞いてくる。適当に答えて作成する
　
　　　●８－３．そうしたら、ビューを作る。vを入力
　　　　　→どんなビューを作るか聞いてくる。適当に答えて作成する

●９．この段階で、ブラウザで確認
　　http://localhost/myapp/適当なビュー
　　適当に表示されればＯＫ

●１０．レイアウトの変更など
　　全体にかかわること・・・view/layout
　　ＣＳＳ・・・app/webroot/css
　　個々の画面・・・それぞれのviewに対してできるctpファイル

※８以降に関しては、いろいろなサイトに出ている。

5月27日(日)のつぶやき

02:49 from web
しまった！か、よかった！かわかんないけど、NHK技研公開、今日までなことに、今気づいた！ nhk.or.jp/strl/open2012/…

by xmldtp on Twitter

「NIFTY-Serve」が“復活”らしい

１年間だけ・・・

「NIFTY-Serve」が“復活”　フォーラムの仲間と「同窓会」を
http://www.itmedia.co.jp/news/articles/1205/24/news036.html


復活した「NIFTY-Serve」は、

ここ
http://www.niftyserve.com/

組み込みソフトウェア開発向けコーディング作法ガイド（ESCR)

DM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第７回（今回から三田）

組み込みソフトウェア開発向けコーディング作法ガイド解説


つまり、ESCRの話を聞いてきたのでメモメモ

---

組み込みシステム開発者技術リファレンスESｘRシリーズ
　　開発プロセス
　　プロジェクトマネジメント
　　プロジェクト計画立案
　　コーディング作法ガイド
　　品質作りこみガイド

■第一章　組み込みソフトウェアにおけるコード品質
１．１　組み込みソフトウェア開発の現状
　　組み込みソフトウェア産業実態調査
　　　　ソフトウェアが原因の問題：半分くらい
　　　　　　→なんとかしないと
　　　　不具合の１／３は、実装工程で作りこまれている
　　　　　　→コーディングに問題
　　　　避けるような作法ガイドに

１．２　コード品質
　　ソフトウェア実装・単体テストの流れ
　　　　コーディング規約
　　　　レビュー観点リスト
　　コーディング規約：あまり使われていない
　　　　流用：もともとのコードの品質影響
　　実装時にレビューしないで、テストでまかなっている
　　　　コーディング規約と静的診断ツール
　　コーディング規約は形骸化している
　　　　命名や書式にこだわりすぎ
　　　　守れないルール・チェックしづらい
　　　　更新されていない。個々のプロジェクトに対応していない

１．３　コーディング規約
　　コーディング規約を守れるようにするために
　　　　必要性がわかるように
　　　　作法をC言語に落とし込む
　　　　カスタマイズしやすいルール
　　　　基本的に押さえるべきコーディング技術を取得
　　　　　　ルールの集合

■第二章　適用事例
２．１　コーディング規約の運用事例
　　静的解析ツールを使用して、コード品質の改善を図っているが、
　　　　様々な課題を抱えている
　　挙がってきた問題点
　　　　開発者がコード品質を上げる意識なし
　　　　ツールが多く指摘：重要点をみうしなう
　　　　対応が表面的になりがち

　　コーディング作法の導入

　　実装の段階で、解析

　　保守性を重点的に

２．２　コード品質を向上するには
　　効果を得るためのアプローチ
　　　　コーディング規約の教育
　　　　プロダクトの目的に適したコーディング規約の作成
　　　　ツールの有効活用
　　　　実装プロセス改善

■第三章　ESCR
３．１　コーディングミスの実際
　　・プログラミング言語の基本的な使い方を理解しただけでは、
　　　実際のソフトウェア開発には対応しきれない
　　・ソースコード中に実行されることのない式や文を記述したまま
　　・型に対する制約範囲を意識する
　　・メモリ操作
　　・論理演算の勘違い
　　・タイプミス
　　・コンパイル依存

３．２　ESCRの内容
　　特徴
　　　・体系化された」作法とルール
　　　・すぐ使えるリファレンスルール
　　　・ルールの必要性をを提示
　　　・他のコーディング規約との対応関係を明示
　　　　　　MISRA　C(みすらーC)
　　基本構成
　　　作法とルールを体系化
　　　　　品質概念：信頼性、保守性、移植し、効率性
　　　　　作法:言語依存しない
　　　　　ルール：言語依存

　　　例：
　　　　作法概要
　　　　　　信頼性１：領域は初期化し、大きさに注意して使用する
　　　　作法詳細：具体的な実装の考え方
　　　　ルール：作法詳細ごとにある
　　　　　　コード例、必要性の提示
　　　　　　選択指針：規約にする必要性
　　　　　　規約化：詳細化する必要性
　　　　作法５１、ルール１２９

３．３　品質特性ごとのルール紹介
　　細かいルール紹介（省略）


３．４　ESCRを使用した実装品質向上への取り組み方
コーディング規約を作る手順
　　（１）コーディング規約作成方針の決定
　　（２）コーディングルールの選択
　　　　　　　選択指針
　　（３）ルールのプロジェクト依存部分定義
　　　　　　　規約化
　　（４）適用除外の手順決定
　　　　　　　文書化

実装プロセスへの適用
　　　要求定義→コーディング規約→ツール→レビュー

継続的改善

効果的に運用していくためには
　　　ESCRを理解
　　　ツール・レビュー
　　　コーディング規約の振り返り

ESCRに対応したツール

利用状況

C++にも対応
　　オブジェクト、ジェネリック、例外
　　構成とかは、Cと同じ作法までは言語非依存なので同じ
　　ルールは言語依存なので違う
　　利用が難しい機能の制限
　　Misra-c++や、EffectiveC++などなどを調査して含めた

ESCRを使い場合の注意点
　　作法ルールをすべて利用するのではない

Redmine、Tracを使った「定量的プロジェクト管理ツール」の紹介

IPAの

日本におけるアジャイル開発に適した契約モデル案と事例
http://sec.ipa.go.jp/seminar/2012/20120523.html

にいってきた。そのときの

Redmine、Tracを使った「定量的プロジェクト管理ツール」の紹介

についての内容をメモメモ

---

Redmine Tracを使った「定量的プロジェクト管理ツール」の紹介

Agile開発におけるプロジェクト管理の課題
・リアルタイム名タスク管理
　　　　・反復開発
・ソースコードの二重、三重、四重・・・管理
・変更管理とバージョン管理

Redmine,Tracとは
　　　　オープンソースのプロジェクト管理ソフトウェア
　　　　バグトラッキングシステム（BTS)として
　　　　課題管理システムへ（Issue　Tracking　System）
　　　　チケット駆動開発へ
　　　　　　　　作業→タスク→チケット
チケットとは
　　　　担当者が割り振られ、作業ごとに状態
Agile開発への適用
　　　　チケットをタスクカードとして使用
　　　　　　　　ボードにはってもいいけど
　　　　チケットをグループ化
　　　　チケット一覧をタスクボードとして利用
チケット駆動開発の利点
　　　　情報共有が簡単
　　　　作業報告の省力化
　　　　残タスク・進捗をリアルタイムに
　　　　ツールとの連携
　　　　トレーサビリティ（履歴として残るので）
　　　　プロジェクト管理の問題を機能へ：ツール自体進化
定量的プロセス管理ツール
　　　　見える化の必要性：作業を楽に
　　　　開発の多様化・短期間化・低コスト化
　　　　　　　　品質、進捗のばらつき
　　　　　　　　　　　　プロジェクトがおかしくなっているのに気づかない

IPAの見える化：３つ
　　　　定性的な見える化
　　　　定量的な見える化
　　　　２つの統合→リスク把握

測定して、何になるの
　　　　→予測ができるようになる
　　　　ベンチマーキング

定量的プロジェクト管理ツールとして公開（４月２７日）

定量的管理の課題
　　　　定量データの工数
　　　　　　　　日常的に使ってるものからデータ
　　　　分析に時間
　　　　　　　　グラフ、直感的に
　　　　現場で使ってるもの違う
　　　　　　　　いったいで提供
　　　　データがたまらないと
　　　　　　　　ためるところをきめる

定量的プロジェクト管理業務
　　　　即時的にデータが見える
　　　　　　　　KKD（勘、経験、度胸）からツールに基づいたプロジェクト管理

（IPAが出した）定量的プロジェクト管理ツールの特徴
　　　　グラフ表示
　　　　既存ツール
　　　　　　　　グラフかく：BIRT、データ収集にPENTAHO
　　　　定量的データの自動収集
　　　　ツールが簡単に利用できることを重視

（そのIPAのツールの）チケット
　　　　プロジェクト管理に足りないものがあったので足していた
　　　　　　　　自由にきっていただいて結構

　　　　各種チケット
　　　　　　　　WBS(タスク）チケット
　　　　　　　　課題チケット
　　　　　　　　障害チケット

（そのIPAのツールの）提供グラフ

アジャイル開発で得た信頼とか

IPAの

日本におけるアジャイル開発に適した契約モデル案と事例
http://sec.ipa.go.jp/seminar/2012/20120523.html

にいってきた。そのときの

IPA/SECにおけるH23年度非ウォーターフォール型開発に関わる活動成果の概要

についての内容をメモメモ

---

現状のソフトウェア開発を取り巻く課題
　　　　ビジネスニーズへの適切な対応
　　　　ウォーターフォール型開発への疑問
　　　　　　　　計画駆動型
　　　　　　　　要求の固定がビジネスリスクを拡大
　　　　ソフトウェア産業構造（多重下請構造）上の問題
　　　　　　　　創造性のあること：報酬がモチベーションにならない

アジャイル型開発の特徴
　　　　顧客の参画の度合いが高い
　　　　動くソフト
　　　　反復
　　　　コミュニケーション
　　　　変化に対応

非ウォーターフォール型
　　　　スクラムが多い

アジャイル宣言における４つの価値
　　　　１．プロセスやツールよりも個人との対話
　　　　２．動くプログラム
　　　　３．顧客との強調
　　　　４．変化への対応

アジャイル開発のプロセスモデル
　　　　３つのプロセスモデル
　　　　　　　　（１）何回もリリースしていく
　　　　　　　　（２）反復に入る前に、要求・アーキ・基盤開発する
　　　　　　　　（３）各リリース直前にリリース前テストをする
　　　　（２）と（３）は組みあわせることも

課題
　　　　契約
　　　　ユーザー経営層の意識
　　　　　　　　関与度合いを高める必要
　　　　　　　　見える化必要
　　　　ベンダー側

人材
　　　　ユーザーに求められること
　　　　　　　　コアとなる機能の見定め
　　　　　　　　優先度
　　　　ベンダー側
　　　　　　　　ファシリテーション
　　　　　　　　マルチタレント（いろんなことができる）

適用領域
　　　　１．ビジネス要求の変化が激しい
　　　　２．リスク高い
　　　　３．市場競争領域

試行領域
　　　　１．大規模開発
　　　　２．分散拠点（オフショア含む）
　　　　３．組織・会社間をまたぐ開発チーム
　　　　４．組み込み

中規模・大規模も

工夫
　　　　チーム間ローテーション
　　　　段階的朝会
　　　　漸進的な展開
　　　　ツール
　　　　アーキテクチャ重視
　　　　疎結合な機能分割
　　　　テスト専用フェーズ

問題点
　　　　全体計画の把握困難
　　　　ビジネス企画側にボトルネック発生
　　　　反復リズム不適合

適切なシステム・ソフトウェア開発手法の選択
　　　　アジャイル開発のスウィートスポットがある

導入の障壁
　　　　組織文化の変化能力
　　　　変化への一般的な抵抗
　　　　技術者
　　　　企業哲学
　　　　手法の不慣れ

非ウォーターフォール型開発に関わる活動成果の概要とか

IPAの

日本におけるアジャイル開発に適した契約モデル案と事例
http://sec.ipa.go.jp/seminar/2012/20120523.html

にいってきた。そのときの

IPA/SECにおけるH23年度非ウォーターフォール型開発に関わる活動成果の概要

についての内容をメモメモ

---

現状のソフトウェア開発を取り巻く課題
　　　　ビジネスニーズへの適切な対応
　　　　ウォーターフォール型開発への疑問
　　　　　　　　計画駆動型
　　　　　　　　要求の固定がビジネスリスクを拡大
　　　　ソフトウェア産業構造（多重下請構造）上の問題
　　　　　　　　創造性のあること：報酬がモチベーションにならない

アジャイル型開発の特徴
　　　　顧客の参画の度合いが高い
　　　　動くソフト
　　　　反復
　　　　コミュニケーション
　　　　変化に対応

非ウォーターフォール型
　　　　スクラムが多い

アジャイル宣言における４つの価値
　　　　１．プロセスやツールよりも個人との対話
　　　　２．動くプログラム
　　　　３．顧客との強調
　　　　４．変化への対応

アジャイル開発のプロセスモデル
　　　　３つのプロセスモデル
　　　　　　　　（１）何回もリリースしていく
　　　　　　　　（２）反復に入る前に、要求・アーキ・基盤開発する
　　　　　　　　（３）各リリース直前にリリース前テストをする
　　　　（２）と（３）は組みあわせることも

課題
　　　　契約
　　　　ユーザー経営層の意識
　　　　　　　　関与度合いを高める必要
　　　　　　　　見える化必要
　　　　ベンダー側

人材
　　　　ユーザーに求められること
　　　　　　　　コアとなる機能の見定め
　　　　　　　　優先度
　　　　ベンダー側
　　　　　　　　ファシリテーション
　　　　　　　　マルチタレント（いろんなことができる）

適用領域
　　　　１．ビジネス要求の変化が激しい
　　　　２．リスク高い
　　　　３．市場競争領域

試行領域
　　　　１．大規模開発
　　　　２．分散拠点（オフショア含む）
　　　　３．組織・会社間をまたぐ開発チーム
　　　　４．組み込み

中規模・大規模も

工夫
　　　　チーム間ローテーション
　　　　段階的朝会
　　　　漸進的な展開
　　　　ツール
　　　　アーキテクチャ重視
　　　　疎結合な機能分割
　　　　テスト専用フェーズ

問題点
　　　　全体計画の把握困難
　　　　ビジネス企画側にボトルネック発生
　　　　反復リズム不適合

適切なシステム・ソフトウェア開発手法の選択
　　　　アジャイル開発のスウィートスポットがある

導入の障壁
　　　　組織文化の変化能力
　　　　変化への一般的な抵抗
　　　　技術者
　　　　企業哲学
　　　　手法の不慣れ

お客様が求めるＩＣＴベンダー（３つのポイント）とか

ラストは、一番初めの（５月１７日　１０時～）

お客様とともに描く、これからの社会とビジネス

対話形式をちょっとまとめてみた。

---

・活動、中長期計画を話す
・昨年は地震で中止、２年ぶり
・テーマ：Shaping ICT Sheaping Business

■経営環境の変化とICT

①２０１０年の日本国内の企業向けICT支出予測
　　２０１０　２２兆８５９２億
　　２０１１　２２兆２７９０億
　　２０１２　２２兆２６６２億
　→変わっていない：成熟産業
　→国内より、海外

②世界と日本のCIOが取り組む２０１２年の経営戦略
　　企業成長を加速
　　新規顧客を維持
　　日本の場合：プロフェッショナルの確保

③テクノロジ
　　モバイル
　　ビジネスインテリジェンス
　　世界：クラウド→日本では、そんなに要望高くない

世界で見ること大事
　　今まで、日欧米
　　　　　　　　→暗黙のルールがあった
　　今　　　中国、インド
　　　　　　　　→ルールが通用しない
　・中国、インドの動きを察知する

ICTの変化そのもの
　従来：バックオフィスの効率化
　　　　　　↓
　　　　社会インフラ
　　　　　　↓
　　　　新たな価値の創造
　　　　　→ICTは、新しい価値創造を可能に

　価格破壊
　　　ひとつの契機はクラウド
　　　　→グローバル化、競争激化
　　　　　価格下がっても、ボリュームある＝売上は変わらず

　簡単に活用できる
　　　経営者はどのようにICTを活用？
　　　　既存資産の運用でかなり使われ
　　　　新たな価値創造に２割しか使えない
　　　守りのICTの削減、成長への投資
　　　スーパーコンピューター
　　　　どのようなものに使えるか
　　　　　　シミュレーション・・・
CIOは何をするのか
　　企業のICT戦略に沿う
　　ビジネスが現場で起きている

個人がコンピューティングパワーを持っている
　　→クレームはネットへ
　　　コールセンターに来た時点では遅い
　　　ICTの力を使わないと対応できない

ビッグデータ
　　２つ
　　　　・会社のデータを見たい
　　　　・ソーシャルメディア等、新しいデータの創出
　　組み合わせて使う

ERP：過去　の情報
　　　今　　→センサー・マルチコンテキストからの予見

クラウド→日本の企業は相対的に関心低い？
　　クラウドが普及して当たり前になった
　　従来のＩＣＴ基盤がクラウド化
　　ＪＵＡＳ
　　　　おととしまで：慎重
　　　　震災後：データを持つリスク、適材適所で使う
　　セキュリティの問題
　　　　１か０でなく、上手な使い方
　　　　仕分けして使う、最適な利用形態

モビリティのビジネス活用
　　モビリティなくして、クラウドはありえない
　　　　→ヒューマンセントリック
　　　　　一気通貫でサポートできないと
　　センサー
　　　　ＳＣＭ等であたりまえ
　　　　富士通では、ものづくりではもちろん使っている
　　　　　　　　　　Ｍ２Ｍ
　　　　ベンダーが最大のユーザーである
　　　　ベストプラクティスを実現していることが大事

　　ソーシャルイノベーション
　　　　社長：Twitter,FaceBookはやっていない
　　　　Voice to カスタマー　お客さんの声、末端の声
　　　　デジタル化される情報
　　　　　　アラブの春
　　　　　　ビジネスとしては？便利だから普及する
　　　　　　　　　　　　　　　新しいマーケティング

　　個人がコンピューティングパワーを持つ
　　　ＴＩＭＥ People of the year
　　　　　２００６年 you
　　　　　２０１１年　プロテスター（アラブの春）
　　　連帯する
　　　ＩＣＴの進化、ネットワークの充実、あらゆる人にチャンス


Reshapingを支える富士通のチャレンジ
　　ビジョン　中長期
　　　　ヒューマンセントリック　インテリジェント　ソサエティ
　　　　　　人に優しいＩＣＴ、あらゆるジャンルにＩＣＴ
　　農業、医療、防災、エネルギー
　　　　農業：継ぐ人が居ない→センサー技術、分析
　　　　　　　食糧問題
　　　　医療：高齢化
　　　　　　　今までの医療　病院そのもの
　　　　　　　今　　在宅医療を支える→遠隔医療
　　日本：課題先進国→ソリューションとして輸出できる
　　　　　最先端技術、テクノロジーをどう使っていくか

人材
　　デジタル化できない部分
　　人材の強化策
　　現場主義　：　現場で磨いていく（肌身で感じる）
　　　フィールドイノベーター制度
　　　　　　現場における人、プロセス、ＩＣＴを見える化
　　　　　　問題の本質を見極め、お客様とともに課題を解決
　　　　　　保守運用→戦略企画へ
　　　ＳＥのエンパワーメント
　　　　　　お客様の悩みをしている
　　　　　　３Ｋ，５Ｋの中で、わくわくする職場は？
　　　　　　　　４月から、組織構造を変えた
　　　　　　　　　　新しいマトリックス型組織
　　　　　　　　　　お客様起点、事業起点

お客様が求めるＩＣＴベンダー
３つのポイント
　１．テクノロジーのエキスパート
　　　業務は自分たちでやる

　２．できないことはできないといってくれ
　　　→すべてのお客様が求めているわけではない
　　　　志のあるＣＩＯ
　３．現場主義
　　ＳＬＡを超えたところで、どうサービスできるか

お客様とのコミュニケーション
　要件定義：お客様と対等に

　　準委託：リスクは、ユーザーがとる
　　請負：日本は
　　　　　→ベンダーのとりくみを透明化

気遣いだいじ

ウルトラブック出した

日本人；職人が好き、そこがＤＮＡ