KAKKA is not 閣下

Drivemodeというシリコンバレーのスタートアップでエンジニア、2019年9月に某自動車会社にExit、某自動車会社のDX推進のリード、「みてね」のエンジニアリング組織マネジメント。 CSP-SM(認定スクラムプロフェッショナル)、メタルドラマー。 ex:Drivemode(Honda), Drivemode、リクルート、MIXI、NAIST Twitter→@KAKKA_Blog

組織は10人で最初の壁にぶつかる — スケーリングと透明性の方程式

「うちの組織、最近なんかうまく回らなくなってきたんですよね」

経営者やマネージャーからこの相談を受けたとき、僕が最初に確認するのは「今、何人ですか?」という質問です。人数を聞くと、ある程度の課題の仮説を立てることができます。

実際にカジュアル面談で組織の人数と職種構成、組織構造、事業フェーズ、開発プロセスを聞いただけで、課題の仮説がかなり的中したことがあります。

なぜそんなことが可能なのか。組織のスケーリングには、驚くほど共通のパターンがあるからです。

組織の壁には理論的な根拠がある

人類学者のRobin Dunbarは1992年の論文で、霊長類の新皮質の大きさと集団サイズの相関から、ヒトの安定した社会集団の上限を約150人と予測しました。いわゆる「ダンバー数」です。

さらに興味深いのは、Dunbarが示した社会的関係の階層構造です。5人(最親密な仲間)→ 15人(親友)→ 50人(友人)→ 150人(意味のある関係を維持できる上限)。この5, 15, 50, 150という数列は、組織の「壁」が現れるタイミングと驚くほど一致しています。

また、Larry E. Greinerが1972年にHarvard Business Reviewで発表した「成長モデル」では、組織は成長段階ごとに特有の「危機」に直面するとされています。創造性の段階ではリーダーシップの危機が、指揮の段階では自律性の危機が訪れます。

これらの理論的背景を踏まえた上で、僕が実際に観察してきた「壁」を具体的に説明していきます。

10人の壁 — 階層の誕生と自律性の喪失

最初の壁は、10人を超えたあたりでやってきます。

1933年にV.A. Graicunasが示したように、上司と部下の関係は部下の数が算術的に増えるだけで、関係の複雑さは幾何級数的に増大します。一人のリーダーが全員を直接マネジメントする「スパン・オブ・コントロール」には限界があり、必然的に組織に階層が生まれます。

階層が生まれると、各階層ごとにコミュニケーションが発生します。ここで意識的に透明性を確保しない限り、組織内に情報格差が生まれてしまう可能性が高いです。

情報格差が生まれるとどうなるか。メンバーは自律的に業務を進めることが難しくなります。判断に必要な背景情報がないので、情報を持っている人に聞くか、指示されるのを待つしかありません。こうして、自律的なカルチャーが徐々に消えていく傾向があります。

スタートアップのあの熱量——全員が同じ方向を向いて、指示がなくても自分で判断して動ける空気感——は、放っておくと10人を超えた時点で静かに失われ始めるかもしれません。「昔はもっとスピード感があったのに」という声は、ほぼ例外なくこのフェーズで聞こえてきます。

30人の壁 — 情報爆発と「どこに何があるかわからない」問題

30人程度まで成長すると、10人の壁の教訓を活かして透明性を意識していたとしても、新たな問題が発生します。情報爆発です。

George A. Millerが1956年の有名な論文で示したように、人間の短期記憶の処理容量には「7±2」という限界があります。組織が多様になり情報量が爆発的に増えると、個人の認知能力では処理しきれなくなるのです。 たとえば電話番号の090-1234-5678を覚えるとき、私たちは11桁の数字を1個ずつ覚えるのではなく、09012345678という3つのかたまりとして認識します。それが7±2という限界の中でうまく処理するための、脳の自然な働きです。 組織が多様になり情報量が爆発的に増えると、個人の認知能力では処理しきれなくなるのです。

わかりやすい例がSlackです。チャンネルが全然追えなくなってきて、整理が始まります。しかし、明確なポリシーを持った命名ルールがない限り、何のチャンネルかわからなくなりがちです。#proj-alpha#team-alpha#alpha-devの違いは? 情報はたくさんあるのに、どこにどの情報があるかわからない状態に陥りやすくなります。

Eppler & Mengisの研究(2004年)でも、組織における情報過負荷は原因→症状→対策→原因というサイクルを形成することが示されています。情報を増やせば透明性が上がるという単純な話ではなく、情報の構造化と検索性が同時に求められるのです。

結果として、メンバーはさらに自律的に動くことが難しくなり、レポートラインとのコミュニケーションに頼らざるを得なくなる傾向があります。情報がオープンであることと、情報が見つけられることは、全く別の問題なのです。前者は文化の問題、後者は設計の問題。30人の壁は、文化だけでは超えられない、仕組みの設計が必要な壁だと考えています。

50人の壁 — 距離と信用のジレンマ

50人を超えると、スパン・オブ・コントロールの観点で組織の階層がさらに一段深くなります。部長、マネージャー、スタッフのような三層構造です。

ここで新しい課題が二つ生まれる可能性があります。

一つ目は分業の設計です。組織のトップは広い範囲の抽象的な業務——戦略、計画、方針——を担い、末端は具体的な業務——タスク、実装、運用——を担います。この抽象と具体の分業を極めなければ、組織は円滑に回りません。Greinerの成長モデルでいう「委譲の段階におけるコントロールの危機」に相当するでしょう。

二つ目は距離の問題です。部長とスタッフでは物理的にも心理的にも距離が遠くなります。普段全然会わない、パーソナリティもわからない人が「納得感のない戦略を押しつけてくる」という印象が生まれやすくなりかねません。

つまり、50人の壁の本質は信用のジレンマではないかと考えています。組織のトップが現場の信用を得るための振る舞いが、10人のときとは全く異なるものになります。全員と1on1ができた頃の距離感はもう戻ってきません。仕組みとして信用を構築する必要が出てくるのです。

100〜300人の壁 — パターンは再帰的に繰り返される

100人、200人、300人とさらに階層が深くなりますが、課題の傾向は本質的に同じです。スパン・オブ・コントロールの限界、情報格差の拡大、自律性の低下、信用の希薄化。スケールが変わるだけで、構造的に同じ問題が再帰的に現れます。

だからこそ、「何人ですか?」と聞くだけで課題が予測できるのです。Dunbarの階層(5→15→50→150)やGreinerの成長モデルが示すように、組織の壁は人間の認知能力と社会的関係の本質的な限界に根ざしています。

処方箋としての透明性 — 3つのフェーズ

これらすべての壁に共通する処方箋があると考えています。透明性です。

Ken SchwaberとJeff Sutherlandが定義したスクラムの三本柱は「透明性・検査・適応」です(Scrum Guide, 2020年版)。透明性がなければ正しい検査ができません。正しい検査がなければ正しい適応ができません。透明性はすべての出発点であり、自律的な組織の土台ではないでしょうか。

僕は透明性を3つのフェーズで段階的に進化させるアプローチを取っています。

フェーズ1:オープンに発信するカルチャーの醸成。 まずは発信のハードルを極限まで下げます。気軽にアウトプットできる場をつくり、日常的な発信が自然に行われるカルチャーを醸成します。

フェーズ2:情報の構造化。 発信量が増えると「情報が多すぎて見つけられない」という30人の壁が顕在化します。ここで組織構造と情報構造を対応させ、階層的に整理します。

フェーズ3:集約・メッセージング・自動化。 50人を超えると構造化だけでは追いつかなくなる可能性があります。ここでAIの力を借ります。投稿の要約をAIが自動生成し、日次で更新記事一覧を配信する。ナレッジベース全体をAIが理解した上で質問に答えてくれるQ&A機能を活用する。必要な情報が向こうからやってくる状態をつくるのです。

誰も課題を提示してくれない

最後に、組織のトップが最も気をつけるべきことを一つ伝えたいと思います。

それは、組織のトップには、誰も課題を提示してくれないということです。

もちろん、現場のメンバーや部下から課題が上がってくることはあります。しかしトップの仕事は、それをそのまま受け取ることではありません。複数の現場や組織全体を考慮した上でバランスを取り、戦略的に優先順位をつけ、解決の方向性を定義する——それがトップの役割です。部下から挙がってきた課題をそのまま使うことはできず、トップ自身が自分の頭で考え、本質的な課題と解決案を定義(または意思決定)する必要があります。その責任を担ってくれる人は、誰もいないのです。

さらに厄介なのは、もう一つの落とし穴です。現場からの課題に対する共感力が、徐々に衰えていくという問題です。現場から距離が離れるほど、日常業務の実感が薄れます。「そんな細かいことが課題なのか」という感覚が生まれ始めたとしたら、それはトップ自身が組織の実態から乖離し始めているサインかもしれません。

本業で組織のリーダーをやっていると、本当にどっぷりハマって社外のことが見えづらくなります。そして社内でも、普段見ている状態に慣れすぎて、それが課題であるという認識すらできなくなる可能性があります。

壁のパターンは決まっています。知っていれば備えられます。備えていれば乗り越えられる可能性が高まります。次の壁がいつ来るかを意識し、先手を打っていくこと。それが、スケーリングを乗り越えるための最も確実なアプローチではないかと考えています。


参考文献

  • Robin I. M. Dunbar (1992) "Neocortex size as a constraint on group size in primates" Journal of Human Evolution, Vol. 22
  • Robin Dunbar (2010) How Many Friends Does One Person Need? Faber and Faber
  • V.A. Graicunas (1933) "Relationship in Organization" Bulletin of the International Management Institute, Vol. 7
  • Larry E. Greiner (1972/1998) "Evolution and Revolution as Organizations Grow" Harvard Business Review
  • George A. Miller (1956) "The Magical Number Seven, Plus or Minus Two" Psychological Review, Vol. 63, No. 2
  • Martin J. Eppler & Jeanne Mengis (2004) "The Concept of Information Overload" The Information Society, Vol. 20, No. 5
  • Ken Schwaber & Jeff Sutherland (2020) The Scrum Guide scrumguides.org

シリコンバレーで信頼を失った話 — 「文句を言う人」から昇格まで

リーダーシップについて語るとき、成功体験は聞こえがいいものです。でも本当に人の心に刺さるのは、失敗の話ではないでしょうか。

今回は、僕がシリコンバレーのスタートアップで「信頼を失った」話をしたいと思います。そしてそこから学んだ、リーダーシップの本質について。

入社時は順風満帆だった

そのスタートアップに入社したのは、会社の規模がまだ数名程度、シードラウンドの直前でした。

エンジニアとしての仕事はもちろん、日本で培ったアジャイルの知見を活かして、チームの開発プロセスの改善に取り組みました。スクラムの導入、タスク管理の仕組み化、レトロスペクティブの運用——当時のメンバーは誰もアジャイル開発の経験がなかったので、僕が持ち込んだプラクティスは新鮮だったようですし、幸いなことに、チームの生産性にも良い影響があったような感覚はありました。

当時はありがたいことに、周囲からも認めてもらえていました。仕事は楽しかったですし、手応えも感じていました。

転機はシリーズAだった

シリーズAの資金調達を経て、会社の人数が一気に増えました。組織に階層が生まれました。

僕は相変わらず現場のエンジニアとして働いていましたが、問題が見え始めました。上層部からの情報の欠落が激しくなってきたのです。なぜその技術スタックを選んだのか。なぜそのプロダクト方針になったのか。意思決定のプロセスが不透明で、決定事項だけが降りてきます。

これは組織のスケーリングで典型的に起きる問題です。10人を超えたあたりで階層が生まれ、情報格差が発生します。数名の頃は全員が同じ情報を持ち、全員が意思決定に関与していました。それが突然、見えなくなったのです。

当時の僕は、その問題の構造をなんとなく感じ取っていました。だから何度も課題を上げました。カルチャーの変革を試みました。しかし、全く空回りしていました。

「文句を言う人」の誕生

フラストレーションが溜まっていきました。

トップダウンの意思決定には納得できるものばかりではないので、決定されたことに対して指摘をすることがどんどん増えていきました。僕としては組織を良くしたい一心でした。より透明性のある、自律的な組織にしたかったのです。

しかし周囲から見た僕は、そうは映っていなかったようです。

徐々に、僕は「文句を言う人」というイメージが醸成されていったのです。

今振り返ると、非常に教訓的です。正しいことを言っているつもりでした。組織のためだと思っていました。指摘していた課題の方向性自体は、大きくは外れていなかったのではないかと思います。

でも、伝え方が悪かった。タイミングが悪かった。そして何より、信頼残高が足りなかったのです。

Stephen R. Coveyは著書『7つの習慣』(1989年)の中で「感情の銀行口座(Emotional Bank Account)」という概念を提唱しています。人間関係における信頼の蓄積を銀行口座に例えたものです。預け入れ——相手を理解する、小さなことに気を配る、約束を守る——を続ければ残高が増え、引き出し——批判する、約束を破る、無視する——をすれば残高が減ります。

組織が小さかった頃は、日々の仕事ぶりで自然に信頼残高が積み上がっていました。しかし組織が大きくなり、直接のやり取りが減った人たちから見ると、僕は「よくわからないけど文句ばかり言っている人」に映っていたのかもしれません。

気づけば、ディスカッションの場から外されるようになりました。自分が望む方向——変革したい方向——と、組織が実際に向かう方向が、完全に逆を向いていく感覚。変革したくて声を上げれば上げるほど、変革から遠ざかっていく。あのパラドックスは本当につらいものでした。

CEOの直接指導

転機は、CEOからの直接の指導でした。

僕の一連の振る舞い、その空回り、そして周囲への影響について、率直に伝えてくれました。自分では見えていなかった周囲への影響。自分は正義の旗を振っているつもりでしたが、実際には組織にネガティブなエネルギーを撒き散らしていたこと。

本質的なメッセージはこうでした——「組織を変えたいなら、まず自分が変われ」。

ハーバード・ビジネス・スクール教授のFrances Freiは、TED Talk「How to Build (and Rebuild) Trust」(2018年)の中で、信頼は真正性(Authenticity)・論理(Logic)・共感(Empathy)の3つの柱で構成されると説明しています。信頼が崩れるとき、必ずこの3つのどれかが「ぐらつく」のだと。

僕の場合、「論理」は正しかったかもしれません。しかし「共感」——相手の立場を理解し、相手のために動いているという信頼——が決定的に欠けていたのだと思います。正論を振りかざすだけで、人を巻き込む力を失っていました。

180度、心を入れ替えなければならないと思いました。

信頼の再獲得に1年以上

心を入れ替えました。

しかし、失った信頼を取り戻すのは、信頼を築くよりもはるかに時間がかかりました。リスク認知研究の第一人者であるPaul Slovicは「信頼の非対称性原理」(1993年)の中で、ネガティブな出来事はポジティブな出来事よりも信頼に遥かに大きな影響を与えることを示しています。信頼を壊すのは一瞬ですが、築くのには膨大な時間がかかるのです。

具体的に何をしたかというと、特別なことはしていません。目の前の仕事を丁寧にやる。周囲の意見をまず聞く。自分の考えを押しつけるのではなく、相手の文脈を理解した上で提案する。小さな約束を守り続ける。求められていないアドバイスをしない。会議では建設的な発言を意識する。

地味です。地味ですが、これしかないと感じていました。

Wharton SchoolのSchweitzer, Hershey, Bradlowらの研究「Promises and Lies」(2006年)でも、損なわれた信頼は一貫した誠実な行動の積み重ねで回復可能であることが実証されています。ただし、完全な回復には時間がかかるとも。

周りが自然と僕を巻き込み、僕に相談してくれるようになるまで、1年以上はかかったと思います。焦る気持ちはありましたが、焦って大きなアクションを取ると逆効果になることは、もう嫌というほど学んでいました。

Directorへ、そして全社最高評価

結果的に、僕はDirector(本部長)のポジションまで昇進し、組織を束ねることができました。退職前の人事評価でも、ありがたいことに高い評価をいただくことができました。

「文句を言う人」からDirectorへ。その間にあったのは、CEOの率直なフィードバックと、1年以上にわたる地道な信頼再構築でした。劇的な転機があったわけではありません。日々の小さな行動の積み重ねが、最終的に大きな結果として返ってきたのだと思います。

外に出て、戻ること

シリコンバレーでの一連の経験——成功も失敗も含めて——は、僕のリーダーシップの根幹を形づくっています。

スタートアップの成長にEXITまで貢献できたこと。規模の大きな組織でDX変革に貢献できたこと。そして何より、信頼を失い、取り戻すという痛みを通じてリーダーシップの本質を学んだこと。

昔からアウトプットする習慣があったおかげで、これらの経験は言語化された知見として蓄積されていました。それが、その後のキャリアでも活きる場面が多いと感じています。体験は風化しますが、言語化された知見は残ります。

一度外に出て、戻る。いわゆるアルムナイ転職は、日本ではまだ「出戻り」のイメージが強いかもしれません。退職したときの印象で見られがちです。

しかし、Academy of Management JournalのKellerらの研究(2021年)では、アルムナイ社員は再入社直後に新規採用者より高いパフォーマンスを発揮することが報告されています。また、Harvard Business ReviewのKlotzらの記事(2023年)によれば、「新規」採用のうち4分の1以上がアルムナイ社員であるというデータも報告されています。

退職時のイメージを遥かに覆す成果を外で残したなら、全く新しい人として見てもらえる可能性があります。そこに、かつて築いた信用や人柄が加わると、信用はさらに積み重なるでしょう。出戻りではなく、パワーアップして帰還した人間として迎えられるのです。

信頼は取り戻せる

この話で伝えたいことは一つです。

一度失った信頼でも、地道に努力すれば取り戻せます。

正しいことを言っているのに伝わらない。変革したいのに空回りする。そんな経験をしているリーダーは少なくないのではないでしょうか。

そのとき大切なのは、「自分は正しい」と思考停止することではなく、自分の伝え方、巻き込み方、そして信頼残高そのものを見つめ直すことだと思います。正しさは、信頼の上に乗って初めて力を持ちます。信頼のない正しさは、ただのノイズになりかねません。

リーダーシップとは、正論を言う能力ではないと考えています。人を巻き込み、共に動く力ではないでしょうか。


参考文献

  • Stephen R. Covey (1989) The 7 Habits of Highly Effective People Simon & Schuster(邦題:『7つの習慣』キングベアー出版)
  • Frances Frei (2018) "How to Build (and Rebuild) Trust" TED Talk, TED2018
  • Frances X. Frei & Anne Morriss (2020) "Begin with Trust" Harvard Business Review, May-June 2020
  • Paul Slovic (1993) "Perceived Risk, Trust, and Democracy" Risk Analysis, Vol. 13, No. 6
  • Maurice E. Schweitzer, John C. Hershey, Eric T. Bradlow (2006) "Promises and Lies: Restoring Violated Trust" Organizational Behavior and Human Decision Processes, Vol. 101
  • J.R. Keller et al. (2021) "In With the Old? Examining When Boomerang Employees Outperform New Hires" Academy of Management Journal, Vol. 64, No. 6
  • Anthony C. Klotz et al. (2023) "The Promise (and Risk) of Boomerang Employees" Harvard Business Review

AI時代に専門家は不要になるのか? — 超・T型人材化と「意思」の時代

AIが80点のデザインを出してくれる時代がやってきました。

エンジニアもAIに指示を出して、その結果を眺めている時間のほうが長くなってきています。デザイナーは「もう自分いらないんじゃないか」と口にし始め、エンジニアは「私の職種って何なんだろう」と問い始めています。

これは僕がマネジメントする組織で、実際に起きていることです。抽象的な未来予測の話ではありません。今、目の前で起きている現実なのです。

専門家不要論への回答は「NO」

結論から言えば、AIが業務を代替していく時代に専門家が不要になるかという問いに対して、答えは明確にNOだと考えています。

ただし、専門家の「役割」は劇的に変わっていくでしょう。

2013年にオックスフォード大学のCarl Benedikt FreyとMichael A. Osborneが発表した論文「The Future of Employment」では、米国の雇用の約47%が自動化のリスクにさらされていると推計されました。一方で、Thomas H. DavenportとJulia Kirbyは著書『Only Humans Need Apply』(2016年)の中で、AIによる「自動化(automation)」ではなく「拡張(augmentation)」——つまり専門家がAIと共に働くことで価値を高める——という方向性を提唱しています。

僕もこの「拡張」の考え方に強く共感しています。これまでエンジニアは自らコードを書き、デザイナーは自らUIを作り、プロダクトマネージャーは自ら仕様を定義してきました。しかしAIエージェントがこれらの実行作業を高い水準でこなすようになった今、プレイヤーの役割は「AIをマネジメントする」ことにシフトしつつあります。

マネージャーとしての僕は、存在意義に悩むメンバーに対してこう伝えるようにしています。

「AIをマネジメントするのが、あなたの新しい役割です」

もちろん「マネジメントとは何か」から説明する必要があります。マネジメントとは、ゴールを定義し、リソースを配分し、品質を担保し、方向性を修正し続けるプロセスです。AIというリソースが加わった今、そのリソースをどう使いこなすかが各プレイヤーの腕の見せどころになるのではないでしょうか。

超・T型人材化という必然

自身の専門分野だけに業務を閉じていると、AIの力によって必然的に時間的余裕が生まれてきます。その余裕は、ミッションや目的のために業務範囲を広げる方向に使われるべきでしょう。つまり、T型人材化がこれまで以上に加速していくと考えています。

「T型人材」という概念は、1991年にDavid Guestが英紙The Independentで紹介し、その後IDEOのCEOであるTim Brownがデザイン組織の採用・チームビルディングの文脈で広めたことで知られています。深い専門性(Tの縦棒)を持ちながら、隣接領域にも越境できる幅広さ(Tの横棒)を備えた人材像です。

僕はこれをさらに発展させた概念として「超・T型人材化」と呼んでいます。

これまでは「越境できたら理想的」というレベルの話でしたが、AI時代ではこれが標準になっていく可能性が高いです。専門分野に閉じているだけでは仕事が足りなくなるからです。エンジニアとデザイナーとビジネス職の境界線がどんどん曖昧になっていく世界。ビジネス職がプロトタイプを作るどころか、コーディング実装まで行う未来は、近々どころかもう来ているように感じます。

AIコーディングツールを使えば、デザイナーが動くプロトタイプを実装できますし、エンジニアがデータ分析を回せますし、PdMがMVPを自力で構築できます。「作りながら考える」というデザインの根源的なプロセスが、あらゆる職種に開放されつつあるのです。

これは単なる工数削減の話ではありません。デザイナーがエンジニアリングの領域に踏み込むことで、コミュニケーションコストは劇的に減少し、プロダクトの磨き込みスピードが上がります。職能の越境は、組織全体の価値創出速度を加速させる可能性を秘めています。

マネジメントの範囲は広がる

こうした超・T型人材化が進むと、それを管理するマネージャーの仕事も変わっていくでしょう。

ピープルマネジメント、チームマネジメント、パフォーマンスマネジメント、ケイパビリティマネジメント、プロジェクトマネジメント、プロダクトマネジメント——これらの領域そのものは変わりません。しかし、メンバーの業務範囲が広がるのに伴って、マネジメントの範囲も広がっていくと考えています。

たとえば従来のEMは、エンジニアの技術スキルとキャリア成長をサポートしていれば十分でした。しかし超・T型人材化したエンジニアは、デザインスキルやビジネス理解もスコープに入ってきます。マネージャーがサポートすべき領域も、必然的に拡張されるでしょう。

EMやVPは、この超・T型人材化を見越して、一人ひとりが取り残されないようにサポートしていく必要があります。全員がAIを使いこなし、全員が越境できるわけではありません。得意な人と苦手な人がいます。その差を埋め、組織全体の底上げをすることが、今後3〜5年で最も重要なマネジメント課題の一つになるのではないでしょうか。

職能組織は「こだわりの砦」

超・T型人材化が進めば、「エンジニア組織」「デザイン組織」という職能別の組織構造自体が不要になる可能性はあるかもしれません。しかし僕は、職能組織を維持する価値はなお大きいと考えています。

エンジニアやデザイナーという専門家だからこそ持っている「審美眼」や「意思」というものがあります。これを職能組織として定義しておくことで、組織全体のケイパビリティを維持する力が強まると感じています。

職能組織は、共通の専門言語を持つ仲間が集まり、互いの仕事を高め合う場でもあります。「このUIの間の取り方が気持ちいい」「このアーキテクチャは美しい」——そうした専門家同士でしか成立しない議論が、プロダクトの品質を底支えしているのではないでしょうか。

極端な話、みんな総合職にして、全員が事業の売上ミッションを持ったマイクロチームにしたらどうなるでしょうか。全社としての技術方針のこだわり、デザインのこだわりが薄まり、いずれAIに良くも悪くも支配された、他社とケイパビリティの差がない組織になってしまう可能性があります。

つまり、職能組織は「こだわりの砦」なのです。超・T型人材化と職能組織の維持は矛盾するように見えるかもしれませんが、実はそうではないと思っています。越境しつつも帰る場所がある。その帰る場所が、専門家としてのアイデンティティとこだわりを養う土壌になるのです。

「意思」こそが人間の存在意義

デザイナーの存在意義はその審美眼に。エンジニアの存在意義はより広義な技術的意思決定に。プロダクトマネージャーの存在意義はミッションやゴールの意思決定に。

突き詰めると、「意思」そのものが人間の存在意義ではないかと僕は考えています。

哲学者のHannah Arendtは著書『人間の条件』(1958年)の中で、人間の固有性は「行為(action)」にあり、それは予測不可能な新しいことを始める「自発性」に基づくと論じました。AI時代以前の著作ですが、この洞察は今まさに重みを増しているように感じます。

意思のないところに組織の意味はありません。James C. CollinsとJerry I. Porrasが『ビジョナリー・カンパニー』(1994年)で体系化したように、コア・バリューとコア・パーパスを持つ企業こそが長期的に繁栄します。MVVがなければ、それはただの営利団体であって、チームではないでしょう。ミッションがあるからこそ、そのミッションに共感する人が集まり、プロダクトが生まれます。

エンジニアリング組織も同じです。意思やこだわりがなかったら、それはただのリソースプールになりかねません。カルチャーギャップが生まれ、組織問題が多発する可能性があります。

AIにできないこと

AIは80点のデザインを出してくれます。ときには90点のコードを書いてくれます。しかしAIには「この80点を100点にしたい」と思う意思がありません。「ユーザーにこういう体験を届けたい」という願いがありません。

Wharton SchoolのEthan Mollick教授は著書『Co-Intelligence』(2024年)の中で、AIを「協調知性」として位置づけ、人間の判断・意志(human in the loop)の重要性を強調しています。AIが80点を出してくれるなら、組織は80点で前に進もうとするかもしれません。しかし、80点を受け取った上で100点に磨き上げる意思を持てるかどうか。その差を生むのは、テクノロジーではなく人間の意思ではないでしょうか。

その意思を持ち、AIを道具として使いこなし、プロダクトの品質を最後の1ミリまで磨き込む。それが、AI時代における専門家の仕事であり、人間の存在意義だと僕は考えています。


参考文献

  • Carl Benedikt Frey & Michael A. Osborne (2013) "The Future of Employment: How Susceptible Are Jobs to Computerisation?" Oxford Martin School
  • Thomas H. Davenport & Julia Kirby (2016) Only Humans Need Apply: Winners and Losers in the Age of Smart Machines Harper Business
  • David Guest (1991) "The hunt is on for the Renaissance Man of computing" The Independent
  • Tim Brown / IDEO — T-Shaped Stars: The Backbone of IDEO's Collaborative Culture (Chief Executive Magazine)
  • Hannah Arendt (1958) The Human Condition University of Chicago Press
  • James C. Collins & Jerry I. Porras (1994) Built to Last: Successful Habits of Visionary Companies HarperBusiness
  • Ethan Mollick (2024) Co-Intelligence: Living and Working with AI Penguin Random House

信頼が尽きたリーダーは何を失うのか

心理的安全性とリーダーシップ・キャピタルから考える「チームを率いる力」

リーダーの役割は、正しい判断を下すことだけではありません。
多くの人が「正しければ伝わる」と信じていますが、実際には正しさだけでは人は動かないという現実に何度も直面します。

たとえるなら、完璧なレシピ通りにカレーを作っても、食卓が温かくなるとは限らないようなものです。スパイスよりも大切なのは、誰とどんな空気で食べるか。
リーダーシップもそれと同じで、成果を支えるのは「正しさ」ではなく信頼です。

本稿では、ハーバード・ビジネス・スクールの心理的安全性の4段階モデル(エドモンドソン)と、経営学者ラム・チャランのリーダーシップ・キャピタル理論をもとに、信頼を失ったリーダーがなぜ孤立し、どうすれば再びチームを動かせるのかを考えていきます。

心理的安全性は「自由」ではなく「関わりの勇気」

心理的安全性とは、チームメンバーが罰や恥を恐れずに発言できる状態のことです。
しばしば「何を言っても許される自由」と誤解されますが、実際は互いへの敬意が前提の自由です。

心理的安全性は四つの層で成り立ちます。
「受け入れられる安心感」から始まり、「学べる安心感」、「貢献できる安心感」、「異論を唱えられる安心感」へと発展します。
この階段を上がるほど、チームの創造性は高まります。

ところが、会議で「上の判断は分かっていない」などと発言した瞬間、空気が止まることがあります。誰も発言しなくなり、議論は形骸化します。
沈黙が始まるとき、心理的安全性はすでに失われているのです。
つまりそれは「遠慮なく批判する場」ではなく、「安心して関われる場」だということです。

「正しいけれど信頼されない人」が生まれる構造

ラム・チャランのリーダーシップ・キャピタル理論によると、リーダーの力はポジションではなく信頼残高によって決まります。
この信頼残高は三つの要素で成り立ちます。
有能さ(Competence)、誠実さ(Character)、関係性(Connection)です。

私は、有能さだけが突出したリーダーほど危ういと感じます。誠実さや関係性を欠く有能さは、冷たい正論を生み、誰も共感できなくなるからです。
理性主義のリーダーは精密に判断しますが孤立しやすく、共感主義のリーダーは不完全でも人を動かします。
信頼とは、人が「あなたのもとで頑張りたい」と思えるかどうか。リーダーの本質はそこにあります。

信頼を支える三つの要素と、崩壊を招くたった一つの欠落

ハーバード・ビジネス・スクールのフランシス・フライ教授は、信頼を三角形(Trust Triangle)で説明します。
三つの頂点は、誠実さ(Authenticity)、論理性(Logic)、共感(Empathy)です。

人は、相手が誠実で、筋が通り、そして自分を理解してくれているときに信頼します。
このうち一つでも欠けると、信頼は崩れます。

私は、特に「共感」の欠如が致命的だと考えます。
論理がどれだけ正しくても、冷たく響く言葉は人の心を閉ざします。
信頼を壊すのは誤りではなく、温もりの欠如なのです。

チームが沈黙するとき、リーダーは孤立している

チームの崩壊は、派手な衝突ではなく静かな沈黙から始まります。
会議で質問が出なくなり、チャットに意見が書き込まれなくなる。
「どうせ言っても変わらない」という空気が蔓延するとき、リーダーはすでに孤立しています。

心理的安全性が損なわれると、誰もリーダーにフィードバックしなくなります。
リーダーは情報を失い、判断を誤り、チームの信頼残高は目に見えない速度で減っていきます。
この状態を、私は「有能な孤立者」と呼びます。
正しさで勝ち続けた結果、信頼を失い、誰も助けてくれなくなる。
それは、優秀さの副作用といえるかもしれません。

リーダーが信頼を取り戻す唯一の道

信頼を取り戻す方法は、驚くほど地味です。
正しさではなく、関係性を優先することです。

マイヤーらの研究(1995)では、信頼は能力・善意・誠実性の三要素で形成されると示されています。
ルウィッキとバンカー(1996)は、失った信頼を再構築するには「約束を守る段階」から積み直す必要があると述べています。
つまり、一度壊れた信頼は積み木のように一段ずつしか戻せないということです。

私は、リーダーがまず実践すべきは「課題を指摘する」ことではなく、「代案を出し」「自ら関与する」ことだと考えています。
批判は距離をつくり、関与は信頼をつくります。

リーナ夫妻(2006)は、信頼の回復には誠実さ・透明性・一貫性の三つを長期的に示すしかないと指摘しています。
私の実感としても、信頼の再構築には少なくとも一年ほどの一貫した行動が必要です。
時間とは、信頼の利息を積み上げるプロセスなのです。

信頼されるリーダーに共通する三つの態度

信頼されるリーダーに共通する態度は三つあります。
謙虚さ、誠実さ、共感力です。

謙虚さとは、自分の限界を認め、他者の知恵を借りる姿勢。
誠実さとは、言葉と行動が一致し、ブレないこと。
共感力とは、相手の立場を理解しようとする努力です。

これらは、マイヤーらの信頼モデルの要素にも対応しています。
コウゼスとポズナー(2017)は、模範的リーダーは「まず学び続ける姿勢で信頼を示す」と述べています。
謙虚さは弱さではなく、人を信じる力なのです。

誠実さはチームに予測可能性を与えます。
共感力は、理性と感情を結ぶ橋のようなものです。
正しさで導くリーダーは人を黙らせ、共感で導くリーダーは人を動かします。
信頼を生むのは後者です。

信頼を中心に据えたリーダーシップへ

心理的安全性はチームの呼吸であり、リーダーシップ・キャピタルはその血流のようなものです。
呼吸が止まれば組織は窒息し、血流が滞れば動けなくなる。

リーダーの仕事は、安全な場をつくり、信頼を運用することです。
正しさよりも温度を、論理よりも関係を。
信頼とは、未来への預金のようなものです。日々の小さな行動が利息となり、いつか大きな信用残高として返ってきます。

そしてその通帳には、リーダーの名前ではなく、チーム全員の名前が刻まれているということです。

参考文献

Edmondson, A. C. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350–383.

Charan, R. (2016). The Leadership Pipeline. Harvard Business Press.

Mayer, R. C., Davis, J. H., & Schoorman, F. D. (1995). An Integrative Model of Organizational Trust. Academy of Management Review, 20(3), 709–734.

Lewicki, R. J., & Bunker, B. B. (1996). Developing and Maintaining Trust in Work Relationships. In Kramer & Tyler (Eds.), Trust in Organizations. Sage.

Kouzes, J. M., & Posner, B. Z. (2017). The Leadership Challenge (6th ed.). Wiley.

Reina, D. S., & Reina, M. L. (2006). Trust & Betrayal in the Workplace. Berrett-Koehler.

Frei, F., & Morriss, A. (2020). Begin With Trust. Harvard Business Review.

絶えず灯り続けるアジャイルのこころ

お久しぶりです、KAKKAです。
ex-MIXI Advent Calendar 2023の最終日の記事として書かせていただきます。
今回は特に僕のアジャイルキャリアについて特に振り返って考える機会があったので、アジャイルキャリアについてフォーカスを当てて書きたいと思います。エンジニアも2足の草鞋でやっていましたが、この記事では技術的なお話はごっそり省略していてます。
もう会って話すこともできないし、文章で書いても届かない人向けに、それでも文章として残しておきたい感謝の気持ちを合わせてここに記したいと思います。

アジャイルキャリアスタートと最初のコーチとの出会い

僕のアジャイルのキャリアのスタートは新卒で入った会社である株式会社ミクシィ(現MIXI)からスタートしました。
このブログの過去記事でも書きましたが、2012年頃に全社的にアジャイル変革が行われました。その頃は日本でもまだアジャイル経験者は豊富ではなく、社内でも人材は非常に限られていました。よって現場のほぼすべてのチームは自習によるスクラムを始めざるを得ませんでした。
僕は当時から非常にプロダクト志向なエンジニアでして、自分一人の頑張りよりもチームのパフォーマンス向上のほうが重要であると思い、その中核を担うスクラムマスターの役割を積極的に担うように動いていました。もちろんこのタイミングで初めてスクラムマスターの役割を担うため、右も左もわかりませんでしたが、社内で一人だけ高原さん(仮名)という認定スクラムマスターのライセンスを保有し、様々なスクラムチームの支援を行っていた方がいました。僕もそのコーチにサポートしていただいていたうちの一人ですが、比較的僕のチームに重点を置いて、時間をかけてサポートしてくださっていました。様々なアドバイスが参考になったのはもちろん、僕自身の良い変化をしっかり観察してくださっており、スクラムマスターとして「良くなってきた」とフィードバックいただけたことは、とても嬉しかったとともに、自分に自信を持てた一言でもありました。

僕はこの頃はアジャイルリーダーとしてのキャリアは全く想像もしていませんでしたが、振り替えるとここでの経験や高原さんのサポート・評価が今の僕を作った原点と言っても過言ではありません。
この頃高原さんから受け取ったアジャイルのこころは、僕のこころにも確実に灯り、後に大きな炎へと成長することになります。

スクラムマスターの経験が予想外に生きた2社目

リクルートの内製での新規プロダクト開発に興味を持って、エンジニアとして転職をしました。この頃、リクルートでは事業の内製化に非常に力を入れており、同時にアジャイルの導入もこれから始まるという段階でした。案の定、前職のミクシィで見てきたように、チームにはスクラムが導入されるものの、経験者があまりいないという状況にまた遭遇しました。そしてこのチームでスタートアッププロジェクトの結果を出すにはしっかりとスクラムを再導入する必要があると感じ、少しでも経験値のある僕自身が抜擢され、スクラムマスターを担うようになりました。
幸いにも、認定スクラムマスター研修を受講でき、Certified ScrumMaster®のライセンスを取得したり、日本でも数少ない外部のアジャイルコーチにサポートしていただけたりと会社からの支援も重なり、とてもいいスクラムチームになりました。スクラムマスターとしてチーム全体からも非常に信頼していただいたのも印象的です。隣のチームのコーチを担当することもありました。また、外部のアジャイルコーチはこのチームは本当に良いチームだとフィードバックをいただけたのも良い経験で、「これが良いスクラムチームなのだ」と認識できたことで、理想のスクラムチームのモデルを頭に入れることができました。
ずっと後に気づきましたが、なぜこのチームが良いチームになったのかは、十中八九、アジャイルマインドセットを持った人たちが集まったスタートアップチームだから(クレイグラーマンの法則)、というのが答えだと思います。
非常に好きな環境だったのですが、わずか一年で去ることになりました。本当はもっとここで働きたかったのですが、スタートアップの本場シリコンバレーの、アーリーステージのスタートアップであるDrivemode, Inc.という会社にご縁があったためです。

シリコンバレーのスタートアップDrivemode, Inc.

Drivemodeには7年も在籍しており、ここでの学びを語りだすととても長くなってしまいます。このブログにもDrivemodeに関する記事はいくつか書いていますのでかなりシンプルに書きたいと思います。
入社時は社員2名、ファウンダー4名という本当に初期フェーズのスタートアップでした。会社全体が1チームで常に動いてました。スクラムマスターという役割はとても好きだったのですが、エンジニアと兼務するとどうしても時間的制約があったため、次こそはエンジニアに集中できるぞ、しかもメンバーはすごい人達ばかりだと、非常にワクワクしながら入社したのを覚えています。
スクラムの知識経験はあったのでそれを活かすバリューストリームの改善は入社直後からやったのですが、本当にそれくらいしかやっておらず、あとは会社全員が一丸となってプロダクト開発を必死にやっていたら勝手にアジャイルになっていたというのが非常に印象的でした。
シリーズAあたりから組織の成長痛を感じるようになりましたが、僕自身のアジャイルの知見をアップデートし、組織課題を提起することで変革のきっかけが作れました。そうこうしている間に2019年にホンダにEXITすることになります。
当時はこういった僕の課題提起の行動がメンバーから非常に煙たがられていたと思いますが、こういうキャラクターだったからこそ、ホンダのDX推進のリードを任していただけたのだと思います。

シリコンバレースタートアップから大企業のDX変革

この頃からアジャイル変革を大胆に行うようになりました(アジャイル変革はDX変革のうちの一部分です)。このころから何チームものアジャイルコーチ業務も本格的に行いましたし、丸3日のオリジナルアジャイルスクラム研修もスタートし、何度も何度も開催しました。研修は単なる座学ではなく、習熟度を上げるようにとても工夫しており、一度に受講できる生徒は10名程度に絞らざるを得ませんでしたが、この時点でも研修受講者やサポート対象者は100名を軽く超えていました。
これらの活動は少なくとも「うまくいっていない」という感覚はなく、DX変革のスコープで見ても確実に前進していることが自分でも感じられました。何と言っても変革対象組織の方々からとても信用をしていただける実感が日々大きくなっていったのです。
DX変革は一般的にとてもむずかしいもので、その成功の定義も曖昧ですが、成功率は10%程度だという情報もあります。そんな中でたった一人で数百名の組織のDX変革の結果を残せているのはとてもやりがいを感じられましたし、社内でも評価され、僕を信用してくれた人たちがついてきてくれ、組織としてDXを変革を行う流れにもできました。
しかしながら申し訳ないことに転職をすることになりました。

MIXIへの再入社と高原さんとの再開、モダンな組織へのアジャイル再導入

MIXI創業者である笠原さんから声をかけていただき、MIXIに再入社することになり、みてねのエンジニアリング組織のマネジメントに現在も従事しています。
MIXIは10年ほど離れていましたが、10年前に在籍していた懐かしのメンバーもいらっしゃり、ワクワクと自分を受け入れてくれるかの不安が混ざったような気持ちでしたが、入社後はその不安は一瞬で消え去りました。
また、僕のアジャイルキャリアのスタートを作ってくれた高原さんも同じ組織にいました。「スクラムもいいけどやっぱり稼がなきゃいけないと思ってエンジニアのフォーカスしている」ということでエンジニア職として活躍されていました。

みてねは非常にDeveloper Experienceの高い組織だなと感じてはいましたが、アジャイルに関してはなんかしら良い変革ができる余地がありそうだとも感じていました。入社後に真っ先に取り組んだ変革アクションはやはりアジャイル変革でした。構造を整える、研修を行う、コーチングサポートを行うという大手製造業でも行っていたことは、みてねでも通用するどころか、そこを丁寧にやることがDeveloper Experienceにクリティカルに効果が現れると確信しました。

組織に受け入れられ、灯り続けるアジャイルのこころ

高原さんは「今はエンジニア」と割り切っていましたが、僕が社内でアジャイル系のイベントを行うときには高原さんも積極的にサポートくださったりもしました。やはりアジャイルのマインドは絶えず灯っているのだなと僕は非常に嬉しく思いました。
そして徐々に高原さんがエンジニアから再びアジャイルコーチの役割に興味を持たれるようになってきました。リソース調整は必要だったものの、10年前に僕にアジャイルを伝承していただいた師匠とまた一緒にアジャイル変革できるのかと僕はワクワクしていました。



僕が入社してからスタートしたアジャイル変革は持続的に良い影響をもたらしていると実感しています(僕自身はきっかけを与えたのみで、すごいのは組織なのですが)。


丸3日のアジャイルスクラム研修を何度も受講したいと申し出る人がいること。

サポートしていた1スクラムマスターがめきめきと成長し、自信に満ち溢れた振る舞いをするようになっていったこと。またそれに従って周りのチームメンバーの信用が一回り大きくなっていったこと。

みてねの組織Valueを改変し、Be Agileを含められたこと。

チームメンバーにとってもスクラムの再導入が非常に好感触であること。
みてねのスクラム開発で私が感じたこと - mitene / FamilyAlbum Team
スクラムの本格導入による開発プロセスの変化@みてねプロダクト開発部 MERCHチーム - mitene / FamilyAlbum Team

これまでチームで悩んでいた人が、今めちゃくちゃいいチームだと笑顔で話していること。

研修などの活動がみてねの組織を超えて、全社に広がっていってること。

この経過を見ると、アジャイルという価値観は少なくとも衰退の気配を感じさせません。僕が理想モデルとして頭の中にある良いチームに近づいていっていると感じています。そしてそれはきっと高原さんも納得するものになってきていると思います。
経営判断としてもちろん常にアジャイルファーストであることはないのですが、それでも現在のところ価値がなくなる未来は見えていません。

しかしながら、高原さんがアジャイルコーチの業務に興味を持たれ、僕がまた一緒にアジャイル変革できるというワクワクは、叶わず今に至ります。

意外にも、一緒にアジャイル変革に携わることができなくてすごく惜しい、という気持ちはそれほどありません。なぜなら高原さん目指したいと思っていただろう状態に向かって僕らは着実に前進しているし、それを実現できるリーダーたちもいるからです。そしてこれらの変革のきっかけが僕だったとしたら、そのスタート地点を作ったのは高原さんなのですから。


10年前、高原さんから受け取ったアジャイルの灯火は、僕にも灯り、今では多くの人々にも灯り始めています。
少なくともみてねでは、この灯火が日々強くなってきています。
それが「世界中の家族のこころのインフラ」を実現するのにとても貢献してくれると思います。

あなたのその存在に感謝したいと思います。本当にありがとうございました。

スクラムにおける現実的最適手段の選択 - INVEST編

スクラムは、理解は容易、習得は困難

スクラムは、理解は容易ですが、習得は困難です。基礎を学び、ルールや推奨方法を理解した後でも、実際のプロダクト開発では理想通りに進まないことが多々あります。しかし、プロジェクトを前に進めることは非常に重要です。スクラムの理想を追求しすぎてプロジェクトが進まなくなると、スクラム自体がアジャイル変革を阻害する要因になる可能性があります。そのため、常に理想を目指しつつも、現実的な最適手段を選択し、その手段が心地よく感じられるようにすることが重要です。今回は、私がさまざまなチームを見てきた中で感じた「現実的最適手段」について考えてみたいと思います。

プロダクトバックログアイテムをINVESTにしたい

INVESTはスクラムのルールからは外れるものの、理想的なプロダクトバックログアイテムの形であることは言うまでもありません。しかし、クロスファンクショナルチームであっても、固定されたスプリント期間内で潜在的にリリース可能なプロダクトインクリメントを生み出すことは困難です。プロダクトバックログアイテムをさらに細分化することが難しくなったり、解決策が見つからなかったりすることもあります。この課題はどの組織でもよく遭遇するものです。

INVESTにならないとどうなるのか?

INVESTを満たさないプロダクトバックログアイテムには以下の問題が生じます。

スプリント期間内に完了しないプロダクトバックログアイテムが常態化する

この状態では、ベロシティの計測が機能せず、経験主義的な見積もりや生産性の可視化が困難になります。スプリントプランニングが困難になり、開発者の作業量が把握できなくなります。極端に忙しくなる場合もあり、スクラムチームとしてのサポートや生産性改善活動、品質の向上などに十分な時間を割けなくなり、レトロスペクティブの機能も低下してしまいます。さらに、アイテムの完了時期が分からないため、プロダクトオーナーは中長期的なプロダクト戦略を立てることも困難になります。

プロダクトバックログアイテムがタスクリストになり、スクラムチーム全員が興味を持てない

これも致命的な問題です。プロダクトバックログアイテムが細かくタスク化されてしまうと、クロスファンクショナルチームがリファインメントに時間を費やすことが無駄に感じられますし、プロダクト戦略の考えが難しくなります。スプリントの成果が分かりづらくなり、スプリントレビューの効果も低下します。

プロダクトバックログアイテムの開発にクリエイティビティを活かせない

開発者にとって、プロダクトバックログアイテムの開発には一定の情報が必要ですが、細かすぎる指示的内容が含まれていると、開発の魅力が減じてしまいます。受け入れ条件やタスクのリストが過剰に詳細化されると、開発者の創造性や自主性が制約されてしまいます。

考えられる原因

スクラムチームの開発者がクロスファンクショナルになりきれていない

バックエンドエンジニア、フロントエンドエンジニア、ハードウェアエンジニア、UXデザイナー、UIデザイナー、QAエンジニア、ディレクター、アナリスト、研究者、カスタマーサポート、セキュリティエンジニアなどの専門家が開発者としてスクラムチームに入ったら、クロスファンクショナルチームになりフロー効率が上がるというのは、この時点では妄想にすぎません。それぞれの専門的タスクには量の違いがあり、常に毎スプリント人的リソースのコントロールも難しいし、それぞれの専門的タスク量のコントロールもできないからです。開発者それぞれが専門性の幅を広げ、ボトルネックになりそうな専門領域のタスクをこなせる人を増やしていくことが重要になります。
QAのタスクはQAエンジニアが、コーディングをするのはソフトウェアエンジニアが、データ分析はアナリストが、などと暗黙的に役割が決まっていて、そこから買われないのであればとフロー効率は改善せず、結果的にベロシティが上がらず、プロダクトバックログアイテムがスプリント期間内に終わらないということにつながります。

プロダクトバックログアイテムの分割アイデアが思い浮かばない

もちろん現実的に分割が非常に難しいパターンもあるはずですが、これ以上分割はできないだろう、という思考停止状態が一番良くない状態です。分割できないから2スプリントにまたがってやろう、ということをゆるしてしまうことで、「今回も分割できないから1スプリントで完了しない前提で計画を建てよう」という思考に引っ張られてしまいます。

待ち時間が発生するタスクが隠れていて、生産性が上がり切っていない

ステークホルダーのレビューや、組織上必要な手続きなど、組織には様々なボトルネックが存在します。徹底排除うするのは難しいにしろ、このタスクの待ち時間を極限まで少なくすることで、開発者は時間を重要な作業に当てることができ、フロー効率も向上します。結果的にベロシティが向上するなども十分にありえます。ベロシティが上がっていけば、プロダクトバックログアイテムは開発者から見て絶対的に小さいと捉える事もできます。

現実的最適手段とは?

上記の問題は一時的には解決が難しいものが多いです。短期的な解決策が見つからない場合には、現実的な最適手段を選択することが重要です。私の経験から、以下の優先順位で目指すのが良いと考えています。

INVESTに優先順位をつける

繰り返しますが、INVESTが良質なプロダクトバックログアイテムを表現するための条件としては理想的なものであるという考えは変わりません。しかしながら、これを意識するあまり、上記のような致命的な問題につながるケースがよくあります。これらをなるべく避けながら、理想状態を目指すためにスクラムを組み続けることも非常に重要です。現実的最適手段を選択することにより、スクラムチームそのものをインクリメンタルに改善していくのが良いと考えます。

個人的な考えとして下記の優先順位で目指し続けるのが良いと考えています。

  1. Small
  2. Estimable
  3. Negotiable
  4. Testable
  5. Valuable
  6. Independent

Small(小さい、最適なサイズ)
小さいとはいえ、小さすぎることも非常に危険です。小さすぎることで、上記のような「プロダクトバックログアイテムがタスクリストになってしまい、スクラムチーム全員がプロダクトバックログアイテムの内容を知らないどころか興味を持てない」という問題が新たに発生します。
では最適なサイズとはどういうことか。下記のプロセスでできたプロダクトバックログアイテムであると考えます。

  1. まずはValuable, Independent, Testableを満たした状態のプロダクトバックログアイテムを作る
  2. サイズが大きすぎてEstimableではない、Estimableではあるが1スプリントで到底終わらない場合、ValuableとIndependentを妥協し、Estimableで1スプリントで終わらられる程度までアイテムを分割する

こうすることで現実的に分割可能になるはずです。繰り返しますが、あまり分割しすぎると上記のような「プロダクトバックログアイテムがタスクリストになってしまい、スクラムチーム全員がプロダクトバックログアイテムの内容を知らないどころか興味を持てない」という問題が新たに発生しますので、上記プロセスでやることが重要です。
それで、INVEST状態ではないと自覚し、それがどうすれば改善できるかを真剣に考え、レトロスペクティブなどの場で話合いましょう。この漸進的なマインドセットは決して忘れてはいけません。
このINVESTの優先順位における妥協が、現実的最適手段となるパターンをよく見かけます。これを選択することによって、

  • 1スプリントで完成させることができます
  • これにより、「経験主義的な見積もりと生産性の可視化」が可能になります
  • これにより、POが中期的なプロダクト戦略を考えやすくなります。また、スプリントプランニング第一に相当するWhatを決める際に最適な選択をできるようになります。そして、スプリントプランニング第二に相当するHowを決める際に、より具体的に時間軸の概念を含めて考えることができます。

みてねのエンジニアリング組織マネジメントをやり始めました

あれから

前回は退職ブログ「2015年から働いていたDrivemodeというシリコンバレースタートアップ(2019年にホンダグループ入り)を、先週に最終出社として退職をしてきました。」を書かせていただきました。あれから長らく有給消化期間となり、今月の12月15日までDrivemode社員でしたが、実際11月ごろから先行して働かせてもらっており、12月16日付けで無事正社員として入社いたしました。タイトルの通り、家族アルバムサービス「みてね」のエンジニアリング組織マネジメントをやります。

家族アルバム「みてね」サービスについて

すでに1500万ユーザーを突破し、日本国内ではママやパパの半数となる47.1%の方が利用しているという、結構とんでもないサービスになってきています。そして意外と知らない人もいるかもしれませんが、これMIXI社の事業なのです。僕は新卒でMIXI社にエンジニアで入社しましたので、約10年ぶりにMIXI社への出戻りとなります。
toyokeizai.net

きっかけ -笠原さんとの再開、組織を知る-

このみてねの事業責任者(PO)はMIXI社のファウンダーでもあり、考えるプロダクトは必ずヒットさせるということで天才と呼ばれている笠原健治さんです。幸い、10年前のおかしな若造であった(過去形?)僕のことを笠原さんは覚えててくださり、今年のある日突然「ランチに行きましょう!」とお誘い頂いたのがことの始まりでした。そしてランチの際に、今の僕のポジションの前任のエンジニアリング組織全体のマネジメントを行っている方も同席され、実質的に「採用のカジュアル面談」となったことをきっかけに興味を持ち、そのままトントン拍子で話が進み、入社させていただくことが決まりました。
少し、個人的に心を動かされたお話を書いていきます。

興味が湧いたポイント1: 組織規模

個人的にこの「みてね」は、初期開発メンバーがほぼ全員知り合いではあったので、リリース前の開発中から知っていましたが、その頃の「数名のスタートアップ」というイメージが強かったですが、なんと今の組織規模は50 -60名程度となっているということを上記ランチでお話したときに知り、驚いたことを覚えています。
僕のこれまでの経験で、数名〜30名程度の規模の組織はいろんな状態を見てきているし、更に数百名以上との組織も見てきましたし、それぞれの難しいところや面白いところも把握してきたつもりです。そんな中で思っていたこと、次にマネジメントという立場で一番興味がある組織規模はだいたい50〜100名かなぁという気持ちでした。
これはぼくの純粋な感覚ですが、組織マネジメント難易度が上がる人数規模のしきい値があるきがしています。

1. まずは1チームの限界が来る10名超え
2. 組織からアウトプットされることすべてを一人の人間が把握する限界が来る50名超え
3. その後はなだらかに難易度があがり、複数事業や部門のサイロ化が起こる、1000人超え

1と3は見てきましたので、2あたりの経験が必要だなとしみじみと感じていました。

興味が湧いたポイント2: 良い組織

シリコンバレーのスタートアップやホンダのDXなどで様々な活動をしてきましたが、組織マネジメントの観点で「これをやるべきだ!」と感じてきて、僕自身も実行してきたことや、これから実行しようとしていることが"マクロな視点で"大体できている良い組織でした。前任の方が本当に頑張ってきたんだなぁと非常にありがたい気持ちです。
え、じゃあこれから何をよくしていくのか?という疑問が湧いてくるかもしれません。今回の転職はそれを"探し求める"ということが目的の一つなのです。
自分が働く上で意識している大事なこととして、「今が非常に良くても完璧ではないのだから、今より良い状態を目指すのだ」というのがあります。これは組織やマネジメントに限らず、ソフトウェアでもUXでもUIもデータ分析でも何にでも共通して言えることだと思います。
ここではどこまで進化しても"完璧を目指し続ける"ことで、エンジニアリング組織の到達点を探索していきたいと思っています。
おそらく世の中的にはまだまだレガシー企業のDXという社会的課題は長年取り組まれることでしょうし、仮に僕自身がまたそれを携わるとしても、目指すべき到達点がアップデートできた状態で取り組みたいという思いがあります。

また、マクロな視点で出来てると思いきや、細部までちゃんとできていなかった、みたいなパターンはどの組織でもあることだと思います(DX変革でもここが本当にキーポイントでした)ので、マクロな視点を持ちつつも、解像度をできる限りあげて課題解決を推進していきたいと思います。

興味が湧いたポイント3: 笠原さんと日々一緒に働くという点

繰り返しますが、このみてねの事業責任者(PO)はMIXI社のファウンダーでもあり、考えるプロダクトは必ずヒットさせるということで天才と呼ばれている笠原健治さんです。一般的にもスタートアップや起業・事業の成功というものは成功確率が非常に低いというのはお察しの通りですが、こんな笠原さんと毎日働く機会は、宝くじを当てるよりもレアだと思います。取締役ではありますが、本当に日々、みてねのプロダクト開発に携わっています。

興味が湧いたポイント4: 事業が素晴らしい

世の中には様々なサービスやプロダクトがありますが、こんなにも事業自体が社会的意義のあるものもレアだと思っています(完全に個人の好みの問題かと思います)。
みてねのミッション「世界中の家族の"こころのインフラ"をつくる」
とても懐かしさを感じました。僕が新卒でMIXI社に入ったときはSNS mixiの全盛期でした。そのSNS mixiのプロダクトミッションが「世界中の人々のコミュニケーションのインフラ」(だったはず)。当時の僕はこれにとても賛同し、仕事に没頭していました。みてねのミッションもまた、その熱さを思い出させてくれるものです。
こころのインフラというものはかなり幅広くて、例えば家族で子供の写真を共有しコメントし合うことで和やかな気持ちになるとかそういうものだけではなく、こころのインフラには「安心」という要素も含み得るものです。子供の危険な状態を察知する(みまもりGPS)、危険な状態になったときに助けてくれる機能(コールドクター)があるなど、この生存のに関する危機を未然に防ぐという”安心”も提供しており、昨今の猛暑での保育園バス置き去り事故などにひどくショックを受けていた僕としては、こういったミッションを持つことは本当に世のためになりつつも、家族のミライを守ることにもつながるのだなぁと感じています。

興味が湧いたポイント5: タイミングと会社の馴染みとポジション

前任のエンジニアリング組織のトップマネジメントを行っていた方が転職するということで、その方自らが後任を採用するというかなり特殊なケースでした。こういうしっかりしたお仕事をされてきたおかげで今の良い組織があるのは間違いありません。だからこそこのタイミング・機会は他にないだろうと思いました。実際外資エンジニアリングマネージャーやCTOの求人はあるにはあるのですが、上記ポイントも同時に満たすものなんてまぁないと思いましたし、しかもそれが自分のよく知っているMIXIでできるというのが良かったなと思います。

「みてね」を支える組織について

ここまで個人的なお話ばかり述べさせていただきましたが、僕自身の責務を果たすためにもみてねの組織についても紹介しておきます。
より良いものにどんどんアップデート予定ですが、みてねの採用サイトはこちら。
team.mitene.us

事業成長の真っ只中、会社からの期待にも答えなければなりません。より一層組織を強化すべく、しっかりと採用枠を確保しに行っています。まだ未確定な枠もあり、ちょっと先走ってますが、すでにJob Descriptionまで公開させていただいてます。この枠に限らずとも、ぜひカジュアル面談からでもお話させてください!
docs.google.com


【家族アルバム みてね】CXエンジニアリングエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】シニアスクラムマスター - MIXI GROUP RECRUIT
【家族アルバム みてね】QAエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】Engineering Manager - MIXI GROUP RECRUIT
【家族アルバム みてね】バックエンドエンジニア(プロダクト開発) - MIXI GROUP RECRUIT
【家族アルバム みてね】iOSエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】Androidエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】 Rails エンジニア(Data Engineering グループ) - MIXI GROUP RECRUIT