「PCを配るだけの仕事」と思われがちなキッティングですが、その品質次第でインシデントや運用負荷も、ITコストも大きく変わります。それでも情シスの仕事は“何も起きない”ほど評価されません。情シスが経営層に伝えるべき“本当の価値”を掘り下げます。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
前編では、「PCキッティング=単純作業」というユーザーが抱きがちな“誤解”を解き、企業IT・セキュリティの品質を左右する高度なエンジニアリングが本来は必要になるはずと提言しました。
後編となる今回は、なぜキッティングが軽視されやすいのか、情シスがその価値を経営層や業務部門にどうすればうまく伝えられるのかを考えていきましょう。
情シスは採用の見極めや評価指標の不在、意思決定の曖昧(あいまい)さにより、その実力や価値が正しく伝わりにくいジレンマを抱えています。本連載では、経歴の見抜き方やツール選定の本質、ヘルプデスクやキッティングの再評価、“ぼっち情シス”の限界などを通じて、単なる「何でも屋」から脱し、正当に評価されるための実践的な視点を提示します。
多くの組織で見落とされがちですが、キッティングはセキュリティの起点です。ここでの設定品質によって、端末が適切な管理下に置かれるかどうか、EDR(Endpoint Detection and Response)やログ収集が機能するかどうか、インシデント発生時に追跡できるかどうかが決まります。
EDRを導入していない端末や、ログが取得できない端末が混在している環境では、インシデント対応は非常に困難になります。端末が暗号化されていなければ、紛失時の情報漏えいリスクは高まります。管理対象外の端末が業務に使われていれば、脆弱性(ぜいじゃく)対応やアクセス制御は不完全になります。ローカル管理者権限が適切に制御されていなければ、不正な変更やマルウェア感染時の影響範囲が広がります。ログが残っていなければ、何が起きたのかを後から確認することもできません。
つまりキッティングとは、セキュリティ対策を実行可能な状態にする必要不可欠な工程です。セキュリティ製品を契約しているだけでは意味がありません。MDM(モバイル端末管理)を導入しているだけでも不十分です。ポリシーが正しく適用され、端末が管理下にあり、ログが取れ、インシデント対応できる状態になって初めて、セキュリティ対策は機能します。その起点がキッティングなのです。まずはその認識でキッティングを再考する必要があるでしょう。
それでもなお、キッティングは軽視されがちです。その理由はシンプルで成果が見えにくいからです。以下は企業のシステム環境にとって非常に良い状態です。しかし良い状態であればあるほど、「何も起きていない」かのように見えてしまいます。
加えて、キッティングは「誰でもできる作業に見える」「外注できそうに見える」「手順書があれば回せそうに見える」と思われがちです。もちろん作業の一部を外部に委託することは可能ですが、設計思想そのものを持たずに外注すると、単なる作業代行になってしまいます。
その結果、「端末ごとに設定が微妙に違う」「管理対象外の端末が残る」「セキュリティ製品が入っているだけで機能していない」「ライセンスが適切に割り当てられていない」「インシデント発生時にログが追えない」「ユーザー体験がバラバラになる」といった問題が後から表面化します。
キッティングの品質が低い環境では、セキュリティインシデントの増加やITサポートコストの増大、従業員の生産性低下という形で、確実にコストとして跳ね返ってくることを忘れてはいけません。
「Jamf」や「Iru」「Microsoft Intune」といったMDMを扱ったことがある人であれば分かるはずですが、ポリシー設計を誤ると全端末に影響が出ます。
スクリプト一つで業務停止が起きることもある他、配布対象を誤れば、不要なアプリが全社に展開されることもあります。制限設定を誤れば、必要な業務アプリが動かなくなることもあるでしょう。Blueprintやポリシーグループの設計次第で、運用コストが数倍変わってしまうこともあります。
ここまで聞けばキッティングが最も設計品質が問われる業務だと認識を改められるのではないでしょうか。キッティングを軽視している人は、手作業で1台をセットアップする場面しか見えていないのだと思います。
しかし実際には情シスはその裏側で、業務影響やセキュリティ、運用負荷、監査対応、ユーザー体験、将来の拡張性まで考慮して設計しています。筆者としてはこれを業務部門や経営層に理解してもらいたいのです。
では、この業務の本質を彼らにどう伝えればいいのでしょうか。重要なのは「作業」ではなく「リスクと価値」で語ることです。
「キッティングを頑張っています」では伝わりません。「PCをセットアップしています」でも不十分です。そうではなくキッティングによって、どのようなリスクを抑え、どのような統制を実現し、どのような業務価値を生んでいるのかを説明する必要があります。
例えば、未管理端末があると何が起きるのか。ログが取れないと、インシデント時に何ができなくなるのか。暗号化されていない端末を紛失すると、どのようなリスクがあるのか。初期セットアップに時間がかかると、従業員の立ち上がりにどれだけ影響するのか。手作業に依存すると、品質のばらつきがどれだけ生まれるのか。こうした形で、キッティングを「作業」ではなく「経営リスクを抑える仕組み」として説明することが重要です。
キッティングの価値は見えにくいため、情シス側からKPIを意識的に可視化する必要があります。例えば、次のようなKPIが考えられるでしょう。
これらの指標を定期的に示すことで、キッティングは単なる裏方作業ではなく、業務生産性とセキュリティを支える重要な活動であることを伝えやすくなります。特に経営層に対しては、サポート工数削減やインシデント対応コストの低減、従業員の立ち上がり時間短縮、監査対応の効率化といったROI(投資対効果)で語ることが有効です。
筆者はキッティングを単なる準備作業とは捉えていません。むしろ、企業全体のIT統制とセキュリティレベルを規定する設計工程だと考えています。
これらの意思決定の積み重ねが、そのまま企業のIT・セキュリティの成熟度を決定します。「Windows」であれ「macOS」であれ、キッティングの本質は共通しており、“あるべき状態を設計し、再現性を持って展開し続ける”ことです。そしてその品質がセキュリティやガバナンス、業務生産性の全てに直結するのです。
PCキッティングを「単純作業」と捉えるか。それとも「企業の基盤を支える設計」と捉えるか。この認識の差は、そのまま企業の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.