プロジェクト完遂後、参画していたプロジェクトが成功したのか、あるいは失敗したのかを判断するために振り返りの時間を設けているチームは多いと思います。もちろんプロジェクトに限らず、何かアクションを起こした場合であっても、振り返る時間は重要です。成功した場合はもちろん、失敗と判断された場合の振り返りは次のステップに繋げられるヒントを多分に含んでいます。

DevOpsのデリバリーパイプラインでは、アクションの結果を素早く得るために、フィードバックループを構築します。第4回目（最終回）ではDevOpsの「モニター」フェーズに着目し、メトリクスとフィードバックループについてご紹介します。

ビジネスとシステムのメトリクスの関係

一般的に成果を判断するためには、何かしらのメトリクス（指標）を設定し、その到達度合いを測ります。ビジネスシーンにおけるKGIやKPIはまさにメトリクスの一種です。システムにおけるメトリクスとしてはその時々のシステムやリソースの状況などがありますが、これはビジネスメトリクスを設定する材料や根拠になり得ます。

例えば、ECサイトのようなB to Cのサービスにおいては、リソースの状況がコンバージョン率や売上を左右する可能性があります。サーバーのリソース不足を検知できないままユーザーがサービスを利用してスローダウン／タイムアウトが発生すると、ユーザーにとっては負のエクスペリエンスとなり、コンバージョン率低下や売上減少につながる場合もあるでしょう。このような事象を未然に防ぐためにITサービスマネジメントのフレームワークであるITIL(※1)では、事業計画にあわせたビジネス遂行に充分なリソースを調達するキャパシティ管理プロセスが定義されています。ITILにおけるプロセスはDevOpsの文脈でも有効です。

フィードバックループの活用

メトリクスを意識しなければ、有益な情報は残念ながら時間とともに流れていきます。実際、アプリケーション開発現場では数多くの情報が生まれては消えていきます。そのひとつが効率化の指標となる「作業期間」ですが、充分に計測・活用できていないことも多いです。開発チームが作業着手してからソフトウェアをリリースするまでの期間を計測すれば「リードタイム」が得られ、さらに実装やテストといった各フェーズの「サイクルタイム」も計測できます。これらのメトリクスは新しいプラクティスが生産性向上に寄与するかどうかを判断するのに有効です。Redmineなどのチケット管理ツールを利用すれば容易に記録することもできます。

ただし、作業期間はとにかく早ければよいというわけではなく、同時に品質も考慮しなければなりません。テスト自動化は品質を担保する目的で導入されることが多く、テストコードを書いて振る舞いを検査する動的テストでの活用事例をよく耳にすると思います。これに対して、内部品質を担保する重要な観点として忘れてはならないのが、ソース解析をはじめとした静的テストです。コードレビューも静的テストに含まれます。当社の一部プロジェクトでは、静的テストでもテスト自動化を取り入れています。例えば前回コラムでご紹介したJenkinsとOSSのコード解析ツールSonarQubeを連携させて、ビルド前に「複雑度」や「重複度」などを計測しています。もし基準を満たさない場合は、ビルドは失敗となります。リリースしてからメンテナンス性の低いソースコードを修正するよりも、開発中に修正する方がコストは軽減できます。

我々が作るのはソフトウェアだけではありません。ドキュメントも重要な成果物です。昨今ではMarkdownスタイルのテキスト形式のドキュメントが注目されています。テキスト形式なので軽量かつ比較可能であることと、フォーマットが定義されているので読みやすく、まとめやすいのがメリットです。OSSの文書検査ツールRedPenは、これらのメリットをさらに活かすことができます。RedPenは文書が規約にのっとって記載されているかどうかをチェックしてくれるため、Jenkinsと組み合わせれば更新するたびに規約チェックができ、ドキュメントの継続的なフィードバックループを構築可能です。本コラムでもMarkdown形式で記載したものをRedPenで検査しています（※2）。

適切なメトリクスは有益なフィードバックループの構築につながります。一方で、メトリクスの設定や計測にのめりこみ過ぎたり、特定のメトリクスに執着して全体の目的を見失ってしまうのは本末転倒です。計測するだけに満足せず、分析・改善を経てその時々の状況から常に学び、見直すためにフィードバックループを活用しましょう。

さいごに　～今日からはじめるDevOps～

全4回に渡ってDevOpsの開発プラクティスの一部をご紹介しましたが、いかがでしたでしょうか。

コラムでは、各プラクティスを詳しく掘り下げることはできませんでしたが、「もっと知りたい」「現場で試してみたい」と調査・検証するきっかけになれば筆者としてはうれしく思います。

第1回目コラムでも触れたとおり、システムに求められるものは時代と共に変わっていきます。従来のような縦割り組織では要求に追いつくことが難しくなってきているのが事実です。これからは開発と運用がお互いに理解し、どれだけ協力できるかが重要になります。ご紹介したプラクティスやDevとOpsで共通のツールを活用して、DevOps実現のための第一歩を踏み出しましょう。

• ※1 ITILは、AXELOS社の登録商標です
• ※2 RedPenでの検査ルールはデフォルトから一部カスタマイズしています