SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers CAREER Boost 2024 セッションレポート(AD)

技術に専念したいシニアエンジニアのための、非管理職「ソルバー」というキャリアの形

【A-3】シニアエンジニアを超え、スペシャリストとして組織の道を開拓する「ソルバー」という働き方

  • X ポスト
  • このエントリーをはてなブックマークに追加

 エンジニアが経験を重ねてシニアエンジニアとなると、その先には何があるのだろう。チームをマネジメントしていくのか、またはスペシャリストとして技術を極めるのか。さまざまな方向性があるが、自分にはどんな選択肢がふさわしいのだろうか。この疑問に対する回答の一つとしてTOKIUMの東優太氏は、組織が抱える課題解決に責任を負う「ソルバー」を提示。その魅力について語った。

  • X ポスト
  • このエントリーをはてなブックマークに追加

技術を極めたキャリアの一つの形「ソルバー」とは

 シニアエンジニアの先、技術を極めたスペシャリストの1つの形として「ソルバー」がある。エンジニアリーダーがチームを効果的に導くためのリーダーシップ』スキルについて解説した書籍『スタッフエンジニア マネジメントを超えるリーダーシップ』で紹介された非管理職の1つだ。主に、会社が信頼を置くエージェントとして、困難な問題に深く関わり、解決に責任を負う。

 いままさにソルバーを実践しているのがTOKIUM プロダクト本部開発部 イネイブリングチーム 東優太氏だ。大手ネット広告会社でエンジニア経験を積み、2020年からTOKIUMに移り、今では開発生産性向上のための単独チームで活動をしている。

 なお東氏が所属するTOKIUMは「未来へつながる時を生む」という志をもとに、経理領域でDXを実現するプロダクトを展開している。今後は経理にとどまらず、企業の支出管理のためのプラットフォームを目指している。

株式会社TOKIUM プロダクト本部開発部 イネイブリングチーム 東 優太氏
株式会社TOKIUM プロダクト本部開発部 イネイブリングチーム 東 優太氏

 TOKIUMにおける東氏の実際の活動を追いながら、ソルバーの働き方について見ていこう。TOKIUMへの入社当初、東氏はシニアエンジニアとして「TOKIUMインボイス」という新しいプロダクトに参加することになった。その後、2022年末ごろからはプロダクト開発から離れ、開発生産性向上のための専任チームで活動している。「チーム」と名前はついているが部下はなく、スペシャリストとして、CTO、PO、EMなどと密にコミュニケーションしながら仕事を進めている。

 例えばCTOや開発部長から「生産性向上のためにリアーキテクチャを検討したい」「チーム間の連携体制を整えたい」といったチームレベルでは解決できない抽象的な課題に対して、具体的な解決策を提案し、意思決定を補助する。また現場での推進も担うのでチームやEMとも密に連携する。

ソルバーの実際の活動

 課題が「リアーキテクチャ」だとしたら、上層から「いつごろ終わりそう?」、EMから「目的や目標は?」、チームから「全体設計は?」といろいろと難しい質問や相談が寄せられるので、それらに対応しながら解決まで責任を持って関わる。

ソルバーの実際の働き方

 ソルバーの仕事は課題次第でもあるので、具体的に東氏がどのような仕事をしてきたのかを見ていこう。

 2022年後半ごろ、TOKIUMでは電子帳簿法対応の需要に合わせて、第3の新プロダクト「TOKIUM 電子帳簿保存」の誕生を目前にしていた。その際、モノリスで構築した弊害が出てしまい、コードの境界線があいまいになってしまっていた。そこでコンテキストマップを作成してサービス境界を設計するアプローチを適用することとなり、東氏はソルバーとしてコンテキストを守るガードレールとなる社内ツールを作成した。

 またTOKIUMの認知度や契約数も高まるなどビジネスとしてもスケールしてくると、それまでの開発スタイルでは限界が見えてきた。そこでスクラムに移行することにしたものの、社内にはスクラム経験者がいなかったため、東氏がスクラムの考え、チームビルディング、基本的なプラクティスの実践を支援した。

 2024年に入ると、利用者およびデータ量の増加により、DBのパフォーマンス悪化に悩まされることになる。当時は開発とSREチームが分かれていて、運用や障害に対して根本的な解決ができない状態だった。そこで東氏はSREとプロダクトオーナーとの接点構築や、相互理解のためのコミュニケーション機会を「地道に泥臭く」増やすように働きかけた。結果的にエンベデッドSRE体制の構築など改善につなげることができた。

 第4の新プロダクト「TOKIUM 契約管理」が生まれるころになると、システム間の連携が必要となるものの分散システムの設計方針が未定だった。そこで東氏はビジネス戦略の展望に合わせたアーキテクチャ設計と基本方針を定め、基盤開発に着手することにした。CDCパターンを用いてレプリケーションでデータ同期、オーケストレーションサービスでシステム接合部を凝集させる方針とした。現状ではオーケストレーションはまだだが、レプリケーションは半年ほど問題なく稼働している。

 直近では、数か月単位の投資が必要な横断プロジェクトが乱立してリソースの取り合いとなり、膠着状態に陥りつつあった。この課題に対しては組織の実行体制を見直すことにした。エンタープライズ規模でアジャイル・プラクティスを導入するためのSAFe(Scaled Agile Framework)に基づき中間構造を再設計し、マネジメント層をプロダクト・技術・運営責任に分割してそれぞれの優先順位を管理していけるようにした。

SAFeの実装

ソルバーが必要とされている現場の「サイン」

 ここまで見て「アジャイルの実装ならアジャイルコーチ、アーキテクチャ設計ならアーキテクト、他の役割とかぶっているのでは?」と思うかもしれない。東氏は「確かに、実際かぶっています。しかしそれでもソルバーが必要とされるのは、組織やチームが抱える状況にあると考えています」と言う。TOKIUMを例に見ていこう。

 法改正の後押しもあり、TOKIUMはここ数年で事業も組織も急拡大を遂げた。その過程で組織が未知の領域に踏み込むことで、次のような問題に直面してきた。

 1点目は採用や教育が追いつかず、リソースやスキルが一時的に不足する。特にサービス立ち上げ時には必要なスキルやリソースが十分ではないチームが生まれてしまう。既存チームも重要な施策が進行中で、なかなか手助けできない。

 こういう時こそソルバーの出番だ。遊撃的にチームにジョインして、チームに知識や技能が足りない程度であれば、一緒に作業することで業務遂行と教育を両立できる。スキル習得や採用で解決したら早期に離脱できる。東氏の経験だと「だいたい1か月で抜けています」と言う。

 2点目はチーム横断体制が未整備で、チーム単体で扱えない課題を前に硬直してしまうこと。共有リソースに関する方針や仕組みが追いつかないままチームが増えてしまうと、チーム単体で扱えない問題が生まれたときに対処したくてもチームの領分を超えてしまうため、「お見合い」状態となり手を出せなくなる。誰かが課題を拾わないとならない。

 こういう時でもソルバーがいったん受け取ることで、協力と解決をリードすることができる。その後問題を緩和させたり、解決策をリーダーやEMに引き継いだりして、ソルバーは離脱する。なお、チームが乱立するリスクもあるため、最終的には管理構造にも手をいれないと解決できない。この点はなかなか難しい。

 3点目は未経験・未知なる問題への直面。組織が初めて取り組む問題や、問題が曖昧で解決策がイメージできなかったりすると、誰かが問題領域を探索する必要がある。これこそソルバーが立ち向かうケースとなる。事業の成長が早く、状況の変化が早いとこうした課題が多く発生しがちだ。

 つかみどころのない課題には探索的なアプローチで具体的な解決策へと導く必要がある。言い換えると、探索するなかで必要なスキルや構造を見いだし、育成や採用で置き換えていくことになる。

 東氏は「ソルバーは組織の基本構造から外れたところで生じた課題に対応するために、時にはアジャイルコーチ、時にはアーキテクトなど必要な役割で切り込みます。またマネジメント構造に固定されない単独のチームなので、必要な箇所、必要な時期に入り込めます。その時々で役割を変えて対応するために、さまざまな能力が要求されてきました」と話す。

 ソルバーに必要な能力については、東氏は3点ポイントを挙げた。1点目は学ぶ計画を立てる能力。重要度の高い、抽象的な課題に取り組むため、効果的かつ計画的に学習する必要がある。東氏は「抽象度と難易度にあわせて計画を使い分けるといい」と提案する。例えばリーダーシップのスキルを半年計画で、大規模アジャイルは3か月計画で学んだという。学ぶべき対象を見定めたら、少しずつでもいいから学ぶ習慣を付ける。「掘り続けつつも、飽きないように他の領域にも目を向けるとか、適度に自分の好きなところをつまみ食いするのもいい」と東氏。

 2点目は頻繁にフィードバックを受けいれること。東氏は「抽象的かつ複雑な課題を扱う時にはすぐに解決策に飛びつかず、プロセスを設計して、チェックポイントを作って取り組むこと」とアドバイスする。そのためにも上司はもちろん、チームからのフィードバックを受けいれるといい。東氏は「相手を尊重すればその分協力してもらえますし、大きな課題は1人では解決できないので協力を得ることが不可欠です」と言う。

 3点目は組織と人を理解すること。課題解決に取り組んでいると、組織に原因があることもある。東氏は「技術負債の原因にプロセスの問題があることはよくあることです。本当の課題解決を請け負うなら、テクノロジーだけではない手段も扱えるようになるといいです」とアドバイスする。2年間ソルバーとして活動するなかで、東氏は「組織も人も、それ自身が望まなければ変わらない」と確信したという。独りよがりでは改革はできないということだ。そのためマネージャではなくてもマネジメントスキルは役に立つ。

 ソルバーを経験して、東氏は次のようにアドバイスする。「めまぐるしい状況で先行きが見えず、能力の限界に悩むなどシニアエンジニアにはない苦しみがありますが、意思決定層に提案して大きな流れを作ったり、刺激的な仕事を通じて成長を感じられたり、ソルバーらしい楽しさもたくさんあります。チームの外に課題が転がっていたら、ソルバーを求めているサインかもしれません。まずはそれを拾ってみるのが第一歩です」

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

提供:株式会社TOKIUM

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/20630 2025/01/28 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング