項目候補 (重複あり)¶

全般的

• プレッシャーが厳しく、精神的につらい
• 定型化されていない業務が多い。
• 個別対応が多く、標準対応といえるものの方が少ない。
• 非定型な内容の依頼が多い。
• がんばっても評価されている気がしない。
• 新しく入った人が定着せずにやめてしまう。

コスト系

• 「運用はゼロが理想」と言われている。
• 「コストセンター」と言われており、コストカット要求に苦しんでいる。
• 定量的評価に必要なデータが無い。
• 工数、件数を適切に把握できていない。
• 定性的評価に必要な評価基準がない。
• 定量的評価に必要な評価基準がない。

高負荷系、非効率

• 体力的にきつい。(20-30代前半)
• 体力的にきつい。(30代後半-)
• 残業が多い

突発、短納期

• 計画的(1週間前に確定)ではない徹夜が多い。
• 期末の短納期依頼が多い。
• 突発業務(非定型&1週間未満)が多い。

アラート、トラブル系

• アラート通知が多すぎる
• 狼少年通知アラートが多い。
• トラブルが多い。
• トラブル対応以外の作業負荷が高い。
• 場当たり的な自動化/ツール化で、あまり工数が下がらない。
• つなぎ目で工数がかかっている。
• 手動で工数が取られている、非効率
• エンジニアリングが不十分
• 人力での判断が必要なポイントがある。
• 同じようなトラブルが再発している。
• 割り込み業務が多い。 集中力低下による品質低下
• 優先順位付けが明示されていない(全体的にあいまい)
• 対外窓口が一元化されていないものがある。(直接問い合わせがくる)
• 非定型の形式(メール/メッセンジャー)による相談や依頼が多い。
• 兼務が多く、各タスクの進みが遅い
• 間接業務(ミーティング/定期レポート)が多い。

運用でカバー系

• 開発側事情(納期/工数/検討不足)による運用でカバーが頻発している。
• 開発側事情による運用でカバーに対してフィードバックする流れがなく、改善されない。
• 声の大きい人への対応の優先順位が高くなっている。
• 声の大きい人に必要以上のサポート工数がかかっている。
• お客様の神様化により隷属している。

属人系

• 異動や退職で混乱することが多い。
• 前任者からの引継ぎは基本的に期待できない。
• 設計について聞ける人がいない作業がある。
• 手順書と違う挙動について聞ける人がいない作業がある。
• 属人が属人を呼ぶ状況になっている。良くって一子相伝状態。
• 他人に引き継げない作業がある。(改善、設計系を除く)
• 求められるスキルが明示されていない。
• やっていることの背景(why)が不明の作業がある。
• 設計の背景(why)が不明の作業がある。
• 判断(権限/理解)できる人が限られている。
• 緊急時に、判断できる人がおらずにボトルネックになっている。
• 承認にかかる時間が長い。
• キーマンがボトルネックになりリードタイムが長い。
• 障害時に必要な肝心な情報は復旧した後に出てくる。
• 全体を把握している人がいない
• 業務が多岐にわたり、現状を把握できない。
• 情報が失われている、そもそも無い
• やったことの履歴が残っていないので、後から追えない。
• 過去の依頼や経緯、ノウハウはメールボックス、メッセンジャーログの中
• 手順、値を決めた経緯、検証結果、評価結果が失われている。
• 作業による影響範囲を見誤る

スキル系

• オペミスが多い。
• 特定の人に業務が集中している。
• 特定の人にしかわからない業務がある。
• ハイスキルな人が単純作業をやっている。
• 用語がローカルすぎて新人には作業ができない。
• 人が育たない。
• 人の入れ替わりが激しい。
• スキルが継承されない。
• ノウハウが蓄積/継承されない。

ドキュメント系

• 全般的に存在しない。どこにあるかわからない。個々人で持っている。
• 手順が更新されない。
• 構成情報が更新されない。
• 設計情報が存在しない。
• ドキュメントをどう書けばいいかわからない。
• ドキュメントの内容が属人的で他人にはわからない。
• ドキュメントのバージョンが輻輳している。どれが一番正確なのかわからない。
• ドキュメントの記述に統一感がなく、よみづらい、保守工数がかかる。
• 手順書の字面だけを追ってOKだったが、サービス的にはNGだったことがある。
• クロスチェックが、シートをチェックすることが目的になってしまい、実質的なチェックになっていない。
• 作業者はシンプルなドキュメントを求めるが、作成者は厳密さを求める。
• ツール系- ツールが使いにくいが我慢して使っている。
• ツールを作りたいが要求があいまいなためとまっている。
• ツールを作ったが、工数品質効果がでていない。
• ツールのカオスな設計と実装で、バグ対応も多い。
• トラブルの復旧作業に必要なツールが動かなかったことがある。
• マクロによる自動化を会社に禁止されている。

その他部署系

• システムが変わっても、開発から運用への連絡がない。
• もやっと渡されてそのままのものがある
• 部署をまたぐと改善が進まない。
• 部署間でお互いに部分最適化が進み対立している。
• 各部署が作業オーナが自分だとは思っていない。
• レイヤーが違うと文化が違う。
• サービスのカオスな設計と実装、バグ対応が多い。

その他改善系

• 部分的な改善で全体のスループットを求められる。
• 例外処理(原因不明なトラブルなどの対応)があらかじめ決まっていない。
• 業務範囲と期待があいまい。
• 前向きな改善をする余裕がない。
• どう改善すればいいかわからない。
• どこに困っているか漠然としている。
• 優先順位が決まっていない。
• 想定しない運用があとからでてくる。運用設計不足。
• 運用設計が無い、古い、見たこと無い。

回答内容による類型化¶

はたして可能か?