まずは自身の開発プロセスに取り入れてみる
小規模から始める
特定のサービスやアプリケーションのテレメトリーデータを取得するところから始めましょう。
最初は開発環境、検証環境で試すのはもちろんですが、そこで得られるデータは面白いものではありません。システムへの影響を確認したうえで本番環境に入れましょう。
オブザーバビリティバックエンドについてはどうしましょうか。
重要な検討ポイントとして、以前の連載で、テレメトリーデータとしてトレース、メトリクス、ログが主に存在しており、それらを連携させることが重大であるということをお伝えしました。また、テレメトリーデータは容易に肥大化するためストレージの問題も考えなければなりません。有償のSaaSオブザーバビリティツールはデータ間の連携機能が充実しており、またストレージを懸念する必要がないため（当然費用はかかりますが）、もし使える場合は使った方がよいと思います。何もない場合、予算はすぐには取れないと思いますのでOSSで始めましょう。
OpenTelemetryに対応しているOSSは公式ページから確認できます。
自動計装に対応した言語から始める
どのようなトレースやスパンが取得できるかは言語やアプリケーションの構造に依存するところが大きいので、やってみなければ分かりません。
そのため自動計装に対応した言語から始めることをお勧めします。
特にJavaは成熟度が高く、多くのライブラリにも対応しています。
ただしそれに限られることはなく手動計装に抵抗がなければ例えばGoでも良いでしょう（Goも自動計装への対応は進んでいます）。
OpenTelemetryを育てる
無事にOpenTelemetryを計装し、バックエンドに送り、可視化ができたらおめでとうございます。
オブザーバビリティ実践のスタートです。
データを見て、解釈し、目的に役立てられるか考えてみましょう。
必要なデータがなければ追加して育てていきましょう（第三回、第四回参照）。
開発プロセスに組み込む
使えると判断できたら、開発プロセスとしてOpenTelemetry計装を組み込んでしまいましょう。
インフラにもOpenTelemetry Collectorを自動デプロイできるようにしましょう。
これによりOpenTelemetryによるオブザーバビリティReadyなシステムができあがり、開発行程のトラブルシューティングから本番環境のオブザーバビリティまで、さまざまな恩恵を享受できます。
