ソルバーの実際の働き方
ソルバーの仕事は課題次第でもあるので、具体的に東氏がどのような仕事をしてきたのかを見ていこう。
2022年後半ごろ、TOKIUMでは電子帳簿法対応の需要に合わせて、第3の新プロダクト「TOKIUM 電子帳簿保存」の誕生を目前にしていた。その際、モノリスで構築した弊害が出てしまい、コードの境界線があいまいになってしまっていた。そこでコンテキストマップを作成してサービス境界を設計するアプローチを適用することとなり、東氏はソルバーとしてコンテキストを守るガードレールとなる社内ツールを作成した。
またTOKIUMの認知度や契約数も高まるなどビジネスとしてもスケールしてくると、それまでの開発スタイルでは限界が見えてきた。そこでスクラムに移行することにしたものの、社内にはスクラム経験者がいなかったため、東氏がスクラムの考え、チームビルディング、基本的なプラクティスの実践を支援した。
2024年に入ると、利用者およびデータ量の増加により、DBのパフォーマンス悪化に悩まされることになる。当時は開発とSREチームが分かれていて、運用や障害に対して根本的な解決ができない状態だった。そこで東氏はSREとプロダクトオーナーとの接点構築や、相互理解のためのコミュニケーション機会を「地道に泥臭く」増やすように働きかけた。結果的にエンベデッドSRE体制の構築など改善につなげることができた。
第4の新プロダクト「TOKIUM 契約管理」が生まれるころになると、システム間の連携が必要となるものの分散システムの設計方針が未定だった。そこで東氏はビジネス戦略の展望に合わせたアーキテクチャ設計と基本方針を定め、基盤開発に着手することにした。CDCパターンを用いてレプリケーションでデータ同期、オーケストレーションサービスでシステム接合部を凝集させる方針とした。現状ではオーケストレーションはまだだが、レプリケーションは半年ほど問題なく稼働している。
直近では、数か月単位の投資が必要な横断プロジェクトが乱立してリソースの取り合いとなり、膠着状態に陥りつつあった。この課題に対しては組織の実行体制を見直すことにした。エンタープライズ規模でアジャイル・プラクティスを導入するためのSAFe（Scaled Agile Framework）に基づき中間構造を再設計し、マネジメント層をプロダクト・技術・運営責任に分割してそれぞれの優先順位を管理していけるようにした。
