KAKKA is not 閣下

Drivemodeというシリコンバレーのスタートアップでエンジニアとか組織開発をしています(2019/09ホンダにExitしました)。 CSP-SM(認定スクラムプロフェッショナル)、メタルドラマー。 ex:リクルート、ミクシィ、トヨタ Twitter→@KAKKA_Blog

プログラミングまでインクリメンタルなソフトウェア開発

はじめに

TDDやインクリメンタルな開発について学び実践する機会があったので、今一度振り返り、記事にしておこうと思う。

ソフトウェアとして目指すべき所

ソフトウェアを開発するにあたり、このソフトウェアの目指すべき方向性とは一体なんなのかふと考え直す必要があるシーンに遭遇する。よくあるパターンでは、不確実な仕様を満たすことに注力したり、技術的品質に異常にこだわったりするあまり、"Things Right"なものにならない、またはなるのが非常に遅くなるパターンだ。もちろん言わずもがなそれは大事なことではあるが、そのソフトウェアが、必要とされるときに使われなかったら、それはただのToyとなってしまう。
世の中に広く普及しているソフトウェアで必ず共通しているものが、「価値がある」ということだ。しかし価値があるだけでは、数年間に渡りメンテナンスを強いられるようなソフトウェアになることだってある。これはビジネス上非常に苦しいことである。

f:id:KAKKA5:20200928095436p:plain

というわけでシンプルに考えると、ソフトウェアは「価値があり、品質が高い」というところを目指すべきである。かんたんに言うけれど、これはなかなか難しいことだ。しかし目指すべき所としては間違いない。ここに向かって走っていくべきだ。

ここでソフトウェアと言っているが、基本的にはソフトウェアに限らず、すべてのプロダクトは価値があり、品質が高いほうが良いということは間違いないだろう。しかし今回はレジリエント、スケーラブル、可観測性といった特徴を持つソフトウェアというプロダクトに対してフォーカスする。考え方そのものはソフトウェアに限らず有効に使えるものだ。

計画型プロセスと経験的プロセスによる不確実への戦い

なぜ使われないソフトウェアを作ってしまうのか。なぜ使われない機能に多大なコストをかけてしまうのか。その根本には要件定義書の不確実度にある。要件定義の精度を高めるという努力も一定効果がある一方で、要件が不確実なことがほとんどだからである。
f:id:KAKKA5:20200928101700p:plain
図で示すようなシンプルな領域については今回お呼びでない。「これは絶対に人々が求めるものだ!シンプルだ!」と思い込んでいるパターンも含め、それを示すデータやサイエンスがない限りたいていcomplexであり、我々の生きる未来そのものがcomplexであり、このchaosやcomplex領域において要件定義というものは単なる仮説にすぎない。
仮説ならばそれを検証しなければならない。いつやるのか?なるべく早いほうがいい。なるべく早く仮説を検証し、ゴールへの一歩を着実に積み重ねる必要がある。これができるのが経験的プロセスだ。
f:id:KAKKA5:20200928102424p:plain
仮説=真実という前提で歩みをすすめるのが計画型プロセスと言われる。
よってcomplexやchaosといった不確実な領域と戦うためには、様々な制約条件の中でも少なくとも経験的プロセスの考え方が必要となってくる。
これはすでに世の中に広く知れ渡っている考え方であり、かなり多くの組織で意識されていることだろうと思う。

Test Driven Development(TDD)でコードレベルの経験的プロセス

ソフトウェア・プロダクトの実態は≒ソースコードと考えることができる。ソフトウェア・プロダクトに対して仮説検証を繰り返す場合、ソースコードでも予めすべてを設計することは不可能である。よってソースコードレベルでのフロー効率を意識する必要がある。
f:id:KAKKA5:20200928112004p:plain
フロー効率を意識するとは、図のように一番早くプロダクト自体がShippableになる状態を目指すことである。これが冒頭で述べたインクリメンタルな開発である。高品質なソフトウェア・プロダクトを目指すのであれば、自動テストはなくてはならない存在であり、そしてフロー効率を考えるあれば、テストコードはタイムリーに書く必要がある。
テストコードをもっとタイムリーにしていくと、先に書いてしまったほうが良いのではないかとも考えられる。流動的な要件に対してそれを具現化したテストコードを書き(テストコード=仕様)、それをパスする実装部分をプログラミングする、さらに継続的にリファクタリングもする必要がある。これはフレームワーク化されており、みなさんご存知Test Driven Development(以下TDD)だ。TDDではTest→Code→Refactoringというサイクルを10分〜15分という非常に短い時間で繰り返しながらソフトウェアを開発していく。

Refactoringで経験的プロセスの考え方を活かす

Simpleな領域においての計画型プロセスの考え方では、プログラムの設計は早期に行われる。要件が固まっていればいるほど設計の抽象度も下がり、設計に従うことが正しく機能する。一方で不確実領域に対して経験的プロセスの考え方を導入する場合、早期に設計を行うことはどうしても抽象度が高くなる。よってプログラミングという具体レベルになると矛盾や無駄などが発生することは想像できる。この場合、設計はほどほどにしてジャストインタイムな設計・リファクタリングが有効に働く。これはシンプルに、開発途中のほうがコードへの理解、テクノロジーの知識が、開発前より高まっているからである。注意するべき点は、これができるのはRefactoringやTDDができる人だけであり、それができない場合、ただ設計をてきとうにやっただけ、ということになって終わってしまう。リファクタリングやTDDは単なる知識ではなく、習得にはそれなりに時間がかかる技術であるため、ソフトウェアエンジニアにはこれらのトレーニングの機会や実務で活かせる機会があると良いと思われる。

TDDはチームでの開発にフレンドリー

TDDは、極めれば極めるほど非常に透明性の高い開発プロセスである。Test, Code, Refactorというはっきりとした工程に加え、それぞれが非常に短い時間で行うため、誰かの頭の中でなにかしらの作業が行われているという時間が少ない。明確なプログラミングプロセスがソースコードにアウトプットされている状態である。これにより、ペアプログラミング、モブプログラミングなどの共同開発プラクティスにフレンドリーである。

終わりに

ソフトウェアは価値があり、品質が高くあるべきだ。不確実な領域との戦いを強いられる現代のビジネス環境において、フロー効率を考えた、早くShippableなプロダクトを開発できるインクリメンタルな開発によって、ソースコードレベルでも経験的プロセスの考えを生かしたプログラミングフレームワークは有効である。特にTDDなどは非常に相性が良いと思われる。継続的な設計、日常的なリファクタリングを繰り返すことにより、抽象的で無駄が多い設計から脱却し、それが高品質なソフトウェアへとつながる。
こういった内容は、Odd-e社におけるスクラムデベロッパーテクニカルトレーニングなどで学ぶことができる。スクラムの知識は必須ではあるが、ここから学べることはスクラムの範疇を超えており、不確実な要件、技術領域において価値のある品質の高いソフトウェアを開発するという観点において非常に役に立つ示唆がある。実務にもすぐに活かせるTDDの実践トレーニングも含まれている。

エンジニアリングリソースを有効活用することについて考える

はじめに

「技術を財務で表現する」という素晴らしい記事を見かけました。
CTOの頭の中:技術を財務で表現する|Shin Takeuchi|note

GP(総生産力)。GPってのは僕が勝手に名付けた名前で「Gross Productivity」の略にしています。要するにエンジニアチームの総生産力を表しています。

僕の視点からすると、現代のIT企業の内製エンジニアチームって凄く特殊で、バランスシートにやってくる「システム」資産を作る力のことと言っても過言でない。もう少し言葉遊びすると「作る」というより「作り続ける」力。流量のようなイメージでしょうか。

Gross Productivity(総生産力)という言葉、いいなぁと思いました。昨今のエンジニアリング組織の生産性向上はまさにここの数字をあげることかと思います。
そして「作り続ける」という言葉選びも重要です。一般的に人的なエンジニアリングリソースはコストが高いため、エンジニアやデザイナーなどがより専門性を発揮できるように、無駄を省いて専門分野にフォーカスする時間を確保するというアプローチは、リソースを有効活用するという観点から言うと自然ではあります。しかし、限られたプロジェクトスコープ内で徹底的に無駄を省くよりは、この「作り続ける」ということを意識して、時間軸踏まえて考えるほうが良いと私は考えます。「きれいな水を一定量、常に流し続ける」というイメージです。
今回はこういった専門職の人たちのモチベーションややりたいことを一旦分けて、「きれいな水を一定量、常に流し続ける」ということを考えてみます。

きれいな水を一定量、常に流し続ける

私の言う「きれいな水」というのは、価値のあるプロダクトインクリメントです。ユーザーがプロダクトに求めている価値そのものです。ときにはそれは技術的負債の返済にあたることもありますが、間接的にこれも価値のあるプロダクトインクリメントとすることができるでしょう。
そして「量」は開発スケールであり、アジャイル開発においてよく用いられるチームのVelocityを意味します。
私は今までこれを「ゴールに向かって正しい方向に一定スピードで走る車」と表現していました。今回は「きれいな水を一定量、常に流し続ける」という表現にフォーカスします。

プロダクトにおけるスタートからゴールまでの水量の合計

プロダクトの開発をスタートしてから、そのプロダクトの一生を終えるまで、常に最大限にエンジニアリングリソースを有効に使えた場合はこの図の用になると思います。
f:id:KAKKA5:20200218124816p:plain

この青色部分の面積が大きければ大きいほど、プロダクトに価値を提供できたということになります。この場合面積がMAXなので最高の例となります。
厳密には、チームを増やして流量のキャパシティ自体を増やしていくこともあるので、縦軸を%ではなく、流量[ml]とかで表現したほうが直感的かもしれません。しかしここでは財務という観点から、限られたリソースを有効に活用するということを考えるため、%で考えます。

ところが実際このようにうまくは行きません。プロダクトに所属する、掛け持ちをしていないチームを想定した場合、例えばこんなふうになったりはしないでしょうか。
f:id:KAKKA5:20200218125315p:plain

青色部分の面積は先の例と比較してかなり小さくなっています。これでは財務的に有効に活用しているとは言い難い状態です。当然、あらゆる組織にはそれなりの制約条件があり、なるべくしてなるという状況は多々あると思います。しかしこれは仕方ないからと見過ごせるほどの差ではありません。文字通り、何倍もの差が出てしまうことになります。解決できるところは解決したほうが良いということは間違いないでしょう。

短期プロジェクトでしか、流量を確保できないパターン

施策を短期プロジェクトでしっかり何をやるかを考え、無駄を省いてスピーディにプロダクトインクリメントをデリバリーすることは悪いことではありません。プロジェクトもうまくいき、そのプロジェクトは無事成功だったとしましょう。
f:id:KAKKA5:20200218141831p:plain
しかしプロジェクトが走っているとき以外はきれいな水の流量は比較的少なくなってしまいます。繰り返しますが、プロダクトに所属する、掛け持ちをしていないチームを想定した場合の話です。もちろん、チームのレベルやプロセス、カルチャーなどに依存するといってしまえばそれまでですが、それでもプロダクトに対する視座という観点でいうと、プロジェクトを構成していた人員のスキルセットと比較すると劣ってしまうことが多々あります。
また、プロジェクトではしばしば期限を設定し、プロジェクトマネージャーはそれを守るためにいかに工夫するかというところにも労力が割かれます。
要件に優先順位をつけ、期限に間に合わないものはやらないという決断は立派な働きだと思います。ときには、「今回は技術的負債には目を瞑ろう」と判断して期限を短くすることもあるかもしれません。その努力の結果、プロジェクトは成功し、期限内に必要なものをリリースすることができました。これはプロジェクト成功と言っても良いでしょう。それではそのプロジェクトのあと、次何をやるのかをしっかりと考えなくなったとすると、Productivityはどのようになるかというと、下がります。
f:id:KAKKA5:20200218142811p:plain
せっかく短縮した期限、プロジェクトは成功したのにも関わらず、中長期的な視点でプロダクトに対する価値提供は最大化できているかどうかは疑問です。
繰り返しますが、これはチームのレベルやプロセス、カルチャーなどに依存するものなのでこのセオリーが全組織に適応されるものではありません。
また、制約条件により、プロジェクトの期限を守ることがかなり重要なケースもあると思います。
回避可能な場合において、短期プロジェクトでプロダクトを作っているときに、こうならないように対策が必要であるということです。
※職能組織編成でプロジェクトのみでプロダクトを動かすし掛け持ちも当たり前のような状態はこのような想定にはなりませんが、それはそれで別の問題があります。*1*2

スクラム&プロダクトチームで流量が保てないパターン

スクラム&プロダクトチームを考えた場合、プロダクトバックログにおいてWhat to doは常にメンテナンスされ、毎週のようにプロダクトインクリメントをデリバリーされる状態が、比較的担保されやすいと考えられます。しかしながらプロセスやフレームワーク銀の弾丸ではないというのはまさにそのとおりで、図のようにうまく行かないパターンも当然あります。
f:id:KAKKA5:20200218145732p:plain
この場合のパターンは見積もりが甘く予定していたVelocityを発揮できなかったとか、技術的難易度が予想以上に高かったとかそういうものから起因する場合を除いて考えることにします。というかその場合、全員が全力で戦ったっけどだめだったということでありエンジニアリングリソースは有効に活用していたということですもんね。

クロスファンクショナルチームとプロダクトインクリメント

スクラムチームを構成する場合、クロスファンクショナルチームを構成するのが理想です。これはプロダクトインクリメントを優先度の高いものから順番にデリバリーできるようにするためというのは理由の一つですが、当然この背景には、プロダクトインクリメントをデリバリーするために必要な職能は単一のものであることはほとんどない、という事実があります。
例をあげながら説明すると、このような要件があったとします。
f:id:KAKKA5:20200218153933p:plain
可視化はされていませんが、それぞれの要件について必要な職能は異なってきます。
一方で現在のチームはこのような構成であるとします。実際他にも職能が必要そうですが、簡単のため、これをクロスファンクショナルチームとしてみます。
f:id:KAKKA5:20200218151110p:plain

もうおわかりかと思いますが、人と職能を紐付けてしまうことによって、それぞれの要件で必要な人、必要でない人が出てきます。
例えば「ユーザーがアプリ内でタイマー機能を使うことができる」、「ユーザーが仕事帰りに電車でおすすめのレシピをpush通知で受け取ることができる」要件に対してはアプリの開発だけで良いかもしれません。一方で、「ユーザーが電車でテキストでレシピを検索することができる」は全員フル稼働が必要かもしれません。それぞれの人の稼働状況に偏りが出てきます。
したがって、リソースを100%有効活用しているかどうか、という観点で見ると、素直にYesとは言えない状態です。

個人レベルでのクロスファンクショナル

この例では極端な話、人=職能と考えてしまう場合に起こってしまいます。この4人のスキルセットをそれぞれ図で表してみるとこのようになります。
f:id:KAKKA5:20200218152244p:plain
f:id:KAKKA5:20200218152257p:plain
f:id:KAKKA5:20200218152320p:plain
f:id:KAKKA5:20200218152333p:plain

それぞれのスキルセットは専門分野ではレベル100と非常に高く、立派な専門性を持っていると言えます。しかしこの状態だと上記のように不安定な流量となってしまいます。Back endの負担が多いからBack endエンジニアをもっと増やそう、という解決法でも一時的に解決できるかもしれませんが、世の中はわからない上に変化しますし、要件もそれに従い変化します。よって不安定な状態は続くと考えられます。
ということで個人レベルでのクロスファンクショナルという事を考えてみます。

f:id:KAKKA5:20200218153144p:plain
f:id:KAKKA5:20200218153214p:plain
f:id:KAKKA5:20200218153227p:plain
f:id:KAKKA5:20200218153251p:plain

そんなもんレベル100マルチスタックがいいなんてわかっとるわ!って声は聞こえてきそうですが、注目していただきたいのは、一旦短期的にそれぞれレベル60程度を目指しているというところです。
レベル100とかレベル60って実際どんなもんなのか?という議論は置いておいて、ここで私が言いたいのは、業界のエキスパートにならずとも、スキルレベルはレベル60あれば、高品質で満たせる要件もまぁまぁあるということです。さらに、0->60への成長のほうが60->100への成長よりも難易度が低いと考えられます。これは世の中にある情報やスキル習得者の数、解説のしやすさから考えてもその様になるのかなと思います。
仮にこの仮設が正しくなかったとしても、重要なのは、人=単一職能と考えないことによって生まれてくる、Productの視座向上だったり、タスクテイカー感からの脱却、そして責任感といったカルチャー的な側面で好循環が生まれて来ます。*3

以上のことから、スクラム&プロダクトチームにおいても、個人レベルでのクロスファンクショナルにすることによって、少なくともプロダクトの価値提供能力つまり今回で言うきれいな水の流量が増え、長期的にプロダクトの価値が高まっていくと考えられます。

やっぱり大事なのはWhat to doが常に考慮されている状態を作る

常に価値のあるものを、継続的に提供するためには、常に価値のあるWhat to doを、文字通り積んでおく必要があります。単純に開発スピードを上げたいからと言ってエンジニアを採用エンジニアを採用というのは、一旦立ち止まって少し深く考えたほうが良いのではないかという場合もあるでしょう。プロダクト開発に必要なのはプロダクトマネジメントだったりプランニング、デザイン、品質管理、カスタマーサポートなど多岐にわたります。その中で例えばWhat to doがボトルネックになっているのであれば、職能としてのエンジニアを強化しても逆効果になり得ます。
What to do がボトルネックになり、管理されていない状態となっている場合、ボトムアップ的なアプローチで委託するとか、明確に権限移譲を行うとかでケアする必要があります。
そのためにはそもそもチームの存在意義と明確に定義し、ミッションや目標を定義し、それに向かって自立的に走っていける環境を作り、障害となるものは取り除いたり、オフィシャルなプロセスを設定したりするなど組織としての基礎の部分をきっちり固めてやる必要があるかと思います。
こういったことを考え出すと、より一層Gross Productivityの最適化を考える場合、エンジニアリングというのはエンジニアのアウトプットではなく、プロダクト開発組織全体のアウトプットということになり、スコープは決してエンジニアにとどまらないということになってきます。

そもそも人は変化して成長できる

ある程度確かに特定分野のエキスパートも必要ですし、この人はこれが得意といったイメージが生まれるのは良いことだと思います。
しかしながら、人=この技術、つまり人の職能フォルダ分けから、人への職能ラベル付けへ考え方を変えることで、組織はより柔軟な動きができ、全体のGross Productivityを向上させることができます。上記の例ではソフトウェアエンジニアに関する複数のスキルセットについて述べましたが、そもそもこれもエンジニアというフォルダに入っているので、このエンジニアと言う枠組みからの脱却ももちろん考えるべきことかと思います。もしかするとデザインや品質管理、人事、プロダクトプランニング、など幅を広げられる可能性もあります。
しかもその人達が、やりたいという思いがあるならこんなに幸せなことはありません。長期的な視点を持ち、この時期はプロダクトに対するインクリメントがどうしてもできないといった状況の場合、新しい分野への学習の時間をガッツリ取るのも、長期的には将来Productivityを向上させることに有効に働きます。

おわりに

今回は、財務で表現するという話から、エンジニアリングリソースを数字的な概念として捉えて有効活用する考えを書いてみました。
振り返ってみると言ってることは非常にシンプルで、要約すると「継続して何をやるかを考えよう」と「人を単一職能の人とかんがえるのをやめよう」みたいになってしまいますね。確かにこういう文言はどこかしらで見かけるものでありますが、それだけ言ってもなかなか伝わらないと思います。私自身も、人に伝えるという経験をすればするほど、今までの抽象的な理解では不十分だったと反省する日々です。
そしてこのセオリーですが、エンジニアやデザイナーなどの専門的な人たちは決して機械ではなく、人なので、これだけでは不十分でしょう。
その前に組織ビジョンやカルチャー、そしてそれが影響を受ける組織構造、さらに基礎となる事業や会社のミッション、ビジョン、バリューなどしっかりとした土台が必要になります。

*1:マルチタスクで仕事は遅くなる

*2:メンテナンスやサポートのコストや、プロダクトビジョンを達成するための時間がかかってしまうなど

*3:このあたりについては別の記事にまとめます。

【イベントレポート】EOF 2019 (Engineering Organization Festival)に参加してきました

はじめに

表題の通りEOF2019に参加してきました。素晴らしいセッションの率が非常に高く、個人的には今まで参加したカンファレンスの中でも、トップレベルで満足度が高かったです。
EOF2019とは?eof-github.github.io
eof.connpass.com

EOFは「エンジニアリング組織をもっとオープンに」をビジョンに掲げるイベントです。

主にプロダクト開発や組織開発をテーマとしたカンファレンスです。セッションがメインではありますが、OSTによる参加型ディスカッションも行われていました。
素晴らしい発表はぜひシェアしたいとおもいつつ、自分の状況や意見も交えながら書いていきたいと思います。

筆者の背景

ここ最近組織開発という分野に熱狂的に取り組んでいるところです。これまでの自分の経験から、自分の力で組織論を組み立て、いざアウトプット、実行を行うときに、言葉選びや表現の仕方にかなり苦戦していました。
ある事象が起こったとき、それは自分の作りたい組織にマッチした、促したい方向性の事象なのか、もしくは逆方向の事象なのか、逆方向の事象が起こった場合に、そっちじゃないよ促さなかったら具体的にどういう組織になっていくのかというものは言葉にできたものの、ではそれはどんなセオリーが背景にあるのか、伝え方としてどういう方法があるのか、このあたりの武器が不足していたと感じることが多かったのです。
それでも何年もかけて、自分の中にはある程度完成されていた考え方を洗練させて、世の中のセオリーと組み合わせながら、ようやくアウトプットと実行をし始めているということろです。

そして最近になり、よくこのジャンルの本を読んだりこういったカンファレンスや勉強会に参加しています(これまでは技術メインでした)。なぜ今なのかという話ではありますが、ある程度自分で完成させてから、「答え合わせ」がしたいという気持ちと、自分が持っていない「言葉や表現」をお借りさせていただきたいなという目的が大きいです。あわよくば自分の知らなかったセオリーや取り組みなどしれたら棚からぼた餅ですね。
「答え合わせ」や「言葉や表現」が出来たときはかなり感動しますし、自信と表現力アップにつながります。

セッション

さてここからは個人的に刺さったセッションを紹介していきます。

正しいものを正しくともにつくる 市谷 聡啓さん(@papanda)

www.slideshare.net
プロダクトを開発するとシンプルにいわれるものを、具体的プロセスに分解して考え、「わからないものをわかる」ようにするために、選択肢に幅をもたせながらも、仮説検証によって絞っていく。それぞれのプロセスで一般的に分業され得るものを「ともにつくる」ことが、チームの多様性を活かすことが出来、プロダクトの視座を高めるために重要ですよという話です。そして多様性が高まったときに低くなってしまうかと思われる機動性をいかにして高めるのかも話されていました。

不確実性曲線と正しいものを正しくつくる各フェーズを同時に可視化したあの図は素晴らしいしぜひ真似させていただきたいなと思います。
そしてさらに一番刺さったポイントが「ともにつくる」ことでプロダクトの視座が高まるという表現ですね。「正しいものを探す」フェーズと「正しく作る」フェーズはたしかにプロダクト開発の現場には存在していて、例えば正しくつくるフェーズでスクラムを導入する場合、「正しいものを探す」ところの責任範囲はプロダクトオーナーになるので、開発チームとプロダクトオーナーチームがフェーズによって分断されてしまうことはあると思います。実際スクラムのルールには全く言及されていないのでそうなってしまうことも想定出来ます。スライド一枚引用させてもらいます。

f:id:KAKKA5:20191101114309p:plain
選択の最大化に反する分業の例
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜より引用
しかし私の経験からしても良いチームは、確実に「正しいものを探す」フェーズで、開発チームも一緒に「探して」いました。これにより、多様性からプロダクトに対する視座が高まり、プロダクトがより洗練されることに加え、「作る」フェーズにおいても、はるかに強いオーナーシップを持つことができるので、それが技術にもデザインにも生かされてくるというわけです。
そこで課題として出てくるのが、機動力です。多様性と機動力がトレードオフの関係にあるのは想像ができるかと思います。この発表では、その対策法が紹介されていました。
仮説検証のフェーズでは、単に話だけではなくリーンキャンバスなどを用いて、必要なものを必要な分、各々の脳内から整理してアウトプットする。そしてその共有。さらに「正しくつくる」フェーズにおけるプロダクトレビューによる内部探索(これはスプリントレビューとは違い、もう少しスコープの広いもの)、ユーザーテストにより外部探索を行う。
上記プロダクトレビューと関係してると私は解釈しましたが、「ジャーニー」という区切りも素晴らしいですね。ビジョンだけでは遠すぎる、スプリントレビューだけでは近すぎるという課題に対する考え方です。具体的には複数スプリントに該当する一定の区切りでプロダクトと組織の振り返りを行いましょうということです。この振り返りにより、組織のフォーメーションを切り替えるということも出来ます。例えばこのジャーニーではとにかく開発をどんどんやっていこうとか、このジャーニーでは品質をどんどん高めていこうとかです。
プロダクトに対する理解度に合わせてアーキテクチャを選択しましょうという適者生存型アーキテクチャという言葉にも感動しました。こういうのって言葉すらないので、共通言語として使えることができたらスムーズですね。

クライアントワーク企業でもできるエンジニアリング組織のつくり方 永江 耕治さん@Kooozii

お客様先に常駐するSES形態の業務がメインである会社では、エンジニアリング組織をつくることが難しいですが、そんな環境でもエンジニアからマネージャー、人事部長、副社長と長年様々なポジションで活躍され圧倒的な経験を積んだ永江さんセッションです。
残念ながら資料は公開されていないみたいなので、資料を置いながら書くことは出来ませんが、これも感動ポイントがいくつもありましたので断片的ではありますが書かせていただきます。
※2019/11/27に資料が公開されました!
speakerdeck.com

組織レベルとマネジメントの話

序盤では主に組織構造と不確実性の話の流れをされていました。内容としては広木さんのエンジニアリング組織論への招待の1章の内容とかなり関係しています。会社という組織を、すごく抽象度と不確実性の高いものからプロダクトというすごく具体的なものを生み出す処理装置だと考えたとき、マネジメントや組織が不確実性にうまく対処してアウトプットをすることができるのかを永江さんは3つの組織レベルに分けて説明していました。(写真もメモもとってなかったので自分の記憶を頼りに書きますが、間違っていたらすみません、修正します。)

組織タイプ 自己組織化もマネジメントもされていない組織 マイクロマネジメント組織 自己組織化された組織
不確実性の削減 出来ない 少しだけしか出来ない 多くできる
業務指示 ほぼなし 具体的で細かい 抽象的で自由度がある

自己組織化されたチームはかなりの不確実性に対処できるというのは言わずもがなですが、
ピラミッド型のマイクロマネジメント組織でを考えたとき、ボトルネックは頻繁に発生するものですが、ボトルネックが発生したとき(例えば中間管理職が急にいなくなったなど)、急に仕事の不確実性が上がります。そうなったときスムーズに対処する難易度は上がります。
さらに自己組織化されていないにもかかわらずマイクロマネジメントをしない組織はピラミッド型のマイクロマネジメント組織のボトルネック発生時が常に起こっているという状態になります。

マイクロマネジメントは古いからやらないというだけでは、「すごく抽象度と不確実性の高いものからプロダクトというすごく具体的なものを生み出す処理装置」としてはうまく回らないということですね。マイクロマネジメントのほうがまだ組織レベルが高いということです。マイクロマネジメントしないのが良いマネジメントだと思うのは、組織レベルが低い場合もあるので注意が必要です。

イノベーションとフォロアーの話

私も前々から気に入ってるこの動画の話をされていました。

First Follower Leadership Lessons from Dancing Guy
全社的にとある取り組みを行った際、最初の数人〜十数人はさらっとついてきてくれるのに対し、そこからのフォロアーが伸び悩む。そこで最初のフォロアーに対しこの動画を見せて、リーダーシップを促すことでその壁を突破し、フォロアーの数は臨界点を突破後指数関数的に伸びていく。ということを実際に行った事例を話されていました。

オープンコミュニケーションの取り組み

客先に常駐する社員もいる中、社内でコミュニケーションを取る難易度が非常に高い中、素晴らしい取り組みをされているなと思いました。
なにか集中して議論すべきことがあった場合、飲み会をセッティング(これは簡単に思いつきそう)、その飲み会にアジェンダを設定し、議事録も取るようにする。全社総会を定期的に開催し(これは簡単に思いつきそう)、出席者全員がリアルタイムでWebから質問や指摘を投稿でき、リアルタイムに役員とのディスカッションができる、など。

新米VPoEがまんまと落とし穴にはまったお話 坂井 健治さん( @saka0ken )

素直に失敗を認め、反省しながら改善していくような人柄の良さがにじみ出てくる良い話でした。NetflixのCulture deckでもはっきりと明記されているように、本当に価値のある情報において重要なこととは、「正直かつ率直に間違いを認める」です。心理的安全性の確保をし、自分に都合の悪い失敗したことや失敗しそうなこと、わからないことなどいかなるポジションやロールにおいても正直かつ率直な情報というものが非常に価値があります。というかこれこそが、他者を自律的に動かす材料の一つです。このように透明性の高い状態が保たれると、誰かが困っているときに誰か知見のある人が助けるという行動をとれるわけです。そんなとても正直かつ率直な坂井さんのセッションではところどころに周りの人との関わりや協力体制が感じ取れました。
残念ながらこちらのセッションも内部的にWeb上に資料を公開する許可がまだとれいていないということなので、ざっくりと思い出しながら書きます。
※2019年11月18日資料が公開されましたので掲載させていただきます。
speakerdeck.com


一つのチームのマネージャーだった坂井さんが、急にVPoEの立場になって組織開発というVPoEの仕事をするもなかなか大変でしたという背景です。

内部的なことをやりすぎないように

途中からこのセッションを聞いたのでセッションでは聞けなかったですが、後に本人に質問したところ、こういう話でした。
1つのチームのマネージャーだった→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 で発言する・しないは単に習慣の問題ではなく才能の問題もあるのではないか、という話です。

どうやったら改善できるのか

BotのようにPublic channelに誘導し続ける、など紹介されていましたが、たしかに地道にやるしかないですね。さらに心理的安全性の確保、Public channelに誘導する人(フォロアー)自体を増やしていくなど地道に努力するしかなさそうですね。
運用方針についての提案はスライドの57pあたりから解説されています。

DMM改革の1年、その実際と反省 松本 勇気さん(@y_matsuwitter)

speakerdeck.com

最後にDMMのCTO松本勇気さんのセッション。これはもう感動というか、自分の興味分野にドンピシャ過ぎて、先に答えを見せないでほしいと思いながらつい見てしまうそんな完成度の高い組織戦略のお話でした。
私自身の組織戦略を剣という武器に例えると、全体像や形はできあがったものの、まだ研磨すべきところがあって本などを通じて言葉を身に着け、研磨してってもうすぐできそうだ!というタイミングで、すでにピッカピカに磨かれた切れ味抜群の同じ剣を見せつけられたかのような気分でした。
このうまくまとまったスライドには無数の理論や経験が盛り込まれているので、全体的な紹介は「ぜひスライドを見てください」とさせていただきたいのですが(スライドでも足りないので話を聞くのがおすすめ)、個人的に松本さんが得意なんじゃないかなぁと思う部分をピックアップして紹介したいと思います。

透明性に対する取り組み

透明性を上げるためにどうしたらいいか、具体的なプラクティスは山のように溢れてしかもそれは自分の組織にマッチするかわかりません。しかし松本さんは透明性が低下する原因を4つに分けて考えておられます。

  • 伝達時の減衰: 組織感の信頼度や情報伝達文化の不足により、情報が減衰し、末端まで伝わらない。
  • 情報伝達アクション不足: そもそも情報を伝達しようとするタイミングが不足し、情報が欠けている。
  • 情報公開の不足: 情報の多くに対してアクセス出来ない状態になっている(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次元モデルについて勉強しましたので、紹介しながら活用方法について考えたいと思います。

文化とは?

まず文化ってなんなのかってところから考えないといけません。
文化を説明するときには玉ねぎ型モデルがよく用いられます。

f:id:KAKKA5:20190614123814p:plain
文化の玉ねぎ型モデル
それぞれが何を意味するかの説明は、ぐぐったら出てくると思うので省かせていただきますが、価値観は一番内側にあるので、外からは見えないようになっています。何を良く思って、何を悪く思うか、何をきれいと思って何を汚いと思うか、何を上品と思って何を下品だと思うか、何を自然だと思って、何を不自然だと思うか。こういった価値観は見えません。
イメージしやすいようにソフトウェアプロダクト開発における具体例を考えてみましょう。Aさんは「しっかり計画を立てて開発を進めるのが当然であり、適当な計画で進められるのは信じられない。あいつは無能だ!」と思っているとします。Bさんは「綿密な計画よりもスピード感を持って進めていくのが重要だ。細かいことにばっかりこだわるやつは無能だ!」と思っているとします。AさんとBさんはお互いに無能だと思っているでしょうが、これは文化のギャップがあるだけであり、それぞれ無能なわけではありません。
一方でそれよりも外側にある儀式や英雄、シンボルなどはある程度見える部分です。この部分は比較的変更しやすい部分です。
経営戦略としての異文化適応力では、中核の価値観(国民文化とも言っている)の部分は12歳くらいまでに無意識下で定着し、その後は変えるのが難しく、それより外側の部分は周りの環境に合わせて変えることができると言われています。

アジャイルの文化

この玉ねぎの図、なんだか見覚えがあるなぁと思ったらこれ、アジャイルの価値原則も同じように書けることがわかるかと思います。実際に玉ねぎ型モデルを用いてアジャイルの価値原則を説明している人を見たことがあります。

f:id:KAKKA5:20190619115349p:plain
アジャイル文化の玉ねぎ型モデル
これらの価値・原則はアジャイルマニフェスト*2*3に定義されています。

価値

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。

原則

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、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次元モデルがこちら。

f:id:KAKKA5:20190614152705p:plain
ホフステードの6次元モデル*6
このあたりはすでに良い説明がされているので引用していきます。*7*8

1. 権力格差 小さい⇔大きい

階層を重視するのか、平等を重視するのか。
権力格差が小さい文化の特徴としては、参加型マネジメントの傾向があり、理想の上司は「コーチ」、ヒエラルキーは便宜上必要になる場合があると考え、分権やエンパワーメント、自立を促され、年長者への経緯は希薄である傾向が高いです。
一方で権力格差が大きい文化においては、階層型マネジメントの傾向にあり、理想の上司は「親」、ヒエラルキーは重要であると考えられ、中央集権、指示命令、上司や年長者の言うことを聞き、敬意を示す傾向にあります。
例えば、権力格差が小さい文化において、上司が権威を示してヒエラルキーを重視しようとすると、部下からは威張っていて融通がきかない無能な上司だと思われる、ということが文化の違いによって生まれます。

2. 集団主義個人主義

自分が属する内集団に依存し、その利益を尊重するのか、それとも独立し個人の利益を優先するのか。
集団主義思考の特徴は一人称が常に"We"、所属集団の意見、メンバーを尊重する、暗黙のコミュニケーション、調和を重んじ、直接的な対立を避ける、集団へのフィードバック、面子を失うことが恥であり所属集団の責任となる、職務より人間関係を優先する、などです。一方で個人主義思考の特徴は一人称は自身である"I"、個人の意見、個人の経済的・心理的ニーズの尊重、明白なコミュニケーションで自分の意見を述べ、対立は必要なものと考える、個人へのフィードバック、自尊心の喪失が恥となり自分自身の責任になる、人間関係よりも職務を優先するなどです。
例えば、集団主義の文化において、個人主義的な価値観でコミュニケーションを取ると、侮辱されている、ストレスがたまる、無作法、無礼である、上司に忠実ではないと思われるということが、文化の違いによって生まれます。

3. 女性性⇔男性性

競争社会の中で家族や友人、大事な人と一緒にいる時間を大切にするのか、それとも達成する、成功する、地位を得ることによって動機づけられているのか。
念の為書いておきますが、これは決して女性や男性の性別としての特徴を言っているのではありません。FeminityなのかMasculoinityなのかという話です。
女性性が高い文化においては弱者を支援、生活の質・連携・協力を重視・目的や目標は方向性を示すもの、良い上司の理想は関係構築力があり意見をまとめることに長けていること、インセンティブは金銭的なものだけではなく、生活の質を高める労働環境、仕事より家庭、男性の女性を果たす役割について感情に同じものを期待する。
一方で男性性が高い文化だと、業績重視の社会、成功者を賞賛、成功・地位・他者より秀でることを重視、明確な目標・ターゲット、良い上司の理想は決定力があり、アサーティブであること、インセンティブは昇給・昇格・賞賛・チャレンジのある仕事、家庭より仕事、男性と女声が果たす役割に対して感情的に異なるものを期待するなどです。
例えば女性性が高い文化において、男性性を発揮してしまうと、攻撃的、自信過剰、自慢している、見せびらかしている、地位や服装・化粧にこだわりすぎなどと思われるということが、文化の違いによって生まれます。

4. 不確実性の回避 低い⇔高い

不確実なこと、知らないことを驚異と捉えるのか、それとも気にしないのか。
不確実性の回避を重視しない文化の特徴は、規則はできるだけ少ないほうがいい、曖昧な状況や不慣れな状況を楽しむ、リラックスしている、実務家・常識への信頼、成功するためにリスクをとる、「Out of box thinking」新しい手法を奨励する、トップマネジメントは戦略にフォーカス、学生は学習のプロセスを求め、教師が全ての解答を知らなくても気にしない、などです。一方で不確実性の回避を重視する文化の特徴は、規則・構造を感情的に必要とする、曖昧な状況、前例のない状況を嫌う、ストレスが多い、専門家への信頼、失敗しないためにリスクを避ける、形式・構造を重視して仕事を進める、トップマネジメントは日々のオペレーションを気にする、学生は正しい答えを求め、教師が全ての解答を示すことを期待する、などです。
例えば不確実性の回避を重視しない文化において、不確実性の回避を重視するような行動をとると、融通がきかない、細かすぎる、マイクロマネジメント、信用されていないなどとおもわれるということが文化の違いによって生まれます。
逆のパターンだと、原則を知らない、モラルがない、不真面目、「無能なのか?それとも単純に怠惰なのか?」と感じるこということが起こります。

5. 短期思考⇔長期思考

将来・未来に対してどう考えるのか。
短期思考の特徴は、短期の財務的結果を重視、評価指標は利益やROI、消費、欲求はできるだけ早く満たしたい、分析的な思考、唯一絶対の心理、原則・原理を重視、善悪を判断する普遍的指針がある、自国に対するプライド。
長期思考の特徴は、長期的な利益や恩恵を短期のそれよりも重視する、評価指標は市場シェアや顧客満足度、倹約、欲求はすぐに満たされなくてもいい、統合的な思考、いくつもの真理、実用性を重視し例外を認める、善悪の判断は状況次第、他の国から学ぶ、などです。
例えば短期思考の文化において、長期思考で行動すると、物事の白黒が明確ではない、ぶれる、分析力がない、決断が遅いなどと思われるということが文化の違いによって生まれます。

6. 人生の楽しみ方 抑制的⇔充足的

人生を楽しみたいあるいは楽をしたいという気持ちを抑制して悲観的に考えるのか、それともその気持を発散させ、ポジティブに考えるのか。
抑制的な文化の特徴は、「非常に幸せ」な人の割合が低い、運命主義で無力感を感じている、悲観主義的、真面目で厳格な振る舞いが信頼と専門性の証、微笑みは疑わしい、道徳的規範が多い、きつい社会。
一方で放銃的な文化の特徴は、「非常に幸せ」な人の割合が多い、人生はコントロールできる、楽観主義的、職場ではポジティブシンキングを奨励、微笑みが基本、道徳的規範が少ない、ゆるい社会、などです。

実際のデータは?

意識調査のデータから生まれたのがこのホフステードの6次元モデルなので、当然データがあり、すでに世界中の101カ国の6次元スコアが出ています。この記事は日本語で書いているので日本人の読者が多いでしょうから、皆さんのイメージと比較するために日本の文化の傾向だけ紹介すると、日本の文化では男性性が高く、不確実性の回避が高く、長期思考で残りは真ん中らへんという感じです。
しかし残りのデータを紹介するのは控えようと思います。
なぜなら*9の著者もかなり慎重になっていると言っていましたが、このデータを安易に知ることによって、あの国の文化はこうだから、あの国出身の人はこういう行動をとるだろう、という間違った固定観念を生むリスクがあるからです。
このデータはあくまでもマクロなものであり、平均化したものですし、同じ国でも組織、コミュニティによってその文化が天地の差ほどあることは周知の事実だと思います。
実際私は日本人ですが、自分自身が日本の文化のスコアとは全然違う文化だなと感じます。しかも、生きている中で大人にになってからでも変わったなと感じます。
このデータ自体は非常に価値がありますし、このデータがなければホフステードの6次元モデルは生まれなかったので、このデータは必要ではありました。しかし私が重要だと考えるのはこのデータから生まれたホフステードの6次元モデルのほうだと考えます。

もしデータを知りたい場合は経営戦略としての異文化適応力の後ろの方に載ってますので読んでみてください。

組織文化の構築

ではホフステードの6次元モデルをどのように活用するのか考えます。
自分が目指している理想の組織文化はどんなものなのか、それを6次元のモデルに落とし込み可視化しておく、現状の文化はどうなのかそれを6次元のモデルに落とし込み可視化しておく。それによってじゃあ変化させるためのアプローチはどうするのかを考えることが出来ます。

仮にアジャイルな組織を作りたいとしてみましょう。
答え合わせをしたわけではありませんが、私自身が考えるアジャイルの文化はこのようなになりました。

f:id:KAKKA5:20190619120303p:plain
アジャイルの文化をホフステード6次元モデルで表した図
不確実性の回避と短期志向/長期志向を真ん中に寄せた理由ですが、それぞれマクロな視点なのか、ミクロな視点なのかによって変わってくるからです。例えば不確実性の回避はマクロな視点から見れば低いと言えますが、良いアジャイルチームは具体的なところで不確実性を回避するための取り組みに力を入れているからです。会議でこういう問題にあたったときにはこうしよう、など予め”変更可能な”ローカルルールとして決めて、ある程度の不確実性を回避し、スムーズに物事を進められるようにしているためです。

一方で自分の組織が仮こうだったとします(これは私の組織とは無関係であり、適当につくったものです)。

f:id:KAKKA5:20190619120658p:plain
現状の組織文化をホフステードの6次元モデルで表した図

すると文化にギャップがあることが可視化できるわけです。

f:id:KAKKA5:20190619120746p:plain
現状の文化と目指したい文化のギャップをホフステードの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では下記5つの内容が語られており、今回はこの中のAim, Boarding, Decisionについての内容の紹介がありました。
Aim(目標設定)の法則〜目指す旗を立てろ! 〜 ★
Boarding(人員選定)の法則〜 戦える仲間を選べ〜★
Communication(意思疎通)の法則〜最高の空間をつくれ〜
Decision(意思決定)の法則〜進むべき道を示せ〜 ★
Engagement(共感創造)の法則 〜力を出しきれ〜

Boarding(人員選定)の法則〜 戦える仲間を選べ〜

どこか特定の組織で、とある手法がうまくいっていて、その手法をそっくりそのまま自分の組織に取り入れても、うまくいかないことが多い。
それぞれの組織にはそれぞれの最適なやり方がある。

f:id:KAKKA5:20190509230308j:plain
組織タイプマトリクス
柔道団体戦(生命保険の営業チーム): 環境変化の度合いが大きく、人材の連携度合いが小さい。
サッカー型(スマホアプリの開発チーム): 環境変化の度合いが大きく、人材の連携度合いも大きい。
駅伝型(メーカーの工場の生産チーム): 環境変化の度合いが小さく、人材の連携度合いも小さい。
野球型(飲食業の店舗スタッフチーム): 環境変化の度合いが小さく、人材の連携度合いも大きい。

f:id:KAKKA5:20190509231833j:plain
環境の変化度合いが大きい場合
環境の変化度合いが大きい場合は、メンバー選びは出口にこだわる=流動的なチームにする。
環境を相手チームに比喩している。サッカーの相手チームがこう動いてきたら、こちらのチームはそれに合わせて変わらないといけない。スマホアプリ開発チームで理解すると、例えば世の中の95%の人類がAndroidスマホを使うようになったら、iOSエンジニアからAndroidエンジニアに入れ替えるとか、スキルセットそのものを入れ替えるとか。

f:id:KAKKA5:20190509231901j:plain
環境の変化度合いが小さい場合
環境の変化度合いが小さい場合は、メンバー選びは入り口にこだわる=固定的なチームにする
環境が変化しにくいということは、今現在のやり方や体制で対応できるということも変わりにくい。ビジネスをより成功させるためには人員の増加=プラスの力の積み重ねであり、そのため誰を入れるのかというところを慎重に考えるのが良い。

f:id:KAKKA5:20190509233042j:plain
人材の連携度合いによる違い
人材の連携度合いが大きい場合は、メンバー選びは異なるタイプを揃える=多様性の高いチーム
人材の連携度合いが小さい場合は、メンバー選びは似たタイプを揃える=均質性の高いチーム
人材の連携度合いが大きいということは、個人ではなくチームで初めて物事を達成できるという状態であり、個々人はそれぞれ違うスキルセットを持った人員で構成することができる。そしてその連携がうまく取れればチームのパフォーマンスは驚くほど高くなる。
人材の連携度合いが小さい場合というのは、人が増えれば増えるほどパフォーマンスがその分プラスされるという感じ。まさに生命保険の営業というイメージがピッタリである。

そして、例えば生命保険の営業マンをやっていた人の価値観や文化というものは、おそらく人材が増やせばそのままパフォーマンスの増加につながる、個人の力こそが成果につながる、などの考えはスムーズに理解できるはずだが、サッカーチームのような組織で働いてきた人たちはその考え方が理解できないかもしれない。

f:id:KAKKA5:20190509233628j:plain
文化摩擦
そんな異なる価値観のチーム間では文化摩擦が起きやすい。
サッカーチームの例としてスマホアプリ開発チームと書いているが、スマホアプリ開発チームでも実は組織の型は様々である。Feature teamなのか、Component teamなのかによってもマトリクス状でこんなに違う位置にいる。
社会人は一般常識を心得ているものだという前提でお互いに接するが、文化がその常識を生むので、その常識がひとによって違ったものになり得る。
このあたりを議論するためには、これらの組織論を学び理解しなければならない。

Aim(目標設定)の法則〜目指す旗を立てろ! 〜

続いて目標設定の話。

f:id:KAKKA5:20190509234519j:plain
目標の種別と特徴
意義目標: 具体的なアクションは分かりづらいが、ブレイクスルーが起きやすい。
成果目標: 意義目標と成果目標の間。
行動目標: 具体的なアクションはわかりやすいが、ブレイクスルーが起きにくい。

昔の日本は行動評価をしていた。等級ごとに取るべき行動が定義されていて、これを評価されていた。
90年代から、世の中の変化に伴い、あまり行動目標を使わなくなった。成果目標が評価されるようになった。具体的なプロセスやアクションはそれぞれの人に任せるようになった。学校の通知表が試験の点数で決まるのも例の一つ。

現代では、OKRのような意義目標を評価するようになってきた。目標があってたら成果を変えても問題ない。
しかしこのような正しいOKRの設定は非常に難しい。トレーニングをする必要がある。精度の低いOKRを設定してしまうと失敗体験につながる。
個々人の自立度合いによって抽象度合いを変えるのはありかも。あとは環境の変化が少ないのであれば、目標を具体的なレベルにするのもあり。

Decision(意思決定)の法則〜進むべき道を示せ〜

経営者に圧倒的人気なフレームワーク

f:id:KAKKA5:20190509235610j:plain
意思決定手法マトリクス
独裁: チームの納得感は低くなるが、速い。
多数決: 中間。
合議: チームの納得感は低くなるが、遅い。

日本の世の中では合議がよしとされているが、今スピードが物を言うので最後はリーダーが決めたらそれに向かうことも必要。
組織の規模が大きくなると、権限の委譲を行わないと回らなくなる。独裁的な意思決定をやっていた場合、意思決定者がキャパオーバーになるし、合議を行っていても合議そのものに時間がかかり、組織が前に進めなくなる。
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割に対して、『フォロワー』が及ぼす影響は8~9割にものぼります。

国境を超えたプロジェクトの70%は失敗し、90%の経営者が異文化間で効果的に結果を出せる人材を見出すのはトップマネジメントのチャレンジと考えています。

80%の企業経営者は、経営の成功には『文化』が鍵になると考え、60%が文化は戦略やビジネスモデルより重要としているものの、文化が効果的に活用されていると考える経営者は35%

文化の中枢にある価値観はだいたい12歳くらいまでに形成されます

近々、著者との勉強会に参加させていただけることになったので、それも踏まえ、記事に書いてみます。

スクラム実践者増加とその評価方法の疑問

Scrum Masters Night!というコミュニティの運営をしております.本日は第23回目の開催で,私は第2回目から運営に入っており,もう5年ほど運営させてもらってることになります.
このコミュニティでは,主にスクラム実践者のための課題解決型イベントを定期的に行っており,今のスクラム実践者はどういう悩みを持っており,今他の人達はどのように解決しているのか,という生の声が聞け,ディスカッションができるので,毎度新たな学びがあります.たまにLeSSの考案者のBas Voddeさんや日本人唯一の認定スクラムトレーナー,熟練アジャイルコーチなど超ビッグなゲストも来たりします.最近福岡や大阪でもイベントやっておりますので,是非一度参加してみてください.Facebookグループで告知してます.

さて,本記事では宣伝をしたかったわけではなく,このコミュニティを運営するにあたっての最近の気づきがあります.
それはここ半年~1年で明らかにこのScrum Masters Night!の参加人数が増えています.徐々に増えたというよりは急に一年以上前の平均から1.5倍ほどの参加人数になりました.
これはどういうことなのかというと,まずスクラム実践者が増えているということは間違いないです.リテンションが上がったんじゃないのか?という仮説もありますが(というかちゃんとデータ溜めておけばよかったんですけどね...),参加者と話していても,確かにリピーターはいますけど,新規は毎回毎回多いです.

次に,参加者と雑談してるときに,スクラムをやることになったきっかけは?という会話になったのですが,多数派はどうやら会社がスクラムをやろうと決めたから,上がスクラムをやろうと決めたから,という理由です.
これはこれで全然良いと思いますし,むしろ,そういう組織体制にしてもらえるというのは非常にありがたいことだと思います.実際スクラムをスタートするには,良いコンディションです.逆に,逆境を乗り越え,地道に関係者全員を説得して回るリーダーシップ力は,相当な体力を消耗するものですし,スクラム自体の成功確率にも影響してきます.
要は,ここ半年から一年で会社の経営レベルの人たちが,「アジャイル」や「スクラム」という言葉に対してポジティブに動いてるということが予測できます.LinkedInなどでScrum Masterの採用メッセージもかなり増えてきました.もちろん,一部の企業ではもっともっと前から導入してるとか,すでに導入して失敗してもとに戻っちゃったとかそういう例もありますが.

では上からスクラムをやるように促されたとなった場合,疑問点として出てくるのが,そのスクラムという方法自体の評価方法です.どのように評価したらいいのかという点に関してはScrum Masters Night!でも何度か見かけるテーマですが,これはスクラムを導入しようとした人(今回の場合は経営層の人たちなど)が,なぜ導入するのかをしっかり現場(スクラムをやるように言われた人たち)に説明する必要があると感じています.もしくはスクラムを導入しようとした人がしっかり何を評価するかにおいて責任を持つ.
特に途中でスクラムを導入するという場合,そもそも何か問題や課題があって,それを解決する方法としてスクラムをやるわけですし.問題を解決する方法は本当はなんだって良いんですよね.
私自身も前回の記事で詳しく書きましたが,会社メンバー全員でやりたいようにやってたらだんだんとやりづらくなってきて,よくよく考えたらやはり組織ちゃんとしてアジャイルにしたら解決できそうじゃないかとなり,スクラムやりやすいのでは?となった感じでスクラムは最後に出てきました.
なので,今どういう課題があって,いろいろ調べてみたら結局のところスクラムをやると解決するかもしれない,という背景がうまく伝わっていると自ずと評価方法も見えてくるのではないかな感じています.
また,そうすることによって先入観による「アジャイルアレルギー」の人に対しても納得感をあたえられるかもしれません.

あと余談ですが,スクラムマスターの数は徐々に増えてきていますが,プロダクトオーナーという肩書の人はなかなか見かけないなーと話してました.確かに,仕事内容としてはPO相当の仕事をしてるけど,大きな組織では企画職とか,総合職とか,プランナーとか,プロダクトマネージャーとか言われたりしてる感じなんですね.

組織の拡大に伴うアジャイルなプロダクト組織構築

Drivemodeというスタートアップにジョインしてから4年が経ちました。ジョインした(入社すると決めた)当時はまだシードラウンド以前であり、ファウンダー4人+エンジニア2人という状態でした。ですが今となっては組織も数十人規模まで大きくなってきています。
組織が大きくなるにつれ、様々な組織やマネジメントの問題に遭遇するようになり、今後もこれらと真剣に向き合わないといけません。
本記事では、これまでの経験を踏まえて、組織の成長に伴ってどのようなアプローチで組織や文化を構築すれば良いか、考えをまとめて書きます。

常に管理されたプロダクトバックログの重要性

いきなりですが、まずプロダクトバックログの話をします。
常に管理されているプロダクトバックログというものは非常に大切です。プロダクトバックログとは目的地に向かうための道筋であり、そこが空になっていたり、でたらめな状態だと、車(プロダクト)は暴走(それぞれ好き勝手開発され)したり、停止(まったく開発されない)したりします。エンジニアリソースを有効活用できないということは言うまでもありません。
これはすべての組織、方法論に言えることだと思います。「何をやるのか」はエンジニアの開発スピードよりも、プロダクトの技術的品質よりも、何よりも大切なことです。

プロジェクト組織とプロダクト組織

上記でいきなりプロダクトバックログの話をしましたが、この扱いがプロジェクトとプロダクトで大きく違います。
プロジェクトとは、一般的には始まりと終わりが明確に決まっているものです。「何かをやろう」と思ったときに何かをやるプロジェクトが発足し、そのためのチームが編成され、プロジェクトが終わると同時にチームが解散します。つまりその後「なにをやるのか」がなくなるということです。
そのため、プロジェクトが行われ、プロジェクトが解散すると、それによって生み出された成果物はしばしばオーナー不明でメンテナンスしづらいものになってしまいます。まさに作って終わり状態です。
一方でプロダクトとは、製品そのものであり、プロダクト組織とはその製品の寿命と同じくずっと存在します。「なにをやるのか」は常にプロダクトバックログで管理されています。
toCサービスのようなプロダクトにおいて、プロダクトチームというものが存在する場合は、プロジェクトからの引き継ぎによってなんかすることも可能ではありますが、そもそもプロジェクトをやらずに、プロダクトチームがプロジェクトの要件をそのまま受け入れて、プロダクトチームがさばくほうが、引き継ぎの必要はなく、オーナーシップも生まれ、メンテナンスもやりやすいですし、プロダクトオーナーによってその施策を生かしていけます。
プロダクトチームそのものが存在しない場合は、作って終わりという状態になり、プロダクトにいい影響が与えるとは考えづらいです。
プロジェクトという考え方があまりにも一般的なので、いきなりプロジェクトをやめるということも難しいことでしょう。しかし、少なくともプロダクト組織を最低限定義することは重要です。

component team(職能組織)とfeature team(機能組織)

一般的なtoCプロダクトを開発するにあたり、component teamとfeature teamのどちらがいいのかについて考えます。

f:id:KAKKA5:20190404190343p:plain
component teamの例
f:id:KAKKA5:20190404190445p:plain
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年目の極めて平凡な社員でしたが、仮に私が当時組織をごそっと変えようとしても、それはとても困難だったでしょう。一体何人の権力者に納得の行く説明をし、合意を取らなければならないか、想像すらできません。この点が数十名規模の組織との違いかなと思います。それでもやらないといけないと強いリーダーシップを持った人は地道にやり遂げるかもしれませんが。

終わりに

ここ2年ほど、組織問題を解決しようとするものの、なかなか適切な言葉や表現が思い浮かばず、苦悩してきた日々でしたが、そんな中で出会ったLarge-Scale Scrumという本が、私が言いたかったことをうまく言葉にしてくれていて本当に助かりました。”Culture follows Structure”という言葉は、感じていたとしても言葉に具現化することが出来ませんでした。できていたとしても単に私が言ったところでそんな名言っぽくならなかったでしょう。
本記事で紹介しているラーマンの法則のラーマンは、まさにこのLarge-Scale Scrumの著者の一人です。
Large-Scale Scrumは単にLeSSについて書いてあるわけではなく、開発組織そのものの考え方をしっかり説明しており、スクラム実践者だけではなく、組織を変えようとしてる人にもおすすめです。最近Odd-eの榎本さんが監修して日本語版が発売されました。

私が現在取り組んでいる組織改編については、現在進行系なので、また後日アップデートしようと思います。

*1:この記事がわかりやすくておすすめです

*2:Larman's Laws of Organizational Behavior - Craig Larman

*3:Larman's Laws of Organizational Behavior - Craig Larman

*4:Large-Scale Scrum

*5:細かいことを言うともうちょっとあります。PMがエンジニアをタスクにアサインしないように、とか。

*6:ジョン・セドン from Large-Scale Scrum

*7:エンジニアリング組織論への招待 の著者です。