ソフトウェアエンジニアのための「機械学習理論」入門

JTF2015にいってきた。

ソフトウェアエンジニアのための「機械学習理論」入門

をメモメモ

---

背景
・機械学習は結構前からある
・ツールがオープンソース＋ディープラーニング：某日経ＢＰがあおりだす
　　オープンソース好きを助けたい
　　日経の人が煽ると、１年後に忘れ去られる→ちゃんと使えば役に立つ
　　　　場図ワードで終わらせたくない

ＮＩＩの資料を使うよ（数式スキップ！）
・第二部の途中くらいまで

・データサイエンスと機械学習
　パーツを組み合わせて、データサイエンス

・いろんな判断
　　→なににもとづくか
　　　　　データに基づいて、過去のデータから判断：データサイエンス
・データサイエンスに必要な知識
　　・ビジネスの理解
　　・分析理論の理解
　　・データの理解

・データサイエンスの誤解
　データサイエンティスト：事実を明らかにする？
　ビジネス判断はスーツの役割？→誤解
　　→ビジネスに役立つ判断まで導く

・どんなふうに機械学習を使うか
　　アルゴリズム
　　過去のデータ
　　判断できる

・機械学習アルゴリズムの分類
　　分類（ＡかＢか）
　　回帰（数値で判断）
　　　　誤差関数（最小２乗法）による回帰→２乗誤差を小さくする

　　オーバーフィッティングの問題→一般化力
　　　実際に良くやるのはテスト用データを用意しておく

・いけてない機械学習の例
　　分類：決定木→根拠ない：比較検討
　　データの理解

・試行錯誤で見つけ出す方法
　　テストセットを用意しておく
　　ビジネスに適用してみる→いいアルゴリズムを適用する

wantedlyでＣＴＯは、３４０件みつかる

JTF2015にいってきた。その内容をメモメモ

まずは基調講演（途中から）

---

１．変化を楽しむ柔軟性を持とう！
　　　世界でパソコン５台？
　　　Flash VS HTML
　　→未来の予測なんてできない
　　→世の中変わる→技術革新→時間ができる→新たな技術革新

　　Ｗｅｂアプリケーションフレームワーク
　　クラウドコンピューティング

　　技術革新を起こし続けるＡＷＳ
　　ＡＷＳのサービスの数は４５以上に
　　Ａｍａｚｏｎ　ＲＤＳ
　　Amaazon AURORA
　　フルマネージド
　　Ａｍａｚｏｎ　ＤｙｎａｍｏＤＢ

　　Ｓ３，ＥＣ２のインフラ提供から、
　　ミドルウェア
　　その先に、Ａｍａｚｏｎ　ＬＡＭＢＤＡ
　　　　Ｎｏｄｅ．ｊｓとＪａｖａで書ける
　　　　サーバーレスなプログラム実行環境
　　Ａｍａｚｏｎ　ＡＰＩ　Ｇａｔｅｗａｙ
　　　　ＡＰＩ作成支援サービス

　　新しい技術を楽しもう！楽をしよう！

２．楽しいと思ったのものにのめりこもう
　　強みがあると強い
　　○○の○○さん

３．技術は手段であると心得よう
　　技術を目的にすると間違った方向に行くかも
　　技術はなくなるかもしれないが、ビジネス課題はなくならない
　　価値を提供することが主、手段はなんでもいい
　　　　→ゲームの基盤の共通化：開発効率下がった
　　　　→Ｘマイクロサービスがはやっているからうちも
　　　　→○Ａの部分は、更新頻度が高いので、切り離して
　　　　　　疎結合に構成して連携

４．いけてるアニキや仲間を見つけよう
　どうやって出会うのか
　　　コミュニティに参加する
　　　イベントで登壇する
　　　大学や会社で出会う

まとめ

最後に
　これらを最短に身につけるには、スタートアップＣＴＯ
　wantedlyでＣＴＯ，３４０件見つかる！！
　Ｌｅｔ'ｓチャレンジ！

「SDM X 要求開発」でイノベーション

７月２４日（金）要求開発アライアンスの

「SDM X 要求開発」でイノベーションを！
https://redajp.doorkeeper.jp/events/27791

を聞いてきたのでメモメモ

---

ＳＤＭとは
あらゆる問題をシステムとしてとらえて
イノベーティブに解決するための
方法を創り、学び、実践する場です

デザイン指向を学べるところ
・慶応ＳＤＭ
・東大i-school

日吉にある
・４Ｋプロジェクタ

ＥＤＧＥ
・３Ｄプリンタがおいてある
・あまだなのたごまなぶさんがデザイン監修
・システムＸデザイン思考で世界を変える

第一部　ＳＤＭでやっていることと要求開発の違い

システムって何
・複数の構成要素から成り立つ集合体のこと
　　太陽系
　　おはし
　　エコシステム
　　ＩＴシステム

・ＩＮＣＯＳＥハンドブックでは
　定義された目的を成し遂げるための、相互に作用する

デザインって何
・あらゆるシステムの新しい構造や仕組みを創造する行為
　　　組織

マネジメントって何
・さまざまなシステムの事業・企画を管理すること

イノベーションって何
・イノベーションの３条件
　（ビジネスデザイナー濱口秀司さん（じーば）の提唱）
　　見たことも聞いたこともない
　　実現が可能
　　物議を醸すこと

システムズエンジニアリングって
・ＩＮＣＯＳＥ（いんこぜ）
　　システムを成功裏に実現させることができる
　　複数のディシプリンにまたがるアプローチ

デザイン思考って何
１．オブザベーション
　　デザイナーのように自由な心で対象を参与観察
　　エスノグラフィックな質的アプローチを重視

２．Ｉｄｅａｔｉｏｎ
　協創を重視

３．プロトタイプ

システムＸデザイン思考＝イノベーション

使われる手法
１．ブレインストーミング
２．親和図法
３．フィールドワーク
　　　：
　　：


要求開発と類似点
・要求分析ツリーとバリューグラフが似ている
　　はしごを登って降りてを繰り返す

・イネーブラー（実現子）フレームワークと

・ユースケース分析を重視します
・To-By-Using手法
　ゴール記述書
・プロトタイピングを重視する点
・匠メソッドとの類似点
　ＣＶＣＡ（顧客価値連鎖分析），
　ＷＣＡ（欲求連鎖分析）
　　→価値の可視化？

相違点
・ライフサイクル、コンテクストに着目する点
　ＩＳＯ１５２８８
　　コンセプト
　　開発
　　製造
　　運用
　　　　利用　サポート
　　　　廃棄　移行

ビジネスのライフサイクル
　　立ち上げ期
　　成長期
　　安定期
　　衰退期

・コーザル　ループ　ダイアグラム（因果関係ループ図）
　　→レバレッジポイント

・ブレーンストーミングの仕方
　　アイデアを大量生産するという観点で使います
　　　　批判禁止、のっかり、質より量

・概念モデルに関しては、要求開発の考え方のほうが
　洗練されている

まとめ
・発送する、発散させる→ＳＤＭ
・設計→ＩＴ

思想的類似点
・要求を開発する→課題の再定義（リフレーミング）
・イノベーティブか否か

要求開発への提案
・要求分析ツリー、概念モデルＴＦＰ分析

吉田類せんせい　モデリング
メタ目的は何なのか？


ワークショップ
・ブレインストーミング
　　思わず触ってしまうもの
・親和図法
　　ブレインストーミングで出たものをグループわけ
・強制連想法
　　グループ分けした表題Ｘ場所で、
　　老人が思わず触ってしまうロボット

必要とされるIT技術者に２種類いて、デジドカ（IT奴隷）は海外シフトしている

ここ

NHKの「IT技術者不足」特集にネット違和感 「足りないのは安く使えるIT奴隷でしょ？」https://news.careerconnection.jp/?p=14365

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


7月22日放送の朝の報道番組「おはよう日本」（NHK総合）で紹介された「IT技術者不足」特集が、ネットで思わぬ反響を呼んでいる。

番組はスマートフォンやネット通販の普及で、IT技術者の需要が高まっていることを紹介。

とあるけど、この番組をみていないので、なんともいえないけど、

少なくとも、この記事を見る限りにおいては、
そもそも、IT技術者には、２種類あることを考慮しないと、
話が？？？になってしまうと思う

---

ITで考えると分かりにくいので、建設業で考える。

建設業では
　　・一般のおうちを立てる大工さん（工務店）と、
　　・大きなビルをたてるゼネコン＋ドカタ
の大きく２種類が有る。

ゼネコン＋ドカタは細分化されていて、ドカタさんは、おうちを作れないし、
設計屋さんは、かんなかけたりはしない。
それに対して、大工さんは一人では無理かもしれないけど、
工務店レベルでは、家を１軒まるまる建てられる。

---

ITも同じで、
　　・有る程度の規模だけど、サーバーを立てて、アプリをつくり、ECサイトなどを立ち上げられる
というソフトハウスと、
　　・大規模アプリ開発を行うSIer＋ITドカタ（デジドカ、IT奴隷）とその派遣会社
の２種類がある。

番組はスマートフォンやネット通販の普及で、IT技術者の需要が高まっている

という場合は、多くは前者の、有る程度の規模のシステムが作れる人で、サーバーの立て方、設計、プログラミング、DB,ネットワークを一通り知っていて、さくらインターネットやGMOのサーバーないしは、Amazonクラウドでシステム全体が作れる人を刺している。
　この場合（＝前者）のソフト開発会社も注文する側の会社もどちらも中小企業で、人月単価も（直接契約なので）高く設定できる（実際には１社あたりは安くても、何社もかけもちできる）。

---

その一方、

「IT技術者じゃなくてIT奴隷が足りないんだろ」
「昔は韓国人技術者、ちょっと前は中国人技術者、そして今はベトナムなので、要するに『技術者が足りない』のは『安く働いてくれるヤツがいない』って言葉なのがスケスケなのが凄く残念。そりゃ僕らの手取りは上がらないよな…」

大手ベンダーならともかく、下請けや孫請けでは激務薄給が珍しくないIT業界。

の話で出てくるのは、大規模アプリ開発を行うSIer＋ITドカタ（デジドカ、IT奴隷）とその派遣会社の話。
この手の発注側会社にはすでにシステムは入っている。リプレース（モダナイズ）案件は限度があるので、高成長は期待できない。そこで、SIerは、単価の安い

　　韓国→中国→ベトナム→ミャンマー→バングラディシュ＝いまここ

に流れている。

このような開発は特定の知識が必要だが、全般的な知識は必要ない（だから勉強しない）
そこで、この方面であまったIT奴隷を、前述のECサイトなどに振り分けることができない。

---

いまはたまたま、モダナイズにも人がいなくて、あたらしいECとかの需要も伸びている。
だから、モダナイズ仕事に、SESでITドカタをそこそこの単価で送り込むことができるんだけど、いずれ、モダナイズ仕事は単価が下がってくる。
単価下がれば、経験者を送り込めないので、炎上する
炎上すると、人がいっぱいいるから、さらに単価の安い人（海外＆新人）をいっぱい送り込む・・

ということで、SESを中心としたモダナイズ仕事は単価も下がるし、海外にいくので、
国内の人手はいらなくなる。

国内では、中小で技術力のあるところは、いまから中小でもやり手ECサイトなどと組み、中小同士で固めてくる。ここは市場は広がるものの、有る程度の技術と業務知識がいるので、今、SESでモダナイやっている人が、はいりこめない。

ということで、今SESでモダナイなど、IT奴隷（デジドカ）やっている人は、
そのうち、あまってくる。

　今この手の人が、あまっているように見えないのは、仕事が好調で需要が有る割には、うつ病になってやめたり、仕事が馬鹿らしくなって転職したりしているから。経験者がそれほど育たず、そのうち（今でも？）新人や海外勢が多くなる。

だから、ECなどに需要があるからというので、この業界に人を送り込むと、
大変なこと（＝ITドカタが職なしであぶれる）になっちゃうのだ・・・

「宇宙エレベーターロボットを動かそう！」のプログラミング教室など開催－子ども霞ヶ関見学デー

総務省がやるみたいですね。夏休みの宿題向け？
モールス信号を打つ体験もできるそうです！！


平成27年度「子ども霞ヶ関見学デー」開催のお知らせ
http://www.soumu.go.jp/menu_news/gyouji/02koho03_03001112.html

(以下上記サイトより引用）

2.開催日時

平成27年7月29日（水）10時～16時、30日（木）10時～16時


3.開催場所

受付場所：中央合同庁舎2号館1階ロビー
会場：講堂（地下2階）、講堂前ホワイエ、1階アトリウム

StrutsからPHP(REST)＋HTML5（AJAX)に「業務を止めないで、段階的に」モダナイズする

StrutsからPHP(REST)＋HTML5（AJAX)へ
「業務を止めないで、段階的に」
モダナイズしたいという要望がある。

いっぺんに切り替えると、なんかあったとき大変だから・・・
（それと、お金の関係も有る）

この場合、StrutsもPHPもRESTにすればできると思う

つまり、
１．まず、画面をHTML5で作成し、Javascriptで、ボタンが押されたら、
　　Struts（＊.do）を呼び出すようにする

２．出力する画面のJSP(strutsタグ入り）を、
　　JSONでデータだけを返すように書き換える
　　そして、１で作成したHTMLを、*.doを単純によびだすのではなく、
　　AJAXで*.doを呼び出すようにして、処理結果（JSPで作成するJSON)
　　をJSONで受け取って、その変数をlocalstorageとかにいれて、
　　次画面に遷移するようにする

３．StrutsでJSONでデータを返しているプログラムを、PHPで書き換える

こうすると、段階的に、置き換えられると思う。

要求仕様「書」を、どこまで「書くか」？（実際、要求仕様書はどこで止めとくか）

さっきの


要求仕様は、どこまで書くべきなのか？（要求分析は、どこまで詳細化するべきか）
http://blog.goo.ne.jp/xmldtp/e/9760b1dd3f3eb3b0bdd676118ad388b8

なんだけど、結論が

機能要件は、出力と、入力データ、利用する関数・演算を決める
非機能要件は、事前に決めた非機能項目チェックリストをチェックする

となっていた。

でも、実は、要求仕様書をここまで決めて書くことは、
無いとは言わないが少ない。

---

実際には、「機能要件の合意形成ガイド」にあるように、機能要件は、外部設計完了時までに完了していれば良い。だから、上述の例でも、グラフと表の位置は、「見てから決める」ということにして、決めていない。

では、要求仕様書はどこまで決めておけばいいのか・・・
ということだけど・・・

「設計者が困らない程度」

に書いておき、要求仕様書が書き終わった段階で

「技術的に実現方法がわからない関数がない」

状態にしないといけない。

---

たとえば、位置を決めるというのは、設計者がどうすればいいかわかる。
（あとでレイアウト図を出して、このへん？このくらい？とユーザーさんに聞けばよい）
これは、先に延ばしてOK

しかし、グラフの場合で、棒グラフをグラデーションしたいなんていうとき、
技術的に出来るかどうかは、確認しないと分からない
（ライブラリを使う場合、Excelでグラフ表示しようとすると、
　グラデーションのライブラリが利かない可能性あり）
こういう部分は、要求仕様書が書き終わる前に、確認しておくべきこと。
PDFへの出力方法も同様。

具体的には、
　出力は、出力する「もの」の名前（帳票名、PDFファイル名、画面名など）と、
　これを出力しないと意味が無いというくらい大事な項目、

　テーブルでは、テーブル名と
　主キー（自テーブル、他テーブル（外部キーになる））

　入力データは、上記の出力データが出力できることを
確認できる程度

は必要。それ以上は、書かなくてもゆるされるかもしれない

非機能は、なんかしないといけない機能について述べる
けど、チェックしたんなら、全部出したほうがいい

なお、入出力に関しては、全体テンプレートがあるのなら、
全体テンプレートの内容を要求仕様書に書くかどうかは別として、
要求仕様書完成前までに出来ていると安心できる。
さらに、１～２個の画面例を作っておくとリスクは軽減する。

このほかの入出力（PDFなど）も、１～２個の例を作っておくとリスクは激減する。

---

実際の工数超過は、項目が１、２項目追加されたというより、
そのような表示は無理！ということによる仕様変更のほうが大きい。

たとえば、JQuery Mobileを利用して、AJAX+SPAを実現しようとしたとき、
AJAXを使って画面を書き換えようとしたら、画面リドローが起こらず、
画面が書き換わらないとか

IEで、位置を合わせようとしたら、X,Y座標を送っても、
その後位置合わせロジックが動いて、指定したところに
フォーム部品が動かない

などによる仕様変更のほうが、項目を１０個足すなどというより、
仕様変更度合いが大きい。
（前者は、SPAから、画面切り替えにプログラムを変えることになるし、
　後者は、setTimeoutで30ミリ秒後くらいに実行させるとうまくいくことあり）

このような危ない橋を渡らない為には、画面サンプル（一番難しそうな）を
作ってしまうことである。
なので、１～２個の例を作っておくとリスクは軽減する。

特に、デザイナーに画面周りデザインを頼む場合、いまだと、Javascriptまで
有る程度書いてくれる。。。けど、デザイナーによってくせがあるので、
どういう風に書くな・・・だから、こう仕様を切ろうという目安をつけるためにも
テンプレート作成までしてしまうと安心だけど、
これは、お金のかなる話（デザイナー代）なので、この段階で踏み切れるかどうかは
疑問だったりする・・・

要求仕様は、どこまで書くべきなのか？（要求分析は、どこまで詳細化するべきか）

しまった！昨日の


ベームの見積もりの不確実性の図やマコネルの不確実性コーンは、JQueryやREST、ＣＩ時代にも有効か？
http://blog.goo.ne.jp/xmldtp/e/e5a0154e483aaff790d930cbcdd65649


の前に、こっちを書かないといけないんだった。じゃないと意味が通じない・・・


要求分析は、詳細化していくと、どこまでも詳細化できてしまう。
では、どこで止めるべきか？
というお話。

---

まず、このとき、機能要件と非機能要件で分ける。

１．機能要件で、データの入出力を決める
　　　（GUIの様子とかではなく、項目とその文字種、桁数などまで）

２．非機能要件は、それ以外のUIや、性能などを決める

とする。

そしてこのとき、以下の事前準備が出来ているとする

【事前準備】
・非機能要求に関しては、非機能項目のチェックリストが挙がっていて、
　（非機能要求グレードを創造してもらうと良い）
　そのチェックリストにチェックを入れると、どのように実現すればいいのか
　技術的に分かっている（＝リファレンスモデルがある）

　例：GUIの場合、
　　データの型が決まってしまえば、どのJQueryを使えばよいかが分かり、
　　どのようなチェックをするかも決まっていて（桁数チェック等）
　　それがすぐに実装可能になっていること（JSをインクルードして、datatypeを指定すればよい等）

　　　DBアクセス性能の場合
　　DBアクセスモジュールが容易に作成でき、速度が足りない場合、DBをアップデートしたり、
　　メモリキャッシュを使ったりするという技術的にどうすればよいかが分かっていて、
　　それが容易に切り替えられるように、DI等でプログラミングされている

---

■機能要件は何処まで決めればいよいか

　まず、出力の項目を決めないといけない。
　そして、出力するプロセスにおいて、何を入力するかを決めないといけない
　さらに、入力したものが、「開発者が知っている」関数、演算方法等を利用し、
　出力が作成できなければならない

　例：月次売上高をPDF出力する

　出力項目
　　・年月　売上高の表
　　・年月を横軸、売上高を縦軸にしたグラフ
　　（位置関係は設計時に決めるものとする）

　入力項目
　　売上データ
　　　・年月日日時　バスケットNo　売上金額

　とあったとき、入力項目から出力を作成するには
　　・売上データを年月ごとに合計する
　　・その合計値を表に書く
　　・その合計値を元にグラフを書く
　　・PDF出力する
　となる。

このとき、位置関係は設計時に（見ながら）決めるとした場合、
位置がわからないと書き出せないが、それは決めないとしたの
だから、ここでは抜けているけど、決めない。

合計値を表に書くといった場合は、表は想像つくので、これもよしと仮にする

しかし、上記の場合、グラフの出力は、棒グラフ、折れ線グラフの２とおり考えられる
どちらだかわからない。したがって、棒グラフ、折れ線グラフのどちらにするかは
決めるべきである（これがExcelのように瞬時に切り替えられ、表示してみないと
分からないというのであれば、ここで決めなくてもよい）

ここで問題なのは、PDF出力である。
これは、想像はつく。しかし、その技法が分からない場合はありえる。
このように、「出力は分かるが、入力からどのように出力を生成するか技術的に分からない」
ものは、要求仕様とは別に、技術的に調査しておく必要がある。

この部分の調査がないと、あとで話がひっくり返る（仕様変更になる）

---

■非機能要件は何処まで決めればよいか

　「開発者が知っている」非機能要件実現方法の中から、今回、どれを選ぶかを
きめる。前述の【事前準備】により、非機能項目チェックリストで、どれを選べば、
どのように実装すればよいか決まっていることになっている。

したがって、事前に決めた非機能項目チェックリストをチェックすれば良いことになる。

---

■この結果

機能要件は、出力と、入力データ、利用する関数・演算を決めれば、
　（その関数・演算が実現できるものであれば）、
仕様が確定するとすぐにプログラミングできることになるので
ここまで決めてあげればいいことになる。

非機能要件は、事前に決めた非機能項目チェックリストをチェックすれば
プログラミングできることになるので、ここまで決めてあげればいいことになる。

そして、項目が増えても、項目種別が増えない限り、工数が増えないように
クラス化されているとしたら、機能要件で項目が増えても、それに伴って
工数は増えない。

さらに、機能要件が増えても、
出力と、入力データ、利用する関数・演算から
自動的にプログラミングが生成できる場合には
（高速開発）工数は増えない

・・・ベームさんやマコネルさんがいうようにはならないのではないの？

（あれは、
　　「関数・演算が実現できるかどうか不明」、
　　「非機能要件のコーディングとテストが、項目増加によって増える」
　　「そもそも、非機能要件とコードの関係が整理されていない」
　という状況で起こるもので、たしかにJQueryのセレクタとCIが出る前はそうだった
　けど、今はそうじゃなくなってきてない？）

　というのが、きのうの話です

ベームの見積もりの不確実性の図やマコネルの不確実性コーンは、JQueryやREST、ＣＩ時代にも有効か？

B. BoehmのSoftware Engineering Economicsにでてくる見積もりの不確実性の図

http://csse.usc.edu/csse/TECHRPTS/1984/usccse84-500/usccse84-500.pdfより引用

や、スティーブマコネルの不確実性コーン

http://itpro.nikkeibp.co.jp/article/COLUMN/20131001/508039/　より引用


は、要求のような上流段階では見積もりは不正確で、下流工程になるほど正確になる
ということを示しているといわれる。

これは、JQueryやREST、ＣＩ以前なら、成立すると思われる。
なぜなら、ソフトウェアの各工程

　　要求ー設計ー実装ーテスト

という各工程は前工程を前提に成立している。
したがって、たとえば要求に変更が起こった場合、

　　要求→設計→実装→テスト

に変更が起こり、この工数が発生するのに対し、

実装に変更が起こった場合

実装→（単体）テスト

にしか変更が起こらないから、この工数分しか工数は発生しない。
なので、工程が進んだほうが、変更工数が少なく、不確実性は低い。

---

しかし、現在のJQueryやREST、ＣＩ時代に同じことは言えるのだろうか？

ＣＩにより、テストは
　　変更点テスト＋回帰テスト
となった。ここで、回帰テストは、どれだけの変更があっても、全部同じである。


JQueryやRESTは、アスペクト指向を事実上実現可能にした。

アスペクト指向は、横断的関心事、つまり非機能要件のような各機能（＝業務）に直性関係ない
ＧＵＩや性能、移植性などを、機能（＝業務）横断的に修正することを可能にする。

　これは、JQueryのセレクタ（クラスをセレクタで選択）したり、ＲＥＳＴでＷｅｂサーバーを
使う場合、そのサーバーのフィルターに、非機能要件となるプログラムを入れることで、
実現可能となる。
　ということは、非機能要件部分は、機能に関係なく、一斉に修正・追加でき、再利用可能になる。

　そのため、要求変更が出たら、その要求変更部分をJQueryのセレクタで切り出して、
　切り出した部分を、非機能要件を実現するプログラムを埋め込めば（再利用すれば）よい　

　そうなってくると、変更になっても、あんまり手間暇かからないから、
　何倍にもなることは、ないんじゃないかなあ？


＊ベームの見積もりの不確実性の図とマコネルの不確実性コーンは同じ図に見えるけど、
　アジャイルでは、この図は、マコネルの不確実性コーンといわれ、
　大学の先生は、ベームの図ということになっている。

すごい人は、すごい人のところにインターンに行っている

昨日（７月１８日）J-WaveのPrimeFactor、
MakeIT21
http://www.j-wave.co.jp/original/makeit/
で
日本初のフリマアプリ　フリル運営
ファブリック（Fablic）の人
の話をやっていたので、メモメモ

---

ファブリック：ふぁびゅらすにホリックになる
フリル：ユーザー４００万ダウンロード
　　ファッション関連

競合：３年たつが１０個以上ある

ストイック
　働く時間は長い。休まないですね！
　仕事ばっかりと意識していない
　これしかない

評価
　フリマアプリはたくさん。業界に定着。サービスの１カテゴリ
　ＰｔｏＰ（Ｐｅｅｒ　Ｔｏ　Ｐｅｅｒ仲間から仲間）
　　→場を作ることが重要
　　　いい場所、信頼のおける場所：プラットフォーム

時間がかかりそうな気がするが・・
　　かかる
　　Ｗｅｂであったところをアプリがチャレンジング
　教育もＰｔｏＰ

一番気をつけていること
　カスタマーサポート
　　トラブルがあった時：人間が対応→競争優位

はじめ」売り手がいないと買い手がいない
　　　　買い手がいないと・・・
→プロトタイプにユーザーインタビュー
　　Facebook、女子しないサークルに連絡して・・・
　リリースする前の仕込みだいじ
　Facebook 秘密のグループ
　　情報提供
　　出品もお願い
　　ポイントを謝礼→買える状態に

アプリの広がり
　最初から口コミ
　　→アプリレビューサイトで取り上げてくれた
　じわじわのじわを起こすには
　　プロダクトを磨いた
　　雑誌モデルの紹介

アプリビジネスをやりたい人はたくさん
　　ハードル低い→審査通ればいけそう？
　　ダウンロードたくさんはある
　　アプリのビジネスは結構難しい
　→基本無料だと思っているから
　　独自の価値提案をして、お金払ってもいいと思わせる

一番気を使ったこと
　ユーザーが使ってくれるようにプロダクトを磨く
　ユーザーの声をよくきく
　カスタマーサポート４０人：フリル利用者
　いいんじゃないとなるのでは？
　　→男性が女性向けプロダクトを作る；客観してみるの徹底

フリルがいけると確信したのは
　なんでこのプロダクトを作ろうと思ったか
　　→アプリに流れが来ている
　　　ヤフオク、モバオク：画像データの不便なところ
　　　　→スモールＢ。せどりの人とか
　　　フリル：いままでやっていない人
　　　　→ブログ、Ｔｗｅｅｔで服を売る人も！
　既存にあるあれやこれ
　　デファクトになっている
　　使いずらいところ→まだいける！
　　アプリ立ち上がってきている（成熟もしてるけど）
　成熟リスク→あらたな機会
　ＰｔｏＰの場になる：ぷらっとフォーマーサービス
　　ＣｔｏＣの細分化
　　ユーザーにとって：
　　　　大きい場所でなんでもできる
　　　　ユーザーインターフェースの使いずらさ→使い勝手の良さ
　　まねはされる

ほかに
　アプリのビジネス、プラットフォームにチャレンジしたい
　サービスのＣｔｏＣ：ハウスキーピング、ベビーシッター
　個人間取引は拡大する？
　　ネイル
　いわゆるＢの人もうかうかしていられない！
　　インターネットは個人の力を最大化

　世界で使われるプロダクト
　　→言語に依存しない

　男性も使えるように：来週から
　上場なんかも・・・

　ミドリムシにインターン
　　→おかしい人かなと思った
　　　そのぐらいの熱量がないとだめ
　もっとおかしく！

---

みどりむしのところに、インターンに行っていたのね・・・
すごい人は、すごい人のところにインターンに行っている！

新国立競技場は、ブランコの要求（顧客が本当に必要だったもの）だよね！

最近、新国立競技場が話題ですけど、あれって、まさに要求工学の世界でいう、
ブランコの要求「顧客が本当に必要だったもの」だよね

（　ニコニコ大百科　単語記事「顧客が本当に必要だったもの」より引用）

デザインの約束はあんなかんじで、
お値段は、ジェットコースター級！
でも本当は、人数さえ収容できれば、
デザインなんてパターン化されたドームの競技場でよかったんだよね・・・

午後は、D-Caseの適用事例を聞いてきた！

７月１７日午後は、

SEC高信頼化技術適用事例セミナー
D-Caseの適用事例に学ぶ、合意形成と説明責任
http://sec.ipa.go.jp/seminar/20150717.html

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

---

事務局から
ごあいさつ
・２０１３年から先進的設計・検証
・事例→普及
　　必要な技術の紹介
　　適用事例
　　別視点から応用する
　　最近の動向

■D-CASEで高信頼性をどのように保障するか？～D－Case活用の基本パターン～
講師　名古屋大　山本先生

・話の内容
　D-Caseの基礎知識
　組み込み分野の適用例
　D-Case活用法

・D-Caseの基礎知識
　なにを保証するのか
　どんな品質を保証するのか
　どういうリスクを持っているのか

・安全性ケースの表現
　　保証ケース
　　GSN
　　　拡張：モニターノード
　　安全性ケース
　　D-Case

・主張と証拠
　証拠によって保障

・D-Caseの例
　　４つ　主張、前提（コンテクスト）、戦略、証拠

・D-Caseのメリットとその理由
　　ミス防止（抜け、漏れ）
　　思考の整理
　　開発期間短縮

・D-Caseの効果例
　客観的に説明できているか

・第三者への説明責任の遂行

・D-Caseの基本概念
　　合意基準
　　　　説明対象が満たすべき特性の基準
　　　　　　D-Case
　　　　証拠におとづく説明によって、説明対象が合意基準を満足
　　説明

・合意記述の前提、記述境界、前提境界
　　コンテクストの境界を明確にする必要がある

・ディペンダビリティ属性の定義

　ノードの日本語があいまいだと、あいまいのまま

・プロジェクトへのD-Case導入のミスマッチ

・組織の適合性評価手法

・組み込み分野の適合例
・論理参照モデル
　　　ユーザー
　　　ユーザーI/F
　　　制御ソフトウェア
　　　　　センサー
　　　　　アクチュエーター
　　　対象
・組み込みシステム参照モデルの分解パターンの例

・LAN機器監視システムの例

・話題沸騰ポット
　組み込みはUSDMがよくつかわれる
　　→個別は出てくるけど、全体的要求は・・・
　　理由の間の依存関係を整理

・イプシロンロケットの監視問題
　　構成要素が安全
　　構成要素に依存関係があれば、依存関係が安全

・安全性ケースアーキテクチャ
　　再利用できる
　　戦略的にリファレンスモデルを決める

・論証プロセス
　　コンポーネント分解
　　パターン分解
　　証拠分解

・D-Case活用法
　　議論分解パターンの分類
　　　議論パターンポケットガイド
　　　　アーキテクチャ分解パターン
　　　　非機能要求グレードの分解パターンの例→インデックスが定義されている
　　　　ECA分解
　　　　均衡分解パターン

　　FTAなどの違い
　　　証拠があるかないか

　　MECEとの関係
　　　MECEは網羅性がなぜ達成されているかを示していない
　　　　→コンテクストだけ

　研修でISDを使う
　経営戦略　BSCを使う→ビジネスゴール分解
　セキュリティCC分解
　医療情報システム安全管理のD-Case

■D-Caseを用いたゴール共有による開発プロセスの適用
講師：富士ゼロックスの人

・自己紹介

・背景
　ソフトウェアはなかなか目に見えない→コミュニケーションが難しい
　D-Caseをコミュニケーションツールに

・D-Caseとは

・適用プロジェクト（ETロボコン）

・本プロセス導入の背景
　DEOSプロジェクト

・なぜD-Caseをコミュニケーションに使うのか
　議論構造が分かりやすい
　Strategyが他のものは明確ではない（例えばマインドマップ）

・試行したD-Case
１）トップゴールを定める
２）ゴールの詳細化と妥当性の議論
３）仮のエビデンスの抽出
４）エビデンスの獲得
５）D-Caseの追加・獲得
６）繰り返しによるD-Caseの構築

・トップゴールを定める
・ゴールの詳細化と妥当性の議論
　　コンテキストの追加
　　ゴールの分割
・仮のエビデンスの抽出
・エビデンスの獲得
　　WBSを使って普通に
　　仮のエビデンスがとれないケース→代替策
・D-Caseの追加・獲得
　　新しい知見の追加
・繰り返しによるD-Caseの構築
　　作っているものを分解しているだけにならないように
・D-Caseによるトレーサビリティ

【質問】
・D-Caseになれるには？
　すぐにできる人と、子供の時からの考えなのか・・・・

■D-Caseで開発成果の品質をどのように説明するか？
～ソフトウェア開発現場におけるD-Case活用事例～
講師：デンソークリエイト
・安全分析の結果を第三者が納得できるように説明したい

・紹介する事例
　　リリース判断会議における活用事例
　　安全分析プロセスにおける活用事例
　　他社製品の品質判断における活用事例　ＡＵＴＯＳＡＲ（おーとざ）

・リリース判断会議における活用事例
　　前提となる文書を整える
　　説明の構造を設計する
　　成果物を証拠にヒモづける
　　D-Caseで説明する

・安全分析プロセスにおける活用事例
　　ハザード分析
　　故障モード抽出
　　故障モード対策定義
　　D-Caseで説明

　＊CAN　車の中の車内LAN

第三者が納得するために必要なこと
　　全体像→戦略で
　　判断基準の見える化
　　対策の組み込み状況


他社製ＡＵＴＯＳＡＲ　ＰＦに関する品質説明事例
　シナリオベースで確認できる

【質問】
・ストラテジーの出し方
　仕事できる人は、わかるみたいよ

・ストラテジーの根拠
　根拠になった絵がある。それをコンテキストとしてストラテジーに張っておけばよかったね

■第三者検証における保障の見える化
～独立検証および妥当性確認（ＩＶ&Ｖ）における事例紹介～
講師：ＪＡＸＡの人

・ソフトウェア品質
　　見えない
　　自由度高い
　　非尾ｔへの依存が高い

・宇宙機ソフトウェアの特徴
　　ロケット、人工衛星、宇宙ステーション、地上管制システム

　・誤作動→損失
　・動作環境過酷
　・部品交換できない
　・基本的に一品モノ
　・運用環境で試験できない

・ＩＶ＆Ｖ活動（ソフトウェア第三者検証）とは

・３つの問い
　　正しく振舞うか
　　意図しない振る舞い
　　不都合な事態

・アシュアランスケースをＩＶ＆V活動に導入し、
　保証の見えるかを実施

・アシュアランスケースとは
　トォールミンロジックとＧＳＮ
　説明先←　主張　←説明もと
　記法としてＧＳＮを応用

・課題
　課題１：具体的に何を記述する？
　　　→誰が誰に対して何を保証する
　課題２：末端ノード増えすぎ
　　　→論点だけ可視化
　課題３：仕事増える
　　　→過去資産を生かす

・活用ポイント
　業務、意義
　
・促進方法
　効果的なところ

・今の課題
　活用：いかに早く過去のケースを参照
　品質：ベースとなるケース
　表現：より多くのステークホルダー→ビューが必要

■D-Case実用化に向けた活動の動向について
～日本の安全安心を世界で共有するために～

・D-Caseプロジェクト
　ＪＳＴのＤＥＯＳプロジェクトの中
　ＤＥＯＳ協会Ｄ－ＣＡＳＥ部会

・アシュアランスケース
　１９９０年代の北海油田事故などから
　チェックリスト→エビデンスをもとにした議論

・アシュアランスケースの課題
　いつ、誰が記述、評価するのか
　ゴール、議論既往増
　粒度、規模

・活用事例
　５０程度の試作　www.dcase.jp

　規模
　ノード　１０～２００、平均６３　標準偏差４７→てんでんばらばら
　階層２～６、平均４　標準偏差１．０３　だいたい３～４階層

　状況ごとのD-CASEが増えている

・３種類の例
　カメラ付きロボットのＤ－Ｃase
　　　フォールトトレランス
　超小型人工衛星の蓄電システムのＤ－Ｃase
　三菱電機のパラメータのシミュレーションのＤ－Ｃase

・傾向
　ＦＴＡ，ＦＥＭＡなどの結果をまとめる：コスト大
　状況ごとのＤ－Ｃase

・これからのＤ－Ｃase
　状況ごとのＤ－Ｃase
　　基本的な前提ゴールが共有されていない可能性のある利害関係者
　　状況に応じて前提、ゴールを設定

ＩＰＡの「ソフトウェア品質説明のための制度ガイドライン」

自分の子にデジタル教科書を使わせますか？→ジョブズ「i-Padを使わせない」が最後のシメでした

今（７月１７日）

HumanCapital2015
ラーニングテクノロジー2015
http://expo.nikkeibp.co.jp/hc/2015tokyo/
にいってきて、

AIが人間を凌駕する時代に人は何をどう学ぶべきか？
講師：NII　新井先生

のお話を聞いてきたので、メモメモ

---

ロボットは東大に入れるか
その前は教育工学→こういうことに関心があった
２０１０　コンピューターが仕事を奪う　日経から
　人工知能→音声合成、画像処理、自然言語、ロぼティクスの人の対話
あまり売れなかった
・どこに置いたらいいの？・・SFの棚に置かれたり
　　→まずいとおもった
・人工知能を作って、東大を目指せば
　　→どらえもんを目指すと書かれた
４年間で作られた認識

　YES:８割

ビッグデータと機械学習
２０１３年　電脳戦第二回
　　　東大入学（２０００人ははいる）　＜　将棋のプロ　
　　　将棋のプロを破ったんだから、東大も入れるのでは？
　そういう話ではない
　　　将棋のプロのフレーム
　　　東大合格のフレームはちがう

どれは犬でしょう？
　犬と猫の写真があって、犬を見分ける
　　　右が猫だと思う人？　人だと１００％
　　　コンピューターで判断させると・・
　　　　論理系推論ではむずかしい

　ディープラーニング→統計の主成分分析
　　　SVM　犬、猫のSVMにリモコン見せても、犬か猫を答える

意味は考えない
正しさは保証しない
　どこの特徴量を見ているか分からない
　DNNは、これはちがうんですというのは難しい

家を見分ける
　リバースエンジニアリングしたら・・・芝生を見ていた！

でも、結構正しい
　Google　正解を教えずに、結構当てたい。インターフェースで工夫
　車　DNNに頼った時、事故が起こったら・・・言えない

東ロボ君
　論理的
　表層的

国語：表層的手掛かりで傍線部問題を解く
　セマンティクスとシンタクスは分かれている
　文字オーバーラップ率

Pepper君は、人の感情を当てている

２０１１年　ジュパディー
　たった１つのタイプの問題しか解いていない
　　→固有名詞
　ファクトイド：解ける問題と確立していた
　モーツアルト　ラスト　シンフォニー
　ワトソンは確信度があるのしかこたえない
　　全部でも６９％→それで、医療分野に入れてますからね（＾＾；）

　まず、７０％の精度を出そう→でも東大は８５、９０％

　キーワード抽出、ランキングモデル
　　→世界的に見て、レッドオーシャン
　　　日本人は、もっとも株が上がった時に買っている
　　　B29に竹やり

大学入試はスモールデータ
　いかに精度よく読むか

　数学
　　問題文
　　言語解析
　　意味合成
　　ZFの式
　　論理式の書き換え
　　実閉体の式
　　数式処理
　　解答

　内容語、機能語：機能語が意味を決めている
　機能語をやると、・・・　　自動的にSQLを出してくる

東ロボくん
　正答率２％の理科の試験で正答
　ボリュームゾーン
　最適化、分類は、機械でできる
　　営業は分類問題→Amazon
　　次は与信審査→確率密度

デジタルにできること・できないこと
　本当にいいの？デジタル教科書
　自動採点→キーワード

あなたは自分の子にデジタル教科書を使わせますか？
　ジョブズ：i-Padを使わせない
　　低コスト

スマホのハイブリッドアプリ開発方法を教わっている（Monaca使って） その２

さっきの話の続き

ちなみに聞いてきたセミナーは「はじめてのHTML5モバイルアプリ開発講座」
Monacaは https://ja.monaca.io/ で入れる。

---

■インポート
　書籍
クラウドでできるHTML5ハイブリッドアプリ開発
https://www.shoeisha.co.jp/book/detail/9784798140285
のプロジェクトは、URLをコピーしてプロジェクト作成のときにインポートできる

上記書籍の説明資料は、slideshareであがっている（公式ガイドブック）

■JS JQueryの確認
・ECMA Script version6
・ブラウザで動く言語
・オブジェクト
　var オブジェクト名={キー:値,・・・}
・配列
　var number=[10,20,30・・・]
　→配列もオブジェクト
・for in
　→配列はふつうのforで
・変数のスコープ（外の変数）
・オブジェクトに関数（無名関数でいい）
・ブラウザでできること
　　イベント→イベントハンドら→メソッド
・DOMドキュメントをオブジェクトで扱うモデル
・JQuery：ブラウザの差を吸収
・Android,iosはかなり同じように表示
　　→エンジン　webkitベース
・# ID
　. クラス名
* すべてのタグ
　h1 タグ
→CSSのセレクターと同じ
・イベント on はずすのはoff

■エクスポート
・ファイル→エクスポートでエクスポートできる。
・IDEの「過去のバージョンを見る」でファイルを元に戻せる

■ローカルストレージ
・ブラウザにデータ保存
・Cookieよりも容量多い
・JSON.parse、JSON.stringify
・情報の確認方法：リソース
　Monacaデバッガーがつながっていれば、ローカルストレージ見れる
　→下のウィンドウ、ResourcesのLocalStorageのLocalFiles
・$li.data("index",0)→data-index=0という属性を作ってくれる

スマホのハイブリッドアプリ開発方法を教わっている（Monaca使って） その１

今、スマホのハイブリッドアプリ(HTML5+Javascriptで、Androidもiosも動くアプリ）
の開発方法を、Monacaを使って教わっている。

途中までのメモ

■なぜMonaca・・・
・Cordova：バージョンあわせるのに大変
　Monaca:Cordovaセットアップ済み

■Monacaでの開発の様子
・ブラウザで開発
・すまほからクラウドにつないで動作確認
　　→Monacaデバッガ
・最終的にはビルドして梱包：配布

■Monacaで開発するまでの手順
（１）アカウント登録
　　https://monaca.mobi/ja/register/start
　　で作成→仮登録→本登録

（２）IDE（くわしくは★）
・Monacaデバッガーで開発中のアプリを起動する●
・プレビューでは、デバッグ情報は出ない
　　→Monacaデバッガーの情報が出る
・設定でAndroid,ios個別設定


★IDEで新規プロジェクトから
・プロジェクト作成
　　Monacaio→最小限のプロジェクト
・素材をフォルダーごとアップロード
　　（または、ドラッグ＆ドロップ）
　　WWWを選択、アップロードするimagesフォルダをドラッグ＆ドロップ
・設定でJQuery追加
・Body部分を記述、保存


●Monacaデバッガーのメニューについて（右下の□を押すと出る）
・更新
・メニューに戻る
　→更新されても出てこない場合、メニューに戻り、
もう一度プロジェクトに入る
　→メニューでは、下にスクロールさせようとすると更新する
・右下の□にびっくりマークが出たらエラー。Monacaの編集画面でみれる。
　このとき、$ is not a function
　となったら、JQueryが利いていない可能性あり
　Monaca（IDE)の設定→JS/CSSコンポーネントの追加と削除でJQueryを追加
・Monacaデバッガーの設定でキャッシュを消せる。JQueryし忘れるとエラーになるが、
　その場合、キャッシュも消しておくこと

■ネイティブ機能→CordovaAPI
　devicereadyが発生してから実行する
　$(document).on("deviceready",関数);

・カメラ撮影
navigator.camera.getPicture(撮影した、しない、オプション）;

■リリース
・Google：マーケットは開発者登録
　　→リリースビルド。直接いれることもできる
　ios：マーケットを通さないと使えない
　　→Monacaデバッガで確認できる