SPRINT最速仕事術を読んで(火曜日編)

前回は月曜日のタスクについてまとめた。 今回は火曜日のタスクについてまとめてみる。

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

火曜日:思考を発散させる

月曜日にはチームで取り組む課題を決めて、ターゲットを決めた。 火曜日はソリューションを考える。

材料を取り揃える

アイディアの素を集める

スプリントでは0から1を作るような方法はとらず、すでにあるアイディアを組み合わせて課題を解決することを目指す。 本書の中ではレゴの部品を集めるようなイメージと書かれている通りで、レゴの部品を自分で生み出したりはしない。

この作業はネットを使うなりなんなり方法を駆使して参考になりそうな他のモノを洗い出す。 他社製品でもいいし、他の業界の同様の問題を解決しようとしているものでもいいし、社内で過去に検討されたアイディアでもいい。

3分間の光速デモを行う

アイディアの素をチームで共有するために3分間の光速デモを行う。 アイディアの主な部分をビッグアイディアと呼びホワイトボードにメモしておく。

ここまでの作業はあくまでみんなでアイディアを共有し、チームの中に材料を取り揃えることを目的として行う。 ここで議論したりはとりあえずしなくていい。

スケッチを行う

今書き出したアイディアと月曜日に作ったマップとスプリントクエスチョンとどうすればメモは大切な素材集となる。 これからこの素材集を使ってソリューションを構築する。

その前に

ソリューションを構築していくためには「スケッチ」を行うが、チームのメンバーと誰がどの部分を担当するのか?それとも分担したりせずみんな同じ箇所を攻めるのかと言ったことはあらかじめ相談しておくこと。

なぜスケッチを行うか?

スケッチを行うことで抽象的なアイディアに具体性を持たせる。 抽象的なアイディアは具体性に乏しいので間違って評価されることが多い。 具体性がないので過小評価されたり、逆に過大に期待されたりする。 これに対してスケッチを行って具体的になったアイディアは公平な評価を受けることができるので、スケッチを行って具体的なアイディアにしてあげることが大事。

どうスケッチを行うか?

以下の4つのステップに沿って行うと良い。

  • メモ-24時間のベストヒット集を作る-
  • アイディア-落書き帳のようになんでも書く-
  • クレイジー8-高速でバリエーションを考える-
  • ソリューションスケッチ-3コマで全体像を見る-

メモ-24時間のベストヒット集を作る-

月曜日と火曜日のこれまでに作ってきたモノを見返して、気になったものをメモにとる。 20分くらいでこの作業を終える

アイディア-落書き帳のようになんでも書く-

20分くらいでざっくりしたソリューションのアイディアを書く。 自分しか見ないから適当に書けばいい。

クレイジー8-高速でバリエーションを考える-

上で作ったアイディアのバリエーションを8分で8個考える(ように頑張る)。 無茶なチャレンジではあるが、無難な原案をより興味深いものに押し拡げるためにとてもいい方法らしい。 同じアイディアの「これをやるための良い方法」としてのバリエーションをたくさん考えることが大事。

ソリューションスケッチ-3コマで全体像を見る-

ソリューションの全体像を3コマで表す。 顧客がサービスを利用するときに目にするものを、3つのコマからなるストーリーボードで表す。

最後に作成したソリューションは水曜日の朝いちばんに、全員で見えるように壁に貼りだして品評を行う。 なので、わかりやすく書くこと。 また、品評に影響を与えないように匿名にしておくことも大切。 キャッチーなタイトルを自分のソリューションにつけて、下手でも構わないので仕上げる。

基本的には1人1つのスケッチを描く。 ひらめきが止まらなければ複数書いてもいいが、収穫逓減の法則があるのであまり良い結果には繋がらないのが著者たちの考えとのこと。

最後に、ソリューションを回収し 他の人のスケッチは見ない。 初めて見る体験をできるのは1度きりなので、それは品評会の水曜日まで取っておくこと。

SPRINT最速仕事術を読んで(月曜日編)

SPRINT最速仕事術を読んだのでまとめてみる. 長くなりそうなのでまずはざっくりとした全体像と月曜日のタスクについてまとめる.

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

スプリントとは?

GV(Googleベンチャーズ)が活用しているプロセス.
5日間のタイムボックスで1つの実験を行うことで,難しい問題に対して迅速に結果を得ることを目的としている.
ここでの結果とは,アイディアの成功という結果や失敗という結果をさす.
成功する素晴らしいアイディアを必ずしも得られるということではなく,本来的には長い時間かけないと成功するか失敗するかわからなかったような複雑な問題に対して 迅速に結果が得られるというところが利点.
素早く市場から学びを得ることを目的としたプロセス.

スプリントの大まかな流れ

  • 月曜日:目標を固める
  • 火曜日:思考を発散させる
  • 水曜日:ベストを決める
  • 木曜日:幻想をつくる
  • 金曜日:テストする

スプリントのメンバー

専門分野に精通し,課題に情熱を持っている人を集めて7人以下でチームを作る.
その中には決定権者を絶対に含めるべき.
これらのメンバーには5日間はそれ以外の仕事から外れてもらって,スプリントに完全集中できる状態を作ること.

月曜日:目標を固める

プロジェクトの長期目標

目標は高く,ポジティブに,下記の長期目標を決める.

  • プロジェクト完了時に何を成していたいのか?
  • どうなっていたいのか?

スプリントクエスチョンを書き出す

今度は逆に悲観的に,プロジェクトが失敗したと仮定した場合の原因を探す.
敗北条件を定めるとも言い換えられる.
同時に,長期目標達成のために満たされるべきポイントも洗い出す.

洗い出したものを,「○○○は×××だろうか?」という疑問に置き換える.
置き換えることでワクワクする興味深い疑問に変える効果がある.

マップを作る

全体を俯瞰し,問題の構成を把握するために役立つマップを作る.
マップは複雑な問題を人間が扱える程度の複雑さに変換する効果がある.
マップは以下の要素で構成される.

  • アクター
  • 完了(例えばECサイトであれば購入など)
  • 一言フレーズと矢印

ここでいう一言フレーズは「動詞」になりそうなきがする.
アクターと完了をつなぐステップであり,アクターの動きを表すものが一言フレーズなのかもしれない.

専門家に聞こう

スプリントで解決したいような大きな問題には様々な陰影がある.
みる立場や方向によって色々な様相を呈する.
なので多くのソースから情報を集めることが大切になる.

特に以下の4つの軸で情報を集めることはとても大切である.

  • 戦略
  • 顧客の声
  • 仕組み
  • 過去の取り組み

これらをヒアリングし,マップの修正を行う. また,同時に「どうすればメモ」を作成する.

どうすればメモ

専門家の話から得られた情報やそこで生じた疑問,面白いと思ったことを「どうすれば」から始まる形で付箋に書き出していく.

チームみんなで書き出したメモをホワイトボードに張り出して,役に立ちそうな質問にみんなで投票する.
得票数が多かったものについて,先ほど作ったマップを振り返り,疑問が該当する箇所にどうすればメモを貼り付ける.

これによってマップ上での対応関係がわかるようになる.

ターゲットを決める

スプリントを通して取り組むべきターゲットを決定する.
ターゲットは「最もリスクが高く,最も大きなことができそうなもの」を選ぶと良い.
これはどうすればメモを見ると想像ができるはずなので,マップに貼り付けられたどうすればメモを参考にする.
どうすればメモを参考にして,マップ上からターゲットとなるアクターと一言フレーズを最終的には決定する.

これが決まったらスプリントクエスチョンを見直して,今回のターゲットで答えることができるものをピックアップする.

月曜日まとめ

長期目標でプロジェクトの達成すべきゴールを定めて,それに関連するスプリントクエスチョンを洗い出した.

全体を俯瞰するためのマップを作り,専門家の意見を取り入れてブラッシュアップした.

さらに,専門家の意見からどうすればメモを作り,チームの興味ある方向を共有した.

上記を受けて今回のスプリントでターゲットとなる瞬間を決定し,これによって答えが得られるスプリントクテスチョンが明らかになった.

残りの4日間はこれを明らかにするために頑張ろう.

とりあえず,月曜日のお仕事はこれにて完了.

人工知能研究会なるものに参加させていただきました

下記の研究会に参加させていただきました. 学生さんが主体でやっている研究会だそうです.

第17回 人工知能研究会「今後のDeepLearning技術の発展とビジネス応用」 https://air-osaka.doorkeeper.jp/events/60057

今日の研究会で聞けた内容が良かったのでお話を聞きながら取ったメモを晒します.

ビジネス応用

ビッグデータ解析と人工知能の違い

ビッグデータ解析は解析しておしまい. 一回では大抵良い結果は出ないのでうまくいかない.

人工知能はシステムを利用するたびに精度が上がっていく. 実運用しながら精度が上がっていくのが人工知能の特徴.

溜まったデータを解析することが目的となってはいけない. 何がしたいのか?そのために必要なデータはどんなデータか?を固めていくことが大切.

そしてデータは必ずしもビッグでなくてはならないわけではない

AIを導入しやすい領域

技術的課題

AIとの親和性が高い(ルール化・パターン化されている) データが取りやすい

社会的課題

AIが失敗しても被害が少ない(人が死なない・大損しない) AIに否定的な人が少ない

  • クラスタ別に分析が資料上ではありました.*
  • あの資料欲しいな・・・*

ビジネス利用のための人材育成のお話

データサイエンティストとして備えておくべきもの

  • 統計学
  • プログラミング
  • ビジネス知識 => お客さんの課題をどうAIに落とし込むか

それ以外にも幅広い知識が必要 物理とか数学とか心理学とか英語とか.

統計:理由を説明する学問.要因を見つける. 例)アイスクリームの売り上げを分析して主因を見つけたりする

機械学習:予測.当てればそれでいい.予測精度の追求. 例)アイスクリームの売り上げさえわかればいい!

AIシステム構築の流れ

課題設定=>AIモデル設計=>データ取得=>データ前処理=>アルゴリズム実装=>分析=>結果=>AIモデル設計へフィードバック

この流れを繰り返すのがとても大切. このために,データサイエンティストには幅広いアルゴリズムの利用経験と知識が必要.

よくある誤解

とりあえずネットワークにデータぶち込んだらええやん

分類精度をあげるには,データ前処理がとっても大事. 手法選定とかチューニングとかは支配的ではない. データ前処理が何より支配的!

データ前処理は実データ解析において重要. 手法の選択は研究において重要. チューニングはコンペにおいて重要.

一般物体認識と詳細画像識別の違いを把握しておく

一般的に誰が見ても明らかなものの比較と,専門家ではないと判断が難しいものの識別では難しさが当たり前だけど違う.

一般物体認識であればとりあえずデータをニューラルネットワークにぶち込んだらええ.ここら辺はよく論文として扱われる範囲. だから上のようにとりあえずぶち込んだらええやんという誤解が生まれる.

実社会で求められるような詳細画像識別ではこれだとワークしない.適切な前処理をしてあげることが大切.

データが大量に必要だが,質も大事

分析に適するデータベースは縦長(特徴量の次元に対してデータ量が多いという意味). 横長のデータはデータ量を増やして縦長にしてあげる必要がある. 要するに過学習の話だなきっと.

分類対象が増えても問題がない

分類するものが少ないほど精度が上がります. これは当たり前の話だと思うなぁ・・・よくある誤解なのかー

講師の考える今後大事になってくるDeepLearning技術Top4

DeepLearningは伸び代がやばい. 今できることって氷山の一角. 5年後,10年後にできることはもっといっぱいある.

これまでの技術と比べて複雑なモデルを扱えるようになってきた. 複雑であるがゆえに,表現度が高くなった.

2016年の現状 音声認識:実用レベル 画像認識:開発レベル~実用レベル 言語認識:研究レベル

2017年の現状 音声認識:実用レベル 画像認識:ほぼ実用レベル 言語認識:研究レベル~開発レベル

ということで講師が考える今後大切なDeepLearning技術Top4を紹介

第4位 転移学習

データが大量にあるドメインで学習させたモデルをデータの少ないドメインに使う. ドメインが大きく違っても高い精度が出るので一般的によく使われる. 別データで学習させたモデルを使って再学習させる.

コンペとかで優勝したモデルを使って転移することが可能. 画像系と音声系でかなり有効 テキストなどではあまり有用性が確認されていないとのこと.

One-Shot学習というものもある. 転移学習よりさらに少ないデータで学習させる. すでに作成されている特徴量空間に新たなクラスをプロットさせる方法. 少ないデータで学習可能だが,分類対象が増えると難しくなる.

第3位 DCGAN

絵の生成とかに使われる. 生成系と判別系のネットワークを戦わせて学習させていく. より本物に近い絵を作り出す技術っぽい.

画像の一部を欠損させて復元させる技術もある.

第2位 DQN

AI同士を戦わせてより強くしていく. 計算コストかかる.相当なリソースを持っていないと強化学習的な手法は難しい.

囲碁のように勝ち負けが明確な場合は有効だが,現実的な問題として良し悪しがわかりにくい問題については 強化学習のアプローチは難しかったりもする.

第1位 マルチモーダルDeepLearning

あらゆる構造のデータを同時に学習して概念を獲得してく. 言語認識精度の向上が見込まれる.

動画とか音声とかテキストとか数値とか,異なる構造のデータを同様に用いる.

テキストから動画を生成したりすることも可能になってきている.

ELBがApplication層でのロードバランシングに対応したらしい

AWSのELBが、Application層でのロードバランシングに対応したらしいです。 Application層で動くロードバランサーということで、ALBと呼ぶらしいです。

Application層で動作するロードバランサー

通信機能を7つの階層に分割するOSI参照モデル(物理層データリンク層・・・などに分割するモデル)の最上層であるアプリケーション層で動作するロードバランサーです。

アプリケーション層で動作するため、この層で使われているHTTPというプロトコル等をもとに負荷分散をすることが可能になったようです。

現状(2016/08)のALBはHTTPリクエストのURLを用いてバランシングすることができます。

ELBでできなかったことと、ALBでできるようになること

ELBは通信を受け、処理を自身の配下のインスタンスに振り分けるという働きをしてくれていました。この際に、全ての処理を同一グループのインスタンスに負荷を分散しながら振り分けるというのがELBの挙動になります。

一方で、ALBではリクエストのURLに基づいて処理を割り振るグループを選択することができるようになります。

例えばhttp://example.com/*へのアクセスはデフォルトでGroup1に振り分けつつ、http://example.com/fugaへのアクセスのみGroup2に割り振るといったことが可能になります。

利点

これにより、より粒度の小さいサービスの組み合わせによるサービスの提供が可能になります。

例えば、ユーザーというドメインCRUDするようなアプリケーションがあったとします。

http://example.com/user/createでユーザーを作成し、http://example.com/user/delete/{id}でユーザーを削除することができるとします。

ELBでは、ユーザーのCRUD機能を全て実装したサーバーをグループに入れておいて、http://example.com/へのリクエストを各グループに負荷分散して処理を振り分けていました。

これがALBではユーザーのCRUD機能をモノリシックに用意する必要がなくなります。

CreateやDeleteなど機能を単体で用意しておき、それらをGroup1とGroup2にそれぞれ格納します。 そして、http://example.com/user/createへの通信はGroup1に処理を振り分け、http://example.com/user/delete/{id}への通信はGroup2に処理を振り分ければいいわけです。

これによって、よりマイクロなサービスの組み合わせでサービス全体を提供することが可能になるわけです。

ALBを使う上で気をつけたいこと

deployの話

アプリケーションのdeploy周りについては考える必要が出てくる気がします。

ELBを使っていた場合はユーザーのCRUD機能が一枚岩で提供されていたので、deploy時にはまるっと入れ替えることができました。

これがALBを使っている場合はCreate機能やUpdate機能が分割できてしまうので、新旧を無停止で入れ替えようとするとタイムラグが起きて問題になる気がします。

今回は例を示す際にユーザーのCRUD機能をあげましたが、分割の単位はドメインごとに切るなりなんなり、サービスにあった切り口を考える必要があるでしょう。

可用性の話

各グループにそれぞれ別の責務を負わせるわけで、それぞれのグループで可用性を確保する必要があると思われます。複数AZで各グループ用のインスタンスを起動してあげる必要があるでしょう。 結構構成が煩雑になりそうなので、CloudFormationによるコード化はしておいたほうがいいかもしれません。

CloudFormationにはすでにALBも対応しているようで、AWS::ElasticLoadBalancingV2::LoadBalancerというようにElasticLoadBalancingV2ってやつを使ってあげればいいみたいです。

MySQLのスキーマ変更をオンラインでやるための選択肢比較

MySQLを使っていて、スキーマを変更したい場合はAlterTableを流す必要があります。 すでに稼動しているサービスのスキーマを変更する際に、可能な限り稼働中システムに影響を与えずにスキーマの変更を行いたいです。

理想はオンライン状態を保った状態でAlterTableが全て完了することで、これが実現できれば少なくともスキーマ変更に伴うメンテナンスのためのダウンタイムが発生しません。

これを実現するためには幾つか方法が存在し、制約もあるみたいなので調べてまとめてみました。

その前にAlterTableのこれまでの挙動を調べる

オンラインでのスキーマ変更を調べる前に、まずはAlterTableの伝統的な挙動(MySQL5.1まで)について簡単にまとめてみます。これによってオンラインスキーマ変更のために何が問題になっているか?が理解できると思います。

MySQL5.1までのAlterTableは、変更したいスキーマ定義に沿った空のテーブルを作り、そこに古いテーブルのデータをコピーすることでスキーマの変更を行います。 この際にデータの不整合を防ぐため、まずは古いテーブルへのデータの書き込みをブロックするlock状態に入ります(ちなみに、古いテーブルからデータが読み込まれたとしても、新しいテーブルへのデータコピー時に不整合は起きないため、読み込みはブロックされません)。

つまり、AlterTable実行中は書き込みがlockされるわけです。 古いテーブルに大量のデータが入っている場合には、新しいテーブルへのデータコピーに時間が掛かるわけなので、書き込みlockによるメンテナンスのためのダウンタイムがどんどん伸びていくわけです。

これがMySQL5.1までのスキーマ変更の挙動でした。

参考にさせていただいた記事はこちら

MySQL5.6からサポートされているオンラインDDL

DDLはデータ定義言語というもので、データベース自体を操作するためのSQL命令文のセットです。 AlterもDDLに含まれます。

多くのAlterTableの操作時に、上記のテーブルのコピーが発生しないようにする変更と、テーブルが変更されている時でも書き込みがロックされないようにした変更の2つを合わせてオンラインDDLと呼ばれています(ちなみに念のためですが、ロックが発生しないだけで、性能上の影響は当然出ます)。

あくまで 多くのAlterTable時であり、全てにおいてコピーが発生せず、書き込みがロックされないというわけではありません。 ざっくり書き込みロックされるされないで分類してみます。

書き込みロックされない

インデックスの作成,追加,削除 カラムのデフォルト値を設定する カラムの自動インクリメント値を変更する 外部キー制約を追加,削除する カラムを名前変更,追加※,削除,並べ替え 主キーを追加する ※オートインクリメントカラムの追加を除く

書き込みロックされる

全文検索インデックスを追加する カラムを追加する(オートインクリメントカラムの追加) カラムのデータ型を変更する 主キーを削除する 文字セットを変換する

参考にさせていただいたのはこちら

つまり、MySQL5.6からは変更の内容によりますが、AlterTable実施時にロックが発生しないケースもあるということです。

pt-online-schema-change

Percona-Toolkitという有名なツールキットに同梱されているpt-online-schema-changeというツールがあり、こちらを使うことでも読み書きロックなしでオンラインスキーマ変更が可能です。

pt-online-schema-change(長いので以後PT)はMySQLのAlterTableの挙動を内部的に再現してスキーマの変更を行いますが、工夫することでロックなしでの動作を可能にしています。

MySQL5.1では古いテーブルの書き込みをロックしてデータの不整合を防いでいました。 これに対して、PTはトリガーの仕組みを使うことで、書き込みロックを行わずにデータの整合性を保ちます。 古いテーブルから新しいテーブルへのデータコピー中に古いテーブルに対して更新が走った場合、トリガーが古いテーブルのデータ更新に伴って新しいテーブルのデータも更新するわけです。

トリガーはInsert, Update, Deleteの3種類全てが貼られます。 そのため 1つのテーブルに対して同じ種類のトリガーは貼れないため、トリガーがすでに貼られているようなテーブルにはPTは使えません。 なお、トリガーはMySQL5.0.2からサポートされるので、PTはMySQL5.0.2以上で動作するそうです。

参考にさせていただいたのはこちら

比較とまとめ

MySQLのオンラインDDLでもPTでもそれぞれ制約はありますがオンラインでスキーマ変更が可能であることがわかりました。オンラインDLLは、オンラインで実行可能なスキーマ変更の種類に制約があり、PTでは既存トリガーの有無が制約になることがわかりました。 また、オンラインDDLはMySQL5.6から、PTはトリガーをサポートしているMySQL5.0.2から動作することがわかりました。

次に性能比較ですが、こちらの記事によると、スキーマ変更にかかる時間は対して変わらないものの、スキーマ変更中の影響という観点からはPTの方オンラインDDLよりも小さいそうです。 さらに、PTでは設定できるオプションが多く、既存システムへの影響を考えながらきめ細やかな実行戦略が組めそうです。 サイバーエージェントさんのこちらの記事にある慎重に使うオプションや過去の失敗事例もすごく参考になります。

以上です。

機械学習のコースを修了した

Stanford大学のオンライン授業で機械学習コースを受講していましたが、この度めでたく修了しました。

機械学習をお勉強したい人には強くお勧めできる内容だったのでアウトラインだけ共有しようと思います。

ちなみに受講自体は無料です。 終了証明を取得したい場合はお金かかりますが、完全に自己満なのでどっちでもいいかと思います。

概要

機械学習の世界では知らない人はいない(?)というくらい有名な先生がわかりやすく機械学習の面白いところを教えてくれる動画授業です。

各動画には小テストがあり、自身の理解度を確認しながら進めることができます。

週に1トピックスの内容を学ぶスケジュールでコースは設計されており、1週間分の動画を全て見た後にはoctaveという言語を用いて実際に学んだ内容を実装してみるプログラミング課題を解きます。

動画授業を受けるだけではなく実際に手を動かしてみるので、理解度が上がります。

学習できる内容

毎週のトピックはざっくり以下の通りです。

線形回帰について

コース全体を通して使われる基礎的な考え方が説明されます。 コスト関数とか最急勾配法とかの説明がされます。

ロジスティック回帰について

線形回帰から派生してロジスティック回帰についてです。 線形回帰で扱えない問題の説明と、それを扱うためのロジスティック回帰の説明です。

ニュラルネットワークについて

今はやりのDeepLearningにつながるニューラルネットについてです。 ニューラルネットのアイディアの説明と、ロジスティック回帰との関連性についてわかりやすく説明されています。

機械学習を用いたシステムを開発していく時の注意点について

機械学習を用いたシステム開発を行う上で身につけておくべき考え方や評価指標についてです。 これを知らないでシステム開発を行うのは時間の浪費だとはっきり理解できる構成になっています。

具体的には学習曲線を用いたアルゴリズムの評価方法を学びます。

自身の構築しているシステムについて、アルゴリズムが適切なのか?学習モデルは適切なのか?学習サンプルを増やすことで性能改善が見込めそうか?それとも学習サンプルを増やしても別の問題が起きているので性能改善が見込めないのか?といった知見を得られるようになり、次に試すべきことが判断できるようになります。

SVMについて

ロジスティック回帰から派生してSVMについてです。 SVMの利点とかが説明されます。

教師なし学習(クラスタリング)について

教師なしデータに対する機械学習の例についてです。 得られたデータをクラス分けする方法を学びます。

具体的にはk-meansアルゴリズムを使ったクラスタリングを学びます。

異常検知学習について

こちらも教師なしデータについての機械学習です。 「いつもとなんか違う!」を検出する方法を学びます。

具体的には得られているデータから事象の確率を求め、 異常に低い確率でしか発生しないデータが得られたら「いつもと違う!」と判定するようなアルゴリズムについて学びます

大規模機械学習について

大量データを扱う上での注意点とかそこらへんのトピックスが説明されます。この内容についてはプログラミンング演習はありません。

Photo OCRを例とした機械学習ワークフローについて

複数の機械学習コンポーネントを組み合わせて開発を行う上でいかに全体最適を満たすために開発リソースを割り振っていくか?というないようです。

大きくて複雑なシステムを効率良く開発していくために必要な知見が得られます。

まとめ

以上長くなりましたが、こんな内容を学ぶことができます。

高度な数学的な背景は知らなくても理解できる講義になっているので興味のある方は是非受講してみてください!

ちなみに最後まで受けると有料ですが、受講証明書をもらうことができます。 完全に自己満ですが、かなり良いコースだったのでお礼の意味も込めて取得しました。

CloudFormationでストリーム名を指定してKinesisストリームを作成することができるようになりました!

2016/06/09のアップデートでストリーム名を指定してKinesisストリームを作成することができるようになりました!

https://aws.amazon.com/about-aws/whats-new/2016/06/aws-cloudformation-adds-support-for-amazon-vpc-flow-logs-amazon-kinesis-firehose-streams-and-other-updates/

詳しい方法は下記をご参照ください。 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-kinesis-stream.html

ここでは簡単にCloudFormationに用いるJsonをご紹介します。 と言ってもかなり直感的にNameを指定してあげたらいけます。

{
  "AWSTemplateFormatVersion" : "2010-09-09",

  "Resources" : {
    "KinesisSample": {
       "Type" : "AWS::Kinesis::Stream",
       "Properties" : {
          "Name" : "Kinesisストリーム名",
          "ShardCount" : シャード数
       }
    }
  }
}

ストリーム名を指定するために、わざわざKinesisストリームを別の手段で作成していたケースにおいて、CloudFormationに集約することができるようになりました!