jiigのREDOブログ

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

認定スクラムマスター(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. スプリントプランニング:8時間
  2. デイリースクラム:毎日15分以下
  3. スプリントレビュー:4時間
  4. スプリントレトロスペクティブ:3時間
  5. プロダクトバックログリファインメント:16時間
  • スプリントプランニングでは、そのスプリントで実現するバックログをピックアップする。選択したプロダクトバックログアイテムと、それらを届ける計画を合わせてスプリントバックログという。
  • デイリースクラムは、前日の作業、本日の作業の確認を行う。毎日同じ時間と場所で行い、リズムをつくることが大事。
  • スプリントレトロスペクティヴ(振り返り)では、改善案を出し合い、次のスプリントで実施する案を決める。さらにそれをスプリントバックログに加える

 

タイムボックス早見表

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

読書記録

せっかく読んだ本を少し記録として残しておこうと思います。今年(2018年)に読んだ本が中心ですが、一部、2,3年前に読んだものもあります。

 

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人からはじめて、「越境」するチームをつくるまで

 

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

 

まだ他にも今年読んだ本が書ききれていないので更新する予定。

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

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

 

リーン・スタートアップ

リーン・スタートアップ

 

 

 

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

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

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

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

デザインシンキングとは何だ

デザインシンキング、デザイン思考

デザインシンキング、デザイン思考を最近よく耳にします。まあ感性の高い人たちにとっては今さら!?というはなしなのですが、私の周りは非常に感性の低い組織なので、、、。

 

さて、では、デザインシンキングとは、何ですか?

突っ込んで聞かれるとドキッとしてしまう質問のひとつです。何やら正体がつかみにくいモノです。

 

デザイン思考が世界を変える (ハヤカワ・ノンフィクション文庫)

デザイン思考が世界を変える (ハヤカワ・ノンフィクション文庫)

 

 



イカの場合

イカって何?と聞かれたら、

『スイカは人の頭より少し大きいぐらいの大きさで、緑と黒のしま模様の固い皮で覆われていて、中の赤い果肉を食べると甘い果物です。』という説明でまぁだいたいスッキリします。要するに、スイカは果物(の一種)ということになります。(野菜でしたっけ、、。)

 

ところが、デザインシンキング、デザイン思考となると、ググってみてもなかなかこれだ!という説明に出会えません。と、少なくとも私は思っています。

 

デザイン+シンキング??

そもそも、違和感があるのが"デザインシンキング"ということば。design thinking。うーん。。。分からん。

ロジカルシンキングは、英語でlogical thinking。直訳すると"論理的な思考"となり、思考法の1つであると言えそうですし、実際にその理解で良いでしょう。

対して、デザインシンキングってなると、design thinking 。designは動詞か名詞、thinkingはこの場合、"考え、思考"という意味の名詞と捉えるのが自然です。で、デザインという言葉を少し補足して、デザインにおける思考法。とかデザインにおけるマインドセット。と説明するようにしています。

 

そう考えると、『デザインシンキングやります』という表現は誤りですね。デザインシンキングやります、とかデザインシンキングを取り入れますが正しい表現だと思うのです。

 

デザインって?

そもそも、デザインということばが日本では限定的な意味で捉えられることが、デザインシンキングって何だ?となる原因のひとつのように思えます。

デザインシンキングというのは、デザインにおける思考法(というよりマインドセット)と言いたくてつけた名称なのですが、日本ではデザイン=アート、に近い理解なので、ここでまたつまづくわけです。図案や外観に限らず、何かを設計することが本来のデザインの意味のはずですよね。

 

 

必須ではないもの

誤解を恐れずに言うと、以下のことは、デザイン思考、デザインシンキングとして必須ではありません。

ポストイットを使う

・メンバーが一堂に会してワーッとディスカッションする

・ラフな服装で取り組む

 

これらは、デザインシンキングの本質ではありません。デザインシンキングをデザインシンキングたらしめている核となるモノではありません。

 

デザインシンキングは万能ではない

デザインシンキングは、『問題解決のアプローチのひとつ』です(と、私は自分なりに定義することにした)。特徴として、問題の起こっている現場や人に対して深く理解する(共感)ところから始めること、が挙げられます。

問題と、その問題で困っている人を深く理解し、本当に解決すべき問題をあぶり出し、簡単なプロトタイプで小さく仮設検証と学習、新たな気づきを繰り返して進めます。

そうすることで、本当に解決すべき問題を、当事者にとって好ましいやり方で解決することを目指します。

 

しかし、ビジネス要素には全く言及していません。

なので、デザインシンキングで導き出したアイデアが、ビジネスとして儲かるモノになる(=マネタイズできる)か、は別です。ココをわかっていない人が多いです。

ここを分からないままに、デザインシンキングに過剰な期待を抱き、新しいビジネス企画に中途半端に取り入れようとして失敗する、というケースを見かけます。

社内の問題を解決する上ではデザインシンキングはそれ単独でも有効です。しかし、新しい製品やサービスとして儲かるものを考える場合には、デザインシンキングだけでは不足しています。どこでお金を得るか、いくら支払ってもらえそうなのか、そのとき収支バランスはプラスなのか、、、。ビジネスとして成立させるために必要な要素は他にもたくさんありますが、デザインシンキングはそこはカバーしていないのです。決してデザインシンキングがダメということでは無くて、新しいビジネスを創出するときにデザインシンキングだけでは足りない部分があるんだ、ということを知っておく必要がある、ということです。

 

なんかとりとめのない文章になってしまいましたが、このぐらいにしておきます。

自分用のメモ

あくまで自分用のメモです

いろんなことばの定義や調べたことを覚え書きとして残しておくためのページ

 
ビジネスモデル
  • ミニマムな定義としては、お金をどうやって儲けるか。誰に何を売ってお金をもらうのかということ。『ピクト図解』で表現すると良さげ。
  • 広い定義としては、上記に加えてどういう顧客にどんな価値を提供するのか、であったり、顧客との接点(チャネル)やコスト構造などを含む。ビジネスモデルキャンバスの各ブロックの内容に相当する。『ビジネスモデルキャンバス』で表現すると良さげ。
コンセプト
  • サービスや活動の全体を貫く方針、基本理念を文章で表現したもの。あえて文章としておく。
  • ≠キャッチコピー。キャッチコピーはコンセプトを短い言葉やワンセンテンスで伝えるためのもの。なのでコンセプトの方が上位概念である。
  • コンセプトは“自然と人工の調和”です。というときも、実際は詳細な補足説明があるはずで、それも含めて初めてコンセプトとして成立する。なので、コンセプトを一文や短い言葉のみで表現することのみに注目すると失敗する。
  • とはいえ、説明する際やプレゼンにおいては、「今回のイベントのコンセプトは○○です」という表現をする。

 

開発の工程定義

いちおうシステムエンジニアなので、ときどきは工程を意識したお仕事もします。そんなとき、自分なりにプロセス定義を持っていないとクライアント企業と会話が空中戦になるので整理。

 

個人的に好きな工程(フェーズ)定義
  1. 企画
  2. (業務)要件定義
  3. (システム)要件定義
  4. 基本設計
  5. 詳細設計
  6. 実装、プログラミング
  7. 単体テスト
  8. 結合テスト
  9. システムテスト
  10. 運用テスト

以降、システムリリースを経て運用フェーズとなる。

最近苦労したのが、システムということば。ITシステムを意味するときもあれば、仕組み全体としてのシステムを指すときもある。

なので、要件定義をあえて細かく区切りました。ビジネスとか、サービスとしてとらえたレベルでの要件と、それを実現するために必要なITシステムに求められる要件を分けるべきだと考えました。

結局このあたりは正解とか唯一の答えは無いと思っていて、ウチではこう考えています、こう呼んでいます、というのを資料ベースで認識合わせするしかないです。