読者です 読者をやめる 読者になる 読者になる

ブロックチェーン技術者への道

何故ブロックチェーンを学ぶべきか?

  • 技術的な面白さ
  • 社会的変革に参加
  • エンジニアとしての価値があがるかも

技術的な面白さ

  • インターネット革命以降の革命?
  • 技術の広さと深さ
    • 暗号通貨のプログラミング?
    • DApps?
      ブロックチェーンの中でアプリケーションが作れる → ギャンブルのような形態でも潰されにくい、作成者に何かがあってもサービス停止にならない
    • エンタープライズ?金融?
      パブリックとプライベート
    • 非中央集権?
    • トラスト・ネットワーク?
      ビットコインなど通貨として凄いのではなく信用のネットワークができるようになったことが凄い
    • DAO?
      ブロックチェーン上で組織を作って色々やろうみたいな概念

社会的変革に参加

社会の仕組みを破壊する? - 金融が破壊される? - DAO - 契約 - ガバナンス/政治/投票 - 資金調達、VC

ブロックチェーンエンジニアの価値

  • 世界的に少ない
  • 日本も少ない
  • 給与の価格としては出しているところは出している、という状態

何を学ぶべきか?

  • 業界
  • 技術
  • 必要な能力

業界

  • 取引所
  • ペイメントプロセッサ
    ビットコイン支払いのバックエンド
  • コンサル/開発
  • 独自ブロックチェーン独自サービス

  • パブリック

  • プライベート
  • エンタープライズ
  • 関連DLT

技術

  • 研究開発
  • 暗号技術
  • P2P
  • コンセンサス・アルゴリズム
  • スマートコントラクト/chaincode
  • 周辺アプリケーション
  • セキュリティ

必要な能力

  • 設計(特にトラストの設計)
    シングルトラストがないように
  • 英語の技術文章を読む能力、質問する能力
  • 数学の基礎
    必要ない場合もあるが論文が絡むと必須
  • 早いキャッチアップ能力
    非常に業界の流れが早い
    3ヶ月〜6ヶ月でガラッと変わる、1年前の技術はもう古い
    デファクトスタンダードがまだ不明
  • 常に学んで行く能力持続する能力

どのように学んでいくか

  • 書籍
  • 講座/オンライン講座
  • ネットで調べる
  • 詳しいに人に聞く
  • 実務で学ぶ

書籍

  • マスタリングビットコイン
    OSSgithubにある
  • bitcoin and cryptocurrency technologies: a comprehensive introduction
  • ブロックチェーン ビットコインへの入り口
  • スマートコントラクト本格入門 ―FinTechとブロックチェーンが作り出す近未来がわかる
    イーサリムでどうやってスマートコントラクトを作るかといった説明もある

現状、プライベート系の本はほぼない

講座

  • ブロックチェーン大学校
  • ブロックチェーンハブの講座
  • 慶應義塾大学 湘南藤沢キャンパス ブロックチェーン寄付講座

オンライン講座

ネットで調べる

情報源はほぼ英語

  • 公式のドキュメント
  • 公式のチャット
  • Stack Exchange
  • その他、いろいろな人の記事
  • 最終的にはソースリーディング
    • ただどうしようもなくなったときに見たほうがよいかもしれない
    • 興味のあるところから見ていくのがいいと思う、IOとかトラストの部分とか
    • ビットコインならBTCDが良い

詳しい人に聞く

  • 技術勉強会
  • ミートアップに参加
    • Tokyo Bitcoin Meetup
      • 外国からの参加者も
      • 非常に濃い
    • Tokyo Ethereum
    • hyperledger Meetup
    • Corda Meetup

実務を通して学ぶ

  • 自分でアプリ作成
  • ハッカソンに参加
  • 会社に入って色々学ぶ

独自ブロックチェーン

少数精鋭で行われている

サービス 組織 備考
mijin テックビューロ
orb1/orb2 Orb
Keychain Keychain
Broof シビラ
hyperledger いろは OSS
miyabi bitFlyer

ブロックチェーン特有のスキル

  • ブロックチェーンの意味、価値を理解する
    それはブロックチェーンでやる意味があるのか?
  • トラストの設計
  • パブリック向けコンセンサス・アルゴリズム
    • 設計(インセンティブとガバナンス)
      誰がどう管理してどう運用するか
    • セキュリティ
      セキュアなブロックチェーンとは何か?
  • 技術以外の能力
    • 特にビットコインは政治、経済、貨幣の歴史、…… 色々な概念が関わる
    • プライベートはともかくパブリックは幅広いスキルが必要

その他

  • ブラウザ上でコードが書けるサービスもある
  • azureに Blockchain as a Service (BaaS) がある
  • テストネット
  • 金融機関をはじめとしたバックシステムの置き換えは数十年はかかるのでは
    • 現状は既存ではない部分でちょっと使うといった程度 → 新しいシステムを作成するとかなら可能性はある
    • R3のcodar、リップルは置き換わるかもしれない
    • 考え方が違うので既存システムをブロックチェーンで置き換えるのは難しい
  • 導入により総コストが減少するといったことは難しいと思う
    • 開発コストは大きな変化はなく、サーバー代が減ったと言っても総コストに対してサーバー代は微々たるもの、ランニングコストも変わらないのでは?
    • 海外で30%ほど減ったといった論文はあるが、トラストの部分では減る可能性はある

ウインドウ関数(ntile)

ntile関数 概要

データを1〜Nに分割する
ntile(N) over (...)

使用例

(セットアップ)

-- 初期化
drop table if exists orders;
create table orders (
    user_id bigint,
    amount bigint
);

-- ランダムデータを登録
insert into orders (user_id, amount)
select
    ((random() * 14) + 1)::integer
    , (random() * 100000)::integer
from generate_series(1, 10000);

ntile関数

select
    user_id as user_id,
    sum(amount) as total,
    avg(amount) as avarage,
    count(*) as count,
    ntile(10) over(order by sum(amount) desc) as decile
from orders
group by user_id;

(結果)

 user_id |  total   |      avarage       | count | decile
---------+----------+--------------------+-------+--------
       5 | 36971500 | 51207.063711911357 |   722 |      1
       9 | 36941712 | 48479.937007874016 |   762 |      1
       4 | 36925173 | 51356.290681502086 |   719 |      2
      12 | 36713323 | 50920.004160887656 |   721 |      2
       2 | 36594138 | 51180.612587412587 |   715 |      3
       7 | 36120228 | 47464.162943495401 |   761 |      3
       6 | 35432197 | 50116.261669024045 |   707 |      4
      14 | 35334110 | 48535.865384615385 |   728 |      4
       3 | 35136999 | 51748.157584683358 |   679 |      5
      11 | 34629867 | 49330.294871794872 |   702 |      5
      10 | 34360367 | 48946.391737891738 |   702 |      6
       8 | 34194119 | 49991.402046783626 |   684 |      7
      13 | 33541738 | 49913.300595238095 |   672 |      8
      15 | 17982500 | 50371.148459383754 |   357 |      9
       1 | 17594380 | 47681.246612466125 |   369 |     10
(15 rows)

データ利活用のSQLちょい足し

データ活用・分析の種類と成果

  • 基礎分析
    • レポート
    • 集計
  • 問題解決
    • 検討
    • 課題の発見
  • 価値の想像

    • レコメンド
    • ターゲティング
  • 大きなフロートしては 既存分析 → 問題解決 → 価値の創造: 前半はディレクター、後半はエンジニアの比重が大きい

  • ディレクターはどんなデータが必要かのイメージはできていても、集め方やアルゴリズムまで熟知できていないことがある。
    ゴールの近くにいるエンジニアからディレクターにアクションを起こす
  • 配信システム・検索システム・API保有データがあっても人手による限界 → 自動化、情報の出し分け、数値化や可視化により旬な情報を届ける

目的

  • セグメント・ターゲティング
  • 変化・状態の可視化
  • 自動化・高精度化

セグメント・ターゲティング

  • デシル分析
    • ユーザーを10段階に分けて重要度を分割する
      • ユーザーを購入金額の多い順にソートし、上位10%ずつのグループに割り当てる → ntileウインドウ関数
    • 一回で大金と回数で大金になった人が同一ランクになってしまう
  • RFM分析 Recency、Frequency、Monetary

変化状態の察知

  • おすすめ枠に何を表示するか → 人気や新着はともかく、急上昇やレコメンドは人手対応は難しい → 自動化
  • 旬な情報を届けたりユーザーの状況に応じた施策が検討可能になる

    • 良い状況に変化 売上を伸ばす要員に注目
    • 悪い状況に変化もしくは変化なし 売上が減少する要員に注目
  • ファンチャート

    • ある基準を100として以降の数値の変化を見る
      売上では金額が少ない項目は変化が分かりにくい
      first_valueウインドウ関数
    • カゴ落ちユーザー
      何かをして以降何かを指定ないユーザーの抽出
      カートに入れて購入していないなど

自動化・高精度化

システムの改善はエンジニア以外には難しい

  • 検索システムの高精度化
    • 商品DBと検索システムの連携
      • 同義語辞書: バイト = アルバイトのようなマッピング
      • ユーザー辞書: ビルゲイツという単語で一つの単語であるという定義
    • 検索 → 再検索、検索 → 詳細ページ、検索 → 離脱 といった行動がある
      • 再検索(絞込): 並び順の最適化、同義語辞書への追加
      • 離脱ワード: 辞書で追加可能なワードがあれば対応
    • 検索ワードに辞書の最適化のヒントが有る
      離脱、再検索をしたのは何故? → LAG、LEAD関数で再検索ワードの取得
      • 結果が0件だたったから離脱?
      • 条件を追加して再検索?
      • 全く違うワードで再検索?
  • レコメンドの高精度化
    • リマインド、ランキング、コンテンツベース、レコメンド、パーソナライズレコメンド、・・・
    • DB上では商品ID、ユーザーID、重みがあれば最低限の分析ができる

      商品ID ユーザーID 重み
      AAA U1 1
      BBB U1 1
      AAA U2 1
      CCC U3 1
    • コサイン類似度: 2つのベクトルのなす角、1に近づくほど相関大

行動に移す

  • 会社の動き: トップダウンボトムアップ
    ちょい足し: ボトムアップ → 予算なし、強制力なし
    メリットの説明 小さく始めて効果を可視化して投資回収が成功することを示していく
  • データを武器にする = 組織作り
    小さなところからやってみて効果を可視化して周りを巻き込んでいく

その他

  • MySQL は非対応のSQLもあるので分析系では postgresql のほうがおすすめ
  • 分析系のSQLでは重くなってしまうこともあるが、ユーザーが使う部分でもないので重くなってもまあ良いのでは?
    中間テーブルへの保存なども上手く使い、2回目以降の処理の高速化も考慮しておく

フリーランスエンジニアの稼ぎ方セミナー

エージェントの選び方

  • Webサイトのつくりがしっかりしている
  • 資本金額が潤沢
  • レスポンスのスピードが速い
  • マッチング精度が高い

自分の価格相場

  • エージェントを探す
  • エージェントと相談をしてスキルを棚卸しする
  • エージェントに相場を教えてもらう

社会保険の知識

  • 税金
  • 健康保険
  • 年金

ディスカッション

契約関連

  • 長期契約: システムについて理解しているから自分の業務が楽になっていく

経歴書

  • エージェントと相談をして強みを書く
  • プロジェクト毎に記述
  • マネージメント経験

エージェントを使うメリット

  • 事務手続きの代行 → 自分がすべきことに集中できる

金銭

  • 振り込まれる金額が大きくなる
  • 年収アップというよりも節税ができるから所得が増える → 節税も楽しみの一つだが納税額が低い=年収が低いとみなされるためローンなどは注意
  • 税理士は必須ではない

副業

  • プログラミングスクールの講師 オンライン上で画面共有して行うことができる スキルも身につくし講師はおすすめ
  • 書籍・webマガジンのライターも
  • 休みの日にやるのは面白いもの 常駐案件で正直十分、でもせっかくフリーランスなんだから色々手を広げたほうが面白い
  • 副業でやったことが本業でも生きてくることがある

保険診療の仕組み

f:id:pluselc:20160803011823p:plain

  1. 保険料支払い:被保険者 → 保険者
    国民皆保険制度により国民は医療保険に加入し、毎月保険料を支払う

  2. 診療サービス(療養の給付):保健医療機関等 → 被保険者
    医療機関が患者に対し診療行為を行い、診療報酬が発生する

  3. 一部負担金の支払い:被保険者 → 保健医療機関等
    診療行為を受けた患者は治療費として診療報酬の一部を支払う

  4. 診療報酬請求:保健医療機関等 → 審査支払機関
    医療機関は審査支払機関に対し、月次で患者の治療費の残りの請求を行う

  5. 審査済の請求書送付:審査支払機関 → 保険者
    審査支払機関は医療機関から送付された請求の審査を行い、問題がない場合は保険者に対し請求を行う

  6. 請求金額支払い:保険者 → 審査支払機関
    保険者は請求に対し意義がなければ審査支払機関に支払を行う

  7. 診療報酬支払い:審査支払機関 → 保健医療機関等
    審査支払機関は医療機関に支払いを行う

(当月)[医療機関]診療行為・診療報酬請求

(翌月)[審査支払機関]請求内容審査

(翌々月)[保険者・審査支払機関]支払い

ヘルスケア関連のIoTセミナー

  • Internet of Things : モノのインターネット
  • 人とモノではなくモノとモノが通信し合う(Machine to Machine)
    • 例:人が計測機を確認し、データ化し、報告(送信) → 計測機が直接データ送信
    • モノから得られたデータをフィードバックすることで人の手を介さずに改善し続けられる
    • 人間の行動をトリガーとするのではなく、人間の行動を予測して動作する

アーキテクチャ

クラウド
 │
フォグ、エッジ
 │
デバイス

  • 通信の度にクラウドまでアクセスしていては物理的な距離や演算能力などで限界が生じる
    フォグコンピューティングが今後は重要
  • リアルタイム性、サーバーとの通信速度・量が既存のwebサービスとは異なる
    サーバー通信速度・量

    ┃        AR
    ┃        M2M
    ┃        医療


    webサービス
    ┃メール

    ┗━━━━━━━━━━━リアルタイム性

注目されるIoT

  • クラウドの浸透や通信の安価
  • 2016年リオデジャネイロオリンピックが終わると次の開催国である日本に世界の目が向く
    → 日本の技術をアピールするチャンス
  • 2022年までに世界で14.4兆ドルの経済効果
    • スマートファクトリー : 1.95兆円
      • リアルタイム性向上・情報の共有による管理コストの低下、過不足のない在庫
    • ヘルスケア : 1060億ドル

ヘルスケア業界

  • 日本人の生涯医療費の平均 : 2400万円
    • 0~69歳で生涯医療費の51%を、70歳以降で49%を支払う
  • 一次予防 : 食生活、運動
    二次予防 : 早期発見
    三次予防 : リハビリ

エンジニアは一次予防に注目すべき

  • 二次、三次は医療行為に当たるため参入障壁がある
  • 日常生活に密着している
    → アプリで大きな改善が期待できる
  • ターゲットを絞り込む

研究の例

  • 薬と一緒にセンサーを飲んで身体の状態変化を把握
  • 血糖値のリアルタイム計測

寝具メーカーのケース

背景・方法
  • 寝具は品物もそうだがいつ起きるか、といったタイミングも重要
    → それなら良いタイミングで起こせるような寝具を作ろう
  • シーツをセンサーにすることで日常に何も変化を与えない
    • 人体に付けるセンサーは最低限に
    • 毎日入力するなどの負担はさせない
問題
  • 昼と夜でトラフィックが全く変わる
  • 毎日大量のデータを保存、処理するための費用や容量

実現可能なことの限界
→ まずは一般寝具ではなく病院などベッド数が有限のところをターゲットに変更

IoT時代に求められるエンジニア像