キッティングは今なお「単純作業」と誤解されがちですが、実際には“届いた瞬間から安全に使えるPC”を実現する裏側で、情シスはIT統制やセキュリティ、業務継続を支える高度な設計と運用を担っています。なぜその価値は見えず、評価されないのか。キッティングの本質を掘り下げます。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
「PCキッティングなんて誰でもできる単純作業でしょう?」
突然ですが、この認識は明確に間違っています。むしろ、PCキッティングを軽視している組織ほど、IT統制やセキュリティ、業務生産性のいずれかに課題を抱えているのです。
PCキッティングは単にPCを箱から出し、初期設定をし、アプリケーションを入れる作業ではありません。従業員が安全かつスムーズに業務を開始するための、セキュリティ・ガバナンス・業務生産性の起点なのです。
しかし残念ながら、その成果は非常に見えにくいものです。問題が起きないこと、ユーザーが困らないこと、インシデントが発生しないこと。それらは本来、大きな成果であるにもかかわらず、何も起きていないように見えるため、価値が認識されにくいのです。
この連載の第1回では、PCキッティングの本質とそれが企業にもたらす価値、そして情シスがその価値を業務部門や経営層にどう伝えるべきかについて整理します。
情シスは採用の見極めや評価指標の不在、意思決定の曖昧(あいまい)さにより、その実力や価値が正しく伝わりにくいジレンマを抱えています。本連載では、経歴の見抜き方やツール選定の本質、ヘルプデスクやキッティングの再評価、“ぼっち情シス”の限界などを通じて、単なる「何でも屋」から脱し、正当に評価されるための実践的な視点を提示します。
PCキッティングを軽視する人の多くは、「1台のPCを手動でセットアップする作業」をイメージしています。例えばそれは以下のような流れです。
確かにこれだけを切り出せば、一定のITリテラシーがあれば対応できる作業に見えます。しかし企業のIT環境におけるキッティングは、そのような単純な作業ではありません。本質は「1台を作ること」ではなく、正しい状態の端末を、正確に、大量に、効率的に、再現性を持って、セキュリティを確保しながら展開する仕組みを作ることにあります。
この違いを理解していないと、キッティングの価値は永遠に見えません。1台を手作業で設定することと、数十台、数百台、場合によっては数千台の端末を、同じ品質で展開し続けることは全く別物です。そこには標準化や設計、検証、自動化、例外対応、運用改善、監査対応といった複数の要素が含まれます。つまりキッティングは単純作業ではなく、企業ITの品質を左右するエンジニアリングなのです。
ユーザー視点では「PCが届いたらすぐ使える」ことは当たり前のように感じられるかもしれません。しかし、この当たり前を実現する難易度は非常に高いものです。筆者としてはそれは以下の条件がそろっていることだと考えます。
これらが一つでも欠けると、ユーザーはすぐに業務を開始できません。さらに重要なのは「問題が起きない状態」を維持し続けることです。実運用では、ポリシーの競合やアプリ配布の失敗、OSアップデートとの整合性、デバイス登録の不整合、ライセンス不足、ネットワーク制約、ユーザー権限の問題など、さまざまなトラブルが発生する可能性があります。
これらを未然に防ぎ、問題が発生したら迅速に原因を特定し、再発防止策を講じる必要があります。ここまでで分かった方もいるかと思いますが、これはもはや初期設定作業ではなく、高度な設計と運用の領域です。
最近は「Microsoft Intune」「Windows Autopilot」「Microsoft SCCM」などを活用したゼロタッチデプロイが主流になりつつあります。
ただ、「PCを開封したらすぐ使える状態にする」という一見シンプルな体験の裏側には、極めて複雑な設計が存在します。例えばゼロタッチデプロイを成立させるには、ネットワークやID基盤、MDM、ライセンス、アプリケーション配布、ログ、監査といった複数の領域が横断的に関わります。
具体的にはプロキシやVPN(仮想プライベートネットワーク)、SASE(Secure Access Service Edge)などのネットワーク設計、「Active Directory」や「Microsoft Entra ID」を含むID基盤、Microsoft IntuneなどのMDMポリシー、「Microsoft 365」や各種SaaSのライセンス管理、業務アプリケーションの配布設計、EDR(Endpoint Detection and Response)や資産管理ツールの導入、ログ取得や監査証跡の設計などです。
さらに、これらを単に構成すればよいわけではありません。誰が、どのタイミングで、どの権限で利用できるのか。どの部門に、どのアプリケーションを配布するのか。セキュリティポリシーはどの粒度で適用するのか。初回セットアップに失敗した場合、どのように切り戻すのか。退職時や異動時に、端末やデータをどのように管理するのか。こうした「運用を前提とした設計」が不可欠です。
つまり、ゼロタッチデプロイは単なる自動化ではありません。“企業のIT統制そのものをコード化する行為”なのです。
ゼロタッチデプロイは主に「Windows」の文脈で語られますが、それだけではありません。実際には「macOS」においても同様、あるいはそれ以上に高度な設計が求められます。例えば「Jamf Pro」や「Iru」(旧Kandji)といったMDMを活用したゼロタッチデプロイでは、単なる初期設定の自動化ではなくポリシーとスクリプトによる状態制御が中核となります。
macOSは「直感的で使いやすい」というイメージが強い一方、企業環境においては、むしろ設計難易度が高い領域でもあります。筆者はその理由を以下のように考えています。
例えばAccessibility権限やフルディスクアクセス、画面収録、通知、システム拡張、ネットワーク拡張など、セキュリティ製品や業務アプリが正常に動作するために必要な権限は多岐にわたります。これらを適切に設計していないと「アプリケーションはインストールされているのに正常に動作しない」「EDRが入っているのに期待した保護ができない」「ユーザーに手動操作を依頼しなければならない」といった不完全な状態に陥ります。
つまり、macOSのゼロタッチもまた、単に「macOSを初期設定する作業」ではなく企業として管理可能な状態を作るための設計業務なのです。
macOSのキッティングで特徴的なのは、完成形のイメージを配るのではなく、ポリシーによって端末の状態を継続的に定義する(あるべき状態を維持し続ける)という考え方です。
例えばJamf Proでは、ポリシーにひも付いたスクリプト実行やパッケージ配布、ログイン時やチェックイン時のトリガー、構成プロファイルの適用などを組み合わせることで端末の状態を制御します。
単に「アプリを入れる」だけではなく「セキュリティ設定を強制する」「不要な設定変更を許可させない」「ローカル環境の整合性を保つ」「設定のドリフトを修正する」「特定条件に応じてスクリプトを実行する」「ユーザーの操作を最小限にして業務開始まで誘導する」といった仕組みをつくる必要があります。
例えば、セキュリティエージェントを配布するだけでなく、必要な権限が付与されているかどうかを確認し、未適用であれば修正する。または、特定のアプリケーションがインストールされているかどうかを確認し、なければ配布する。設定ファイルや証明書が正しく配置されているかどうかを確認するといったものです。
これに対してIruが特徴的なのは、Blueprintという概念です。Blueprintとは、端末のあるべき構成をテンプレートとして定義し、それをデバイスに適用する仕組みです。ここで重要なのは、単一のテンプレートを全端末に適用するのではなく、デバイス種別や所属部門、利用用途、リスクレベルに応じてテンプレートの種類を分ける設計思想です。例えば、次のような分け方が考えられます。
それぞれに必要なアプリケーションやセキュリティ設定、OS制御、スクリプト実行、制限事項は異なります。開発者には一定の自由度が必要な一方で、経理や人事など機微情報を扱う部門では、より強い制御が必要でしょう。役職者や管理者権限を持つユーザーには追加のセキュリティ制御が求められる場合もあります。Blueprintの設計を誤ると、過剰な制御によって業務効率を落とすこともあれば、制御不足によってリスクを高めることもあります。
Blueprintは単なるセットアップテンプレートではありません。ITガバナンスの設計図そのものなのです。
企業環境ではWindowsとmacOSが混在しているケースが一般的です。
WindowsはMicrosoft IntuneやAutopilotで、macOSはJamf ProやIruで管理するといった構成は珍しくありません。しかしここで重要なのは、ツールが分かれていても、統制の考え方まで分断してはいけないということです。WindowsにはWindowsの管理手法があり、macOSにはmacOSの管理手法があります。しかし企業として実現したいことは以下のように共通しています。
つまり、キッティングはWindowsかmacOSかという個別ツールの話ではありません。デバイス管理ではなく企業全体の統制設計の問題です。ここで重要になるのは、ポリシー思想の統一やログ・監査の一元化、IDベースのアクセス制御、ライフサイクル管理、例外運用のルール化です。
しかし、ここまで読んで「なるほど、キッティングは高度な設計業務なのだ」と理解できても、現実にはなお、多くの企業でその価値は十分に評価されていません。むしろ、「問題が起きないこと」が当たり前と見なされることで、キッティングは“見えない仕事”として扱われがちです。
だが実際には、キッティングの品質はセキュリティ事故や内部統制、監査対応、従業員の生産性、さらにはIT部門への信頼性にまで直結します。次回は、なぜキッティングが軽視されやすいのか、そして情シスはその価値を経営層や業務部門にどう伝えるべきなのかについて掘り下げます。
NetworkEngineer、ServerEngineerを経て、外資系ベンダーでSIer及び社内システムEngineerを経験。その後、freee株式会社に確実なIPO実現のため、コーポレートIT部門の立ち上げの責任者として参画。同社では、ITEngineerも務めながらCSIRTも兼務し、セキュリティ整備を実施。現在は、バリュエンステクノロジーズ株式会社の執行役員CIO/CISO、情報システム部長/コーポレートエンジニア。また、他社での業務委託やIT顧問なども担いISMSやPマーク取得〜更新、監査対応等も対応。
Linux主要配布版にroot権限奪取の恐れ ゼロデイ脆弱性「Dirty Frag」公開
GitHub侵害で銀行連携停止 マネーフォワード事案が突き付ける開発リスク
Edge、保存済みパスワードをメモリ内に平文保持していると判明
NIST、ついに“脆弱性の全件分析”を断念 CVE爆増でパンク状態、方針転換
LinuxカーネルのゼロデイをAIが発見 悪用で簡単にroot権限奪取が可能にCopyright © ITmedia, Inc. All Rights Reserved.