運用あるあるチェックシート¶
- 4段階評価
項目候補 (重複あり)¶
事象 | 高負荷 | 属人的 | 費用対効果 |
---|---|---|---|
業務が多岐に渡り、全てを把握することが困難になっている。 | ++ | ||
業務の設計思想が失われていて、変えられない作業がある。 | +++ | ||
ドキュメントが整備されていない。あっても更新されていない。 | +++ | ||
どんなドキュメントが必要なのかがわからない。書き方がわからない。 | +++ | ||
ドキュメントがなくても大丈夫だとおもっている。 | +++ | ||
ドキュメントがどこにあるのかわからなくなることが多い。 | +++ | ||
一部の人間にしかできない業務があり、業務が集中している。 | +++ | +++ | |
スキルやノウハウの継承ができていない。 | +++ | ||
求められるスキルがわからない。 | +++ | ||
異動により現場が混乱することが多い。 | +++ | ||
人が育たない。優秀な人が入ってこない、定着しない。 | +++ | ||
がんばっても評価されない。 | +++ | ||
業務や現場自体が評価されている実感がない。 | +++ | ||
運用作業やトラブルが多く、前向きな改善に着手する余裕がない。 | +++ | +++ | +++ |
ツールが使いにくいが、改修にはコストと期間が必要なため、我慢して「運用でカバー」して使っている。 | +++ | +++ | +++ |
「コストセンター」と言われ、コストカット要求への対応に苦慮している。 | +++ | ||
新規のツールを設計したいが、どんな要求があるのか現場でもわかっていない。 | +++ | ||
サービス設計導入時の検討漏れや実装が間にあわない部分を「運用でカバーする」など設計側のその場しのぎの影響を直接受ける。 | +++ | +++ | |
開発側都合の「運用でカバー」について開発側に上手くフィードバックできずに放置されている。 | +++ | +++ | |
開発から受け入れた手順書について、意図がわからない部分があるため手順書通りの対応しかできない。 | +++ | ||
個別に対応しすぎて、全てが特別対応に等しくなっている。 | +++ | +++ | +++ |
依頼されてから動き出すまでのリードタイムが長い。 | +++ | ||
声の大きいユーザが強く、必要以上のサポートを強いられる。 | +++ | +++ | |
コスト削減要求が強いが、どう効率化すべきなのかが見えない。 | +++ | ||
運用メンバーに、もやっとおねがいすることがたまにあり、おねがいしっぱなしになっているものがある。 | +++ | +++ | |
依頼元から、もやっとおねがいされることが多い。長らくおねがいされっぱなしのものがある。 | +++ | +++ | |
手動で工数を取られている作業があり非効率だ。 | +++ | +++ | |
他人に引き継ぐ自信のない定常業務がある。 | +++ | ||
突発業務が多い。 | +++ | ||
非定型業務が多い。(内容 or 依頼形式) | +++ | +++ | |
間接業務(ミーティング/定期的な報告やレポート)が多い。 | +++ | +++ | |
再発型のトラブルが多い。(教訓が生かせない) | +++ | +++ | +++ |
チケットを使っておらず、メールベースの依頼が中心のため過去の経緯やノウハウはメールボックスの中にある。 | +++ | ||
運用設計書がない。 | +++ | ||
運用設計って何? | +++ | +++ | |
急ぎではない割り込みが多い。 | +++ | ||
オペミスが多い。 | +++ | +++ | +++ |
バグ対応が多い。 | +++ | +++ | |
アラートが多すぎる。狼少年アラートが多い。 | +++ | +++ | |
計画的ではない徹夜が多い。 | +++ | ||
残業が多い。 | +++ | ||
体力的にきつい。 | +++ | ||
精神的なプレッシャーがきつい。(上司、顧客、他部署) | +++ | ||
「運用はゼロ」が理想とか言われちゃっている。 | +++ | ||
顧客に「お客様が神様」と言われ、事実上隷属させられている。 | +++ | ||
開発側が運用の現状を理解しておらず、苦労している。 | +++ | ||
現状をどう改善すればいいのか見えていない。 | +++ | ||
どの業務で困っているか漠然としている。優先順位が決まっていない。 | +++ | ||
どの程度、属人作業があるかわからない。 | +++ | ||
どの作業がブラックボックス化しているか可視化されていない。 | +++ | ||
作業工程について歴史的経緯などのWhyが不明のものがある。 | +++ | ||
人手作業を要するなど、非効率な部分がある。エンジニアリングの活用が不十分である。 | +++ | +++ | |
定量的評価に必要な測定データが無い。工数、件数を把握できていない。 |
全般的
- プレッシャーが厳しく、精神的につらい
- 定型化されていない業務が多い。
- 個別対応が多く、標準対応といえるものの方が少ない。
- 非定型な内容の依頼が多い。
- がんばっても評価されている気がしない。
- 新しく入った人が定着せずにやめてしまう。
コスト系
- 「運用はゼロが理想」と言われている。
- 「コストセンター」と言われており、コストカット要求に苦しんでいる。
- 定量的評価に必要なデータが無い。
- 工数、件数を適切に把握できていない。
- 定性的評価に必要な評価基準がない。
- 定量的評価に必要な評価基準がない。
高負荷系、非効率
- 体力的にきつい。(20-30代前半)
- 体力的にきつい。(30代後半-)
- 残業が多い
突発、短納期
- 計画的(1週間前に確定)ではない徹夜が多い。
- 期末の短納期依頼が多い。
- 突発業務(非定型&1週間未満)が多い。
アラート、トラブル系
- アラート通知が多すぎる
- 狼少年通知アラートが多い。
- トラブルが多い。
- トラブル対応以外の作業負荷が高い。
- 場当たり的な自動化/ツール化で、あまり工数が下がらない。
- つなぎ目で工数がかかっている。
- 手動で工数が取られている、非効率
- エンジニアリングが不十分
- 人力での判断が必要なポイントがある。
- 同じようなトラブルが再発している。
- 割り込み業務が多い。 集中力低下による品質低下
- 優先順位付けが明示されていない(全体的にあいまい)
- 対外窓口が一元化されていないものがある。(直接問い合わせがくる)
- 非定型の形式(メール/メッセンジャー)による相談や依頼が多い。
- 兼務が多く、各タスクの進みが遅い
- 間接業務(ミーティング/定期レポート)が多い。
運用でカバー系
- 開発側事情(納期/工数/検討不足)による運用でカバーが頻発している。
- 開発側事情による運用でカバーに対してフィードバックする流れがなく、改善されない。
- 声の大きい人への対応の優先順位が高くなっている。
- 声の大きい人に必要以上のサポート工数がかかっている。
- お客様の神様化により隷属している。
属人系
- 異動や退職で混乱することが多い。
- 前任者からの引継ぎは基本的に期待できない。
- 設計について聞ける人がいない作業がある。
- 手順書と違う挙動について聞ける人がいない作業がある。
- 属人が属人を呼ぶ状況になっている。良くって一子相伝状態。
- 他人に引き継げない作業がある。(改善、設計系を除く)
- 求められるスキルが明示されていない。
- やっていることの背景(why)が不明の作業がある。
- 設計の背景(why)が不明の作業がある。
- 判断(権限/理解)できる人が限られている。
- 緊急時に、判断できる人がおらずにボトルネックになっている。
- 承認にかかる時間が長い。
- キーマンがボトルネックになりリードタイムが長い。
- 障害時に必要な肝心な情報は復旧した後に出てくる。
- 全体を把握している人がいない
- 業務が多岐にわたり、現状を把握できない。
- 情報が失われている、そもそも無い
- やったことの履歴が残っていないので、後から追えない。
- 過去の依頼や経緯、ノウハウはメールボックス、メッセンジャーログの中
- 手順、値を決めた経緯、検証結果、評価結果が失われている。
- 作業による影響範囲を見誤る
スキル系
- オペミスが多い。
- 特定の人に業務が集中している。
- 特定の人にしかわからない業務がある。
- ハイスキルな人が単純作業をやっている。
- 用語がローカルすぎて新人には作業ができない。
- 人が育たない。
- 人の入れ替わりが激しい。
- スキルが継承されない。
- ノウハウが蓄積/継承されない。
ドキュメント系
- 全般的に存在しない。どこにあるかわからない。個々人で持っている。
- 手順が更新されない。
- 構成情報が更新されない。
- 設計情報が存在しない。
- ドキュメントをどう書けばいいかわからない。
- ドキュメントの内容が属人的で他人にはわからない。
- ドキュメントのバージョンが輻輳している。どれが一番正確なのかわからない。
- ドキュメントの記述に統一感がなく、よみづらい、保守工数がかかる。
- 手順書の字面だけを追ってOKだったが、サービス的にはNGだったことがある。
- クロスチェックが、シートをチェックすることが目的になってしまい、実質的なチェックになっていない。
- 作業者はシンプルなドキュメントを求めるが、作成者は厳密さを求める。
- ツール系- ツールが使いにくいが我慢して使っている。
- ツールを作りたいが要求があいまいなためとまっている。
- ツールを作ったが、工数品質効果がでていない。
- ツールのカオスな設計と実装で、バグ対応も多い。
- トラブルの復旧作業に必要なツールが動かなかったことがある。
- マクロによる自動化を会社に禁止されている。
その他部署系
- システムが変わっても、開発から運用への連絡がない。
- もやっと渡されてそのままのものがある
- 部署をまたぐと改善が進まない。
- 部署間でお互いに部分最適化が進み対立している。
- 各部署が作業オーナが自分だとは思っていない。
- レイヤーが違うと文化が違う。
- サービスのカオスな設計と実装、バグ対応が多い。
その他改善系
- 部分的な改善で全体のスループットを求められる。
- 例外処理(原因不明なトラブルなどの対応)があらかじめ決まっていない。
- 業務範囲と期待があいまい。
- 前向きな改善をする余裕がない。
- どう改善すればいいかわからない。
- どこに困っているか漠然としている。
- 優先順位が決まっていない。
- 想定しない運用があとからでてくる。運用設計不足。
- 運用設計が無い、古い、見たこと無い。
事象 | 悪い影響 | 望ましい状況 | Remarks |
---|---|---|---|
業務が多岐に渡り、全てを把握することが困難になっている。 | xxがおきる。 | 業務が俯瞰しやすく、把握しやすい状態になっている。 | (sample) |
回答内容による類型化¶
はたして可能か?