Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
シニアエンジニアを超え、 スペシャリストとして組織の道を開拓する 「ソルバー」という働き方
Search
Mulyu
December 09, 2024
0
93
シニアエンジニアを超え、 スペシャリストとして組織の道を開拓する 「ソルバー」という働き方
Developers Career Boost 2024
Mulyu
December 09, 2024
Tweet
Share
More Decks by Mulyu
See All by Mulyu
コンテキストマップの継続的な活用に向けて
mulyu
1
260
ECSを活用してDigdagに安らぎを与える
mulyu
1
860
Featured
See All Featured
Become a Pro
speakerdeck
PRO
26
5k
Navigating Team Friction
lara
183
15k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
We Have a Design System, Now What?
morganepeng
51
7.3k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
RailsConf 2023
tenderlove
29
940
Producing Creativity
orderedlist
PRO
341
39k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Transcript
シニアエンジニアを超え、 スペシャリストとして組織の道を開拓する 「ソルバー」という働き方 2024年12月7日 株式会社 TOKIUM 開発部 イネーブリング 東 優太
自己紹介 プロダクト本部 開発部 イネーブリング 東 優太 Yuta Higashi 経歴 大手ネット広告会社のエンジニアとして初期のキャリアを
経験後、2020年に沖縄移住とともにTOKIUMに参加 2023年にイネーブリングチームに異動し、全体の生産性向 上のために尽くす 興味領域 Scala / Ruby / DDD / Scrum / SAFe
TOKIUMの志 未来へつながる時を生む 3 経理の領域でDXを実現する複数のBtoB/SaaSを開発 会社紹介 📊売上推移 2年で 4.1倍
4 支出管理プラットフォームTOKIUMの構想 支出に関する書類を一元管理できる支出管理プラットフォーム TOKIUMは、企業の経済活動を支える社会インフラとして、「支出データの可視化を通じて、企業の支出の最適化と迅速な意思 決定をサポートする」プラットフォームの構築を目指しています。 法人支出管理 プラットフォーム 経費・請求書の管理 稟議・契約管理 会計連携・支払い
支出に関する オペレーションを支援 支出分析・比較 支出先の提案 支出分析を基に 支出の最適化を支援
シニアエンジニアの先に どんなキャリアを描いていますか?
僕はシニアエンジニアとして プロダクトの立ち上げに参加していましたが チーム
開発部 グループ 二年前にプロダクト開発から離れ、 開発生産性の向上のため活動しています チーム チーム チーム
チームですが部下はおらず、 マネージャとは別のキャリアを歩んでいます チーム イネーブリング
部長 CTO EM マネージャではありませんが、 マネジメント層と密に協力しています
僕のキャリアは「ソルバー」です
ソルバーって何なのか? どんな仕事をするのか? どんな能力が必要なのか? 今日はそんな話をしたいと思います
ソルバーとは何なのか
ソルバーとは何なのか 会社が信頼を置くエージェントとして 困難な問題に深くかかわり、その解決 に責任を負うのが「ソルバー」だ。 ソルバーの任を受けた者は、会社幹部 が重要と認め、かつ明確な解決策が欠 けているか、もしくは実行する際のリ スクが極めて高いと考えられる問題に 取り組む。 Will
Larson. スタッフエンジニア マネジメントを超 えるリーダーシップ (p.25). 「スタッフエンジニア」で紹介 非管理職の典型の一つ
ソルバーとは何なのか 「生産性の向上のためにリアーキテクチャを検討したい」 「チーム間の連携体制を整え、今後の拡張に備えたい」 上位組織が捉えている抽象的な課題と施策に対し、 CTO 部長
ソルバーとは何なのか 具体的な解決策を提案し、意思決定を補助します 「生産性の向上のためにリアーキテクチャを検討したい」 「コンテキストマップを作ってシステム分割がよさそうです」 「チーム間の連携体制を整え、今後の拡張に備えたい」 「大規模アジャイルを導入・実践してみませんか」 CTO 部長 ソルバー
ソルバーとは何なのか 推進も担うので、EMやチームとも連携します CTO 部長 ソルバー 「リアーキテクチャやりましょう!」 チーム EM
ソルバーとは何なのか 課題解決の最前線で、責任を果たします CTO 部長 ソルバー チーム 「全体の設計って どうなります?」 「目的や目標って 明らかですか?」
「いつ頃終わりそう?」 「リアーキテクチャやりましょう!」 EM
ソルバーはどんな仕事をするのか
こうあるべきという仕事はなさそうですが 実際にどんな仕事をしてきたのか 事業・組織の変化も踏まえながら一部抜粋...
ソルバーとはどんな仕事をするのか New! 2022年後半~2023年前半 チームと作業衝突の増加 電子帳簿法対応の需要に合わせプロダクトが増加 モノリスで複数のサービスとチームが活動 設計方針の統制が取れなくなり、コードの境界線があいまいに
ソルバーとはどんな仕事をするのか 2022年後半~2023年前半 サービスの戦略的な境界設計 コンテキストマップを通して境界を明確化 コンテキストを守るガードレールとなる社内ツールを開発し、 意図しない構造変更や越境を防いだ 一般業務
ソルバーとはどんな仕事をするのか 2022年後半~2023年前半 ビジネス環境の変化 法改正およびテレビCM等により認知度も契約数も、要望も増加 法対応を進めつつも多様な要望に対応が必要 独自の開発スタイルにも限界が出てきた 開発プロセスの硬直 客観性のない見積 先行する締め切り 直前の仕様変更
人数=並列開発数
ソルバーとはどんな仕事をするのか 2022年後半~2023年前半 スクラムの実装支援 スクラムを導入することが組織内で決定 各チームをまわりながら、スクラムの知識のインストール 選出されたスクラムマスターと協力しながらスクラムを実装 継続的な振り返り 共同での相対見積 ベロシティ計測 頻繁なデモ
WIP制限
ソルバーとはどんな仕事をするのか 2023年後半~2024年前半 運用改善の阻害 開発とSREでチームが分かれていたこともあり、DevOpsが分断 障害に対処しても、根本解決に進められない SRE 開発者 PO
ソルバーとはどんな仕事をするのか 2023年後半~2024年前半 インタラクションの改善 特に接触が薄かったSREとプロダクトオーナーとの接点構築や、 相互理解のためのコミュニケーション機会を増やす SREエンジニアの開発チーム移動(embedded SRE化)も支援 SRE 開発者 PO
SRE
ソルバーとはどんな仕事をするのか 2023年後半~2024年前半 長期戦略と全体構成の複雑化 長期的なビジネス戦略が更新され、継続的にプロダクト増加 システム間連携が増えるが、分散システムに対する設計方針が未定 New! 一般業務
ソルバーとはどんな仕事をするのか 2023年後半~2024年前半 アーキテクチャビジョン作成と連携基盤構築 数年単位で目指すアーキテクチャを設計・計画 連携基盤としてのレプリケーション・オーケストレーションを 構想し、基盤構築と初期運用を担う データA ロジックA レプリケーション オーケストレーション
データB ロジックB サービスA サービスB
ソルバーとはどんな仕事をするのか 2024年後半~ プロジェクトの乱立 数か月単位の投資が必要な横断プロジェクトの乱立により 開発者が共有リソースと化し、取り合い状態に 長期的な施策が渋滞してしまった インシデント対策 リリース長時間化 パフォーマンス悪化 新プロダクトの構築
大型案件 サービスの基盤化 UI・UX改善
Arch ソルバーとはどんな仕事をするのか 2024年後半~ 大規模アジャイルの実装 エンジニア組織とPdM組織がミスマッチを起こし、 階層構造が機能していないと判断して中間構造を再設計 プロダクト・技術・運営責任に分割し、協力して優先順位管理 チーム層 マネジメント層 EM
Dev PO Dev PO Dev PO Dev PO PdM EM インシデント対策 リリース長時間化 パフォーマンス悪化 新プロダクトの構築 大型案件 サービスの基盤化 Backlog
アジャイルの実装とか、 アーキテクチャの設計とか アジャイルコーチや アーキテクトがやる仕事と被ってない?
実際被っている部分は多いと思います それでも場合によってはソルバーが必要です
ソルバーはなぜ必要とされるのか
TOKIUMは法改正の追い風もあり、 ここ数年で大きく事業も組織も急拡大を遂げました その一方で、組織が未知の領域へ踏み込むことで、 いくつかのよくある問題が表面化していきました
ソルバーはなぜ必要とされるのか 人員やスキルが一時的に不足する サービスの立ち上げ時などに教育や採用が追いつかず、 スキル・リソースが必要十分ではないチームが生まれてしまう 既存チームも重要な施策が進行中で、なかなか手助けを出せない状況 チームのスキル リソース 新規構築の経験が無かったり、 どうしても人が足りなかったり
チームのスキル リソース ソルバーはなぜ必要とされるのか 人員やスキルが一時的に不足する ソルバーがジョインし、スキル習得を手助けしながら解決を請け負う 教育や調達が間に合い次第引き継いで離脱する チームのスキル リソース 教育・調達
ソルバーはなぜ必要とされるのか チーム横断の体制が未整備 共有リソースに対する方針や仕組みが追いつかないままチームが増え、 問題に対してチーム単体では切り取れなくなってしまった 何とかしようにも、チームの領分を超えるのでお見合い状態に チームA チームB どこにも属さない
ソルバーはなぜ必要とされるのか チーム横断の体制が未整備 ソルバーがいったん受け取り、協力と解決をリードする 問題の緩和や解決策をリーダー・EMに引き継いで離脱する (最終的には管理構造にも手を入れないとなかなか解決しない) チームA チームB 緩和策 解決策
ソルバーはなぜ必要とされるのか 未経験・未知な問題への衝突 組織上初めて取り組む問題や、問題が曖昧で解決策がイメージできていな かったりすると、誰かが問題領域を探索する必要がある リスクが高い問題になりがちで、トップ層をアサインする必要がある 抽象的・曖昧・複雑
ソルバーはなぜ必要とされるのか 未経験・未知な問題への衝突 ソルバーが調査や検証など探索的なアプローチで具体的な解決策を形作る その中で必要なスキルや構造を見つけ、育成・採用を通じて置き換えていく アーキテクトなど役割の分化もこの過程で進んでいく 新しい ポジションや チーム 具体化 一般化
マネジメント構造に固定されないことで、 アジャイルコーチだったり、 アーキテクトだったり、 必要な箇所・必要な時期・必要な役割で切り込む その時々で役割を変えて対応するために 様々な能力が要求されました
ソルバーにどんな能力が必要だったか
ソルバーにどんな能力が必要だったか 効果的・計画的に学習する 集中した投資はリスクが高く、分散した投資はリターンが低い 予測と計画を立てて学習しなければ、無駄な投資に終わってしまう 情報収集を通して投資計画を立てることが必要 ビジネスロードマップ プロダクトロードマップ 組織体制 開発組織のスキルセット チーム層から聞く懸念
マネージャ層から聞く懸念 3ヶ月計画 6ヶ月計画 年間計画
ソルバーにどんな能力が必要だったか 効果的・計画的に学習する 学ぶべきものを決めたら、少しずつでいいから学ぶ習慣を付ける 知らないことを書き出して、一つ調べたら、一つ追加する 掘り続けつつも、飽きないように他の領域にも目を向ける Kafkaの概要 Kafkaの パーティション CDCのパターン debeziumの概要
大規模アジャイル SAFeの概要 アーキテクトの 役割 レプリケー ション アジャイル
ソルバーにどんな能力が必要だったか 頻繁にフィードバックを受け入れる 抽象的・複雑な課題を扱う際、すぐ解決策に飛びつかない プロセスを設計して、チェックポイントを作って取り組む 「生産性の向上のために リアーキテクチャを検討したい」 CTO ミッションの策定 評価指標の策定 コンテキストマップレビュー
アーキテクチャレビュー
ソルバーにどんな能力が必要だったか 頻繁にフィードバックを受け入れる 上司はもちろんのこと、チームのフィードバックもたくさん受ける 頻繁に相談することが納得感を得て、協力につながる 困難な問題は一人では解決できないから困難だと理解する ミッションの策定 評価指標の策定 コンテキストマップレビュー アーキテクチャレビュー レビュー
チーム レビュー マネージャ
ソルバーにどんな能力が必要だったか 組織と人を理解する 課題について考えていると、原因は組織だと気づくことがある 課題解決のためには、技術以外の手段も学ぶ必要がある プロセス 技術負債 スキル 組織 課題 チーム
システム アーキテクチャ 環境 バグ パフォーマンス 技術負債の原因にプロセスの問題があるのはよくあること
ソルバーにどんな能力が必要だったか 組織と人を理解する 二年取り組んで気づいたたった一つ確かなこと 「組織も人も、それ自身が望まなければ変わらない」 マネージャを担わなくても、マネジメントスキルは有用 課題 上司を巻き込む 目標に絡める 勇気づける 並走する
おわりに
今日はシニアエンジニアの先のキャリア、 スタッフエンジニアの典型「ソルバー」についてお話ししました テックリード アーキテクト ソルバー ライトハンド
目まぐるしい状況で先行きが見えなくなったり、 自身の能力の限界に悩んだり、 シニアエンジニアになかった苦しみもありますが 常に初めての挑戦 協力が得られない スコープが大きすぎる 責任の重さ 要求の高さ
意思決定層に意見を反映して大きな流れをつくったり、 興味深く刺激的な仕事を通して自己成長を感じられたり、 ソルバーらしい楽しさもたくさんあります 飽きのこない仕事 ソフトスキルの向上 協力者が増える 重要情報へのアクセス 大きな達成感
特にチームの外に課題が転がっていたら、 ソルバーを求めているサインかもしれません まずはそれを拾ってみるのが第一歩です 行き場を失った課題 チーム 曖昧な課題
株式会社TOKIUM 東京都中央区銀座6丁目18-2 野村不動産銀座ビル12階 53 URL : https://www.keihi.com/company