こんにちは、FLINTERSでPMO的な仕事をしています。今回の投稿はFLINTERSブログ祭りの記事です。テーマは#プロジェクトマネジメント #ソフトウェア品質 #SLO 今回はプロジェクト横断でサービスレベル目標を取り入れた話について書きます。
サービスレべル目標（SLO）を取り入れた背景
プロジェクト内でシステムの品質について議論になった際に顧客と品質の期待値があっていないという問題がありました。その原因を深掘っていくと、そもそも顧客が求める品質要求が明確になっていないことが原因だと分かり、 品質要求を明確にしていくために改めてソフトウェアの品質とは何なのかという原点に立ち返りながら、最終的にはSLOを決めるところまでたどり着きました。
ソフトウェア品質とは
SLOの話に行く前に簡単にソフトウェアの品質について触れます。
国際規格のSQuaREシリーズのソフトウェア品質モデルによると品質は製品の品質モデル、利用時の品質モデルに分けられます。
製品の品質は機能の豊富さや、操作のしやすさといった製品自体が備えている品質を表しているのに対して、
利用時の品質は利用者がサービスを使ったときの満足感や作業効率の向上といった利用者への影響を表しています。
詳細はIPAから出ている「つながる世界のソフトウェア品質ガイド」でまとめられているのでソフトウェア開発に関わる方はぜひ一読されることをおすすめします。
サービスレベル目標（SLO）
前項でソフトウェア品質をおさらいした上で、我々のプロジェクトで顧客と品質要求が合っていなかったのは信頼性とセキュリティと分かっていたため、その二つの品質要求をなるべく網羅的かつ定量的に評価可能な指標を探しました。 幸い経産省から2008年に出されていたSaaS 向け SLA ガイドラインのモデルケースがSLOの各項目を網羅的にまとめられていたため、こちらを採用しました。
（SLA、SLO、SLIといった品質要求に関わる用語の基本的な話はこちらを参照。）
プロジェクトへの導入の流れ
先ほどのSLAガイドラインをもとに、我々のプロジェクトで必要なサービスレベル指標の選定をしました。
指標を計測する環境を用意するのにも開発工数がかかるため、極力不要な指標は計測対象から外すことと、計測することでシステムの改善に使える指標の選定を心掛けました。
約1カ月ほど各項目について議論を進めながらSLOが出来上がりました。
SLOを導入した後の効力として、品質について問題が発生した際にSLOのどの指標がどの程度問題なのかといった、定量的に問題を議論出来るようになりました。
今後の展望
今回は顧客との品質レベルの期待値を合わせるためにSLOの策定までの話になります。今後はこのSLOを定期的にモニタリングしてシステムの改善サイクルを回していくことを目指しています。
