jiigのREDOブログ

やったことや考えたことなどを不定期に書き残していきます

これからはフルスタックエンジニアとマルチロールエンジニアになりたい

自分自身のキャリアについて、何かにすごく特化した専門分野があるかって考えたとき、個々のスキルで見たらどれも超一流では無いかもなって悩んだ。

でも、IT系の新規事業開発を考えたら、霧が晴れた気がした、そんな話です。

エンジニア→フルスタックエンジニア→マルチロールエンジニアという道です。

フルスタックエンジニア

フルスタックエンジニアとは?

システム開発のすべてを自分ひとりで行えるエンジニアのこと。

システムエンジニア、ネットワーク、データベース、サーバー構築、アプリケーション開発(フロントエンド+バックエンド)

要件定義から設計、実装、テスト、リリースを、すべてやれるエンジニアのこと。

自分に当てはめてみる

要件定義から設計、実装までひととおりやれる。スペシャルでない部分もあるができないフェーズはない。

フロントエンド開発→Vue.js、Bulma

バックエンド→ Node.js 、AWS Lambda

データベース→大好物。OracleMaster、データベーススペシャリスト

インフラ、ネットワーク→AWSネットワークスペシャリスト

モバイル→Android開発

デスクトップアプリ→C#.NET

うーん、ハードに近いところは難しい(RaspberryPi、Arduinoにセンサーつなぐレベルが限界)が、わりとカバーしている気がします。

マルチロール

エンジニアという職種を越えた活動。

企画、マーケティング、ユーザーインタビュー、営業、+エンジニアリングと、なんでもやれる人。

自分に当てはめてみる

これらの実践する中で、必然的にマルチロールになってきた。

単一のスペシャリストでは無い道。

新規事業をやろうとすると、最初のうち、Product/Market Fitまではコスト的にもコミュニケーション的にも、小さいチームで進める方が良い。スピードも出る。

意思決定に関わる人、邪魔する人、説明をしなければならない相手が少ないほど早く進めることが出来る。体制×期間が人件費やらの形でコストに直結するので、同じコスト内でより多くの仮説検証を回せる。

そう考えると、新規事業開発にこそ自分のスキルセットや経験が活かせると思うし、そこに必要な知識とスキルを備えれば、それはそれでスペシャリストだなぁという結論で腹落ちできた。これからの当面はそこを目指して必要なスキルを獲得していこうと思います。

 

同じような話を、私が一方的にリスペクトするi2keyさんのブログで見つけました。

ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog

読書記録

せっかく読んだ本を少しずつ記録として残しておこうと思います。

2019/01/19 更新

 

ユーザーストーリーマッピング

ユーザーストーリーマッピング

ユーザーストーリーマッピング

 

新規事業をリーンスタートアップを参考に進めていて、プロトタイプやらMVP開発なんかのシステム開発スクラム導入後し始めたとき、ユーザーストーリーの書き方とかもやもやしたので読んだ本。

すごく良著。

 

amazon 世界最先端の戦略がわかる

amazon 世界最先端の戦略がわかる

amazon 世界最先端の戦略がわかる

 

Amazonのビジネスについてはある程度知っているつもりだったが、まだまだ甘かった。意図してなのか結果的になのかは分からないが、事業戦略としてすごく興味深い示唆がたくさんある。

 

アントレプレナーの教科書

アントレプレナーの教科書[新装版]

アントレプレナーの教科書[新装版]

 

リーンスタートアップ関連をざっとまとめて勉強した。そのうちの1冊。

いろいろ読んで自分なりに理解を深めるのが1番だとは思っているが、最小限で、となると、この本+『RUNNING LEAN』を読んだあと、『起業の科学』に進むのが良いと思っている。

 

起業の科学

起業の科学  スタートアップサイエンス

起業の科学 スタートアップサイエンス

 

なんというか、リーンスタートアップ全部入り、とい感じである。著者もそう言っているとおり、いろんな本を読んだが、スタートアップの全体を体系的に網羅したモノが無かったので、スライドにまとめた、とある。この本はそれらスライドの書籍版。

概念よりも、かなり具体的なやり方を中心に記載されているので、何度も参照しながら社内の新規事業開発を進めている。

 

リーンスタートアップシリーズ

リーン・スタートアップ

リーン・スタートアップ

 
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

 
リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

 
Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

 

最初にRUNNING LEANを読み、興味を持ったのでその他シリーズも読み進めた。

青本リーンスタートアップと、RUNNING LEANで全体像をつかんだあと、顧客発見あたりは『リーン顧客開発』を参考にインタビューを実施し、Problem/Solution Fitを達成してMVPを有償で提供するあたりから、『LEAN ANALYTICS』を参考にKPIを追いかけるイメージで考えている。

正直、初めて読んだときはLEAN ANALYTICSは理解できなかった。だが、リーンスタートアップを読んで革新会計を学んだあとで再読すると、しっくりきた。

 

カイゼン・ジャーニー

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

アジャイル開発(スクラム)を社内で少しずつ導入した著者の経験に基づくリアルなストーリー。すごく共感できるし、これを読んで、自分もまずは小さいところから始めないと、と思うきっかけになった。

あと、ギルドワークスさんのサイトにいろいろ共感

Vue.jsでHighchartを使う(しかもビルドシステムなしで)

サンプルとかあまり見つけられず、苦労したので備忘録としてメモしておこうと思います。

highchart vue.jsラッパーを入手

まず、Highchart公式GitHubリポジトリから、highcharts-vueを入手する。リポジトリ丸ごとダウンロードかcloneするが、使用するファイルは、 「highcharts-vue-master/dist/script-tag/highcharts-vue.min.js」だけです。 ※dist/module/配下にあるやつは、モジュールとしてロードする用です  (普通はこっちを使うと思いますが、今回はタイトルにもあるとおり、ビルドシステムを使わず、htmlファイルからscriptタグで読み込むので。。。)

GitHub - highcharts/highcharts-vue

index.html(本体のHTML)

bodyタグの最後で、以下の順でスクリプト読み込み。

new Vue() する前に、Vue.useでプラグインを登録する。書き方に注意が必要です。

Vue.use(HighchartsVue.default);

※HTMLのscriptタグで読み込んでいるので、Vue.use(HighchartsVue)ではダメです

グラフ描画に関して。 Highchart公式には、さらっと1ページ書いてあるだけ(しか見つけられていない)。

Highcharts Vue Wrapper - Highcharts

こんな感じになるらしい

data() {  
  return {  
    title: '',  
    points: [10, 0, 8, 2, 6, 4, 5, 5],  
    chartType: 'Spline',
    seriesColor: '#6fcd98',
    colorInputIsSupported: null,
    chartOptions: {
      chart: {
        type: 'spline'
      },
      title: {
        text: 'Sin chart'
      },
      series: [{
        data: [10, 0, 8, 2, 6, 4, 5, 5],
        color: '#6fcd98'
      }]
    }
  }
},

ここで、chartOptionsが、チャート描画に使用するデータです。 ただし、vue.jsラッパーのポイントとして、pointsと、chartOptions.series[0].dataとに同じ値が入っている。 使い方としては、直接chartOptionsを触らずに、いったんpointsにグラフデータをセットする。pointsの変更をwatchして、変更後の値をseries.dataに代入することで、リアクティブにチャートが更新されます。。 この辺は、Chart.jsのVueラッパーであるvue-chart.jsとはアプローチが異なるので、最初は少し悩みました。 vue-chart.jsでは、mixinしたうえでreactivePropやらを使うので、どっちが分かりやすいかというと人それぞれかなぁ。

認定スクラムマスター(LSM)になりました

Scrum Inc. 認定スクラムマスター研修というものを受講してきました。さらに、そのあと受験できる試験に合格して、認定スクラムマスターとなることができました。

動機としては、独学オンリーのなんちゃってアジャイルなままではなく、きっちりと理解したものを社内外に導入したかったからです。

 

認定スクラムマスター

スクラムマスターの認定資格には、Certified Scrum Master(CSM)というものと、Licensed Scrum Master(LSM)があります。他にもあるかも知れません。CSMのほうが昔からあるようで、日本ではスクラムマスター資格というと、こちらの方が多いようです。これからはLSMが多くなりそうですが。

LSMは、スクラムの創案者のひとりであるJeff Sutherland博士により設立されておりScrum Inc.という会社が提供しています。

Scrum Inc.認定資格セミナー / Scrum導入支援

 

スクラム

用語説明や詳細はたくさんサイトがあるので、簡単に自分のリマインドとして書いておく。

スクラムチーム

プロダクトオーナー(PO)、スクラムマスター(SM)、チームメンバーで構成する。

スクラムチームにとって大事なことは、自己組織化機能横断的である、ということ。

自己組織化

チームが誰かに管理されているのではなく、自らを管理できていること。進捗や課題の管理、プロセス改善などの活動を自分たちで適切に行えていること。

スクラムマスターは、プロジェクトマネージャやプロジェクトリーダーのように管理をするのではなく、チームメンバーが自分たちで管理できるように促す。

機能横断的

スクラムチーム外の誰かに頼らずにバックログをDONEにできるチームであること。また、チーム内での役割も完全な縦割り専任主義ではなく、T字型に役割を担えることが理想(コーディング担当、テスト担当とか専任にしない)。

これは、現実はなかなか難しいなーと感じました。やっぱりコーディング出来ない人はホントにできない(やろうともしない)ので。。

ただ、機能横断的であることが理想的なことは理解、共感できる。

プロダクトオーナー

プロダクトの仕様決定者。複数人いないほうがよい。どうつくるか、ではなく『何が欲しいか』をプロダクトバックログとして定義する。

自社プロダクトではない受託開発の場合、顧客側の人間がプロダクトオーナーになるか、もしくは顧客側の要求を深く理解しているメンバーが担当する。スクラムマスターとの兼任は避ける。

スクラムマスター

スクラムがうまく機能するように支援する役割。スクラムについては一番詳しく、プロダクトオーナーやチームメンバーをコーチする(開発そのもののコーチではなく、スクラムのコーチ)。

スクラムマスターはメンバーを兼任しても良い。

プロセス

スクラムでは、スプリントいう単位で価値創造をくり返しながら漸進的に開発を進める。各スプリントの期間(長さ)は固定化する。最長でも一カ月。チームによっては、半日スプリントという短さでやっているところもあるらしい。

スクラムでは、さまざまな活動にタイムボックスという概念で制限時間を設定している。

 

スクラムイベント(活動)

スクラムにはいくつかのイベント、活動が定義されている。さらに、それぞれについてタイムボックスが決められている

  1. スプリントプランニング
  2. デイリースクラム
  3. スプリントレビュー
  4. スプリントレトロスペクティブ
  5. プロダクトバックログリファインメント
  • スプリントプランニングでは、そのスプリントで実現するバックログをピックアップする。選択したプロダクトバックログアイテムと、それらを届ける計画を合わせてスプリントバックログという。
  • デイリースクラムは、前日の作業、本日の作業の確認を行う。抱えている課題や、乗り越えた課題なども共有する。毎日同じ時間と場所で行い、リズムをつくることが大事。
  • スプリントレトロスペクティヴ(振り返り)では、改善案を出し合い、次のスプリントで実施する案を決める。さらにそれをスプリントバックログに加える
  • プロダクトバックログリファインメントとは、スクラムガイドに以下のように定義されている。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の 10%以下にすることが多い。

タイムボックス早見表

スプリントが一週間の場合
  • デイリースクラム:15分
  • スプリントプランニング:2時間
  • スプリントレビュー:1時間
  • スプリントレトロスペクティブ:45分
  • プロダクトバックログリファインメント:4時間
スプリントが二週間の場合
  • デイリースクラム:15分
  • スプリントプランニング:4時間
  • スプリントレビュー:2時間
  • スプリントレトロスペクティブ:90分
  • プロダクトバックログリファインメント:8時間

リンスタの革新会計を考える

リーンスタートアップの中で、革新会計というものがいまいちイメージ出来ていなかったが、グロースハックやファネル分析について学ぶうちに、少し自分なりに腹落ちした(しかけている)ので整理しておこうと思います。

 

リーン・スタートアップ

リーン・スタートアップ

 

 

 

まず、ファネル分析について

ターゲットが特定の行動をとるまでのプロセスを分解して考え、どこで離脱しているかを明らかにする分析手法。

"特定の行動をとる"ことを、成果達成とかコンバージョンといい、その達成率をコンバージョンレートという。

よくあるのは、webサービスのサイト訪問者が会員登録するまで、の流れをファネル分析で最適化したりする。

この場合、例えば以下のようなファネル構造と考えることができる。

  1. サイトの存在を知る
  2. サイトにアクセスする
  3. 会員登録ページに移動する
  4. 会員登録に必要な情報を入力する
  5. 確認メールを受信する
  6. メール本文にある認証完了URLをクリックする

このステップのどこを開始とし、どこを達成(=コンバージョン)と考えるか、はケースバイケースだが、ビジネス的な価値につながるステップをコンバージョンと置くのが良いと思う。

これらのステップのどこで離脱している人が多いかを計測することで、適切な打ち手を考えることができる。

さらに、ターゲットごとにトラッキング(追跡)できればなお良い。離脱している人たちに共通する特徴が見えるかも知れないからだ。

 

革新会計

リーンスタートアップでの革新会計(innovation accounting)という考えは、このファネル分析を新規事業の成長計測に使おうというものだと理解しています。

ポイントは、"数"や"売上"ではなく"率"でみるところ。ビジネスの成功につながる注目すべきコンバージョンは何かを考え、その達成率を向上させることを目標にする。つまり、"〇〇率"をKPIにする。さまざまな施策を打ちながら、KPIが狙った方向に上昇(もしくは下降)していく傾向があるかどうかで、新規事業の成長が上手くいっているか否かを判断するということ。

 

リアルな世界での話

上記の考え方は、リアルな世界でも適用できると思う。

例えば、サービスを売り込むときを例に考えてみる。

  1. メールでアポを申し入れる
  2. 日程を確定する
  3. 訪問して説明する
  4. 後日、問い合わせが来る
  5. 契約につながる

みたいなプロセスだとして、メールの文面を変えながら、アポの成功率が上がる文面にチューニングしていく、送信相手を変える、という事が当てはまる。さらに、訪問したときの説明の仕方(プレゼンのみ、資料渡す、movie見せる、など)による変化を計測するということもやれそう。

 

まとめ

要は、ちゃんと指標を定めて、それをモニタリングしましょうね、という事ですね。

リクルートさんのリボンモデルについて書かれた書籍でも、『勝ち筋』や『価値KPI』という言葉が出てきていましたが、同様の考え方なのだと理解しています。

リクルートの すごい構“創

リクルートの すごい構“創"力 アイデアを事業に仕上げる9メソッド

 

 

 

MovidiusとRaspberry Pi Zero Wでディープラーニング

Intel Movidius NCS をRasPi ZeroWで使ってみた話です

 

f:id:jiig999:20180907083034j:image

 

はじめに

Intel Movidius NCSを手に入れた。正式名称はIntel Movidius Neural Compute Stickというらしいです。

こいつをUSBポートにぶっさすと、DeepLearningを高速化してくれるという代物です。

www.switch-science.com

 

当たり前ですが、何でもかんでも高速化出来るわけではなく、ディープラーニングの領域のうち、トレーニングは無関係です。トレーニングしたモデルを使った推論部分を高速化します。トレーニングによって出力されたモデルを、専用のSDKで提供されるコマンドを使ってNCS用にコンパイルして使います。

ですので、既存のソースコードそのまんまで、挿すだけで高速化という訳ではありません。また、対応しているディープラーニングフレームワークはCaffeかTensorFlowの二つになります(2018.09時点)。

こいつを手に入れて、まずはRasPi3で動かしてみました。とりあえず簡単なサンプルが動いたところで、どうせエッジコンピューティングやるなら、もっと安価で小型のラズパイゼロでやってみたいなぁという思いに駆られ、気がつけばAmazonでRasPi Zeroをポチっていました。こうして修羅の道に足を踏み入れてしまったのです。

 

今回やりたいこと

ラズパイゼロでディープラーニングを(そこそこ)高速に動かしたい。

流れ

  1. 学習用の環境構築(Docker for Windowsを使用した)
  2. RaspiZeroに推論実行用の環境構築
  3. 学習環境でトレーニングし、モデル出力(Kerasを使用)
  4. KerasモデルをTensorflowモデルに変換
  5. mvNCComplileコマンドを使ってTensorflowモデルをMovidius用にコンパイル(graphファイルが出力される)
  6. graphファイルを推論実行環境(RaspiZero)にデプロイ
  7. RaspiZeroで推論を行う

ざっくりこんな流れです。ようやくRaspi3でできていたレベルに追いつきました。本当にやりたい事(自分で何か作ってエッジで動かす)はここからですので、頑張ります。

力尽きたので、気が向いたら流れの詳細を書き足していきます。

解説

ネットにもなかなか情報がありませんでしたが、そもそもRaspberry Pi ZeroではNCSDKでのモデルコンパイルはできない事が分かった。でも、変換済みモデルを使って、MovidiusNCSでの実行(推論)はできる。

よって、学習&NCSDKモデル変換用の環境が別途必要になる。面倒だったが、そもそも本気でやるときは学習環境と推論実行環境は異なることになるので、よしとした。 

ハマったポイント
  • Movidius NCSDKのインストール方法がいろんなサイトに書かれているが、なんかGithubリポジトリがつながらなくなっていて、代わりにtarファイルをAmazonS3から取得する手順になっていたこと。git cloneに失敗するので、ブラウザで見てみて気づきました。どうも暫定的っぽいですが。
  • NCSDKが新しくV2が登場しているが、ネットの記事はV1のものも多く混乱した。
  • TensorFlowそのままではなく、Kerasを使いたかったが、MovidiusはCaffeかTensorFlowにしか対応していないのでKerasモデル→TensorFlowモデルへの変換が必要になりました。
  • 当初、RaspiZeroにMovidiusをぶっさすと再起動が走り、はまりました。結局USBバスパワーの電力不足だったようで、ACアダプタ付きのUSBハブを間に挟むことで解決しました。
  • (その後の追記)電力不足については、USBからの給電がデフォルトでは600mAらしく、1200mAに変更することでハブ無しで動くようになりました。やり方は、/boot/config.txtに、max_usb_current=1の設定を追記してラズパイを再起動するだけ。
  • Windows+Dockerの構成だと、ホスト側のUSBを認識させることができないので、Movidiusを挿して推論実行させることはできません。Docker Toolboxを使うとか、VirtualBoxUbuntuVMを起動して、とやればできるが、Docker for Windowsと共存できない(Docker使うときとVirtualBox使うときでいちいち設定を変更して再起動しないといけない)ので断念しました。ホント、最近の開発ではWindows使うとMacと比べてムダな作業が増えることが多い気がする。

 

参考にしたサイト

How to run Keras model on Movidius neural compute stick | DLology

主にこのサイトを参考にしました。使用するTensorFlowのバージョンが新しいので、Pythonコード中のKerasのimport部分を変更する必要があります。

from keras import layers, models

とかを、

from tensorflow.python.keras import layers, models

に変更します。

 

developer.movidius.com

 

AmazonEchoの醍醐味はスマートホームスキルにあり

久しぶりにAmazonEchoの話題。

少し前のことですが、Nature Remoがついに、スマートホームスキルに対応してくれました。

(ベータテスター参加で使っていたのですが、そのあとすぐに一般公開されました)

f:id:jiig999:20180907093950j:image

 

スマートホームスキルとは

AmazonEchoで使えるさまざまな追加機能(スキル)には、いくつか種類があります。

と言っても、ユーザーから見ればあまり違いは分からず、開発者が意識することの方が多いのですが。

2018年4月時点では、以下の3種類から選択して開発することになります。

 

カスタムスキルというのは、会話モデルを1から考えて作り上げるもので、汎用性が高い反面、ユーザーが話すであろうさまざまなフレーズをある程度想定して設定する必要があります。Alexaは、設定されたサンプル発話をベースに学習し、ユーザーの話す内容を処理に振り分けます。

 

これに対して、スマートホームスキルでは、スマートホーム(主にリモートコントロール)というコンテキストのためのサンプルフレーズが事前に設定されています。開発者は、会話モデルを設計して、設定する必要がありません。

 

で、何が便利なのか

ここまでは開発者目線の話。

ユーザーからして1番の違いは、『スマートホームスキルでは、スキル名を言わなくてもよい』ということです。

いざ使用してみると、ユーザー体験としてこの差がとても大きいと感じました。

 

カスタムスキルでエアコンONできるスキル(仮にスキル名を"俺リモコン"とします)を作った場合、「アレクサ、俺リモコンでエアコンつけて」と話しかける必要があります。

スマートホームスキルでは、「アレクサ、エアコンつけて」でOKです。

この"俺リモコン"の部分が邪魔なのです。Amazon Echoというか、Alexaでは、基本的に会話モデルを学習し、多少の表現の違いは吸収してくれ、これがAIスピーカーならではの強みでもあります。

しかし、スキル名の部分は、キーワード扱いなので、間違わずに発話しないといけないですし、そもそもスキル名なんだっけ?となりがちです。

※実際には、発話するのはスキル名ではなく、呼び出し名なのですが、ここでは触れません

 

今後に期待

便利なスマートホームスキルですが、まだまだ足りない部分があります。そもそも、スマートホーム向けなのでそれ以外のことを実現したいスキルでは使えません。

また、スマートホーム用途でも、事前に用意されている会話モデル以外のことはできません。例えばエアコンのモード切替などは対応していません。

 

※2018/04/28

近々、Alexaの機能強化が行われ、スキル名なしでも適切なスキルを起動して対応してくれるようになる予定らしいです。ただ、日本での公開はしばらく先になりそうです。