Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa...
Search
Yoshiki Iida
July 20, 2024
Technology
7k
17
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
Yoshiki Iida
July 20, 2024
More Decks by Yoshiki Iida
See All by Yoshiki Iida
スタートアップでゼロからマネジメント文化を作ってきた話 / How I built a management culture from scratch at a startup
yoshikiiida
0
990
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
2
39k
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
5
13k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
1k
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
1.4k
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
12
4.2k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
yoshikiiida
4
2.2k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
8
4.7k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
6.5k
Other Decks in Technology
See All in Technology
「どのログを見ればいい?」 から始めた サーバーレス障害解析
y_waka1
1
110
新機種発売前に見直そう!端末移行で再ログインが要るアプリ・要らないアプリは何が違うのか 〜シームレスに再開できる設計と実装〜
zozotech
PRO
0
220
AIによるクリエイティブ生成を行う上での試行錯誤
plaidtech
PRO
0
160
データ_AIの事業の勝敗をわけるもの
nek0128
1
460
Vibe Coding で作ったプロダクトをどう安全に動かすか / How to Safely Run Products Built with Vibe Coding
glidenote
0
330
CLIライブラリ開発を支える技術
htnabe
0
140
目の前の楽しいが人生を変える - コミュニティの螺旋の歩き方と楽しむコツ / change your life
soudai
PRO
5
650
エージェントはローカル、検証はMicroVM — Lambda MicroVMsでつくるServerless CI
fujioka6789
3
510
人間はどの意思決定を手放せるのか
kawasima
15
7.5k
.NET WebAssemblyで実現するクライアントサイドAI推論:NuGetからViteまで、2つのエコシステムを繋ぐビルド戦略
yamachu
0
260
Goodbye ShellScript, Hello File-based App
shunsock
0
400
30座EKS, 180次升級淬煉的EKS Upgrade Skill 的歷程
eric8230
0
190
Featured
See All Featured
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
700
From π to Pie charts
rasagy
1
370
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
730
Paper Plane (Part 1)
katiecoart
PRO
2
11k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
430
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
460
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
230
Typedesign – Prime Four
hannesfritz
42
3.2k
Optimizing for Happiness
mojombo
378
71k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Transcript
1 ©2024 Loglass Inc. スタートアップにおける組織設計と スクラムの長期戦略 2024/07/20 #scrumkanazawa Yoshiki Iida
2 ©2024 Loglass Inc. Profile Yoshiki Iida (@ysk_118) 株式会社ログラス 開発本部
プロダクト開発部 部長 シニアエンジニアリングマネージャー 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、 プロダクトオーナーを経て、2019年から執行役員として開発部門の統括を行 う。現在は株式会社ログラスにてソフトウェアエンジニアとしてプロダクト開発 に携わったのち、1人目のエンジニアリングマネージャーとして事業と組織の成 長にコミットしている。
3 3 ©2024 Loglass Inc. 企業価値を向上する 経営管理クラウド
4 ©2024 Loglass Inc. ログラス公式Xがんばっています!フォローしてください! https://twitter.com/LoglassPrdTeam
5 ©2024 Loglass Inc. 今日最も伝えたいこと
6 ©2024 Loglass Inc. 事業に貢献し続けられる組織を作りたい! …でも誰がやる?
7 ©2024 Loglass Inc. 事業に貢献し続けられる組織を作りたい! …でも誰がやる? マネージャーがリーダーシップを 発揮すべきだと思うよ
8 ©2024 Loglass Inc. 目次 • 前提となるスクラムチームとマネージャーの関係 • プロダクト開発と人事評価 •
マネージャーの人件費 • 組織の取り組みのリードタイム • 組織のスケールについて • 組織設計は誰がリードすべきか
9 ©2024 Loglass Inc. 前提となるスクラムチームと マネージャーの関係
10 ©2024 Loglass Inc. 今日扱うスクラムチームのコンテキスト • 自社プロダクト開発 • スタートアップ的な環境 ◦
まだ小回りの効く組織規模で、変化が激しい
11 ©2024 Loglass Inc. スクラムの考え方(理想) • スクラムはチームの自律性を重視する ◦ 自己組織化し、チームで意思決定できるようにする ◦
チームは最も価値の高いものから取り組み、それを邪魔するものは 取り除く必要がある • スクラムにマネージャーという役割はない ◦ 誰かにマネジメントされずともチームはセルフマネジメントできる ◦ チームの障害になるような影響はマネージャーであれど取り除かれ る
12 ©2024 Loglass Inc. スクラムとマネージャーの関係性の現実 マネージャーは会社の仕組みの中でチームに対して少なからず影響力を持っ てしまう • 会社の人事評価システムがあれば、スクラムチームのメンバーに対し人事 的な影響力を及ぼす
• 予算管理や労務管理など、会社としてガバナンスを効かせるための仕組 みにおいて影響力を及ぼす • 他にもいろいろ・・・ → 「本質的なプロダクト開発以外の組織構造上の力学」がチームに働くことを 受け入れた上で、どうコントロールするか?を考える必要がある
13 ©2024 Loglass Inc. プロダクト開発と人事評価
14 ©2024 Loglass Inc. プロダクト開発のアウトカムを定量的に扱うことの難しさ 人事評価においてプロダクト開発のアウトカムを扱う際、 機能リリース(アウトプット)が売上(アウトカム)に繋がった と言えたら定量で成果を比較できて良さそうだが・・
15 ©2024 Loglass Inc. プロダクト開発のアウトカムを定量的に扱うことの難しさ 人事評価においてプロダクト開発のアウトカムを扱う際、 機能リリース(アウトプット)が売上(アウトカム)に繋がった と言えたら定量で成果を比較できて良さそうだが・・ 現実には、 「この機能によっていくらの売上が立ちました」
という因果を説明することは難しい😢
16 ©2024 Loglass Inc. プロダクト開発のアウトカムを定量的に扱うことの難しさ 難しさ1: 売上に寄与するプロダクト以外の多くの貢献者 • マーケティングの新しい施策が成功し見込み顧客と出会うことができた •
インサイドセールスが粘り強くコンタクトしアポイントを獲得できた • フィールドセールスが長期的なプロダクトの構想含めて魅力的なプレゼンを行い顧 客の心を掴んだ • 法務が迅速な手続きで契約手続きを行い信頼感を得ることができた • カスタマーサクセスが勝ち取った信頼で契約更新の際にアップセルできた • ・・・ → 機能的に不足があっても売れてしまうこともある
17 ©2024 Loglass Inc. プロダクト開発のアウトカムを定量的に扱うことの難しさ 難しさ2: プロダクト内部の複合的要因 • 複数の機能を連携させることでの価値 •
デザインによって生み出されている利便性
18 ©2024 Loglass Inc. プロダクト開発のアウトカムを定量的に扱うことの難しさ 会社全体の中において特定の機能開発部分のみが及ぼす アウトカムを定量的に算出することはやはり難しい。 スクラムのようなチーム開発をしている場合、 個人単位の定量的な成果に細かく分解することは より現実的ではない。
では、どうするか?
19 ©2024 Loglass Inc. 人事制度の定義と必要性 では、どうするか?の前に、定義と必要性を整理しておく。 「そもそも人事評価って何?」 「人事評価って必要なの?」
20 ©2024 Loglass Inc. 人事制度の定義と必要性 人事評価とは、 「業績向上のために行うフィードバック」 • 個人の成長が業績を作り出す •
課題に向き合い、良い点をさらに強化するためのもの • 報酬決定のインプットにもなるが、フィードバックの側面がよ り重要
21 ©2024 Loglass Inc. 人事制度の定義と必要性 人事評価がない場合、 • 成長機会・モチベーション管理が個人まかせやチームまかせ • 報酬決定のための基準化されたインプットがない
◦ 給与が変わらない ◦ もしくは給与が一部の意思決定者の一存で決定される という状況が発生する。
22 ©2024 Loglass Inc. 人事制度の定義と必要性 • 高いレベルのセルフマネジメントを求める • 昇給などを考慮しなくてもいいくらいの高待遇を実現できる •
組織を大きくせず少数精鋭で事業運営していく といったスタンスの会社であれば人事評価は必要ないかもしれない。 しかし、個人の育成や組織そのものの拡大や成長を見込んでいる場合 には人事評価を整備したほうがいい可能性もある。
23 ©2024 Loglass Inc. 人事制度の定義と必要性 • 人材を育てられる組織を作りたい ◦ 内部で育成できる能力を持つことで組織拡大の選択肢を増やせる •
事業成長に伴って昇給を実施していきたい ◦ プロダクトが売れる状態になっていないのに人件費が肥大化していく状態は 避けたい ◦ 特にスタートアップでは、初期フェーズで年収を下げて参画するケースがあ る。この場合、事業成長に伴い昇給を実施していくことになる。 • 組織拡大に伴う権限委譲を実施したい ◦ 組織拡大を行う場合、評価システムのスケールが必要になる → この3点を想定するならば「人事評価」の仕組みを整えた方が良い
24 ©2024 Loglass Inc. 人事制度を整える 人事制度の考え方 kaneda blog / 人事制度の構造
https://kaneda3.com/2022/02/22/structure-of-personnel-system/ 目標管理、等級、評価、報酬、それぞれの 制度の位置付けと関連性を考慮して全体の 制度設計を考える。 ※金田宏之さんのブログが非常に充実して いるので関心のある方はご一読ください。
25 ©2024 Loglass Inc. 人事制度を整える kaneda blog / スタートアップ 3社に見る「人事評価がない人事制度」とは?
https://kaneda3.com/2024/05/28/%e3%82%b9%e3%82%bf%e3%83%bc%e3%83%88%e3%82%a2%e3%83%83%e3%83%973%e7%a4%be%e3%81%ab%e8%a6%8 b%e3%82%8b%e3%80%8c%e4%ba%ba%e4%ba%8b%e8%a9%95%e4%be%a1%e3%81%8c%e3%81%aa%e3%81%84%e4%ba%ba%e4%ba%8b%e5%88%b6/ 実は「人事評価がない人事制度」というグラデーションもある (Nstock社、NOT A HOTEL社、Ubie社の事例)
26 ©2024 Loglass Inc. 人事制度を整える 私の意見は、 「評価を価値あるものにすることが マネージャーとして非常に重要」
27 ©2024 Loglass Inc. 人事制度を整える 私の意見は、 「評価を価値あるものにすることが マネージャーとして非常に重要」 • 事業が伸びなくて昇給原資が少なかったとしても業績向上のため
フィードバックはしなければいけない • 評価のフィードバックが価値のないものだと思われたら、目標も等 級も形骸化する • 形骸化した状態で将来昇給しても人は果たしてついてくるだろう か?
28 ©2024 Loglass Inc. 人事制度を整える 私の意見は、 「評価を価値あるものにすることが マネージャーとして非常に重要」 • 事業が伸びなくて昇給原資が少なかったとしても業績向上のため
フィードバックはしなければいけない • 評価のフィードバックが価値のないものだと思われたら、目標も等 級も形骸化する • 形骸化した状態で将来昇給しても人は果たしてついてくるだろう か? → 組織に対して大きなレバレッジが効く投資と捉える
29 ©2024 Loglass Inc. スクラムチームでどうやるか? • 個人ごとの貢献度を定性的に扱うしかない ◦ 自己評価でも貢献度を書いてもらう •
最終的には”納得解”を高めるための情報収集をマネージャーが自ら 動いて行う ◦ チームの活動をすべて見ていればマネージャー自身で一定の高 い精度の納得解を出せる ◦ チームの活動の一部しか見ていなければ、個別に評価対象者につ いてチームメンバーにヒアリングを行い、フィードバックの質を高 める
30 ©2024 Loglass Inc. 評価を価値あるものにするために 人と向き合い手厚くフィードバックする。人の人生と向き合う。 • 手厚い is not
褒めまくる • ポジティブもネガティブも全力で相手のためになることをフィード バックする 「GREAT BOSS」の中では、「徹底的なホンネ」と表現 されている。 「徹底的なホンネ」 = 「心から気にかけ」ながら「言いに くいことをズバリいうこと」 キム・スコット. GREAT BOSS(グレートボス) ―シリコンバレー式ずけずけ言う力 . 東洋経済新報社.
31 ©2024 Loglass Inc. 評価を価値あるものにするために 評価へのフィードバックの収集 • 一方的なコミュニケーションにしない • しかし、交渉による変更は絶対しない(形骸化するから)
32 ©2024 Loglass Inc. 技術力の評価 アウトカムの評価の考え方は前段の通り。 では、アウトプットの技術力はどう評価する? 高い技術力には相応の対価が払われるべきではないか? という問いについて。
33 ©2024 Loglass Inc. 技術力の評価 アウトカムの評価の考え方は前段の通り。 では、アウトプットの技術力はどう評価する? 高い技術力には相応の対価が払われるべきではないか? という問いについて。 →
基本的には品質の観点で整理できると考えられる
34 ©2024 Loglass Inc. 技術力の評価 「技術的難易度が高い」問題について • 時間が無限にあり • 個人の探究心が無限に継続できれば
• いずれは解決できるはず 一方、現実世界では • 期日や予算があり、個人のモチベーションも有限 • したがって、その制約の中でより質の高い解決を実行できることが 技術力の高さと考えられるのではないか
35 ©2024 Loglass Inc. 技術力の評価 質の高い解決 • 長期でも価値を発揮し続けられる解決策 ◦ その上で短期的にもコストを下げたり、早く解決できるアイデア
質が高いとは言えない解決 • 短期では要件を満たすが、、、 ◦ すぐに追加改修が必要となる解決策 ◦ その後負債となり周辺実装の開発生産性が下がるような解決策 ◦ 維持費用が重荷になる解決策
36 ©2024 Loglass Inc. 技術力の評価 プロダクトマネジメントでも近い考え方がある 技術力に置き換えると、 • はやい •
やすい • 変わらぬおいしさ を実現できる解決が質が高い、と言える。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえにな るチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/product-management-rsgt2023?slide=160
37 ©2024 Loglass Inc. 技術力の評価 - 変わらぬおいしさとは何か? つまるところ、内部品質をどう評価するか?という話 • いくら低コストで解決しようが、素早く解決しようが、
内部品質が伴わなければ良い解決にはならない • 内部品質→外部品質→利用時の品質 ◦ ソフトウェアの製品品質モデルでも言われる通り、 内部品質が最終的にはユーザーに影響を及ぼしてしまう 直接的なビジネスインパクトに置き換えることは難しいかもしれないが、定性的に でも発案や実装貢献を収集し、行動評価に組み込むことで技術力を評価する
38 ©2024 Loglass Inc. 技術力の評価 - 実際の取り組みの例
39 ©2024 Loglass Inc. マネージャーの人件費
40 ©2024 Loglass Inc. 直接プロダクト開発をしないマネージャーの人件費をどう捉えるか? 会社組織において個人にパフォームしてもらうためにマネージャーが考え るべきことを述べてきたが、スクラムチームにはどうやっていい影響を及 ぼすか? いい影響があるのであれば、マネージャーの人件費も妥当な投資と言える はず。
逆に言えば、チーム以上の抽象度の高いミッションを持たないマネー ジャーを増やすと開発組織のROIは純粋に悪化する
41 ©2024 Loglass Inc. 直接プロダクト開発をしないマネージャーの人件費をどう捉えるか? - 余談 テスラの直労費の話 “マスクの会社では、チームは通常50人以上でスタートしますが、その後はリーダーを置かずに、5人以下のグループ に自己組織化します。目標は、リーダーやマネージャーを置かずに、100パーセントのスタッフが直接製品に携わるこ
とです。” “管理者を待つような承認は、ソフトウェアによって自動化されています。ソフトウェアがマネジメントに取って代わりま した。このソフトウェアは、「デジタルセルフマネジメント」と呼ばれ、ほぼ100パーセントのスタッフがエンジニアとな り、日々製品を直接改善できるようになりました。 ファイナンシャルエフィシェンシー(投資効率)ということで、財務的な効率を上げる唯一の方法は、やはり給与が高い 管理者を省くことです。テスラでは、こういった管理者をソフトウェアに置き換え、実際に管理者と呼ばれる人たちも 現場で作業をすることで製品の価値を向上することが100パーセントできるようになりました。” 「イーロン・マスクに社員が直接質問」「プロジェクトは自分で選ぶ」テスラが開発チームにあえてリーダーを置かない理由 https://logmi.jp/tech/articles/327164
42 ©2024 Loglass Inc. 直接プロダクト開発をしないマネージャーの人件費をどう捉えるか? 一方、マネージャーを廃止し、その後復活させたという事例もある。 (FYI. Google, サイボウズ) 言えることは、管理をするだけのマネージャーはいらない、ということ。
特に、対スクラムチームの観点では、チーム間のアラインメントや、チーム を超えた組織での進化をどう作り出すか?に着目すると良い。 Google re:Work - 優れたマネージャーの要件を特定する https://rework.withgoogle.com/jp/guides/managers-identify-what-makes-a-great-manager#learn-about-googles-manager-research
43 ©2024 Loglass Inc. 直接プロダクト開発をしないマネージャーの人件費をどう捉えるか? 「エッセンシャルスクラム」の第13章はマネージャーの章になっている。 “自己組織化されたチームがいる世界で、マネージャーの居 場所はあるのだろうか? もちろん存在する。 〜〜〜
マネージャーはチームを形作る。境界を定めたり、先に進む ための明確なゴールを定めたり、チームの体制を決めたり、 チームの構成を変更したり、チームに権限を持たせたりと いったことだ。” Kenneth S. Rubin. エッセンシャル スクラム (p.213-215). 翔 泳社.
44 ©2024 Loglass Inc. 直接プロダクト開発をしないマネージャーの人件費をどう捉えるか? スクラムチーム プロダクト プロダクトが1チームで見る には大きすぎる場合は複数 チームで見る必要がある
スクラムチーム プロダクト スクラムチーム 複数チームでプロダクトの全体を カバーし、全体の価値にも向き 合えている状態であれば問題な い スクラムチーム プロダクト全体の価値 スクラムチーム 複数チームに分かれてプロダク ト全体の価値に向き合えている かがわかりにくくなってきたら対 処が必要 担当領域内での 価値 担当領域内での 価値 チームでは解決できないような抽象度の高い課題に向き合い、 チームのパフォーマンスをひき出すことができれば、 マネージャーの人件費の価値があると言える。
45 ©2024 Loglass Inc. 組織の取り組みのリードタイム
46 ©2024 Loglass Inc. 組織全体の持続性を作るための施策はどのようなものがあるか? 事例:専任スクラムマスターを置いたらどうなるのか?という施策 背景課題: Zuziの言うレベル1のスクラムマスターはチームがよしなにやれている、しか しレベル2以上のスクラムマスターの振る舞いができていない場合、横断的な取り組み はマネージャーがボトルネックになってしまう
「SCRUM MASTER THE BOOK」ではスクラムマスターのレベルを3段階で 定義し、 1. 私のチーム 2. 関係性 3. システム全体 という順に影響を与えるスコープを広げていく話が書かれている。 Zuzana Sochova. SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極 意――メタスキル、学習、心理、リーダーシップ. 株式会社 翔泳社.
47 ©2024 Loglass Inc. 組織全体の持続性を作るための施策はどのようなものがあるか? 事例:専任スクラムマスターを置いたらどうなるのか?という施策 実施に際して検討したこと • 専任スクラムマスターを置くことで、この状況を回避し、組織的な進化を作り出すこ とができていればそのコストは必要経費と言える
◦ 組織全体で見た時のケイパビリティが増加しているかどうか? • どのタイムスパンで見るかは施策ごとに見積もるべきだが、その間にその施策に よって組織の進化を生み出せたのか?を検証する • 専任スクラムマスターは当初半年を見込んでいた
48 ©2024 Loglass Inc. 組織全体の持続性を作るための施策はどのようなものがあるか? 事例:専任スクラムマスターを置いたらどうなるのか?という施策 • 短期的にはチームに良い影響があった • 現在約半年が経過し、スクラムからFASTというス
ケーリングフレームワークの検討をプロダクト組織全 体で推進している これに限らず、採用なども含めて組織系の施策は 半年くらいのリードタイムを見込んで仕込みをしないと いけないということ 専任スクラムマスターを置くまでの思考過程と置いてどうなったか? https://zenn.dev/loglass/articles/95f367d2a6ced7
49 ©2024 Loglass Inc. 組織全体の持続性を作るための施策はどのようなものがあるか? 事例:専任スクラムマスターを置いたらどうなるのか?という施策 短期でチームに良い影響があった 具体のお話しは、 Scrum Fest
Sendai 2024 でお話しさせていただく予定です。 https://confengine.com/conferences/scrum-fest-sendai-2024/proposal/20238
50 ©2024 Loglass Inc. 組織のスケールについて
51 ©2024 Loglass Inc. スケールが必要かどうか? スケールは最終手段といわれることもあるが・・ 組織拡大が必要かどうか?はビジネスモデル次第ではある 組織拡大の投資によってビジネスが大きく成長する見込みがあ るのであれば組織拡大によって事業拡大するという戦略になる
52 ©2024 Loglass Inc. 事業成長が組織成長を追い越す • 事業的な大きなモメンタムが生まれると、組織拡大の速度よりもプロ ダクトへの期待が上回る ◦ お客様が増えて要望が盛りだくさん!の状態
• したがって開発の生産力を増強し期待を埋める動きを取らなければ いけない ◦ 期待を下回ったままの状態だとユーザーの離脱に繋がる 組織の成長 事業の成長
53 ©2024 Loglass Inc. 事業成長を読みながら、非連続な組織成長を作り出していく 組織の未来を読み、成長を作り出していくことは非常に難しい • 連続的な成長 ◦ 組織がこう動いていったら半年後こうなるから、今のうちにこれをしてお
いたほうがいいな・・という嗅覚 ◦ 問題が起きてから対処するのではなく、問題の火種を察知して手を打つ ▪ 特にスタートアップにおいては問題が同時多発的に発生することが あるので致命傷にならないように • 非連続な成長 ◦ ゲームチェンジとなるような非連続な成長も考える ◦ 新卒採用、海外採用、など・・ ◦ 想像できなかったような成長機会を作り出すことができる可能性
54 ©2024 Loglass Inc. 組織設計は誰がリードすべきか
55 ©2024 Loglass Inc. 組織設計はマネージャーがリードすべきか?現場からリードすべきか? 結論、マネージャーがリードすべき • マネジメントも偶有的複雑性への対処にすぎない • 現場はプロダクトの価値という本質的複雑性に向き合ってほしい
• 組織としてどういう構造になっていれば最もパフォームしやすいの か?今だけでなく持続性も考慮すると何をしておかなければならな いのか?はこれまで述べてきたように非常に複雑で難易度が高い • 全体最適としてパフォームしているか?についてはマネージャーが 責任を持つべき
56 ©2024 Loglass Inc. マネジメントも偶有的複雑性への対処にすぎない https://speakerdeck.com/itohiro73/huitiyakai-fa-kara-horupurodakutokai-fa-he-gu-ke-jia-zhi-hexiang-kihe-isok-kerutiao-zhan-at-itohiro73-number-kai-fa-sheng-chan-xing-con-findy?slide=16
57 ©2024 Loglass Inc. 組織の探究者でありたい 様々な観点からどう考えて何をすべきなのかを述べてきたが、最終的に はやりたいことを一言で表すと「価値を生み出している、ユーザーの課題 を解消できている、社会をよりよくしていけているという効力感を持って 働ける環境を作りたい」ということに尽きる。 組織は生き物のように、環境の変化に対して適応しないとどんどん元気が
なくなっていってしまう。スタートアップであればさらに過酷な環境でチャ レンジすることを選択した人の集まりとも言える。そんな難しいチャレンジ を成功させられたらカッコいいと思っているだけかもしれない。 マネジメントは大変なこともあるが、 好奇心をもって探究を楽しむことができればいい組織を作れると思う。
58 ©2024 Loglass Inc. 事業に貢献し続けられる組織を作りたい! …でも誰がやる? マネージャーがリーダーシップを 発揮すべきだと思うよ
59
60 ©2024 Loglass Inc. Appendix
61 ©2024 Loglass Inc. まとめ プロダクト組織 未来の進化した プロダクト組織 リードタイムかかる アウトプット
アウトカム チーム 個人 コストかけてでも フィードバックを 価値あるものにする マネージャー 全体最適を考え続ける 未来を見据えた 制度設計・運用 人事制度