【イベントレポート】『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歳くらいまでに形成されます
近々、著者との勉強会に参加させていただけることになったので、それも踏まえ、記事に書いてみます。
