数ヶ月案件を任されたので、エンジニア主導で「シフトレフト」やってみた

この記事は、🎄LITALICO Engineers Advent Calendar 2024🎄シリーズ4の12/24(火)公開の記事です。
同日公開予定のものとして以下記事もぜひご覧ください！

• シリーズ1: by @mamama_saito
• シリーズ2: by @yamahiro2022
• シリーズ3: by @shoji_kishimoto

はじめに

LITACICOのエンジニアの折田と申します。
2年目になり、偉そうに後進の育成なども少しずつ関わるようになりました。

さて、今年度の上半期に、数ヶ月規模の開発案件において、仕様検討、タスクマネジメントや、品質計画の一端まで任せていただきました。

そこで、「お！好き放題できるじゃん」（※イメージです）という気持ちになり、前々から興味があった 「シフトレフト」 なる考え方を取り入れて案件を進めてみたので、今回はその実践例の共有のために本記事を執筆しました。

↓こんな人はぜひ読んでください!!!

• 「シフトレフト」 ってなに？となった人
• プロダクトの品質を上げたいエンジニア
• おまえの品質管理などまだまだじゃ！という品質ガチ勢の方（ぜひご意見ください🙇）

サマリ

• シフトレフトの考えを取り入れ、工程後半に見つかるとやばいバグを事前検知できた
• その結果、コスパ良く品質向上でき、リリース後大きなバグもなし。シフトレフトいいぞ！
• エンジニアがもっと 「自分事として」 シフトレフトに取り組もう！
  • エンジニア自身が得をする
  • エンジニアだからこそ寄与できる面が大きい

前提

• 今回は、とある検索機能の実装案件においてのお話です
• 開発メンバーは、僕を含めエンジニア２人＋QAの、トータル３名が中心です（レビュワー含めると＋２人）
• 開発期間は約3ヶ月でした
• 僕の所属チームでは諸々の事情によりウォーターフォールに近い開発形態となっています

シフトレフトとは

ソフトウェアテストの第一人者と言われる、高橋寿一氏のコラムでわかりやすくまとまっておりますが、端的には以下になるかと思っています。

テストを最後にまとめて、ではなく、それぞれの工程の直後に実施、修正していく

特にウォーターフォール的開発においては、工程後半で初めて本格的なテストを実施するケースが多く、工程最後でバグが噴出します。

バグの修正コストは工程の後半で見つかるほど大きくなるということが理論的に証明されてるということもあり(以下図の赤線)、この状況はいかんよね、ということで、こういった概念が提唱されてきたという理解です。

(画像はこちらより引用)

僕の所属チームでも、工程最後のテストでバグが見つかり、リリース直前であたふたするケースが散見されておりました。
若僧ながら、「どうにかならんもんかなぁ」と思っていたところ、この概念に出会った次第です。

シフトレフト実践！

方針

というわけで、若僧が自分なりに「シフトレフト」を取り入れてみたわけですが、、、。

とりあえず、具体的な取り組みとしては、以下が考えられます。

• 仕様検討段階といった上流工程でユーザーストーリーの観点での仕様見直し
• PRレビュー・単体テストでのバグ検知
• システムテストの前に部分的にリリースしてテスト

ただ、考えなくてはいけないのは、こうした取り組みには工数・コストがかかることです。

そこで今回は、後半で見つかるとやばいバグのリスクのみに限定して、事前検知のための品質施策を実施することにしました。
たとえば、「送信ボタンが5pxずれてる！」などは、リリース1日前に見つかってもなんとかなりそうですよね

具体的プロセス

以下の工程にて、「後半で見つかるとやばいリスク」の洗い出し、およびそのリスクに対応するための施策を策定しました。

仕様検討フェーズ

• PdM、デザイナー、僕、QA、上長、シニアエンジニアで検討
• このなかで、エンジニア視点で、パフォーマンスに影響が出うる仕様だと感じたため、この時点で、パフォーマンスがリスクになりうることを検知
  • 工程後半でパフォーマンスが悪いと、インフラ構成や計算ロジックの大幅変更が必要になりうるので、「後半で見つかるとやばいリスク」 であると判断
  • 教科書的にも、パフォーマンステストは工程の中で定期的にやろうねと書かれている¹
• そこで、バックエンドの検索ロジックを細かくリリースし、その度にパフォーマンスチェックを行うことを決定

実装前のワイヤーフレーム確認

• デザイナーが作ってくださったワイヤーフレームを元に、QAメンバーと関係メンバーを交えて仕様の読み合わせを実施
• ここでは、デザイナーと実装側で解釈が分かれていた機能を検知できた
  • 工程後半に、デザイナーさんに、機能単位で「思ってたのと違います＞＜」って言われると、機能ごとの修正が必要なので、「後半で見つかるとやばいリスク」 と判断
• 結果的に、解釈が分かれた箇所については、プロトタイプを優先的に実装して、そのプロトタイプを元に、工程中盤でデザイナーと再度議論する方針を決定

QAとのテストについての擦り合わせの中で

• テストについてQAと話していると、今回の機能はSQLインジェクションのリスクがあるね、などといくつかのセキュリティリスクについて議論になった
  • 工程後半でも対応できなくはなさそうだが、万一漏れた場合、重大なセキュリティリスクになるため、「後半で見つかるとやばいリスク」 と判断
• 実装面で気をつけるのはもちろん、工程中盤で、社内のセキュリティグループにセキュリティチェックを依頼・実施することを決定
  • (主題とずれますが、自己完結できないものは、こういうふうに他チームを巻き込むのもよい動きだったなと思います。)

実装前半での気づき → 部分テストの事前実施

• 画面側の実装を進める中で、IMEまわりの機能が、OSとブラウザの組み合わせによって全く異なる挙動になることが判明
  • じゃあどんなブラウザとOSの組み合わせがありえて、、、みたいなテストケース洗い出しをリリース直前にしだすとバタバタするので、こちらも 「後半で見つかるとやばいリスク」 と判断
• そこで、IME関連機能をリストアップし、そこのみを優先的に実装したうえで、この範囲のみの挙動を対象としたテストを工程中盤で実施

一旦まとめ

• パフォーマンスあぶなそうと検知
• ある程度作ってみてからデザイナーと擦り合わせた方がいい箇所を発見
• セキュリティリスクを検知
• ブラウザ依存の箇所があり、予想外の挙動になるリスクを検知

結果

先に総評

• 結局、パフォーマンス基準を満たさないことが工程後半に判明し、バタバタしてしまった
• ただ、後述の通り、そのリスクについては事前検知できており、検知方法を誤っただけ、というもののため、シフトレフトの方針は成功したといってよさそう
• 以下の通り、事前検知できなかったバグもクリティカルなものはなく、規模に対してバグの総数も少なかったと言えるのではないか
• シフトレフトのために大きく工数が増えていると言うこともなさそうであり、コスパがいい品質施作になっていた

事前検知したリスクについて

• パフォーマンス
  • 予想通りパフォーマンスに影響が出た。事前検知すべきというのは正しい判断だった
  • ただ、パフォーマンステストの環境としてlocal環境を用いており、結局、工程後半ではじめて、本番環境にてパフォーマンス基準を満たしていないことが判明
  • テスト手法が正しければ、完璧だった
• デザイナーとの認識ズレ
  • プロトタイプを用いて認識を合わせたことで、工程後半でデザインにおける認識ズレによる仕様漏れはゼロ！
• SQLインジェクションリスク
  • セキュリティチェックを通し、無事合格
  • 工程の途中で、セキュリティ面で一定の保証を得ている安心感があった
• ブラウザ依存挙動
  • 明らかにUXが悪くなる挙動をするケースを工程中盤で事前検知
  • 検知後すぐに、どのOS、ブラウザまで対応するかのスコープの議論をPdMとできたため、ここで予想外に工期が伸びるリスクを排除できた！

事前検知できなかったバグについて

• 以下が、工程後半でバグ・仕様漏れとして挙がってしまった
• パフォーマンス基準を満たしていない
  • 先述の通り、テスト手法を誤らなければ事前検知できた
  • この対応でバタバタしてしまった＞＜
• 記号入力時に意図しない挙動
  • 後半に見つかったが故に、対応に結構工数がかかったため、事前検知したかった
  • ここはどうやったら事前検知できたか模索したい
• 細かいデザインずれ
  • すぐ対応できた
  • 元から、こういった「後半に見つかってもリスクが小さいバグ」は、事前検知の対象外にしていたため、この種のバグが後半に一定数出るのは許容

シフトレフト施策の工数について

• 案件全体としては、元の見積もり+2wになってしまったが、リソースの見積もり違いが大きな原因であり、今回のシフトレフト施策によるコスト増大が主因ではない
  • 余談ではあるが、より詳細の話をすると、僕自身の実装工数を5h/日と見積もっていたが、実際には僕自身が案件全体のマネジメントに工数を取られ、3h/日しかなかった。ここで大きくずれた
  • マネジメントをする工数も考慮する！²

これを読んでいるエンジニアのみなさんもシフトレフト！

見ていただいた通り、（パフォーマンスの件は惜しかったけど）大きなリスクについて事前検知し、あらかじめ出せるバグを工程前半〜中盤までに出しておいたおかげで、コスパよく品質向上できたと言えるのではないでしょうか！

特に、エンジニアがこういった取り組みをすることに意義があると僕は感じています。
たとえば、仕様検討フェーズでパフォーマンスに影響が出うる仕様だと事前にリスクを検知できたのは、実装を一定イメージできるエンジニアだからこそだと思いますし、ブラウザ依存挙動の件も、実装を進める中でエンジニアが気づいたことです。

僕自身、シフトレフトを意識して、なるべくリスクを事前検知したおかげで、後半のバタバタを減らせた実感があり、これは実装するエンジニアにとってもうれしいことです（デスマーチしなくない）

「シフトレフト」と検索すると、マネージャーやQA視点の記事が多いのですが、エンジニアだからこそ貢献できる面がとても大きいのではないかと思います！！

シフトレフト、もっとエンジニア界隈に広がれ〜！！

余談

• とはいえ、エンジニアがやるのはやはりコストかかりすぎるよねという論調もあるようです。たしかに、もっと大きな規模になった時に実装で忙しいエンジニアが、シフトレフトを意識できる余裕がない可能性はあります
  • https://cloud.google.com/blog/ja/products/application-development/richard-seroter-on-shifting-down-vs-shifting-left
  • DevOpsで自動化することで、コストなくシフトレフトしよう！という論調です。たしかに大規模だとこれが現実的なのかもしれません
• 僕自身、まだまだ新米(2年目)ですので、もっと多くの案件を経験する中で、開発フローのあり方について考えをより洗練させていきたいと思います。今回の僕の記事が、みなさんのエンジニアリングの何かのタネになれば幸いです！

1. 知識ゼロから学ぶソフトウェアテスト 改訂版: アジャイル・クラウド時代のソフトウェアテスト by 高橋寿一 ↩

2. プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで by 橋本将功　にもそう書かれています。案件完了後に読んだのですが、こういった基礎的インプットを怠ると足をすくわれますね。反省。 ↩