社内SEの面接対策：業務部門との調整とシステム運用を事例で説明する

社内SEの面接では、「利用部門と調整しました」「システムを安定運用しました」だけでは、自分の判断が伝わりません。どの業務が止まり、誰が何を決め、自分は何を調べて、どの範囲の変更を確かめたのか。業務への影響から対応の判断と確認結果まで、一つの事例でつなげて説明します。

この記事では、異動した担当者が月次帳票を開けない架空のケースを使います。権限を広げて終わらせず、業務上の必要性、承認、運用、期限後の確認を整理します。自分の経験へ置き換える前に、非技術部門の関係者との合意を説明する問題で、相手の要望をどう具体化したかを話してみてください。

**根拠の範囲：**採用の説明と技術資料は出典を付け、以降のケース、時刻、帳票、アカウント、回答文例はすべて独自の架空例とします。特定企業の候補者報告や実際の障害記録ではありません。小さな権限判定モデルはローカルで実行しましたが、実サービスの認証基盤や本番運用を検証した結果ではありません。

志望動機を「社内だから」から具体的な仕事へ進める

dodaの社内SE面接ガイドは、志望理由や経験を具体化し、面接官の立場に応じて説明する考え方を紹介しています。2022年公開の人材サービスによる助言であり、応募先の公式選考案内ではありません。同ページの過去の調査から、応募先の現在の面接回数や順番は、当該企業の案内で確認してください。

ここでの編集上の提案は、志望理由を、自分が経験した業務上の問題と、応募先で担いたい仕事へつなぐことです。「社内SEなら落ち着いて働けそう」という印象だけでは、応募先でどの業務を支え、何を担いたいのかが伝わりません。一方、架空の例なら「利用部門が必要とする情報を、権限と運用の条件に落とし込む仕事を深めたい」と表現できます。

その理由を説明するには、実際に担当した範囲が必要です。問い合わせを受けた経験、要件を整理した経験、設定した経験、判断を承認した経験を混ぜないでください。求人票に運用と書いてあっても、アカウント管理、業務アプリの保守、委託先管理のどこを担うかは、当該募集で確認します。

架空ケース：異動後に月次帳票が開けない

午前9時、業務担当者U17から「11時の会議で使う月次帳票が開けない」と連絡がありました。ログインはできていますが、対象帳票の閲覧で403が返ります。別の担当者は同じ帳票を開けます。U17は前日に部署を異動していました。ここまではケースの観測情報です。

この情報だけで、原因を「異動に伴う権限不備」と確定しません。403は観測した応答であり、アプリの権限判定、対象帳票の状態、申請処理などのどこに原因があるかは追加確認が必要です。業務影響も「全社停止」ではなく、現時点では特定担当者による一つの帳票閲覧に限られます。

9時10分の確認で、少なくとも申請状態と閲覧権限の不足を説明できます。ただし、権限が未付与であるという確認結果は、付与の承認を意味しません。申請者の困りごとを聞きながら、業務の責任者に必要性と範囲を確認します。

利用部門、承認者、運用担当の判断を分ける

「調整した」という一語を、誰と何を決めたかに分解します。利用者へは、必要な帳票、操作、期限、代替手段を聞きます。業務責任者へは、その人が対象情報を扱う必要性と、認める範囲を確認します。アプリ運用担当へは、設定できる権限の単位、反映方法、失効の確認方法を聞きます。

Google SREの公式インシデント対応資料は、調整、連絡、対応の管理と、指揮・連絡・作業の役割を説明しています。これは参考にする運用の考え方で、日本企業の社内SEに同じ役職名や人数を求める採用基準ではありません。この小さな例でも、説明する人と操作する人、承認する人の違いを残すために使います。

業務部門へ「権限がないので無理です」とだけ返すと、必要な仕事を進める判断が残りません。反対に「急ぎなので管理者権限を付けます」では、帳票閲覧という要望を広すぎる変更へ変えてしまいます。必要な対象と操作を限定し、組織の承認経路に沿って進めることが、このケースの判断です。

委託先が実際の設定をする場合も、誰が業務上の範囲を決めたかは残します。「ベンダーに任せました」で終わらず、渡した条件、受け取った確認結果、社内で判断した点を説明してください。委託したことと、社内の判断責任が消えたことは同じではありません。

暫定対応を選ぶときは、期限と確認方法まで話す

ケースの選択肢は、承認された期限付き閲覧、既に権限を持つ担当者による業務上認められた代替、会議で使う範囲の再調整などです。どれを選べるかは情報の扱いと組織の手順によります。他人のアカウントを借りることを代替として提案する必要はありません。

架空の合意文は「U17が対象の月次帳票を当日の集計のため閲覧する。操作は閲覧のみ、期限は12時。業務責任者が範囲を承認し、運用担当が設定を記録し、期限後に実アプリで失効を確認する」です。会議の期限だけでなく、権限の対象、実施者、確認する人が分かります。

OWASPの公式Authorization Cheat Sheetは、必要最小限の権限、既定の拒否、リクエストごとの権限確認を推奨しています。ここでは技術設計の参考として使います。「ログインできるから閲覧してよい」と考えないことや、操作ごとに対象を確認する論点につながります。組織の実際の承認制度を、この資料だけで決めるわけではありません。

業務部門への途中報告は、分かった影響、進めている確認、次の連絡時点を短くまとめます。「対象帳票の閲覧権限が未付与であることを確認しました。必要な範囲と期限を責任者へ確認中です。次は9時30分に状況を共有します」。完了見込みが分からない段階で、必ず復旧すると約束しません。

原理を確かめる小さな判定モデル

次は架空ケースのローカル判定モデルです。承認済み、対象一致、有効期間内などの入力条件から閲覧可否を返します。承認者の本人確認や実際のIAM連携を実装したコードではありません。

from datetime import datetime

def can_read(user_id, resource, now, user_active, grant):
    return bool(user_active and grant
        and grant['principal'] == user_id
        and grant['resource'] == resource
        and grant['permission'] == 'read'
        and grant['status'] == 'approved'
        and not grant['revoked']
        and datetime.fromisoformat(grant['valid_from']) <= now
        < datetime.fromisoformat(grant['valid_until']))

対象U17、帳票monthly-report、閲覧のみ、承認済み、取消なし、開始9時30分、終了12時を基準に、11ケースを実行しました。基準入力の開始は2026年10月1日9時30分、終了は同日12時で、いずれも日本標準時のオフセットを付けています。

この実行で確かめたのは、与えた入力に対する関数の返り値です。実アプリで12時にセッションが無効になること、既存トークンが使えなくなること、ログが永続化されることは確かめていません。approvedという文字列が正しく設定されたことを保証する仕組みも、この関数の外に必要です。

面接で「期限のテストをしました」と話す場合は、この違いを説明します。本番の経験なら、対象環境、確認したリクエスト、監査記録、対象外の操作、期限後の結果を話します。演習なら演習と伝え、実サービスで未確認の項目を残してください。

恒久対応は既存機能、自作、委託を比較する

暫定対応の後には、異動時の申請経路や役割の見直しが必要かを考えます。ここでも「自作すれば柔軟」「SaaSなら安い」と決めません。今回必要なのは、帳票単位の閲覧、承認記録、期限、取消、確認可能な操作履歴です。それぞれを実現できるか比較します。

これは見積もり済みの製品比較ではありません。価格、納期、機能の可否は未確認で、表は見積依頼や機能確認の前に論点をそろえるためのものです。既存機能で条件を満たせるなら、その確認結果を基に判断できます。満たせない項目があるなら、追加実装の費用だけでなく、運用、検証、契約変更の負担も比較します。

委託を選ぶ場合、受入条件を「画面が動く」にしないことが大切です。対象利用者の閲覧、対象外帳票の拒否、承認待ちの拒否、期限境界、取消後の扱い、記録の確認方法を、関係者と合意する例が考えられます。実際の条件は対象システムに合わせます。面接では、自分が比較案を作ったのか、決裁したのか、受入を担当したのかも分けて話します。

自分の事例へ置き換える回答の組み立て

回答の出発点は、業務と影響です。次に自分の担当、観測した事実、未確認だった点、関係者との判断、確認した結果をつなぎます。専門用語を並べるより、「なぜその範囲の対応を選んだか」が分かる順序にします。

架空の短い文例です。「異動した担当者が月次帳票を開けず、会議準備に影響していました。私は問い合わせの整理と申請・権限状態の確認を担当しました。業務責任者へ必要な対象と期間を確認し、承認後の設定は運用担当が実施しました。私は本人の閲覧確認と期限後に確認すべき項目を整理しました。権限全体の設計や承認を自分一人で行ったわけではありません」。

結果に数字を入れるなら、測れた範囲を示します。問い合わせ件数、確認した対象数、応答時間などがあっても、測っていない売上損失の回避へ広げません。後続の改善提案が採用されなかった場合も、比較根拠と未解決事項を説明できます。「成功した話」に整えるために、決まっていない恒久対応を完了済みにしないでください。

経験がない場合は、このケースを演習として説明し、実際の業務承認や本番失効を扱っていないと伝えます。自分の小さな運用経験があるなら、許可された範囲で置き換えます。顧客名、個人のアカウント情報、内部ログを公開しなくても、判断の前提と自分の役割は説明できます。

PracHubで調整と運用の根拠を練習する

以下は他社・一般の英語問題を含む練習先です。日本企業の社内SE選考での出題報告や、固定の選考手順ではありません。

まず非技術部門の関係者との合意を説明する問題で、自分が整理した要望と、他の人が承認した点を分けて話してください。続けて「その対応が必要な範囲だけに効いたと、何で確認しましたか」と問い直します。答えが曖昧な部分が、事例を見直す箇所です。

Sources and Further Reading

• doda：社内SEの面接での質問例（2022年公開）
• Google SRE Workbook：Incident Response
• OWASP：Authorization Cheat Sheet