サービス運用をしていくうえで、ログはとても重要です。 どういった操作がされているのか、どういったことが起こっているのか。運用しているサービスを調べる方法として、「実際のデータを確認すること」と「ログを確認すること」しかできません。 「データを確認する」ことは、問題があった時に原因が分からず、どうにかして確認するための最終手段となります（個人情報を含むようなサービスであれば、そう簡単には見ることができないでしょう…）。 ということは、サービス運用の視点も踏まえたログ出力を心掛ける必要があります。 では、実際にログを取得しないといけない状態になったと仮定しましょう。どういったことができると 楽ができる(早く見つけられる) でしょうか。 追跡しやすいログ出力にする意味 ログを確認する時、多くの場合は下記の流れになると思います。 「何かが発生した時間」で絞り込み その出力内容と同じ処理であるログ出

作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い