事業開発もシステム改善も諦めないために考えてきたこと
メリークリスマス！
本日は 12 月 25 日ですね、皆様いかがお過ごしだったでしょうか？
はてさてかなり久しぶりに筆をとるわけですが、今回は「事業開発とシステム改善の両立」にいかに向き合ってきたか？そんな話をしようと思います。
主として手を動かしている時とマネージャーとしてチームを動かしている時と、両面で思考してきた末の内容となります、共感や何か発見があれば幸いです。
システム改善との向きあい方
システム改善と一口にいっても、色々な粒度感があると思います。
僕はユーザー体験変化と投入リソース規模感という観点を用いて、事業開発とシステム改善の両立に向き合う方法に行き着きました。
イメージが沸かせやすいように、最初にざっくりと分類を作ります。
どうでしょうか？リファクタリングがユーザー体験変化が高い分類にいるのは、なんだか違和感ある感じがしますね。
考え方を深ぼっていきたいと思います。
投入リソースをどう確保するか？問題
基本的にはシステム改善というものは、それ単体で考えた場合にユーザー体験としては変化が起こらないものであると捉えています。
事業目線で考えていくと、投入リソースを大きくする力学が働かないと言うことを意味しています。（ユーザー体験の変化が起こらない行為にリソース投入するインセンティブが薄い）
これが 投入リソースをどう確保するか？問題。
システム開発の生産性の低下を防ぐ、システムパフォーマンス向上に比例したユーザー体験向上、いかに事業価値へと翻訳するのか？色々なエンジニア組織で翻訳家がいて、腕の見せ所であろうと想像します。
僕も長年この問題と翻訳に向き合ってきました。その中でやはりこう、事業成長や業績を後ろ盾にされると、どうしても説得には時間もスキルも必要だなと痛感します。（翻訳活動を諦めはしない）
システム改善への投入リソースを安定確保できないと、サービス品質が低下していくことを専門家として定性的に理解しています。だからこそ、これはエンジニア組織が解かなければいけない普遍的なコア課題だなと考えます。
そこで僕は、事業と交渉する回数減らしたり難易度を下げるにはどうしたら？ こんな問いに対して試行錯誤してきました。
事業と交渉する回数や難易度をできる限りコントロールする
取り組みは以下の 3 つ
- 運用リソースとして固定費扱いで確保する
- 機能開発要求に合わせてシステム改善をプランニングする
- 事業規模に合わせてシステム改善をプランニングする
1. 運用リソースとして固定費扱いで確保する
書いた文字の通りで、開発工数の 10% 程度は固定でシステム改善に確保させてくれと言うものです。
ライブラリ更新や開発環境の更新系等、ルーティンで行いたい改善アクションや、システム改善活動を行いたい箇所の課題マップをため込んでいくアクションに使っています。
エンジニアリングマネージャーが組織へ説明して獲得するケースが多く、固定で確保してしまうことで都度交渉をなくします。
2. 機能開発要求に合わせてシステム改善をプランニングする
細かい単位でのリファクタリングに始まり、データ構造の改修や、1 の活動でため込んだシステム改善課題マップの解消に至るまで、多様なユースケースがあります。
キモは、機能開発要求が発生した際に触る事になるコードをスコープとして実施すること。
これによりシステム改善単独の投入リソース交渉ではなく、事業成長や業績貢献とセットでシステム改善を行う目的で投入リソース交渉ができる構図となる。
※ リファクタリングがユーザー体験変化が高い分類にいた理由
この目線を取り入れることで、プランニングとしてのスケジューリング時には、自分のスキルが高まるほどにシステム改善ができるとも言えます。（変数が自分のみになるのがいい）
エンジニア自身で PO や事業企画へ説明して獲得するケースが多く、交渉難易度を低くします。
3. 事業規模に合わせてシステム改善をプランニングする
1 と 2 による活動は、あくまで予防や改善活動の細分化になります。
これだけではリアーキテクチャのような、投入リソースが大きいシステム改善を行うことには至らないなぁというのが本音です。
ここで初めて、システム改善活動のみによる事業価値への翻訳が必要になります。事業規模によるバックキャスト思考を用いて、大規模な改修リソースを確保しに動きましょう。
事業計画上 xx 年後にxx 倍になるユーザー数に対応するシステムパフォーマンスを得るため、xx 年後のシステムクライアント数に対応するアーキテクチャを得るため、色々な観点が成長戦略上から逆算して描ける。
技術トップが経営へ説明して獲得するケースが多く、地道に交渉する領域ですね。
終わりに
システム改善活動を安定的に行うというのは、事業価値へと繋がっているものであると信じています。
エンジニア、EM、技術責任者等、それぞれの領域でのアクションの積み重ねによって、事業開発もシステム改善も両立していきたいですね。
おしまい。
