コラム
システム開発において考慮が欠かせないものの、どのような対策をとればよいか悩ましい「デグレ」。今回は「デグレ」についての解説や対策例、対策をとるうえでの考え方などをご紹介していきます。
デグレとは、正確にいえば英語の「degrade」(低下する、下がる)の略語で、IT業界で使われる場合は、ソフトウェア開発のなかで、不具合を修正した場合などにそれまで動作したものが動かなくなってしまうというように、品質が低下してしまうトラブルのことをいいます。
日本のIT業界では「デグレ」がこのトラブルを表す言葉としてなじみがありますが、英語圏では「リグレッション(Regression)」という言葉を用います。ISTQB - Standard Glossary of Terms used in Software Testing の定義によれば、「リグレッション」は「変更により引き起こされた、コンポーネントやシステムの品質の悪化」とされていることから、私たちが日ごろ日本で使っている「デグレ」と「リグレッション」は同じような意味をもっていることがおわかりいただけると思います。
このコラムでは、以降、「デグレ」という言葉を、英語圏でいう「リグレッション」と同じ意味で用いますが、「リグレッション」についてはその言葉を含む事項を説明する際に使い分けて用いることにします。
デグレにはさまざまな種類がありますが、このコラムでは不具合の埋め込み箇所別に、3つに大別して整理してみます。
みなさまがもっとも多く遭遇しているデグレはこちらではないでしょうか。
この種のデグレの影響範囲は、埋め込まれたコード箇所だけでなく内容によっても影響範囲がさまざまで、自身で担当している機能だけでなく、担当外の機能へデグレを誘発してしまうこともあります。
こうして発生してしまったデグレは、当然ですが影響がおよんでしまった機能の担当とも連携してデグレの修正を行う必要があります。
複数のインフラや、多数のサービスの結合で成り立っているシステムにおいて悩ましいデグレの例です。この種のデグレは、個々の環境設定値の変更という以外にも、環境に適用しているミドルウェアやライブラリのバージョンアップ、また環境の移行といったことによって起こります。また、比較的広範囲に影響が出てしまいがちでもあります。
影響範囲が大きいことを念頭に置き、実際にデグレが発生しないことを広い範囲で確認しながら進めるような対策を講じ、慎重にリリース前の段階で想定外のデグレを防いでおくことが肝要です。
システム開発を行うなかで、ソフトウェアの挙動そのものを決める処理実装のほかに、デバッグ用のログ出力といった処理が含まれることもあります。このログ出力などに代表される、エンドユーザーとなるお客さまには直接影響しない機能においても、実装の仕方を誤るとデグレを誘発することがあります。例えば、ログを過剰に出力し過ぎてシステムの安定性に悪影響をおよぼしてしまい、正常処理ができない状態となる、といった具合です。
またレアケースではありますが、十分な計算やシミュレーションをせずに必要以上のデバッグデータを保持する処理を入れてしまい、想定以上にデータベースの容量が膨らんで満杯となってしまった。そのことで、デバッグとは関係のない通常処理でもエラーが起きるようになってしまった、ということなどもありえます。必要十分以上に容量を確保している本番環境では起きづらいかもしれませんが、容量も限られる検証環境においてはこのようなことが発生し、プロジェクトの進行に悪影響をおよぼしてしまう、といったこともありえます。
デグレの種類が明確にできたところで、次にデグレが発生する原因を整理しながら、それぞれについて簡単に対応のポイントを紹介しておきます。
仕様理解が正しくない状態で実装や影響範囲調査を行った(結果、間違いや考慮不足があった)場合が該当します。勘違いや思い込み、認識違い、といったことが直接の原因で、これは端的に「ミスをしてしまう個人の問題」と考えられるかもしれません。
ただもう少し慎重に分析してみると、体制的な問題、状況的にミスを誘発しやすい状態だったなど、原因は個人のミスとだけはいえない課題が潜んでいる可能性もあります。
簡単な例を以下に紹介しておきます。
体制的な課題例：
・実装者のスキルがアンマッチにも関わらずアサインされている
・レビューなどで拾いきれない(レビューをする側のスキル不足、レビュー実施方法の問題、など)
実装時のミスを誘発しやすい状況例：
・外的重圧(短納期、過度な管理や干渉、過度なハードワーク)
・複数の解釈の余地がある、あいまいな仕様
また厄介なことに、どのようなルールや体制を構築したとしても、「ミス」を完全になくすことは非常に難しいものです。とはいえ、ミスが多発する状態では対応が後手に回らざるをえなくなります。
したがって、「ミスが起きづらい体制と状態づくり」を先ず念頭に置きましょう。そのうえで「何らかのミスは起きる」という前提のもと、デグレを検知して対応できる方策を考えてみるとよいでしょう。
仕様が最新の正しい内容に整備されていないことで「正しい情報を基に正しい考慮ができない」という状況が発生しえます。また整備が滞ってしまう原因をもう少し詳しく検討すると、次のような課題が見つかるかもしれません。
・プロジェクト内での仕様整備ルールが明確でない
・仕様整備ルールがあるが、徹底されていない
・仕様整備ルール自体に不備がある
仕様整備については、まずは整備ルールをどこまで徹底できるかが鍵となりますが、メンバーへ呼びかけるだけでは徹底もむずかしいというのが現実かと思われます。
メンバーが自然と徹底していけるようになることが理想ですが、そのためには次のようなことをポイントとしておさえておくとよいでしょう。
・過度になり過ぎない程度にシステム側で更新が必要となる管理方法を導入する
・プロセスにルールを組み込むことで担当者以外から更新を促せる状態をつくる
・ルール自体に徹底できない大きな要因となっている内容があれば見直す
このような対応で、自然と仕様書を最新に保っていけるようになると、未整備情報を起因としたデグレも減らせるのではないでしょうか。
プロジェクトの進行はすべてが直列作業というわけではないため、どうしても仕様整備のタイミングにずれが生じ、つねに最新情報を自分だけで把握しておくのは非常に困難です。そこで重要になることの一つがメンバー間のコミュニケーションとなるわけですが、そのなかで、質疑応答のすれ違いや更新情報の共有漏れなど、影響を受ける機能担当同士での確認が不十分なままお互いの作業が進行してしまうと、想定外のデグレにつながることがあります。さらに、複数ベンダーで体制を組んでいるようなプロジェクトでは、チーム間やチームをまたいだ担当者間のコミュニケーションの課題に起因するデグレも起きる可能性があります。
コミュニケーション上の課題に対してはルール整備も大事ですが、何よりもプロジェクト内の風通しをよくすること、情報共有や相互確認をすることがお互いにとってプラスになるといった意識がもてるような体制をつくること、そして環境面や心理面でコミュニケーションをとるハードルを下げていく取り組みをすることなども非常に重要です。
起きる原因はわかったとしても、何らかのきっかけでデグレは発生しえます。ここでは実際にデグレが発生してしまった場合に起きてしまうこと、そのなかでも影響が大きい、リスクが高い点について触れてみます。
デグレの発生は「使える想定でいたものが使えない」状況を生んでしまいます。この状況はお客さまの信用・信頼を失うことに直接つながってしまいます。
信用を失うと、より厳しい目でお客さまから見られることとなり、その分要求も厳しくなりがちです。また一般の消費者がお客さまの場合、デグレをきっかけにサービスの利用者が減ってしまうということにもつながりかねません。
デグレは基本的に早急な修正対応が求められます。当たり前ではあるのですが、このときさらなるデグレが発生しないようにする必要があります。そのための詳細な影響範囲の調査とテストにも、十分なものが求められます。十分とする根拠を示すための報告資料が必要となることもあります。
ただ、これらの対応はそもそも想定外の作業であり、それにともなった工数とコストが必要となることがあります。また作業上だけでなく、リリースや納品などの予定まで大きく狂わせる可能性があります。
最終的に期限に間に合わなくなってしまうと、受託プロジェクトであれば契約違反とみなされ請求ができない事態になったり、場合によっては損害賠償請求されたり、といったことすらありえます。
自社プロダクトであっても外部にステークホルダーがいて、リリースが必須要件といった場合は、リリースできないことで同様の状況にもなりえます。
デグレが発生したということは、そもそもデグレリスクが潜んでいた箇所で、リスクが問題として顕在化してしまった結果、と考えることができます。つまりそもそもリスクが高かった箇所なのであれば、再度同じような問題も発生しやすいといえます。そのため、デグレの修正対応も通常より正確で確実な対応が必要となります。
正確さや確実性が要求されるうえに、デグレには早急な修正作業が求められます。また、対応は想定外のことでもあるため、対応する人あるいはチームに焦りを呼び込み、人為的なミスも起きやすい状況となりがちです。
このような場合は、さらなるデグレの再発を誘発する可能性も高まり、デグレがデグレをよぶという、いわゆる「負のスパイラル」状態となってしまいかねません。苦しいところではありますが、デグレ発生時は通常時以上に、正確な情報を基に、確実な修正対応をとることが肝要です。「とりあえず」の対応でその場をしのぐのはおすすめできません。
デグレの原因とあわせて簡単な対応のポイントは紹介しましたが、ここではもう少し具体的にデグレ対策について紹介していきたいと思います。
デグレの対策は、目的別に考えてみると、次のような2つのものに大別できるといえるのではないでしょうか。
・デグレの発生そのものを防止する「防止策」
・デグレが発生したとしても影響を最小限にとどめるための「対応策」
そもそもデグレ自体が想定外のことであるため、それを完全に防止しきることは非常に困難です。このことを受け入れ「想定外の不具合やデグレは一定数発生し得るもの」という前提にたてば、デグレの発生自体をおさえることを目的とした「防止策」だけでなく、デグレ発生時の影響を低減させることを目的とした「対応策」も必要だといえます。
以上に加えて、これらの策をどれだけ効果的に導入するか、戦略的にどのようにコントロール可能な状態を目指すのか、ということがとても大事な考え方です。
これらを踏まえたうえで、どんな防止策や対応策があるかを見ていきましょう。
防止策としては、基本的にデグレが発生してしまう「原因」に対して有効な手段を考えていきます。ここで紹介している策は基本的ですが重要なことでもあり、いずれかに対応すればよいものではなく、複数(あるいは全部)に取り組むことで、よりデグレが発生しづらくなるといえます。
仕様情報を含めたバージョン管理や更新ルールを決め、運用を徹底することで、そもそもミスが起きづらい状態をつくることが必要です。具体的には、次のようなものがあげられます。
・(もしなければ)管理・更新ルールの導入
・更新時の関係者への通知方法、タイミングなどのコミュニケーションルールの策定
・更新内容に応じて影響を受ける関係者への説明機会を設けるための基準の設定
・プロジェクトのプロセス内への更新の確認やレビューの組み込み
・ルール運用の徹底をプロジェクト全体へ浸透させるためのウォッチング、呼びかけなどの活動を定常化
・可能な範囲でシステム化し、定めたルールが自然と徹底される仕組みの導入
デグレは、往々にして影響範囲の調査でミスや考慮不足が直接の原因となって発生することが多いのが実態です。そのため影響範囲の調査という作業に対しても、ルールや方針、ミス防止の仕組みといったものを導入することもデグレ防止に有効です。具体的には次のようなものがあげられます。
・正しい仕様情報、正しい理解を基に、確実で十分な(的確な)調査の実施
・不確実な部分があれば、仕様情報にもとづく確認だけでなく現新比較を実施
・可能であれば静的解析ツールなどを用いて人的ミスの発生を抑止
・自身の理解の正しさを影響範囲の担当者とすり合わせる
・同じような処理のなかにあるわずかな「差」こそデグレを生むもとと考え、考慮を怠らない
対応策としては、デグレが存在していた場合でも、最終的なリリースまでにどのようなコントロールが有効か、という手段を考えます。
デグレがあったとしても、お客さまへ影響しないようにテストなどで事前に検知して対応できること、さらにそこをすり抜けたとしても、リリースへの影響を最小限にとどめるためにどんな取り組みが有効か、というような例をあげます。
以降で紹介する対応策は、デグレそのものだけでなく、結果的にシステムの品質までコントロールしやすくなるメリットもあります。ぜひ参考にしてみてください。
ここでようやく「リグレッション」という言葉が登場しました。
リグレッションテストは主にデグレを検出したり、デグレが発生しないことを確認したりするため、基本的に既存機能などテスト済みの範囲に対して行うテストです。日本語では回帰テストと呼び、同じようなものとして無影響確認と呼ぶこともあります。
リグレッションテストを行う際の対象(範囲)や優先度の考え方、気をつけるべきポイントは次のとおりです。
・「十分な影響範囲調査」結果を基に、的確な影響範囲に対してテストを行う
・リグレッションテストで重篤な問題が出た場合でもリリースまでに修正対応可能なスケジュールでテストを行う
※リグレッションテストで検出された不具合の対応方針を決めておく(不具合の重要度などを別途定義しておき、重要度に基づいて許容可否を判定するなど）
・本番環境と極力同等の保証が可能な環境においてテストを行う
※環境の違いで起きるデグレを見逃さない
・優先度を考慮してテスト範囲を絞り込む(影響範囲全体・全パターンのテストは工数や期間的に困難なことが多い）
以下、優先度を高く考慮した方がよいポイント例：
・不具合が発生した場合に影響が大きい範囲
―お客さまの利用頻度の高さ、機能的な重要度を考慮
・過去の不具合発生傾向が高い範囲
・ほかと比べて処理差分が存在する範囲(特定パターンのみ異なる処理を行うなど)
CI (Continuous Integration, 継続インテグレーション) では、コンパイル、テスト、デプロイといった一連の作業を任意のタイミングでも定期的にも自動で行うことが可能です。テストに関しては自動テストコードの実装が必要で、運用していくなかでメンテナンスも欠かせません。しかし、実装済みの自動テストは、次のような目的に対して有効な手段となります。
・リグレッションテストの効率的な実行
・検出し易いデグレの早期発見
またCIで定期的に自動テストを行うことで思わぬデグレを検出できることもあるなど、次のような場面で効果を発揮します。
・手動で実施しきれない範囲や量のテスト実行
・影響範囲外と考えていた範囲のデグレの検出
・環境や別機能の変更の影響を受け、知らぬ間に埋め込まれたデグレの検出
一方で当たり前ですが、自動テストはテストを実装していない内容で発生するデグレは検出できません。内容によりますが、手動だから気づける場合もあります。そして手動テストであれば自動テストコードの実装までは不要で、自動テストと比較すると新たな内容に対して柔軟に対応しやすいことが多いです。
上記の通り自動テストは効率的にリグレッションテストを行ううえで有効な手段ですが、実装やメンテナンスにもコストがかかり、デグレの検出に不向きなこともあります。そのため自動テストと手動テストとをバランスよく組み合わせて活用することで、さらなる効果を発揮するものだとお考えください。
一度発生したデグレや類似の不具合は再発しやすいものです。デグレについて吟味し、振り返ることで、その後の同じまたは類似の不具合の再発防止に有効な改善策が見つかるかもしれません。見つかった改善策は、防止策の質向上にも適用できます。デグレの振り返りをするうえでおさえておきたいポイントは次のとおりです。
・デグレの直接的な原因に留まらず、その原因を生んでしまった真因まで分析する
＊個人のミスや問題とするのではなく、それがなぜ起きたのかまで吟味する
・改善策はプロジェクトの仕組みや取り組み上の改善となるものを念頭に、真因に対して有効な策を検討する
・改善のための具体的なアクションまで決めて導入する
・検討した改善策を導入するだけでなく、導入後の効果測定も行い、必要に応じて見直しも行う
リリース時に問題を検知してすぐに巻き戻したりできれば、デグレによる影響を最小限にとどめることもできます。
ここではではGoogle Cloudアーキテクチャセンターの解説にもある、代表的な手法「カナリアテスト」と「シャドーテスト」および「A／Bテスト」を取り上げてみます(それぞれの詳細はリンク先の解説をご参照ください)。これらはデグレ発生時の対応策として有効なだけでなく、システム品質の安定や向上にも寄与する手段でもあります。
・カナリアテスト(カナリアリリース)／シャドーテスト
いずれもリリース自体をコントロールする手法で、本番に100%開放する前にデグレなどの問題発生をモニタリングし、もし重篤な問題が検知された場合はロールバックやリリース取りやめも行えるところがポイントです。
システムの継続運用を念頭におくと導入しておきたい仕組みではないでしょうか。デメリットとしてリリース開始～完了まで時間を要する、シャドーテストでは複数環境のコストがかかる、といったものがあげられます。導入を検討する場合は、予算やスケジュールを考慮することをオススメします。
・A／Bテスト
カナリアテストやシャドーテストはあくまでリリース単位でコントロールするものですが、A／Bテストは特定の機能や実装単位で開放率をコントロールできます。そのため新たな機能や実装の割合を0%にしてしまうことで、デグレが発生しない状態へ実質ロールバックできます。
カナリアテスト、シャドーテスト、A／Bテストは組み合わせることも可能です。導入しておくと、いざという時のコントロールがしやすいでしょう。
デグレは「これさえやっておけば大丈夫」という完璧な対策は存在せず、厄介なものであることは間違いありません。しかし、しっかりと向き合って対策をしなければ、このコラムでご紹介したリスクにつながる危険性もあります。デグレを未然かつ完全に防ぐことは難しく、そのため先に紹介したように目的に合わせて「防止策」と「対応策」を検討することは不可欠だということはご理解いただけたと思いますので、あとは、どのように実行していくかをみなさまが日々対峙するシステムの特性にあわせて検討いただければと思います。
最後に、このコラムでご紹介したことが、多くの人の気づきにつながり、世の中のシステムの品質向上の一助になれば幸いです。
