FDE（Forward Deployed Engineer）の着任日が決まると、情シスに回ってくるのは「月曜から来る外部のエンジニアに、何をどこまで開ければいいか」という問いです。全社共通のアカウント発行フローに乗せると、申請から発行まで日数がかかる。かといって管理者権限を渡せば、あとから誰が何を触ったのか説明できなくなる。当社の見立てでは、着任初日の午前が「ログインできない」「共有ドライブが見えない」「テスト環境の DB につながらない」への対応で終わり、FDE が業務の話を聞き始めるのが翌日からになることがあります。
この記事は、着任前に情シスが用意する具体物だけを扱います。FDE とは何かという職種の説明はハブ記事に、AI に社内データを渡してよいかという判断はデータの扱い6項目の記事に、経営・現場・情シスの役割分担と会議体は受け入れ体制の記事に書いたので、そちらに譲る。ここで書くのは、アカウントを発行する順番、権限を絞るときに決める4つの軸、端末の3案、監査ログが何日残るか、契約終了日から逆算する退場手順。仕様と数字は Google Workspace・Microsoft Entra ID・Microsoft Purview の公式ドキュメント、NIST の用語定義、IPA のガイドラインで確認できた範囲を書き、所要日数などの目安は、当社が経理 AX・kintone・案件管理システムの刷新・Claude 導入で本番稼働まで伴走した経験を一般化したものとして区別しています。
情シスが着任前に用意するのは、アカウント・権限・端末・ログ・退場の5点。読める範囲を先に開け、書き込みと管理者権限は必要になった日に足す。権限表は対象範囲・操作・期間・接続経路の4軸で書き、退場は発行の逆順で閉じる。
この記事の要約
着任初日の午前は「待ち」で消えやすい
FDE は初日に業務の分解とデータの棚卸しから始めます。どちらも実物を見ないと進みません。業務の流れを聞くだけなら会議室でできますが、実際の帳票・実データ・例外処理の履歴を見て初めて「どこが自動化できてどこができないか」が分かる。初日に必要なのは、開発権限ではなく閲覧権限です。「まず開発環境を用意しました」だけ渡すと、FDE は見るべきものが見えないまま2日目を迎える。
待ち時間の中身を分解すると、原因は3つに絞られます。第一に、アカウント発行が全社共通の申請フローに乗っていて、承認までに日数がかかる。何営業日かかるかは会社ごとに違うので、着任日が決まった時点で自社の申請フローの実績日数を確認しておく。第二に、アカウントは発行されたが、共有ドライブ・kintone のアプリ・会計システムの参照権限が個別付与になっていて、誰に頼めばよいかが分からない。第三に、貸与端末の初期設定（暗号化・MDM の登録・VPN 証明書）が終わっておらず、当日その場でやることになる。3つとも、着任日が決まった時点で着手できる作業です。
当社の経験では、着任前の準備が終わっている現場とそうでない現場で、最初の1週間に積める判断の数が変わります。準備ができていれば、初日から実データを見た質問が出せる。できていなければ、同じ地点に着くまでに数日を使う。どれだけ差が開くかは案件によって違うので、日数を決め打ちで見込むより、90日の計画を引くときに「初週は準備待ちで潰れうる」という前提を置いておくほうが実務的です。
発行の順番——着任14日前から初日までの逆算
準備は「全部そろってから渡す」ではなく、「先に読める範囲を開け、書ける範囲はあとから足す」の順で進めます。読み取り権限は書き込み権限より影響範囲が狭く、承認の判断がしやすい。そして FDE の初日の仕事は読むことなので、それだけで初日が動く。書き込み・本番環境・管理者権限は、必要になった日に、必要な範囲だけ足す。
ただし「読むだけだから軽い」と情シスの判断で開けてよいわけではありません。実データを外部の人間に見せてよいかを決めるのは、そのデータを持っている部署です。アカウントの申請と同時に「どのデータを、誰の承認で、いつから見せるか」をデータ保有部署に確認する。承認が着任日までに下りない見込みなら、匿名化した抜粋か、本番と同じ構造のダミーデータで業務の分解を先に始める。実データが見られる日が後ろにずれても、業務の流れの整理は前に進みます。
| 時期 | 情シスがやること | これが無いと着任初日に止まること |
|---|---|---|
| 14日前 | 社内アカウント（メール・チャット・ID 基盤）の発行申請を出す。自社ドメインのアカウントかゲスト招待かを先に決める | ログインそのものができない。承認に数日かかる会社では、ここが最も長い待ちになる |
| 10日前 | 貸与端末を確保し、暗号化・MDM 登録・ウイルス対策・VPN 証明書まで済ませる。貸与しない方針なら、持ち込み端末に何を求めるかを書面にする | 端末の初期設定を当日その場でやることになり、初日の作業時間が削られる |
| 7日前 | 閲覧権限を付ける対象（共有ドライブのフォルダ、kintone のアプリ、会計システムの参照ロール、設計書の置き場所）を一覧にし、データ保有部署から承認を取る | 「見たい資料がどこにあるか」を聞いて回る時間が発生する。権限の持ち主が複数部署に分かれていると、承認だけで数日かかる |
| 5日前 | 監査ログの取得設定と保存期間を確認する。必要な期間より短ければ、延長か外部への書き出しをこの時点で決める | あとから「4か月前に誰が何をしたか」を調べようとして、ログが残っていないことに気づく |
| 3日前 | 権限表（後述の4軸）の初版を作り、FDE と受け入れ側の Echo 役に渡す。連絡先とエスカレーション先も同じ紙に書く | 障害や権限不足が起きたとき、誰に連絡すればよいかが分からず止まる |
| 初日 | 閲覧権限で実際にログインし、見える範囲を FDE と一緒に確認する。見えないものがあればその場で追加申請 | 「開いたつもりが開いていない」が発覚するのが数日後になる |
| 初日〜2週目 | 書き込み権限・検証環境・API キーを必要になった時点で追加し、そのたびに権限表を更新する | 最初に全部渡してしまい、何が使われているか分からなくなる |
外部委託先に自社ドメインのアカウントを出すか、ゲストとして招待するかは、着任14日前までに決める論点です。手間の大小だけで決めると、あとから監査や成果物の扱いで詰まる。次の5つを共通の軸にして比べる。
| 比較する軸 | 自社ドメインのアカウント | ゲスト招待 |
|---|---|---|
| 対象システムへの対応 | 社内システムの権限設計をそのまま流用できる | SaaS 側が対応していれば足りる。社内システムがゲストを想定していないと、結局アカウントが要る |
| 認証と端末の条件 | 全社の多要素認証・条件付きアクセス・端末条件がそのまま効く | 招待元の条件が相手側の認証にどこまで及ぶかを個別に確認する。端末条件が効かない組み合わせがある |
| 監査の対象になるか | 社内利用者と同じ監査ログに残る | ログの形式と保存先が別扱いになることがある。開始前に何が残るかを確認する |
| 成果物の所有先 | 作ったファイル・アプリの所有者が自社側になり、退場後も社内に残る | 所有者が外部側になる場合がある。所有権の移管を終了前の作業に必ず入れる |
| 終了時の確認事項 | 停止・データ移管・削除まで、社内の退職者と同じ手順を通す | 招待の取り消しで終わりにしない。所有権の移管、共有リンクの解除、外部側に残ったコピーの扱いを確認する |
当社の見立てでは、社内システムを触る範囲が広い案件は自社ドメインのアカウント、SaaS だけで完結し成果物も SaaS 上に残る案件はゲスト招待が実務に合います。どちらでも、成果物の所有先と終了時の確認事項は権限表に1行ずつ書いて残す。
権限の絞り方——4つの軸で権限表を書く
「最小権限」という言葉は、それだけでは現場で機能しません。何をもって最小とするかが人によって違うからです。NIST の用語集は最小権限を「それぞれの主体に、その機能を果たすために必要な最小限のシステム資源と権限だけを与えるように設計する原則」（SP 800-53 Rev.5）と定義しています。これを情シスの作業に落とすには、権限を4つの軸に分解して1行ずつ書く。
| 軸 | 決めること | 書き方の例 |
|---|---|---|
| 対象範囲 | どのシステムの、どの範囲か。テナント全体か、特定のフォルダ・アプリ・テーブルか | 共有ドライブの「経理_月次」フォルダ配下のみ。全社ドライブは対象外 |
| 操作 | 読むだけか、書けるか、設定を変えられるか、他人の権限を変えられるか | 読み取りのみ。書き込みは検証環境のみ。本番の設定変更は情シスが実施 |
| 期間 | いつから、いつまで。恒久か、その日だけか | 10月1日〜12月26日。管理者権限は移行作業日の当日のみ |
| 接続経路 | どの端末・どのネットワーク・どの認証方法で使えるか | 貸与端末から、2要素認証あり。個人端末とVPN外からは接続不可 |
4軸だけでは、その行を誰がいつ処理するのかが決まりません。1行ごとに申請者・承認者・付与担当・利用開始日・申請期限を足す。大事なのは、利用開始日と申請期限を別の欄にすることです。同じ欄にすると「必要になった日に申請する」運用になり、そのたびに承認待ちが発生する。申請期限を「利用開始日から自社の承認所要日数をさかのぼった日」として先に埋めれば、権限表がそのまま申請のスケジュール表になります。記入例は次のとおり。
| 対象範囲 | 操作 | 期間（利用開始日〜終了日） | 接続経路 | 申請者／承認者／付与担当 | 申請期限 |
|---|---|---|---|---|---|
| 共有ドライブ「経理_月次」配下 | 閲覧のみ | 10月1日〜12月26日 | 貸与端末・2要素認証あり | 情シス／経理部長／情シス | 9月17日 |
| kintone の請求管理アプリ（検証） | レコードの追加・編集 | 10月8日〜12月26日 | 貸与端末・社内ネットワーク | FDE／情シス課長／情シス | 9月30日 |
| 会計システム 本番 | 設定変更（管理者役割） | 11月12日の当日のみ | 貸与端末・情シス立ち会い | FDE／情シス課長／情シス | 11月5日 |
この4軸のうち、日本の現場で抜けやすいのは「期間」です。作業のために一度渡した管理者権限が、案件が終わったあとも残る。Microsoft Entra ID の Privileged Identity Management は、この問題に対して「対象（eligible）」と「有効（active）」を分ける仕組みを持っています。対象に設定された利用者は、必要なときに自分で役割を有効化する。有効化の条件として多要素認証・理由の入力・承認者の承認を求められ、有効化されたことは通知され、監査履歴として書き出せる。開始日と終了日を指定した期限付きの割り当てもできます。公式ドキュメントは利用にライセンスが必要だと明記しているので、導入済みかどうかを着任前に確認しておく。
管理者アカウントの扱いは、Google Workspace の管理者向けドキュメントが具体的です。特権管理者は複数人を別々の担当者が持つこと、1人につき「特権管理者用」と「日常業務用」の2アカウントを持たせること、管理者アカウントを複数人で共有しないこと（共有すると監査ログで誰の操作か特定できなくなる）、管理者アカウントには2段階認証を必須にしセキュリティキーが最も強い second factor だと書かれています。加えて、管理作業をしていないのに特権管理者でサインインしたままにしない、日常の管理作業は権限を絞った委任ロールで行う。外部から来る FDE に管理者権限を渡す場面でも、この考え方をそのまま当てはめれば判断できます。
Microsoft 側には、作業ごとに「その作業に必要な最小の役割」を一覧にした公式ページがあります（Least privileged roles by task）。全体管理者を渡す前に、その作業が別の役割で済まないかをこの一覧で確認する。アプリの登録・条件付きアクセスの閲覧・利用者の追加といった作業の多くは、全体管理者以外の役割で実行できます。権限表の「操作」欄には、この一覧の役割名をそのまま書くと第三者が読んでも再現できる。
端末——貸与・持ち込み・仮想環境の3案
端末は、着任前の準備で最も日数がかかる項目です。在庫から回せるのか調達からなのかで所要日数は大きく変わるので、着任日が決まった時点で自社の調達フローに当てる。選択肢は3つで、案件の性質と社内規程によって答えが変わります。
| 案 | 用意にかかる時間（当社の目安。自社の調達フローで要確認） | 向く場合 | 決めておくこと |
|---|---|---|---|
| 自社の貸与端末 | 在庫から回せるなら数日。調達が必要なら数週間かかることもある | 本番の顧客データを画面に出す作業がある。社内規程で外部端末からの接続を認めていない | MDM の登録範囲、貸与期間、返却日、返却時のデータ消去の手順と記録 |
| FDE 側の持ち込み端末 | 条件を書面にすれば即日〜数日 | SaaS 上での作業が中心で、本番データを端末に保存しない。開発ツールの都合で FDE 側の環境が必要 | 求める条件（ディスク暗号化・画面ロック・ウイルス対策・OS の更新状況）を書面にし、接続元のIPと認証方法で制御する |
| 仮想デスクトップ・踏み台 | 既存基盤があれば数日。新規に立てるなら数週間 | 本番データを端末に一切残したくない。作業内容をすべて記録したい | 同時接続数と費用、ファイルの持ち出し可否、コピー＆ペーストの制御、応答速度が開発作業に耐えるか |
持ち込み端末を認める場合、条件を書面にするだけでは守られたかどうか分かりません。接続する側の条件をシステムで判定する仕組みを使います。Google Workspace の Context-Aware Access は、IP アドレスの範囲、端末の状態（暗号化やパスワードの設定など）、アクセス元の国、独自の属性を条件にしてアプリごとにアクセスを制御できます。ただし対応エディションが限られており、公式ドキュメントは Frontline Standard / Frontline Plus、Enterprise Standard / Enterprise Plus、Education Standard / Education Plus、Enterprise Essentials Plus、Cloud Identity Premium を挙げたうえで、「これ以外のエディションの利用者は、Context-Aware Access のポリシーを適用しても通常どおりアプリにアクセスできる」と書いています。自社のエディションを確認せずにポリシーを作ると、制御しているつもりで何も効いていない状態になる。
Microsoft 側は条件付きアクセス（Conditional Access）が同じ役割を担います。利用者・グループ、IP の位置情報、端末、アプリケーション、リスク検出といった信号をもとに、アクセスの拒否か許可かを決め、許可の条件として多要素認証・準拠端末・承認済みクライアントアプリなどを要求できる。公式ドキュメントは Microsoft Entra ID P1 ライセンスが必要（Microsoft 365 Business Premium でも利用可）と明記しています。ここも、着任前に「自社で使えるかどうか」を確認する項目です。
監査ログ——「何が何日残るか」を着任前に確認する
外部のエンジニアが社内システムを触る期間は、あとから「誰が・いつ・何をしたか」を説明できる状態にしておく必要があります。見落としやすいのは、ログの取得設定は確認しても、保存期間を確認していないことです。案件が終わってしばらく経ってから確認しようとしたときに、保存期間を過ぎていて何も残っていない、ということが起こりえます。
| 対象 | 既定の保存期間 | 出典 |
|---|---|---|
| Google Workspace の管理ログ・ログインログ・Drive・Groups・デバイス・OAuth トークンなど大半のログイベント | 6か月 | Google Workspace 管理者ヘルプ「データの保持期間とタイムラグ」 |
| Google Workspace のメールログ検索 | 30日 | 同上 |
| Google Workspace の Chrome アプリ・拡張機能の利用状況レポート | 12か月 | 同上 |
| Microsoft Purview の監査（標準） | 180日（2023年10月17日より前に生成されたものは90日） | Microsoft Learn「Microsoft Purview の監査（Audit）」 |
| Microsoft Purview の監査（プレミアム） | Entra ID・Exchange・OneDrive・SharePoint は既定で1年、それ以外は180日。保持ポリシーで最長10年（10年は利用者ごとの追加ライセンスが必要） | 同上 |
必要な保存期限は、案件の期間ではなく「案件が終わったあと、いつまで遡って確認する可能性があるか」で決めます。案件が3か月でも、退場後のログイン試行を1か月後に確認し、社内監査や顧客からの照会が半年後に来るなら、必要なのは案件期間ではなく1年前後です。既定の保存期間がそれより短い場合の選択肢は2つ。上位のライセンスや保持ポリシーで延長するか、API・エクスポートで外部に書き出して保管するか。Google Workspace は利用状況データを API 経由で15か月分取得でき、Microsoft は Office 365 管理アクティビティ API で既定の180日より長く保持できると公式ドキュメントに書かれています。どちらを取るにしても、決めるのは着任前です。案件が終わってからでは、過ぎた分は戻りません。
ログで見るべき対象も先に決めておきます。管理者権限の有効化と付与の履歴、本番データの一括ダウンロード、外部共有の設定変更、第三者アプリへの認可（OAuth）、そして退場後のログイン試行。当社は、この5つを週次で機械的に確認し、受け入れ体制の記事で書いた週次の定例会議の議題に1行入れることを勧めています。毎週見るから、異常があったときに前の週との差で気づける。
その5行それぞれに「保存する担当」「確認する頻度」「異常を見つけたときの連絡先」を書き添えて、権限表と同じ紙に載せる。担当を書かないと、案件が進むにつれて誰も見なくなります。連絡先は情シスの窓口ではなく、そのシステムを止める判断ができる人の名前にする。
退場手順——契約終了日から逆算して、発行の逆順で止める
退場手順は、契約が終わってから考えるものではありません。着任前に日付入りで決めておく。理由は、退場時にやることが権限の停止だけではないからです。作ったものを引き継ぐ作業（引き継ぎの記事で書いたランブック・権限表・変更手順の受け渡し）と、権限を止める作業を、同じ週に並行させると片方が漏れます。当社は、引き継ぎを終了7日前までに終え、権限の停止を終了日の当日、アカウントの削除を終了から2〜4週間後、という3段階に分けることを勧めています。
止める順番は、発行の逆順です。まず管理者権限と本番環境への書き込みを外す。次に検証環境・API キー・第三者アプリへの認可を取り消す。最後に閲覧権限とアカウントそのものを止める。閲覧権限を先に止めると、引き継ぎの最中に「あの設定を確認したい」が出たときに管理者へ依頼が集中する。
ただしこの順番が使えるのは、期間満了で終わる通常の終了だけです。契約の中途解除や事故対応で即時に止める場合は、順番を守らずに全部同時に遮断する。その代わり、遮断したあとに何が壊れるかを確認する作業が必要になります。通常終了と緊急停止で、手順と完了条件は次のように分かれる。
| 通常終了（期間満了） | 緊急停止（中途解除・事故対応） | |
|---|---|---|
| 利用者の認証情報 | 終了日当日に停止し、セッションも失効させる | 即時に停止し、発行済みのセッションと更新トークンもその場で失効させる |
| 業務用の認証情報 | 案件中に発行した API キー・サービスアカウントの鍵・共有パスワードを失効し、再発行する | 同じ作業を先に行う。他の業務が使っている鍵も再発行する前提で調整する |
| 残ったアクセスの確認 | 停止後に、共有リンク・外部共有・第三者アプリの認可が残っていないか一覧で確認する | 同じ確認を停止直後に行い、退場後のログイン試行を監視する |
| 自動処理の扱い | 定期実行・連携処理が権限を止めたあとも動くかを事前に確認し、止まるものは付け替える | 止めたことで動かなくなった処理を洗い出し、業務への影響を当日中に把握する |
| 完了条件 | 権限表の全行に停止日が入り、自動処理が停止後も正常に動いていること | 利用者と業務用の認証情報が両方とも無効化され、残存アクセスが無いとログで確認できること |
見落としやすいのは、下の2行です。利用者のアカウントを止めれば全部止まると考えていると、FDE が発行した API キーやサービスアカウントが生きたまま残る。逆に鍵を一斉に失効させると、FDE が作った定期実行が止まり、月次の集計が動いていないことに翌月気づく。権限表に「この行を止めると何が動かなくなるか」を書いておけば防げます。
- 終了7日前——引き継ぎ資料の受け渡しを完了し、Echo 役だけで1サイクル動かす。ここで足りないものが出れば、まだ FDE に聞ける
- 終了日当日——管理者権限・本番の書き込み権限を外す。発行した API キーとアクセストークンを失効させ、第三者アプリへの認可を取り消す。パスワードやキーを共有していた場合は、共有していた側も再発行する
- 終了日当日——アカウントを停止（サスペンド）する。Google Workspace では、停止するとサービスが使えなくなり新着メールと招待がブロックされる一方、メール・ドキュメント・カレンダーのデータは削除されない。停止中のアカウントもアクティブなアカウントと同じ料金が課金される、と公式ドキュメントは書いている
- 終了日当日——共有されていた側の確認。Google の公式ドキュメントは、停止しても「共有されたドキュメントへのアクセス権を与えられていた共同編集者は、引き続き閲覧・編集・共同作業ができる」と書いている。本人のアカウントを止めれば全部止まる、ではない
- 終了2〜4週間後——データの移管を済ませてからアカウントを削除する。Google Workspace では削除後20日間は復元でき、移管しなかった本人所有のデータ（Gmail の本文と添付、本人所有の Drive ファイルなど）は完全に削除される。特権管理者は削除時に Drive とドキュメント、主要カレンダー、Data Studio のデータを移管できるが、それ以外の管理者は削除前に移管しておく
- 終了1か月後——退場後のログイン試行が無いことを監査ログで確認し、権限表の該当行に停止日を記入して閉じる
貸与端末を回収した場合は、返却日とデータを消去した事実を記録に残します。IPA の「中小企業の情報セキュリティ対策ガイドライン」第4.0版（2026年3月27日公開）は、付録6として資産管理台帳のサンプル、付録5として情報セキュリティ関連規程のサンプルを配布しています。一から作るより、この様式に「外部委託先の利用」の列を足すほうが早い。
まとめ——情シスが着任前に渡す3枚
ここまでの内容を、実際に渡す紙の形にすると3枚になります。受け入れ体制の記事で「情シスが着任前に出す3つの一覧」と書いたものの、具体物にあたる部分です。
1枚目は権限表。対象範囲・操作・期間・接続経路の4軸で1行ずつ書き、行ごとに申請者・承認者・付与担当・利用開始日・申請期限、そして付与日と停止日の欄を作る。案件中はこの表が唯一の正本になり、退場時にはこの表を上から下まで閉じれば作業が終わる状態にする。
2枚目はシステム一覧。FDE が触る可能性のあるシステムを列挙し、それぞれに「データの持ち主の部署」「運用の担当者」「障害時の連絡先」「本番と検証の区別」「メンテナンス時間帯」を書く。FDE が最初に困るのは、権限が無いことより誰に聞けばよいか分からないことです。
3枚目は制約の一覧。持ち出してはいけないデータ、外部の生成 AI に入力してはいけない情報の範囲、本番環境で禁止している操作、変更を出してよい時間帯。ここは会社によって差が大きく、書いていないと FDE 側は安全側に倒して手が止まるか、悪くすると知らずに越えます。生成 AI に入力してよい範囲の決め方は[データの扱い6項目の記事]({GOV})に書いたので、その結論をこの1枚に写す。
3枚とも、A4で1枚ずつに収まる分量で構いません。分厚い規程集を渡すより、1枚に絞って着任前に読んでもらうほうが機能します。失敗パターンの記事で挙げた「権限が下りずに最初の2週間が消える」も、90日ロードマップの第1週の遅れも、この3枚が着任前にあるかどうかで結果が変わる部分です。
この3枚のうち、着任前にまず決めるべきなのは1枚目です。誰が権限表を書き、誰が承認し、いつまでに作るか。当社は、情シスの担当者が3日前までに初版を書き、承認者をその日のうちに押さえ、FDE と受け入れ側の Echo 役に着任前日までに渡す形を勧めています。書き始めるのに外部の支援は要りません。既存の ID 基盤の管理画面と社内の申請フローの実績日数が分かれば、1枚目は自社で書けます。
外部に相談したほうが早いのは、自社の ID 基盤で条件付きアクセスや期限付きの権限付与が使えるかの判断がつかないとき、社内規程と実際の運用が食い違って線引きを決めきれないとき、複数部署にまたがる承認を短期間でまとめる必要があるときです。費用は、既存の端末とライセンスで足りるなら準備そのものにはあまりかかりませんが、端末の調達や上位ライセンスへの変更が必要なら発生します。どちらになるかは、着任前に自社の在庫とライセンス構成を確認すれば分かる。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
着任前のアカウント・権限・端末の設計を、情シスと一緒に詰めます
権限表の4軸への落とし込み、貸与端末と持ち込み端末の線引き、監査ログの保存期間と取得対象、契約終了日から逆算した退場手順を、貴社の ID 基盤と社内規程に合わせて設計します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、着任前の準備から退場後の確認までご相談いただけます。