ID:59651さん

## 部署 IT部　リライアビリティチーム（CRE）／ミッションコントロールセンター（全社横断組織）兼任 2026/3〜 CREマネージャー／ミッションコントロールセンターマネージャー 2025/10-2026/2 CREリードエンジニア ネット専用スーパー「Green Beans」を運営する新設会社で、社内外のユーザーのシステム利用を支えるCRE組織を担当。主にJIRAを使ったフロー整備や生成AI導入、大型障害のインシデントコマンダーやポストモーテム文化の醸成に努める。 ## 1. 問い合わせを発生させない導線の設計 ### 1-1. アカウント・権限付与の役割分離 SaaSと社内システムを横断する権限付与依頼がCREへ集中し、可否判断まで抱え込む状態にあった。権限体系と付与基準を調査し「CREは付与者ではなくトリアージ担当」と再定義、各管理者へ振り分けるフローを確立。JIRAの自動化を中心に、フロー整備や正しいフローの啓蒙活動、それに必要なデータの分析を行い、大量の異なるジャンルからの導線を正しい担当者へデリバリーできる状態を継続した。 ### 1-2. トイル削減プロジェクト 対応の速さではなく発生量そのものを削減対象と定義したプロジェクトを企画・稟議。課題棚卸から効果測定までの週次サイクルを設計し、チケット化されない隠れトイルも対象に含めた。一番効果のあった削減策として、依頼元へのツールレクチャーで月100件の依頼が発生しない体制を形成し、再アサイン（5分×月100件）等の自動化で月約65時間を削減。前月比約2倍（164件）まで増加した定型作業は依頼元自身が対応できる形へ移管し、移管後の起票はゼロとなった。 ## 2. インシデントマネジメント ID管理から、受発注システム、倉庫内出荷に関するロボット、システム、ネットワーク障害・セキュリティインシデントなどあらゆる分野の障害で重大なインシデント発生時の一次オンコーラーとして24時間365日のシフトを3名で組み、週2件前後・月10件規模に対応。 15分以内に対応チームを結成する体制を整備し、対外報告・関係者を巻き込んだポストモーテムのリードと恒久対策の実施までを担当。暗黙知だったインシデントレベルは初学者でも判断できる基準へ文書化し、テンプレートに沿えば漏れなく判断できる形へ再構築した。 ## 3. 生成AI活用推進 生成AIツールの導入担当から、AIエージェントを自ら内製して運用に載せ、IT部全体のライセンス・コスト・普及・統制までを担う範囲へ拡大した。 ### 3-1. 運用手順のAIエージェント化 社内ITヘルプデスクの定型運用を、AIエージェントが実行可能な手順として体系化。判断基準の共有マスタへの一元化・冪等設計・自動化ツールへの移管条件の事前定義を設計原則として固定した。自身で31件を作成して週次・月次の手作業を自動化する一方、命名規則とフォルダ構成の正本を整備して他メンバーが同じ型で作れる状態にし、5ヶ月で208件・作成者21名へ拡大。特定個人に依存しない体制とした。 ### 3-2. 定期巡回によるチケットトリアージ Slack常駐型のAIエージェントを構築し、月1,000件規模のタグ付け、週20件規模のアカウント申請の連携調整漏れ、期限付きタスクの期限切れを日次で巡回。人手では維持できない頻度の点検をエージェントの責務として設計した。 ### 3-3. 判断を要する領域のAIエージェントへの委譲 機械的に決まる領域は既存ルールで完結していた一方、IT部への新規リクエストは導入スコープや管理主体の判断を要するためルール化できず、経験知に依存していた。 過去90日・110件を全件分析し、判断パターンを3段階の判定フローとして辞書化。チケットの状態遷移を起点にエージェントを起動して担当を確定する経路を構築し、ルールで裁ける領域は既存の自動化に残して判断を要する領域のみを委譲することで、IT部への新規リクエストは人が介在せず担当が確定する状態とした。例外は辞書に蓄積し優先参照させ、運用するほど精度が上がる構成としている。 ### 3-4. IaC（Terraform）によるID管理と定義の保守 IT部の正社員・業務委託 約100アカウントのEntra IDをTerraformで管理。月10件規模の入退場に伴うユーザー追加は、フローをMiroとNotionで構造化して手順化し、CRE・SREとシニアマネージャーの計6名で分担できる状態に整備、Devinで半自動化した。一方、定義漏れやEntra ID側の手動追加との乖離によるエラーは切り分けに半日を要するため、担当できる要員が2名となった状況下で、自身が一次トリアージから原因特定・再定義までを担い、レビューを経て適用（apply）まで実施している。 ### 3-5. 生成AIの導入・普及とライセンスガバナンス Claude CodeのIT部導入を主管し、利用者想定の取りまとめから契約交渉まで担当。SSO確立、費用決裁と月次支払いの自動化、リスク評価とガイドライン整備など、利用者が自力では越えられない障壁を先に片付け、IT部41名中33名（80.5%）へ付与。利用実績を月次で可視化するスキルを自作し、利用者数・利用強度・キャッシュ効率・コストを追える状態を整備。利用が倍増した月もキャッシュ効率により定額プラン内に収まり、追加課金ゼロを維持。他部署からの個別ツール導入要望は、対象スコープと代替手段を提示して全社共通ツールへ誘導し、適用範囲を広げない運用とした。 ### 3-6. AI利用ガイドラインの改訂 グループ会社とガバナンスを揃えるAI利用ガイドライン改訂プロジェクトに、情報セキュリティ委員会のAIガバナンス分科会メンバーとして参画。MCP接続の実態調査とAIツールの洗い出し・プロコン整理を担当し、作成した台帳を母体データとして改訂リリースに至った。 ## 4. ピープルマネジメント 直属3名（＋業務委託2名）の一次評価者。1on1は隔週で実施し、進捗管理ではなく配慮すべき状況の把握と本人のロールモデルの言語化を目的に運用。採用では書類選考と一次面接を担当し3ヶ月で約6名を面接。 判断のばらつきを抑えるため観点と配点体系を統一し、選考業務自体も生成AIでスキル化し、書類選考から採用管理システムへの記録までを1件30〜60分から約10分へ短縮。 ## 5. 【環境／ツール】 コミュニケーションツール：Slack、Teams 情報管理ツール: 編集閲覧 Microsoft 365、Notion、Miro、Jira Software、Jira Service Management 管理領域：Entra ID、Terraform、Azure、GitHub 生成AI：Devin、Copilot、Gemini、NotebookLM、Cline、Claude Code

# 職務要約 ## 部署 2023/11〜2024/11 CS部　カスタマーサポートチーム/業務企画チーム兼任　マネージャー 物流向け自動搬送ロボット（RaaS）のカスタマーサポートおよび業務企画を担当。問い合わせ月100件規模の体制が、事業拡大により件数の倍増を見込む状況にあり、個別の対応改善ではなくサポート体制そのものの再設計に取り組んだ。問い合わせデータの構造化と傾向分析を起点に、委託先・開発・営業を横断して対応方針を決定する役割を担う。 ## 1. 問い合わせデータの構造化と対応方針の決定 不具合チケットが症状ベースでのみ記録されており、どの製品のどの領域に負荷が集中しているかを集計できない状態であったため、まずCRM（HubSpot）のプロパティ設計を改修し、症状と原因を分類軸として集計できる構造へ作り替えた。そのうえでハードウェア／ソフトウェア別・システム別に傾向分析を実施し、負荷の集中箇所を特定。ハードウェア修理の多い領域は外部委託の検討に接続し、ベンダー選定まで実施のうえハードウェア部門へ引き継ぎ。ソフトウェアかつ新規案件に集中している事象は、顧客ごとの個別改修に起因する可能性が高いと判断し、改修を担当した開発チームへエスカレーションした。 ## 2. インシデント対応方針の決定 検出したクリティカルな障害について、ユーザーへ告知するか・改修で解消するか・運用で回避するかの3つを選択肢として整理し、インシデント会議をファシリテートして方針を決定。カスタマーサポート・開発・営業にまたがる判断を1つの会議体で決着させ、対応の指針として展開した。 ### 2-1. 同種不具合の水平展開 顧客ごとの個別改修が多く、かつオンプレミス環境で稼働していたため、ある顧客で検出した不具合が他顧客に潜在したままとなる構造にあった。検出済みの事象について、適用の要否・実施タイミング・ユーザーへの告知の有無を営業を含む関係者と調整して展開方針を策定し、問い合わせが発生する前に解消する運用を設計（リリース作業は開発が担当）。 ## 3. サポート体制の再構築（コールセンターの外部委託） 1次受付から4次受付までのサポート網を、各層の稼働時間帯・雇用形態（正社員／派遣社員／業務委託／アウトソース）・担務の粒度まで分解して可視化。1次受付は24時間365日体制であるものの技術的な切り分けができず、実質的な回答を持つ2次受付は平日9〜17時のみという構造上のギャップを特定した。 当時は問い合わせ月100件を社員1名と常駐の業務委託2名で対応しており、月200件へスケールする際は常駐要員を増員する構図で、要員が入れ替わるたびに教育コストが発生するうえ、24時間365日対応にも耐えられない状態にあった。 技術的なバックボーンを持つ専門コールセンターを発掘から選定契約まで主導。 1次・2次受付を統合し、増員が教育コストに直結しない構造へ転換する方針を設計。 部長レイヤーの合意を形成したうえでCOOへ提案し、承認を獲得した。 ### 3-1. 委託形態の判断フレームの設計 選定に先立ち、インハウス（正社員／請負）とアウトソース（専任／シェアード）の4区分で委託形態を定義し、それぞれの利点と制約を整理。あわせてコア業務とノンコア業務の切り分け基準を設定し、標準化が可能な業務を委託対象とする判断軸を明文化した。稼働時間を拡大するほどコストが増大する構造も判断材料として置いた。 ### 3-2.ベンダー選定と段階的な移行 4社へのヒアリングを経て3社から見積もりを取得し、技術対応の親和性から1社を選定。移行にあたっては全体を一度に移管せず、2024年7月より1次受付のみを先行して置き換え、その運用期間をトライアルと技術教育に充てる設計とした。 ### 3-3.教育の内製化 FAQを整備したうえで研修を設計・実施。過去の問い合わせからハードウェア・ソフトウェアのユースケースを20件作成し、自身が顧客役となってランダムに出題するロールプレイを行い、対応後にフィードバックの場を設けてオペレーター10名全員に実施した。2次受付の統合時には、常駐していた既存の業務委託メンバーへ教育の役割ごと引き継ぎ、委託先内で教育が完結する状態とした。 ### 3-4. 旧体制の解約と統合 トライアル期間中に対応能力を評価して既存委託先との契約終了を判断し、交渉および関係先への説明を自ら担当。着手から約3ヶ月で2次受付の統合までを完了し、1次と2次を1社に集約したことでエスカレーションの段数が縮まり、24時間365日の技術対応を維持したまま件数の増加に耐えられる体制へ移行した。運用開始後は課題を洗い出しながら委譲範囲を段階的に拡大した。 ## 4. 受電オペレーションの平準化と属人化の解消（クラウドPBXの導入） 従来は貸与した社用携帯への直接架電で受電しており、シフト制であるにもかかわらず担当交代時の引き継ぎが成立せず、休暇中のメンバーへ直接電話が入る状態が発生していた。 メンバーの負荷の偏りを懸念する声も上がり分析。 hubspotのチケットを分析するとメンバー間で受電数に偏りがあり、最も多く受けていたのがリーダーである社員であることが判明した。 ただ詳しく分析していくと、①古参の顧客はリーダーが受けている。理由としては電話番号自体が知られている②新規ユーザーはリーダーは取れていない と負担の構造が単なる受電率では異なることがわかった。 シフトの引き継ぎ、メンバー負荷の偏り解消、この2つの課題を解消するために導入を提案し推進した。 ### 4-1.クラウドPBXの導入を推進 候補10社から資料請求により5社へ絞り、必要条件をマトリクスで比較したうえで2社をデモ環境で評価し、オペレーターと協働して性能を検証して選定した。 着信のラウンドロビン配分を設定した結果、受電比率は3:4:3へ是正され、リーダーは生まれた余力を業務委託メンバーからのエスカレーション対応に充てられる状態となった。 あわせて全員が同条件で受電する状態となったことで受電率を横並びで集計できるようになり、負荷配分を調整する根拠として提示した。 ### 4-2. チーム運営 立ち上げ途上のチームに対し、FAQのNotionへの移行、コールセンターKPIの再設定、新人受け入れ手順の整備、チーム会議のファシリテーションを担当。また、新プロダクトのタスクフォースにカスタマーサポートの代表として推薦され（2024年4月）、導入後サポートのオペレーション設計とユーザー向けマニュアルの再構成を担当した。 ## 5. 【環境／ツール】 コミュニケーションツール：Teams 情報管理ツール: 編集閲覧 Microsoft 365、Notion、kintone、HubSpot、Miro 閲覧中心 Jira Software、GitHub、MySQL、nginx

# 職務要約 ## 部署 CS＆OP部 2022/5〜2023/10 harmo株式会社（100%出向）に在籍し、2019年6月にソニー株式会社より承継した電子おくすり手帳「harmo」の全面リニューアルに伴う、カスタマーサポートおよびオペレーション（コールセンターとオンサイトはアウトソーシング）の構築業務を担当。 ## 1. カスタマーサポート業務 ソニーより継承した電子おくすり手帳システム（薬局にタブレットを設置し、ネットワークを通してクラウドのデータベースと連携するシステム）のサポート体制のオペレーション構築、ヘルプデスクの管理。 問い合わせは月200件程度 - ヘルプデスクのエスカレーション対応（月30件程度） - ヘルプデスクのFAQ作成 - 運用フローの検討 - 問い合わせ分析業務（月次） ## 2. 全国約1,000店舗を対象としたシステム入替プロジェクト（オペレーション設計・ベンダーコントロール） ソニー製の電子おくすり手帳を自社製品へ全面リニューアルに伴う全国規模のシステム入替を担当。 導入ベンダー1社と契約し、地域ごとに再委託先を切り替える体制を設計。 既存の導入対象700社からagreementを取得する際、同意取得フォームに現行の機器構成・導入希望時期・必要台数のヒアリングを組み込み、個別ヒアリングを発生させることなく導入スケジュール設計の基礎データとして活用。 ソフトウェア開発のリリース時期の遅延に伴い、導入計画を3度組み替え。 ### 2-1. 導入不成立の原因特定と手順の標準化 主要レセプトコンピュータを使用する薬局を訪問し、連携可否を実地で調査。 Windows 7／8環境では動作しない構成であることを特定して導入対象を再設定。 さらに特定1社以外のレセプトコンピュータでは調剤情報の連携が成立しないことを突き止め、調査結果を根拠に開発へ再調査を依頼し、実装の大幅なリファクタリングにつなげた。 検証済みのケースはパターン化し、フィールドエンジニア向けの手順書として配布。 ### 2-2.データを根拠とした導入停止の意思決定 2023年6〜8月に200店舗へ着手したが、導入成功率は約50%にとどまる。 事前に計画の見直しを進言したものの事業継続の存続可否と天秤の上、着手継続と判断されたため、実績値をもとに残り約500店舗へ同条件で展開した場合の失敗件数・再訪問件数・所要リソースおよびユーザーへの影響を定量化。 社内の交渉窓口である部長と連携しつつ、自身もCEOへ直接データを提示し、一度は導入継続として判断された状態を会社として導入を一時停止する意思決定に至った。 あわせて開発への改修依頼と導入スケジュールの再設計を実施。 ### 2-3. 導入ベンダーのマネジメント スケジュール変更が重なるなかで委託先の実働キャパシティが縮小した局面では、地域別の人員配置から主要レセプトコンピュータ3社への対応順を軸とした段取りへ計画を組み替え、導入を継続。 社内でエスカレーション対応チーム（4名）を組成し、対応手順と情報集約のオペレーションを構築。集中的なトライアンドエラーにより早期不具合の発見、後のコールセンター移管のナレッジを構築。 ### 2-4.ドキュメント・ツールの整備 入替手順書はNotionに集約し、フローはMiro、Notion上はMermaidで可視化。外部公開向けFAQサイトはZendesk・Helpfeelを比較検討のうえ、構築・委譲コストの低さからwikipyを採用。 ## 3. リリース品質の担保（QAプロジェクト） QA専任者が不在の状況でQAをプロジェクト化する方針となり、リリースが遅延し、オペレーションも後ろ倒しになることから、期間限定で兼任メンバーとして自ら参画（4名体制）。 前職の経験を活かし、QAリーダーとマインドマップでテストシナリオを設計し約1,000項目を洗い出したうえで、検証の実行は外注メンバーへ委譲。 自身は現行システムと新システムの差分という最もリスクの高い領域に注力する体制とした。 結果、現行システムに存在する工程が新システムで欠落している事象を多数検出し、リリースを遅らせてでも修正するという意思決定につながった。 ## 4. 【環境／ツール】 コミュニケーションツール：Slack、Teams 情報管理ツール: 編集閲覧 Microsoft 365、Notion、kintone、Salesforce、Box、Miro 閲覧中心 Jira Software