面接で最も見極めるべきは、財務と人事のトップ。確かめることは、たった1つです　【フェーズ4-9｜ITエンジニアの卵に贈る、就活の書】

【お知らせ】本連載は、2026年9月20日に全記事を全面アップデートしました。

　この記事は本気でITエンジニアになりたい！ という学生さんたちに向けて就活プロセスを伝える「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。

　エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。

　ITエンジニアの卵に贈る、就活の書・フェーズ4-9の記事です。前回のフェーズ4-8では、最終面接（社長・役員層）のお話をしました。

　最初に、この記事の結論を置きます。

　この記事は、シリーズの中でも特別篇です。ほかの記事は、みなさんが何を作り、何を語るかの話でした。この記事だけは、相手が何者かを確かめる話です。

　言いたいことは、4つだけです。

1. 財務担当取締役は、社内最強のエンジニアでなければならない。そして同時に、最強のMBAでもあること

2. 人事のトップも、同じである。上の役職は、下の役職の上位互換であるべきだから

3. 面接では、出てきたその人が、エンジニアであるかどうかを見極める

4. もしエンジニアでなかったら、撤退を考えてよい

　財務も人事も、学生のみなさんには縁のない世界だと思います。専門用語は、そのつど短く言い換えながら進めます。知識は要りません。確かめるのは、その人がエンジニアかどうか。それだけです。

　そして、先にお断りしておくことが1つあります。この記事は、財務担当取締役や人事のトップという席が実際に置かれている会社を想定して書いた部分が多くあります。社員が数十名の会社では、その席はありません。役員が社長と専務の2人だけ、という会社はごく普通です。その場合にどう読み替えるかを、1-5に書きました。そちらを先に読んでいただいても構いません。

この記事のポイント

• いちばん厳しく見極めるべき相手は、社長でもCTOでもなく、財務担当取締役と人事のトップです。会社の将来を左右する技術投資は、取締役会で決議されます（会社法362条4項）。

• 確かめることは1つだけ。その人がエンジニアか。自社の技術を自分の言葉で説明できるか、この半年で何を作り読み書いたか、技術の判断をどこを見て決めたか。この3つで測ります。

• 二度聞いても自分の言葉で答えが返らなければ、内定を待たずに撤退を検討してよい。ただし、その人が面接に出てこなかったこと自体は、判断材料にしません。

1. 財務担当取締役は、社内最強のエンジニアでなければならない

　みなさんが入ろうとしているのは、IT企業であり、テック企業です。技術で価値を作り、技術で稼ぐ会社です。その会社の意思決定の席に、技術が分かる人が一人もいない。この状況が構造としておかしいということは、フェーズ1からフェーズ3を歩いてきたみなさんなら、もう分かるはずです。

　そのうえで、この記事でいちばん強くお伝えしたいことを書きます。いちばん厳しく見極めるべき相手は、社長でも、CTOでも、部課長でもありません。財務担当取締役です。

　ここで、あえてCFOではなく、財務担当取締役と呼びます。CFO（Chief Financial Officer）は会社のお金の責任者を指す呼び方ですが、日本の会社法に定めのある役職名ではありません。管理部長、経営管理担当といった呼び方の会社もあります。

　取締役、と言い切る理由があります。大きな意思決定は、取締役会で決議されるからです。会社法は、多額の借財や重要な財産の処分といった重要な業務執行の決定を、取締役会が行うものと定めています（会社法362条4項）。会社の将来を左右する規模の技術投資は、ここに乗ります。議席のない人は、その決議に加われません。これは、フェーズ4-2の3章で書いた決裁の線の、いちばん上の階での話です。肩書きではなく、どこに線が引かれていて、その人がどちら側にいるか。会社の最上位では、その線が取締役会の議席という形をとります。だから、みなさんが見るべきは「CFOという肩書きがあるか」ではなく、財務を担う人が、取締役会に議席を持っているか。そして、その人が技術を分かっているかです。

　もうひとつ、先にお伝えします。財務と総務・人事を、まとめて1人の取締役が担当している会社も、たくさんあります。「財務・総務担当取締役」「管理本部長」といった呼び方です。その場合、この記事でこれから書く2つの確認は、同じ1人に対して行うことになります。確かめる中身は変わりません。むしろ、1人がバックオフィス全体を見ている会社ほど、その人がエンジニアであるかどうかは重く効きます。

　なぜこの人がいちばん見落とされるのか。社長とCTOは、放っておいても学生さんの視界に入ります。部課長は、面接の回数が多いぶん、情報が自然に集まります。財務担当取締役だけが、見られないまま素通りされる。それでいて、技術投資にお金を出すかどうかを最後に決めているのは、その人です。

1-1. 財務担当取締役は、社内すべての起案を、財務の立場から技術的にレビューできる技術者である

　CTOがどれほど優れた技術投資の提案をまとめても、それを審査してお金を出すかどうかを判断するのは、財務担当取締役です。稟議（りんぎ）というのは、社内でお金を使うときの申請の仕組みで、上の人が順に承認していきます。

　そして、審査する相手はCTOだけではありません。社内のあらゆる部署から、お金を使う起案が上がってきます。営業が入れたいSaaS。人事が入れ替えたい勤怠システム。経理が使い続けている会計パッケージの更改。情報システム部門のネットワーク投資。工場や現場の設備。そのどれもが、いまはソフトウェアとデータの話です。財務担当取締役は、その全部を、財務の立場から技術的にレビューする立場にいます。

　技術の中身を理解せず、レビューする力もないままに技術投資を承認するというのは、内容を検証せずに稟議書に印鑑を押しているのと同じです。これでは、良い提案と悪い提案の区別がつきません。声の大きさや政治力で予算が動く組織になり、本当に必要な投資が通らず、目先の見栄えだけの投資が通ってしまいます。

　念のため、正確に申し添えます。技術が読めなくても、間接的な検証はできます。誰の意見を信用するか、過去の見積もりが当たってきたか、回収の実績はどうか。ただし、それは人と実績を通した検証であって、提案そのものの質を見る検証ではありません。目の前の1件が良い投資かどうかは、中身を読める人にしか分かりません。

　ここから先は、統計ではなく、私が20年以上のあいだに見てきた範囲での実感としてお伝えします。強いIT企業では、財務担当取締役こそが社内でいちばん技術に詳しい人物である、ということが珍しくありませんでした。技術投資の妥当性を数字と実装の両方から見抜き、時にはCTOの提案に鋭い技術的な指摘を返す。そういう会社は、意思決定の質そのものが違います。

1-2. 財務担当取締役は、会社をまるごとデザインし、実装するアーキテクトである

　もう一段、踏み込みます。理想として掲げたい財務担当取締役の像は、「技術がそこそこ分かる財務の人」ではありません。社内で最もシステムに詳しい人間です。

　理由は単純です。会社の数字は、システムから出てきます。会計、販売管理、勤怠、原価計算、データ基盤。どこにどんなデータが、どんな粒度で、どんな整合性で溜まっているのかを知らないまま、その数字の意味を保証することはできません。数字に責任を持つとは、その数字を生み出す仕組み全体に責任を持つということです。

　だから、その人は会社丸ごとのアーキテクチャを描ける、一級のアーキテクトであるはずです。事業構造と、業務プロセスと、システム構成と、データの流れを、一枚の絵として頭の中に持っている人。必要なら、片手間に自分でシステムを組んで動かしてしまえる人。数字は計算できるけれど、企業のアーキテクチャは描けない。システムも作れない。コードの1行も書けない。技術で稼ぐ会社の、技術投資の最終決定者が、それでいいのか。

1-3. 求められるのは、最強のエンジニアであり、最強のMBAであること

　では、その人は何を持っているべきなのか。具体に落とします。エンジニアとしてのスキルセットと、経営としてのスキルセットの、両方です。

　MBAについては、フェーズ4-2で触れました。Master of Business Administration、日本語では経営学修士。会計、財務、戦略、マーケティング、組織、オペレーションといった、経営に必要な知識を体系として学ぶ大学院の学位です。ここでも、学位そのものというより、そこで扱われる知識と技能のまとまりを指す言葉として使います。

　フェーズ4-2で書いたとおり、課長から上は、事業を経営する側に入る以上、この範囲が実務として必須になります。裏を返せば、課長より上の役職者は、MBAで扱う範囲を、なんらかの形で持っているのが前提だということです。取締役なら、なおさらです。だから、この記事で問うのは、経営の側ではありません。エンジニアの側が欠けていないか、です。

エンジニアの側。社内最強のエンジニア組織を、率いるに足るだけの厚みです

• ソフトウェアエンジニアリングの基礎：設計し、実装し、テストし、レビューを受ける。この一巡を、自分の手で通ってきている

• データモデリングとクエリ：全社のデータが、どのシステムに、どんな形で溜まっているかを頭の中に持っている。必要なら自分で引く

• 会社全体の設計：業務、データ、アプリケーション、インフラの4つの層で、会社を一枚の絵として描ける（エンタープライズアーキテクチャと呼ばれる考え方です）

• システムの選定と刷新：要件を自分の言葉で書き、内製と外部サービスを天秤にかけ、移行の計画を立て、ベンダーと対等に交渉する

• 統制とセキュリティ：不正やミスが起きないよう会社の中に仕掛けておく歯止め（アクセス権限、変更の記録、申請する人と承認する人を分けること）を、システムの設計として理解している。どこが危ないかを、構成図の上で指させる

• 品質と信頼性、そして自動化：止まらない仕組みをどう作り、止まったときどう戻すか。手作業で回っている工程を見つけて、自分で潰しにいける

• 見積りと技術的負債：技術投資の効果を、実装の難易度と、負債の返済コスト込みで読める

　これは、外から眺めて「技術が分かる」という水準の話ではありません。バックオフィスという社内最強のエンジニア組織の中で、自ら手を動かし、あるいはその組織を管掌してきた人が、仕事の結果として身につけているものです。

経営の側。MBAで扱う領域と、ほぼそのまま重なります

• 会計：損益計算書、貸借対照表、キャッシュフロー計算書のつながりを、数字で動かせる。原価と、1件あたり・1人あたりの採算で、事業の構造を見る

• お金の設計と投資判断：株を出すか借りるかを決める。かけたお金が何年で戻るかで、投資の可否を決める

• 経営戦略：どこで戦い、どこで戦わないかを決める。技術投資は、その選択を実行する手段

• 組織と人への投資：人への投資を、コストではなく資本として扱う

• 説明する責任：株主や社会に対して、数字の意味を説明する責任を負う

　そして、MBAで扱う知識は、バックオフィスでこそ日常の道具になります。会計も、資金繰りも、投資判断も、組織設計も、開示も、実際に手を動かしているのはバックオフィスです。開発チームにとっては時々必要になる知識が、ここでは毎日使う知識になる。エンジニアリングとMBAの掛け算がいちばん効くのが、この2人の席です。

　最強のエンジニアであり、同時に最強のMBAであること。ずいぶん高い要求に見えると思います。ただ、この2つを別々の人が持っていると、そのあいだに翻訳が挟まります。翻訳のたびに、技術の必然性は落ち、数字の切実さも落ちる。1人の頭の中で両方が繋がっているとき、技術投資の議論は、翻訳ロスなしに数字になります。だから、この2つは足し算ではなく、掛け算です。

　この要求が無茶に見えた方へ、もうひとつ。財務担当取締役は、バックオフィスの中でキャリアを積んできた人であることが、珍しくありません。経理や情報システム、人事の実務を通り、会社の仕組みを内側から作り直しながら上がってきた人たちです。つまり、社内で最も技術が要る集団の中で、MBAの知識を毎日使うルートを歩いてきたということになります。

　そう考えると、最強のエンジニアであり最強のMBAであるというのは、無理な要求ではありません。そのルートを正しく歩いてきた人なら、自然に備わっているスキルセットです。持っていないとしたら、それは要求が高すぎるのではなく、どこかで技術を降りた、ということです。

1-4. 肩書きがなくても、その機能は誰かが担っています

　みなさんが受ける会社に、財務担当取締役やCFOという肩書きの人がいないことは、まったく珍しくありません。従業員数十名の会社では、財務は社長が兼ね、人事は総務部長が兼ねているのが普通です。そもそも取締役会を置いていない会社もあります。肩書きがないこと自体は、何も悪いことではありません。

　確かめてほしいのは、肩書きではなく、機能を誰が担っているかです。技術投資にお金を出すかどうかを、最後に決めているのは誰か。エンジニアの評価と昇給を決めているのは誰か。この2つの問いには、どんな規模の会社にも、答えがあります。「決めている人はいません」という会社は、存在しません。

　だから、こう聞いてください。

• 「技術投資の予算を、最終的に承認されるのはどなたですか」

　この記事でこれから書く問いは、すべてその人に向けたものです。役職名は関係ありません。

　なお、「その方と、選考の中でお話しする機会をいただけますか」と続けるかどうかは、慎重に決めてください。面接の回数が案内で決まっている選考で学生がこれを言うと、選考の進め方への注文になります。答えは前半だけで返ってきますし、規模の小さい会社では、答えはたいてい「社長です」で、その社長とはすでに会う予定が組まれています。

1-5. 役員が2〜3人の会社を受ける方へ

　ここが、この記事でいちばん読み飛ばされやすく、いちばん多くの方に当たる節です。

　社員が数十名の会社では、財務担当取締役も、CFOも、人事のトップも、いません。役員紹介ページに載っているのは社長と専務の2人だけ。面接は2回、出てくるのは人事と現場、そして社長。この記事がここまで「主役」と定めてきた2人が、選考のどこにも存在しない。そういう方に向けて、読み替えを書きます。

1-5-1. 読み替え1：取締役会の議論は、いったん脇に置いてください

　1章で会社法362条4項を持ち出しました。ただし、取締役会を置いていない会社では、この論拠はそのまま当たりません。取締役会の設置が義務づけられるのは公開会社などに限られ、規模の小さい会社では置いていないほうが普通です。

　その場合、議席の話は消えて、話は単純になります。決めているのは、たいてい社長1人です。ですから、この記事の問いは、全部その1人に当たることになります。

1-5-2. 読み替え2：財務と人事の「機能」を、社長に当てる

　1-4で書いたとおり、肩書きがなくても機能は誰かが担っています。規模が小さいほど、その誰かは社長に集中します。技術投資を決めるのも社長。評価を決めるのも社長。だから、7章の問いは、そのまま社長に当ててよいことになります。

　ただし、当て方には注意が要ります。社長が営業出身であることは、この規模ではごく普通のことで、構造がおかしいという話ではありません。7-1の危険度の注記を、必ず読んでから使ってください。

1-5-3. 読み替え3：いちばん効く観測は、現場の社員への問いです

　そして、ここがこの節の結論です。役員に会えない、あるいは会っても1人だけ、という選考で、バックオフィスの実態をいちばん正確に運んでくるのは、現場のエンジニアです。

　一次面接に現場の方が出てくるなら、そこが最良の機会です。次の2問を持っていってください。

• 「入社されてから、社内の手続きで困ることはありますか」

• 「社内で使っている仕組みを、直近1年で入れ替えられたものはありますか。どなたが決めて、どなたが入れられたのですか」

　この2問は、聞いても角が立たず、しかも答えがそのまま実態です。前者で、承認待ちや紙の申請がどれだけ日常を食っているかが分かります。後者で、社内の仕組みを自分たちで直せる会社か、外に丸投げしている会社かが分かります。「自分たちで入れ替えました」と返ってくるなら、その会社のバックオフィスは動いています。「よく分かりません」「昔から使っています」なら、そこは止まっています。

　現場のエンジニアは、この話をたいてい正直にしてくれます。自分が毎日困っていることだからです。

1-5-4. 読み替え4：受託開発が中心の会社では、見る場所が変わります

　この記事は、自社でプロダクトを持つ会社を前提に書いた部分があります。受託開発が中心の会社では、技術投資の多くが客先の案件の中で動きます。社内の技術投資の規模は、そのぶん小さくなります。

　ですから、受託が中心の会社では、聞く先を変えてください。

• 「社内の開発環境や検証環境は、どなたが決めて、どなたが用意されていますか」（客先の環境ではなく、自社の話として聞きます）

• 「案件と案件のあいだの時間は、何に使われていますか」（ここに学びの時間が置かれているかどうかが、その会社の技術への姿勢です）

• 「技術的負債の返済に、専用の工数や予算がついていますか」（「負債はお客様のものです」と返ってくるなら、それも1つの答えです）

　受託であること自体は、良いも悪いもありません。見る場所が違うだけです。

2. 人事のトップも、同じです

　もう一人が、人事のトップです。エンジニアの評価制度、キャリアパス、採用基準、育成方針を設計するのは、多くの場合、人事です。

　はっきり書きます。人事がエンジニアの仕事を分かっていない会社で、エンジニア組織がうまく回っている例を、私は見たことがありません。近年はHRBP（事業部門に張り付いて、その部門の人事を担当する人）という役割を置く会社も増えました。人事はもう、勤怠と給与の手続きをする部署ではなく、企業戦略そのものの一部です。採用計画も、評価制度も、育成への投資も、事業戦略を実行する手段として設計されます。

2-1. 評価制度は、人が動くシステムである

　エンジニアのみなさんに、いちばん伝わる言い方をします。評価制度は、仕様です。

　誰の、どんな行動を、どんな基準で、いつ測り、いくらに換算するのか。それを文書として定義し、全社に配り、毎年動かす。要件を定義し、設計し、実装し、運用し、改訂していく。やっていることは、システム開発とまったく同じです。違うのは、その上で動くのが機械ではなく、人だということだけです。

　だから、曖昧な仕様は、現場を壊します。何が評価されるのか分からない制度の下では、人は評価されそうなことだけをやるようになります。そして、仕様に書かれていない仕事は、存在しないことになります。

　この視座を持たない人が制度を設計すると、こうなります。コードレビューや技術学習の時間を「売上に直接つながらない時間」として評価から外す。技術的な難易度を無視して、片づけたタスクの件数だけで評価する。悪意からではありません。理解の不足から生まれます。そして、その仕様の上で動かされるのは、みなさんです。

2-2. 人事のトップは、人と組織をまるごと設計するアーキテクトである

　もうひとつ、財務担当取締役と同じ構造があります。人事の数字も、システムから出てきます。

　採用管理、タレントマネジメント、評価のワークフロー、勤怠、労務、学習管理。人事の実務は、いまはそのほとんどがシステムの上に乗っています。離職率も、平均勤続年数も、育成への投資額も、そこから出てくる数字です。どのシステムに、どんな粒度で、どんな定義でデータが溜まっているのかを知らないまま、その数字を人事施策の根拠にすることはできません。

　近年はピープルアナリティクスという言葉もあります。人のデータを分析して、組織の意思決定に使うという考え方です。ここで問われるのは分析の技法よりも先に、そもそも何を、どう定義して記録するかという設計です。これは、データモデリングそのものです。

　だから、人事のトップもまた、人と組織をまるごと設計するアーキテクトであるはずです。等級と報酬のテーブル、キャリアの階段、育成の道筋、その全部を一枚の絵として持ち、システムとデータの上に載せて回している人。

2-3. 求められるのは、一級のエンジニアであり、人と組織のプロフェッショナルであること

　財務担当取締役と同じく、両側から書きます。

エンジニアの側

• エンジニアリング組織を率いる視座：VPoE（エンジニア組織のマネジメント責任者。CTOが技術の方向、VPoEが人と組織を見る分担が一般的です）やテックリード（チームの技術の舵取りをする先輩エンジニア）が持っている見え方。チームの生産性がどこで詰まるのか、技術的負債が人の時間をどう食うのか、設計とレビューにどれだけの時間が要るのか

• エンジニアの成長曲線の理解：何年目に何ができるようになり、どこで壁に当たるのか。育つのに時間がかかる能力と、すぐ身につく能力の区別がついている

• 知識体系にもとづく育成設計：思いつきの研修ではなく、技術の知識体系に沿った育成の道筋を描ける

• 指標の使い方と、その誤用の理解：Four Keysのような数字を、チームの改善に使うのか、個人の評価に流用してしまうのか（Four Keysは、デプロイ頻度、変更のリードタイム、変更障害率、復旧時間という、開発チームの速さと安定を測る4つの指標です）。この違いが分かること自体が、技術への理解の証明です

• 人事システムとデータの設計：どのデータを、どう定義して記録するか。分析より前の、この設計ができる

人と組織の側

• 労働法規と労務：労働時間、契約、安全衛生。守るべき線を、制度として実装できる

• 等級・評価・報酬の設計：何を価値とするかを、テーブルと基準に落とす

• 採用の設計：どんな人を、どんな基準で、どう見極めるか。現場と一緒に作れる

• 組織開発：チームの形と、そこで起きることの因果を扱える

• 人的資本の開示：人への投資を、社外に説明できる数字にする

　評価制度は、その会社が何を価値とするかの宣言です。技術の価値が分からない人が書けば、技術の価値は、その宣言に載りません。だから人事のトップにも、エンジニアであることを求めます。

3. 上の役職は、下の役職の上位互換であるべきです

　フェーズ4-2で置いた原則を、ここでもう一度使います。上の役職は、下の役職の上位互換であるべきだ、ということです。

　課長はメンバーができることが当然できて、そのうえでチームの責任を負う。取締役は部長ができることが当然できて、そのうえで会社の責任を負う。上に行くほど責任の範囲が広がるのであって、できることが減るのではありません。

　だから、選考を通して、面接の階層が上がるにつれて技術の話が深くなっていくかを見てください。これが、この原則を確かめる道具です。上に行くほど話が抽象的になり、技術の具体が消えていくなら、それは面接官の個性ではなく、その会社の構造です。

　逆に、上に行くほど技術の話が鋭くなる会社があります。そういう会社では、みなさんが5年後、10年後に上を目指すとき、技術を捨てずに上がれる道が、すでに通っているということです。

4. この2人が率いるバックオフィスは、社内最強のエンジニア集団である

　この2人が率いているのは、バックオフィス（経理・財務・人事・法務・情報システムなど、社内を支える部門）です。そして、そこは本来、社内で最も技術が要る場所であり、最強のエンジニア集団であるべき場所です。

　かつて、情報システム部門は、社内の花形と呼ばれました。計算機を扱えるのが限られた人たちで、会社の中枢の仕組みを預かっていたからです。その位置づけは、いまも変わっていません。むしろ、重要性は増しています。会社のあらゆる業務がソフトウェアの上に乗った時代に、その全体を握っているのですから。

　IT企業のバックオフィスは、自社の中のデジタル化とDXを推進する部署です。会計も、勤怠も、稟議も、契約も、採用も、実体は業務プロセスとデータとシステムです。それを自分たちで設計し、選び、入れ替え、回している。組織としても、活動としても、技術としても、強いのが、本来の姿です。

　だから、良い会社のバックオフィスは、ある意味で開発チームよりも先端です。開発チームが向き合うのはお客様に届けるプロダクトですが、バックオフィスが向き合うのは自分たちの会社そのものです。要件を出す人と、使う人と、直す人が、同じ会社の中にいます。改善のループが、とにかく速く回せる。猛烈な勢いで改善を回している部署が、開発チームのほかにもう1つある。そういう会社は、強いです。

　私が見てきた範囲では、強い企業はバックオフィスも強い。そして、その集団を率いるのが、財務担当取締役と人事のトップです。これが、この2人にエンジニアであることを求める理由です。同時に、この集団は、会計も人事も法務も、経営の実務そのものを回している場所でもあります。エンジニアリングとMBAの両方が要るのは、ここが両方の交差点だからです。逆に、バックオフィスが事業から切り離されている会社では、現場のエンジニアが、承認待ち、紙の申請、通らない稟議、実態に合わない評価制度に、日常的に時間を奪われます。エンジニアの生産性を決めるのは、開発環境の性能だけではありません。その会社の意思決定の速さが、同じくらい効きます。

5. 面接で確かめるのは、たった1つ

　では、何をもって「エンジニアである」と言えるのか。ここが、この記事の蝶番です。

　序章-1で置いた定義を思い出してください。プロフェッションとは、知識体系を持ち、生涯にわたる自己研鑽を職業上の責任とし、自分の判断に責任を負う職業のことです。学位でも、肩書きでも、昔の経歴でもありません。いま、そう振る舞っているかです。

　ただ、これを面接でそのまま測ることはできません。だから、観測できる形に置き換えます。

• 知識体系を持っているか → 自社の技術とシステムを、自分の言葉で説明できるか

• いまも自己研鑽しているか → この半年で、何を作り、何を読み、何を書いたか

• 判断に責任を負っているか → 技術の判断を、どこを見て決めたかを語れるか

　この3つが、みなさんが実際に当てる線です。実装できるかではありません。説明できるか、続けているか、決めた理由を語れるか。この3つなら、財務のことも人事のことも知らなくても、聞けば分かります。

　人事のトップにも、同じ3つを当てます。ただし1つ目だけ、対象が変わります。自社の技術ではなく、エンジニアがどう育ち、どこで詰まるのかを、自分の言葉で説明できるかです。

　もちろん、それぞれの役割ならではの観点も要ります。財務担当取締役には、投資の判断の仕方。人事のトップには、制度の設計。ただし、順番を間違えないでください。まずエンジニアであるかを確かめ、そのうえで役割の観点を見る。この順です。

6. 面接の前に、5分でできること

　「そもそも財務担当取締役に会えるのか」と思ったはずです。わざわざ会いに行くわけではありません。この2人を計る場は、役員面接・最終面接と、人事面接です。選考の流れの中に、すでに用意されています。

　ただし、財務担当取締役が新卒の面接に出てくるとは限りません。出てこないこと自体は、判断材料にしないでください。1-4の質問は、会えなくても「誰が決めているか」の答えを連れてきます。

　そして、その面接の前に、かなりの部分が机の上で埋まります。プロフェッションは、痕跡を残します。次の4つは、いますぐ、無料で、5分でできます。

• 役員紹介ページで、財務担当取締役と人事のトップが誰かを特定する。名前が分かれば、この先の確認はその2人に絞れます。役員一覧に財務の担当が見当たらない会社もあります。その場合は、誰が兼ねているのかを、1-4の質問で聞いてください

• その2人の経歴を、時系列で読む。技術の現場を通ってきたのか、通っていないのか。通っていないなら、いまどう補っているのかが、そのまま面接での問いになります

• その2人の名前で検索して、直近半年に何か書いているかを見る。技術の話でなくても構いません。実名で、自分の専門を、外に向けて説明し続けているか。何も出てこないなら、それも1つの事実です

• その2人の技術ポートフォリオを確かめる。フェーズ2-2でお話しした公開・質・第三者の目利きという3条件は、経営層にもそのまま当たります。ただし、観る場所は職位によって変わります（次に分けて書きます）

　勉強会への参加は、たいてい無料です。ですから、名前が1つも出てこないことを、費用の問題として説明することはできません。お金がないのではなく、そこに時間を使っていない、ということです。

　ただし、観測の精度だけ、正確に添えます。外から見えるのは「名前が出てこない」ことであって、「出ていない」ことではありません。記録を残さずに参加している人はいます。だから、埋まらなかったところは、面接で直接聞いてください。

　4つ目の技術ポートフォリオは、見る場所を3段に分けます。

• 実践者としての痕跡：connpass、GitHub、技術ブログ、Speaker Deck。個人の名前で出てこなければ、会社名でも調べてみてください

• その職位ならではの場での登壇と、団体での役職：役員クラスが登壇するカンファレンスの記録は、主催者のサイトに残ります。財務なら日本CFO協会、人事なら日本CHRO協会や日本の人事部、技術なら日本CTO協会。これらの団体は、理事・監事・委員の氏名を公式サイトで公開しています。学会（情報処理学会、日本ソフトウェア科学会など）も同様です。名前で検索すれば出てきます

　ここで、正確に言っておきたいことが2つあります。

　1つは、会員かどうかは、外からは確認できないということ。多くの団体が個人会員の名簿を公開していないからです。しかも日本CFO協会や日本CHRO協会の個人会員は職務経験の要件がなく、誰でも入れます（日本CTO協会だけは例外で、個人会員はCTO職務経験者の審査制です）。外から確かめられるのは、役員や委員としての氏名と、登壇の記録。この2つだけです。

　もう1つは、見つからないこと自体は、減点材料ではないということ。学会や協会の役員は業界の中での選出ポストで、優れた実務家でも就いていないほうが普通です。とくに、規模の小さい会社の役員が、ここに名前を残していることは、まずありません。見つかったときに強い加点材料になる、そういう種類の情報です。当たらないと分かっているなら、この段は飛ばして構いません。

　そして、いちばん大事なことを。ここで埋まらなかった空欄が、そのまま次章で持っていく問いになります。全部を調べる必要はありません。調べて分からなかったことを、本人に聞けばいいのです。

7. 面接で聞く

　机の上で立てられるのは、仮説までです。役員に技術の経歴がない、GitHubに何もない。そこから言えるのは「たぶんこうだろう」までで、断定ではありません。その仮説を本人に当てる場が、役員面接であり、人事面接です。

　問いの設計の原則は、ひとつです。

　「どうお考えですか」は、いくらでも語れます。「昨年度、何件でしたか」は、語れません。

　持っていくのは2問で十分です。逆質問の時間は、実際には3〜5分しかありません。1問目は、7-1から選んでください。2問目は、6章で調べて分からなかったことを、そのまま聞けばいい。前置きの型を3つ置いておきます。「差し支えなければ」「勉強のためにお伺いしたいのですが」「入社後の働き方を具体的に想像したいので」。問い詰めるのではなく、敬意を持って、対等に。

　そして、先に危険度をお伝えします。このあと並べる問いには、相手個人の能力を測る形になるものが混ざっています。会社のことを聞く問いは、たいてい角が立ちません。相手個人の実践を問う形は、当てる相手を選びます。どれがどちらかは、各問いに書きました。

7-1. まず、エンジニアであるかを確かめる（財務にも人事にも、同じ3問）

　この記事の主題は、ここです。5章の3つに、そのまま対応しています。

　順番は、下から使ってください。3つ目がいちばん安全で、いちばんよく効きます。

• （危険度：低）「御社の技術やシステムのことで、いまいちばん危ういと感じていらっしゃるのは、どのあたりですか」（知識体系を観る問いです。人事の方には「エンジニアの育ちで、いちばん詰まりやすいのはどこですか」と置き換えます）

  • 1問しか投げられないなら、これにしてください。弱点を具体で言えるのは、中身を知っている人だけです。知らない人は、ここで一般論に逃げます。しかも、形としては「課題を教えてください」なので、誰に当てても角が立ちません。

• （危険度：中）「技術投資を判断されるとき、どこを見て決めていらっしゃいますか。差し支えなければ、直近の1件で教えてください」（判断の責任を観る問いです。人事の方には「評価制度を設計されるとき」と置き換えます）

  • 決めている本人に当てるなら、自然な問いです。「直近の1件で」がやや踏み込むので、前置きを添えてください。

• （危険度：高）「ご自身が技術に触れていらっしゃるのは、どんな場面ですか。この半年で手を動かして作られたものがあれば、教えてください」（自己研鑽を見る問いです）

  • これは、当てる相手を選びます。財務担当取締役や人事のトップに、この記事の文脈で当てるなら成立します。しかし、規模の小さい会社の社長に当てると、事故ります。営業から会社を作ってきた社長に、学生が「最近コードを書かれましたか」と聞く形になるからです。社長が技術出身だと分かっている場合を除いて、この問いは使わないでください。代わりに、危険度の低い1つ目を使ってください。

7-2. そのうえで、役割ならではの観点を見る

　エンジニアであることを確かめたら、次に役割です。

財務担当取締役へ

• 「エンジニア一人あたりの、昨年度の教育研修費の実績額を教えてください。予算ではなく、実績で」

• 「技術的負債の返済に、専用の工数や予算がついていますか。ついていない場合、その作業はどの時間で行われていますか」
  　PCについては、聞くより見てください。社員が使っているPCの購入年とメモリ容量は、一切ごまかせない事実で、しかもオフィスを見学すれば見えます。金額としては小さい話なのに、そこに手が回っていない会社があります。見て分かることを、わざわざ質問に使わないでください。質問の枠は、見て分からないことに使います。

人事のトップへ

• 「評価制度は、文書として全社員に配布されていますか。最後に改訂されたのは、いつですか」

• 「コードレビューや技術学習といった、直接の成果物に見えにくい時間を、どう評価に組み込んでいますか」

• 「デプロイの頻度や、障害から戻るまでの時間のような数字は、社内で追っていらっしゃいますか。その数字を、個人の評価にはどう扱っていらっしゃいますか」

• （危険度：中）「資格取得の支援制度には、どういう資格が入っていますか。一覧はありますか」

　資格の問いは、名指しをやめて、一覧を聞く形にしてください。見たいのは、社員が何を目指せるかの一覧が、誰かの判断で作られているかどうかだからです。一覧が出てくれば、その中身で判断できます。

　なお、技術士（科学技術の分野で、国が認めた最上位の技術者資格です）を名指しで聞くのは、相手を選びます。情報工学部門の第二次試験の合格者は、令和7年度で全国18人です（序章-2）。一覧に入っていないのが普通なので、名指しで聞くと「なぜそれを」となり、意図が伝わらないまま終わります。一覧を見せてもらって、入っていたら加点。それで十分です。

　Four Keysの問いにも、補足が要ります。指標の名前を出さずに聞いてください。「デプロイの頻度や、障害から戻るまでの時間のような数字は、社内で追っていらっしゃいますか」。名前を出すと、学生が横文字で経営者を試す形になります。そして、これはチームの改善のための指標で、個人評価に持ち込むと数字合わせが始まります。「チームの改善に使っていて、個人の評価には直結させていません」。こう答えられたら、それが最も見識のある答えです。

8. 答えの読み方

8-1. 逃げの答えの、5つの型

1. 丸投げ型：「そこは情報システム部門に任せています」「技術のことはCTOが」。任せること自体は普通です。危ういのは、任せた先の中身を一切語れないこと

2. 役割分担型：「数字のプロと技術のプロで、役割分担していますので」。聞こえは良いのですが、技術投資を決める人が技術を分からないという構造を、そのまま肯定しているだけです

3. 世代型：「そういう新しいことは、若い人たちに任せています」。学ぶことを降りた、という宣言です。生涯にわたる自己研鑽を職業上の責任とする序章-1の視座から、いちばん遠い答えです

4. 標語型：「弊社はエンジニアを大切にしています」。制度と数字の話が続かないとき、この言葉は中身の代わりに置かれています。大切にしている会社は、大切にした結果を、金額と日数と回数で語れます

5. 論点ずらし型：「そのご質問は、また別の機会に」「まずは弊社の魅力からお話ししますね」

　1つの型が1回出ただけで断じる必要はありません。同じ人の答えに、2つ以上の型が重なったときが、判断のときです。

8-2. では、良い答えとは

　良い答えには、この3つのどれかが入っています。

• 固有名詞：使っている製品名、システム名、案件名が出てくる

• 数字か日付：「昨年度は一人あたり3万2千円です」「最後の改訂は2025年4月です」

• できていないことの自白：「予実の突き合わせは、いまも月次で手作業が残っています」「実績はゼロでした。来期から付けます」

　3つ目がいちばん大事です。自社の弱いところを、数字で言える人は、その数字を見ている人です。よどみない完璧な答えより、こちらのほうが信用できます。

8-3. 実際には、たいてい中間です

　ここが現実的なところです。8-1の逃げの型にも、8-2の良い答えにも、きれいには当てはまらない。これがいちばん多い。

　固有名詞は出たが、数字は出なかった。半分は自分の言葉で、半分は用意された言葉だった。この場合、どう読むか。

• 固有名詞が出たなら、そこは中身を知っています。製品名やシステム名が具体で出てくるのは、日常でその話をしている証拠です。数字が出ないのは、その場で覚えていないだけかもしれません。

• 「あとで確認してお伝えします」は、良い答えです。ただし、実際に届くかどうかまで見てください。届いたら、その会社は約束を守る会社です。届かなかったら、それも答えです。

• 1つの問いで判断しないでください。この記事の3問は、同じ人の答えを3方向から見るためのものです。3つとも一般論に逃げたときに、初めて意味を持ちます。

　そして、初対面の学生に自社の弱みを自白する経営者は、そう多くありません。8-2の3つ目は、出てきたら強い加点材料ですが、出てこないことを減点にはしないでください。この記事の観測は、みなさんが思うほど感度が高くありません。だから、次の章の条件が要ります。

9. エンジニアでなかったら、撤退を考えてよい

　ここは、いちばん誤解されやすいところなので、順番に書きます。

9-1. 撤退を検討してよい

　面接の場で、二度聞いても、7-1の問いに自分の言葉で答えられなかった場合、その企業の選考は、撤退を検討してよいと、私は思います。エンジニアであるかを確かめて、そうではなかった、という判断です。内定を待たずに、その時点で判断してよい、という意味です。

　根拠は2つあります。1つは、これがその場の失敗ではなく、構造の表れだからです。技術で稼ぐ会社の、技術投資の最終決定者が、自社のシステムを語れない。ここは、入社後に自分の努力で変えられる範囲の外側にあります。もう1つは、選考が1社あたり数十時間を要するからです。その時間を、フェーズ3で見つけた別の候補に回す。これは逃げではなく、配分の判断です。

　ただし、条件を5つ付けます。

1. 一度の受け答えで決めない。角度を変えて、もう一度だけ聞く。「差し支えなければ、直近で技術投資を判断されたときに、どこを見て決められたのかを教えていただけますか」。二度目でも抽象論しか返らないときに、初めて判断する

   • 面接が1回しかない、逆質問が3分しかない。そういう選考では、二度聞くことができません。その場合は、判断しないでください。1問しか投げられなかったなら、それは判断には足りない、というだけのことです。1-5の読み替え3のとおり、現場の社員への2問で埋めてください

2. 6章で見た事実と、同じ向きを指しているかを確かめる。役員構成にも、技術コミュニティの履歴にも、同じ傾きが出ているなら、それは偶然ではありません

3. その人が面接に出てこなかったことは、判断材料にしない。財務担当取締役が新卒の面接に出ないことは、珍しくありません

4. 規模の小さい会社の社長が、技術出身でないこと自体を材料にしない。数十名の会社を、営業や現場から立ち上げてきた社長は大勢います。構造がおかしいという話ではありません。見るのは、技術を分かる人を要所に置いているか、そして技術の話を自分の言葉でどこまで持てるかです

5. 通える範囲の候補が少ない人は、「撤退」ではなく「保留」でかまいません

9-2. そのうえで、これは「覚悟の材料」にもなります

　撤退を選ばない場合でも、この観点で分かったことは、必ず持ち帰ってください。

　技術投資を決める人が技術を分からないなら、予算の通り方はそうなります。評価を設計する人が技術を分からないなら、評価のされ方はそうなります。それを知らずに入るのと、知って入るのとでは、入社後の身の処し方が変わります。知っていれば、最初から社内での説明の仕方を用意できますし、期待の置きどころも変えられます。

9-3. 候補が少ない方へ

　4つ目の条件を、もう少し書きます。「撤退して、その時間を別の候補に回す」という言い方は、回す先がある人にしか成り立ちません。

　実家から通える範囲で、と決めている。地元に同規模の会社が3社しかない。その状況で1社減らすのは、配分の判断ではなく、ただの1社減です。私は、そこを軽く見ていません。

　ですから、候補が少ない方は、こうしてください。

1. この観点を、点数ではなく重みとして持ち帰る。「技術が分かる人が要所にいない」という事実を、他の材料と並べる1つとして扱います。

2. 入るなら、その前提で入る。9-2のとおり、覚悟の材料として使ってください。予算が通りにくいこと、評価が技術の難易度を拾わないこと。それを知って入った人は、知らずに入った人より、ずっとうまく立ち回れます。

3. 判断は、フェーズ5で複数社を並べるときに下す。この記事の役割は、そこに持っていく材料を1つ増やすことです。

　なぜここまで書くのか。技術の難易度も、設計に費やす時間も、負債を返す作業の重みも、伝わらない相手には、評価されないからです。伝わらないものは、評価されません。その先に何が起きるかは、みなさんが想像するとおりです。

　なお、バックオフィスの実態は、フェーズ3-6のカジュアル面談やOB訪問でも確かめられます。1-5の読み替え3で挙げた2問を、そこで使ってください。役員に会えない選考では、これがいちばん確かな観測です。

まとめ

　本記事で言いたかったことを、整理します。

• 財務担当取締役は、社内最強のエンジニアであってほしい。会社の数字はシステムから出てくる以上、数字に責任を持つとは、その仕組み全体に責任を持つこと。取締役会を置いている会社では、大きな技術投資はそこで決議される（会社法362条4項）ので、議席の有無も見る材料になります。ただし、規模の小さい会社では取締役会を置いていないほうが普通で、その場合は決めているのはたいてい社長1人です（1-5）

• 求められるのは、最強のエンジニアであり、同時に最強のMBAであること。この2つが別々の人にあると、あいだに翻訳が挟まり、技術の必然性も数字の切実さも落ちる

• 人事のトップも、同じ。人事はもう労務の部署ではなく企業戦略の一部で、エンジニアの評価と育成を設計する立場には、VPoEやテックリードと同じ視座が要る。この2人が率いるバックオフィスは、本来、社内最強のエンジニア集団

• 上の役職は、下の役職の上位互換であるべき。上に行くほど責任の範囲が広がるのであって、できることが減るのではない。面接の階層が上がるにつれて技術の話が深くなるかを見れば、その会社の構造が分かる

• 面接では、出てきたその人が、エンジニアであるかどうかを見極める。序章-1のプロフェッションの定義を、観測できる3つに置き換える。自社の技術を自分の言葉で説明できるか／この半年で何を作り、読み、書いたか／技術の判断を、どこを見て決めたかを語れるか。計る場は、役員面接・最終面接と、人事面接。役割ならではの観点は、そのあとに見る

• もしエンジニアでなかったら、撤退を考えてよい。ただし条件は5つ。二度聞くこと。面接が1回で二度聞けないなら判断しないこと。その人が面接に出てこなかったこと自体は材料にしないこと。規模の小さい会社の社長が技術出身でないこと自体も材料にしないこと。候補が少ない人は保留でよいこと

• その席がない会社を受ける方は、1-5を読んでください。いちばん確かな観測は、現場のエンジニアへの2問です。「入社されてから、社内の手続きで困ることはありますか」「社内の仕組みを、直近1年で入れ替えられたものはありますか。どなたが決めて、どなたが入れられたのですか」

　次のフェーズ4-10では、選考の最後の局面・オファー面談に進みます。フェーズ3-2で扱った給与欄の裏取りを、この場で完了させる旅です。

エンジニアの卵のみなさんへ、エール

　財務も人事も、学生のみなさんには遠い世界だと思います。私も、就活のときには何ひとつ知りませんでした。

　それでも、この記事を書いたのは、知らないまま入って、いちばん困るのがみなさん自身だからです。予算が通らなければ、望む技術投資は実現しません。評価制度が実態に合っていなければ、みなさんの働きは正当に評価されません。そして、その2つを決めているのは、面接でいちばん印象に残る人ではありません。

　みなさんが入ろうとしているのは、技術で稼ぐ会社です。その会社で見落とされやすいのが、財務と人事のトップです。確かめることは、たった1つ。その人は、エンジニアか。

　そして、その席がない会社を受ける方も、確かめることは同じです。決めている人が、技術を分かっているか。相手が社長1人でも、問いは変わりません。

　今週、なにか一つ、始めてみてください。

• 応募先の役員紹介ページを開いて、技術の経歴を持つ人を数える。2人しか載っていなくても構いません。数えることに意味があります。

• その人の名前で、検索してみる。出てきたものと、出てこなかったものを分けて書き出す。出てこなかったところが、そのまま質問になります。

• 一次面接で現場の方に当てる2問を、書き留めておく（1-5）。役員に会えない選考では、これがいちばん効きます。

　まずはどれか1つで構いません。ただし、1つで終わりという意味ではありません。この3つは、いずれ全部やることになります。今週はどれか1つ、というのは、始める順番の話です。

　そして、フェーズ4-10で、オファー面談の実践でお会いしましょう。

　一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。

次の記事は、フェーズ4-10「オファー面談・オファーレターで、曖昧にされがちな条件の裏取りをする。手取りは、いくらか」です。

この連載を読むにあたって

　事実の確認について。 法令・統計・制度の記述は、一次情報にあたって確認し、出典のリンクを各記事の末尾に置いています。それでも、誤りが混じっている可能性は、ゼロではありません。数字と法令は、リンク先の原典で確かめてから使ってください。確かめる手間ごと、この連載がお渡ししたいものです。

　調査の時点について。 記事中の法令・統計・制度は、2026年9月15日時点で確認したものです。法令は改正され、統計は毎年更新されます。読んでいる時点との差は、ご自身で埋めてください。

　生成AIの利用について。 この連載は、調査と推敲に生成AIを使っています。

　最後は、ご自身で判断してください。 就職活動は、みなさんの人生の大きな選択です。この連載がお渡しするのは、判断の物差しであって、判断そのものではありません。物差しを当てるのは、みなさん自身です。

　そして、一人で抱えないでください。 相談先があります。大学のキャリアセンター。新卒応援ハローワークは全国56か所にあり、すべて無料で、専任の就職支援ナビゲーターが担当者制でついてくれます。労働条件のことは、総合労働相談コーナー（都道府県労働局や労働基準監督署などに全国378か所）でも相談できます。

#エンジニア就活 #CFO #人事評価 #技術投資 #就活生 #経営者 #エンジニアの卵に贈る就活の書

関連記事・参考文献等

• 新卒ITエンジニア 新卒研修シラバス

• 新卒エンジニア、観察ノートを開く（上巻）　観察を、始める

• 新卒エンジニア、観察ノートを開く（中巻）　両輪を、回す

• 新卒エンジニア、観察ノートを開く（下巻）　道を、選び取る