組織の拡大に伴うアジャイルなプロダクト組織構築
Drivemodeというスタートアップにジョインしてから4年が経ちました。ジョインした（入社すると決めた）当時はまだシードラウンド以前であり、ファウンダー4人+エンジニア2人という状態でした。ですが今となっては組織も数十人規模まで大きくなってきています。
組織が大きくなるにつれ、様々な組織やマネジメントの問題に遭遇するようになり、今後もこれらと真剣に向き合わないといけません。
本記事では、これまでの経験を踏まえて、組織の成長に伴ってどのようなアプローチで組織や文化を構築すれば良いか、考えをまとめて書きます。
常に管理されたプロダクトバックログの重要性
いきなりですが、まずプロダクトバックログの話をします。
常に管理されているプロダクトバックログというものは非常に大切です。プロダクトバックログとは目的地に向かうための道筋であり、そこが空になっていたり、でたらめな状態だと、車（プロダクト）は暴走（それぞれ好き勝手開発され）したり、停止（まったく開発されない）したりします。エンジニアリソースを有効活用できないということは言うまでもありません。
これはすべての組織、方法論に言えることだと思います。「何をやるのか」はエンジニアの開発スピードよりも、プロダクトの技術的品質よりも、何よりも大切なことです。
プロジェクト組織とプロダクト組織
上記でいきなりプロダクトバックログの話をしましたが、この扱いがプロジェクトとプロダクトで大きく違います。
プロジェクトとは、一般的には始まりと終わりが明確に決まっているものです。「何かをやろう」と思ったときに何かをやるプロジェクトが発足し、そのためのチームが編成され、プロジェクトが終わると同時にチームが解散します。つまりその後「なにをやるのか」がなくなるということです。
そのため、プロジェクトが行われ、プロジェクトが解散すると、それによって生み出された成果物はしばしばオーナー不明でメンテナンスしづらいものになってしまいます。まさに作って終わり状態です。
一方でプロダクトとは、製品そのものであり、プロダクト組織とはその製品の寿命と同じくずっと存在します。「なにをやるのか」は常にプロダクトバックログで管理されています。
toCサービスのようなプロダクトにおいて、プロダクトチームというものが存在する場合は、プロジェクトからの引き継ぎによってなんかすることも可能ではありますが、そもそもプロジェクトをやらずに、プロダクトチームがプロジェクトの要件をそのまま受け入れて、プロダクトチームがさばくほうが、引き継ぎの必要はなく、オーナーシップも生まれ、メンテナンスもやりやすいですし、プロダクトオーナーによってその施策を生かしていけます。
プロダクトチームそのものが存在しない場合は、作って終わりという状態になり、プロダクトにいい影響が与えるとは考えづらいです。
プロジェクトという考え方があまりにも一般的なので、いきなりプロジェクトをやめるということも難しいことでしょう。しかし、少なくともプロダクト組織を最低限定義することは重要です。
component team(職能組織)とfeature team（機能組織）
一般的なtoCプロダクトを開発するにあたり、component teamとfeature teamのどちらがいいのかについて考えます。
プロダクトバックログアイテムはどのcomponentにどれくらい工数がかかるのかなどは全く関係がないため、component teamが開発する場合、どこかのチームがボトルネックになったり、それによってオーナーシップが不明瞭になったりします。しかしfeature teamはクロスファンクショナルであり、どのように開発するかもチーム内で決めることができ、開発したものに対するオーナーシップも生まれるため、長生きするプロダクトに所属するチームとして相性が良くなります。
バイモーダル戦略: プロダクト組織かつfeature team
以上をふまえ、SoE(System of Engagement)のような一般的なtoCサービス、リーンスタートアップやアジャイル開発が適したプロダクトの場合、プロダクト組織でかつfeature teamのほうが相性が良いと考えられます。
そしてこれらを理解し、早めに組織構造を固めておくことが、組織問題を未然に防ぐためにはかなり重要です。
組織と文化とプロダクトの関係「文化は組織構造に従う」
上記で述べたように、プロダクトのタイプによって、それに適した組織構造が違います。
コンウェイの法則を利用した逆コンウェイ戦略、SoEやSoRのようなシステムのタイプに合わせたバイモーダル戦略は、組織構造を語る上でしばしば出てきます*1。
また、まだあまり一般的ではないですが、ラーマンの法則(Larman's Law)*2というのもあり、このひとつに"Culture follows Structure"、文化は組織構造に従うというものがあります。
これを考えるとSystemに限る話ではなく、適切な組織構造を作ることは組織の文化にもかなり影響が出るだろうということがわかります。
他にもラーマンの法則を紹介すると、
1. 組織構造は暗黙的に現行のマネージャーと専門家の役職や権限が変わらないように最適化されています。
2. 1の影響により、変化を起こす提案は、元の状態が再定義される、もしくは新しい用語が乱用されることになり、結果的に元々の状態と変わらない状態になります。
3. 1の影響により、変化を起こす提案は「理想主義だ」、「机上の空論だ」、「革命だ」、「宗教だ」、「我々の環境に合うようにカスタマイズすべきだ」といった批判や嘲笑の対象になります。 ーこれは、自分たちの弱点から目をそらすためであり、マネージャーや専門家が現状を維持するためのものです。
4. 1の影響により、変化を起こす提案を間違えた方向にさらに変化させた後、仕事にありつけなかったマネージャーや専門家がまだ残っていた場合、彼らは(2)や(3)を推し進めながら変化を遂行するためのコーチやトレーナーになってしまいます。*3*4
つまり、プロダクトやシステムのタイプに合わせて組織構造を考慮することは極めて重要であり、それを怠った場合、将来的に苦労するだろうというのが予測できます。
適切な組織構築が遅れてしまった場合
組織の規模が大きくなると、組織問題が増え、対処する必要が増えてくるということは、簡単に想像ができるかと思います。
組織問題についての根本的な対策をなされないまま規模が数十人、数百人と大きくなってくると、改善がどんどん難しくなってくることでしょう。
ありがちなパターンとしては、何か問題Xが起こったときに、Xを対処する役割を定義、そしてXマネージャーが誕生し、そのXマネージャーがXの問題を対処する。組織の問題に対しても当てはまります。組織AにYの問題があると発覚する。Yを対処するには組織Aにマネージャーが必要だ、組織Aにマネージャー設置、組織Aマネージャーに仕事Yが追加される。
古くからある大企業でいろんな肩書の人がいるのは、こういった事象も一つの要因になっていることでしょう。もちろん、古くからの大企業でその現場を長年見てきたわけではないので、確信を持っては言えません。また、これ自体が決して悪いことではないということも言っておきます（実際そういった企業も力強く生き残っているわけですし）。
ではそうなった後に、組織全体を大規模なアジャイル組織にしたいとなった場合、どうなるでしょうか。例えば、LeSS(Large-Scale Scrum)やLeSS Hugeを導入しようとなった場合、何が起こるでしょうか。
まず、スクラムにおけるプロダクトオーナーやスクラムマスターがいません。中には経験者や有識者がいるかもしれませんが、人を採用するときにスクラムプロダクトオーナーやスクラムマスターの経験は、歓迎条件としてはあっても、requirementとして定義されていないことでしょう。つまり大規模にスクラムをやろうと思っても、急にうまくやるのは難易度が高いです。今までスクラムに注力しなかった分、うまくスクラムを行うというところにエネルギーを注ぎづらいのです。その難易度故に、スクラムの失敗体験が増える結果となり、悪循環が始まってしまいます。
そして次に、従来のXマネージャーや組織Aマネージャーの扱いです。特にスクラムやLeSSにおいてはマネージャーのroleは定義されておらず、あくまでも任意の存在です。すると、Xマネージャーはクロスファンクショナルなチームの一員とならざるを得ないでしょうし、組織Aマネージャーはこれまでとは違った「別の」責任と権限を持った完全なるサポート役になります。この認識をしっかり定義して、組織全体で認識をすり合わせないといけないのでこちらも難易度が高いかと思います。
よって、先に紹介したラーマンの法則も踏まえ、組織が大きくなってから組織や文化を変えるのは難易度が高く、早めに手を打たなければならないなと感じています。
組織規模によって変わる方法論
組織の大きさや状態によって、組織構築のためのアプローチ方法や難易度は変わってきます。
極めて少人数の時代（〜数名）
私の場合、会社のプロダクトはtoCサービスでありSoEのタイプです。リーンスタートアップやアジャイルは少人数チームだった時代に自ずと文化として生まれていました。
ラーマンの法則で「文化は組織構造に従う」と紹介しましたが、実はスタートアップの場合、むしろ「組織構造は文化に従う」のであると言われています。私はまさにこれを経験しました。スタートアップの初期メンバーだけの頃なんて、特に組織やプロセスなんて意識しなくても組織問題には遭遇せず、プロダクトをどうするかに常にフォーカスがあたっていますし、全員が全力疾走できている状態です。ただ、詳細な業務プロセスはちゃんとしてないこともあるので、そこだけ整えるようにはしていました。
そのプロセスは、ほぼスクラムのパクリなのですが、こんな感じです。
- プロダクトバックログにあたる一元管理された「やること」リストがある
- それは毎日プロダクトオーナーによってアップデートされる
- それはリファインメントミーティング（必要になれば都度やる）によってリファインされる
- エンジニアはプロダクトバックログの上からどんどん拾って開発する
- 開発ができたらプロダクトオーナーが要件を満たしているかを確認する
- そして一定のラインまで来たらリリース
- 週1でレトロスペクティブ
- スプリントという概念はない
- 見積もりもほとんどしない
これだけでうまくいっていました。少人数で皆がオーナーシップとやる気に溢れ、皆がクロスファンクショナルで、そして一つのプロダクトを作っていたからだと思います。
スプリントを定義しなかったのは、スプリントを定義しないほうが柔軟で速かったからです。頑張ってスクラムをやる必要がなかったのです。*5
このようにスタートアップで少人数の場合は、組織論そのものが不要ではありました。
十数名〜数十名の時代
しかし、このやり方もだんだんとうまくいかなくなっていきます。
それは新しく人を採用したり、事業領域が広がってきた場合です。
このときにどんな事が起こったのか、経験からお話します。
シリーズAの資金調達が終わり、人数は一気に2倍以上になりました。8人→20人程度。
また、プロダクトに関連したプロジェクトも増えていき、ふと気づいたらcomponent teamが定義され、component teamのマネージャーも定義され、プロジェクト思考な仕事の進め方が定着していきました。個人的にはプロダクト思考のfeature teamを作りたかったのですが、当時の私はなぜそれがいいのかということについて、まだうまく説明ができず、それとは全く逆の方向に進んでいったのでちょっとまずいなと思っていました。component teamはあまりにも突然決定され、説得の余地があまりなかったのですが、それでも断片的にfeature teamにしようと提案してもなかなかうまく伝えることが難しかった記憶があります。当時の私には、プロダクト思考のfeature teamにおける成功体験はあっても、プロジェクト思考のcomponent teamにおける明確な失敗体験が乏しかったのです。また個人的にもこの体制でやってみたらどうなるのか？というのは非常に興味がありました。よってこの経験は私にとっても貴重なものになりました。
この頃はプロダクトの一部の機能追加もプロジェクトとして扱われるようになり、従来のプロダクトバックログは常時メンテナンスされなくなりました。
このとき、改めて上記の「常に管理されているプロダクトバックログ」の重要性を認識しました。
一方でプロジェクトが頻繁に立ち上がるようになりました。そのため、プロダクトバックログとは別に「次何をやるか」はプロジェクトのタスクとして管理されるようになりました。それぞれのcomponent teamから必要人数をアサインし、デザイン、開発、テストのスケジュールを引き、プロジェクトマネジメントをよしなに行うという感じです。プロジェクトが終わればそのフォロータスクなどはプロジェクトに関わってた人がやるし、そうでない人もやります。
改めて考えてみると、ウォーターフォール的なプロセスだったと思うわけですが、文化としては、依然アジャイルな感じだったので、アジャイルのスタンスではいるけど、ウォーターフォールでやっているという不思議な状態でありました。なので責任権限も偏ることはなく、teamにも比較的オーナーシップがあり、タスクマネジメントもなんとか自分たちでやるし、どのように実装するのかというのは完全にチームの裁量で決めていました。ただし、明確に定義されていない分どうしても組織構造やプロジェクト思考に引きづられ、アジャイル感は薄れていくことが実感できました。ですので問題なかったのかと言われるとそういうわけではありません。
とある一つの大きなプロジェクトが終了したあと、何人もの人が「あのプロジェクトは失敗だった。あの失敗から学ぼう」という意識を持ったことがありました。
何が起こったかというと、これがまたウォーターフォールの典型的なパターンでした。加えて複雑なシステムを作った、アサインされていたエンジニアが退職し、有識者がいなくなり、かつプロジェクトは完了してチームは解散されたので・・・（以下略）という状態です。
幸い、優秀なメンバーに恵まれているため、実際こんな状態でも力技でやっていけてる状態ですが、プロジェクトを振り返ると上記のような認識になってしまいます。
もちろん振り返りは行い、改善を試みようとするものの、改善しようがないものが出てきたりもします。代表的なものとしては、コミュニケーション不足だったのでコミュニケーションをもっととろう！とかですね。
組織の文化を変えようとするのは愚かなことで、常に失敗します。人々の行動（文化）というのはシステムの産物です。ですので、システムを変更すると、人々の行動は変化します。*6
とあるように、文化だけ変えるのは難しい、やはり根本的に組織構造を見直す必要があると改めて実感します。
「組織構造」を見直す必要があるので、もう少しスコープは広く、「プロダクト開発組織」について考え、説明し、組織を作り変えていく必要があります。
もしこの人数規模でも組織が適切な構造になっている場合、例えば最初の熟練したスクラムチームをスケールさせていって、LeSSを導入したり、プロダクト数に応じてスクラムチームを増やしていくというアプローチになっていきます。
数百名の事例
この規模までなると、先程述べたようにかなり難易度が上がりますが、不可能ではありません。
これは私が実践したわけではなく、私は単なるチームの一員だった時の話ですが、私はミクシィに在籍していたことの話になります。
ミクシィでは2012年に全社的に大規模な組織改編がされました。従来のcomponent team-マネージャー構造のプロジェクト思考組織から、feature teamでプロダクト思考な組織になったのです。当時のミクシィ社員だった現株式会社レクターの松岡さんや広木さん*7の施策でした。それと同時に全feature teamにスクラムが導入されました。
社内にはほとんどスクラムに関する知見はなかったので、現場は結構大変ではありましたが、大胆で勇気のある素晴らしい施策だったと思います。
これにより、従来の社内受託開発的な構造が一掃され、マネージャーというポジションはほとんどなくなりました。そして一気にプロダクト開発のスピード感が増し、オーナーシップが形成されていきました。特に上層部からスクラム導入におけるサポートはありませんでしたが、ほとんどの現場で自主的に学習し、より良いスクラムをやろうと模索していったのです。まさにこれは文化が組織構造に従った例だったと思います。
しかしここで注意することは、ほとんど知見がない状態での強引なスクラム導入は、スクラムの失敗体験に繋がる可能性あるということです。スクラムの失敗体験をすると、「スクラムはうまくいかない」というかなり危険度の高い認識が生まれます。私も当時はそのスクラムチームにおけるスクラムマスターの一人でしたが、スクラムガイドを読みながらがんばるものの、「これでいいんだっけ？」という事象が多々ありました。
スクラムはシンプルで理解は容易ですが、習得が困難なため、こういった迷いは生じるかと思います。幸い私は新しく入ってきた当時唯一のCSP(Certified Scrum Professional)保持者及びCSM(Certified Scrum Master)保持者にアジャイルコーチとしてついてもらい、たくさんのことを学びました。個人的には現場に経験豊富なアジャイルコーチを呼ぶことは、かなり効果があると思っています。
また、このような大きな組織で改変を行うには、単にリーダーシップだけではなく、権力が必要になります。例えば私は当時新卒2年目の極めて平凡な社員でしたが、仮に私が当時組織をごそっと変えようとしても、それはとても困難だったでしょう。一体何人の権力者に納得の行く説明をし、合意を取らなければならないか、想像すらできません。この点が数十名規模の組織との違いかなと思います。それでもやらないといけないと強いリーダーシップを持った人は地道にやり遂げるかもしれませんが。
終わりに
ここ２年ほど、組織問題を解決しようとするものの、なかなか適切な言葉や表現が思い浮かばず、苦悩してきた日々でしたが、そんな中で出会ったLarge-Scale Scrumという本が、私が言いたかったことをうまく言葉にしてくれていて本当に助かりました。”Culture follows Structure”という言葉は、感じていたとしても言葉に具現化することが出来ませんでした。できていたとしても単に私が言ったところでそんな名言っぽくならなかったでしょう。
本記事で紹介しているラーマンの法則のラーマンは、まさにこのLarge-Scale Scrumの著者の一人です。
Large-Scale Scrumは単にLeSSについて書いてあるわけではなく、開発組織そのものの考え方をしっかり説明しており、スクラム実践者だけではなく、組織を変えようとしてる人にもおすすめです。最近Odd-eの榎本さんが監修して日本語版が発売されました。
私が現在取り組んでいる組織改編については、現在進行系なので、また後日アップデートしようと思います。
*2:Larman's Laws of Organizational Behavior - Craig Larman
*3:Larman's Laws of Organizational Behavior - Craig Larman
*5:細かいことを言うともうちょっとあります。PMがエンジニアをタスクにアサインしないように、とか。
*6:ジョン・セドン from Large-Scale Scrum
*7:エンジニアリング組織論への招待 の著者です。
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さんよろしくお願いします！
