デザインとイノベーションを架橋する諸理論

昨日、公開セミナー　知的資産経営新ビジネス塾の「デザインとイノベーションを架橋する諸理論」を聞いてきた！その内容をメモメモ

---

■社会科学とデザイン　鈴木先生
・前半：デザイン思考
　後半：除染とデザイン思考

１．マーケティングとデザイン
　　４P：マッカーシー、コトラーの分類
　　競争戦略とデザイン
　　　ポーターの５フォースに基づく３戦略
　　　　コストリーダーシップ
　　　　差別化・・技術的スペック、デザイン
　　　　集中

　　４C：ローターボーン
　　　　Consumer:
　　　　Cost
　　　　Convenience
　　　　Communication

　　経験経済：パインとギルモア（１９９９年）
　　　　なにをデザインして利益を上げてきたか
　　　　→付加価値：演出（思い出に残るもの／１回限りの個人的経験）
　　　　→需要の源は感動にある：ディズニーランド
　　　　　顧客の経験

　　経験価値マーケティング：シュミット（１９９９）
　　　感覚的経験価値
　　　情緒的経験価値
　　　認知的経験価値
　　　行動的経験価値
　　　関係的経験価値
　　→顧客に提供する感動は？→それにはどんな技術がいる？
　　　知的創造サイクルVSビジネスの構想サイクル

２．デザイン思考によるイノベーション
　　着想（インスピレーション）
　　発案（アイデアノート）
　　実装（インプリメンテーション）
　　→直線的でない

　イノベーションの制約条件
　　　・技術的実現性
　　　・有用性
　　　・経済的現実性
　　→全部交わる：成功するイノベーション

　デザイン思考に必要な要素
　　　洞察
　　　観察
　　　感情移入

　アンケート
　　　Q：なぜ・・・？
　　→表面的理由
　　　真のニーズ、ウォンツはとれない
　　　これがほしかったんでしょ？というもの

　観察＋感情移入→洞察！

　デザイン思考のプロセス
　　１．理解
　　　制約条件を頭に叩き込む

　　２．観察
　　　具体的に何をしているか観察
　　　→解釈しないで書き続ける
　　　　エスノメソドロジー
　　　　　シャドーイング
　　　　　行動マッピング
　　　　　消費者旅行
　　　　　カメラジャーナル
　　　　　究極ユーザーインタビュー
　　　　　ストーリーテーリング
　　　　　アンフォーカスグループ：まったく使ってない人に
　　　　→IDEOの手法より

　　３．ブレインストーミング
　　　結果をもちよる
　　　アグレッシブなアイデア

　　４．ラピッドプロトタイピング
　　　仕上がりのよさにこだわらない
　　　わかればいい
　　　製品でもサービスでも

　　５．ブラッシュアップ

　　６．実現

IDEOの成功例
・ケース１：ウォーナゴー
・ケース２：シマノ（アメリカのほうの例）
　　　マニア向け営業トーク
　　　高価な自転車・複雑
　　　自転車向けに整備されていない道路
　　　メンテナンス
　　→子供のころの楽しい思い出
　　　　→コースティング

　包括的な解決策の採用

　デザインプロジェクト
　　商品
　　　コースティングバイク
　　　
　　環境
　　　販売戦略
　　　安全な走行場所

　日本のシマノはもっとすごいことを！

　シマノ全体→ありとあらゆるものを・・

　わが社はどんな企業であるべきか？

３．意識的イノベーションプロセス
　除染技術開発におけるイノベーション
　→テーマ決めてのんびりはできない

　課題
（１）当事者意識／使命感
（２）多様な経験／人材
（３）意見交換／チームワーク
（４）プリコラージュ／試行錯誤
（５）実用性の探求／改良

デザイン思考
　→意識的プロセス：今、何のための作業なのか？
　　知的な協業の場を意識的につくる

従来の知財業務とデザイン思考による知財業務は違うのではないか

---------------

ニューロサイエンス
ニューロマーケティング
　　体験に基づいたものか？

次なるデザインの記憶とは？NEXPECTATION
　　クロスモーダル

期待学の実践の方針
　　今まで機能どおり：ファンクションリクアイアメントに答える

　　アブダクション：ジャンプをする
　　　共感を得るためのブランディング

デザインをどこで評価するか
　　はじめの印象？
　　使っていって？
　　愛着？

期待学における差別化
　　ねじれの正当化
　　おもてなしは予測→記憶

　　予感、予想、予測、予見、予知

　　出会い
　　学習
　　予測

期待学の基本的発想
　　プロスペクト理論

UAI：不確実性回避の各国インデックス
　　不確実性が心の中に入ると不安
　　不安：日本人の多くは恐怖の前段階ととらえる

　不安と恐怖遺伝子
　　セロトニントランスポーター遺伝子

　不安は進化を生む

　感情予測と期待

　期待不一致理論

　感情の仮想化
　　　おこったかたち、やさしいかたちは共通する
　　　でも、「せつない」きもちを表現してもらうと違う

PEAMモデル：期待学のエンジン

感情は記憶のために発達した
　　→もう、そんな目にあいたくない、
　　　また、会いたい

脳は違いを見つけることが快適
　似てるところを探すのは飽きる

記憶における遷移モデルRTM理論

ブランディング：思い出して・・・
　　→リマーカブル、Nexpect次を読む

期待以上と期待通り
　リスクにさいなまれた中にしか、感動はない！
　→想定外の満足は感動、
　　ただし一歩間違えれば期待はずれ
　→勇気ある企業を求める！

満足度の高いクルマは失敗が多い
　ユーザー調査で満足度が高い：とがったものしかやっていない
　→数は売れない
　ケータイに満足度調査をしたら？
　→スマホが出たら？
　　軸のむこうに
　マス・カスタマイズ

ロングセラーはなぜ生まれるのか？
なじむ？→・今日は今日の新しい自分がいる
　　大きく売れたもの：メディアの力？
　　そうでなく売れる：輝いている？
→使い込まれることまで読み込んで設計する

ロングセラー
　　新規顧客：期待以上のものがある
　　同じ人が繰り返し：不確実性を回避する→ある程度満足

JavaScriptのフレームワークknockout.jsのHello worldサイト

どっちなんだ？

　インフラジスティックスから、「Knockout.js ってご存知ですか?」っていう宣伝メールが来て、そうそう、JavaScriptのフレームワークだよね！とおもって、

「Knockout.JS - Hello World example」をクリックしたら
・・・リンク切れ（－＿－；）

でも、興味ありありなので、Knockout.JS - Hello World example
でビーイングったら（ってことばはあるのか？）

Knockout.js
http://knockoutjs.com/index.html

の

Hello World example
http://knockoutjs.com/examples/helloWorld.html


と、


Kockout　MVC
http://knockoutmvc.com/

の

Hello world
http://knockoutmvc.com/HelloWorld


の２つがあるんだけど・・・どっちなんだろう？

メイカーズ革命 オートディスクにおける３Dプリンタ

28日に、リーンカンファレンス２０１４にいってきた内容のメモメモの続き。
「メイカーズ革命　オートディスクにおける３Dプリンタ」についてメモメモ。

---

ソフトウェア
　・Autodesk
　　　プロフェッショナル向けツール
　・Autocad、Inventor（３次元CAD)、3dsMax（CGを作る）

新たなプラットフォームデバイス
幅広いユーザー
目的・用途の多様化

世界がVUCA（ぶか）になった
　変動性 Volatility
　不確実性 Uncertainty
　複雑性 Complexity
　あいまいさ Ambiguity

機能重視からユーザーエクスペリエンスへ

output→outcome
　バグのかず→お金で勘定されていた
　いろんな指標でネットプロモーターズ
　　不具合の期間とか

一般消費者向けクリエイティブツール
　Autodesk 123D
DIYコミュニティ
　instructables

写真をインプットすると３Dデータができる
www.123dapp.com

そしてプロフェッショナル向け製品のコモディティ化
　　複雑で高機能なツールを使いこなせない
　　価格競争が激化
クラウドコンピューティングの普及
　　ソフトウェアのあり方の変化
　　利用形態の変化
所有からコンサンプション（利用）へ
　　ビジネスモデル→サブスクリプションへ
　　ライセンスモデル→レンタル、ペイ・パー・ユーズ

コンサンプションエコノミクス
　　クラウド時代を乗り切る
　　ビジネス再生の新ルール

ハードウェア
・Makers　クリス　アンダーソン
　→誰もがMakerになれる！

・デジタルファぶりケーション
　　３Dプリンティング
　　３Dプリントサービス
　　３Dプリンターが使える工房　TechShop,FabLab,f.Labo

・リーンスタートアップ

・ハードアップスタートアップ
　　OUYA：オープンソースのゲーム機
　　cerevo（せれぼ）

・クラウドファンディング
　　Campfire
　　ぺブル腕時計

・IoT：モノのインターネット

・ソフトウェアメーカーがハードウェアをリリース

・GE Report　The Biggest Startup：

米グーグル、モトローラ売却へ→レノボにより、「美しすぎる研究者」だよねえ～

いま、本家のブログを書くために、ネット見てて知った


米グーグル、モトローラ売却へ＝中国レノボに2970億円で
http://headlines.yahoo.co.jp/hl?a=20140130-00000021-jij-n_ame

(以下太字は、上記サイトより引用）


米グーグルは29日、2012年5月に買収した携帯電話機大手モトローラ・モビリティを、中国のパソコン大手レノボ・グループに売却すると発表した。売却額は買収額の4分の1以下となる29億1000万ドル（約2970億円）。


ただし、

グーグルによるモトローラ買収は当初から通信関連の特許を囲い込むことが最大の狙いとみられ、モトローラが持つ特許の大半はグーグルが引き続き保有。レノボには使用ライセンスを供与する。


とのこと。

でも、そんなことより、「美しすぎる研究者」だよねえ・・・

ビッグデータのオープンソースETLのTalendとか、BIのActuate(BIRT)とか

昨日「TalendとActuateでビッグデータ資産をセキュアに活用する方法」を聞いてきた。
その内容をメモメモ

---

社内外のデータを徹底的に活用する！
～データドリブン経営を実現するTalendのご紹介～

■Talendについて
・２００５年　フランスにて２人のエンジニアが創業
・talendに投資してくれた人＝ビジネスオブジェクトの人
・前年度売り上げ成長率　１２８％
・２０００００００ダウンロード、日本でも１０００人
・ユーザー数１００万→４０００社が導入企業（商用：日本２２０社程度）
・Open　ソースコード、ビジネス
　　→データインテグレーション
　　→コミュニティ４５０００人（４番目）
・１５００名の品質テスター
　→社員は４００名：コミュニティでテストしてくれる
・５００＋のアダプター
・ユーザー
　　まぶちもーたー、三菱UFJインフォメーションテクノロジー
・設立依頼、データ統合にフォーカスしてきたビジネスをしてきた
　Talend→I love Data

■データドリブン経営
ユーザーに聞けばわかる
・従来方式
　月９方式
　トレンド俳優なら視聴率がとれる

・かつ方法
　お願いランキング
　理論系系＋科学

かん、経験、度胸→仮説検証データ分析

データ処理
・仮説検証
　　データ処理、データ統合

・ビッグデータ
　　構造化データ＋質のよい非構造化データ

・てらでーたのステファン
　　大量
　　　ビッグデータ→インタラクションデータ
　　　　→トランザクションが生まれるときのデータ
　　質が重要なのか
　　　→そのとおり

■Talendはビッグデータを活用するデータドリブン経営を支援します
　データに基づいたほうが勝てる
　ビッグデータ活用の５つの課題
　　量と処理速度
　　ソースの拡大
　　複雑性
　　適時性
　　整合性

　オープンデータ：政府が統計処理してしまう

　事実
　→
　本質：質より量

■何からはじめる
　　データ収集　
　　データ統合
　　データ分析
エンタープライズで使えるようにする：エンタープライズシリーズ
・組織の内外にあるデータ資産を統合
　　Hadoop,Nosql,Opendata,センサー

■他者がまねできないTalendの優位性
　　オープン性
　　先進性（YARNに対応）
　　ビジネスモデル

■BigDataのコミット
　　Easy To USE
　　Hadoop　Power

・MapReduceの取り扱い、
　データの収集

・Talend 5.4

・YARN→MapReduceの次
　　TalendはYARNの上でもネイティブに動作

・データ処理が飛躍的に早くなることで何が変わるのか

・Map処理、Reduce処理をシミュレートできる

■クラウド
・オンプレミス環境とクラウド環境の橋渡し
　　amazon
　　Treasure Data
　との接続にも
　　
・親和性が高いビジネスモデル

■まとめ

なぜTalendがデータドリブン経営？
　当初からI love Data
なぜデータドリブン経営が重要
　競争に勝てない
なぜ今データドリブン経営？
　ビッグデータが扱いやすい

---

【ビッグデータインテグレーション製品】

■Talendのアプローチ
　　ベスト・オブ・ブリード
　　ユニファイドプラットフォーム

■コードジェネレーション
■標準、普及技術の準拠

■オープンソースと商用製品
　　ねてぃーざにも対応
　　Neo4j（グラフ型）

・Hadoop→DWHの最適化

・最適化
　　アーキテクチャ
　　　　ビル・インモン　DWH
　　ツール
　　設計
　　技術

・Hadoop適用例
　　コールドデータの保存場所
　　ステージングエリアの適用（前処理）
　　ハイブリッドDWH（外部データ）
　　ETL処理基盤としての適用

・要求
　　プッシュダウン処理方式
　　データ量への拡張性
　　NoSQLサポート
　　双方向性
　　スキーマオンリードへの対応
　　データストアへの透明性

・Talendは？
　２０１０年Hiveサポートから
　GUIベースで
　SOAP,REST、メッセージキューの連携
　SAP　Hanaのコンポーネントもあるよ！
　ケルベロス認証のしかけ

■運用
１．Talend Studioでジョブ設定
２．共有リポジトリで自動格納
３．TAC(たれんどあどみにすとせんたー）
　スケジュール、ジョブフロー
４．ジョブ実行
５．運用監視モジュールで監視

■ユーザー
・シティバンク
・ボーだフォン（UK　CDR：通話履歴）
・フランス内務省（ドライバー）

■ビッグデータにTalendをつかうと・・
・自動運転を実現
・MapReduceをGUIで開発
・サブスクリプションモデルにより親和性の高い課金モデル

---

【Actuate
パーソナライズビジネス分析プラットフォーム】

インフォメーションデリバリー（ID)
ビジネスインテリジェンス（BI)
データアナリティクス（DA)
　→パーソナライズビジネス分析プラットフォーム

通常は、OLAP
Actuateは、定型レポートを高速＋BI
　　→レポートが基本
　　　レポート検索だから、高速化できる！

データアナリスティクス

■Actuate
・オープンソース　BIRTベース
　　→eclipseで作れるよ！
　　　互換があるよ！
・スケーラビリティも、
　　→ミッションクリティカルでも！

・ピュアブラウザでOK
　　→モバイルもOK、利用環境を問わない

■インストールするソフト
２つ
　・デザイナーライセンス（BIRT Designer Pro)
　　　→Eclipseで作る部分

　・サーバーライセンス（BIRT　iHub)
　　　ブラウザで見る部分

■実績
・５００社以上
　　→みずほ信託銀行、三省堂、エステー、阪急交通等

■デモ
・サーバーからブラウザ表示
・PDF表示
・Excelに落とす
　　→データが非表示になっている
　　→アップロードもできる
・カスタマイズ
　　→ピボットテーブルも作れる
・ダッシュボード

・作り方
　・データソース：どこからとってくるか
　・データセット：SQLとか
　・ドラッグアンドドロップでもOK

・データ分析

---

【エアー社のプレゼン】

■クラウドサービスの課題
・データ大丈夫か？
　→知らぬ間に公開
・セキュリティに不安、個人情報、機密情報の所在
　→Googleカレンダー情報を公開していた

クライアント側で暗号化：問題

wise encrypt
　検索、ソート可能な文字の暗号化技術を提供するライブラリ

派生開発のXDDPとかの話を、USDMの清水氏から聞いてきた！

昨日、リーンカンファレンス２０１４にいってきた。その中の講演の１つ「派生開発をリーンにするXDDP」をメモメモ
XDDPとUSDMの清水吉男氏ともう一人（だれだったっけ？）のかけあいの形で講演してました。

---

派生開発をリーンにするXDDP

■派生開発推進協議会（AFFORDD：あふぉーど)の紹介
　　２０１０年２月
・派生開発カンファレンス（次回６／６）
・１０テーマほどの研究会
　　・調整の克服方法
　　・USDMの入門
　　・XDDPの入門など
・研究会主催の「フォーラム」
・XDDPやUSDMに関する勉強会

■派生開発とは
・組み込みの現場では使われていた言葉
　　→改造（保守という言葉はつかわれなかった）
　　→既存のソースコードをベース
　　　機能追加が入る
　　　　→背景：競争＝予想できない→くずれていく
・派生どれくらい？
　組み込みの９０％以上は派生開発

・派生開発の課題とは？
　新規開発だと、工数と予算がつく
　でも、派生開発だと→変更＝納期がシビア
　　→変更行数で見積もられたら大変！
　要求仕様を書いて・・・
　　派生開発はそういううパターンではない
　　　　機能追加と変更がまじっている
　　　　変更のところで大きく
　　　　　→プロセスが合わない
　　新規開発くずし
　　　　変更箇所を完成させていく
　　　　　文章を完成させるように変更
　　ソースコードしかない会社
　　　　ソースコードをいきなり変更
　　→変更に対するデグレード：品質低下

・ソフトでリーンというと、アジャイル開発
　　XDDPとスクラムで発表されている
　　成果物が伴っていないと
　　変更という考え方がアジャイルでは対応しにくい

XDDPとは
・XDDP機能追加と変更依頼＝仕様知ってる人、国内にいない
　　→保守のプロセスではできない

・部分理解を前提としたレビュー中心の手法
　　→この方法でいける！
　　　ソースコードが分からないケースでも

・機能追加と変更を異なるプロセスで
　　AをBに変更→それいがいの箇所を探す
　　要求が異なる
　　変更３点セットの最小限の成果物を作る
　　　　変更箇所：Before→After
　　　　　Before：担当者の理解

・XDDP：コーディングをすぐしない

XDDPとリーン
・無駄をなくす
・品質を作りこむ

・知識を作り出す
　　AをBに直す→思わぬところに不具合＝わからない
　　　関係ないならバグでないはず！
　　　変更箇所を残している＝後ろから探れる
　　　→知識がたまる

・決定を遅らせる
　　いきなり変更：早く片付けたい→変更量を見積もっていない
　　　→変更同士が絡み合う：さっさと変更することが早くならない
　　　→１つの条件：見積もれている
　　　→生産性データを使う→ここまで遅らせるということがわかる

・似ている考えかた
　　手戻りを減らしたい
　　LAMDAプロセス→レビューを小さくまわす

ソフト
　　依存性が高い：XDDP
　　依存性が低い：アジャイル
ハード
　　依存性が高い：リーン製品開発
　　依存性が低い：リーン生産（TPS)

派生開発
　　変更してバグになった→ばんそこはってなおす
　　　→ソースコードは劣化している

レビュー
　変更要求仕様書：ここを、なぜ
　変更方法を考える：トレーサビリティマトリックス
　変更する
レビュアー：自分のシマにはいってしまう
トレーサビリティ　マトリックス（TM)
　原則、全部立てる。並べ方を変えない　

ソフトウェア開発を加速させるリーン開発の原則

昨日、リーンカンファレンス２０１４にいってきた。その中の講演の１つ「ソフトウェア開発を加速させるリーン開発の原則」をメモメモ

---

・リーン開発の原則
　ソフトウェア開発の現場で継続的な改善のきっかけを見つける視点を提供

・スピーカー：天野　勝　氏
　　これだけKPT（振り返りのときに使う）
　　日経コンピューターで連載

・会社
　　福井県にあるのが売り

・リーンソフトウェア開発とは
　リーンから、リーンソフトウェア開発へ
　リーンの日本語
　　　がりがり？
　　　贅肉を落とした（ほそまっちょ？）○

　リーンの起源
　　　トヨタ生産方式の研究
　　　TPSの家（出展「ザ　トヨタウェイ（上巻）」
　　　トヨタウェイ→ジャストインタイム、自働化

・リーン思考の原則
　　リーンシンキング
　　　製造、製品開発の原則：７つの原則
　　　→応用可能（金融業務、保険、医療）

・リーンソフトウェア開発
　　　日本だと２００５
　　　２００９年に本質 from concept to cash
　　　　→儲かるのが正義
　　　　　アイデアをいかにカネに変えるか

　ソフトウェア（ITサービス）の特徴
　　・開発のメインは設計
　　　　製造やデリバリーの開発／コストはわずか
　　　　　製造：コンパイルする、コピーする
　　　　　デリバリー：サーバーに配布する、利用者がサーバーにアクセスする

　　・リリース後の改修コストが低い
　　　　　回収は不要

　　・物理法則が及ばない
　　　　　重さ、大きさがない
　　　　　劣化しない
　　→製造の考え方は、そのままは通用しない

・リーン開発で重視する「品質」
　　品質の定義　SQuBOKから
　　　　→人の名前がはいっている（～がいった）
　　品質が高ければ儲かる：不具合があるかないかではない
　　余分な機能の無駄→まったく利用されない機能４５％

・リーン開発
　　言ったもん勝ち？
　　ニーズ→システム
　　　システム開発にはさまざまなリスクが潜んでいる

・ニーズに合う商品を提供するために
　　無駄を省いてニーズの獲得から商品提供をすばやく行う

・アジャイル開発
　　技術の総称：ひっくるめて！
　　アジャイルソフトウェア開発の誕生
　　　　→アジャイルソフトウェア開発宣言
　　AKB：事務所はちがうけど、同じ名前で
　　アジャイル：さまざま手法違うけど、同じ名前で

　　ポペンディック夫妻：この宣言の人ではない

　　アジャイルとリーンの関係
　　　図がある

・リーンソフトウェア開発の原則
（１）無駄をなくす
　　　ポペンディックさん「ソフトウェア７つの無駄」もかえている
　　　無駄に３つの種類
　　　　　お客さんの無駄：レビュー（レビューせずにいいものができれば）
　　　　→生産性があがる
　　　　　　組織の無駄を０にすれば、付加価値にあがる

　　　バリューストリームマップでプロセスの無駄を見る

（２）品質を作りこむ
　　作って直すのではなく、直さないように作る
　　→テスト駆動開発
　　　後で直すより、早く直せば安くつく

（３）知識を作り出す
　　学習サイクルをまわしながら進める
　　　　振り返り
　　　タイマー駆動／イベント駆動
　　　イテレーション内でPDCA

（４）決定を遅らせる
　決定を遅らせた分だけ知識が増え、ぎりぎりまで磨ける
　　　→ぎりぎりがどこまでか？
　　　→継続的インテグレーション　VS　ビッグバン結合
　　　　　モジュールを少しづつ足す

（５）早く提供する
　提供能力を上げる
　イテレーションからフローへ
　　　→カンバン、継続的デリバリーを自動で

（６）人を尊重する
　　ともに働く人
　　リーダーシップのあり方
　　　　支配型リーダーからサーバント型へ
　　見える化
　　　　異常を見えるようにし、行動を誘発する仕組み
　　　　カイゼンの道具で管理の道具ではない
　　タスクボード
　　KPT(けぷと）
　　バグレゴ
　　振り返り会で出た　「机を取り払う」を実行

（７）全体を最適化する
　　全体が滞りなく流れる
　　KANBAN＝タスクボード＋流量制限

　　システム開発からビジネス開発へ
　　　→ビジネスとシステムは一体

テスト要求分析とテスト観点

昨日、西先生の「テスト観点によるテスト要求分析モデルの構築」
について聞いてきたので、メモメモ

---

■テストには、テストのための要求分析が必要である

テストする

５年位前
　テスト設計（ですと計画）、テスト実施

今どき
　テスト要求分析
　テストアーキテクチャ設計
　テスト詳細設計
　テスト実装
　テスト実施


■テスト開発プロセスの基本的考え方
・品質を高めないといけないプレッシャーは意外とさらされていない
・仕様で明記されていない非機能特性を考えていない

■テスト要求分析で考える
１）要求の源泉の準備
　　→自分たちでステークホルダーになりきって
　　　ブレーンストーミングや仮想ヒアリング
２）要求獲得と分割
　　エンジニアリング要求とマネジメント的要求をわける

３）モデル

■テスト観点
　・機能：テスト項目の鳥が
　パラメータ
　状態
　タイミング
　組み合わせ
　性能
　信頼性
　GUI
　出荷先
　障害対応性
　セキュリティ
　（いくつかぬけた）

■テスト観点をモデリングする
　マイヤーず
　システムの振る舞い

■テスト観点
　　因子？
　　要求？
　　テスト目的？

・テスト観点
　　→正三角形
・テストケース
　　→１，１，２、　１，２，３

・テストスクリプト
　　→ぱそこん・・・

テスト観点図（NGT)
VSteP

漏れをなくす→ステレオタイプ

詳細化の種類を限定して

テスト観点図に書き直す
条件ベース：抜けがある
　　リコメンデーション部分のテストがない
　　あいまい記述が抜ける
　　おいしくないが抜けている
観点ベース：抜けがない

GSNとか、アシュアランスケースとか

昨日、KBSEの「アシュアランスケース超入門」を聞いてきた！
その内容をメモメモ

---

アシュアランスケース超入門

アシュアランスケース（AC)概要
AC研究課題
　プロセス開発
　言語設計・実装
AC超入門

・なぜACが必要なのか
　私たちを取り巻くシステム環境の変化
　　システムの大規模化
　　利害関係者の合意保証

・安全性、ディペンダビリティをどのように合意保証
　　１９８８年の北海油田事故
　　　→ACの提出義務付け
　従来は宣言的、これはゴール指向

・アシュアランスケース（AC)とは
　　システムが与えられた適用先と環境で
　　十分にディペンダブルであることを提供
　　する構造化された証拠ドキュメント

・ACの呼び方
　　日本語だと保証ケース
　　　ケース：証拠書類
　　安全性：Safety　Case
　　ディペンダビリティ；ディペンダビリティケース
　　　→ACは、全部を含めた言い方

・ACの背景
　　１９７４　一般的概要
　　１９８４　Seveso　Directive
　　　　　組織事故（日科技連）
　
・Safety　Caseの評価
　　肯定的：ゴールベースな規格認証
　　否定的：本当に効果的？Nancy Leveson

・ACとは何か
　　ゴール：システムは安全である
　　前提：ハザードリスト
　　議論の流れ
　　展開
　　テスト結果：確かな証拠
　　GSN

・ACとクリティカルシンキング
　　→トォールミン

・ACの研究課題

・ACプロセス開発
　　個別の規格認証のための方法はあるが・・
　　ACを行うことで、本当にシステムの安全性・
　　ディペンダビリティはあがるか？

・ACの実証実験
　　ACの評価→評価項目をどう作るの？

・ACの評価項目
　　プロセス品質
　　プロダクト品質

・効果：
　１．実施内容の確認
　２．成果物作成前の作業内容確認
　３．プロセス品質が達成されていることの検証
　４．プロダクト品質の証明→エビデンスで

・どこでやるのか？
　　要求分析のAC
　　　シナリオ分析
　　　モデルベース分析
　　　リスク分析

・ACのコスト

・目的が大切
・作成時に戦略を立てておかないと

・アシュアランスケースの記述法
　　→GSNパターン言語
　　→関数型言語では？
　　→D-Caseエディタ
・先行研究
　　定理証明器
　　パターン

・ＡＣ超入門
　　ＧＳＮ
　　ＣＡＥ

・表記法（７種類）
　　ゴール
　　戦略
　　前提（ガイド情報）
　　未達成
　　エビデンス
　　前提関係（ゴール、戦略と前提）
　　ゴール関係（ゴールと戦略）

・記述基本規則
　　ゴールはＳ＋Ｖの形をした命題
・戦略は、サブゴールに分割する議論の仕方
・前提：システム運用環境、定義
・前提ノードは文章ではなく、前提となるドキュメント
・証拠ノード

ＧＳＮの書き方
１）議論構造の図解
２）ドキュメントから作る方法
３）具体例
　　戦略で分割方法を示す場合は、
　　前提が上位ゴールか戦略にないといけない

Linuxデバイスドライバの作りかた（２．６以降） その１

Linuxのデバイスドライバの作りかたをメモメモ。

【参考】

以下のサイトをもとに、作成しています。

Linux Kernel 2.6.x プログラミングガイド
http://uguisu.skr.jp/algo/device.html


【動作確認環境】
ubuntu
（なので、suしてrootでやるところは、sudoしてる）

---

■手順

１．ソースを作成する。

上記サイトを参考に、以下のファイルをhello.cとして作成した

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");

static int hello_init(void) {
    printk(KERN_ALERT "Hello world!\n");
    return 0;
}

static void hello_exit(void) {
    printk(KERN_ALERT "Goodbye\n");
}

module_init(hello_init);
module_exit(hello_exit);

２．Makefileを、以下の内容で、上記hello.cと同じフォルダに作成

obj-m   := hello.o

KDIR    := /lib/modules/$(shell uname -r)/build

PWD     := $(shell pwd)

default:

        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

３．コマンドラインからmake
sudo make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules

４．実行
sudo insmod hello.ko
　　→デバイスドライバのインストール

sudo lsmod
　　→入っているデバイスドライバの表示


５．削除と書き出し内容の確認

sudo rmmod hello.ko
　　→デバイスドライバのアンインストール

dmesg
　　→デバイスドライバでprintkで出したものを表示


（dmsgの下のほう：２回実行したので、２回出ている）


※uname -rは、実行するとわかるけど、linuxカーネルのバージョンを返す。
　つまり、makeの-Cで、カーネルのバージョンに対応した/lib/modulesを
　渡している

統計モデル その１０ 順序・名義変数を使ったSEM

統計モデルの続き、順序・名義変数を使ったSEMについて
講義のメモメモ

---

・カテゴリカルデータを含んだ多変量解析
　　→順序変数で通常の相関係数を出すと、精度が悪くなる

・閾値のモデル：連続変数が背後にある

順序変数を取り扱う方法
　　（１）四分相関（テトラコリック相関）
　　（２）ポリコリック相関（重分相関）
片方が順序変数、片方が連続変数
　　（３）双列相関（シリアル相関）
　　（４）ポリシリアル相関（重双相関）

注意：２変量正規分布になっていないものを当てはめるとX
　　　相関係数がソフトで異なるかも（大きな問題にはならないかも）


※ピアソンでいくかは微妙。
　５件法、４件法？
　　→２件法、３件法は、上記の方法
　　　４件法グレー
　　　５件法ピアソンの積率相関で
※５件法：どちらでもないにつける人おおい→正規分布になりやすい

変数の種類
・質的変数／カテゴリかる
　　・Ordinal:順序
　　　　　　２カテゴリ
　　　　　　多値
　　・Nominal：名義　順序性がない、相関X：性別とか
・量的変数→ピアソンの相関
　　・間隔尺度
　　・比尺度：０がある

SEMにおける順序変数の扱い方
　　潜在変数Z
　　　　正解不正解　不正解０、正解１

SEMにおける名義変数の扱い方
　　潜在変数を置けない
　　　　潜在行動変数
　　　　　独立変数
　　　　　　ｔ検定、分散分析と同じになってくる
　　　　　じゅうぞく変数
　　　　　　ロジスティック、
　　　　　　多項ロジット

ライアビリティを想定
　　潜在変数Z、閾値ある→分布分かれる
標準正規分布
　　ライアビリティ
２変量正規分布
　　相関によって、大きさ違う
　　　→てとらぽりっく相関
２変量正規分布を区切る：４つのパーツ
３カテゴリ以上；２変量正規分布、閾値が違う
一方が連続
連続X２かてごり　シリアル
連続X３かてごり　ポリシリアル

順序変数を含んだSEM
　　Sのijテトラコリック相関
　　推定：一般化最小二乗法
分布が正規分布で全然ない！
　　→適当に切って順序尺度へという手も

統計モデル その９ 潜在クラスモデル

統計モデルの続き、潜在プロフィルモデルと潜在クラスモデル、
それと潜在構造分析を使って、非線形のものをもとめる、バウワーの方法とかをメモメモ

---

■潜在構造モデル
　　潜在混合分布モデル　　観測変数：連続変数　　潜在変数：質的変数
　　潜在プロフィルモデル　観測変数：連続変数　　潜在変数：質的変数
　　潜在クラスモデル　　　観測変数：質的変数　　潜在変数：質的変数


■潜在プロフィルモデル
　＝潜在混合分布モデルの下位モデル
　　共分散行列が対角行列
　→e1,e2,e3,e4とかの間の関係がない

・ギブソンが１９５９年に導入
・因子分析モデルに似てる
　　構成概念が潜在クラスであるような因子分析モデル

・対角行列であると言う制約を入れるか、各クラスの共分散行列が同じかどうかで
　以下のようになる

モデル１：対角／なし、各クラス／なし＝潜在混合分布モデル
モデル２：対角／なし、各クラス／あり＝判別分析流の級内分散行列モデル
モデル１：対角／あり、各クラス／なし＝潜在プロフィルモデル
モデル１：対角／あり、各クラス／あり＝因子分析的モデル


■潜在クラスモデル
　　ｎ個の尺度名義の観測変数の背後にｃ個の潜在クラスを仮定
　　潜在クラス内では、観測変数が互いに独立（局所独立）

・ある潜在クラスｃ内において観測ベクトルuが観測される確率
　　　→観測される確率の積となる（独立の場合）
　全体母集団から、無作為に標本を取り出したときuの分布
　それ(u)がN個観測される尤度を考える

・積率構造
　　潜在クラス分析は積率構造分析の下位モデル
　　積率行列は確率行列に一致する


■バウワー(Bauer 2005）
　潜在構造分析を使った非線形関係の表現
　非線形
　　・１次の項、２次の項、３次の項
　　　→３クラスの分けて単回帰
　　・クラスの確率を求める
　　・予測値＝各クラスの確率＊単回帰の和

→単回帰では表現できないものも、こんな形で扱える！！！

■コメント
・実際には、すべて潜在クラスモデルと言っちゃってるケースが
　　→潜在的なクラスをみつける

3Dプリンタでバレンタインのチョコ作り

昨日、３Dプリンタの話、聞いてきた（厳密に言うと違うけど）
その話、書こうと思ったけど、時間がないので、また今度かく。
だけど、その中で興味深い話をいくつか・・・

３Dプリンタ、実は難しい・・・
　　くっつかない
　　それてしまう

ビジネスモデルが大事
　　事例：
　　　　・歯科矯正具
　　　　・お菓子作成

→たとえば、3Dプリンタでバレンタインのチョコをつくるとか
　（あれ、バレンタインって、いってなかったかな？
　　それとも、３Dプリンタでチョコ作りまでがあって、それをバレンタイン
　　でやったらという話だったか・・・忘れた　＾＾；）

特許訴訟で意見公募－アップルＶＳ．サムスン

アップルＶＳ．サムスン特許訴訟で意見公募　知財高裁
http://headlines.yahoo.co.jp/hl?a=20140124-00000013-asahi-soci

によると（以下太字は上記サイトより引用）

スマートフォンの通信技術をめぐり、米アップルの日本法人と韓国サムスン電子が知財高裁（飯村敏明裁判長）で争っている特許訴訟で、双方が２３日、争点について意見を公募することで合意した。重要な論点を含む訴訟だとして高裁が提案したもので、日本初の試み。広く英知を結集して判決を出そうとする「市民参加型」訴訟といえそうだ。


おお、意見が言えるわけですね！

意見を募るのは、重要技術の特許権を持つ企業が「有料で使用させる」と表明したが、交渉不調などで、使用料が支払われないまま他社がその技術を使った場合、損害賠償請求権を行使できるかという点。

？？このまま素直に考えたら、行使できそうだけど、
きっと、なんか、そこに裏があるんですね、わかります・・

動画再生ソフト「ＧＯＭプレーヤー」更新で感染

ここの記事

動画再生ソフト「ＧＯＭプレーヤー」更新で感染
http://news.goo.ne.jp/article/yomiuri/trend/20140123-567-OYT1T01596.html

によると(以下太字は上記サイトより引用）


　推定６５０万人が利用する動画再生ソフト「ＧＯＭプレーヤー」のアップデート（更新）の際にウイルス感染させる新たな手口のサイバー攻撃が行われていることが分かった。


で、どういうかんじかというと

　ソフトは開発元のグレテック（韓国）の正規品だが、起動させると「アップデートのお知らせ」との偽の通知がパソコン画面に現れ、更新すると感染する仕組み。


問題はその手口

何者かがソフト更新用のサーバーを攻撃して、利用者を不正サーバーに転送させるよう工作していたとみられる。

更新サーバー攻撃ですか。。今後、他でも使われそうですね！