ITコストが爆増する“低品質キッティング”の特徴 あるべき姿を考える:正しく評価されるための情シス入門
「PCを配るだけの仕事」と思われがちなキッティングですが、その品質次第でインシデントや運用負荷も、ITコストも大きく変わります。それでも情シスの仕事は“何も起きない”ほど評価されません。情シスが経営層に伝えるべき“本当の価値”を掘り下げます。
前編では、「PCキッティング=単純作業」というユーザーが抱きがちな“誤解”を解き、企業IT・セキュリティの品質を左右する高度なエンジニアリングが本来は必要になるはずと提言しました。
後編となる今回は、なぜキッティングが軽視されやすいのか、情シスがその価値を経営層や業務部門にどうすればうまく伝えられるのかを考えていきましょう。
連載「正しく評価されるための情シス入門」について
情シスは採用の見極めや評価指標の不在、意思決定の曖昧(あいまい)さにより、その実力や価値が正しく伝わりにくいジレンマを抱えています。本連載では、経歴の見抜き方やツール選定の本質、ヘルプデスクやキッティングの再評価、“ぼっち情シス”の限界などを通じて、単なる「何でも屋」から脱し、正当に評価されるための実践的な視点を提示します。
結果的にコストが増えちゃう“低品質キッティング”の特徴
多くの組織で見落とされがちですが、キッティングはセキュリティの起点です。ここでの設定品質によって、端末が適切な管理下に置かれるかどうか、EDR(Endpoint Detection and Response)やログ収集が機能するかどうか、インシデント発生時に追跡できるかどうかが決まります。
EDRを導入していない端末や、ログが取得できない端末が混在している環境では、インシデント対応は非常に困難になります。端末が暗号化されていなければ、紛失時の情報漏えいリスクは高まります。管理対象外の端末が業務に使われていれば、脆弱性(ぜいじゃく)対応やアクセス制御は不完全になります。ローカル管理者権限が適切に制御されていなければ、不正な変更やマルウェア感染時の影響範囲が広がります。ログが残っていなければ、何が起きたのかを後から確認することもできません。
つまりキッティングとは、セキュリティ対策を実行可能な状態にする必要不可欠な工程です。セキュリティ製品を契約しているだけでは意味がありません。MDM(モバイル端末管理)を導入しているだけでも不十分です。ポリシーが正しく適用され、端末が管理下にあり、ログが取れ、インシデント対応できる状態になって初めて、セキュリティ対策は機能します。その起点がキッティングなのです。まずはその認識でキッティングを再考する必要があるでしょう。
それでもなお、キッティングは軽視されがちです。その理由はシンプルで成果が見えにくいからです。以下は企業のシステム環境にとって非常に良い状態です。しかし良い状態であればあるほど、「何も起きていない」かのように見えてしまいます。
- 問題が起きない
- ユーザーが困らない
- インシデントが発生しない
- PCが予定通り届き、予定通り使える
- 問い合わせが少ない
- 障害が起きない
加えて、キッティングは「誰でもできる作業に見える」「外注できそうに見える」「手順書があれば回せそうに見える」と思われがちです。もちろん作業の一部を外部に委託することは可能ですが、設計思想そのものを持たずに外注すると、単なる作業代行になってしまいます。
その結果、「端末ごとに設定が微妙に違う」「管理対象外の端末が残る」「セキュリティ製品が入っているだけで機能していない」「ライセンスが適切に割り当てられていない」「インシデント発生時にログが追えない」「ユーザー体験がバラバラになる」といった問題が後から表面化します。
キッティングの品質が低い環境では、セキュリティインシデントの増加やITサポートコストの増大、従業員の生産性低下という形で、確実にコストとして跳ね返ってくることを忘れてはいけません。
ポリシー設計を失敗すれば、運用コストが数倍変わる
「Jamf」や「Iru」「Microsoft Intune」といったMDMを扱ったことがある人であれば分かるはずですが、ポリシー設計を誤ると全端末に影響が出ます。
スクリプト一つで業務停止が起きることもある他、配布対象を誤れば、不要なアプリが全社に展開されることもあります。制限設定を誤れば、必要な業務アプリが動かなくなることもあるでしょう。Blueprintやポリシーグループの設計次第で、運用コストが数倍変わってしまうこともあります。
ここまで聞けばキッティングが最も設計品質が問われる業務だと認識を改められるのではないでしょうか。キッティングを軽視している人は、手作業で1台をセットアップする場面しか見えていないのだと思います。
しかし実際には情シスはその裏側で、業務影響やセキュリティ、運用負荷、監査対応、ユーザー体験、将来の拡張性まで考慮して設計しています。筆者としてはこれを業務部門や経営層に理解してもらいたいのです。
情シス必見、キッティングの価値は「頑張っています」では伝わらない
では、この業務の本質を彼らにどう伝えればいいのでしょうか。重要なのは「作業」ではなく「リスクと価値」で語ることです。
「キッティングを頑張っています」では伝わりません。「PCをセットアップしています」でも不十分です。そうではなくキッティングによって、どのようなリスクを抑え、どのような統制を実現し、どのような業務価値を生んでいるのかを説明する必要があります。
例えば、未管理端末があると何が起きるのか。ログが取れないと、インシデント時に何ができなくなるのか。暗号化されていない端末を紛失すると、どのようなリスクがあるのか。初期セットアップに時間がかかると、従業員の立ち上がりにどれだけ影響するのか。手作業に依存すると、品質のばらつきがどれだけ生まれるのか。こうした形で、キッティングを「作業」ではなく「経営リスクを抑える仕組み」として説明することが重要です。
キッティングの価値は見えにくいため、情シス側からKPIを意識的に可視化する必要があります。例えば、次のようなKPIが考えられるでしょう。
- 管理下にある端末の割合
- 暗号化が有効な端末の割合
- EDRが正常稼働している端末の割合
- MDMポリシー適用率
- 初期セットアップ完了までの平均時間
- 入社日当日に業務開始できた割合
- キッティング起因の問い合わせ件数
- 手作業削減時間
- ゼロタッチ化率
- 例外対応件数
これらの指標を定期的に示すことで、キッティングは単なる裏方作業ではなく、業務生産性とセキュリティを支える重要な活動であることを伝えやすくなります。特に経営層に対しては、サポート工数削減やインシデント対応コストの低減、従業員の立ち上がり時間短縮、監査対応の効率化といったROI(投資対効果)で語ることが有効です。
筆者はキッティングを単なる準備作業とは捉えていません。むしろ、企業全体のIT統制とセキュリティレベルを規定する設計工程だと考えています。
- どのようなポリシーを適用するのか
- どこまでを自動化するのか
- どのように例外を扱うのか
- どのログを取得するのか
- どの状態を「正常」と定義するのか
- どのタイミングで改善するのか
これらの意思決定の積み重ねが、そのまま企業のIT・セキュリティの成熟度を決定します。「Windows」であれ「macOS」であれ、キッティングの本質は共通しており、“あるべき状態を設計し、再現性を持って展開し続ける”ことです。そしてその品質がセキュリティやガバナンス、業務生産性の全てに直結するのです。
まとめと次回予告:ヘルプデスクは“コストセンター”ではない
PCキッティングを「単純作業」と捉えるか。それとも「企業の基盤を支える設計」と捉えるか。この認識の差は、そのまま企業のIT・セキュリティの力の差になります。キッティングを軽視する組織は、見えないリスクを抱えます。キッティングを正しく設計している組織は、見えないところで業務とセキュリティを支えています。
- 問題が起きないこと
- ユーザーが迷わず業務を始められること
- 端末が管理下にあり、セキュリティが機能していること
- インシデント時に追跡できること
これらは全て、皆さん情シスが作り込んだ成果です。だからこそ、情シスには技術力だけでなく、翻訳力も求められます。技術的な作業を、経営リスクや業務生産性、セキュリティ統制の言葉に翻訳する力です。キッティングの本質を正しく理解し、正しく伝えること。それこそがこれからの情シスに求められる重要な役割ではないでしょうか。
次回はヘルプデスク業務の本質と、問い合わせ対応を受け身の仕事から組織改善の起点に変えるために必要な視点について具体的に解説していきます。
筆者紹介:木戸啓太(バリュエンステクノロジーズ 執行役員 CIO / CISO コーポレートIT部 部長/コーポレートエンジニア)
NetworkEngineer、ServerEngineerを経て、外資系ベンダーでSIer及び社内システムEngineerを経験。その後、freee株式会社に確実なIPO実現のため、コーポレートIT部門の立ち上げの責任者として参画。同社では、ITEngineerも務めながらCSIRTも兼務し、セキュリティ整備を実施。現在は、バリュエンステクノロジーズ株式会社の執行役員CIO/CISO、情報システム部長/コーポレートエンジニア。また、他社での業務委託やIT顧問なども担いISMSやPマーク取得〜更新、監査対応等も対応。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
Linux主要配布版にroot権限奪取の恐れ ゼロデイ脆弱性「Dirty Frag」公開
主要Linuxディストリビューションでroot権限を奪取可能なゼロデイ脆弱性「Dirty Frag」が見つかった。情報漏えいによってパッチ提供前の緊急公開となっている。
GitHub侵害で銀行連携停止 マネーフォワード事案が突き付ける開発リスク
マネーフォワードは認証情報漏えいによるGitHubへの不正アクセスを受け、ソースコードや一部個人情報が流出したと公表した。銀行連携機能まで一時停止に追い込まれた今回の事案は、開発現場に潜む見落とされがちなリスクを浮き彫りにしている。
Edge、保存済みパスワードをメモリ内に平文保持していると判明
Microsoft Edgeが保存済みパスワードをメモリ内に平文で保持する仕様が判明した。共有端末などで他者の認証情報が抽出される危険性が指摘されている。Microsoftは仕様であると回答したが、侵害時の被害拡大の恐れがある。
NIST、ついに“脆弱性の全件分析”を断念 CVE爆増でパンク状態、方針転換
NISTは、脆弱性データベース「NVD」の運用を大きく見直す。CVEの急増により従来の“全件分析”が限界に達したためだ。今後は優先度に応じた対応へと転換する。この変更は、脆弱性管理の前提そのものを揺るがす可能性がある。
LinuxカーネルのゼロデイをAIが発見 悪用で簡単にroot権限奪取が可能に
Linuxカーネルに約9年間にわたり見過ごされてきた致命的なローカル権限昇格の脆弱性「Copy Fail」が突如浮上した。この脆弱性を悪用すれば、一般ユーザーが極めて簡単にroot権限を取得できる。さらにこの発見を後押ししたのはAIだという。