【イベントレポート】EOF 2019 (Engineering Organization Festival)に参加してきました
はじめに
表題の通りEOF2019に参加してきました。素晴らしいセッションの率が非常に高く、個人的には今まで参加したカンファレンスの中でも、トップレベルで満足度が高かったです。
EOF2019とは？eof-github.github.io
eof.connpass.com
EOFは「エンジニアリング組織をもっとオープンに」をビジョンに掲げるイベントです。
主にプロダクト開発や組織開発をテーマとしたカンファレンスです。セッションがメインではありますが、OSTによる参加型ディスカッションも行われていました。
素晴らしい発表はぜひシェアしたいとおもいつつ、自分の状況や意見も交えながら書いていきたいと思います。
筆者の背景
ここ最近組織開発という分野に熱狂的に取り組んでいるところです。これまでの自分の経験から、自分の力で組織論を組み立て、いざアウトプット、実行を行うときに、言葉選びや表現の仕方にかなり苦戦していました。
ある事象が起こったとき、それは自分の作りたい組織にマッチした、促したい方向性の事象なのか、もしくは逆方向の事象なのか、逆方向の事象が起こった場合に、そっちじゃないよ促さなかったら具体的にどういう組織になっていくのかというものは言葉にできたものの、ではそれはどんなセオリーが背景にあるのか、伝え方としてどういう方法があるのか、このあたりの武器が不足していたと感じることが多かったのです。
それでも何年もかけて、自分の中にはある程度完成されていた考え方を洗練させて、世の中のセオリーと組み合わせながら、ようやくアウトプットと実行をし始めているということろです。
そして最近になり、よくこのジャンルの本を読んだりこういったカンファレンスや勉強会に参加しています（これまでは技術メインでした）。なぜ今なのかという話ではありますが、ある程度自分で完成させてから、「答え合わせ」がしたいという気持ちと、自分が持っていない「言葉や表現」をお借りさせていただきたいなという目的が大きいです。あわよくば自分の知らなかったセオリーや取り組みなどしれたら棚からぼた餅ですね。
「答え合わせ」や「言葉や表現」が出来たときはかなり感動しますし、自信と表現力アップにつながります。
セッション
さてここからは個人的に刺さったセッションを紹介していきます。
正しいものを正しくともにつくる 市谷 聡啓さん(@papanda)
www.slideshare.net
プロダクトを開発するとシンプルにいわれるものを、具体的プロセスに分解して考え、「わからないものをわかる」ようにするために、選択肢に幅をもたせながらも、仮説検証によって絞っていく。それぞれのプロセスで一般的に分業され得るものを「ともにつくる」ことが、チームの多様性を活かすことが出来、プロダクトの視座を高めるために重要ですよという話です。そして多様性が高まったときに低くなってしまうかと思われる機動性をいかにして高めるのかも話されていました。
不確実性曲線と正しいものを正しくつくる各フェーズを同時に可視化したあの図は素晴らしいしぜひ真似させていただきたいなと思います。
そしてさらに一番刺さったポイントが「ともにつくる」ことでプロダクトの視座が高まるという表現ですね。「正しいものを探す」フェーズと「正しく作る」フェーズはたしかにプロダクト開発の現場には存在していて、例えば正しくつくるフェーズでスクラムを導入する場合、「正しいものを探す」ところの責任範囲はプロダクトオーナーになるので、開発チームとプロダクトオーナーチームがフェーズによって分断されてしまうことはあると思います。実際スクラムのルールには全く言及されていないのでそうなってしまうことも想定出来ます。スライド一枚引用させてもらいます。
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜より引用
そこで課題として出てくるのが、機動力です。多様性と機動力がトレードオフの関係にあるのは想像ができるかと思います。この発表では、その対策法が紹介されていました。
仮説検証のフェーズでは、単に話だけではなくリーンキャンバスなどを用いて、必要なものを必要な分、各々の脳内から整理してアウトプットする。そしてその共有。さらに「正しくつくる」フェーズにおけるプロダクトレビューによる内部探索（これはスプリントレビューとは違い、もう少しスコープの広いもの）、ユーザーテストにより外部探索を行う。
上記プロダクトレビューと関係してると私は解釈しましたが、「ジャーニー」という区切りも素晴らしいですね。ビジョンだけでは遠すぎる、スプリントレビューだけでは近すぎるという課題に対する考え方です。具体的には複数スプリントに該当する一定の区切りでプロダクトと組織の振り返りを行いましょうということです。この振り返りにより、組織のフォーメーションを切り替えるということも出来ます。例えばこのジャーニーではとにかく開発をどんどんやっていこうとか、このジャーニーでは品質をどんどん高めていこうとかです。
プロダクトに対する理解度に合わせてアーキテクチャを選択しましょうという適者生存型アーキテクチャという言葉にも感動しました。こういうのって言葉すらないので、共通言語として使えることができたらスムーズですね。
クライアントワーク企業でもできるエンジニアリング組織のつくり方 永江 耕治さん@Kooozii
お客様先に常駐するSES形態の業務がメインである会社では、エンジニアリング組織をつくることが難しいですが、そんな環境でもエンジニアからマネージャー、人事部長、副社長と長年様々なポジションで活躍され圧倒的な経験を積んだ永江さんセッションです。
残念ながら資料は公開されていないみたいなので、資料を置いながら書くことは出来ませんが、これも感動ポイントがいくつもありましたので断片的ではありますが書かせていただきます。
※2019/11/27に資料が公開されました！
speakerdeck.com
組織レベルとマネジメントの話
序盤では主に組織構造と不確実性の話の流れをされていました。内容としては広木さんのエンジニアリング組織論への招待の1章の内容とかなり関係しています。会社という組織を、すごく抽象度と不確実性の高いものからプロダクトというすごく具体的なものを生み出す処理装置だと考えたとき、マネジメントや組織が不確実性にうまく対処してアウトプットをすることができるのかを永江さんは３つの組織レベルに分けて説明していました。（写真もメモもとってなかったので自分の記憶を頼りに書きますが、間違っていたらすみません、修正します。）
| 組織タイプ | 自己組織化もマネジメントもされていない組織 | マイクロマネジメント組織 | 自己組織化された組織 |
|---|---|---|---|
| 不確実性の削減 | 出来ない | 少しだけしか出来ない | 多くできる |
| 業務指示 | ほぼなし | 具体的で細かい | 抽象的で自由度がある |
自己組織化されたチームはかなりの不確実性に対処できるというのは言わずもがなですが、
ピラミッド型のマイクロマネジメント組織でを考えたとき、ボトルネックは頻繁に発生するものですが、ボトルネックが発生したとき（例えば中間管理職が急にいなくなったなど）、急に仕事の不確実性が上がります。そうなったときスムーズに対処する難易度は上がります。
さらに自己組織化されていないにもかかわらずマイクロマネジメントをしない組織はピラミッド型のマイクロマネジメント組織のボトルネック発生時が常に起こっているという状態になります。
マイクロマネジメントは古いからやらないというだけでは、「すごく抽象度と不確実性の高いものからプロダクトというすごく具体的なものを生み出す処理装置」としてはうまく回らないということですね。マイクロマネジメントのほうがまだ組織レベルが高いということです。マイクロマネジメントしないのが良いマネジメントだと思うのは、組織レベルが低い場合もあるので注意が必要です。
イノベーションとフォロアーの話
私も前々から気に入ってるこの動画の話をされていました。
First Follower Leadership Lessons from Dancing Guy
全社的にとある取り組みを行った際、最初の数人〜十数人はさらっとついてきてくれるのに対し、そこからのフォロアーが伸び悩む。そこで最初のフォロアーに対しこの動画を見せて、リーダーシップを促すことでその壁を突破し、フォロアーの数は臨界点を突破後指数関数的に伸びていく。ということを実際に行った事例を話されていました。
オープンコミュニケーションの取り組み
客先に常駐する社員もいる中、社内でコミュニケーションを取る難易度が非常に高い中、素晴らしい取り組みをされているなと思いました。
なにか集中して議論すべきことがあった場合、飲み会をセッティング（これは簡単に思いつきそう）、その飲み会にアジェンダを設定し、議事録も取るようにする。全社総会を定期的に開催し（これは簡単に思いつきそう）、出席者全員がリアルタイムでWebから質問や指摘を投稿でき、リアルタイムに役員とのディスカッションができる、など。
新米VPoEがまんまと落とし穴にはまったお話 坂井 健治さん( @saka0ken )
素直に失敗を認め、反省しながら改善していくような人柄の良さがにじみ出てくる良い話でした。NetflixのCulture deckでもはっきりと明記されているように、本当に価値のある情報において重要なこととは、「正直かつ率直に間違いを認める」です。心理的安全性の確保をし、自分に都合の悪い失敗したことや失敗しそうなこと、わからないことなどいかなるポジションやロールにおいても正直かつ率直な情報というものが非常に価値があります。というかこれこそが、他者を自律的に動かす材料の一つです。このように透明性の高い状態が保たれると、誰かが困っているときに誰か知見のある人が助けるという行動をとれるわけです。そんなとても正直かつ率直な坂井さんのセッションではところどころに周りの人との関わりや協力体制が感じ取れました。
残念ながらこちらのセッションも内部的にWeb上に資料を公開する許可がまだとれいていないということなので、ざっくりと思い出しながら書きます。
※２０１９年１１月１８日資料が公開されましたので掲載させていただきます。
speakerdeck.com
一つのチームのマネージャーだった坂井さんが、急にVPoEの立場になって組織開発というVPoEの仕事をするもなかなか大変でしたという背景です。
内部的なことをやりすぎないように
途中からこのセッションを聞いたのでセッションでは聞けなかったですが、後に本人に質問したところ、こういう話でした。
１つのチームのマネージャーだった→VPoEになった、という時点で、昔から見てる自分の組織のことにフォーカスが当たりがちです。しかし組織問題や組織開発というのはスコープがさらに広く、全社的にもなる話なので、それぞれの組織間の関係性の問題や、組織構造の問題などもっとフォーカスを当てるべき場所があった。自分が知っている範囲を対処するのではスコープが狭すぎるということでした。
最先端じゃなきゃダメだと思ってしまう問題
今となっては組織開発に関する様々な知見が、本やカンファレンスなどを通じて入手できるようになりました。その中でモダンな組織構造とはこれだ！モダンな開発プラクティスはこれだ！という情報が溢れています。自分の組織と照らし合わせて、しっかりと理論を組み立てずにこの流行に乗っかってしまっても、うまくいかない、という話でした。
チャットコミュニケーションの問題と心理的安全性の課題 中山 ところてんさん (@tokoroten)
www.slideshare.net
SlackにおけるコミュニケーションでDirect messageの割合が非常に高くて困っているという（友人）話から、なぜそうなってしまうのかを、様々な理論から解説し、さらにDirect messageの割合が多くなるとどんな問題が起こるのか、解決方法はあるのか、というセッションです。
SlackにおけるDirect messageの割合データ
非常に困っているという方の実際のデータを見てみると、Direct Message 50%, Public channel 30%, Private channel 20%という結果が出て、これはやばいとなったとのことです。一方で非常に成功している他社のデータはというと、SmartHRさんはPublic channel 96%, Private channel 3%, Direct message 1%。scoutyさんはPublic channel 100%(?)。NextIntさん（中山ところてんさんの会社）もほぼ100% Public channelという結果でした。このデータを見るだけでも、いかにチームでコミュニケーションを取れているか（つまり情報が共有されている）、個人でのみコミュケーションをとってしまっているか（つまり情報共有がされていない）が、会社によって天地の差ほどあるということですね。
Direct messageじゃなくてPublic channelでもしくはチームのチャンネルで発言してくれというのは、私も昔からうるさく言っている人間ですが、それはもちろんDirect messageによるコミュニケーションによって起こる問題を避けたいからです。これに関する説明も次のようにバッチリされていました。
Direct messageによって起こる問題
知識の偏在化、属人化が起こり、トラックナンバーが増えない。
指揮系統の逸脱、業務負荷の偏りが起こる。
社内政治の温床。社内政治が必要と理解しつつも、その環境を作ってしまうのはダメですね、ということです。
確かにこれにつきますね。。。これによって起こる組織問題は計り知れないほど多いですね。
なぜDirect messageで送っちゃうのか
Public channelで発言することを促すためには、Public channelの心理的安全性の確保が必要であるということ。つまり、Public channelでの発言率が高いということは心理的安全性が保たれているということが出来ます。
そしてこの心理的安全性という言葉はかなり重要で、Googleがアリストテレスプロジェクトというものを通じて、チームのパフォーマンスには何が重要なのかを調査しました。そこで出てきたのが、一番重要であり基礎となるのが心理的安全性です。
つまり心理的安全性の欠如からDirect messageの利用につながるのだということを話されていました。
あとはコミュニケーションに対する認識の違い、多知能理論から考えるPublic channelで発言しやすい人のパラメータなどのお話もありました。
ソフトウェアエンジニアはコミュ障だなんて一般的に言われがちではありますが、ソフトウェアエンジニアは論理・数学的知能が高く、言語的知能も高い傾向にあります。じゃあなんでコミュ障なんていわれなきゃいけないのか、それは多知能理論における他の知能、対人的知能が関係しているのではないか、という説を話されていました（マーケ・営業・マネージャは対人的知能が高い傾向）。
そんな理論から、Public channel で発言する・しないは単に習慣の問題ではなく才能の問題もあるのではないか、という話です。
DMM改革の1年、その実際と反省 松本 勇気さん(@y_matsuwitter)
最後にDMMのCTO松本勇気さんのセッション。これはもう感動というか、自分の興味分野にドンピシャ過ぎて、先に答えを見せないでほしいと思いながらつい見てしまうそんな完成度の高い組織戦略のお話でした。
私自身の組織戦略を剣という武器に例えると、全体像や形はできあがったものの、まだ研磨すべきところがあって本などを通じて言葉を身に着け、研磨してってもうすぐできそうだ！というタイミングで、すでにピッカピカに磨かれた切れ味抜群の同じ剣を見せつけられたかのような気分でした。
このうまくまとまったスライドには無数の理論や経験が盛り込まれているので、全体的な紹介は「ぜひスライドを見てください」とさせていただきたいのですが（スライドでも足りないので話を聞くのがおすすめ）、個人的に松本さんが得意なんじゃないかなぁと思う部分をピックアップして紹介したいと思います。
透明性に対する取り組み
透明性を上げるためにどうしたらいいか、具体的なプラクティスは山のように溢れてしかもそれは自分の組織にマッチするかわかりません。しかし松本さんは透明性が低下する原因を４つに分けて考えておられます。
- 伝達時の減衰: 組織感の信頼度や情報伝達文化の不足により、情報が減衰し、末端まで伝わらない。
- 情報伝達アクション不足: そもそも情報を伝達しようとするタイミングが不足し、情報が欠けている。
- 情報公開の不足: 情報の多くに対してアクセス出来ない状態になっている（e.g. slackのprivate channel, direct message）
- 情報整理の課題: 触れられる情報が整理されておらず、複雑。一見して理解がしづらい、情報量が多い
それに対しての対策法。それぞれをくるっと逆サイドに持っていくと
- ネットワークの構築: 暗黙的に出来上がってるコミュニケーションネットワークのハブを見つけ出し、連携
- インナーとアウターの活用: インナー（自分の言葉で即座に）、アウター（第三者の客観的情報を付与）
- 発言の習慣化: タイミングをルール化して発信者と受信者の行動をデザイン
- フォーマット化: 読みやすい整理された情報フォーマットを用意し全体へ公開
またこれらの情報の信頼性を確保することもまた重要。
自己組織化チームにおいて情報の透明性は最も重要と言って過言ではないですが、それに対する対策法をバッチリ言語化されて実行してるのは本当に素晴らしいと思います。また松本さんと話したときに、グノシーにいたときにやっておけばよかったとおもったことを今DMMでやらせてもらっているとおっしゃってたのですが、すでにグノシーにいたときからこれらの対策の基礎となる行動をされていた感じですね。
【連載：エラーに学べ】DMM松本勇気の過去から紐解く「組織のポテンシャル」の引き出し方 - エンジニアtype | 転職type
そうですね。あとは意識的に行っていたこととして、悩みや不満を拾い上げたら、その後定期的に「解決に向けた取り組みがどんな進捗状況にあるのか」を伝えるようにしました。仮に事情があって要望に応えられない場合でも、なぜ今これができないのかをきちんと説明することで、メンバーとの信頼関係を少しずつ再構築していったのです。
これを読んだときに1 on 1というかそれも重要だけども、情報の透明性の確保するスタンスが非常に良いと過去にぼそっとツイートした記憶があります。
おわりに
以上私が見ただけでも非常に素晴らしいセッションばかりでしたし、ほかも見たかったなぁと思うくらい満足度が高かったです。
私の本来の目的通り、こういった方々から知恵や言葉ををお借りして、今後の自分に活かせていただきたいと思います。
運営の方々、素晴らしいイベントをどうもありがとうございました。
ホフステードの6次元モデルを用いたアジャイル組織文化の構築
グローバル組織においてのマネジメントの難易度は非常に高く、頭を悩ませている人も多いかと思われます。
また優れたリーダーはIQ(知能、専門性、知識)とEQ(対人関係能力、心の知能指数)が高い人だと考えられてきましたが、グローバル化が進むにつれて、これらの人がグローバル組織において失敗することが増えています。
この流れで新しくCQ(多様な文化的背景に効果的に対応できる能力、文化の知能指数、Cultural Intelligence)という概念が重要と考えられるようになってきました。
CQの高さは、語学力の高さと海外経験の多さとは無関係です（もちろんあったほうがいいですが）。*1
さらにグローバル組織にとどまらず、近年では新しい文化の企業が多々出てきており、同じ国でも、同じ業界でも会社や組織によって様々な文化があり、このCQの高さはどんどん求められることになるかと思います。
今回はそのCQの一部の強力なツールであるホフステードの6次元モデルについて勉強しましたので、紹介しながら活用方法について考えたいと思います。
文化とは？
まず文化ってなんなのかってところから考えないといけません。
文化を説明するときには玉ねぎ型モデルがよく用いられます。
イメージしやすいようにソフトウェアプロダクト開発における具体例を考えてみましょう。Aさんは「しっかり計画を立てて開発を進めるのが当然であり、適当な計画で進められるのは信じられない。あいつは無能だ！」と思っているとします。Bさんは「綿密な計画よりもスピード感を持って進めていくのが重要だ。細かいことにばっかりこだわるやつは無能だ！」と思っているとします。AさんとBさんはお互いに無能だと思っているでしょうが、これは文化のギャップがあるだけであり、それぞれ無能なわけではありません。
一方でそれよりも外側にある儀式や英雄、シンボルなどはある程度見える部分です。この部分は比較的変更しやすい部分です。
経営戦略としての異文化適応力では、中核の価値観（国民文化とも言っている）の部分は12歳くらいまでに無意識下で定着し、その後は変えるのが難しく、それより外側の部分は周りの環境に合わせて変えることができると言われています。
アジャイルの文化
この玉ねぎの図、なんだか見覚えがあるなぁと思ったらこれ、アジャイルの価値原則も同じように書けることがわかるかと思います。実際に玉ねぎ型モデルを用いてアジャイルの価値原則を説明している人を見たことがあります。
価値
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
原則
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
文化の玉ねぎ型モデルでもあったように、アジャイルマニフェストで定義された「価値」や「原則」がなければ、「プラクティス・フレームワーク」の部分が定着しません。ここが不安定な状態でスクラムを導入してもうまくいかないということは容易に想像できると思います。
とはいえ、経営戦略としての異文化適応力でも述べられてるように、価値観を変えろといっても難しいです。
ここがBe Agileにおける最大のチャレンジとなることでしょう。
難しいとはいえ、現状のそれぞれの価値観とアジャイルのそれとが180度違うということはほぼありません。いずれかの次元では非常にマッチしていて、いずれかの次元ではマッチしていない、というパターンが多いので、それぞれの次元でどうギャップを埋めていくのかが重要になります。
ホフステードの6次元モデル
シンプルにアメリカと日本は文化が違うよね、と言われると、うんそうだねとほぼすべての人が答えると思いますが、どのように何がどれくらい違うのか、また他の国はどうなのかというのはあまり会話には出てきません。しかしグローバルな組織文化を取り扱う場合、このあたりを意識することが重要になってきます。
国別の文化の差異を6次元のパラメータに分けてスコア化したものが、ホフステードの6次元モデルとそれの元になったデータです。
タイトルにも書いたこのホフステードの6次元モデルを紹介していきます。
ホフステード博士はオランダの社会心理学者で2008年に世界で最も影響力のあるビジネス思想家トップ20に入っています。*4
彼は1967年から1970年にかけて、IBMの組織開発のため、IBM従業員意識調査をIBM社員11万6000人、72カ国、20言語で実施すると、意識や行動の違いは、職種や性別、年齢などよりも、国別の文化の違いによって生まれるということが偶然にも発見できました。*5このときに6次元モデルの原型ができ、その後50年かけて追加調査、検証を行い、データが正しいものであると確認されました。
そのホフステードの6次元モデルがこちら。
1. 権力格差 小さい⇔大きい
階層を重視するのか、平等を重視するのか。
権力格差が小さい文化の特徴としては、参加型マネジメントの傾向があり、理想の上司は「コーチ」、ヒエラルキーは便宜上必要になる場合があると考え、分権やエンパワーメント、自立を促され、年長者への経緯は希薄である傾向が高いです。
一方で権力格差が大きい文化においては、階層型マネジメントの傾向にあり、理想の上司は「親」、ヒエラルキーは重要であると考えられ、中央集権、指示命令、上司や年長者の言うことを聞き、敬意を示す傾向にあります。
例えば、権力格差が小さい文化において、上司が権威を示してヒエラルキーを重視しようとすると、部下からは威張っていて融通がきかない無能な上司だと思われる、ということが文化の違いによって生まれます。
2. 集団主義⇔個人主義
自分が属する内集団に依存し、その利益を尊重するのか、それとも独立し個人の利益を優先するのか。
集団主義思考の特徴は一人称が常に"We"、所属集団の意見、メンバーを尊重する、暗黙のコミュニケーション、調和を重んじ、直接的な対立を避ける、集団へのフィードバック、面子を失うことが恥であり所属集団の責任となる、職務より人間関係を優先する、などです。一方で個人主義思考の特徴は一人称は自身である"I"、個人の意見、個人の経済的・心理的ニーズの尊重、明白なコミュニケーションで自分の意見を述べ、対立は必要なものと考える、個人へのフィードバック、自尊心の喪失が恥となり自分自身の責任になる、人間関係よりも職務を優先するなどです。
例えば、集団主義の文化において、個人主義的な価値観でコミュニケーションを取ると、侮辱されている、ストレスがたまる、無作法、無礼である、上司に忠実ではないと思われるということが、文化の違いによって生まれます。
3. 女性性⇔男性性
競争社会の中で家族や友人、大事な人と一緒にいる時間を大切にするのか、それとも達成する、成功する、地位を得ることによって動機づけられているのか。
念の為書いておきますが、これは決して女性や男性の性別としての特徴を言っているのではありません。FeminityなのかMasculoinityなのかという話です。
女性性が高い文化においては弱者を支援、生活の質・連携・協力を重視・目的や目標は方向性を示すもの、良い上司の理想は関係構築力があり意見をまとめることに長けていること、インセンティブは金銭的なものだけではなく、生活の質を高める労働環境、仕事より家庭、男性の女性を果たす役割について感情に同じものを期待する。
一方で男性性が高い文化だと、業績重視の社会、成功者を賞賛、成功・地位・他者より秀でることを重視、明確な目標・ターゲット、良い上司の理想は決定力があり、アサーティブであること、インセンティブは昇給・昇格・賞賛・チャレンジのある仕事、家庭より仕事、男性と女声が果たす役割に対して感情的に異なるものを期待するなどです。
例えば女性性が高い文化において、男性性を発揮してしまうと、攻撃的、自信過剰、自慢している、見せびらかしている、地位や服装・化粧にこだわりすぎなどと思われるということが、文化の違いによって生まれます。
4. 不確実性の回避 低い⇔高い
不確実なこと、知らないことを驚異と捉えるのか、それとも気にしないのか。
不確実性の回避を重視しない文化の特徴は、規則はできるだけ少ないほうがいい、曖昧な状況や不慣れな状況を楽しむ、リラックスしている、実務家・常識への信頼、成功するためにリスクをとる、「Out of box thinking」新しい手法を奨励する、トップマネジメントは戦略にフォーカス、学生は学習のプロセスを求め、教師が全ての解答を知らなくても気にしない、などです。一方で不確実性の回避を重視する文化の特徴は、規則・構造を感情的に必要とする、曖昧な状況、前例のない状況を嫌う、ストレスが多い、専門家への信頼、失敗しないためにリスクを避ける、形式・構造を重視して仕事を進める、トップマネジメントは日々のオペレーションを気にする、学生は正しい答えを求め、教師が全ての解答を示すことを期待する、などです。
例えば不確実性の回避を重視しない文化において、不確実性の回避を重視するような行動をとると、融通がきかない、細かすぎる、マイクロマネジメント、信用されていないなどとおもわれるということが文化の違いによって生まれます。
逆のパターンだと、原則を知らない、モラルがない、不真面目、「無能なのか？それとも単純に怠惰なのか？」と感じるこということが起こります。
5. 短期思考⇔長期思考
将来・未来に対してどう考えるのか。
短期思考の特徴は、短期の財務的結果を重視、評価指標は利益やROI、消費、欲求はできるだけ早く満たしたい、分析的な思考、唯一絶対の心理、原則・原理を重視、善悪を判断する普遍的指針がある、自国に対するプライド。
長期思考の特徴は、長期的な利益や恩恵を短期のそれよりも重視する、評価指標は市場シェアや顧客満足度、倹約、欲求はすぐに満たされなくてもいい、統合的な思考、いくつもの真理、実用性を重視し例外を認める、善悪の判断は状況次第、他の国から学ぶ、などです。
例えば短期思考の文化において、長期思考で行動すると、物事の白黒が明確ではない、ぶれる、分析力がない、決断が遅いなどと思われるということが文化の違いによって生まれます。
実際のデータは？
意識調査のデータから生まれたのがこのホフステードの6次元モデルなので、当然データがあり、すでに世界中の101カ国の6次元スコアが出ています。この記事は日本語で書いているので日本人の読者が多いでしょうから、皆さんのイメージと比較するために日本の文化の傾向だけ紹介すると、日本の文化では男性性が高く、不確実性の回避が高く、長期思考で残りは真ん中らへんという感じです。
しかし残りのデータを紹介するのは控えようと思います。
なぜなら*9の著者もかなり慎重になっていると言っていましたが、このデータを安易に知ることによって、あの国の文化はこうだから、あの国出身の人はこういう行動をとるだろう、という間違った固定観念を生むリスクがあるからです。
このデータはあくまでもマクロなものであり、平均化したものですし、同じ国でも組織、コミュニティによってその文化が天地の差ほどあることは周知の事実だと思います。
実際私は日本人ですが、自分自身が日本の文化のスコアとは全然違う文化だなと感じます。しかも、生きている中で大人にになってからでも変わったなと感じます。
このデータ自体は非常に価値がありますし、このデータがなければホフステードの6次元モデルは生まれなかったので、このデータは必要ではありました。しかし私が重要だと考えるのはこのデータから生まれたホフステードの6次元モデルのほうだと考えます。
もしデータを知りたい場合は経営戦略としての異文化適応力の後ろの方に載ってますので読んでみてください。
組織文化の構築
ではホフステードの6次元モデルをどのように活用するのか考えます。
自分が目指している理想の組織文化はどんなものなのか、それを6次元のモデルに落とし込み可視化しておく、現状の文化はどうなのかそれを6次元のモデルに落とし込み可視化しておく。それによってじゃあ変化させるためのアプローチはどうするのかを考えることが出来ます。
仮にアジャイルな組織を作りたいとしてみましょう。
答え合わせをしたわけではありませんが、私自身が考えるアジャイルの文化はこのようなになりました。
一方で自分の組織が仮こうだったとします（これは私の組織とは無関係であり、適当につくったものです）。
すると文化にギャップがあることが可視化できるわけです。
この場合、女性性／男性性はほぼマッチしています。なのでこの部分においては、何を価値・原則とするのかを明文化してやるだけで十分である可能性が高いです。
他の部分においてはかなりギャップが大きいので厳しい戦いを強いられることが見えてきます。
ギャップを埋めたいからと言って、いきなりプラクティスやフレームワークを適用しても、価値観の部分が合致していないのでうまくいかないリスクが高いのです。
では価値・原則はどうやって？というところですが、確かにアジャイルマニフェストには価値や原則が定義されていますが、これを読むだけでは不十分だと思うのです。これらの捉え方や理解の仕方は色んなパターンがあり得ると思います。もっと他の、その状態になったときにどういう美しい景色が見えるのか、経験を通じて伝えないと行けないと思います。
ここでこのギャップを埋めるためのプラクティスで私が個人的に注目しているのがLINE社における取り組みです。
speakerdeck.com
スライドの30ページからその説明がありますが、LINE社においては、みんなに「アジャイルは一つのお気に入りだ」と思われるような取り組みをEmail Marketing Funnel Storategy*10を参考にして、独自のFunnelを作成しています。
Awareness -> Positive Impression -> Desire to experiment -> Practice -> Spreading
この流れは、現状の文化から、アジャイルの文化へ変える、もしくは価値を理解してもらって気に入ってもらうために必要な流れです。
具体的に何をするのかはおそらくいろんな方法があると思いますし、私もどんどん知って、試していきたいなと思っているところです。
終わりに
ホフステードの6次元モデルを勉強するにあたり、宮森千嘉子さん・宮林隆吉さんの
『経営戦略としての異文化適応力 ホフステード6次元モデルの実践的活用法』を読み、勉強会に参加させていただきました。貴重な知見をありがとうございました。
【イベントレポート】『THE TEAM』×『エンジニアリング組織論への招待』コラボイベント〜“最適”なエンジニアリングチームを目指して〜
今回は組織論についてのトークイベントに参加してきたので参加レポートを書きます。
せっかくこのブログもあるんだし、ブログ枠で参加登録したので、ブログ書かなきゃいけないですね。
イベントページはこちら。
connpass.com
それぞれこれらの本の著者がパネラーでした。
麻野耕司さん: THE TEAM
THE TEAM: 5つの法則 [書籍] - Google 検索
広木大地さん: エンジニアリング組織論への招待
エンジニアリング組織論への招待: 不確実性に向き合う思考と組織のリファクタリング - Google 検索
トークの内容
まずはトーク内容がどんなだったかを紹介し、その後に自分の考えや感想を書いていきたいと思います。
なのでこの章で書いてることは私が思っていることではありません。なるべく忠実にパネラーの伝えたいことを書いてみます。
基本的に話のアウトラインは、麻野さんのTHE TEAMの内容に沿ったものであり、適宜広木さんの考えも盛り込んでいったり、ディスカッションしたりするという感じでした。
THE TEAMでは下記５つの内容が語られており、今回はこの中のAim, Boarding, Decisionについての内容の紹介がありました。
Aim(目標設定)の法則〜目指す旗を立てろ! 〜 ★
Boarding(人員選定)の法則〜 戦える仲間を選べ〜★
Communication(意思疎通)の法則〜最高の空間をつくれ〜
Decision(意思決定)の法則〜進むべき道を示せ〜 ★
Engagement(共感創造)の法則 〜力を出しきれ〜
Boarding(人員選定)の法則〜 戦える仲間を選べ〜
どこか特定の組織で、とある手法がうまくいっていて、その手法をそっくりそのまま自分の組織に取り入れても、うまくいかないことが多い。
それぞれの組織にはそれぞれの最適なやり方がある。
サッカー型(スマホアプリの開発チーム): 環境変化の度合いが大きく、人材の連携度合いも大きい。
駅伝型(メーカーの工場の生産チーム): 環境変化の度合いが小さく、人材の連携度合いも小さい。
野球型(飲食業の店舗スタッフチーム): 環境変化の度合いが小さく、人材の連携度合いも大きい。
環境を相手チームに比喩している。サッカーの相手チームがこう動いてきたら、こちらのチームはそれに合わせて変わらないといけない。スマホアプリ開発チームで理解すると、例えば世の中の95％の人類がAndroidスマホを使うようになったら、iOSエンジニアからAndroidエンジニアに入れ替えるとか、スキルセットそのものを入れ替えるとか。
環境が変化しにくいということは、今現在のやり方や体制で対応できるということも変わりにくい。ビジネスをより成功させるためには人員の増加＝プラスの力の積み重ねであり、そのため誰を入れるのかというところを慎重に考えるのが良い。
人材の連携度合いが小さい場合は、メンバー選びは似たタイプを揃える＝均質性の高いチーム
人材の連携度合いが大きいということは、個人ではなくチームで初めて物事を達成できるという状態であり、個々人はそれぞれ違うスキルセットを持った人員で構成することができる。そしてその連携がうまく取れればチームのパフォーマンスは驚くほど高くなる。
人材の連携度合いが小さい場合というのは、人が増えれば増えるほどパフォーマンスがその分プラスされるという感じ。まさに生命保険の営業というイメージがピッタリである。
そして、例えば生命保険の営業マンをやっていた人の価値観や文化というものは、おそらく人材が増やせばそのままパフォーマンスの増加につながる、個人の力こそが成果につながる、などの考えはスムーズに理解できるはずだが、サッカーチームのような組織で働いてきた人たちはその考え方が理解できないかもしれない。
サッカーチームの例としてスマホアプリ開発チームと書いているが、スマホアプリ開発チームでも実は組織の型は様々である。Feature teamなのか、Component teamなのかによってもマトリクス状でこんなに違う位置にいる。
社会人は一般常識を心得ているものだという前提でお互いに接するが、文化がその常識を生むので、その常識がひとによって違ったものになり得る。
このあたりを議論するためには、これらの組織論を学び理解しなければならない。
Aim(目標設定)の法則〜目指す旗を立てろ! 〜
続いて目標設定の話。
成果目標: 意義目標と成果目標の間。
行動目標: 具体的なアクションはわかりやすいが、ブレイクスルーが起きにくい。
昔の日本は行動評価をしていた。等級ごとに取るべき行動が定義されていて、これを評価されていた。
90年代から、世の中の変化に伴い、あまり行動目標を使わなくなった。成果目標が評価されるようになった。具体的なプロセスやアクションはそれぞれの人に任せるようになった。学校の通知表が試験の点数で決まるのも例の一つ。
現代では、OKRのような意義目標を評価するようになってきた。目標があってたら成果を変えても問題ない。
しかしこのような正しいOKRの設定は非常に難しい。トレーニングをする必要がある。精度の低いOKRを設定してしまうと失敗体験につながる。
個々人の自立度合いによって抽象度合いを変えるのはありかも。あとは環境の変化が少ないのであれば、目標を具体的なレベルにするのもあり。
Decision(意思決定)の法則〜進むべき道を示せ〜
経営者に圧倒的人気なフレームワーク。
多数決: 中間。
合議: チームの納得感は低くなるが、遅い。
日本の世の中では合議がよしとされているが、今スピードが物を言うので最後はリーダーが決めたらそれに向かうことも必要。
組織の規模が大きくなると、権限の委譲を行わないと回らなくなる。独裁的な意思決定をやっていた場合、意思決定者がキャパオーバーになるし、合議を行っていても合議そのものに時間がかかり、組織が前に進めなくなる。
THE TEAMは3~10人を想定して書いた。
日本では合議で決めることが多い。しかしこれがしばしば組織を腐らせる。
権限は責任が常に付きまとう。責任を怖がっている人も少なくない。責任を見えづらくさせるために合議が使われることもあるのではないか。
あまり健全ではない会社の特徴としては、なにか起案してYESみたいな返答をされてもずっと放置される。そんな組織が腐っていく。
質疑応答
Q: 意思決定や行動ができない上司がいて、げんばからあまり感謝されていない。どうすればいいか？
A: マネージャー研修とかよくあるけど、意思決定に関するトレーニングとか全然ない。もっとトレーニングすべきではある。意思決定を早くしても、遅くしても、答えはほぼ同じになることが多い。早く決めることは価値が高い。
意思決定および行動を促すためには、サイコロを降ってサイコロに決めてもらうのも意外とありなのではないか？
Q: 権限委譲の概念が殆どない組織で、環境も変化が激しい状態で、意思決定早くしないといけない、としっかり考えている経営者はどれくらいいるのか？
A: 割合とかわからないけど、会社にとってはそれらのことについて考えることはかなり重要。
delegationできない→自分で決めたい→任せられない。そんな会社伸びない。
昆虫のように小さく無数にある会社、カブトムシは殻以上に大きくならない。
大きい会社は哺乳類。体がでかい。大きくなる。数は少ない。背骨で支えている。判断を社長からdelegationする。
こういった変化に対応できる人ってかなり少ないと思う。
感想と私なりの考え
まず組織タイプの話について。
連携度合いが少なく、環境変化が多い柔道団体戦(生命保険の営業チーム)タイプはかなりシンプルにイメージできますね。人材の増加＝売上の向上につながるのが想像できます。 環境変化の度合いが小さく、人材の連携度合いも小さい駅伝型(メーカーの工場の生産チーム)もシンプルにイメージできます。安易にマネジメント1.0のアプローチをとってしまいそうです。もちろん経験したことがないので、あまり勝手な判断はできないのですが、チームでの連携が少ないということは仕事の分割が容易であり、その仕事の結果も客観的に可視化しやすく、比較的評価もしやすいイメージです。
私自身、Webサービス企業で自社プロダクトを作ってきた経験がほとんどのため、ここでいうサッカー型のタイプとばかり向き合ってきました。なのでもう少し掘り下げてみます。
連携の度合いについては、この業界ではさすがにUX/UIデザインもサーバーもインフラもアプリもフロントエンドもデータ解析もプランニングも機械学習も全部できる！みたいなスーパーマンはほとんどいないので、連携度合いは常に高い、と考えても良いと思います。
連携度合いの大小、環境の変化の大小以外にも、プロダクトとプロジェクトの違い、Component teamとFeature teamの違い、プロダクトタイプの違いなどの次元が、それぞれ単に独立した次元としてではなく複雑に絡まっています。
というかそもそも、『プロダクトやサービスの成功』のためにそれに適した組織構築しようと考える場合、まずはそのプロダクトやサービスのことを最初に考える必要があります。
信頼性、コスト削減、効率化などが求められるプロダクトSoRなのか、柔軟性、俊敏性、変化への適応が求められるプロダクトSoEなのか、プロダクトじゃなくてやりきったら終わりのプロジェクトなのか、またそれらの融合体なのか、そこを明確にしてはじめて組織構造が作れるかなと思います。バイモーダル戦略というやつですね。おまけに文化形成にも重要なラーマンの法則も関わってきます。単純に、じゃあうちはアプリ開発するから多様性が高く、流動性が高いサッカー型チームを作ろう、では少し危ない感じがします。
具体例を考えると、うちの会社ではインドで最も使われるSNSアプリを作ろう、となった場合、SoEなので、アジャイルなプロダクト組織を作るのが適していると言えます。アジャイルなプロダクト組織を作る場合、Feature teamを構成し、クロスファンクショナルでstableな自己組織化チームを目指して文化を形成するため、人材そのものはあまり流動的ではないほうが良いのです。スキル＝人ではないので、クロスファンクショナルチームでは自己成長が行われスキルそのものが新たに付与されるというのが理想です。
そのため、迎え入れるべきメンバーは新たなスキル習得に貪欲で、その知見を共有できる人、が最適だと考えています。
続いて目標設定のについて。
まさにかつての高度経済成長期の仕事及びマネジメントスタイルとともに変わってきたなぁという印象です。
日本ではなぜいまだにマネジメント1.0のようなスタイルでかつウォーターフォールプロセス思考が定着しているのか。その起源は戦後の産業に因るところが大きいと考えられます。
工場のラインなどのシンプルな作業が大量にあった。シンプルな作業をこなせばこなすほど、その会社は儲かった。シンプル作業は分割しやすく、マネジメントも単純作業を割り振るというシンプルなものであった。そのマネジメントスタイルはからツリー構造の階層型組織を構成できた。
現代はかなりクリエイティブな仕事が増えてきた。クリエイティブな仕事が多いWeb業界などではマネジメントスタイルもかなり変わってきた。しかしまだ変化が始まったばかり。
というような感じでしょうか。クリエイティブな仕事が増え、マネジメントスタイルがかわるということは設定する目標も変わらざるを得ないですね。
OKRを流行にのって導入するも、なかなかうまくいかないという話も聞きます。こういうトレーニングが必要なものは安易に導入すると逆効果にもなりかねません。スクラムの安易な導入と失敗体験と近いものを感じます。
私も全然経験がないので、OKRの設定を勉強したいです。
意思決定について。
一番印象に残った言葉はこれですね。
あまり健全ではない会社の特徴としては、なにか起案してYESみたいな返答をされてもずっと放置される。そんな組織が腐っていく。
自戒の念を込めてですが、実際これはいろんなところで見かけますね。。。麻野さんのように様々な組織を見て、そんな組織が腐っていくという現象を目の当たりにしているのなら、これはかなり重要な事項として心に留めておきたいと思いました。
あと合議をするのか独裁をするのかは、組織によってまるっと決めてしまうとかなり不自由になるかなと思いました。チームが多様性のあるチームなのかどうかによっても変わるかと思います。多様性のあるチームでそれぞれ一様の責任を追っている場合、内容によっては独裁がいいでしょうし、合議が良い場合ももちろんあります。
全体的な感想
自社プロダクトをつくるWeb企業でばかり働いていたので、それよりも広い視野の方の組織論を聞けて満足しました。
組織論っておもしろいですね。それぞれが苦労して言語化しているので、それぞれに説得力がありますし、自分が考えていることと全く同じポイントがあったらテンションが上がります。
今読んでる本
多分次のブログ記事にこの本について書くと思うので予告だけしておきます。
今読んでるこの本、まだ途中ですが面白いです。
https://www.amazon.co.jp/dp/4820726986www.amazon.co.jp
グローバルな組織をつくるにあたり、障壁となる文化の違いにどう対応していくのかという本ですが、ファクトが研究成果などから引用されており、信憑性の高い情報が詰め込まれているのも良いです。組織について考える際に文化への対処は欠かせません。グローバル企業にかかわらず、日本企業でも程度の差はあれど同様だと思います。
以下一部引用。
リーダーはフォロワーがいて初めて成立します。組織のパフォーマンスに対して『リーダー』が及ぼす影響力は1～2割に対して、『フォロワー』が及ぼす影響は８～９割にものぼります。
国境を超えたプロジェクトの70％は失敗し、90％の経営者が異文化間で効果的に結果を出せる人材を見出すのはトップマネジメントのチャレンジと考えています。
80％の企業経営者は、経営の成功には『文化』が鍵になると考え、60％が文化は戦略やビジネスモデルより重要としているものの、文化が効果的に活用されていると考える経営者は35％
文化の中枢にある価値観はだいたい12歳くらいまでに形成されます
近々、著者との勉強会に参加させていただけることになったので、それも踏まえ、記事に書いてみます。
スクラム実践者増加とその評価方法の疑問
Scrum Masters Night!というコミュニティの運営をしております．本日は第２３回目の開催で，私は第２回目から運営に入っており，もう５年ほど運営させてもらってることになります．
このコミュニティでは，主にスクラム実践者のための課題解決型イベントを定期的に行っており，今のスクラム実践者はどういう悩みを持っており，今他の人達はどのように解決しているのか，という生の声が聞け，ディスカッションができるので，毎度新たな学びがあります．たまにLeSSの考案者のBas Voddeさんや日本人唯一の認定スクラムトレーナー，熟練アジャイルコーチなど超ビッグなゲストも来たりします．最近福岡や大阪でもイベントやっておりますので，是非一度参加してみてください．Facebookグループで告知してます．
さて，本記事では宣伝をしたかったわけではなく，このコミュニティを運営するにあたっての最近の気づきがあります．
それはここ半年～１年で明らかにこのScrum Masters Night!の参加人数が増えています．徐々に増えたというよりは急に一年以上前の平均から１.５倍ほどの参加人数になりました．
これはどういうことなのかというと，まずスクラム実践者が増えているということは間違いないです．リテンションが上がったんじゃないのか？という仮説もありますが（というかちゃんとデータ溜めておけばよかったんですけどね．．．），参加者と話していても，確かにリピーターはいますけど，新規は毎回毎回多いです．
次に，参加者と雑談してるときに，スクラムをやることになったきっかけは？という会話になったのですが，多数派はどうやら会社がスクラムをやろうと決めたから，上がスクラムをやろうと決めたから，という理由です．
これはこれで全然良いと思いますし，むしろ，そういう組織体制にしてもらえるというのは非常にありがたいことだと思います．実際スクラムをスタートするには，良いコンディションです．逆に，逆境を乗り越え，地道に関係者全員を説得して回るリーダーシップ力は，相当な体力を消耗するものですし，スクラム自体の成功確率にも影響してきます．
要は，ここ半年から一年で会社の経営レベルの人たちが，「アジャイル」や「スクラム」という言葉に対してポジティブに動いてるということが予測できます．LinkedInなどでScrum Masterの採用メッセージもかなり増えてきました．もちろん，一部の企業ではもっともっと前から導入してるとか，すでに導入して失敗してもとに戻っちゃったとかそういう例もありますが．
では上からスクラムをやるように促されたとなった場合，疑問点として出てくるのが，そのスクラムという方法自体の評価方法です．どのように評価したらいいのかという点に関してはScrum Masters Night!でも何度か見かけるテーマですが，これはスクラムを導入しようとした人（今回の場合は経営層の人たちなど）が，なぜ導入するのかをしっかり現場（スクラムをやるように言われた人たち）に説明する必要があると感じています．もしくはスクラムを導入しようとした人がしっかり何を評価するかにおいて責任を持つ．
特に途中でスクラムを導入するという場合，そもそも何か問題や課題があって，それを解決する方法としてスクラムをやるわけですし．問題を解決する方法は本当はなんだって良いんですよね．
私自身も前回の記事で詳しく書きましたが，会社メンバー全員でやりたいようにやってたらだんだんとやりづらくなってきて，よくよく考えたらやはり組織ちゃんとしてアジャイルにしたら解決できそうじゃないかとなり，スクラムやりやすいのでは？となった感じでスクラムは最後に出てきました．
なので，今どういう課題があって，いろいろ調べてみたら結局のところスクラムをやると解決するかもしれない，という背景がうまく伝わっていると自ずと評価方法も見えてくるのではないかな感じています．
また，そうすることによって先入観による「アジャイルアレルギー」の人に対しても納得感をあたえられるかもしれません．
あと余談ですが，スクラムマスターの数は徐々に増えてきていますが，プロダクトオーナーという肩書の人はなかなか見かけないなーと話してました．確かに，仕事内容としてはPO相当の仕事をしてるけど，大きな組織では企画職とか，総合職とか，プランナーとか，プロダクトマネージャーとか言われたりしてる感じなんですね．
組織の拡大に伴うアジャイルなプロダクト組織構築
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さんよろしくお願いします！
