わかりやすい正解を捨てて、 コトに向き合う スクラムフェス金沢2024 スポンサーセッション

2 自己紹介 Leaner Technologies リーナーテクノロジーズ @yusuke_kokubo ソフトウェアエンジニア from 2021/01 金沢は人生二度目です

このセッションについて

4 このセッションでリーナーについて知って欲しいこと ● リーナーDevの文化が他の会社にはないユニークな文化であること ○ エンジニアの多様なキャリア ○ 非エンジニアとの協力関係（Biz<>DevMix） ○ エンジニアも非エンジニアもみんなが同じコトに向かっている

5 このセッションで話さないこと ● 事業の紹介 ○ ざっくり言うと、調達購買のtoB SaaS スタートアップ ○ 興味ある人はブース/Discordへどうぞ ● よくある会社紹介 ○ 社員60名くらい（エンジニア20名弱） ○ 興味ある人はブース/Discordへどうぞ

6 このセッションで伝えたいこと ● 人もチームも大きなコトに向かっている時が一番成長する ● 自分のキャリアのためだけにツールやプロセスやプロダクトと向き合っ ても大したアウトプットは出ない ● 必要なのは「どんなコトに向かうのか？」「なぜそのコトに向かうの か？」という解くべき問いの設定をチームみんなで一緒に考えて立ち向 かうこと ● それさえできればアウトプットの質が上がり、適切なツールやプロセス を選べるようになり、個人のキャリアもついてくる

前振り

8 皆さんはどんなキャリアを目指してますか？ ● CTO、VPoE、PdM、EM、スタッフエンジニア、プロダクトオーナー、 スクラムマスター、アジャイルコーチ、… ● あなたはなぜそのキャリアを目指してますか？ ● どのキャリアでも何かしらのマネジメント(or リード)は求められるよね ○ （特殊なポジションで仕事してない限り）

ところで、 最近のマネージャー業務は 難しくなってきてる

10 マネージャーの業務は難しすぎる ● プロジェクトやプロダクト、ピープル、チーム、組織のマネジメントは ますます複雑になり、難易度を増している ● マネジメントをマネージャーと呼ばれるロールの人だけに任せるには負 荷が高過ぎる状況になっている ● 多くのケースではマネジメント業務は属人性が高く、再現性のないマネ ジメントになってしまっている

マネジメントは難しいので ふつうのマネージャーは 効率的で楽な方法を求める

12 マネージャーは安易なマネジメントに流されやすい ● 思考停止して流された結果「わかりやすい正解」に行き着く ○ わかりやすいキャリアパスと評価制度 ○ わかりやすい職能分割と責任の所在 ○ わかりやすい開発手法と生産性指標 ○ わかりやすい目標設定

13 たとえば、こういうわかりやすさ1 職能間でわかりやすい境界線を引く ● エンジニアはつくる人 ● PdMは考える人 ● デザイナーは見た目を綺麗にする人 ● CSはサポートする人 ● セールスは売る人 → 職能間でこぼれ落ちるボールは無視 こぼれ落ちるボールを拾う労力が高いのでみんなやりたがらないし評価 も難しい

14 たとえば、こういうわかりやすさ2 開発生産性の評価をベロシティとFour Keysだけで測る → アウトプットを出すことがエンジニアの仕事なので、アウトカムは無視 「作りすぎのムダ」が多い人ほど評価される

わかりやすいマネジメント の結果、メンバーもわかり やすさを求めるようになる

16 たとえば、こういうわかりやすさ3 自分がどの業務にアサインされるかはマネージャーに委ねる 自分の役割、発揮できる価値はすべてマネージャーに評価してもらう 「自分は自分に与えられた仕事を全力でがんばります！」 → 普段関わらない人は無視 ※ 自分の存在価値を他人に決めさせる = 生殺与奪の権を渡してる （ジュニアな人が言うならよいけど...）

17 たとえば、こういうわかりやすさ4 プロダクトビジョンやプロダクトバックログの優先順位はPdM・P.O.が適切 に決めてくれるだろうと期待する → 相談されたら考えるけど、自分からやることはない 職種・職能・役割の違いが壁となってお互いを分断している

時間チェック ここまで10分の予定 残り10分

19 何も疑問に思わずそういうものだと思っていませんか？ ● 本当に必要な仕事は、わかりやすい境界線の狭間にある ○ しかしわかりにくいので無視されがち ● なぜ「わかりやすさ」を求めてしまうのか？ ○ 楽をしたいから、もしくは何も考えてないか、本人は良かれと思っ てやってる（悪意がないのでタチが悪い） ● 世間の「わかりやすい正解」を持ってきて、銀の弾丸のように振りかざ して導入するのはわかりやすくて簡単 ○ 「世間ではこうするのが当たり前」 ○ 「進捗が悪いのは、この現場は○○を正しくできてないせい」

現場で起きてる問題を ツールやプロセスで語るこ とはできない

21 スクラムもその「わかりやすい開発手法」のよくある例 ● 現場で起きてる問題をツールやプロセスで語ることはできない ○ プロジェクトが進捗しないのはスクラムのせいでもウォーター フォールのせいでもない ○ 職場の人間関係が悪いのはスクラムができてないからではない ● フレームワークの前提となる文脈を咀嚼せずに導入しても問題は解決し ない

ここから本題

23 ここから本題 ● リーナーではどういうわかりやすさを捨てているか？例えば... ○ わかりやすい職種を捨てる ○ わかりやすい役割分担を捨てる ○ わかりやすい開発手法を捨てる

わかりやすい職種を捨てる

25 わかりやすい職種を捨てる ● 職種の違いはスキルの強みの違いでしかない ● みんなで良いプロダクトをつくって事業に貢献するために便宜上の役割 分担をしてるだけ ● みんなが事業開発も営業もデザインも開発もCSもすべてやれるのが理 想的だしその可能性を閉じない ● みんなで同じコトに向かっているので、職種の違いはお互いの強みに頼 ることであり、リスペクトへとつながる これをリーナーでは「矜持: みんなで一つのコトに向かう」と呼んでいる

わかりやすい役割を捨てる

27 わかりやすい役割分担を捨てる ● チームとしてやるべきこと、チーム内での最適な役割分担は状況によっ て常に変化する ○ ex. 会社の資本、競合の存在、市場動向、チームの練度、...etc. ● その時いるメンバーでできることをできる範囲でやり切る ○ 🙅「フロントエンドエンジニアなのでQAやセキュリティはわから ないのでできません」 ○ 󰢏「やったことないけど興味あるので調べながらやってみます」 ○ 󰢏「専門外だけどできる範囲でひとまずやってみます」 ● みんなが状況を把握し、担うべき役割を考え続けることが重要 リーナーでは「不撓: 今できる最善を探り続ける」と呼んでいる

わかりやすい開発手法 を捨てる

29 わかりやすい開発手法を捨てる ● スクラムを否定も肯定もせず、教養として身につける ○ （スクラムに限らず、すべての開発手法に対して同様） ● どんな開発手法を取っているとしても、大前提としてみんなで一つのコ トに向かっていることを気に掛ける ● 具体的にどういう開発手法を採用しているかはスポンサーブースで聞い てください ○ スクラムはやってないけど、すごくアジャイルな開発をやってる自 負はあります

時間チェック ここまで15分の予定 残り5分

みんなでコトに向かう ためにリーナーが やっていること

32 リーナーではみんなでコトに向かうために何をやっているか？ ● ※ あくまで試行錯誤の例として雰囲気を感じてください ● これを「わかりやすい事例」として持ち帰っても役に立ちません ● 事例 ○ 期待合わせ会 ○ 相棒制度 ○ 熱狂できるコトを探求する会（ネコたん）

33 期待合わせ会 ● 四半期ごとにチーム内での期待値をお互いに合わせる場 ○ チームとしてやること ○ 個人がやること、やりたいこと、やらない（任せる）こと、心配ご と ● チームにとって今何が必要か、自分が何をやるべき（期待されている） か、を擦り合わせることで役割を柔軟に変化させる ● マネージャーが決めるのではなく、メンバー内で話し合って決める

34 相棒制度 ● 営業、CS、エンジニアなどがお互いに相棒を募って深い話をする場 ● 商談で出た疑問、顧客要望の深掘り、プロダクト改善などなど ○ テーマを決めて相棒を募る → 相棒をアサインしてもらう ○ 相棒とテーマについて話す（1週間~1ヶ月） ○ （話して終わりの場合もあれば、実際のプロダクト改善につながる こともある） ● チームで公式な意思決定をする場以外の非公式なコミュニケーションを 促進している ○ 人が多いと話しにくいことでも、個別でなら深く話せる ● マネージャーが介入することなく、個別で話している

35 熱狂できるコトを探求する会（ネコたん） ● 全社でやる「声出し訓練」 ○ 会社がオープンであり、安心安全な場であることを感じてもらう ○ 一人ひとりが目の前の仕事に頑張れる環境をつくる ○ 経営陣と現場、ミドルマネジメントの距離を近づける ● 説明すると長いので詳細はお問い合わせください

これらはあくまで現時点の最善だと思 われることでしかない 重要なのはみんなで同じコトに向かう こと、そのための場を整え続けること わかりやすい正解ではなく、自分たち が置かれた状況を踏まえて最善を探し 続けている

まとめ

すべてはコトに向かうこと からはじまる

39 わかりやすい正解を捨てて、コトに向き合う ● すべてはコトに向かうことから始まる ● 最適なツール、プロセスは後からついてくる ● コトに向かってないのにツールやプロセスを議論しても無駄 ● 自分たちは今どんなコトに向き合っているのかをチームで話すことから 始めよう 向かっているコト = その会社の一番の魅力

最後にリーナーが向かって いるコトについて

41 かつて“Japan as No.1”と称され、世界を席巻した日本企業。 調達・購買部門が生み出す高い利益率に支えられ、驚異的な経済成長を遂げました。 しかし現在、日本企業は厳しい局面に立たされています。 スタンダードの刷新が遅れ、“失われた30年“が今もなお続いています。 ここ数十年の間、社会のスタンダードを刷新してきたのは 「ソフトウェアの進化」です。 営業部門にはじまり、経理、人事、法務… あらゆるアナログ業務がデジタル化され、 人間は「人間がやるべき仕事」に集中できるようになりました。 調達の スタンダードを 刷新し続ける。 しかし、日本における調達・購買部門のスタンダードは、未だ塗り替えられていません。 アナログな業務と紙書類に日々忙殺され、1,000兆円にのぼる企業の買い物は、属人的で不透明なまま。 僕らは、この「最後に残されたアナログ領域」で、新たなスタンダードを築き上げます。 そして、年間1000兆円にのぼる企業の買い物を科学し、日本企業の利益率を上げます。 ひいては、必ずや “Japan as No.1” と称され、世界を席巻した日本企業の繁栄を取り戻します。 調達・購買部門を。Leanerを。 “Japan as No.1" 復活の震源地に。 ー　Mission　ー

みんなで一つのコトに 向かって、 今解くべきイシューを日々 議論してます

ありがとうございました

44 最後に注意 ● 「わかりやすい正解」を何もかも否定しているわけではないです ● 自分たちが何に注力して、何を諦めるかは大事な選択です ● 自分たちに重要ではないことは、必要に応じてわかりやすい正解を選ぶ べきです ● その判断を適切にするためにも、自分たちが本当に解くべき課題がなん なのか、を職種・役割を超えて議論することがとても大事です