ex-mixiのその後
こんばんは！12月になったのでブログを開設しました。
というかこの記事はex-mixi Advent Calendar 2017 - Qiitaの2日目担当の記事なので、そのためにブログ開設したと言っても過言ではありません。
1日目のmasartzさんお疲れ様でした！
ex-mixiつまり株式会社ミクシィを卒業した人のくくりなので、多分少しくらいエモい話は入りますよね。
なので技術的な話オンリーならばQiitaに書いていたのですが、Qiitaでこの記事書くとちょっとあれなので。
自己紹介
2011年にmixiに新卒入社し、日記やつぶやき機能の開発エンジニアとして働いていました。
学生のころはずっと理系で、音声や雑音抑圧に関する信号処理を研究していたので、プログラムは書いていましたが、WEBエンジニアというくくりではほぼ初心者で入社しました。
入社当初は本当にもうどうしようかと思うくらい意味不明なことばっかりで、一行のコード書くのに3日かかったりしたこともあったのはいい思い出です。
開発という仕事以外の面で、やんちゃなことをして注意されたり、変なやつだと思われたりしてたらしいですが、あまり記憶にありません。
大きめなプロジェクトでいうとつぶやきの公開範囲制御（昔はつぶやきの公開範囲は個別で変えられなかったのです）、つぶやきネタなど開発した後、Androidアプリをちょこちょこ作って、モンストが開発途中のときにおっさんマンというゲームを作りました。
その後大阪の中小零細企業を一瞬手伝い、リクルート（マーケティングパートナーズ）に転職しました。
リクルート時代は料理サプリ（現ゼクシィキッチン）というサービスを立ち上げ段階からジョインすることができました。Androidアプリの立ち上げからリリースまで元ミクシィのエンジニアと開発をするというおもしろい状況でした。
その後Drivemodeというシリコンバレースタートアップにジョインして今に至ります。
mixi 2011年新卒同期は25人(エンジニア11人、総合職14人)、今残っているのはそのうち約20%、スタートアップに転職している人が割りと多め、個人事業やっていたり、会社立ち上げにジョインしたり、イラストレーターになったり、キャビンアテンダントになったり、様々な進路を歩んでいますし、中には億の資産を築いた人や年収1000万超えプレーヤーも普通にいます。6年も立つとこんなにも変わるのですね。でもやっぱり億はビビりますよね。卑怯だぞ！！！！本丸！！！！！！！(CV: 原子力(タルるート))
スクラム
そういえばスクラムはかなりやってきたけどスクラムに関する記事は書いてこなかったなとふと思い、ここでいきなりスクラムの話をします。
テクニカルな記事はQiitaにあるので、そっちはさらっと紹介程度にしようかなーと思ってます。
スクラムとの出会い
ずっとエンジニアとして働いてきましたが、スクラムマスターという役割も並行してこなしていました。ミクシィ時代にはCertified Scrum Professional(以下CSP)保持者にみっちりついてもらってスクラムマスターの役割としてビシビシ鍛えられ、リクルート時代にはOdd-eの本物のアジャイルコーチについてもらってたくさん知見をいただきました。Certified Scrum Master(以下CSM)をサクッと取得し、実務を積み重ねてCSPになって2年が経過しました。
現在ではScrum Allianceの公認コミュニティであるScrum Masters Nightの運営の一人となっています。
「スクラム」はまるで変わっていない
何年経っても日本におけるスクラムに対する印象や理解、結果などあまり代わり映えしていない印象があります。
スクラムそのものはスクラムガイドがマイナーアップデートされたり等の少しの変化はあるのですが、基本的に全く変わってません。
しかし数々の組織がスクラムに挑戦し、うまくいかず（というかデメリットを感じ）、やめていくという話をよく聞きます。
スクラムがベストなものでは決してないので、やめるのは全然良いのですが、その後適当マネジメントに戻ってしまうのは避けたいですね。
スクラムは結局アジャイルの現状を可視化し、改善の機会を得るためのフレームワークなので、スクラム自体に価値があるいわゆる銀の弾丸ではないです。これはよく言及されているので、もちろんよく知られているとは思います。
可視化されたあと、チームを良くするための取り組みをするのはそのチーム自身に依存します。皆がBe Agileであって初めて成功するものです。
そもそもAgileとは
スクラムをアジャイル開発手法と度々言われますが、Agileというのは状態のことなので「Agile」単体で使われることと、「アジャイル開発手法」という言葉で使われるときで少しニュアンスが違います。ちょっとややこしくなるので今回はアジャイル開発手法という言葉は使わないでおきます。
Agileという言葉の始まりは2001年頃であり、とある集団でアジャイルという言葉が使われ、アジャイルマニフェストというものが作られました。アジャイルマニフェストは、その価値と原則が定義された物になります。
スクラムをやっているからアジャイルだというのは間違いで、むしろアジャイルじゃないからこそ失敗するのです。
なので「Don’t just Do Agile, Be Agile」などとよく言われています。
Be Agileだったらどうなるの？
それで、アジャイルな状態だったら、つまりアジャイルのマインドセットを持っている状態だったらどうなるのか。
なんとなくチームよくなりそうだってのはわかりそうですが、Agile Singapore でLinda Risingさんという方が発表していた内容で
こんなのがあります。
学生をFixedグループ、Effortグループに分けました。
Fixedグループは子供の時に「あなたは頭が良い」など人物に対して褒めたり、しかられたりした。
Effortグループは子供の時にとった行動や努力に対して褒められたり怒られたりした。全員に下記の選択をしてもらいました。
more difficult test
another easy test
90%のEffortグループの学生は1を選びました。80%のFixedグループの学生は2を選びました。とてもむずかしい試験を2つのグループに行わせました。
Effortグループの学生はとても楽しんでたっぷり働きました。
Fixedグループの学生はいとも簡単に落胆しました。そして、下記のどちらかを選択して回答してもらいました。
誰が一番頑張ったか、良かったか
誰が一番足を引っ張ったか
Effortグループは1を選びました。Fixedグループは2を選びました。また簡単なテストを受けてもらいました。
Effortグループはスコアが上がりました。他の学生を励まし、スコアを伸ばすためにはどうしたらいいかアドバイスをしてもらいました。
Effortグループはたくさんのアドバイスをと励ましをしました。Fixedグループはアドバイスをせず、40%が自分のスコアに嘘をつきました。
スクラムをやるかやらないにかかわらず、良い組織にはなりそうですよね。
スクラムじゃなくていいんじゃないか
Be Agileになったあとは特にスクラムやらなくてもいいんじゃないでしょうか。
でもお察しの通りBe Agileになるのってすごく難しいんです。
そこで、スクラムなのです。
スクラムは次に述べるルールをしっかり守って真面目に取り組めば（もちろんAgileを意識して）、Be Agileに近づけるようになるフレームワークなのです。
スクラム守るべきルールは少なく、シンプル
スクラムにおいて守るべきルールというものは本当に少なく、19しかありません。
1. 検証
2. 適応
3. 透明性
4. 役割（プロダクトオーナー、スクラムマスター、開発チーム）
5. セレモニー
6. アーティファクト
7. スプリントプランニング
8. スプリントレトロスペクティブ
9. プロダクトバックログリファインメント
10. デイリースクラム
11. スプリントレビュー
12. プロダクトバックログ
13. スプリントバックログ
14. Impediment List （障害リスト）
15. スプリントの中止
16. スプリント
17. プロダクト
18. 受け入れ基準
19. Done
幾つかセレモニーの成果物も含まれているので、実際意識するルールはもっと少ないんではないでしょうか。
つまり何が言いたいかというと、この他はすべて自由なのです。
Q: スクラムだと残業しないといけない・・・
A: そんなことありません。残業する状態を作っている原因を探ってプランニングを改善していきましょう。
Q: スクラムで使ってるタスクボードが使いづらい・・・
A: タスクボードやフォーマット変えてください。TODO, DOING DONEとかじゃなくて全然いいのです。
Q: デイリースクラムが朝にあるのしんどい・・・
A: 朝以外にやってください
Q: このプラクティスやりづらいんですけど・・・
A: 19のルール以外のものはすべてローカルルールです。他のチームからの輸入してきたプラクティスやルールはあなたのチームに合わないのでやめると良いです。
など、今やっていて不満に思っていることはだいたいレトロスペクティブ（振り返り）で解決可能です。
もちろん、会社の制約条件はそれぞれにあり、難しいポイントはあると思います。
しかしそれを可視化することがやはり重要です。可視化されていなければ、その制約条件を解消しようとする上層部の動きは全くないでしょう。
良いコーチに見てもらい、トレーニングする
初めてスクラムを円滑にやるには、良いコーチについてもらうのが一番だと思います。
上記のルールに役割というものが定義されていますが、この役割をしっかりこなすのは、初心者では至難の業です。
特にスクラムマスターの役割をうまくこなすには5つスキルが必要だと言われています。
- teaching
- facilitating
- mentoring
- coaching
- situationaling
これらは普通みんな持ってないので、トレーニングしていく必要があるわけです。
Odd-eの方々は会ったらとりあえずcoachingのトレーニングを手短にすると聞いたことがあります。
一番馴染みがありそうなのでfacilitatingでしょうか。会議を進行していく役割ですね。
これもトレーニングする場所はあります。
Scrum Masters Nightという私自身も運営に携わってますが、このコミュニティで定期的にイベントがあるのでファシリテーションのトレーニングが可能です。
smn.connpass.com
こういった他者からのフィードバック、特に良いコーチからのフィードバックは非常にためになります。
スクラムはAgileになるためのトレーニングみたいなもの
なんかトレーニングっていう言葉ばっかり使ってますね。。。筋トレの影響でしょうか。
アジャイルになろうと、スクラムをうまく回していこうと努力し続けると上記のようなトレーニングによってスキルアップをしないといけないようになります。
これはスクラムマスターに限った話ではなく、開発チームのエンジニアやデザイナーは生産性を高め続ける責任があるので、それぞれのどこかのスキルを高めていく必要があります。それで皆が前向きにこういうことに取り組んでイケてる状態こそがAgileなのです。
※ よく誤解があるので一応説明すると、生産性をあげる=ベロシティを上げることではないということです。そんなことしていたら品質は上がらないし、プロダクトバックログの中身はカスカスになるし、残業は増えるし、柔軟な対応ができなくなります。プロダクトオーナーはプロダクトバックログのアイテムを作るのも大変なんですよね。デザイナーもPOとディスカッションすることが多く、ただでさえ開発チームメンバーなのに余計忙しくなります。開発チームはエンジニアが多数だと思いますが、デザイナーのケアは重要ですね。
エンジニアっぽいこと
というか私エンジニアなんですよ、技術の事書かないと行けないですよね。
でもこの流れでいきなり技術のこと書くのかと、自分に秒速1003回くらい問い詰めましたが、秒速1003回くらい"Yes"って返事が返ってきました。おばあちゃんから。いや俺のおばあちゃん日本人で関西弁やで。
あれ？でも長い？
長いわ！ってどっかから聞こえてきた。
じゃあちょっと手短に。
Drivemodeにおける音声コントロール
技術的なチャレンジという意味では現職のDrivemodeが圧倒的です。
世界の死因ランキングTOP 10に唯一ランクインする病気じゃないものは、交通事故なのです。
交通事故怖いですよね。自分がミスをしないという自信がある人は多いでしょうけど、たまたますれ違うミスをする人によって大切な命が脅かされるのです。
ポケモンGOでの事故は話題になりましたね。当然スマホによる不注意運転が原因による事故もかなり多く、増加傾向であります。
病気は医療業界に任せるとして、交通事故は別の人たちが解決せねばなりません。
日本ではカーナビが結構普及していますが、海外では全然だめで、スマートフォンを使ってナビゲーションなどを行っております。
たとえ違法であっても、その人達を事故させないように、そのために開発しているのがDrivemodeというアプリになります。
これはナビゲーションアプリではなく、スマートフォンの基本的な機能を画面をほぼ見ないで使えるインターフェースそのものと考えてください。
画面を見ないで使えるようにするためにはいくつかアプローチがありますが、当然音声コントロールというものは誰もが思いつくでしょう。
音声、ボイスコマンド
音声検索は凄くシンプルです。
目的地の検索をする際に音声認識を開始して、認識結果のテキストで検索をすれば良いだけです。
AndroidだとSpeechRecognizerがあるので、こちらを使うと容易です。
Android Speech Recognizerを使いこなす - Qiita
認識精度も高いです。
ただ、音声認識開始後の無音待機時間が短いこともあり、そこだけが厄介です。
Googleの音声認識エンジンは雑音抑圧はほぼしておらず、抜群に優秀なモデルだけでこの音声認識精度です。
余談ですが、音声認識のための雑音抑圧を研究していましたが、雑音抑圧によって音声認識精度はそれほど向上しません。
推定雑音を原信号から減算する際に歪みが生じてしまうからです。
この利用シーンのような目的信号が一つ＋拡散性雑音（無限の音源到来方位から到来する雑音、環境雑音）の場合は、Delay-and-Sumのようなシンプルな信号処理をして音声強調ができるとかなりの音声認識精度が見込めますが、スマートフォンにはそんな大きなマイクロフォンアレーはつめないので、やはりモデルを強くする必要があります。
莫大な学習データを持つGoogleにモデルで勝てることはなさそうですね。
さて、このAndroidのSpeechRecognizerはもちろんボイスコマンドにも使えます。辞書データ作るだけで良いです。
ただし、認識結果の表記ゆれも考慮して辞書を作る必要があります。
OK, Google
普通にOK googleみたいなん作りたいですよね！？あなたのアプリの名前が「すぎたさん」であれば、「よっ！すぎたさん！」って言ってアプリ起動すればかっこいいですよね。
DrivemodeでもSpeechRecognizerをスタートさせるときはタップするしかないという状態だと、完全なノールックインターフェースにはなりきれないのです。
それで実装したんです。
何も画面に触れずに
「Yo, Drivemode」
「Navigate to Tokyo station」
って言えばもう東京駅にナビゲーションしてくれるんですよ。（英語のみ対応のため、試験的機能です）
これ実現するためには連続音声認識を実装する必要があります。
上記のSpeechRecognizerだったら勝手に認識終了してしまうし、終わったら再開すればいいやんとおもうかもしれませんが、終了から開始までの間認識がとぎれますし、なにより開始、終了効果音が消せない仕様なので使い物にならないわけです。
あとはGoogle Cloud Speechも理論的には可能ですが、これを連続音声認識として使うととんでもないお金をGoogleに支払うことになりますし、ユーザーは通信量多すぎ！速攻で消した！ということでしょう（Cloud Speechはもちろんオンラインで認識します）。
オフラインで連続音声認識、それがpocketphinxです。
qiita.com
ネタっぽい記事になってますが、これ使えばOK googleみたいなのが実装可能です。
ここまでのお話は実はDroidKaigi2017で発表しているので、詳しくはそちらをどうぞ。
Drivemodeの運転検知起動
Drivemodeでは運転を検知して自動的に起動する機能があります。
スマホを車にセットして運転スタートするだけで起動すると楽ちんだし、安全ですよね。
ここではActivityRecognitionを使っています。
これは素晴らしい機能なのですが、精度が完璧ではないのでこれも工夫が必要になります。
そもそもどのセンサー使っているのかとか、どういうときに誤認識発生するのかとかいろいろとまとめ（る予定）のをDroidKaigi2018で発表致します。
最後に
コンテキストが私とmixiになってしまい、謎の構成になりましたが最後まで読んでくれた方いたらありがとうございます。
次はk_kinukawaさんよろしくお願いします！
