未唯宇宙8.6

8.6　ソーシャル
　・店舗コミュニティを具体化するフェーズにある。ポータルで、スタッフを取り囲むメッセージとライブラリをつなげる。ソーシャルウェブのチャッターの活用技術で、コミュニティイメージをスタッフに与え、販売店単位のデータ活用を可能にする。開発は、ソーシャルウェブで社会と一体化した柔軟なものにする。
　・ソーシャルという世界
　・ソーシャルネット
　・社会基盤
　・情報共有

1　配置を生かす
　・ソーシャルウェブ開発の良さを活かす。開発要件はユーザー主導にする。新機能での拡張性がポイントになる。作ることよりも活用する人をイメージし、情報共有基盤を開発して、販売店で容易に加工できる。ファシリテーターは販売店に任せるカタチになる。
　・ポータルの開発方法

1-1　構造
　・現行機能の確保が前提になっている。現行はポータルの最終形ではない。足りない部分、できなかった部分をシステム構築を通じて補完する。ポータルでの拡張性としては、４つの機能で展開していく。販売店システム全体と先行きのイメージも提示していく。

1-1.1　市民の覚醒
　・（要件）何を目指し、どう解決するのか
　・ポータルの要件
　・相変わらず、作ることしか考えていない

1-1.2　地域の循環
　・クルマ社会は配置　

1-1.3　近傍で拡張
　・インフラは自己判断で実施
　・お客様とのコミュニケーション
　・電算部が日和っている

1-1.4　パートナー支援
　・パートナーに言いたいこと
　・パートナーのロジック
　・ポータルの基本設計
　・専門に縛られない

1-2　柔軟性
　・開発方式は３つが提案されている。Salesforce、SharePont、Liferayです。私はソーシャルウェブを選びます。SFDCのポイントは、アジャイル型開発手法、生産性、情報共有基盤の認識、全体への展開、機能改善の抑え込みです。電算部のメーカー決定に3カ月以上掛かっている。

1-2.1　市民の多様性
　・2015年まで延期の可能性
　・2015年まで凍結案
　・CITの思惑
　・IT推進室の思惑
　・評価ポイント
　・ポータルの進め方

1-2.2　ＳＮＳ組合せ
　・SFDCの評価ポイント
　・ポータルのメーカー決定
　・語れる相手
　・私にとってのクラウドへの期待
　・未唯（μ）との対話　SFDCからの回答

1-2.3　自由な組替え
　・チャッター・コラボレーション
　・ポータルの検討会
　・議事録ではなく、SNSにする

1-2.4　循環を定義
　・サファイアがサファイア
　・ジャンヌ・ダルク
　・たった一人で世界を変える
　・ポータル検討
　・時間のシナリオで解決させる
　・出来た時のイメージを描く
　・未唯空間は脚本

1-3　拡張性
　・構築の考えは情報共有基盤とし、販売店で加工できることが前提になる。構築体制は販売店全域で展開していく。仕様書を元に、稼働状態を見ながらの開発するオンサイト方式をとる。オンサイト方式で、SNSはコラボ、モバイルはメッセージ表示、検索はライブラリで対応。アイデアボックス、データ抜出を機能追加する。

1-3.1　クラウド活用
　・ＩＴ企業のプラットフォームに注目する二つの理由
　・プラットフォーム運営に欠かせない視点「共有価値観」
　・巨大ＩＴ企業の共有価値観を読み解く

1-3.2　好き嫌いの拘り
　・顔つきはよくない
　・許容範囲の判断
　・私は正しい

1-3.3　全域に適用
　・プロジェクト推進体制：会議体
　・ポータルの検討会

1-3.4　オンサイト対応
　・社会モデルの概念
　・社会モデルを作り上げる

1-4　進化
　・10万人に対する展開ではなく、先行する販売店を優先する。事務局を構えて、ファシリテーターで販売店展開するのと同時に、販売店事例の横展開を行っていく。販売店内では、情報共有を経営層へのアプローチして、スタッフのナレッジ化を進める。さらに、お客様への進化のアイデアを抽出する。

1-4.1　事例で展開
　・プラットフォームが私たちの生活を左右する
　・インタープリターを探してきた
　・カテゴリーの概念
　・サファイアなきサファイア
　・パートナー奪還
　・開発費よりも人件費

1-4.2　行政は支援のみ
　・事務局機能
　・事務局機能（使うことの支援）

1-4.3　ナレッジ誘導
　・スタッフに対する不信感
　・組織と闘う
　・組織に対する見解

1-4.4　サファイア貫徹
　・夢を描くには
　・次期ポータル

2　クラウド支援
　・ポータルを単なる入り口だけではなく、スタッフの武器にするために、データ活用を可能にする。基幹系・情報系のデータをクラウドに外付けして、販売店単位での機能開発、お客様の声をフロー情報として吸い上げ、スタッフ単位での活用、メーカー情報をプル型で提供する。
　　スタッフ単位のデータ

2-1　インフラ機能
　・ポータルをスタッフ自身の武器にしていく。店舗コミュニティの情報共有を徹底させて、店舗の活性化をめざす。販売店での機能開発を可能にする。ソーシャル・ウェブを活用して、社会システムとの親和性を図り、各種情報の収集と整理、お客様との双方向通信を行う。

2-1.1　コミュニティ主体
　・コスト・パフォーマンス
　・SFDCでのポータル
　・スタッフのIT環境
　・経営者とスタッフの間のジレンマ解消

2-1.2　個別対応を適用
　・スタッフに武器を配る
　・販売店の方針は待ちになっている

2-1.3　個人環境を整備
　・マイクロソフトとネットスケープの戦い
　・ノキア　燃えるプラットフォーム
　・ブラックべリーの例
　・情報は渡した後、話し合い

2-1.4　双方向通信
　・お客様のデータ集約

2-2　フェースブック
　・お客様ポータルは、お客様にとって、販売店とかメーカーにつながるメリットが感じられない。お客様の声を吸い上げ、的確に対応するスタッフ側の意識が必要になる。その上で、お客様の声を吸い上げる。お客様のコミュニティとの接続して、メーカー企画と情報共有を図る。メーカーの存在理由になる。

2-2.1　情報共有係数
　・お客様とのコミュニケーション（お客様とつながりたい）

2-2.2　要望の吸い上げ
　・FBへのわがままな入力
　・お客様とのメール
　・お客様の声を吸い上げる

2-2.3　コミュニティ支援
　・Facebook、Twitter、Wikipedia
　・お客様とのコミュニティ
　・お客様との情報共有
　・お客様の声を取り入れる

2-2.4　行政・企業と共有
　・サファイアの構成
　・メーカーからのマーケティングと接続させる

2-3　グーグル
　・システムからお客様情報を分離させ、差分については、EAI機能を使って、反映させることで、個別ライブラリが可能になる。自社で収集した、フロー情報と合わせて、お客様接点で得られた情報を集約する。タブレットの簡単な操作で、スタッフ単位の活用を可能にする。

2-3.1　ユニットで活動
　・競争入札方式の導入
　・収益モデルを求めての試行錯誤
　・収入源がなかったグーグル

2-3.2　知の入口
　・Googleの音声認識
　・Googleを組み合わせる発想
　・データの外付け

2-3.3　資本主義の枠
　・グーグルは資本主義に収まらない　
　・お客様データの徹底活用
　・簡単に使えるシステム

2-3.4　情報付与
　・グーグルのDocument
　・ソーシャルメディアのビジネスモデル　グーグル
　・グーグルの言語資本主義
　・グーグル化する世界
　・スタッフ情報の作成

2-4　アマゾン
　・大量データは衛星配信から地上回線に変わる。メーカー情報を取りに行くから、関係する情報をプッシュさせる方式に変える。サーバー情報とポータルの個人情報を関係づける。ライブラリの見える化として、利用状況・ランキングなどを提供。ソーシャルウェブで微分的から積分的なものに変わる。

2-4.1　大容量情報処理
　・アマゾンが一番
　・Mu-Boxサーバーの見える化

2-4.2　メール通知
　・アマゾンのキンドル・オアシス発送時期への問い合わせ
　・ソーシャルウェブ化
　・販売店が使えるシステム

2-4.3　電子書籍展開
　・『まっ直ぐに本を売る』
　・アマゾンとの付き合い方
　・ポータルでつながるをつなげる

2-4.4　個人の好き嫌い
　・ネット通販と宅配便の異変
　・クラウドでの検索

3　検索とシェア
　・今どきの操作性で、ポータルを進化させます。ポータル管理のレベルアップ、モバイル対応、ダッシュボードでの編集、コラボ機能（チャッター）、ライブラリのナレッジ化と検索エンジン、多様なデータ取込みの汎用化を可能にして、販売店毎のニーズに対応させる。
　・コミュニティ機能の要件

3-1　ポータル
　・ポータルの情報共有機能を前面に出していく。サファイアの４つの機能を進化させる。ポイントは販売店での加工・追加できるようにしていく。ソーシャルウェブを用いて、権限の徹底、活用状況の把握、モバイル表示を行い、即時性を持つことでポータルの独立を目指す。

3-1.1　分かり易い操作
　・30万人のコラボレーション
　・ポータル
　・ポータルのツールで意識を変える
　・次期ポータルの機能改善の項目をまとめている。

3-1.2　理解の容易さ
　・本社・店舗間は本社からの指示が中心

3-1.3　個人の空間構築
　・パートナーのポータル
　・パートナーのポータル

3-1.4　モバイル活用
　・4つの機能の進化
　・ポータル・ケータイ環境

3-2　共有機能
　・ポータルは、コミュニケーション、メッセージ、情報収集、ライブラリの4つの機能で構成される。コミュニケーションの基本は操作画面です。個人認証で的確な表示を行い、関連システムをシングルサインオンする。

3-2.1　コミュニケーション
　・ポータルの機能
　・ポータルを論理的に説明
　・使うこと主体のシステムを志向
　・従来のやり方からの発想

3-2.2　メッセージ
　・レイアウト・パーツ管理要件書
　・画面レイアウト
　・作成状況

3-2.3　情報収集
　・ATSC認証は後付け
　・ユーザー管理要件書
　・外部認証（ATSC)との連動（シングルサインオン）

3-2.4　ライブラリ
　・ポートレットの操作性の機能ベース
　・業務メニュー

3-3　検索機能
　・販売店ライブラリについては、スタッフのコラボ結果を集約できるようにする。検索機能を含めて、スタッフのナレッジ化を図る。販売店からバラバラでアクセスしているメーカー情報、大容量データ、自社映像コンテンツなどをポータルからアクセスできるようにする。

3-3.1　コンテンツ集約
　・お客様要望のメーカー収集
　・バラバラにやっている
　・ライブラリのクラウド

3-3.2　多様なエンジン
　・Yahoo！検索の「話題」
　・30万人のコラボレーション
　・検索機能

3-3.3　二次資料の蓄積
　・グーグルサーチ
　・コラボ結果はライブラリに集約
　・ポータルでのライブラリ

3-3.4　ライブラリ接続
　・ライブラリとメッセージの検索
　・地域の主役は市民

3-4　絞り込み
　・ポータルのコンテンツ編集の機能を使って、基幹系・情報系の販売店でデータ外付けして、自社用のお客様情報の表示を可能にする。ポータル画面には、情報系データのメッセージ表示、基幹系データの表示などは進化させる。アピール・アンケートの結果なども、グラフなどで表示して、アピールする。

3-4.1　自分なりの解釈
　・ポータル・集計表
　・ポータルに対するパートナー
　・簡単に使えるデータ
　・個人で日報などの情報蓄積の可能性

3-4.2　情報系システム
　・お客様情報の活用

3-4.3　多様なメッセージ
　・機能よりもコンテンツ
　・コンテンツを活かす力
　・EUCデータのさまざまな表示

3-4.4　受け手編集
　・SFDCのアプリの活用
　・羊の皮をかぶったオオカミ

4　外部に押し出す
　・新ポータル開発を通じて、店舗コミュニティをイメージしていく。開発機能としては、入口としてのポータル画面、メッセージでのフロー処理（掲示板・お知らせ）、ライブラリでのストック処理、本社との情報処理のアピール・アンケート(コンテンツ表示・Web表示）です。
　ポータルでの情報共有

4-1　内から外延
　・様々なところから飛んできたメッセージをシステムを通さずに、個人の権限で表示させる。お客様・メーカー・本社とのメッセージのスルー性を確保する。ライブラリが変更した時も自動的にメッセージを発生させる。社内SNSでスタッフがお客様を代表して、コラボで要望を吸い上げる。

4-1.1　入口
　・SFDCでダッシュボード
　・ポータルの範囲拡大
　・意見がいえるスタッフ
　・店舗の意見をまとめる

4-1.2　メッセージ
　・システムを経由せずに、権限で表示させる

4-1.3　外延
　・SNSのコラボイメージ
　・チャッターとの一体化
　・自己顕示欲の世界

4-1.4　要望
　・アイデアボックス
　・アピール機能
　・情報の吸い上げ

4-2　外部と接続
　・システム毎にメッセージが存在している。ポータルに集約させる。その上で、メッセージから始まる循環をイメージする。お知らせ以外に、掲示板・iFlameなどで伝えている。それらの効果が不明。基幹系と同時表示ができない。

4-2.1　お知らせ
　・メッセージ系
　・メッセージ要件
　・掲示板もメールの機能

4-2.2　掲示板
　・メールの発信
　・メールを吸収しようとはしなかった

4-2.3　画面編集
　・お知らせ機能
　・チャット的な機能は社内SNSで対応

4-2.4　メニュー
　・業務メニューの要件

4-3　アピール
　・アピール・アンケートという名前はフィンランドのハメリンナのDr.ヘリさんからもらった。環境で市民と一緒にやるためのツールです。表形式のアンケートが主になっている。結果をアピールできるものが必要になる。チャッターでの問答形式も意見集約には必要です。

4-3.1　アウトリーチ
　・アピール・アンケート
　・アンケート機能
　・ポータルへの経緯
　・ポータルメモ

4-3.2　伝播
　・コンテンツ管理機能要件
　・実績表の表示

4-3.3　ユニット行動
　・テロップの作成～閲覧
　・簡易Webの作成～閲覧
　・入力制限

4-3.4　コミュニティ連携
　・エクセルの加工

4-4　アンケート
　・本部の情報をストックする場として、ライブラリを開発して、ポータルのメッセージと連携させた。メッセージはスタッフに対してのフロー情報だが、ライブラリはストック情報になる。ライブラリを必要としない販売店はノウハウの蓄積とか、情報共有を従来のままになっている。ライブラリの存在理由を明確にしてきた。

4-4.1　皆の思い収集
　・ポータル検討
　・ライブラリ機能
　・店舗との情報共有に限定

4-4.2　多様な表現
　・グループの扱い
　・フローとストック
　・ポータル・ファイル管理

4-4.3　リアルタイム
　・ライブラリを必要としない販売店
　・販売店単位に有料で設定

4-4.4　参画意識
　・ライブラリでの権限