ID:84290さん

個人事業主として参画していた企業様（HR Tech × マーケティング事業）より、情報システム部門の立ち上げ依頼のお声がけをいただき入社しました（2024年8月〜現在）。 情報システム部門の実務責任者として IT 統制・ISMS・端末管理・全社 AI ツール導入を一気通貫で推進し、途中からプロダクト開発部門の QA チーム発足の責任者を兼任しています。 # プロジェクト経験① 情報システム部門の立ち上げとコーポレート IT 基盤整備 ## ＃プロジェクト経験概要 情シス専任者が不在だった状態から、IT 統制の年間計画策定・ISMS 運用・端末管理基盤・全社 AI ツール導入までを整備。規程類の策定だけでなく、講習会や理解度テストによる定着まで含めて設計・実行しました。 ## ＃チーム情報 情報システムセクション（実務担当は自身1名が主担当。計画・規程類は担当役員のレビュー・承認を受ける体制）。全社導入 PJ では各部門の代表メンバーと連携。 --- ## ＃取り組みA IT 統制の整備推進（年間計画〜運用定着） 【概要】 IT 統制（ITGC）の年間計画立案から規程・手順書の策定、全社への定着までを担当。 【どのような業務か】 - IT 統制の年間計画を立案し、担当役員経由で役員会へ提出・承認取り付け（計画作成は自身、提出は役員経由）。期中には「シャドー IT 対策への計画差し替え」など実態に合わせた計画修正も実施 - 企画業務手順書（ITGC-B01）・プロジェクト管理手順書（ITGC-B02）と、システム化計画書／プロジェクト計画書／プロジェクト報告書の3様式を整備 - 年間計画と実績の振り返り会を各部門の代表メンバーと実施し、Jira タイムライン上に全統制活動をマッピングして進捗を可視化 【課題・問題点】 - 規程を作っても現場が申請フローを理解していなければ形骸化する - 3様式がスプレッドシート運用で、版管理・編集履歴・AI からの参照性に難があった 【打ち手・使用した技術】（いずれも自身が主担当） - 規程公開と同時に手順書・申請フローの講習会を2日連続で開催し、録画＋スライドを未参加者へ共有して全社員に到達させる設計に - 3様式をスプレッドシートから Confluence ページ運用へ移行。約1か月の並行運用期間を設けて正式切替し、テンプレート直接編集の禁止や Live Doc 不使用など編集履歴を担保する運用ルールも同時に策定 - Confluence 移行により Claude（MCP 連携)から過去の統制資料を参照でき、対話的に申請書の下書きを作成できる状態を実現 【成果】 - 3様式の全社切替を計画どおり完了し、統制文書の作成負荷を AI 支援ありの運用へ転換 - 使用技術: Jira / Confluence / Claude (MCP) / バクラク（ワークフロー） --- ## ＃取り組みB IT 全社統制・全般統制 RCM の作成と監査対応 【概要】 IT 全社統制／全般統制の RCM（リスクコントロールマトリクス）を作成し、監査法人・内部監査対応を実施。 【どのような業務か】 - RCM の作成・細部調整・レビュー対応（作成は自身、レビューは担当役員） - 監査法人向けの情報システム概要書の記入・提出、サイバーセキュリティ評価テンプレートへの回答 - IT 統制規程に係る内部監査対応、特権 ID 管理規定の棚卸し運用整理 【課題・問題点】 - 統制の証跡が Confluence・議事録・規程類に分散しており、監査資料の作成に都度大きな工数がかかる 【打ち手・使用した技術】（自身が主担当） - サイバーセキュリティ評価では、Claude で Confluence と RCM を解析して仮の見解を抽出→内容を精査して記入するフローを構築し、回答作成を効率化 - RCM のエビデンスとして役員会議事録等への参照リンクを整備し、証跡を辿れる状態に 【成果】 - RCM を監査法人へ提出し、指摘事項の修正まで完遂 - 使用技術: Claude / Confluence / Google スプレッドシート --- ## ＃取り組みC ISMS（ISO27001）運用責任者 【概要】 ISMS の運用責任者として、年間運用サイクル全体を管理。 【どのような業務か】 - 定期点検、力量テスト（入社時セキュリティテスト）の実施・案内、インシデント登録と是正確認、内部監査、更新・サーベイランス審査（審査機関: BSI）の準備と立ち会い - 供給者（委託先）登録・セキュリティチェックシートの運用 【課題・問題点】 - セキュリティチェックシートを依頼部門が精査せずそのまま情シスへ流し、差し戻しが繰り返し発生していた 【打ち手】（自身が主担当） - 「自部門で記入できる項目は自部門で記入し、全社統制に関わる部分のみ情シスへ依頼する」原則へ運用を変更し、手順書に明文化。各部門の IT セキュリティリテラシーを底上げする狙いも含めた設計 - ISMS 定期点検と AI ガイドラインの半期棚卸しを同日実施に揃えるなど、点検イベントの統合による運用負荷削減も提案・実施 【成果】 - 差し戻しの削減と情シス作業の削減を両立する運用へ改善し、後任へ引き継ぎ可能な状態に文書化 - 使用技術: SecureNavi / Confluence --- ## ＃取り組みD 端末管理環境の整備（MDM・セキュリティソフトの選定〜導入） 【概要】 MDM とセキュリティソフトの選定から全社導入・運用設計までを担当。 【どのような業務か】 - Microsoft Intune による端末管理基盤の構築（Apple Business Manager 連携、Windows / Mac / Android の登録運用、配布ポリシー設計、キッティング手順の整備） - セキュリティソフトの刷新: 既存 ESET の評価→法人向け製品の選定調査（比較一覧の作成・個別問い合わせ）→ Microsoft Defender for Endpoint への移行を決定 【課題・問題点】 - 法人向けセキュリティソフトは価格非公開が多く、機能・コストの比較材料が揃わない - 移行期は既存 ESET のライセンス解除と新環境の展開を、業務を止めずに並行させる必要があった 【打ち手・使用した技術】（選定・設計・展開とも自身が主担当） - 選定一覧表を自作し、既存 Microsoft 契約とのライセンス統合効果まで含めて評価。Defender 採用により端末管理（Intune）とセキュリティを Microsoft 基盤へ集約 - 全社員分の Microsoft アカウント作成・ライセンス付与を行い、部門単位の2段階で配布して切替リスクを分散。ESET はアクティベーション解除〜ライセンス連携解除まで完全撤去 - 導入後もコスト最適化を継続（利用実態に合わせ Office 要素を外したライセンスへの切替提案、vPro 等の追加提案への費用対効果評価) 【成果】 - MDM＋セキュリティソフトを Microsoft 基盤へ統合し、管理コンソールの一元化とライセンスコスト最適化を実現。運用説明資料を Confluence に整備し引き継ぎ可能な状態に - 使用技術: Microsoft Intune / Microsoft Defender for Endpoint / Entra ID / Apple Business Manager / Android Enterprise (EMM) --- ## ＃取り組みE 全社 AI ツール導入 PJ（Claude × Atlassian エコシステム統合） 【概要】 全社の情報基盤を「AI が参照・活用できる状態」に再整備するエコシステム統合 PJ を推進。Jira / Confluence / Claude の全社導入を担当。 【どのような業務か】 - Jira・Confluence の全部門導入支援（Notion からの移管を含む）と、Claude（Team プラン）の全社導入 - エンジニア向け Claude Code（Premium シート）、デザイナー向け Cursor の導入と、職種別のライセンス設計 - 生成 AI 利用ガイドラインの策定・運用と、非エンジニア向け講習会の実施 【課題・問題点】 - 部門ごとに業務フローが異なり、ツール導入の障壁も部門ごとに違う。一律導入では定着しない - AI が社内ドキュメントを参照するようになると、情報の鮮度が低いページがそのまま AI の回答品質を下げる - ガイドラインは配るだけでは読まれず、利用判断が人によってブレる 【打ち手・使用した技術】（PJ 推進・ヒアリング・ガイドライン・講習会とも自身が主担当） - 各部門へ導入障壁のヒアリングを実施し、解消策をガイドライン・マニュアルへ反映しながら段階導入。移管状況は5段階の全社ヒアリングで可視化し、導入後アンケートで定着度を測定 - AI の参照品質を保つため Confluence のアーカイブ運用ルールを新設し全社展開 - AI ガイドラインの理解度テストを自作（OK/NG の利用判断を問う選択式）し、読了ではなく判断できる状態をゴールに設定 - 非エンジニア向けに「Cowork & Claude in Chrome ハンズオン勉強会」を全社対象で実施（環境構築からコネクタ接続、業務での実演までを設計。録画を全社共有） - 社内 AI 開発（K-AI）として、文字起こしツールの選定（会議準備コストの ROI を算出して評価)、議事録を自動で Confluence に仕分け格納するスキルの開発なども実施 【成果】 - Jira / Confluence / Claude を全社標準ツールとして導入完了。AI が社内ナレッジを参照して業務文書を下書きできる基盤を実現 - 使用技術: Claude (Team / Claude Code / MCP / スキル開発) / Jira / Confluence / Cursor / Tactiq --- ＃取り組みF コーポレートサイト群（コーポレート／採用／オウンドメディア）のリニューアル実装 【概要】 自社の3サイト（コーポレートサイト・採用サイト・デジタルマーケティング系オウンドメディア）のリニューアルにおいて、フロントエンド実装からインフラ構築・公開作業・CMS 移行までを担当。 【どのような機能の開発・実装か】 構成は Next.js ＋ ヘッドレス CMS（Contentful → Strapi へ移行）＋ GCP（Cloud Run / Cloud Load Balancing / CDN / Cloud Build による CI/CD）。 コーポレートサイト（自身が主担当）: 新サイトのリポジトリ作成〜CI/CD 構築、公開前の Basic 認証 middleware 実装、ステージング環境の構築、LB のパスベースルーティングによる段階公開の設計・実施、DNS 切り替え オウンドメディア（自身が主担当）: リニューアル公開作業（noindex/nofollow 解除・旧 URL リダイレクト設定・リニューアル告知バナー）と、公開後のパフォーマンスチューニング（dynamic import・キャッシュ制御・CDN 設置） 採用サイト（他エンジニアと分担）: メタデータ整備・デプロイ障害解決・応募フォームの Slack 通知拡張などの機能追加 PR、Cloud Run のドメインマッピング、CI/CD トリガーの世代切り替え提案と障害解決 CMS 移行（自身が設計、作業は一部メンバーへ依頼）: Contentful から Strapi への記事データ移行と Contentful 解約 【課題・問題点】 コーポレートサイトはビジネス影響が大きく、サイトを止めずに新旧を並行稼働させながら段階的に公開する必要があった 段階公開（新旧サイト混在）では canonical / robots.txt / sitemap / GA4 / Search Console / Clarity など SEO・計測の継続性が壊れやすい オウンドメディアは表示速度スコアが低く、メディアとしての集客力に影響していた CMS 移行では記事 URL が変わると SEO 資産を失うため、既存 URL を完全に維持する必要があった 【打ち手・使用した技術】 段階公開は LB のパスベースルーティングで「特定 URL のみ新サイトへリダイレクト」する構成を設計。DNS 切り替え当日は切り戻し・中止の判断時刻を事前に決めて実施し、手順書を社内 wiki に整備（自身が主担当。LB 設置手順は社内エンジニアへの質問会を自ら設定して確立） タグ・SEO は新旧混在時の設置要否（GSC タグ不要、GA/Clarity は Next.js 側へ埋め込み必須等）を事前調査してから公開。Next.js の AssetPrefix を活用して静的アセットのパスを制御 パフォーマンスはサイドバーの dynamic import・キャッシュチューニング・LB の CDN 機能追加を段階実施し、実施前後で PageSpeed スコアを計測して社内外へ報告（デスクトップ 50〜65 → 60〜85、モバイル 45〜50 → 50〜55） CMS 移行は Strapi 側の public ID を SQL で旧 ID へ付け替えて既存 URL と公開日時を継承。移行時に公開日時の更新漏れで記事非表示の障害が発生した際は当日中に原因特定・復旧し、再発防止として「引き継ぎ作業は作業内容・影響範囲・前提条件をテキストで明文化する」ルールを設定 Contentful 解約前には有効サイト全ソースコードを走査して依存箇所を洗い出し、影響を整理した上で停止を提案・実行 【成果】 3サイトのリニューアル公開を完了。オウンドメディアは CDN 設置で表示速度スコアを改善（上記計測値） CMS を Strapi へ統合し Contentful を解約、SaaS コストを削減。インフラ・運用手順を文書化し後任へ引き継ぎ完了 使用技術: Next.js / TypeScript / Strapi / Contentful / GraphQL / GCP (Cloud Run, Cloud Load Balancing, CDN, Cloud Build) / MySQL / GA4 / Google Search Console / Microsoft Clarity / GitHub・Bitbucket # プロジェクト経験② QA チーム発足とドメインモデリングの再設計 ## ＃プロジェクト経験概要 プロダクト開発部門にて QA チーム発足の責任者を兼任。QA 基盤の年間計画策定と、既存プロダクト（複業マッチングプラットフォーム）の全ドメイン再整理を推進しています。 ## ＃チーム情報 QA チーム2名（自身＝責任者 兼 実務、エンジニア1名）。CTO 室・メンテナンスチームとの合同定例で進捗共有し、成果物はプロダクト本部のレビューを受ける体制。 --- ## ＃取り組みA QA チームの立ち上げと年間計画の策定 【概要】 QA チームの活動方針をゼロから設計し、マネージャー・リーダー層と合意形成。 【どのような業務か】 - 年度で実施すべき内容を DesignDoc 2本（①ドメインモデリング ②QA 基盤整備）にまとめてレビューを実施し、「まずドメインモデリングに注力する」方針と最終アウトプット（ドメイン知識のルールドキュメント化＋E2E テスト）を確定 - QA 年間計画の草案作成、上期目標とスケジュールの合意、QA 定例のゴール設計 【課題・問題点】 - 長年の開発でドメイン知識が暗黙知化しており、QA の判断基準となる仕様の一次情報が存在しなかった - 開発の実態を伝聞ベースで判断すると計画が崩れるリスクがあった 【打ち手】（自身が主担当） - DesignDoc に「伝聞やコードからの推測が含まれる」箇所を明示して開発責任者に事実確認を依頼し、推測と事実を分離した上で計画化 - 4月に最初のドメイン整理を自身で完遂させ、その実績工数をベンチマークに残り全ドメインの工数見積もり（人日単位）とロードマップを作成。メンバーとの担当分担・完了予測（最速で10月末）まで数値で合意 【成果】 - QA チームの活動計画が経営・開発サイドと合意された状態で始動。工数根拠のあるロードマップにより優先度議論が可能に --- ## ＃取り組みB 既存プロダクトのドメインモデリング再整理 【概要】 プロダクト全体を約10ドメインに分割し、ドメインごとに仕様の一次情報を体系的に文書化。 【どのような業務か】 - 各ドメインについて「ドメインスコープ設計→ユースケースシナリオ作成→画面・エンドポイント整理」の順で分析し、成果物4点セット（ドメインモデリング図／オブジェクト図／ユビキタス言語リスト／ユースケースシナリオ）を作成 【課題・問題点】 - 集約整理の基準やレビュー観点を確定させないまま作図を進めた結果、セルフレビュー段階で見直しが発生し全成果物への反映という手戻りが発生 - ドメインを跨いだ用語の揺れがあり、シナリオの粒度も作成者間でブレた 【打ち手・使用した技術】 - 「完成判定に使うレビュー観点（チェックリスト）を作成前に定義し、判断基準を先に確定させてから作る」プロセスへ転換し、手戻りの発生地点を作成前へ前倒し（自身が改善策を設計しチームルール化） - ユビキタス言語リストで用語を統一し、シナリオ粒度はメンバーと再定義して基準を揃えた（チームで実施) - セルフレビュー→プロダクト本部レビューの2段レビューを標準プロセス化。ドメインで発見したリファクタ課題は都度チケット化して開発へ還元 - Gherkin 記法のユースケースを元に AI（Cowork）でフロントエンドの簡易テストを実行する検証も実施し、QA 基盤フェーズへの布石に 【成果】 - 暗黙知だったドメイン知識が、レビュー済みの一次ドキュメントとして開発・QA 双方から参照可能に。コンテキストマップによる全体俯瞰も整備中 - 使用技術: ドメイン駆動設計（DDD）の手法（ユビキタス言語 / オブジェクト図 / コンテキストマップ）/ Gherkin / Confluence / Claude・Cowork