サイト内検索

閉じる閉じる

サイト内検索

閉じる

ITアーキテクトコラム

  1. コラム
  2. ITアーキテクトコラム
  3. [DevOps連載]第4回(最終回) 継続的なフィードバック環境を目指して

[DevOps連載]第4回(最終回) 継続的なフィードバック環境を目指して

2017/08/08

友野 敬大友野 敬大

  • Facebook
  • Twitter
  • google+
  • はてなブックマーク
  • DepOps

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

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での検査ルールはデフォルトから一部カスタマイズしています

著者プロフィール

友野 敬大

友野 敬大

開発本部 金融ソリューション第1部 金融テクノロジーソリューショングループ

当社のクラウドサービス「寄付金クラウド」をはじめ、金融機関向け・エネルギー企業向けの複数のクラウドサービス案件に参画し、基盤構築からアプリケーション開発(Java)まで幅広く従事してきました。これらの経験から、プロダクト(ひいては組織)の全体最適化に興味を持ち、その一つであるDevOpsを推進し、お客様に提案しています。先日、娘が生まれ、溺愛しています。

資料請求・お問い合わせはこちら

インターネットからの資料請求

インターネットでのお問い合わせ

お電話でのお問い合わせ

営業本部03-6757-7211

受付時間 9:00~17:30(土日祝日を除く)