昨日、こんな記事を読みました。

これは、エンジニアの仕事を大きく3種類に分け（↓）、「エンジニア」と「依頼する側」とが、認識が徐々にずれていくことによって、保守系のタスクの優先度が下がり、あるとき大きな不具合が起き、みんな不幸せになってしまうという、分かりやすくて辛い例え話です。

・事業系 issue：事業運営上のissue（売上利益に直結する施策や機能）
・保守系 issue：リファクタリング等、コードの保守性を高める為のissue
・改善系 issue：開発や通常業務を改善する為のissue

これを読みながら、これって、別にエンジニアの仕事に限ったことではなく、全職種においても言えることなのでは？と思いました。

というのも、仕事における運用保守って、「今って目標から逆算してどの状況にいるんだろうか？」と振り返って整理することです。

すぐすぐに効果が出るわけでもないので優先順位は下がってしまいがちなタスクですが、これを定期的にやっているのとやっていないのとでは、結構変わってくるのではないか、と気づきました。

もし寄り道をしていたとしても、毎週末に振り返る時間をつくっていれば、元の道に戻ってこれるけど、全然振り返る時間をつくっていなかったら、元の道に戻るのに1ヶ月かかってしまう、だから、近道はないかと探すもうまくいかずに変な道に迷い込んでしまう ──。これは例え話ですが、有り得なくない話。気を引き締めねば。

・・・

最近バタバタだったので、ここら辺で来週〜今月までのタスクを振り返る「運用保守」の時間をつくっていきたいと思います。