いまの時代だからこそ「稼働品質」に取り組む。IPA/SECの報告書から何を学ぶか

近年、Webサービスのインフラは、クラウドサービスを使うことで、10数年前に比べ容易に構築することができるようになりました。また、FinTechはますますの盛り上がりを見せ、金融とITテクノロジーの融合により、革新的なサービスが次々と生まれようとしています。LINEの銀行業参入や電子決済サービスPayPayが話題になったのも記憶に新しいです。Webサービスは、社会インフラとただ繋がっているだけではなく、社会インフラの一端を担うようになったといえるでしょう。社会的に重要度の増すWebサービスはこれから「稼働品質」が求められるようになります。「稼働品質」とは何か、ITサービスを生み出すプロジェクトマネージャーやエンジニアはどのようなエッセンスを学び取ることができるか一緒に考えてみませんか?

稼働品質を知る

稼働品質は、言葉の響きからぼんやりと意味をイメージできますが、具体的にはどのようなことをいうのでしょうか。『情報システム障害の再発防止のための組織的マネジメントの調査WG報告書』では稼働品質を次のように定義しています。

「情報システムが事業基盤としての役割を果たせない(例:情報システムが停止し業務が通常どおり実施できなくなる、または情報システムの利用者に迷惑をかける)ことにより、事業上の損出をどの程度発生させているかを表した指標。」
引用元:https://www.ipa.go.jp/sec/softwareengineering/reports/20120405.html

稼働品質が指標であるという点は重要な定義です。たとえばWebサービスを生み出すにあたって「最新のテクノロジーによって高い可用性を確保するべきである」との品質に関する主張は、稼働品質を考えるうえではおそらく不十分でしょう。
稼働品質を考えるにあたり、提供サービスに合わせた目標設定をします。『情報システム障害の再発防止のための組織的マネジメントの調査WG報告書』では、年あたりの「重大な障害の発生件数」を目標とする事業者が多いと書かれています。同資料では、障害について以下のとおり定義されています。

「『障害』とは、情報システムを用いた業務に対する悪影響、情報システムの利用者(事業者内利用者、主要顧客)への迷惑」
引用元:https://www.ipa.go.jp/sec/softwareengineering/reports/20120405.html

FX(外国為替証拠金取引)のWebサービスを例にしてみましょう。FXは平日24時間Webサービスが利用できます。土日にもWebサービスは利用可能ですが、利用者は注文を出すことができるのみで取引が確定することはありません。また、為替レートには大きく動くタイミングがあり、たとえば初月第1金曜日に発表されるアメリカの雇用統計が有名です。この時間帯には多くの利用者が注文と取引の確定を行います。
何らかの障害によって利用者がWebサービスを使えなくなった場合に、その障害の内容が同じであっても、土日に起こったか、アメリカの雇用統計発表直後に起こったかによって利用者が受ける悪影響の大きさは異なるものになります。

障害=システムバグとのイメージがありますが、障害の定義は利用者にどれだけ迷惑をかけたかがポイントのようです。稼働品質を考えるうえで、障害の影響度(重大さ)は技術的な観点よりも、迷惑を受けた利用者の数や時間で測ることが大切だと分かります。

品質向上のための取り組み事例を知る

品質向上のためにWebサービスの利用者への迷惑という観点で何から取り組めばよいでしょうか。IPA/SECの『情報システム障害の再発防止のための組織的マネジメントの調査WG報告書』の第3章では調査対象の事業者の取り組みが紹介されています。

私が注目したのは「リスク」です。かつての品質向上施策と言えば品質マニュアルを作成し、それに沿って運営されることが重要とされていました。ところが上記報告書では品質マニュアルの記載はなく、リスクに関する管理と対応の説明に多くのページが割かれています。

品質マニュアルは、品質マネジメントシステムに関する国際規格であるISO9001が要求していたものです。私はISO9001をあらためて確認することにしました。

ISO審査登録機関である日本検査キューエイ株式会社(JICQA)が発表した『ISO9001:2015規格改正の解説』によると、2015年改定で「品質マニュアル」の要求がなくなり、「リスクに基づく考え方」が強化されていました。
引用元:https://www.jicqa.co.jp/member/member/data/iso9001_2015kaisetsu.pdf

IPA/SECの当該報告書でもISO9001でも、計画策定や組織態勢についてリスクに基づいたアプローチの重要性が語られています。クラウド時代に稼働品質の目標を達成するためには、プロジェクトチームが直面するリスクにどのように対応するかがカギといえそうです。

【エッセンス】リスクベースで考える

これらを調べていくうちに、私にちょっとした意識のアップデートがありました。

1つ目はPDCAサイクルについてです。

PDCAサイクルといえば、まずは想定した正解をもとに計画やルールを作り(P)、それらに従って作業を進め(D)、計画やルールどおりか見直し(C)、改善する(A)ものです。PDCAサイクルを実践しようとすると痛感するのですが、正解ありきということが今の時代難しいように思います。
かつてITシステムといえば「手作業で行われていた業務をコンピュータにやらせる」というようにシステムに対する要求が明らかなものが多数でした。しかし、近年かかわったプロジェクトの多くは、完成形が見えにくいものとなっています。

リスクに着目してPDCAサイクルを回す場合は、まず計画を策定するにあたってリスクを洗い出し、意思決定に役立てます(P)。それらに従って作業を進め(D)、計画どおりか見直し(C)、最初の段階でリスクの洗い出しに漏れがないかを検証します(A)。稼働品質を継続的に確保するために、リスクの変化に機動的に対応できる態勢を維持するにはリスクに着目したPDCAサイクルの使い方のほうが有効に機能するのではないでしょうか。

2つ目は変更管理についてです。

Webサービスの完成形が見えにくいときの基本戦略として、スモールに早期にリリースし、その後改修を繰り返すといった方法を取ることがあります。そのような進め方のとき、プロジェクトマネージャーにとって変更管理は骨の折れる仕事です。
よく目にするプロジェクトの進め方は、変更に関する機能要件をまとめたドキュメントをベースにする方法です。しかし、変更のたびにバラバラに作成したドキュメントは、プロダクトを一気通貫に管理できていないことがほとんどです。

リスクに着目して、プロジェクトチームが変更を管理できる態勢を維持するには、以下のようなことが重要だと考えられます。

  • 変更に関する機能要件作成と同時に、リスクの再評価と望ましくない影響の予防/軽減策を立てる。
  • 変更による悪影響、または意図しない変更による利用者への影響を最小限にするための対策を講じる。

リスクベース・アプローチで「稼働品質」に取り組む

IPA/SECでは多くの報告書や教訓集が発表されていますが、読む機会はそう多くはないのではないでしょうか。クラウドサービスを活用したWebサービスやFintech分野からは遠いものだとイメージされている方も多いと思います。実は私もそのように思っていました。

今回記事を書くにあたりIPA/SECの報告書とISO9001関連資料を読み進めたことで、その印象は大きく変わりました。

プロジェクトマネージャーやエンジニアは、作り上げようとしているWebサービスが利用者にとってどのような体験価値を生むかを積極的に理解する姿勢が求められるようになるでしょう。生み出された、もしくはこれから生み出そうとしている革新的なサービスにおいて、稼働品質は重要な指標になると感じました。
さらに稼働品質の目標を達成するために活用するリスクベース・アプローチは、プロジェクトすべての工程における意思決定において大きな役割を果たしていくことになるのではないでしょうか。

最新情報をチェックしよう!
>TeamHackで、タスク管理を驚くほどラクに。

TeamHackで、タスク管理を驚くほどラクに。

TeamHackは、タスク管理とチャットが同時にできる「業務コミュニケーションのしやすさ」に特化したオンラインワークスペースです。コミュニケーションツールとタスク管理ツールを行ったり来たりして、二重に管理の手間がかかる問題をスッキリ解決します。

CTR IMG