はじめに
現在のソフトウェア開発において、開発とQAは密接な関係にあります。
それこそ、手を取り合ってプロジェクトを進めていくのが基本となりつつあります。
しかし、開発の専門性が高いようにQAも専門性が高く、用語や意図がわからない場面は多々あるでしょう。
そんな方のため、用語の解説を行っていくシリーズです。
また、本記事は私の独断と解釈によるまとめですので、一部事実と違う点があるかもしれませんが、その際はご指摘ください。
「シフトライト」のざっくりとした解説
「シフトライト」の概要
本来、開発物を確認する工程は「テスト」のみでした。
その「テスト」より後ろの段階で「確認する」という作業を実施することを指します。
また、何かの仕様についての正と定めるものを、要件定義や設計ではなく、
リリース後の「顧客の声」を正として開発すること、とも言えます。
「シフトライト」の主なメリット
「実際の顧客の要望を正確に反映できること」がシフトライトの主なメリットです。
「シフトライト」のお試し方法
製品のリリース後、顧客の声を元に開発を行っているのであれば、
そこの拾い上げ方を工夫したり、強化することがシフトライトに繋がります。
ただ、その一部の手法は非常にデリケートであり、お試し感覚で実施できません。
「シフトライト」の詳細な解説
品質関連書籍からの引用
まずは私自身の言葉で説明するよりも正確性を大事に、世に出ている公的な書籍から引用しようと思いました。
が、手元にある何冊かQAの参考書に、シフトライトの記載はありませんでした。
何に対して「右」なのか
「右に行く」ことはわかると思いますが、何を指して右方向なのかが不明瞭かと思うので、そこから解説します。
Vol.1で「シフトレフト」を解説しているので、一旦そちらを参照いただくと前段の理解も深まるかと思います。
前段を端折って説明すると、
古くはウォーターフォールという開発手法が世の代表だった時に「シフトレフト」が生まれました。
ウォーターフォール開発はその名の通り、一方通行で行ったっきりの開発フローです。
この図で、元の「テスト」のフェーズよりも左側でもテストを実施する、ということで「シフトレフト」と呼ばれています。
そして、近年の、特にソフトウェア開発では、ほぼウォーターフォール開発は使われていないでしょう。
リリースして終わり、ということはなく、機能追加、要望、不具合修正等々、継続的な開発が行われます。
終わりなきシステム開発ライフサイクルです。
先ほどの図に書き足すと、以下のような感じでしょうか。
「シフトレフト」は「テスト」より左側でテストをすることですので、
「シフトライト」は「テスト」より右側、つまり「運用」をテストの場にすることです。
「シフトライト」の詳細なメリット
最も大きなメリットは、
「要件定義や開発者の想定したものでなく、実際の顧客の要望を反映できる」という点です。
「リリースした後も修正が無限に続く」というのが実務上の感想でしょうが、
「リリースした後に修正することができる」と利点に捉えています。
関連して、要件定義や設計段階で顧客のニーズやシナリオを想定して仕様を決定したりしますが、
それが一発で、すんなりと決まったことはありますでしょうか。
特にフロント側、WEB系だと、デザインも相まって紛糾するでしょう。
「実際に運用してみて、顧客の反応を見ましょう」と、そこで議論を収めることができます。
つまり、運用のタイミングで何が良いかテストを実施しています。
多少レビューの時間を抑えつつ、本当の正解を探ることができます。
デザイン周りであれば、改修する場合に表示崩れなどあるかもしれません。
多彩なデバイスでの表示確認など、修正工数と比較して確認やテストの工数が多くかかったりします。
「メジャーケースは押さえておいて、マイナーケースは実際に運用してみて、指摘されたら修正しましょう」と、
ある程度の工数で切り上げる判断ができます。
つまり、運用のタイミングで不具合がないかテストを実施しています。
工数を抑えつつ、効率よく不具合を検出することができるということです。
「ABテスト」や「カナリアリリース」と言えば、聞き覚えがあるでしょう。
これらが「シフトライト」に当たります。
「シフトライト」の導入方法
シフトレフトとセットで詳細を記載しようと思っています。
シフトレフトでも記載していますが、これ自体は導入しようと思って導入するものではありません。
品質向上のため、不具合をより発見しやすくするため、各種コストを下げるため、
そういった問題を解決するための手段の一つだからです。
特に「シフトライト」とはその性質上、不具合をリリースする前提でもあり、容易に行うことができません。
本記事ではそのあたりまでご理解いただければ幸いです。