QRコードを使った鉄道チケット販売 〜堅牢な品質〜

実績紹介
【案件名】QRコード改札用乗車券販売サイト開発
【担当範囲】設計 / 開発 / テスト
【技術要素】開発:Laravel PHP / Lambda
環境:AWS(ECS/AuroraDB)
【主要要件】スマホから販売サイトにアクセスし、乗車券を購入する。乗車券はQRコードで表示し、改札のQRコードリーダにかざすことにより入場する。
課題

鉄道向けのソフト開発案件、購入したQRコードチケットを表示できなければ乗車できない事態となる。本案件においては、品質はもとより、品質を向上させるプロセスにおいても重要視される。

ここでは弊社における品質における考えかたやプロセスに関して、紹介も踏まえて考察する。
一言で品質をどう確保するか?との問いに関して、明確な答えはないと考える。局所的に品質を上げる手段を設けても、プロセス全体で統制が取れておかなければ、意味がない。

品質は、開発する企業独自のプロセスにおいて統制的に担保されるものと考える。

  • 上流工程
    特に要件定義・外部設計において、認識のずれ、検討漏れ、抜け等(以降エラーと呼ぶ)が発生すると、後工程に多大な影響が発生する。この段階で定義書のエラー抽出と是正は品質向上において最も重要なファクターとなる。レビュー是正処置だけでは拭えないエラーを如何に排除するかが大きな課題となる。
  • 下流工程
    実装においては、実装ミス・勘違いが必ず発生する。ミスするな!仕様を把握しろ!といっても、完全に払拭はできない。ツール(AIの活用が大きい)でそのリスクを軽減する手段はあるが、必ず起こるものとして構えないといけない。その上で、最終砦のテスト工程で確実に排除することが下流工程での課題となる。
解決方法

弊社での品質における考え方とプロセスを本開発にそのまま適応する。(他の開発も同様であるが。)
ここでは一部の紹介であるが、これらをメンバーの共通認識のもと一連の流れで自動的に行われるスキームを作ることが重要である。

上流工程

上流工程で発生するエラーを効果的に排除する方法として、本来は下流工程で実施するテストの一部(テストシナリオ作成)を、要件定義がある程度固まった段階で上流工程と並行して進める手法が有効である。これは大きなメリットをもたらす。

  • 要件の漏れや誤解の抑止:テスターがケースを抽出する段階での気づきが、要件の不足や勘違いの早期発見につながる。
  • テスターによる要件理解の浸透:本段階でテスターが要件を把握できるため、後工程での理解不足や詰め込み作業を防止できる。
  • 要件修正とケース修正の早期確立:要件の追加・是正が発生しても、是正処置の共有をフェーズを超えることがないため、その段階でケース修正のプロセスを確立できる。
  • レビュー効率:テストケースのレビューも上流工程の新鮮な状態で同時に実施できるため、レビュー効率が断然に向上する。
  • 工数削減:ある程度の同時並行で進めることで、後工程にかかる工数を大幅に抑制できる。

下流工程

下流工程で発生するエラーの排除については、各種ツールが大きな役割を果たす。特に近年はAIの活用により、生産性の向上のみならず、品質改善にも大きく寄与する可能性が高まっている。

  • 実装時のエラー排除:統合環境におけるコードの静的解析は依然として有効である。さらにAIによるコード補完は非常に有用であり、コーディング規約の遵守や実装の効率化に大きく貢献する。ただし最終的な判断はエンジニアの力量に依存するため、AIはあくまで支援的役割と位置づける必要がある。
  • 単体試験時のエラー排除:テストコードの実装とカバレッジの確認が基本となる。AI支援型のテストツールも登場しており、今後の活用によって効率性・網羅性の向上が期待される。
  • コードレビュー:特にローンチ後の機能追加において、コードレビューは極めて重要である。ISSUEやPRの管理とあわせ、リリース対象の差分をAIにも確認させることで、マージ前に潜在的な不具合を未然に防ぐことが可能となる。
  • テストケースの消化:最終的なエラー排除の「最後の砦」となる工程である。既に抽出されたテストケースについて、UIテストコードで自動化可能なものと、そうでないものを切り分けることが重要。自動化できない部分は、どのように品質を担保するかを明確にし、責任を持って対応する必要がある。

プロジェクト管理

プロジェクト管理において、品質管理はPMの最も重要な責務のひとつである。もし流出したバグを単に「エンジニアのミス」として片付けてしまうのであれば、そのプロジェクトは何も成長しない。バグの流出自体は好ましくないが、それを契機としてプロセスを是正し、改善へつなげる大きな機会と捉えるべきである。

  • フェーズ毎の品質担保:各フェーズにおいて、どの範囲まで品質を担保すべきかを明確化する必要がある。流出したバグについて「どの段階で防ぐべきだったのか」を議論することが、全体的な品質向上には不可欠である。
  • カンバンという箱の役割:カンバンは単なる進捗管理のツールにとどまらない。各カンバンの「枠」とISSUEという「箱」に明確な役割と責務を持たせるかどうかが、プロジェクト全体の品質管理における重要なポイントとなる。

成果

結果的な話になるが、運用上において大きな不具合は発生していない。これは発注元による厳格な品質テストの効果も大きい。
しかしここでは、不具合の「混入」と「流出」に焦点をあてておきたい。この2つを切り分けて捉えることで、再発防止策をより検討しやすくなるからである。
そして何より重要なのは、それぞれの「箱」に明確な役割と責務を持たせることである。これが品質管理における要点となる。

  • 混入
    不具合が開発プロセスに入り込むことを指す。カンバン上では「どの枠(フェーズ)のどの箱(タスク)で混入したのか」を捉えることが重要であり、その時点で何らかの不備や見落としが発生したことを意味する。
  • 流出
    混入した不具合が検出されず、最終的に実稼働環境まで到達することを指す。こちらも「どの枠・箱で検知できなかったのか」を明確にし、原因を特定することが求められる。
  • 再発防止・根絶
    混入と流出の両面に対して是正策を講じる必要がある。再発防止の観点からは、同様の混入や流出が再び発生していないかを継続的に確認する。根絶の観点からは、同じ要因による不具合を完全に取り除くことを目指す。

阿部 恭三

株式会社L's Craftsman代表
経済産業大臣登録 中小企業診断士
統括プロジェクトマネージャー

メーカーでのソフトウェア開発を通じて技術的な基盤を築き、20年以上にわたり、運用設計から品質管理まで一貫した IT サービスを提供できる総合的な技術力を保持。さらに、中小企業診断士の資格を有し、経営に近い立場での実務経験を重ねることで、経営計画の立案から事業の具現化・実行・成果達成まで、幅広い視点と高い実行力を兼ね備えている。

タイトルとURLをコピーしました