情シス初心者向け 基本の考え方（案 v0.2）｜ITILで考えるIT管理
情シスの仕事は、ユーザーの要望より先に「定義」に合わせて回すこと
情シスの仕事は、頼まれたことを頼まれた早さで片付けることではありません。誰に何を、どの手順で、何日で提供するかを先に決め、その定義を1か所に置き、どの依頼も定義どおりに扱うことです。ITILは、そうした定義の型を集めた枠組みです。急ぎの依頼でも定義を飛ばさず、定義に用意した道筋で扱います。
要望駆動これまでの運用になりがちな形
- ユーザーの要望
- 担当者がその場で判断
- 頼まれたとおりに対応
- 担当者ごとに結果が変わる
- 例外が積み上がる
- あとから説明できない
定義駆動これから目指す形
- 定義（1か所に置いた正本）
- 依頼を定義と照らす
- 定義どおりに対応定義になければ、定義を直してから扱う
- 誰が対応しても同じ結果
- 例外が増えない
- 記録で説明できる
1頼まれたとおりに応える運用は、早く見えて、あとで回らなくなる
要望駆動は、ユーザーに頼まれた内容を、頼まれた順に、担当者の判断で処理するやり方です。目の前のユーザーはすぐに喜ぶので、うまく回っているように見えます。
ただ、この運用は続けるほど崩れます。担当者によって判断が変わり、例外が少しずつ積み上がります。強く急かす人ほど早く対応してもらえるので、声の大きい人が得をします。あとから「なぜこの人にこの権限があるのか」と問われても、誰も答えられません。
定義駆動は、先に定義を決め、来た依頼を定義と照らして処理するやり方です。定義にない依頼は、その場で判断せず、定義を決める人に上げて、定義を直してから扱います。
| 観点 | 要望駆動 | 定義駆動 |
|---|---|---|
| 判断の基準 | 目の前の要望と、担当者の判断 | 先に決めた定義 |
| 対応の早さ | 急かした人ほど早い | 誰でも同じ。日数は定義で約束する |
| 結果 | 担当者ごとに変わる | 誰が対応しても同じ |
| 例外 | その場で増え、残り続ける | 定義を直すか、受けないかのどちらか |
| あとからの説明 | 担当者の記憶とメール頼み | 定義と記録で説明できる |
| 担当者が替わったとき | やり方が分からなくなる | 定義を読めば引き継げる |
定義駆動は、ユーザーを待たせるための仕組みとは違います。誰が頼んでも、同じ早さで同じ結果になると約束するための仕組みです。
2定義と記録は、1か所に置く（SSOT）
SSOT（Single Source of Truth）は、正しい情報の置き場所を1つに決める考え方です。ITILの用語ではありませんが、ITILが求める「定義どおりに回し、記録で説明する」運用の土台になります。
正本が複数あると、ユーザーは都合のよい方を根拠にします。担当者も、どれが最新か分からないまま判断することになります。メールやチャットのやりとり、担当者の記憶、古い申請書は、どれも正本にはなりません。
3つは役割が違うので、混ぜずに持ちます。そのうえで、台帳と実データを定期的に突き合わせ、ずれていれば直します。定義と違う運用が見つかったら、運用を定義に戻すか、定義そのものを直すかを決めます。
3「急いでほしい」には、定義に用意した道筋で応える
「急ぎなので、先に登録だけしてほしい」という依頼は必ず来ます。ここで手順を飛ばすと、許可の確認と記録が抜けます。次の人も同じ扱いを求めるので、定義は形だけになっていきます。
管理者の仕事は、目の前のユーザーの不満を早く消すことではありません。決めた定義を守り、全員を同じように扱うことです。不満の声は無視せず、定義を見直す材料として受け取ります。1人を例外で満足させるより、定義を直して全員分を解消する方が、組織にとっての価値は大きくなります。
急ぎそのものを否定する必要はありません。本当に急ぐべき場面があるなら、その道筋を定義の中に用意します。ITILでも、変更を「標準・通常・緊急」の3つに分け、緊急の変更にも決まった手順を置いています。
急ぎの依頼を受けたときの流れ
- 標準の処理日数を伝える。日数は、定義で先に決めておく。
- 急ぐ理由が、定義した「緊急」の条件に当たるかを確かめる。
- 当たらなければ、標準どおりに進めると伝える。足りない情報があれば、何がそろえば進むかを伝える。
- 当たれば、緊急の手順で進める。緊急でも、許可と記録は省かない。
- 同じ急ぎが何度も出るなら、処理日数や手順そのものを見直す。
言い方の例
標準どおりに進めるときこの申請は、決まった手順で受け付けています。許可がそろってから、〇営業日で反映します。
急ぎの事情を受け止めるとき急ぎの事情は承知しました。手順は省けませんが、許可を先にいただければ、その日のうちに進めます。
定義にない依頼のとき決まりのない依頼なので、この場では判断できません。ルールを決める担当に確認して、お返事します。
4ITILは、IT管理の「定義の型」を集めた枠組み
ITILは、ITサービスを安定して届けるためのやり方を、多くの組織の経験からまとめた枠組みです。最新のITIL 4では、34のプラクティス（実践の型）に整理されています。初めから全部を覚える必要はありません。
情シスに来る依頼は、まず「どの型か」を見分けます。型が分かれば、何を定義しておくべきかも決まります。どの型でも、依頼が来る前に定義を決めておきます。来てから考えると、その場の判断が定義の代わりになってしまうからです。
| 来たもの | ITILの型 | 先に決めておく定義 | 例 |
|---|---|---|---|
| 使えない・壊れた | インシデント管理 | 優先度の基準、連絡の流れ、復旧の目安 | PCが起動しない |
| ほしい・使いたい | サービス要求管理 | 受け付ける要求の一覧、申請様式、承認者、処理日数 | アカウントの追加 |
| 設定や仕組みを変えたい | 変更実現 | 変更の種類（標準・通常・緊急）、承認、元に戻す方法 | SSOの設定変更 |
| 誰に何を使わせるか | 情報セキュリティ管理（アクセス管理） | ロール、許可する人、見直しの頻度 | Backlogの権限 |
| 何を持ち、誰が使っているか | IT資産管理、サービス構成管理 | 台帳の項目、正とする情報源 | ライセンス、PC、SaaSの契約 |
| いつまでにやってくれるのか | サービスレベル管理 | 処理日数や対応時間の約束 | 申請から〇営業日で反映 |
| 外部の会社に任せている部分 | サプライヤ管理 | 契約、責任の範囲、確認の頻度 | SaaS事業者、業務の委託先 |
「いつまでに」の約束（サービスレベル）を先に決めておくと、「急いでほしい」への答えを、担当者の気分に左右されずに定義から返せます。
5ユーザー管理は、アクセス管理の型で考える
ユーザー管理は、定義駆動がいちばん効く仕事です。ITIL v3のアクセス管理は、権限の扱いを6つの活動に分けています。情報セキュリティ管理が決めた方針を、日々の権限の扱いとして実行する役目です。ITIL 4では、情報セキュリティ管理のプラクティスの一部として扱われています。
| 活動 | 先に定義しておくこと | 残す記録 |
|---|---|---|
| 申請Request access | 誰が申請してよいか、申請の様式 | 申請の原本、申請者、受付日 |
| 確認Verification | 誰の許可が要るか、何を確かめるか | 確かめた人と、その根拠 |
| 付与Providing rights | どのロールに何を許すか | 付与した日、操作した人、ロール |
| 記録と追跡Logging and tracking | 正とする記録と、その置き場所 | 変更の履歴、システムの実データ |
| 状態の監視Monitoring identity status | 不要になったことに、何で気づくか | 確かめた日と結果 |
| 削除・制限Removing or restricting rights | 何をきっかけに外すか | 外した日と、そのきっかけ |
| 見直し6つの活動の点検 | 頻度と、誰に確かめるか | 見直した日、回答者、結果 |
迷ったときの原則
- 付与より先に、外し方を決める。追加は困る人がいるので申請されますが、削除は申請されません。
- 必要性を判断する人と、権限を渡す人を分ける。渡す側は、記録してから操作します。
- 権限は必要な範囲だけにする。管理者の権限を持つ人は少なくし、通常とは別のアカウントにします。
- 人とアカウントを分け、変わらない番号で結ぶ。メールアドレスは、異動や出向で変わります。
- 「今いるか」はシステムから、「誰か・なぜ」は台帳から取る。手で持つのは、システムが持っていない情報だけにします。
- 続けられる頻度と手段を選ぶ。追い切れない確認は、決めても回りません。
7つの問いで確かめる（Backlogでの当てはめ例つき）
| 活動 | 答えるべき問い | Backlogでの当てはめ |
|---|---|---|
| 申請 | 誰の申請で、何を求められたか | 申請書の原本を保管し、台帳に申請番号つきで1行残す |
| 確認 | その人は誰で、使わせてよいと誰が確かめたか | 部門情報管理者の許可を確かめ、委託先は審査部署が審査する |
| 付与 | 申請どおりの権限を、いつ誰が付けたか | 台帳に記録してから操作し、操作日と操作者を残す |
| 記録と追跡 | 今誰がどの権限でいて、記録と一致しているか | ユーザー一覧のCSVと台帳を突き合わせる |
| 状態の監視 | 不要になった人に、何で気づくか | 弊社のアドレスは請求明細で毎月、それ以外は半年に1回の棚卸しで |
| 削除・制限 | 不要な権限を、いつ何をきっかけに外したか | 棚卸しの結果をきっかけに外し、台帳に記録する |
| 見直し | 全員の権限が今も必要だと、いつ誰が確かめたか | 半年に1回、PJの管理部門に継続か削除かを確かめてもらう |
Backlogでの具体的な運用は、「Backlogユーザー管理 運用ガイド」を参照してください。
6新しい依頼や業務に向き合うときの5つの確認
初めての依頼や、決まりがよく分からない業務に当たったら、手を動かす前に次の5つを確かめます。
- これは、どの型の依頼か。4章の表で、インシデント・要求・変更・アクセス・資産のどれかを見分けます。
- 定義はあるか。あるなら、正本はどこか。メールや担当者の記憶を、正本の代わりにしません。
- 定義どおりに処理したと、記録で説明できるか。説明できない処理は、どこかの手順が抜けています。
- 定義にないなら、その場で判断せず、定義を決める人に上げたか。その場の判断は、次の人への前例になります。
- 同じ例外が、繰り返し出ていないか。繰り返す例外は、定義を見直す合図です。
用語集
- ITIL
- ITサービスを安定して届けるためのやり方を、多くの組織の経験からまとめた枠組み。
- プラクティス
- ITIL 4での実践の型。インシデント管理、サービス要求管理など34ある。
- インシデント
- サービスが止まった、使えないといった、予定外の中断や品質の低下。
- サービス要求
- アカウントの追加や機器の貸与など、あらかじめ決めた手順で応える依頼。
- 変更
- 設定や仕組みを変えること。標準・通常・緊急に分けて扱う。
- サービスレベル
- 何日で、どの時間帯に対応するかといった、提供側の約束。
- SSOT
- 正しい情報の置き場所を1つに決める考え方。ITILの用語ではない。
- 定義駆動
- 先に定義を決め、依頼を定義と照らして処理する進め方。本資料での呼び名。
- アクセス管理
- 認められた人にだけ必要な権限を渡し、不要になったら外す活動。
- 職務分離
- 必要性を判断する人と、権限を渡す人を分けること。