Developer's Summit 2016 【19-E-2】実演＆全員参加型 - 鳥肌必至のニューラルネットワークによる近未来の画像認識技術を体験し、IoTの知られざるパワーを知る 聴講メモ
講演資料
http://www.slideshare.net/nkjm/iot-58447760
概要
ニューラルネットワークのライブラリを用いた画像認識のデモと、Oracle Database Clowdでリアルタイム機械学習を活用した例を通して、機械学習の可能性を紹介する。
スピーカー
Oracleの中島さん。
詳細
デモをメインとしたセッション。
前準備
- 最初に、quiz.oracle.tokyo/ds というサイトにつなぐことを指示される。
- node.jsを使ったリアルタイムアンケートシステム。
- Oracle Database Clowdに興味があるか? と謎の質問をされる。
- 割と『いいえ』が多かった。
Neural Network
- 脳の神経回路を模した機械学習のアルゴリズム
- めちゃめちゃ難しい
- 簡単に紹介してもらったと言いつつ難しい
- 画像認識や自動運転の世界で応用されている
- そこで、まずは画像認識がどれほどの精度を持っているのかを伝えたい
デモ(静止画像が何であるかを認識する)
キーとなるライブラリ
- TensorFlow
- Imagenet
- 今回の画像学習データのモデル
- 世界中の物体、名詞について1000個ぐらい保持
この組み合わせはTEDで有名になった。
- コンピュータが写真を理解するようになるまで (https://www.ted.com/talks/fei_fei_li_how_we_re_teaching_computers_to_understand_pictures?language=ja)
- めちゃくちゃわかりやすいので、後で興味のある人は見ておいてもらいたい。
このライブラリを使ったデモ1を動かす(http://tf.oracle.tokyo/)。
- 画像をアップロードすると、その画像が何であるかを示すWebアプリ。
- 暖炉(薪ストーブ)っぽい写真をアップロードする
- 『99%でストーブ』と認識
- ちなみに暖炉と薪ストーブは厳密には違うらしい
- ミニチュアダックスフンドの写真をアップロード
- ゴールデンレトリバーとして認識された。
- まぁその程度。ライブラリはゴールデンレトリバー好きらしい。
デモ(静止画像を自然言語で表現する)
キーとなるライブラリ
- NeuralTalk2
- 画像認識ライブラリの一つ。
何ができるのかをビデオで紹介(https://vimeo.com/146492001)
このNeuralTalk2を使ったデモ。
- 椅子の上に犬が座っている写真をアップロード。
- 英語でdog on the chairみたいな文章が表示された。
IoTとどう繋がるのか
- 防犯カメラ
デモ(普段と違う画像を検出する)
- 家の玄関ドアの画像を以下のバリエーションで数枚アップロード。
- 夜間、ドアの前に誰もいない画像。
- 夜間、ドアチャイムを鳴らす人が撮影されている画像。
- 朝、ドアの前に誰もいない画像。
この時、チャイムを鳴らす人が撮影されている画像を機械学習で検出できるかを見てみる。
データベース上に機械学習エンジンが組み込まれている。
Oracle Database Clowdの機械学習
- Enterprise High Performance Edition以上だと機械学習が可能。
告知
- 3/4 Oracle Cloud Developerというイベントを開催予定とのこと。
最後に
Developer's Summit 2016 【19-C-4】事業に貢献する商品開発とその成長の仕組み作り～これからのエンジニアに必要とされるスキルとは～ 聴講メモ
講演資料
http://www.slideshare.net/JSUXDesign/ss-58461116
概要
かつてWordに押された『一太郎』『ATOK』の開発元ジャストシステム。 継続成長のために、B2B/B2Cに複数の事業の柱を作り、事業構造を変えながら行ってきた製品開発の中で見えてきた、エンジニアに必要なスキルと、それを有効に活かすための仕組みについて語る。
スピーカー
ジャストシステムの三木CDO(Chief Development Officer)。
詳細
継続成長するために変えたこと
- ジャストシステムは1979年創業、37年の社歴。
- 『一太郎』と『ATOK』。
- スペースキーでかな漢字変換、という当たり前を作った。
IT業界では老舗と言われる会社。
変えることの前に変えないことを決めた。
- 変えないこと：提案型の自社商品開発。
- 役に立つ、使いやすい、喜んでもらえる を愚直に。
- 自分たちで価値を考え、価格、売り方を決めて、より良く変えていく。
- 変えないこと：提案型の自社商品開発。
一方で時代の変化と環境の変化があった。Microsoft Wordに押された。
- 単独商品では難しい。依存したくない。
- 沈んでからもがくのは大変。避けたい。
- 実際に大変だった。
- 会社を継続成長させたい。
『選択と集中ではなく、戦略的分散』
- 継続成長するために、複数の事業を確立していく。
- 個人向け(B2C)と法人向け(B2B)の両輪を作る。
- 新しい価値を生み出しながら、事業構造を変え続ける。
- 実行できるか？
- 我々は、自分たちを『一言では言えない会社』にしたいと考えた。
結果、現在個人向け(50.9%)と法人向け(49.1%)の売上構成比が半々。
継続成長する基盤ができてきており、営業最高益更新中。
- 成長カーブを加速していきたい、というのが会社の現状。
商品開発が直面する課題
- 『新しい価値を生み出しながら、事業構造を変え続ける』
個人向けと法人向けのサービスはそれぞれ多種多様
課題は
- 価値を生み出し続けられるか。
- 他にない多様性に対応できるか。
- そのためには、強い個人、強い仕組みが必要。
エンジニアに必要なスキル
以下の3つだと考えている。
- 価値創造力
- 何を作るか。
- 技術力
- どう作るか。
- PM力も含む。計画通りにものを作るという、広義の技術力。
価値想像力と技術力を支える、プロとしての姿勢
この3つの育成、強化について、仕組みや施策を整備していきたいと考えた。
メンバーごとに強みはバラバラで良い。
- が、この2つから素晴らしい商品が生まれる。
- なので、組織としてはあえてこの2つを分業せず、混ぜこぜになるようにした。
- 他社の話を聞くと、『何を作るかを決める部隊』と『作る部隊』を分ける会社も多いが、うちは分けないことにした。
- いい意味でのカオス状態にして議論していきたい、というこだわり。
製品開発の実例
ATOK Medical
- 電子カルテシステムのフロントエンド。
- 法人向け最大のヒットは病院。
- 全国の営業部隊が直接コンサル営業して販路を作っている。
- 医療用語が自分の手に馴染むように出てくるのが医者に受けている。
- 『助かっているよ』と医者に言われつつ、明確な機能要望はない。
- が、どんな利用シーンでどう使っているか、開発者が行動観察してみた。
- 医者はとても忙しくいろんな場所で端末にログイン。
- すると、端末ごとに設定、単語がバラバラで使いにくそう。
- そこで、プロファイルローミング(端末間で設定を同期できる機能)を提案し、仕組みごと提供した。
- 結果大好評。当たり前に欲しいよね、という機能に。
- 開発が行動観察して提案した例。
- 同期する価値に気づくことと、同期する技術の両方がある。
Actionista
スマイルゼミ
- タブレットによる通信教育。
- 2011年当時、教育課程に完全にマッチしているタブレット通信教育はなかった。
- ipadが出始めて面白いねーと言っている程度だった頃。
- 学校系には1999年から『ジャストスマイル』という製品を導入していた。
- スマイルゼミを作ろうというのは、ジャストスマイルのユーザから意見をもらったのが端緒。
- 買う人と使う人が違う。
- 買う人(親)の課題で、かつ開発によって解決できそうなことは？ と考えた。
- 小学生では学習を継続させることが課題。そこで、こんな仕組みを導入した。
- 勉強したら親に連絡する。
- 連絡すると親が、アプリの鍵を開ける。
- 鍵を開けると、決められた時間アプリで遊べるようになる。
- 某社通信教育のテキストよりも取り組むようになったわ、と言ってもらえるように。
- 中学生では定期テストで点を取ることが課題。
- オーダーメイド型の教材を配信。
- 学校名と時期を入力すると、学校の教材に合わせて対応する試験範囲を決定し配信する仕組みを提供した。
新規開発テーマだったが、価値と技術の両面を有しているため、本質的な困りごとに対して、価値と実現性の両面性から具体化できる。
- 言われたものではなく、当事者意識を持って作っている。
- 開発効率が良い。
- 価値と技術をまぜこぜにするチームだからできること。
仕組みの実例
取り組んでいることの幾つかを話す。
訴求ファースト
- 『変えないこと』として話したように、提案していくことをやめないでいきたいと考えている。
エンジニア視点だと機能とか品質を見てしまうが、提案に当たっては、購入決定権のある人に、提供価値が伝わるか、心を動かせるかが勝負。
作る前に、訴求が成り立つかどうかを徹底的に勝負する。
- 提供価値の確信に絞って開発できるから。
TechCABINET
事業ごと、商品ごとにそれぞれ同じ課題で悩んでいたりする。
- そこで、技術分野ごとに"大臣"を置いて、事業商品横串で技術課題を解決していく体制にしてみた。
- WEBブロントエンド、サーバシステム、サービスインフラ、データベース、セキュリティなど。
- そこで、技術分野ごとに"大臣"を置いて、事業商品横串で技術課題を解決していく体制にしてみた。
大臣ごとの検討項目
- 技術軸での課題抽出、推進
- 社内の情報共有、ガイドライン化
- 社外の情報収集
- 技術力向上、勉強会など
- 人材戦略 キーマンの把握と育成
ディープラーニングとかセキュアプログラミングとかもやっている。
社外勉強会(JustTechTalk)
ジャストシステムの育成方針
- 成果を出すための手段として学ぶ、ということを忘れない。
- 目標達成のために、試合だけではなく、良質なトレーニングで鍛える、というイメージ。
まとめ
Developer's Summit 2016 【19-C-3】今日の習慣が明日をつくる～よりよい技術者を目指して～ 聴講メモ
講演資料
概要
良い技術者の基準を定義した上で、『仕様書とコードを大量に読んで、書いて、捨てる』という技術者の成長のための指針を、自身が行っている習慣を通して語る。
スピーカー
佐藤さん。某SIerのR&D部門の人らしい。 githubやツイッターなどで活動。 WebDBPressで連載。
詳細
- 今日は、自分の習慣のうち、明文化して効果を説明できるものを持ってきた。
- 技術者としての習慣を見直すきっかけを提供したい。
よい技術者とは
3つの基準がある。
読む力
- 仕様理解、類推
- 暗黙の条件や仮定を理解する能力。
- コードを理解する能力
- 短い時間で多くを把握する力。
- 関数やオブジェクトの関係性を把握する力。
- コードを評価する能力
- 設計や品質の妥当性を評価する力。
- 書きっぱなしでは良い技術者ではない。
- 自分の過去を評価するのも力。
書く力
- (当然だが)仕様に対して妥当なアルゴリズムを実装できること。
- 書いたコードの制約事項を明らかにする力。
- こういう条件、環境では動かないよ。
- 最低限の品質をテストによって保証する。
捨てる力
- 作り直す力。
- 厳密に仕様を再定義する力でもある。
- 同じ仕様を様々な方法で表現する力とも言える。
- ただし、実際、動く既存のものを捨てて作りなおすのはそう簡単ではない。
- 能力に大きく左右される。
- ただ、日々成長しているなら捨てられるはず。
良い技術者になる方法
仕様書とコードを『大量に』読んで、書いて、捨てる。
標準化された仕様書を読む習慣
標準化された仕様を読む意味
- 高度に整理された知見から都合の良い部分だけを拾う。
- 0からモノを作り出すには労力が必要だが、変更したり削除するのは遥かに楽。
- 原理、原則の理解
- 原理、原則を理解するのはエンジニアリングの根幹。
- とりあえず動いたからいいやを避ける。
- アプリケーションやミドルウェアの正しい動作確認
普段から読む習慣がない人は、HTMLがおすすめ
- HTML5は大きいので全部通して読む必要はない
が、仕様上どうなっているかを、グーグル先生に雑に聞くのではなく、仕様書に当たること。
RFCなら2119から読むとよい。
- 要求の程度を表す言い回し(Must,Shall…)を説明している。
- これを踏まえて、日本語の言い回しとしても一定になるように仕様書を書けると良い。
RFC7231(HTTP1.1)を開始点にする。
JSR
論文と仕様はIEEE
ISO
- どこかのタイミングで、必ず網羅性を気にする時がやってくる。そんな時はISO。
- ISO 12207
- ライフサイクル全般
- ISO 90003
- 品質保証に関するガイドライン
- ISOのプロセス系は、各プロセスがモジュール化されている
- 一部分だけ取り出すことに利便性が高い
仕様書を読もう。
- 良い技術者はこまめに仕様書を確認している。
コードを読む習慣
GitHubには成長の機会
- 大量の良いコードがある。
- が悪いコードもある。
- 貢献の機会がある。
毎日ログイン
- 毎日5分トレンド(Trending Repositories)を見る。。
- 惰性で見るようになるまで続ける。
- 頑張り過ぎない。
最近のGitHubのトレンドは"無理のない学習のやり方"。最近は"Til(Today I Learned)"がバズっている。
- 学習を続けた成果が共有されている。
- これを見ても分かる通り、GitHubの技術者たちは常に学んでいる。
GitHub以外だとTech Blogが情報源。
毎日30分コードを眺める。
- 理解しなくても良い。
- ソースコードを絵画的に鑑賞する。キーワードとインデントを認識できる程度。
- なぜ？
- 畏れを減らすため。
- 意識レベルになくても脳に記録されている。
- よりたくさんのコードを見た時に挫折しないようにするため。
- 良い処理構造は言語にあまり関係ない。
- なぜ？
- コードを見慣れよう。
- モチベーションなしにコードを見られるようにしよう。
- 呼吸するたびに意識を高める必要はないはず。
読むべきリポジトリ
- 得意な言語
- 説明がわかりやすい
- Readmeがしっかりしている
- 半年以内のコミット
- CIサービスによって成功が維持されている
読み始め方
- 依存ライブラリを確認
- 先に見たほうが役に立つ。
- ビルド環境、ユニットテスト環境を作る。
- ローカルでやるとこける。
- が、それが勉強になる。
- ローカルでやるとこける。
- 全部のコードを何度も眺める。
- 広く浅く。
- 境界面となる場所から読む。
- 仮説と検証を繰り返しながら読むと記憶に定着しやすい。
- 抽象度の高い部分から読む。
- 難しければブックマークして後回し。
- git blameを見ると、開発者たちの苦労がわかる。
- コードを動かしながら読む。
コードは高速に読もう
- コードを読む速度は改善できる。
- 良い技術者は毎日コードを読んでいる。
コードを書く習慣
- SIer企業では実装者に対する評価は低い。
一人砂場プロジェクト
- GitHubでやろう。
- 一人でコードを書き、学ぶ遊び
- 計画しない。
- 飽きたらやめる。
公開しなくてもいいが、公開しておくのがオススメ。
- 見られると恥ずかしいと思うかもしれないが、実際誰も見てないので大丈夫。
意味は？
- 自由を味わう。
- 自身の能力を客観評価する。
- 自身の価値観を変える。
- 価値の不明なものを評価する。
何すれば？
- 良さそうなものを何でも使ってみる。
- 言語
- ライブラリ
- フレームワーク
- CIサービス
- PaaS
- 良さそうなものを何でも使ってみる。
ネタがない
小さい車輪を再発明する。
- 他の言語にはあるけど得意な言語にはない。
- XUnitとかはそうやって広まってきた。
- 他の言語にはあるけど得意な言語にはない。
毎日少しづつ書く。
- 最初はエディタ起動とプラグインだけで良い。
- 毎日楽しくコードを書くほうが大事。
コードを捨てる体験
- 続けていると『もうこのコードに耐えられない』となる。
- 最高の体験。
- 別な方法で0からやり直すことで成長できる。
- 一人プロジェクトをやりなおそう。
- 始まりから終わりまで、そしてやりなおすこと。
まとめ
- 良い技術者になるには？
- 仕様書とコードを大量に、読んで、書いて、捨てる
- 無理せずやっていきましょう。
Developer's Summit 2016 【18-D-7】エンジニア・コミュニティで組織は動き出す〜これからの時代のエンジニア、組織、エンジニアと組織の関係とは 聴講メモ
講演資料
http://www.slideshare.net/ssuserafaef6/ss-58412612
概要
エンジニア出身の経営者が、Pythonエンジニアを集中して採用することで発生した会社の変化を通して、これからのエンジニア、組織のあり方と、両者の関わり方について話す。
スピーカー
- ビープラウドの佐藤社長。
- 20年エンジニア、10年経営者。
野球ファンらしい。野球のユニフォームをIT勉強会の正装にしたいらしい。
詳細
ビープラウド
などをやっている。
Pythonをメイン言語に採用したあとで見えてきたもの
会社設立からPython採用まで
- 当初はJava、Perlを使っていたが、2008年にメイン言語をPythonにした。
- 当時はメンバー4人、Python開発実績は0件。
- Java,PHPのエンジニア採用は大手との競争になる、資金力で勝てない。
- Pythonは仕事で使っている人が少ない、競争を避けられるのではと考えた。
Pythonを採用した結果
個性的なエンジニアをどう束ねるのか
- と、よく聞かれるが、束ねない(制御しきれない)。
- エンジニアの声に耳を傾けて経営している。
Pythonを採用してから変わったこと
これからの時代の会社のあり方とは
- 従来は工業社会。肉体労働者と階層型の組織構造。
これからは知識社会。組織構造の姿は模索中というのが現状だと思う。
私なりの答えはエンジニアリングコミュニティのような形。
- エンジニアコミュニティとは、エンジニアが自発的に参加し、様々な価値を生むコミュニティ。
つまり、これからの時代の会社は、『エンジニアがのびのびと創造性を発揮し価値を作り出せる会社』
この点について、以下3点を軸に話したい。
- 組織
- エンジニア
- 組織とエンジニアの関係
組織(会社をエンジニアコミュニティに)
- 会社＝コミュニティである
- コミュニティとは、同じことに興味を持った人たちの集まり。
- 同じことに共感、感動できる→暗黙知の共有、情報共有→知識レベルのアップ→会社自身のブランドになる。
- こういうコミュニティを作るのに、組織にとって大事な事柄。
- 雑談の積極奨励
- 社内勉強会のような場作り
- OSS(オープンソース・ソフトウェア)型運営から学ぶ
OSSのコミュニティ運営の特徴は以下3点。
1. フラット化組織
階層型組織にはこんな特徴が。
- 管理しやすい。
- 官僚制。
- 階層間で情報が滞りやすい。
出世に目が行く。
管理しやすいのでうまく回れば上の人が楽だが、内発的動機、自尊心、好奇心が失われる。
- 結果的に創造性が失われる。
一方でフラット化組織。
- 目的ごとにチームを作り、役割を決める。
- 管理のためのルールは最小限。
- 仕事をスムーズにすすめるためのルールに限定される。
- 仕事は進めやすいが、管理が難しい。
フラット化組織のポイントはセルフマネジメントと信頼関係。
- 管理する、されるの関係を作らない。
- 管理コスト、コミュニケーションコストを削減し、本来やるべき価値に集中できる。
経営者はコミュニティ・リーダーであり、権力ではなく役割。
- 権力ではなく良い人格を持つ事が重要。
2.コミュニティ評議会
- 『Art of Community』に記載されている意思決定グループ。
全体運営を担当、課題がある場合、ここに提出し評議会内で評議する。
ビープラウドでは、会社改善目的のプロジェクト(BP改善プロジェクト)を作った。
評議会を会社に置くメリット
- 自分たちで良い制度を提案していくので参加者意識、当事者意識が高まる。
- 決定プロセスの透明性が高く、公平感がある。
3. コミュニケーション
OSSのコミッターはフルタイムの仕事ではなかったり、世界中バラバラに仕事していたりする。
- 時間、リソース、場所の制約が多い。
- 隙間時間で成果を出している。
- が、それは実は会社も同じ。
リモートワークの体制づくりで制約を超える
- 通勤時間の削減や、家庭の事情で出社できない人も仕事ができるようになる。
- 『リモートワークはチーム仕事に向かないのでは？』という話もあるが、段取りが重要だと考えている。
- アイデアを生み出すのはチームだが、作るのは個別。
- すべての時間を顔を合わせる必要はない。
エンジニア(創造的なエンジニアになる)
創造性を発揮するからには、エンジニアは創造的である必要がある。
OSSのコントリビュータなどの創造的なエンジニアは、価値に目を向けつつ、アイディアを持ち、そのアイディアを実装することで価値を提供している。
つまり創造的なエンジニアになる＝主体的に価値を作り出すエンジニアになること。
そのためには。
不安を乗り越える
- 創造性の最大の敵は不安(出来なかったらどうしよう)と恐怖(出来なかったら首になる)。
- ディフェンシブな志向になり、創造性を失う。
不安を乗り越える方法は2つ。
- 技術を身につける
- 不安の原因は自分に自信がないから。
- 不安がなくなるまで徹底的に学ぶと良い。
- 体(仕事ができる健康)→技(技術力)→心(不安の克服)と身につけていけば良い。
- 今を生きる
- 不安ドリブンは集中できない。
- 求められる結果(完成したプログラム)のことをあえて一旦忘れ、プログラミング自身を楽しむ。
- フロー状態に入りやすくなり、結果につながる。
技術に感動する習慣を持つ
- プログラムを始めた頃は、動いたことに感動していた。
- 経験を減るとだんだん感動が薄れてくるが、感動によって創造的になれる。
- 感動→好奇心→探究心→創造に繋がる。
記憶にもつながる。
ジェフ・ベゾスも、好奇心や冒険心が新しい物に繋がると言っている。
価値を作り出すプロセスを学ぶ
- 想像は『思考』、『行動』、『行為』の3つのプロセスから成る。
- この時の入力は入力は『視点』。だが、人は自分の視点をなかなか変えられない。
価値創造プロセスを学ぶと変えられる。
よく、『走りながら考える』と言われるが、走りながら考えると間違った方向にスタートし、たいていの場合は力尽きて失敗する。1
- 運が良ければ辿りつけるが‥。
価値創造にはいくつかの定型的なプロセスがあったりする。例えば以下。
- 匠メソッド
- リーンスタートアップ
- U理論
エンジニアが何に取り組めばよいか
儲かりそうだ、という理由で手を出すことはNGパターン。
- 外発的動機なので長続きしない
自分(強み、興味、経験)×社会(機会)＝取り組むべきこと。
- 自分の中にある経験、強み、興味と、時代の流れやニーズが合致した箇所。
- 自分の中から出てきた動機なので長続きする。
創造的なチーム
- ドラッガーの言葉のように、専門知識を単独でなく結合させる必要がある。
- エンジニアの専門知識を組み合わせなければならない。
メンバー同士の協働姿勢が求められる。
よりよいアイデアを生むための思考
『Team Geek』では、HRTがチームコラボレーションの基盤として必要だと述べている。
- H(Humility) 謙虚
- R(Respect) 尊敬
- T(Trust) 信頼
チームが価値を生むためのリーダーシップ
- これからのリーダーシップは、リーダーがビジョンを全部描くとは限らない。
- 2つの形態があると考えている。
- 空白のキャンバスのリーダーシップ
- リーダーがみんなの意見を聞いてキャンバスを書いていく。
- コレクティブリーダーシップ
- 全員がリーダー。
- 一人ひとりがリーダシップを持って主体的に取り組む。
- 全員のリーダーシップを集約して価値化する。
- 空白のキャンバスのリーダーシップ
組織とエンジニア
- OSSのコントリビュータのように仕事をしよう。
- 契約で決められた仕事をするのではなく、
- 自分の強み、興味を活かして探し、貢献する。
- 役割に対して報酬を支払う。
- 役職ではない、という点が重要。
- 会社とエンジニアのシナジーで価値を生み出す。
- エンジニアと会社は対等。
- エンジニアは創造性を持つ。
- 会社は価値を生み出すインフラとなる。
- 自発的に参加したくなるような運営が必要。
- エンジニアと会社は対等。
まとめ
- これからの時代の会社＝エンジニアコミュニティのような会社。
- 現実世界に価値を向けてハックしよう。そのために必要な経営はコミュニティ経営。
-
実現したい価値を最初に認識していない時のことを指しています。↩
Developer's Summit 2016 【18-A-6】Yahoo! JAPANを支えるデータテクノロジー 〜機械学習、クラウド分散システム処理モデル〜 聴講メモ
講演資料
2/21時点で未公開。
概要
Yahooでどのように機械学習が活用されているか、とクラウドアプリケーションを表現する分散アーキテクチャとして、過去の知見を活用した試作事例を説明する。
スピーカー
- 前半はYahooの山下さん。
- 後半はYahooデジタルコムの今野さん。
詳細
ヤフオクにおける機械学習
ヤフオク
ヤフオクの深層学習
Yahooの商品カテゴリの話。
- 例えば、Macbook Airというカテゴリがある。
- これは本体を出すカテゴリ。
- 周辺機器は別カテゴリだが、周辺機器が出品されてしまう（カテゴリ違い）
- 関係ない商品が検索に出てしまうので、ユーザのモチベーション、UX低下に繋がる。
- カテゴリ違いに対し、人による検知を行うと、精度が高いが量、スピードに限界がある。
- そこで機械学習の導入を考えた。
- 例えば、Macbook Airというカテゴリがある。
機械学習の限界は色々ある。
- 未知のパターンに対応できない。
- 100%の正確性実現は難しい。
- などなど。つまり銀の弾丸ではない。
そこで、人と機械学習のハイブリッドを考えた。
- 人が判断するが、判断の順序を機械学習が提示する。
- 具体的には、カテゴリ違いの確率が高いものから優先的に提示し、その順序で人が判断していく。
カテゴリ違いの検知モデル
検知方法にもいろいろある。
- 商品タイトルベース
- タイトルの文言からカテゴリ違いを検出する。
- 自然言語の自由度に依存して検知が左右されてしまう。
- 一定の精度はあるが、限界が早い段階で来る。
- 商品タイトルベース
そこで、単語に加えて画像を使用している。
学習データは2万件。
- よい学習データを揃えるのが難しいらしい。
- CaffeV1.0rc2
Cuda7.5 GPUサーバはオンプレミス。
例えば、出品画像がノートPCである確率を計算させる。
ユーザによってはカオスな画像を上げる場合もあるが、関係ない画像は1%以下の確率と計算される。
この確率だけではなく、過去のカテゴリ違いがあるユーザなど、他のモデルを参照してゴニョゴニョして決定している
課題
- やり始めたばかりなので課題はある。今後取り組みたいこと。
- 学習データを高精度、大量、継続的に増加させる仕組み
- 精度の向上、新しいパターンへの対応
- ヤフオクには様々なものが出品される。
- 新しい物が出てくると、新しいパターンが入ってきやすい。
- 対応が非常に重要な所
- ヤフオクには様々なものが出品される。
分散表現
ヤフオクには『人気＋新着順』という謎のソート項目がある。
重要なFeatureは単語、特にタイトル中の単語。
そこで分散表現を用いることにした。
- ある単語に対して複数の要素で表現する。
- 意味が近い表現を近いベクトルで表現できる。
分散表現の対義語は局所表現。
- ある単語に対して単一のベクトルだけが対応する。
- 単語を単にエンコードしただけの言語表現。
分散表現を使うと、単語をクラスタリングできる。
分散表現モデル
- 学習コーパスは商品タイトル。
- 5000万件ぐらい
- 学習結果が単語の供給頻度に依存するので、重複単語を排除する必要がある。
- 単語数は3億8千万。
- Vocabulary 40万。
- Skip-gramとNegative Samplingをモデルとして使用。
- 5000万件ぐらい
今後はSkip-gram以降の分散表現のモデルを使っていきたい。
- 重複タイトルの判断精度を上げたい。
- タイトルを変えてモデルをすり抜けるユーザがいるので、それに対処するため。
- クラスタリング精度を上げたい。
- ディクリレ過程混合正規分布などの採用も検討している。
クラウド分散システム処理モデルの課題と展望
現状
現在のクラウド分散システムにはいくつかのパターン化されたモデルが含まれている。
協調サービス
- 複数ノードが強調して目的を達成するモデル。
- パターン
- 共有メモリ方式。
- 生産者消費者パターン。
リソース管理
- 分散システムのリソース管理機能。
- パターン
- マスターワーカー。
アプリケーションフレームワーク
- アプリケーションを書くための基盤。
- パターン
- データフローなど。
歴史に学ぼう
- 分散アーキテクチャを適切に表現する方法。
クラウドとは要件が違うと言われるが、以下の様な過去の知見を使えるのではないか。
-
- 1980年代、モノシリックカーネルへのアンチテーゼとして提唱された。
- カーネルを小さく分割
- 最小限機能をKernelModeで実行する。
- 高信頼性、単一責務、可変性、柔軟性がメリット。
- 今日のマイクロサービスとの類似性がある。
データフロー
リアクティブシステム
- 外部環境からの入力に対して連続反応するもの。
-
現状の課題を解決する試作
現状のアーキテクチャを見ていくと、分散クラウドにはモノリシック構築されており、以下の問題があった。
- 再利用性が低い。
- 拡張性が低い。
- 特定の言語に依存している。
- 機能追加時に全体を再起動しなければならない。
- 関数、モジュールが長くなる傾向があり、可読性が低い。
- ブラックボックス化の温床。
そこで、以下を志向した試作を行ってみた。
- モノリシックからマイクロに
- 静的から動的に
- ホワイトボックス的な開発、運用
- 可読性、透過性の重視
マイクロ協調サービスをコンセプトとした。
- 各ノードにはそれぞれ限定した機能を持たせ、RPCで他ノードの機能を呼ぶ。
- メソッド、ルート、トリガーの3つで構成する。
- データフロー上にこの3つをマッピングする。
実装方式
ラズパイでクラスタを作った。
- コアとスクリプト間のオーバヘッドが心配だった。
- が、実際はオーバヘッドは問題にならなかった。
- コアとスクリプト間のオーバヘッドが心配だった。
Developer's Summit 2016 【18-A-3】myThingsからみたIoTの未来と課題 聴講メモ
講演資料
2/21時点で未公開。
概要
Yahooが提供を始めたIoTサービス『MyThings』を通して見えてきた、IoTの可能性と現実的な課題について説明する。
スピーカー
- 前半はYahooの山本さん。
- IoTの可能性について話す。
- 後半はYahooの倉林さん。
- IoTの課題について話す。
- ID連携 『黒帯』1 ID厨らしい。
詳細
IoTの可能性
IoTの定義
IoTという言葉を正確に説明できる人は現状いないのではないか。
- とりあえずこのセッションではIoTを2種類に分類する。
- 工業系IoT。
- スマートファクトリーとか。
- 商業系IoT
- スマートハウスとか
今回のセッションでは商業系IoTのことについて話す。
MyThings
- YahooのIoT向けプラットフォーム。
IoTを構成する要素
- 3つある。
なぜYahooがIoTに?
IOTは現実世界の課題を解決できるのか?
岐阜県の限界集落に行って、課題解決のフィールドワークに取り組んでみた。
- 何が出来るのかと思っていたが、話を聞いてみるといろいろ取り組めそうな課題はある。
- 獣害(熊)
- センサーで熊を検知して、鈴を波状に鳴らす。
- 熊を誘導できないか、ということも考えた。
- ライフライン(水源)の監視
- 水車をつけて水流を監視するとか。
- 獣害(熊)
- このフィールドワークで、IoTは現実世界の課題を解決できるのでは、という糸口を掴んだと思った。
- MyThingsはこうした課題解決のハードルを下げられるのではないか。
- 何が出来るのかと思っていたが、話を聞いてみるといろいろ取り組めそうな課題はある。
課題は量産では。
- 試作止まりになってしまう。
- 試作段階で出てこなかった問題が量産段階で出てくる。
IoTにおける課題
- プロトタイプと量産型プロダクトの差。
- 初期のプロトタイピングでは、メイン以外の機能検証が後回しになりがち。例えば以下。
- 認証。
- データの保存。
- 運用後の更新。
- API組み合わせの安全性。
認証の課題
- 設置場所、利用環境をユースケースに取り入れて検討する必要がある。
- デバイスで利用可能なプロトコルは？
- 暗号通信方式は？
- 直接通信か、母艦が必要かどうか？
ディスプレイの有無。
- UIがリッチかどうか？
- これによって、画面上で直接認証できるか、あるいはスマホ経由の認証になるかが変わってくる。
IoTには2種類の認証がある。
YahooではOAuthを使って、以下の認証メカニズムを提供している。
デバイスを使わなくなった際の解除、無効化の検討も必要。以下も含めて考える必要がある。
- 解除したあとの再認証。
- 付与したトークンの無効化。
データの保存(センシングデータ)
送られてくるのはどんな種類のデータなのかを認識する必要がある。
- サーバはセンシングデータをセキュアに保持すべきかを考える必要があるから。
- 必要に応じてセキュアなデータベースに保持する。
サーバからデバイスへのデータ送信時にも、送信対象データの種類を考える。
- 漏洩時のリスクを考慮して、保管場所を考える。
- デバイス側のセキュアな領域に保存できるかどうか。
- セキュア領域がないなら保存せずに利用することも考慮する。
- 漏洩時のリスクを考慮して、保管場所を考える。
運用開始後の課題
- デバイスのアップデート
API設計
- YahooのIoT連携アーキテクチャはトリガーとアクションの2つからなる。
新たな課題について
- 課題だらけに見える。しかし考えて欲しい。
- 数年前は試作自体にハードルがあった。
- が、今は試作できるようになったので、新たなハードルが見えているという状態(前には進んでいる)。
-
Yahoo社内で、各専門領域特化エンジニアに与えられる肩書。活動用に特別な予算がついたりするらしい。↩
Developer's Summit 2016 【18-E-1】DevOps時代に明日から活かせるセキュリティ対策術 聴講メモ
講演資料
概要
OWASPに参加しているセキュリティエンジニアが、セキュリティに関する誤解を解きながら、どのようにセキュリティに取り組むべきかを、OWASPの活動と成果物を示しながら説明する。
スピーカー
OWASPの中田さん。
本業はセキュリティエンジニアからコンサルタント。
OWASPの運営メンバー。PRを担当している。
詳細
OWASP
- Open Web Application Security Project
- Webアプリケーションセキュリティに関する非営利コミュニティ。
- 日本では4つのチャプターがある
- 3ヶ月に一度勉強会しているらしい
- 場所によって勉強内容は異なる
- 日本独自の成果物を作成している
- 3ヶ月に一度勉強会しているらしい
デブサミで発表する理由
- セキュリティと他部門のコラボレーションを実現したい
- 昔ある企業のセキュリティ部門に努めていた。
- カンファレンスで、セキュリティにどう取り組めばいいのかがわからない、という質問をよく受けていた。
2つの勘違い
セキュリティ対策は『難しい』
- なぜセキュリティ対策は難しいと考えられがちなのか。
- 作成者は立場、フェーズごとに考慮すべき事項が異なる。
- OSI参照モデルの全層に関する理解が必要になる。
- 実態が見えないサイバー空間という脅威もある。
- 一方で、攻撃者は意識が甘いシステムを狙う。
- ちょっとした対策や意識向上でも効果がある。
- 研究レベルの対策は難しいが、システム実装レベルの対策はさほど難しくない。
- 逆に、ものすごく硬いシステムを作るとかえって狙われやすい。
- 地味なセキュリティ対策が重要。
- ちょっとした対策や意識向上でも効果がある。
- なぜセキュリティ対策は難しいと考えられがちなのか。
セキュリティ対策は『後回しにして良い』
- 何故セキュリティ対策は後回しにされがちなのか？
- セキュリティ対策は機能ではなく品質要素。
- 実装が任意。
- ユーザ満足に直結しない。
- コスト、時間がかかる。
- が、『セキュリティ対策は当然と判断された判例』がある。
- SQLインジェクション攻撃による個人情報漏洩事件。
- 仕様書にセキュリティ要件がなかった。
- 発注側がSQLインジェクション対策不足を重過失として受注側に損害賠償請求したが、
- 受注側からのセキュリティ向上提案を取り入れなかった点について過失相殺が認定
- 発注側もセキュリティ対策を知らないといけない。
- 予めセキュリティを必須のものとして考慮しなければならず、後回しにしてはならない。
- SQLインジェクション攻撃による個人情報漏洩事件。
- 何故セキュリティ対策は後回しにされがちなのか？
いつ対策するのか？
- 設計、開発工程でセキュリティ対策するのが最も効果が高い。
- 80%の脆弱性バグが発生するから。
- 設計、開発工程でセキュリティ対策するのが最も安い。
- 93%のコスト抑制効果があるから。
- セキュリティ対策のカギを握るのはセキュリティエンジニアではなく、プログラマ、アーキテクト、プロダクトマネージャ。
どうすればいいのか？
- OWASPの成果物からはじめてみては？
Top 10 Web脆弱性
- OWASP最高の成果物。
- 10の脆弱性と、それを作り込まないようにする対処法が記載されている。
- 公的機関の基準になることも。
- 攻撃シナリオが書かれているのが特徴。
- A9(既知の脆弱性を持つコンポーネントの使用)の対策には簡単に取り組める
- グーグル調査結果によると、セキュリティエキスパートが推奨する対策は『ソフトウェアのアップデート』1
Cheat Sheet Series
- 設計、開発時のリファレンスに。
- 設計、開発、運用、保守の知識と対策。
- 48のチートシート。CodeZineの解説を読むと分かりやすくなると思う。
- 概要の日本語版を公開中。
- JPCERT CCがチートシートの翻訳を調達中(そのうち日本語版が出る)。
Proactive Controls
- Web開発時に考慮したいセキュリティ技術を紹介。
- 最近2016年版がリリース
- 日本語翻訳中でまもなく公開
- 2016以前は優先度が低かった、要件定義、設計工程でのセキュリティ要件の考慮が重視されている
- OWASPTop10やCheat Sheetとの対応関係がある。
OWASP ASVS
- セキュリティの取り組みで、自分たちができていることとできていないことを把握する。
- 2015年末に最新版がリリース。
- どのレベルに有りたいかを設定したうえで、レベルに対応した要件をチェックしていく。
- インシデントに即応する時、前もってできていることを事前に把握していることが何より重要。
- 効果が高いのはV1とV9。
- こっちもJPCERTの方で翻訳中。
OWASP ZAP
- 脆弱性診断ツール。
- 実行ボタン一つでできる。
- IPAテクニカルウォッチで評価されている。
- 初学者でも使いやすく、検知精度が高く、効率的。
- XSS(クロスサイトスクリプティング)とかを見つけてくれる
IoT Top 10
まとめ
- 成果物を是非活用してもらいたい。
- 成果物の使用、勉強会参加、プロジェクトに貢献できる機会もあるので、OWASPにも参加して欲しい。
- 2/27にオワスプデイがあるので参加してね。
-
情報セキュリティスペシャリスト試験の模範解答パターンの一つでもあります。↩
