2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

読書感想文『運用設計の教科書』運用テスト編(p106〜p127)

2
Last updated at Posted at 2026-07-05

書籍情報

書籍名: 運用設計の教科書【改訂新版】 〜現場でもっと困らないITサービスマネジメントの実践ノウハウ〜
著者: 近藤 誠司

著者について

株式会社K-model代表。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。運用設計・運用改善コンサルティングを専門とする。趣味は小説を書くことで、第47回埼玉文学賞にて正賞を受賞。

著者の他の著作

著者リンク



学んだこと

1. 運用テストで運用設計がやること(p106)

詳細設計フェーズまでに決めたルールと作成したドキュメントが問題なく使えるかを検証するのが運用テストだ。運用設計担当の主な役割は、運用テスト計画書と仕様書の作成・発注者との合意、テストのファシリテーション、課題・結果のとりまとめ、ドキュメントの最終修正の5点だ。重要なのは、

ドキュメントを作成した運用設計担当が自らテストを実施しても客観性が低く効果が薄い(p.106より)

という点で、実際のテストは運用担当者が行う。


2. プロジェクト全体から見た運用テストの立ち位置(p107〜p108)

運用テストを理解するには、アプリケーション担当・基盤構築担当がどのようなテストを実施しているかを理解する必要がある。単体テストはパラメーターや設計書をもとに正しく設定されているかを確認するもので、結合テストはサーバー間連携などシステム間の連携を検証するものだ。

システムテストとは、提供するサービスに問題ないかを検証するテストの総仕上げ(p.108より)

総合テスト・業務テストとも呼ばれる。運用テストはこのシステムテストの後に位置づけられる。


3. 運用テスト計画書を作成する(p111)

運用テスト計画書には、テストの目的・実施前提・範囲・種別・実施方法・スケジュール・実施体制・合否の判定基準を記載する。テスト範囲は運用項目一覧すべてが対象で、

全体統括は発注者、全体ファシリテーターは運用設計担当、実施者は運用担当者(p.111より)

という役割分担が基本だ。テスト種別は、関係者間の情報連携を確認する運用フローテストと、実際の手順書を実施する運用手順書テストの2種類があり、実施方法は実機テストと机上テストを使い分ける。


4. 運用テストで考える網羅性(p113)

運用テストの範囲が漏れなく検討されているかを説明できなければならない(p.113より)

という網羅性(カバレッジ)の観点は、テスト計画書で必ず問われる。運用設計担当はカバレッジを客観的に示せる状態で計画書に臨む必要がある。


5. 運用テスト仕様書の書き方(p115)

テスト仕様書とは、テストを実施する項目と想定結果を記載したもの(p.115より)

で、想定結果通りであれば合格、そうでなければ何かしらの対策が必要になる。運用フローテスト仕様書では申請書フォーマットの確認や台帳更新を含む関係者間の情報連携をテストし、運用手順書テスト仕様書では実際の環境で手順書を実施して想定通りの結果が得られるかを確認する。


6. 運用テストの実施(p122)

テスト仕様書が完成したら、運用開始後の登場人物にテストを実施してもらう。運用設計担当は、

ファシリテーター(調整役・促進役)として振る舞う(p.122より)

立場だ。テスト実施前には計画書・フローテスト仕様書・手順書テスト仕様書を使った全体説明会を開催し、テスト中は進捗管理を行い、テストで出てきた課題の内容確認と対応方針を発注者と合意していく。


7. 運用テストの課題・結果のとりまとめ(p125)

テスト完了後に結果をとりまとめる。「合格」ではないテスト項目には何かしらの課題が残っている。

運用フローテストと運用手順書テスト、どちらの課題も同じファイル(1つの一覧)へマージして管理する(p.125より)

とよい。すべての課題に優先度と重要度を設定し、対応方針と担当者を明確にする。


8. ドキュメントの最終修正(p127)

運用テストが終わり改善点が課題として洗い出されたら、

サービス開始までの間に優先度の高い課題を対応しながら関連ドキュメントを修正していく(p.127より)

課題対応と並行してドキュメントを最新化することで、運用開始時点でのドキュメント整合性を保つことができる。


感想

運用テストでここまでやることがあるとは思っていなかった。計画書・仕様書の作成からファシリテーション・課題とりまとめ・ドキュメント最終修正まで、体系的なプロセスが整理されている点に驚いた。

きちんと実施できれば、エンドユーザーの満足度向上にも直結する内容だと感じた。だからこそ、今後は自分でも実践できるようになることが大事だと思う。

一方で、この工程は「実際の業務を具体的にイメージできる人」でないとこなせない。テスト設計や課題の優先度判断には現場の経験と想像力が求められる。技術力だけでなく、業務理解の深さが問われるフェーズだと感じた。


実践できること

  • 個人開発で自分がユーザー役になり、運用手順書を1つ実際に動かしてみる
  • 気になった点をメモして、簡単な課題一覧を作ってみる
  • 将来チームで実施できるよう、運用テストのチェックリストを作っておく
  • 優れたSaaSプロダクトがどのような運用テストを行っているか調べて参考にする

定量評価(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
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?