この記事でわかること
-
ドメイン・役割・システム種別を越境して活躍するためのマインドセット
-
未知の領域に素早く適応し、成果を出すための「コンテキスト把握」の手法
-
変化の激しい時代の中で、エンジニアが価値を高め続けるためのキャリア戦略
エンジニアを取り巻く環境が激変する現代において、特定の技術や業界だけに留まることに不安を覚える人は少なくありません。次々と新しい技術が生まれ、エンジニアに求められる役割も拡大し続ける中、どのようにキャリアを築いていけばよいのでしょうか。
シンプレクス株式会社で技術者組織のリード（コンピテンシーリード）を務める松本氏は、FXシステムの開発からweb3、そして官公庁のプロジェクトまで、業界も役割も全く異なる領域を「越境」しながらキャリアを歩んできました。
本記事では、松本氏へのインタビューを通じて、論理的かつ本質的な問題解決アプローチから、技術が変わっても揺るがない普遍的なスキル、そしてあえて「キャリアのゴールを決めない」という独自の生存戦略まで、第一線で活躍し続けるためのヒントを紐解きます。
松本 頌
シンプレクス株式会社
システムディベロップメントコンピテンシー コンピテンシーリード
2015年にシンプレクスに新卒入社し、外国為替証拠金取引システムのエンジニアとしてキャリアをスタート。その後、同システムの導入プロジェクトのテックリード、web3領域のプロジェクトマネジャー、証券業向けのコンサルティング、官公庁向けのアーキテクト、技術者組織のリードなど、多種多様な領域、ロールに携わる。キャリアのゴールはない。
IPAのシステムアーキテクト、「Japan All AWS Certifications Engineers」に2023年から2026年まで連続で選出、PMPなど保有資格多数。
シンプレクス株式会社
1997年の創業以来、メガバンクや大手総合証券を筆頭に、日本を代表する金融機関のテクノロジーパートナーとしてビジネスを展開。現在では、金融領域で培った豊富なノウハウを活用し、金融機関以外の領域でもソリューションを展開している。2019年3月にはAI企業のDeep Percept株式会社、2021年4月には総合コンサルティングファームのXspear Consulting株式会社がグループに加わり、公的機関や金融機関、各業界をリードする企業のデジタルトランスフォーメーション（DX）の推進を支援。
目次
「隣接領域」へ連続的にスライド。ドメインや役割を越境するエンジニアの歩み
松本さんは、新卒で入社されてから現在に至るまで、本当に多様なご経験をされていますよね。まずは、現在のお仕事内容から教えていただけますか？コンピテンシーリードや現場のアーキテクトとして、日々どのような役割を担っていらっしゃるのでしょうか。
現在は、主にプロジェクト業務と組織マネジメントの2つの軸で動いています。割合としてはプロジェクト業務が8割ほどですね。メインのプロジェクトでは、証券業向けのスマホアプリの大規模エンハンス開発で開発リーダーを務めつつ、プロジェクト内での生成AIの利用推進も担当しています。
プレイングマネージャーとして現場を牽引するだけでも多忙かと思いますが、残り2割の組織マネジメントとは、具体的にどのような業務なのでしょうか。
システムディベロップメントコンピテンシーという100名を超える技術者組織のリードとして、メンバーのタレントマネジメントを強化する取り組みを行っています。それぞれのメンバーがどのような強みやキャリアへの関心を持っているかを棚卸しし、本人の希望も踏まえながら最適なアサインを検討しています。また、若手の開発リーダー向けに「開発リーダー論」という社内研修の講師も務めています。
現場の第一線で開発をリードしながら、100名規模のタレントマネジメントや育成まで手がけられているのは驚きです。松本さんは2015年の入社以来、FXからweb3、そして官公庁のプロジェクトまで、ドメインも役割も大きく変えながらキャリアを歩まれてきました。ご自身のこれまでの変化を、どのように振り返りますか？
客観的に並べて眺めてみると「本当に色々なことをやっているな」とは思うのですが、主観的には大きくかけ離れた転換をしているわけではなく、少しずつ隣の領域へと連続的にスライドしてきているという感覚なんです。同じプロジェクトにずっと留まるのではなく、一つの区切りがついたら別の役割やお客様、システムのプロジェクトへと移っていく。それを10年ほど続けてきた結果ですね。
断絶ではなく、連続的なスライドとしてキャリアを捉えられているのですね。とはいえ、携わるシステムが変われば、当然求められる技術スタックも大きく変わってくると思います。その都度のキャッチアップは大変ではありませんでしたか？
そうですね、最初はJavaが中心でしたが、そこからブロックチェーンの技術に触れたり、インフラがオンプレミスからクラウドに変わったりと、変化は常にありました。Javaのリッチクライアントから、Reactなどを用いたWebシステムになり、さらにはモバイルアプリへと広がっていきました。プロジェクトが変わるごとに、技術スタックが少しずつ変わっていくような環境でした。
毎回新しい技術を学ぶ必要がある環境だったのですね。ご自身の役割も変化していく中で、学習の深さなどはどのように調整されていたのでしょうか。
自分の役割に応じた深さでキャッチアップすることを意識していました。例えば、一人のメンバーとして開発に携わる時は、自分でコードを書いてテストまで完遂しなければならないので、深いレベルでの理解が必要です。
一方でリーダーのポジションにいる時は、技術の細部よりも一般的な設計原則や、システムのアーキテクチャとして外してはいけないポイントをしっかりと押さえるレベルでキャッチアップを進めていました。
不確実性の高い現場で成果を出す、エンジニアの「普通に考える」マインドセット
先ほど「隣の領域へのスライド」とおっしゃっていましたが、FXシステムの開発リーダーから、官公庁プロジェクトでの品質統括やアーキテクトへの転換は、役割の重みとして非常に大きな変化に感じます。全く新しい環境で、ご自身の役割をどのように見つけ、立ち回られたのでしょうか。
まずアーキテクトの役割については、前任の方がいらっしゃったチームに加わる形だったので、比較的キャッチアップはしやすかったですね。一方で品質統括という役割は、もともと存在しなかったポジションでした。プロジェクトで障害が発生していた時期があり、その品質改善を行うために新設され、そこに私がアサインされた形です。
新設されたポジションとなると、マニュアルも前例もない状態ですよね。誰も正解を知らない中で、何から手をつけていったのでしょうか。
誰も正解を知らないからこそ、まずは「一般的に考えたら、普通はこういう状態を目指すべきだよね」という当たり前のことを一つずつ整理していきました。品質が悪く見えているという課題に対して、問題の本質がどこにあるのかを特定する。そして、その改善のためにどのような成果物を作り、どのようなルールを設けるべきかを関係者とすり合わせながら進めていきました。
非常に論理的で冷静なアプローチですね。ただ、実装の最前線に立つメンバーと、品質を統括する立場とでは、目指す方向性が異なり、衝突することもあったのではないでしょうか。
おっしゃる通りです。作る側の人間と品質を良くしたい側の人間では、どうしても目指す方向性が食い違うことがあり、衝突することもしばしばありました。私自身、元々は開発の現場にいたので、ルールで縛られたくないという開発メンバーの気持ちはよく分かります。
ですので、やみくもに強制的なルールを増やすことは避け、自動化できる部分は積極的に自動化を取り入れるようにしました。
現場の痛みが分かるからこそ、運用までを見据えたバランスの良い設計ができたのですね。新しい環境や未知の課題に直面した時、松本さんが着実に成果を出すために意識しているマインドセットなどはあるのでしょうか。
先ほど「一般的に考えたら〜」とお話ししましたが、私はこれを社内で「普通に考える」と表現しています。要するに、『論理的な妥当性』を探るということです。前提知識や制約条件がある中で、「普通に考えたらこうなるだろう」というロジックを組み立てるんです。
インプットとアウトプットがあって、その間にどのような道筋が存在するのか。条件と目的さえ明確になれば、何をすべきかの判断は自然とつくはずだと考えています。
なるほど。最初の品質改善のアプローチも、まさに「普通に考える」ことの実践だったのですね。言葉の裏には、極めて論理的な要素分解のプロセスがあると感じます。具体的にはどのような思考順序になるのでしょうか。
例えばプログラミングで、文字列の操作や日付の変換を行いたい時、「わざわざ自分でイチから作るのではなく、誰かがすでにライブラリを作っているのではないか」と類推しますよね。
品質改善の仕事でも同じです。問題が発生しているなら、何が原因かを特定し、優先度を決めて順次対応し、再発防止のルールを整備して周知する。対象が変わっても、この論理的なアプローチは汎用的に使えると信じています。
| ステップ | 具体的なアクション例 |
| 1. インプットの整理 | 前提条件、制約事項、最終的な目的を明確にする |
| 2. 論理的な道筋の設計 | 現在の状況から既知の状況を類推しつつ、インプットから目的のアウトプットに至るための、最も妥当な手順を導き出す |
| 3. 順次実行と仕組み化 | 原因特定 → 優先度付け → 実行 → チームへのルール整備・自動化という手順を踏む |
過去の経験を抽象化し、新たな領域の課題解決へ変換する思考プロセス
先ほどの論理的なアプローチは、特定の技術に依存しないため、ドメインが違っても応用できそうですね。実際に、過去のプロジェクトでの経験が全く別の現場で活きた具体的なエピソードがあれば教えていただけますか。
FXのシステム開発を経験した後に、ITコンサルティングの業務に携わった時期がありました。証券会社様向けに、内製システム開発のアーキテクチャや開発プロセスをコンサルティングする案件です。それまでの「システムを作る仕事」とは異なり、成果物はPowerPointでの提案書や報告書になりましたが、直面する技術的な課題の構造はシステム開発と非常に似ていました。
開発現場からコンサルティングへの転換ですね。成果物の形は全く違いますが、どのような部分に共通点を感じられたのでしょうか。
結局のところ、何を実現したいのかという要件があり、期間やリソースという制約がある。その中で全てをやりきれないなら、どう優先順位をつけるかという判断です。コンサルティングにおいても、現在の姿（As-Is）を把握し、理想の姿（To-Be）を描き、そのギャップをどう埋めていくかというロードマップを引く。この思考プロセスは、システム開発のアーキテクチャ設計や開発プロセスのマネジメントで培った考え方がそのまま活きました。
まさに経験の抽象化ですね。新しいプロジェクトに参画する際、この「As-Is」を正しく把握することが非常に重要になると思いますが、松本さんが最も時間をかけていることは何ですか？
一番時間をかけるべきなのは「コンテキストの把握」と「前提条件のすり合わせ」です。自分の中で想像上の前提を作って議論を進めると、大抵は外してしまいます。プロジェクトに途中から入る場合、過去に同じような議論がされていて、自分の知らない事情で結論が出ていることも少なくありません。いかに早く、既存のメンバーと同じ知識量と前提を持った状態になれるかが勝負ですね。
「想像で議論しない」というのは、頭では分かっていても焦りから陥りがちな罠ですよね。未知のプロジェクトに素早くキャッチアップするために、普段から実践している具体的な行動はありますか。
特別なことはしていませんが、既存のドキュメントがあれば徹底的に読み込みます。それでも分からない部分は絶対に出てくるので、有識者にヒアリングを繰り返す。そして、自分のキャッチアップの過程で得た知識は、後から来る人のために自らドキュメントにまとめて残すようにしています。
最近は生成AIを使って長文を要約させたりもしますが、まずは早期に自分の目で全体を通読することを重視しています。
ドキュメント化して後進に残すというのは、組織にとっても大きな財産になります。新しいチームに入った際、スキル面だけでなく、メンバーとの信頼関係を築くために心がけていることはありますか？
社内で名前や経歴だけが先行してしまい、必要以上に堅い印象を持たれてしまうことがありました。ですので、なるべく親しみやすい存在でいられるよう意識しています。例えばSlackなどのコミュニケーションツールでは、堅苦しくならないよう、少しフランクな投稿も交えたりしていますね。
ただ、オンライン上にしかいない得体の知れない人間にならないよう、なるべく早い段階で直接対面でコミュニケーションをとることも大切にしています。
| 取り組み | 目的と効果 |
| ドメイン知識の吸収 | 既存ドキュメントの精読。生成AIの要約機能も活用しつつ、早期の全体把握に努める |
| コンテキストのすり合わせ | 想像で議論せず、過去の経緯や制約条件を有識者にヒアリングし、認識のズレをなくす |
| 暗黙知の形式知化 | 自分が学んだ内容をドキュメント化し、後続メンバーのキャッチアップコストを下げる |
| 人間関係の構築 | Slackでの親しみやすい発信と、早期の対面コミュニケーションを組み合わせる |
あえて「キャリアのゴールを決めない」不確実な時代を生き抜くサバイバル能力
松本さんは「あえてキャリアのゴールを決めない」というスタンスだとお聞きしました。ゴールを定めずに、様々な領域や役割に挑戦し続けることで、結果としてどのような強みを得られたと感じていらっしゃいますか。
「未知の課題に直面しても、まあ何とかなるだろう」という適応力と心理的なタフさが身についたことですね。また、特定の領域にだけ強い専門性を持つのではなく、ジェネラリスト的に色々な役割をそれなりにこなせるため、会社やマネジメント層から見て、多様なプロジェクトにアサインしやすい人材になれたのではないかと思っています。
環境の変化に対する耐性が強いというのは、これからの時代において最大の武器になりそうですね。よく「技術を極めるか、マネジメントに進むか」で悩むエンジニアが多いですが、松本さんはその両方を往還されています。この点についてのお考えはいかがですか？
私自身は、技術とマネジメントに明確な境目があるとは思っていません。テックリードとして技術を牽引するにしても、チームメンバーやプロダクトのマネジメントは少なからず必要になります。
逆にマネージャーであっても、技術的な実現可能性や工数を理解していなければ、正しい判断や顧客への提案はできません。技術とマネジメントは相互補完的であり、本来はどちらもできるべきだと考えています。
なるほど。どちらか一方の道を選ぶのではなく、両方の視点を持つことがプロジェクトの成功に不可欠だということですね。シンプレクス社ならではの環境も影響しているのでしょうか。
そうですね。当社には一般的な階層型の管理職がなく、年次が上がれば必ずピープルマネジメントに専念しなければならない、という構造ではありません。プロジェクトマネジャーをやった後に、次のプロジェクトで一人の開発メンバーに戻ることも普通にあります。
役割が一方向ではなく、上にも下にも、右にも左にも行ったり来たりできる流動的な環境が、私のキャリア観に合っていたのだと思います。
それは非常に柔軟で刺激的な環境ですね。お忙しい実務の中で、AWSの全冠（全資格取得）やIPAの高度資格など、多数の資格を取得されているのにも驚きました。学習のモチベーションや時間をどのように確保されているのですか。
モチベーションに左右されて勉強しているというよりは、「業務上の必要性」を理由に仕事の一環として取得しています。例えばAWS全冠は、会社がAWSパートナーとしてのプレゼンスを高めるという目標があり、そこに貢献するための一環として達成を目指しました。
IPAのシステムアーキテクトなどの高度資格も、官公庁案件の入札において有資格者を体制に含めることが要件になることがあったため、必要に駆られて取ったという側面が強いです。
明確なビジネス上の目的があるからこそ集中して取り組めるのですね。実務に直結しない資格学習もあるかと思いますが、そうした学習はキャリアにどう活きていますか？
実務で直接役立つかは資格によりますが、「体系的な知識を一定期間で身につけ、アウトプットできる状態にする」という訓練としては非常に有効です。これは新しいプロジェクトに入ってキャッチアップする際のプロセスと全く同じなんです。資格学習を通じて、新しい概念を素早くインプットし構造化する「メタ学習能力」を鍛えることができると考えています。
技術が変わっても求められ続ける、エンジニアの「普遍的なコアスキル」
技術トレンドが目まぐるしく変わる中で、環境が変わってもエンジニアに「変わらず求められ続けるスキル」とは何だとお考えですか？
逆説的かもしれませんが、「エンジニアであることにこだわりすぎないこと」だと思っています。もちろん、私はエンジニアという職種に愛着はありますが、エンジニア以外の仕事を任されても対応できるような、ビジネスパーソンとしての基礎力を身につけることが最も重要です。時代によって「エンジニア」という言葉が指す範囲もどんどん変化していますからね。
たしかに、昔と今では「エンジニア」の定義自体が変わってきていますね。具体的にどのような変化を感じていらっしゃいますか？
昔は特定の技術のコードを書くことだけに特化した人も多かったかもしれませんが、今は技術領域で言えばフロントエンドからサーバー、インフラまで、開発工程で言えば要件定義からテスト、運用保守まで一気通貫でこなせるようなフルスタックエンジニアが当たり前に求められています。
さらに最近では、そこへ生成AIを使いこなすスキルも加わり、顧客の現場に入り込んでシステムの活用をサポートするフォワードデプロイエンジニアのような役割も登場しています。自分が「ここまでやればいい」と思っている範囲に固執せず、メタな能力を広げていく柔軟性が必要です。
現場で使われているAIがさらに進化していくと、エンジニアにはどのような役割が残るのでしょうか。
AIエージェントを束ねる「マネジメント力」と、最終的な「要所を見抜く力」が人間の仕事になります。複雑に絡み合った大きなタスクを分解し、複数のAIにどういう順番で処理させれば手戻りがないかという段取りを設計する力です。
そして、AIはそれっぽいものを出力してくれますが、最終的に作られるシステムを使うのは人間のユーザです。品質や機能性など、ユーザが本当に気にするポイントを人間がしっかりと見極める必要があります。
AIのディレクションと、品質の最終担保がエンジニアの価値になっていくのですね。最後に、今後のキャリア戦略に悩んでいる読者に向けて、背中を押すアドバイスをお願いします。
今の自分の役割や「エンジニアとはこういうものだ」という枠に縛られず、様々な領域に越境して挑戦してみてほしいですね。そこで得た経験や論理的な課題解決のアプローチは、業界や技術が変わっても必ず活きる普遍的な武器になります。技術の進化を楽しみながら、変化を恐れずに新しい環境に飛び込んでいっていただきたいです。
ライター
