ID:83961さん

●大規模エンタープライズ向け VDIリプレースおよびクラウド移行における方式策定・検証主導 環境・技術スタック: Azure Virtual Desktop (AVD), Citrix Cloud, Windows Server (Active Directory), PowerShell, GPO, SPMT, UWF (Unified Write Filter), ExpressRoute (2Gbps) ●チーム情報・役割 役割：移行設計・方針策定リード（大規模端末群の移行方式策定、フィジビリティテスト計画・実行、自動化スクリプト設計を主導） ●業務内容・成果 A：旧来方式の限界打破と「全一括自動切り替え」方式の確立・検証 【概要】 全国に配備されている大規模な共有操作端末（600台超）の次期クラウドVDI環境への移行において、従来の予備機配送ローテーション方式の破綻を回避し、期限内の完全一括移行を実現する新方式を策定・検証。 【どのような機能の開発・実装か】 Active Directory（AD）のOU変更とGPO適用による、書き込み保護（UWF）配下端末への環境切替・証明書自動配布ロジックの構築および検証。 【課題・問題点】 現行ハードウェアの保守期限に伴い「年内の完全移行」が絶対条件であったが、旧来の手動キッティング・配送方式では作業遅延が累積し、完了が1〜2ヶ月以上遅延するリスクが顕在化していた。また、対象端末はUWF（書き込み保護フィルター）が有効化されており、通常の設定変更が再起動後に保持されない制約が存在した。 【打ち手・使用した技術】 前提条件をゼロベースで見直し、UWF保護下であってもAD上のOU移動に伴うGPO適用はバックグラウンドで即時反映・永続固定化されるシステム仕様に着目。 1.OU変更に伴うGPO制御による自動化設計: 接続先URLの上書き変更および次期デジタル証明書（ルートCA/下位CA）の信頼ストアへの自動インジェクション構造を設計。 2.夜間自動処理ロジックの構築: PowerShellスクリプトを用いて、対象端末オブジェクトの所属OUを一括付け替える夜間自動処理ロジックを作成。 3.フィジビリティテスト主導: UWF有効状態の検証実機を用い、OU移動直後のGPO動的引き込み、再起動後のレジストリ保持、閉域網を経由したSSOログイン疎通などのフィジビリティテスト（動作検証）を主導。 【成果】 現場ユーザーの手間や現地SEのキッティング工数を最小限に抑えつつ、年内一括移行を確実にする実行可能なロードマップを確立。後続のオンプレサーバー退役スケジュール全体の遅延リスクを完全に解消し、移行工数を大幅に短縮した。 ●業務内容・成果B：クライアントアプリ（Citrix Workspace app）更新に伴うリスク検証と運用設計 【概要】 基盤移行に伴うクライアントアプリケーションのバージョンアップにおいて、セキュリティポリシー動作への影響領域を特定し、サイレント配信による一括更新アプローチを策定。 【どのような機能の開発・実装か】 移行フェーズにおけるCitrix Workspace appの自動アップデート検証、および権限分離環境下でのリカバリー運用の整理。 【課題・問題点】 旧バージョンのまま移行した場合、接続自体は可能であるものの、次期環境のセキュリティポリシー（画面キャプチャ禁止、強制ログオフタイマー等）が正常動作しない実害リスクが懸念された。また、一般ユーザー権限ではアップデートが不可能であるため、配信方式の精査が必要であった。 【打ち手・使用した技術】 1. 動作境界線の精査: 現行バージョンと次期推奨バージョンの差異、および各種セキュリティGPOの動作境界線を机上・実機にて精査。 2. 無人配信の評価: UWF保護環境下における配信ツールを用いた無人サイレントアップグレードの評価（フィジビリティテスト）を実施。 3. リカバリー手順の策定: 万が一の配信失敗端末に対し、特権アクセス権を用いた現地対応用の物理リカバリー手順（手順書作成・切り分けシナリオ）を策定。 【成果】 セキュリティガバナンスを確実に担保した安全なアプリケーション更新プロセスを構築し、移行本番に向けた運用設計の信頼性を大幅に向上させた。

●Azureエンタープライズ共通基盤（ALZ）におけるハイブリッドネットワーク設計構築、IaC運用および高度トラブルシューティング 環境・技術スタック: Azure Landing Zone (ALZ), Azure Virtual WAN (vWAN), DNS Private Resolver, Azure Firewall, Bicep, Windows Server (AD), PowerShell, TCP/IP, 明示的プロキシ, Chromiumサンドボックス仕様 ●チーム情報 役割：インフラ・ネットワーク領域のリードアーキテクト（詳細設計・高度トラブルシューティング・IaC実装を単独で主導） ●開発・実装内容A：大規模ハイブリッド環境における名前解決タイムアウト不具合の完全解決 【概要】 オンプレミスとAzureを跨ぐ大規模なハイブリッドネットワークにおいて発生していた、深刻な名前解決のボトルネックを徹底的なルーティング検証により解消。 【どのような機能の開発・実装か】 Azure Landing Zone (ALZ) および Azure Virtual WAN (vWAN)、DNS Private Resolver、Azure Firewallを組み合わせた共通インフラ基盤の最適化。 【課題・問題点】 環境移行に伴い、大規模ハイブリッド環境の一部で名前解決のタイムアウトが多発し、システム間連携に影響が出ていた。原因がネットワーク、DNS、OSのどのレイヤーにあるか判別が難しく、既存チームでは長期間クローズできない難易度の高い課題となっていた。 【打ち手・使用した技術】 マイクロソフトのサポートケースを自ら完全主導。パケットキャプチャや各種ルーティングテーブルを自ら精査し、仮想ネットワーク接続内における「既定のルートを伝達する（Propagate Default Route）」の設定が無効化されていることが、名前解決のパケットが迷子になる真因（ルーティングの不整合）であることを突き止めた。 【成果】 真因の特定に基づき適切なルーティング修正を行い、名前解決のタイムアウト不具合を完全解決。移行プロジェクトの遅延リスクを未然に防いだ。 ●開発・実装内容B：プロキシ自動構成（PAC）における3重デッドロック構造の解明 【概要】 明示的プロキシ環境下で発生した、特定のブラウザ仕様とネットワーク制限が絡み合う極めて複雑な不具合のロジックを解明。 【どのような機能の開発・実装か】 Azure Firewall環境における、セキュアなインターネットアクセス（明示的プロキシおよびPACファイルによる制御）のトラブルシューティングとソリューション策定。 【課題・問題点】 特定のChromiumブラウザ環境下において、プロキシ自動構成（PAC）が正常に機能せず通信が遮断される事象が発生。ネットワーク、ブラウザ、プロキシの仕様が複雑に絡み合い、原因の切り分けが困難を極めていた。 【打ち手・使用した技術】 TCP/IPレイヤーの通信挙動と、Chromiumのサンドボックス仕様を深く分析。結果として、「Azure Firewall配下でのネットワークのデッドロック」「Chromiumブラウザのローカルファイル遮断仕様」「MIMEタイプの不一致」という、3つの異なる原因が同時に絡み合う「3重デッドロック構造」であることを論理的に特定。これを回避するための暫定・恒久ソリューションを独力で策定した。 【成果】 他メンバーでは解決できなかったブラウザ起因の複雑な通信不具合をロジカルに解明。後続のシステム運用やセキュリティ設計に多大な貢献を果たした。 ●開発・実装内容C：Bicep（IaC）によるインフラ自動化コードの解析とバグ修正 【概要】 他者が作成したインフラコード（IaC）のバグや考慮漏れを詳細設計書ベースでコード解析し、プラットフォーム全体のパッチ適用自動化ロジックへ安全に修正を適用。 【どのような機能の開発・実装か】 Bicepを用いた、Azure Update Managerによるサーバ（Windows Server / Active Directory等）へのパッチ適用自動化パイプラインの修正とリファクタリング。 【課題・問題点】 他のメンバーが先行して作成していた `AzureUpdateManager.bicep` のコードにおいて、自動化の分類定義に不備があった。このままでは詳細設計書に記載された厳密な適用スケジュールや対象サーバの分類が正しくインフラに反映されず、本番環境のパッチ適用が失敗するリスクを抱えていた。 【打ち手・使用した技術】 他者が書いた既存のBicepソースコードを自ら1行ずつ詳細に読み解き、詳細設計書との厳密なインプット・アウトプットの突合を実施。問題となっている分類定義のロジックの誤りを自ら特定し、正しい挙動になるようコードの書き換えと検証を行った。 【成果】 既存コードのバグを安全に修正し、プラットフォーム全体へのパッチ適用自動化ロジックへ反映。手動運用を完全に排除し、インフラ全体のセキュリティガバナンスと信頼性をコードレベルで担保した。

●AWS/ハイブリッド環境におけるインフラ運用保守案件のプロセス改善および自動化・標準化の推進 環境・技術スタック: AWS (EC2, S3, CloudTrail, IAM, Route 53, Backup), Linux (RHEL, Amazon Linux), Windows Server 2022, Windows 11, Cybereason, PowerShell, Shell Script, SRE思想 ●チーム情報 役割：運用保守・SRE領域のプロセス改善リード（課題分析、タスクマネジメント、手順標準化・コード化を主導） ●開発・実装内容A：タスク炎上状態のプロジェクトにおける運用プロセスの仕組み化 【概要】 多数の未処理タスクが積載し炎上状態にあったAWS運用保守プロジェクトへ参画し、タスクの可視化とチーム連携の仕組みを新設することでプロジェクトを正常化。 【どのような機能の開発・実装か】 アドホック（その場しのぎ）な運用体制から、ロジカルなタスク管理およびチーム内レビューを組み込んだ「持続可能な運用プロセス」への再設計。 【課題・問題点】 前任担当者から引き継がれた多数の未処理事象が山積みとなり、タスクの全貌や優先順位が不透明なまま、チーム全体が目の前の対応に追われる炎上状態に陥っていた。また、メンバー間での情報共有が不足しており、特定のタスクがボトルネック化していた。 【打ち手・使用した技術】 単なるオペレーターとしての作業にとどまらず、全体を俯瞰した課題解決アプローチを自ら主導。積載していた未処理事象をすべてロジカルに分解し、ビジネスインパクトと技術的難易度から優先順位（マイルストーン）を再定義した。さらに、チーム内での「定期的な内部レビュー」や「目線合わせ（ナレッジシェア）」の場を新設し、心理的・技術的なボトルネックを早期に検知・解消する仕組みを構築した。 【成果】 チーム内の連携が円滑化し、山積みだった炎上タスクをすべて消化。プロジェクト全体を遅延なくオンスケジュールでの完了へと導いた。 ●開発・実装内容B：エージェント導入手順の共通化・標準化による工数75%削減 【概要】 属人化し莫大な時間がかかっていたセキュリティエージェントのインストール作業において、OS間の差異やインベントリ情報を共通化し、手順を標準化・コード化。 【どのような機能の開発・実装か】 AWS上のマルチOS（Linux / Windows）環境に対する、Cybereasonエージェント導入プロセスの自動化・標準化設計。 【課題・問題点】 対象となるEC2インスタンスへのCybereasonエージェント導入作業において、定型的な手順書が存在していなかった。そのため、作業のたびに個別にアドホックな調査（対象OSの仕様確認、IPアドレスやパスワードが記載されたインベントリファイルへの動線確認など）を行う必要があり、1台あたり約2時間もの莫大な工数が発生し、深刻な属人化と生産性の低下を招いていた。 【打ち手・使用した技術】 LinuxとWindowsそれぞれのOSにおけるコマンドラインの差異や、環境固有の情報（インベントリ）など、共通化・標準化できる要素を徹底的に洗い出した。手探りだった作業を誰もが迷わず実行・自動化できるレベルまで手順へ落とし込み、コード化（コマンドの標準化）を実施。さらに、作成した手順をチームレビューにかけることでフィードバックを反映し、さらなる最適化を図った。 【成果】 当初、1台あたり約2時間（120分）かかっていた作業を、わずか30分へと短縮（75%の工数削減 / 4倍の効率化）することに成功。属人化を完全に排除し、チーム全体の生産性向上に大きく貢献した。

●「座指Web」システム AWS移行に伴うインフラ詳細設計・環境構築 環境・技術スタック: AWS (VPC, Subnet, Route Table, Security Group, EC2, Amazon Aurora, Amazon ElastiCache, Amazon S3, Amazon EventBridge, SNS, AWS IAM, AWS Backup), Windows 11 ●チーム情報 役割：インフラ詳細設計・構築リード（12領域の詳細設計、検証、環境構築、単体テストを一気通貫で単独主導） ●開発・実装内容A：入場1ヶ月での12領域におよぶ詳細設計・構築テストの高速完遂 【概要】 オンプレミスからAWS環境への移行プロジェクトにおいて、プロジェクトのインフラの根幹をなす主要AWSリソースの詳細設計から単体テストまでを、極めてタイトなスケジュールの中で完遂。 【どのような機能の開発・実装か】 VPC/Subnet設計、Aurora、ElastiCache、EventBridge（イベントパターン定義）、IAM、Security Group（SG）など、計12領域に及ぶAWSマルチレイヤーインフラ基盤の詳細設計および環境構築。 【課題・問題点】 プロジェクト全体のスケジュールが非常にタイトであり、入場初月からわずか1ヶ月の間で12領域もの詳細設計シートの作成、実構築、そして単体テストまでをオンスケジュールで完了させなければならないという、極めて高い業務密度とスピードが要求されていた。 【打ち手・使用した技術】 WBSをベースに自身のタスクを徹底的に細分化して並行管理。単にドキュメントを作成するだけでなく、内部レビューでの指摘事項の回収、協業ベンダーからのフィードバック反映、さらにお客様とのヒアリングシートを用いた要件定義の往復を自らがハブとなって迅速かつ円滑に牽引した。これにより、課題解決と意思決定のスピードを組織を跨いで大幅に加速させた。 【成果】 すべてのステークホルダーとの合意形成を爆速で回し、計12領域の詳細設計・構築・テストを1ミリの遅延もなく、完全なオンスケジュールで予定通りに遂行した。 ●開発・実装内容B：制約環境下における顧客要件の精緻な回収とインフラパラメータ設計 【概要】 直接的な権限やアカウントが制限された状況において、顧客の「設計思想や背景」を深く汲み取った高精度なパラメータ設計の実現。 【どのような機能の開発・実装か】 ヒアリングシートの構造化による顧客要件定義の標準化、およびそれに紐づく各種AWSリソースのパラメータ設計・品質管理。 【課題・問題点】 自身のアカウントが直接発行されていないという環境上の制約があり、顧客の本音や要件を直接画面を見ながら、あるいは対面で即座に回収することが難しい状況だった。そのため、要件の吸い上げ漏れや、パラメータ設定における顧客との認識齟齬（手戻り）が発生するリスクを抱えていた。 【打ち手・使用した技術】 単に指示された値を入力するだけのオペレーションを徹底的に排除。「お客様がどういう思想や背景でこのリソースを選定したか」をビジネス・技術の両面から逆算して設計するアプローチをとった。制約を打破するために、ヒアリングシートを通じて間接的に顧客要件を精緻に回収する手法を確立。さらに、社内レビューの段階であらかじめ確認すべき要点を「構造化」してメンバーに共有し、チーム全体のレビュー観点を統一した。 【成果】 顧客との認識齟齬を徹底的に排除した、極めて高品質なインフラパラメータ設計を担保。後続の工程における設計起因の手戻り「ゼロ」を達成した。