システム思考を使ってリーダーシップを考えてみた
先日、「組織の課題を整理しよう」となった時に、ある人がシステム思考を使っていい感じの絵を描いていて、「へ～、すごいな」と思った。
ちなみに、その人が薦めていた本（日本語の本）は、『なぜあの人の解決策はいつもうまくいくのか？』という本であり、その本を読んでみると、元ネタは、MITのSystem Dynamicsという手法？アプローチ？のようである。
で、実は、数年前にそのSystem Dynamicsという授業を受けたことがある。その授業自体は面白かったし、なるほどなと思ったが、授業以外で実践したことはなかった…
という背景もあり、「これはいかん」と反省し、その日本語の本を読みながら、いろいろ考えてみることにした。
ここでは「いい感じのループ図が書けたな」と思うものを紹介したい。
テーマは「リーダーシップと成長の関係」である。
基本のループは、「Output（発表、発信、発言）が増える ⇒ スキル、知識、技術力が上がる ⇒ 成果が上がる ⇒ エンジニアとしての自信が上がる ⇒ 更なる成長への想いが上がる ⇒ Outputが増える」である。また、「スキル、知識、技術力」に加えて「他人への影響力」という要素もあるので、そのループも一緒に描いている。
少し話はずれるが、注意すべきは、このループは正のスパイラルにも負のスパイラルにもなる点である。例えば、このループは、「Output（発表、発信、発言）が減る ⇒ スキル、知識、技術力が上がらない ⇒ 成果が上がらない ⇒ エンジニアとしての自信が下がる ⇒ 更なる成長への想いが下がる ⇒ Outputが減る」という悪循環にもなる。
話を元に戻すと、このループは、若手の頃は正のスパイラルを回ることが多いと思う。特に失うものはなく、ひたすら学び、吸収するからだと思う。
で、このループをもう少し中長期的な視点で整理したのが、その外側のループである。
下の方から説明すると、成果が上がると、ポジションが上がるし、そのポジションによる責任感が上がる。そうすると、Outputも上がるし、他人への影響力も上がる。結果として、上述した基本のループをさらに強化することになる。
一方、基本のループを抑制する方向に働く要素として「恥ずかしいという気持ち」が考えられる。これは、日本の文化や教育の影響もあるが、馬鹿なことを言うと恥ずかしいとか、スマートに見られたいとか、Dumb questionsをしてはいけないとか、そういう気持ちをどうしても持ってしまう。ポジションが上がったり、中堅の年齢になったりすると、この「恥ずかしいという気持ち」が大きくなる人も多いと思う。
また、基本のループ自体を減速させる要素としては、「時代の変化による（技術の）陳腐化」というものもあると思う。
これが全てとは言えないが、なかなか上手く描けたなと思う。こういう関係性を図にして理解した上で、「では、自分はどうしよう？」と考えることは重要だなと思う。
特に、「恥ずかしい気持ち」は意識しないことも多く、知らず知らずの内に消極的になってしまうこともあるのでは？と思う。
ループ図の良いところの1つに「チームで共有することで、議論ができる／共通の認識を持つことができる」というものがあるが、まさにそうだなと思う。このループ図をもとにいろいろな人と議論したい。
後、結局、この「恥ずかしい気持ち」は、詰まるところ「Growth Mindset」に帰着するなといつも思う。また、この手の本を読むと、必ずGrowth Mindsetが引用されている。
Growth Mindsetは最強だなと思う
前頭前野について
"The Defining Decade: Why Your Twenties Matter--And How to Make the Most of Them Now"という本を読んでいて、「え？そうなの？」という驚きがあったので、ここで軽くまとめたい。
多少、意訳している部分もあるが、この本の一節に、
ということが書いてあり、「まじかよ！」と思った。
よく知られているように、言語を司る機能は、幼少期（生まれてから7、8歳ぐらいまで）に発達する。よって、小学校中学年ぐらいまでに英語圏の国に住むと、英語がすぐに身に付くが、その後（小学生高学年以降）に英語圏の国に住んでも、英語を学ぶのに苦労すると言われている。
実際、赤ちゃんの脳は、全ての言語の発音を聞き取ることができるが、小学生の高学年以降は、母国語の発音しか聞き取れなくなるらしい。これは、脳の中のニューロンの結びつきが最適化されてしまうからというのが、その理由らしい。
同じようなことが前頭前野で起きていて、かつ、それが10代の終わりから20代で起きる、というのはまさに衝撃の事実だなと思った。もっと早く知りたかった。
この事実は子育てにおいても非常に重要だなと思う。とは言え、具体的に、「じゃあ、どうするの？」と言われても、あまり何も思いつかないけど…
後、最近、コロナで対面でのコミュニケーションの機会が失われているが、その黄金期の世代の人にとってはかわいそうだな～と改めて思った。
（2022年7月18日 追記）
なんと前頭葉 (or 前頭前野) は、衰えるのが最も早いらしい。早い人では、40代で委縮が始まるとのこと。
というわけで、前頭前野を鍛え続けよう！！！
具体的には、
- 「自分が楽しい」を優先して考えてみる
- 最初から答えを求めすぎない
- 初めての食材や旅行先にトライする
- 投資などに挑戦、リスクを負ってみる
- 恋愛こそ感情の若さを保つ特効薬
などをするのがいいらしい。
知らんけど。
チームを跨いだ変革の進め方について
複数チームを跨いだ変革について思ったことを書いてみたい。
まず大前提として、「人は自分の組織に愛着を持つ生き物であり、複数チームを跨いだ変革は難しい」ということが言える。
変革をするためには、「今までのやり方はおかしい」という自己否定から始める場合が多く、この自己否定がなかなか難しい。
一般的には、より高い視野に立つ人が「こうあるべきだ！」と言いいながら、大鉈を振るうというアプローチになると思う。いわゆる、トップダウンによる変革である。
一方で、スムーズな変革を行うには、チームメンバーの納得感も必要であり、ボトムアップ的な何かはあったほうがよい。また、チームビルディングという観点でも、既存のチームを壊しすぎることは良くないとされている。改めてチームビルディングに多大な労力をかけるより、変革そのものに力を割くべきだと思う。
このトップダウンとボトムアップの両方の良さを活かすやり方として、以下のようなやり方がいいと思っている：
- Step 1：各チームの取り組み内容を紹介する、トップからは現状の課題、進むべき方向性を示す
- Step 2：各チームからStep 1で得た情報を踏まえ、変革案を理由とともに提示してもらい、各チームからの変革案に違いが見られる場合は、その違いを議論する。
- 違いがあるということは良いこと（そこから新たなものの見方、考え方が生まれる）という意識で議論する
- Step 3：トップダウンで、新しいチームの体制を提示する。その際にその理由も丁寧に説明する
- Step 4：新体制で始まった後も、ボトムアップ的に振り返りを行い、必要な微調整を行う
このやり方であれば、チームメンバーの納得感もあり、自分ごととして変革を推進できると思っている。また、副次的な効果として、チームメンバーが、より高い視座からチームを見つめ直すことができるというものもあると思う。
一方、トップからしても、見えていない部分に気づける可能性もあり、より適切な意思決定ができるのでは、と思う。
また、Step 2の前後で、トップが各チームメンバーと1on1をしておくと、よりスムーズに議論が進むのでお薦めである。
実は、チームメンバーからすると、「そもそも〇〇の背景がよくわかっていない」ということがあるが、「恥ずかしくてみんながいる会議で訊けない」ということが往々にしてあると思っている。そういう疑問に答えつつ、1on1で丁寧にお互いの意見を交換することはとても重要だと思う。
コミュニティマーケティング
先日、「ビジネスも人生もグロースさせる コミュニティマーケティング」という本を読んだ。AWSのコミュニティを立ち上げた小島さんの本である。
本のポイントを要約すると、
- マーケティングにおいて、従来のマスマーケティングは、「認知」のところにフォーカスしている。「自分ごと化」のところは、クリエイティブに依存しており、かなりいい加減
- 一方、コミュニティマーケティングは、そのプロダクト／サービスのファンが、熱量を持って、そのプロダクト／サービスのファンになるであろう人に、適切なタイミングで適切な情報量を伝えることで、「自分ごと化する」、及び、「使い続ける」という部分にフォーカスするマーケティング手法である
- コミュニティに参加する人にとっては、単に楽しいという部分もあるが、結果的に、成長する／自分の価値を認識する／自分を見つけてもらうという大きな価値がある
- だからこそ、ワークする
- コミュニティマーケティングを進める上でのTips
という感じである。
何となく「コミュニティが大事だよね～」、「勉強会に参加すべきだよね～」、「コミュニティの幹事をやるといいよ～」というのは知っていたが、この本を読んで、そのポイントを整理して理解できたと感じた。
また、普通のコミュニティとマーケティングのためのコミュニティはちょっと違うのかもなとも思った。どっちがいい／悪いではなく、コミュニティ自体は、自然発生的に立ち上がるという性質を持つため、何かの意図があって、コミュニティを立ち上げようと思うであれば、明確に意思を持って取り組むべきだと思った。
という意味で、過去に社内でコミュニティを立ち上げたことがあり、この本を読みながら、その振り返りを行うことができた。
具体的には、
- 明確な意志を持ってコミュニティの立ち上げと運営をしておくと、また違った形になったかもしれない
- 特に、人事異動により、コミュニティのキーマンがどんどん抜かれていったのは痛かったな～
と思った。次、もう一度、コミュニティを立ち上げる際には、その辺の反省点を踏まえて、もっと上手くやりたいなと思う。
いずれにせよ、マーケティングに使うか否かは置いておいて、コミュニティという概念は大事だなと改めて思った。特に、「コミュニティを立ち上げる」という行為は、なかなか勇気がいるが、一方で、自分の成長や世界の拡がりという意味で大きそうだ、というのを改めて感じた。そういう力学的なものをもう少し意識していきたいなと思う。
「今年度の組織の目標を1つだけ変えてみて」というお話
先日、所属する組織の年度初めのキックオフがあった。
そこで、その組織の長から
こちらが今年度の組織の目標（4つの箇条書き）です。その1つを変えていいなら、どうする？各自で考えて、Slackに書き込んで！
というお題が出された。
このお題に関して、「これ、いいな～」と思ったので、備忘録として書いておく。
正直、最初に聞いた時は、「え？大変だな～。面倒くさいな～。」と思った。
その目標自体は、例年の目標をベースに、組織の長やその周りの人がしっかり考えたもので、完成度も高く、「それを変えるのは大変だな～」という感覚である。
とは言え、「そんなのやりません」というのもダサいので、真面目に考えることにした。
となると、まず4つある中から1つを選ぶことになる。
で、他の人のSlack上での投稿を見ていると、この「選ぶ」という部分で、その人の見ている視点が明らかになるな～というのがわかり、面白いなと思った。
また、完成度の高いものを無理やり変えようとするからこそ、自分の一番気になっていることを入れ込む形になり、かつ、それを無理やり言語化するというところが素晴らしいなと思った。
ちなみに、後で、その組織の長とも話したが、
どこかの本に書いてあった。確か資生堂。ああいう目標は、誰も気にしない。ただ、こうやってお題を出すと、穴が開くほど見て、考える。それで目標は達成している。
と言っていた。
この手法はどこかで使えるなと思うので、いつか使いたい。
そういや、ふと思い出したが、1年前のキックオフでは、「各自がキックオフそのものをKPT法で振り返ろう」だった気がする。あれも良かったなと思う。
Visionについて
昨日、ある先輩と話していて、私から、
「最近、若手が中堅になる頃に会社を辞めていくんですよ。外資の方が待遇もいいし、終身雇用という時代でもないので、しょうがない部分もあるのですが…」
という話をしたら、
「それは経営層が悪い。リーダーが『○○を実現しよう。付いてきてほしい』と言って、それに共感してくれるか。そこで共感できずに出ていくのはしょうがない。」
というコメントをいただいた。
ちょっと目から鱗というか、「確かにそうだな」と思った。考えてみると当たり前の考え方だが、今まで悩んできた中で、あまり明確に意識できていなかったなと反省した。いわゆるBlind Spotsというやつかもしれない。
もちろん、Visionだけではなくて、MITのDistributed Leadershipにあるように、「Relating」、「Sense-making」、「Visioning」、「Inventing」のそれぞれでチームへの求心力は存在し、それぞれを意識すべきだとは思うが、あまりにも「Visioning」への意識が薄かったなと反省した…
改めてVisionを意識したいと思う。
後、やはりいろいろな人と話すべきだなと思った。今回、コロナも収まってきたので、この方とも久しぶりにお会いして、Face-to-Faceで話をした。ちょっと他の人とも話してみようと思った。
「Team Topologies」を読んで
GWの空き時間に「Team Topologies」という本を読んだ。
最近、いろいろお手本にしているチームのエースエンジニアの方が「Team Topologiesを読んでいる」と話していたので、それに触発されて読んでみた。
一言で感想を書くと、「チーム作りを考える上でとても参考になる本だな」と思った。
例えば、個人的に、「Microservices」、「Two-pizza teams」、「疎結合」などについて概念としては知っているが、「何故、それを採用すべきなのか？」はよくわかっていなかった。要は、ぼんやりとは理解していても、他人に論理的・合理的に説明するほどには深く理解していない状態だった。
この本を読んだ今は、その「何故」をパシッと言えるようになったという感覚がある。
これから新しくチームを作ろうと思う方は必読の書だと思う。
というわけで、（いつものように）この記事では「なるほどな」と思ったところをいくつか備忘録としてまとめたい。
Microservices／Two-pizza Teams／疎結合の「何故」
この本では、以下の3つの考え方に基づきチームのあるべき姿を考えている:
- コンウェイの法則
- ソフトウェアのアーキテクチャは組織の形と同じになる
- Cognitive Load（認識負荷）
- チームのCognitive Load（認識負荷）を意識し、大きくなりすぎないようにする
- Dunbar’s Number
- お互いに親密に信頼できる人の数は5～9人ぐらいである
この切り口が素晴らしいなと思う。
自分の言葉で説明すると、
- Dunbar’s Numberにより、チームの人数は5～9人にすべき
- Innovationを起こすためには、お客様の反応に基づき、Flexibility & Agilityを持ってサービス／プロダクトを進化させていく必要がある
- そのためには、1つのチームでDesign/ Develop/ Test/ Operateの全てを行うべき
- とは言え、チームにはCognitive Load（認知負荷）という考え方があり、Cognitive Loadが大きくなりすぎると、上手くいかなくなる
- よって、チーム、及び、チーム間の相互作用は、Cognitive Loadをいかに下げるかに基づいてDesignすべき
- 例えば、APIを用いた疎結合にすることで、Cognitive Loadが下がる。あるいは、Managed ServicesやPlatform化されたServicesを使うことでCognitive Loadが下がる
- 最後に、コンウェイの法則に基づき、そのチームに合ったソフトウェア／システムのアーキテクチャを採用すべき
ということかと思う。
この7個の箇条書きで、Microservices／Two-pizza Teams／疎結合の「何故」を説明することができている（と個人的には思う）。そこがこの本の凄みだなと思った。
4つのチームタイプと3つのチーム間の相互作用
この本では、チームは、以下の4つに限定すべきと言っている:
- Stream-Aligned Team
- Enabling Team
- Complicated-Subsystem Team
- Platform Team
ポイントは、「Stream-Aligned Teamがチームの基本であり、残りの3つのチームタイプはStream-Aligned TeamのCognitive Loadを下げるためにある」である。
このわかりやすさが素晴らしいなと思う。
また、チーム間の相互作用に関しては、以下の3つに限定すべきと書いてある:
- Collaboration mode
- 新しい何かを発見するときには、密接に連携する
- X-as-a-Service mode
- 新しい何かを発見し終わった後は、連携の度合いを最低限にし、Cognitive Loadを下げる
- Facilitating mode
- ある特定の問題に関して、助ける／助けられる関係を構築する
こちらにおいても、「Cognitive Loadを意識しつつ、チーム間の相互作用を考える」というその切り口が素晴らしいなと思う。
このわかりやすさは、チームを作る上で非常に参考になるし、チームメンバーも意図するところを理解できるので素晴らしいなと思う。
コミュニケーションは必ずしも良いものではない
（若干、しつこいが）このCognitive Loadという考え方は、「コミュニケーションは必ずしも良いものではない」に基づいている。
これは、言われてみると当たり前だが、なかなか気づいていない部分だなと思う。
例えば、昔、いた部署では、多くの人がいろいろな打ち合わせに出席していて、1人で作業する時間を取ることができず、夜な夜な残業する、ということが多かった。
この「打ち合わせ」を「コミュニケーション」と捉えると、まさにコミュニケーションは必ずしも良いものではないなと思う。
言い換えると、コミュニケーションはコストが高いということを認識した上で、どのようにコミュニケーションを行うかをデザインすることが大事だなと思う。
