はじめに
自分のキャリアの方向性を改めて言語化したくなったため、2026年5月時点で考えているキャリアビジョンをまとめておく。
考えていることは時間とともに変わっていくものだが、こうして節目で文字にしておくことで、後から振り返ったときに「当時何を大切にしていたか」を辿れるようにしておきたい。
サマリ
「アーキテクトとして組織とソフトウェアの価値を長期的に向上させる」ことを目指している。組織とソフトウェアはコンウェイの法則によって本質的にシンクロしており、両軸を意図的に設計できる人材は希少だと考えている。
そのために「自分が書いたコードよりも、自分が作った仕組みで他者が成果を出せること」を価値の中心に置き、アーキテクトとしての設計・意思決定を軸にしつつ、必要に応じてリードや組織づくりにも踏み込みながら成果を出すことを大切にしている。技術判断は常に事業・ユーザー価値と接続して説明する。最終的には組織のDNAレベルで価値を残すことを目指す。
これまでの経験(Web系受託 → スタートアップ → 事業会社での基盤設計経験)と現在の強み(構造化思考、横断領域の実務経験、チームリード経験)を活かし、より大きなインパクトを組織に与えたいという想いから生まれているビジョンである。
目的
アーキテクトとして、組織とソフトウェアの価値を長期的に向上させ、事業に貢献すること。
単に技術力を発揮するだけではなく、チームでより大きな成果を生み出すことを目指している。
中核となる価値観
組織の価値とは
個人ではなく仕組みと文化によって、変化に適応しながら持続的に成果を生み出し、その成果が組織全体に波及していく状態。
組織の価値を構成する要素は次のように整理している。
- 再現性:誰がやっても一定水準の成果が出る(属人化されていない)
- 学習能力:環境変化や失敗から学び、自己更新できる
- 波及力:一部の改善・成功事例が他チーム/組織全体に伝播する仕組みがある
- 持続性:短期成果と長期投資(技術負債解消・人材育成等)を並行して実行できる
ソフトウェアの価値とは
ユーザー・事業に提供する直接価値を起点に、それを長期的に維持・進化させ続けられる能力までを含めた総合的な価値。
ソフトウェアの価値は時間軸によって重み付けが変わる。
| 時間軸 | 価値の中身 | 主要な指標 |
|---|---|---|
| 短期 | ユーザー価値・事業価値の提供 | 機能性・体験・事業KPI寄与 |
| 中期 | 変更容易性・進化可能性 | リードタイム・変更失敗率・拡張コスト |
| 長期 | 信頼性・運用性・知識の継承可能性 | 可用性・MTTR・新規参画コスト |
時間軸が長くなるほど「設計の質」が支配的になる。アーキテクトは時間軸を超えて重み付けを意思決定する役割だと考えている。
組織×ソフトウェアのシンクロ
組織構造とソフトウェア構造は相互に整合する(コンウェイの法則)。両者を意図的に同期させてコントロールできる状態こそが、長期的価値の源泉。
- 組織を変えずにアーキテクチャだけ理想化しても、設計と実態が乖離し続け、結局元の構造に引き戻される
- 良い設計があっても、それを運用する組織が回せなければ陳腐化する
- 良い組織があっても、共通基盤がスケールしなければ各チームが車輪の再発明を続ける
- 両軸を同時に設計できる人材は希少であり、これがアーキテクトという役割の本質的な価値だと考えている
チームでスケールする技術の価値
個人の能力に依存せず、仕組み・基盤・標準として他者の生産性を底上げし、組織の資産として蓄積されていく技術。
自分が書いたコードよりも、自分が作った仕組みで他者が成果を出せることに価値を置く。
価値の昇華プロセスは「個人技 → チームの標準 → 組織の資産 → 組織のDNA」だと捉えている。
1人が100%出力するより、10人が80%出力できる仕組みを作る方が事業インパクトは大きい。手を動かすことは線形だが、仕組み・基盤・標準は時間とともに価値が複利で増えていく。
動機:なぜアーキテクトを目指すのか
1. チームでスケールする技術の価値を実感している
技術は「個人」よりも「チーム」でスケールするものだと考えている。
過去にリードエンジニアとして開発を牽引した経験から、個人の技術力向上以上に、チーム全体の技術力を底上げすることが組織に与えるインパクトの大きさを実感した。協働によって生まれる成果や成長に価値を感じており、チームとして持続的に成果を生み出す仕組みづくりに貢献したい。
2. 構造的思考と抽象化を活かしたい
システムの構成要素を俯瞰し、再利用性・スケーラビリティ・整合性の高い設計をすることに関心がある。複雑な課題を構造的に整理し、抽象化して本質的な問題を見抜くことが得意だと自覚しており、この思考力を組織やシステムの構造的な課題解決に活かしたい。
3. 基盤領域での実務経験から横断的価値を理解している
認証・通知・権限管理といった、複数チームやプロダクトに影響する基盤領域の設計・開発を経験してきた。1つの基盤システムが組織全体の開発効率や品質に与える影響の大きさを体験し、横断的な技術基盤が組織の長期的価値を支えることを実感している。
4. 組織とソフトウェアの両軸を同時に設計したい
コンウェイの法則が示すように、組織構造とソフトウェア構造は相互に影響し合う。どちらか一方だけを最適化しても破綻する。両軸を同時に見て、意図的に同期させながら進化を駆動できる役割は希少であり、自分の構造化思考・基盤領域の経験・チームリード経験を統合的に活かせる場だと考えている。
5. 大きな成果を出したい
アーキテクトとして事業・プロダクトの方向性に影響を与える立場で、インパクトの大きな意思決定や支援をしたい。
姿勢
- ハードスキルとソフトスキルのバランスを重視する
- 技術だけでなく、チームや組織の文脈を踏まえた調整力・説明力・巻き込み力を重視し、成果を出すことにこだわる
- ビジネスへの関心と理解を持つ
- 単なる技術の最適化ではなく、「なぜこの設計が事業に貢献するか」を説明・納得できる状態を目指す
- 組織全体への波及を意識する
- 個別最適より横展開を優先する。1チームの改善 → 仕組み化 → 他チームへの展開という流れを設計する
取り組みたいこと
技術面での貢献
-
組織を横断する技術基盤の設計
- 複数プロダクト・チームに共通する関心事(認証・通知・権限管理など)を統合的に扱える基盤を設計し、開発効率と品質を底上げする
- 標準仕様や設計原則に立脚した、再現性・説明責任のあるアーキテクチャを志向する
-
事業成長のボトルネックを技術で解消
- スケーラビリティ・可用性・パフォーマンスといった非機能要件を、事業フェーズに応じた水準で体系的に設計する
- 短期の事業要求と長期の保守性が両立する技術判断をする
組織面での貢献
-
中長期の技術戦略の策定と実行
- 事業の方向性と技術的制約を踏まえ、あるべき姿と優先課題を言語化する
- 短期の開発速度と長期の保守性が両立する形で、技術負債の扱いを意思決定する
-
意思決定と知識継承の仕組み化
- 誰が・いつ・何を判断するかを明確にし、設計判断を継承可能な形で残す
- 個別の成功事例を標準化し、組織全体に波及させるプロセスを設計する
-
持続可能な技術組織の構築
- 技術文化の醸成と開発効率の向上を通じて、組織として成果を出し続ける状態を作る
- 採用・育成・次世代リーダーの輩出によって、特定個人に依存しない組織を作る
事業への貢献
-
技術判断を事業価値と接続する
- 技術施策の効果や「やらないリスク」を事業指標・コストで説明し、経営判断として議論できる形に整える
- 事業フェーズに応じて最適なアーキテクチャを選び取る(常に正しい設計は存在しないという前提に立つ)
-
技術起点で事業の選択肢を広げる
- 技術的に可能になる新機能・新ビジネスモデルを能動的に提案し、技術を事業を駆動する力として位置づける
ユーザーへの貢献
- ユーザー価値を起点とした基盤判断
- ユーザー体験の劣化を技術的課題として可視化し、基盤投資の優先順位に反映する
- 基盤投資が技術者の自己満足にならないよう、常にユーザー価値を判断軸に置く
おわりに
ここに書いたビジョンは、現時点での自分の考えである。経験を重ねるごとに表現や粒度は変わっていくだろう。
それでも「アーキテクトとして組織とソフトウェアの価値を長期的に向上させる」という軸は当面変わらない見込みなので、この方向性で日々の意思決定や学びを積み重ねていきたい。