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?

読書感想文『運用設計の教科書』運用引き継ぎ・業務運用編(p129〜p140)

2
Posted at

書籍情報

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

著者について

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

著者の他の著作

著者リンク


学習メモ

運用引き継ぎ・業務運用編では、プロジェクト完了後のサービス開始に向けた最終フェーズとして、システム説明会の開催・運用支援活動の報告・業務運用の設計進め方・作成ドキュメントの整備が解説されている。


学んだこと

1. 運用引き継ぎで運用設計がやること(p129)

運用引き継ぎでは、

運用担当者がスムーズに運用できるように、システムの構成や特性・運用ドキュメントの説明に実技訓練などを行います(p.129より)

書籍では運用テストの後に位置づけられているが、実際のプロジェクトではポイントごとに徐々に引き継ぎを行っていくことが多い。


2. システム説明会・新規導入製品勉強会の開催(p130〜p131)

システム説明会は、

運用に関わるすべての人を対象に、導入するシステムの特徴・構成を説明する場となります。(p.130より)

で、システムの導入方法・利用方法・機能などの前提知識をインプットしてもらう。一方、新規導入製品の勉強会は、運用担当者が今まで利用したことのないミドルウェアを導入する場合に必要に応じて実施するもので、不要と判断された場合は実施しない。


3. 運用支援実績を発注者へ報告する(p133)

運用支援は能動的に何かを作成するわけではないため、

定期的に運用支援で何が行ったかを報告しておく必要があります。(p.133より)

必要がある。これは活動報告であると同時に、発注者と運用支援の方向性をすり合わせる意味もある。報告しないと「何もやっていない」と評価されてしまう場合があるため、発注者から求められなくても実施する方がよい。


4. 運用引き継ぎのまとめ(p134)

運用引き継ぎは、

作成したドキュメントに従って安定運用できるまでをサポートする位置づけです。(p.134より)

位置づけだ。それまでのフェーズと違い、説明による運用準備フォローに重点を移している。運用引き継ぎが終われば、プロジェクトとしての運用設計は完了となる。ただしシステムの運用はその後もサービスが終わるまで続く。


5. 業務運用の設計範囲(p136)

業務運用は発注者・利用者・アプリケーション担当と協力しながら設計する。

利用者とシステム側のやりとりが円滑に行われるようになること(p.136より)

が目的で、設計範囲はサービスを提供するアプリケーションと利用者だ。


6. 業務運用の設計の進め方(p137)

業務運用の設計は、BPMNフロー図を作成→アプリケーション担当とレビュー→発注者とディスカッションして方針決定→最終合意という4ステップで進む。

実際の流れを見ながらディスカッションすることで、より具体的な業務内容を聞けるようになります(p.139より)

のがこの進め方の利点だ。作成するドキュメントは、運用フロー図・ユーザー利用作業書・FAQ・適用手順書・申請書・台帳などで、申請やシステム依頼の有無に応じて必要なものを選択する。


感想

「あれば便利」ではなく「あった方が良い」項目が多い章だった。実際、こういった取り組みが徹底されているプロジェクトは少なく、あるだけでありがたいと感じる水準のものが揃っている。そもそもこの本を読むまで、これらを意識すらしていなかった。定期的に成果を報告する重要性についても、「何もやっていない」と見なされるリスクがあるという視点は、自分の活動をどう可視化するかという問題にも直結する。

特に印象的だったのはシステム説明会の部分。これはセールスエンジニアや営業にも直結する領域で、説明会の質次第で顧客の第一印象が大きく変わる。単なる引き継ぎ作業と軽視せず、顧客体験の一部として設計する視点が重要だと思った。個人開発の機能リリース時も、ユーザーに対してどう説明するかを事前に考えることで、初期体験の質を高められると感じた。

FAQも効果が高い。開発エンジニア向けと顧客向けで作り分けることで、問い合わせ対応コストを下げながら、それぞれの理解促進にもつながる。FAQは一度作ってしまえば継続的に価値を生むドキュメントで、作成コストに対するリターンが高い。まずは1機能分だけでも試してみる価値がある。


実践できること

  • 個人開発の1機能をリリースする際に、一度だけシステム説明動画とFAQページを作成してみる(毎回やるのではなく、まず体験することが目的)
  • BPMNフロー図を1つ書いて、利用者とシステム間のやりとりを可視化してみる
  • 運用引き継ぎの説明会をイメージして、自分のプロジェクトの「初期説明資料」を1枚作成する
  • 運用支援の活動報告として、月次で何が起こったかを箇条書きでまとめる習慣をつける

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