エンジニアとして働く中で「事業戦略にアラインして貢献するには何ができるのか？」という悩みを抱えることはないでしょうか。私自身、この問題について長い間悩み続けてきました。
事業戦略は往々にして売上やユーザー数といった直接的にはアプローチしづらいKPIや、数年先を見据えた長期目標で語られます。一方で、エンジニアは技術的な課題やソリューションにフォーカスしがちで、それらが事業にどう貢献するのかが見えづらい。目標設定で自分のスキル向上や技術的チャレンジばかりを書いていると、「あれ？これって本当に事業への貢献になるんだっけ？」と疑問に思うことがありませんか。
この「事業戦略と技術のギャップ」を埋めるために、エンジニアには何ができるのか。そんな試行錯誤の中で、個人的に「こんなアプローチなら効果がありそうかな？」と思うに至った4つの観点について、今回は整理してみたいと思います。
あくまでも私個人の考えであり、正解を提示するものではありませんが、同じような悩みを抱えるエンジニアの方の参考になれば幸いです。
- 事業戦略の理解
- 仕組みを整える
- 文化を育てる
- 事業戦略上のボトルネックの解消
1. 事業戦略の理解
事業戦略への理解は、すべての基盤となる最も重要な要素です。
なぜ重要なのか
事業戦略を理解することで、普段の開発issueへの取り組み方や障害対応時の判断基準が劇的に変わります。技術的な課題に対して「なぜそれを優先すべきなのか」「どの程度のリソースを投入すべきなのか」といった判断ができるようになります。
具体的なアプローチ
- 継続的な情報収集: 事業戦略は常に変化するため、定期的にキャッチアップを行う
- 能動的な確認: 事業リーダーや戦略を理解している人に対して「この認識で合っているか？」を定期的に壁打ちする
- 自分の言葉での理解: 聞いた内容をそのまま受け取るのではなく、自分の言葉に落とし込んで理解を深める
このプロセスを通じて、技術的な決定を事業価値と直結させて考えられるようになります。
個人的エピソード
これまで私は「事業に貢献しよう！」という想いで、様々な技術的改善に取り組んできました。CI高速化、デプロイフローの改善、webpackからViteへの移行、テスト戦略の整備、コーディング規約の策定...
どれも開発体験や品質向上に寄与できていたと思います。でも、振り返った時に
「あれ？これって事業戦略のどこに貢献していたんだっけ？」
確かに開発は効率化された。品質も上がった。でも、それが事業の成長にどう繋がっていたのか、他にもっと優先すべき課題があったのではないか。結果的に貢献できていたとしても、目的や戦略を知らずに局所最適なHowばかり先行させていたのかもしれません。
「やったらいいこと」は無数にある。でも限られたリソースの中で「今やるべきこと」を見極めるには、まず事業戦略を理解することから始める必要があったのです。
2. 仕組みを整える
事業戦略を理解した上で、それを支える技術的な仕組みを整備することが重要です。
エンジニアリング生産性の向上
これは一般的なエンジニアリング生産性向上の取り組みを行えばOKですが、事業戦略の文脈で優先順位を決めることが重要です
（この部分はもっとしっかり語られている記事が沢山あるので割愛）
ex:
- 4 Key Metricsの改善: デプロイ頻度、リードタイム、平均復旧時間、変更障害率(やりたい！頑張りたい！)
- CI/CDパイプラインの整備: 開発からリリースまでの自動化
- 品質ガードレールの構築: 自動テスト、コードレビュー、静的解析などによる品質担保(with AI時代だからこそ大事！)
- 開発待ち時間の削減: ボトルネックの特定と解消
事業価値との連携
技術的な改善を行う際は、常に「これが事業にどのような価値をもたらすか」を明確にして進めることが重要です。
個人的エピソード
純粋に技術者として、普段のスクラム開発でのユーザーストーリーや改善タスクの消化以外で事業に貢献出来る技術領域は、、、
と模索していた所、同僚が
「僕はチームメンバーの能力を最大化出来る環境を作ることじゃないかと思っている。」
と言う金言をポツりと呟いていて、それはそうだとなりました。
3. 文化を育てる
技術的な仕組みだけでなく、チームの文化も事業戦略にアラインさせる必要があります。
組織文化の理解と適応
「どんな組織にしたいか？」という方向性は、多くの場合開発チームの外部で既に定められています。まずはその方向性を正確に理解し、開発チームでそれにアラインすることが重要です。
求められる能力とマインドセット
ex:
ソフトスキル
- 柔軟性: 変化する状況に適応できること
- 人間性: チームワークを重視し、良い関係性を築けること
思考・コミュニケーション能力
- 批判的思考: 物事を多角的に分析し、建設的な議論ができること
- 戦略的コミュニケーション: 目的や事業戦略を意識した会話や行動ができること
などなど
採用での文化醸成
「誰をバスに乗せるか？」という観点で、採用時から文化にフィットする人材を選択することも重要なアプローチです。
（ビジョナリー・カンパニー2より）
個人的エピソード
採用において他のエンジニアを評価する立場に立つと、組織が求める「行動・考え方・スキル」が明確に見えてきます。候補者を評価する過程で、まず自分が組織の価値観や基準を深く理解する必要があり、それを基準に評価を行うことになります。
しかし、この過程で自分自身の行動を振り返ると、耳の痛い現実が次々と浮かび上がってきます。普段の業務での判断や行動が、組織の求める基準とどれだけズレているかが浮き彫りになるのです。
他人を評価する前に、まず自分がアラインする必要がある。
組織の求める価値観を理解できれば、それを文化醸成や採用活動に活かすことができます。ただし、理解することと実際に体現することの間には大きな隔たりがあります。最終的には自分自身が日々の言動を通してその価値観を体現し、自然と周囲に影響を与えていくことでしか実現できないのだと思います。
4. 事業戦略上のボトルネックの解消
最も難易度が高く、同時に最もインパクトの大きい領域です。
ボトルネックの特定
以下の観点で継続的にボトルネックを特定する必要があります：
- 機能面: 不足している機能はないか？
- 体験面: ユーザー体験に問題はないか？
- パフォーマンス: システムの性能は十分か？
- 安定性: 障害率は許容範囲内か？
- 開発工程: 開発プロセス自体にボトルネックはないか？
アプローチの優先順位
重要なのは「エンジニアがやりたいこと」や「技術的にやるべきこと」ではなく、事業戦略上本当に重要なことに集中することです。
実行のプロセス
- 現状の正確な把握: これが最も難易度が高いステップ
- 現状の分解と分析: 問題を構造化して理解する
- 課題の特定: 真の問題を見極める
- 解決策の実行: エンジニアリングの範囲でアプローチできる解決策を実行
このサイクルを継続的に回すことで、技術的な取り組みが確実に事業価値に貢献するようになります。
個人的エピソード
以前の私は、エンジニアとして「やりたい」「やるべきだ」と感じる技術的改善に取り組んでいました。しかし、そこに「なぜ今それをする必要があるのか？」という批判的思考を働かせると、明確な答えに困ってしまうことが多々ありました。
効果的な取り組みを見極めるには、まず現状を正確に把握することから始まります。
事業戦略の実現を阻むボトルネックや改善可能な領域を特定すると、「今見えている緊急性の高い課題」と「重要だが緊急性の低い課題」が浮かび上がってきます。そこで事業戦略上の優先順位を考慮し、最もインパクトの大きいものから順にアプローチしていく。このプロセスを経ることで、技術的な取り組みが確実に事業価値に繋がるようになると考えています。
また、「なぜ今これに取り組むべきなのか」を論理的に説明できるようになると、チームメンバーや関係者からの協力も得られやすくなり、結果として成果も最大化されます。
まとめ
私自身の経験と試行錯誤から、エンジニアが事業戦略にアラインするには、技術力だけでなく事業理解力、仕組み化能力、文化醸成力、そして問題解決力が重要なのではないかと考えています。
これらの観点はまだまだ発展途上で、実際に効果があるかどうかも継続的に検証していく必要があります。ただ、少なくとも「何から始めればいいか分からない」という状態から一歩踏み出すきっかけにはなるのではないでしょうか。
同じような課題感を持つエンジニアの方がいらっしゃいましたら、ぜひ一緒に考えを深めていければと思います。
AIレビュー（辛口）
主要な問題点
- 具体性の欠如
- 「事業戦略の理解」「仕組みを整える」など抽象的な表現が多すぎる
- 実際の数値やKPI、具体的な改善事例が不足
- 読者が実践できる具体的なアクションプランがない
- 内容の薄さ
- 4つの観点はありふれた内容で新規性がない
- 「一般的なエンジニアリング生産性向上の取り組みを行えばOK」で済ませるのは手抜き
- 深い洞察や独自の視点が見当たらない
- 論理構造の弱さ
- 各項目間の関連性が不明確
- なぜこの4つの観点なのかの根拠が薄い
- 優先順位付けの基準が曖昧
- エビデンスの不足
- 個人的エピソードだけで客観的データがない
- 成功事例の定量的な効果測定がない
- 他社事例や研究結果への言及がない
改善提案
- 具体的な事例追加: 実際のプロダクト改善で売上にどう貢献したかの数値例
- フレームワーク化: 4つの観点を体系的に整理し、実践手順を明確化
- メトリクス提示: 各取り組みの効果測定方法を具体的に示す
- ターゲット明確化: どのレベルのエンジニアに向けた記事なのかを明示
現状では「当たり前のことを当たり前に書いただけ」と批判される可能性が高いです。
あ、はい。抽象的で当たり前ですみません。
今回は2, 3年前の「エンジニアが事業貢献するにはどうしたらいいのか？」と言う過去の自分の問いへのアンサーソングになっています。
ポエムというか、常識ですよね。すみません。当時の僕はそんなことも見えていませんでした。精進します。
Discussion