はじめに
手段を目標に近づけるとは、非機能要件における本質的な困難を解決する技術です。
より分かりやすく目標達成につながる手段を決める技術と言い換えることができます。
目標と関係ないタスクをこなして工数を無駄にしない技術と言えます。
いいね、ストックをよろしくお願いします！
大量の測定と統計に傾向的に明らかにする
大量の測定を行うことで、どの部分が本質的な問題になっているかをデータ分析できる可能性があります。この手法は大量のデータが必要なので、人力での評価が必要になると難しいです。そのため、比較的機械的に処理できる範囲の大きいパフォーマンスと信頼性の分野で発展してきました。次のベストプラクティスは全て本質的には同じ内容を主張しています。
- パフォーマンス：プロファイリングによりボトルネックを特定する。「推測するな計測せよ」
- 信頼性：オブザーバビリティを高め、障害の原因を明確に追跡できるようにする
統計的な意思決定
大量の情報を測定すれば、データから効果的な手段を考案できる可能性がある
「オブザーバビリティ・エンジニアリング」には、測定の手法と測定からの意思決定の手法の両方が詳しく述べられています。
「効率的なGo」にも、パフォーマンスの改善をデータ駆動で行うための手法が書かれています。この書籍では、効率化の際に、目標を用いることの重要性も述べられています。
ベースラインと比較する
これは、いわゆる対照実験の考え方です。
なんらかの手段を打った直後に起きた変化は、おそらく手段による効果だろうと推定することができます。
この手法の問題点は、やった後にしか評価ができないことです。統計的に効果を予測する場合と違って、事前に必要な内容がわかるわけではなく、手段の決定時点ではただの予想に過ぎず、実施した後にようやく手段のよさを推定できます。
- ベースラインとの比較は手段の良さを評価する手法であって、予測する手法ではない
- ベースラインとの比較は目標の設定・測定に継続的に取り組んでいることが前提である
この性質から、手段についても継続的な改善が必要だと分かります。
つまり、効果がありそうな手法をいくつか予想して実施し、実際に効果的だったものを残し、外れたものを取り消すことで、効果的な手段を見つけることができます。
このフレームワークがKPTです。Keepは良い手段、Problemは悪い手段、Tryはそれをもとに行う新しい手段です。逆に言えば、具体的な品質・目標を理解することなく漫然とKPTだけを運用しても意味がありません
ベースラインとの比較
- 継続的に品質情報の測定を行うと、比較によって手段の良さを推定できる
- ベースラインとの比較は事後的な推定なので、良い手段を発見するためには継続的な手段の改善が必要である
現在の状態・目標の状態・期間から考察する
前節では、効果がありそうな手法を予想する必要性を説明しました。大量の測定と統計が使えない非機能要件の場合、予想と評価の繰り返しが必要です。
予想は人間による勘と経験に頼らざるを得ない領域ですが、ある程度のフレームワークはあります。いわゆるロジカルシンキングなどの手法は予想のために有用です。
本記事では具体的な思考法は解説しませんが、非機能要件の考察で必要な概念について簡単に述べます。
効果的な手段を発見するポイント
- 手段とは、現在の状態と目標の状態の差分を埋めるためのものであるから現在・目標・差分の全てを認識した上で考える必要がある
- 手段には効果を発揮するまでの時間がある。長期的施策と短期的施策の両面から考えるべきである
「アジャイルなチームを作る 振り返りガイドブック」には、測定が難しい状況を乗り越えて継続的に改善を続けることの重要性が述べられています。
失敗から学ぶ
失敗から学ぶことは、非機能要件において特に重要視されています。
- 信頼性・セキュリティ・パフォーマンスの分野では、インシデント分析が重要視されている
- DevOpsでは、非難のない事後分析が重視されている
この理由は、失敗からは、問題があることを認識できるからです。
失敗は情報量が多い
- 失敗は、現在の目標および手段が誤っている・不足していることを示す
- 現在の問題の原因は、確実に間違っていることが保証される
成功は情報量が少ない
非機能要件では、目標を達成しており、品質が高いように見えたとしても、それは正しい目標・手段を意味しない。なぜなら、次のようなケースがあるからである。
- 目標で本来必要ない過剰な水準を要求してしまっている
- 手段のうちいくつかはむしろ逆効果だが、全体としてプラスになっているため顕在化していない
- 実は目標も手段の全くのデタラメだが、外部の要因によってたまたまうまく行っているため問題になっていない
失敗には必ず直接的な原因があります。例えば次のように、具体的な問題個所を特定できます。
- パフォーマンス：スロークエリがあった
- ユーザ価値：ユーザーの隠れたニーズを見逃していた
- 信頼性：外部の信頼できないコンポーネントと強い依存関係があった
成功しているときには開発プロセスのすべての改善の余地を探っていたのに対して、失敗しているときは問題の原因の箇所の改善の余地を探せばよいです。
さらに、失敗の分析からは、品質・目標・手段のすべての領域にわたって改善可能性を見出すことができます。例えば、次のような分析結果が得られる可能性があります。
- 目標が間違っている
- そもそも追いかけていない品質につながる内容があった
- 数値設定・確認項目が不十分だった
- 手段が間違っている
- 手段を実施しても目標に寄与しなかった
- 手段が正しく実施されていなかった
失敗から得られる教訓
失敗からは、目標・手段どちらの問題も検出できる。
おわりに
目標に適した手段を発見する方法は、具体的な目標の内容に大きく依存するため、一概に手法を述べることは困難です。この記事で解説したような方法を通じて継続的に改善し、当事者意識を持つことが重要です。
幸い、目標は測定可能なので、目標が達成されるまであきらめないことで、それなりの確率で良い手段を発見できるはずです。