書籍情報
書籍名: 運用設計の教科書【改訂新版】 〜現場でもっと困らないITサービスマネジメントの実践ノウハウ〜
著者: 近藤 誠司
著者について
株式会社K-model代表。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。運用設計・運用改善コンサルティングを専門とする。趣味は小説を書くことで、第47回埼玉文学賞にて正賞を受賞。
著者の他の著作
著者リンク
学習メモ
（本書学習メモより：サポートデスクの問い合わせ受付から解決・クローズまでの対応フロー全体図と、ヒアリングシートによる事象把握・エスカレーション設計の概要ページ。問い合わせ窓口の一本化と各役割の担当範囲の明確化が図示されていた。）
学んだこと
1. サポートデスクとは（p158）
サポートデスクとは、利用者のサービスに関する問い合わせ対応を行う組織のこと。ヘルプデスク・サービスデスク・カスタマーサポート・窓口サポートなど呼び名はさまざまあるが、その本質は変わらない。
利用者からの問い合わせに返答するという役割は同じ。（p.158より）
2. サポートデスクのあり方（p159）
社内サポートデスクが業務アプリケーションごとに分かれているのは、望ましい状態ではない。窓口が乱立すると、利用者情報が分散したり、情報システム室が全体のルールを把握しにくくなる。
サポートデスクが乱立すると、社内ITシステム利用者に関する情報が拡散してしまう。（p.159より）
3. 問い合わせ対応の運用フロー図（p164）
サポートデスクの最大の役割は利用者からの問い合わせ情報の集約である。（p.164より）
問い合わせを取りまとめ、決められたルールで仕分けをする。一次対応できるものはサポートデスク内で完結させ、対応が難しいものは運用担当者へエスカレーションする。この一連の流れを図として明示することで、担当者ごとの役割分担が明確になる。
4. 問い合わせ対応の基本動作（p166）
担当者ごとに作業粒度が違っていては正しい処理ができないため、基本動作を標準化しておくことが重要。（p.166より）
問い合わせ対応は「ヒアリングと記録」「一次対応」「エスカレーション」の3ステップで構成される。まず病院の問診表のようなヒアリングシートで事象を標準的な粒度で把握し、ナレッジ・FAQで解決できれば一次対応として完結させる。解決できない場合は事象切り分けを行い、しかるべき担当者へ引き継ぐ。
5. システム停止・縮退時のお知らせ（p170）
システムが使えなくなると、まずサポートデスクへ問い合わせが集中する。そのため、停止や縮退が事前にわかっている場合は早めに周知することが欠かせない。
システムが使えなくなったり接続が不安定になる時間が事前にわかっている場合は周知しなければならない。（p.170より）
周知の手段としては、ポータルへの掲載・端末引き渡し時の印刷・デスクトップへのデフォルト配置などが効果的で、手順書の届け方まで設計に含めることが重要となる。
6. サポートデスク運用のまとめ（p173）
サポートデスク設計の要点として、問い合わせ対応フローの標準化・ポータルによる情報集約・問い合わせ内容の可視化と定期報告の3点が挙げられる。
サポートデスクの問い合わせ内容を可視化して、定期報告する仕組みを設計する。（p.173より）
ポータルには「お知らせ・社内PC利用手順・申請方法・FAQ」を掲載し、利用者が自己解決できる割合を高めることが運用負荷の軽減につながる。
7. 基盤運用の設計範囲（p198）
基盤運用はアプリケーションが動作するシステム基盤（インフラ）に関する運用である。（p.198より）
目的はアプリケーションによる業務適用が継続されることで、設計範囲はシステム基盤とアプリケーションの一部となる。
8. 基盤運用の設計の進め方（p199）
基盤運用の設計は「情報整理 → プロジェクト内レビュー → 発注者・運用担当者レビュー → 最終合意」の4ステップで進める。業務運用と異なり、運用項目の変動が少ない分、インプット情報のほとんどをプロジェクト内から収集することになる。
アウトプット情報を作るためのインプット情報のほとんどをプロジェクト内から連携してもらうことになる。（p.199より）
基盤構築担当だけでなくアプリケーション担当にもレビューを依頼すると精度が上がる。運用担当者には「負担のかかる実装がないか・既存運用と比べて不足がないか」の観点で確認してもらうことが重要となる。
感想
サポートデスクは兼務でこなしているケースが多く、体系的に設計されることが少ない印象がある。問い合わせ窓口の存在は認識されていても、その後の対応フロー（エスカレーション・切り分けルール）が明文化されているプロジェクトはほとんど見たことがない。担当者ごとに判断基準が違っていたり、問い合わせが口頭のみで記録されなかったりするケースも多く、対応品質が属人化している現場はよく目にしてきた。
この章で紹介されているような問い合わせ対応フロー図は、社内だけでなく顧客にも共有できれば「どこに問い合わせればいいか」が明確になり、双方の負担を減らせると思った。特に、リリース直後やシステム変更後の混乱期には、事前に周知できる仕組みがあるだけで現場の状況がまったく変わってくると感じた。周知のタイミングや手段（ポータル掲載・印刷配布・デスクトップ配置）まで設計するというのは、実際に運用する側の視点に立った現実的なアドバイスだと思う。
窓口の存在だけ決まっていて、問い合わせ発生から解決までのフローが決まっていないケースが多い。担当者が変わったとき・複数人で対応するときに「誰が持ってる？」が発生するのはこれが原因だと思う。問い合わせを受けた後のフローまで明文化することが、真の意味でのサポートデスク設計だと感じた。ヒアリングシートを使って情報を標準化するという発想も、医療の問診表のアナロジーで説明されており非常にイメージしやすかった。
また、この章の内容はITに限らず汎用的に使えると感じた。「受付 → 切り分け → エスカレーション → クローズ」という構造は、飲食のクレーム対応や医療のトリアージ、小売の返品フローと本質的に同じ。「窓口だけあってフローがない」問題もIT以外でよく起きている。運用設計はITを題材にしているが、実態は組織の仕組みの作り方を教えている本だと思った。業種を問わず、窓口業務を持つ組織であれば参考にできる考え方が詰まっている一章だった。
実践できること
- 問い合わせ受付から解決・クローズまでの対応フロー図を1枚書いてみる
- 中小企業・小規模プロジェクトを想定し、営業も含めた一気通貫の問い合わせ対応フロー図を作成する
- 問い合わせ受付時に使えるヒアリングシートを自作し、事象を標準的な粒度で把握できる設計にする
- 「よくある問い合わせ」をFAQ形式でまとめ、サポートデスク担当者が一次対応できる割合を高める仕組みを検討する
- サポートデスクの問い合わせ内容を台帳で記録し、月次で傾向を集計・可視化できる仕組みを設計する
定量評価（1年後に記入）
注意: このセクションは読書直後ではなく、1年後など実際の効果が見えてから記入してください。
記入日: YYYY-MM-DD
スキル・知識の評価
| 評価項目 | 評価 | コメント |
|---|---|---|
| 長期的な有用性 | ⭐⭐⭐⭐☆ (4/5) | |
| 実践のしやすさ | ⭐⭐⭐☆☆ (3/5) | |
| 汎用性 | ⭐⭐⭐⭐☆ (4/5) |
スキルスコア: /15点
経済的インパクト
投資コスト
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 書籍価格 | ¥X,XXX | |
| 読書時間 | XX時間 | |
| 読書時間コスト | ¥XX,XXX | |
| 総投資額 | ¥XX,XXX |
リターン
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 時間削減効果 | XX時間/月 | |
| 時間削減の金額換算 | ¥XXX,000/月 | |
| コスト削減効果 | ¥XXX,000/年 | |
| 年間経済効果 | ¥XXX,XXX |