運用でカバーとは何か？
運用でカバーの意味がメンバーによって違ったみたいなので、私なりの定義をまとめてみました。
運用でカバーとは何か？
SNSのエンジニア界隈で少し流行っている言葉。
実装しなければ機能を実装せずに、運用（マニュアルなど）にて対応するという悪い意味で使われることが多い
主にカバの写真とともに共有される場合が多い
実装できない理由
機能実装ができない理由は色々あるが、個人的には下記の2パターンだと考えられる。
1.工数/期間などが足りず実装を諦める場合
最も多いと思われるがプロジェクト上の優先度が低く、後回しにされた機能でマニュアルでも代用が効くものがこれに当たる。
本来であれば実装を計画していた機能であるため、運用でカバーする範囲が想定よりでかくなりがちで、他部署や開発部門の足を引っ張りがち。
2.利用頻度が測れず、リリース後の利用頻度で実装を検討したい場合
例えば1000件販売するとして1件程度しか利用しないであろう機能がこれに当たる。そもそも、主たる機能ではなく、実装しなくても販売に影響はないであろうという判断がされている機能である。
お客様のニーズによって実装したいと思っているが、大体の場合はその願いは叶わない場合が多い。
実際にどうするの？
実際にはサポートなどで対応する事になるが、場合によってはお客様への対応を依頼する場合もある。
下記は私がざっくり考えた運用でカバーの例である。
例：監視作業
監視作業が自動化できていない場合、手作業でサーバ監視を行う場合もあります。定期的にどこかの数値や日時を確認して、サーバ自体が正しく動作していることを確認する形です。
24時間365日確認することが難しく、色々なリスクを含んでしまいますが急ぎの場合はこの方法で仕方なく運用されることもあります。
例：グラフ機能
グラフ機能を運用でカバーする場合は、CSVでダウンロードさせてお客様側のEXCELにてグラフ表示してもらうやり方があると思われる。
親切に行わせるのであればCSVと共に、グラフ表示できるEXCELをダウンロードできるようにすれば優しいと思います。
しかし、そもそもそれを実装する時間すらない場合が多い。
例：登録作業
バックエンド側で既存の顧客管理システムと自動連携ができていない場合は、登録フロー上に顧客を別のシステムへコピーするような作業を明記してマニュアルで行ってもらう形である。
この場合、ミスが発生する場合もあるだろうから何らかのチェック方法があったほうがいいし、このような作業は誰もしたくないものと思われるが…
意外にこの形の運用は多いように思われる。
最後に
なんにしろマニュアルの作業は誰もやりたくないし、できて当たり前で失敗すると怒られる類のものである。
出来る限り運用でカバーは避けたいものだが、開発も0円ではないためどうしても避けられない場合がある。
避けられない場合も、ミスや問題が起きないような設計が重要である。