金融ソリューション事業部 事業推進ユニット の 石沢です。ソフトウェア開発者の皆さんは「横展開調査」「水平展開調査」「ヨコテン」などの言葉を聞いたことはありますか？ （本記事では以下「横展開調査」と記述します）
部門の勉強会で、改めて「横展開調査」について整理したので、本記事ではその内容をご紹介します。
所属部門ではわりとカジュアルに「横展開調査」という言葉がよく使われているのですが、人によって理解の幅に違いがあるようだったので、勉強会で取り扱ってみました。勉強会ではわかっている人、わかっていない人それぞれの理解の解像度が上がったようです。またよりよい方法についての議論も盛り上がりましたが、その内容はナイショです。
「横展開調査」ってなんだ？
本記事ではシステム開発におけるエラーや欠陥の「横展開調査」の話題について取り扱います。
- 製造業を中心とした生産技術における「横展開」（調査はつかない）という考え方もあるようです
- ややこしいのですが、トヨタ生産方式（TPS）では「ヨコテン（横展）」という独特のワードがあります（たぶん、カイゼンを組織に展開する情報共有プロセスのことです）
- さらにややこしいことに、TPSを参考にしたソフトウェア開発手法「リーン開発（プロセス）」というものがあるのですが、ここに逆輸入されて欧米では「Yokoten」というワードにもなっているようです
- なお、手元で調べた限りJSTQB/ISTQBやSQuBOKなどには「横展開調査」という言葉の定義はないようです
では「横展開調査」とは何なのでしょうか？ 改めて、次のように言語化しました。
「横展開調査とは、ソフトウェアの品質を効率よく向上させる手法である」
ソフトウェアにはエラー（欠陥）が含まれます。個々のエラーはレビューやテストを実施することで検出できますが、すべてのエラーをレビューやテストで検出すると膨大なコストがかかってしまいます。そこで、検出したエラーに類似する問題を（レビューやテストを省略して）調査することで発見することを横展開調査（または水平展開調査等）と呼びます。ポイントは、効率よく網羅的にエラーを検出することが目的だということです。
エラーの検出には手間がかかります。テストを実施し、結果を検証し、発生した想定外の事象を解析して、原因であるソフトウェアの問題がどこにあるかを特定しなければならないからです（め、めんどくせー！）。そういった手間を省略し、発見済のエラーの特徴に着目して、隠れている他の未発見エラーを（テストの前に）一網打尽にしたい。そのために実施するのが今回説明する「横展開調査」です。
「横展開調査」の2つの種類
大きく分けて「横展開調査」は2種類に分類できます（諸説あります）。それは「原因に対する横展開調査」と「真因に対する横展開調査」です。
「原因に対する横展開調査」
テスト等で検出したエラーの原因（コードの誤り等）の特徴に基づいて、同じような特徴をもつエラーを洗い出すのが「原因に対する横展開調査」です。もう少し丁寧に書くと「ソフトウェアのエラー原因に対する横展開調査」と言えばよいかもしれません。
ひとことでいえば
似たような間違い探し
ということになります
「真因に対する横展開調査」
ソフトウェアのエラーは（基本的に）人間によって埋め込まれます（だって人間だもの）。しかし、エラーを埋め込んだ理由を深掘りすることによって、同じような間違いが発見できるかもしれません。これが「真因に対する横展開調査」です。もう少し丁寧に書くと「ソフトウェアエラーの原因を埋め込んだ真の理由に対する横展開調査」というものになります。
例えばソフトウェアのエラーの埋め込み理由が「インプットとなる仕様ドキュメントの記述があいまい」であったとすれば、仕様ドキュメントの他の箇所にあいまいな記述がないか、そしてそこから展開されたコードは正しいかを疑うことによって、未検知のエラーが発見できるかもしれません。
ひとことでいえば
似たようなミス探し
と言えるかもしれません
「横展開調査」を実施する際の注意点
さて、横展開調査にはいくつか注意点があります。
効率よく網羅的にエラーを検出することが目的
横展開調査の目的は、効率の良いエラーの検出です。よって、他に効率的／網羅的なエラーの摘出方法があるのであれば、あえて横展開調査を実施すべきではありません。たとえば今後のテストによって類似エラーの網羅的な摘出が高い確率で確約できる場合や、アーキテクチャ上の制約で類似エラーが存在しないことを証明できる場合、横展開調査を実施することはむしろムダになります。やみくもに横展開調査をしてはいけません。
調査結果だけではなく、プロセスの検証も重要
横展開調査は、その結果だけではなく調査手法が正しいかについて注意を払ってレビューする必要があります。着目点の正しさと、実際の調査方法（対象と洗い出し方法、範囲）が間違っていると、エラーの検出漏れにつながります。最低限ピアレビューを実施するなどして、作業内容に問題がないかダブルチェックをするようにしましょう。
よくあるチェックポイントはこのようなものだと思います。
- 「原因に対する横展開調査」と「真因に対する横展開調査」共通
- 調査方針は妥当か（利用するツール、検索キーワード、フィルタリング方法などの使い方は正しい？）
- 調査の範囲は妥当か（エラーが含まれる可能性のある範囲を漏れなく調査しているか）
- 洗い出し結果に漏れはないか（意図した内容が洗い出されているか）
- 洗い出された結果に対する評価は妥当か（抽出結果に対して OK、NGの評価が正しく出来ているか）
- 「原因に対する横展開調査」のみ
- 調査の基点となったエラーは抽出されているか（最初に発見したエラーが見つかっていなければ、調査方法の正しさを疑う必要あり）
- 「真因に対する横展開調査」のみ
- 真因は妥当か（エラー埋め込み理由の推定の確からしさはあるか）
こういった点に注意することで、より効率的な成果が達成できるのではないでしょうか
おわりに
本記事では勉強会で実施した、システム開発におけるエラーの横展開調査についての整理をご紹介してみました。所属組織やプロジェクトによって言葉の定義や考え方は異なるかもしれませんが、参考にしていただければと思います。そこまでやるの？！という意見もあるかもしれませんが、プロジェクトの特性に合わせて考えていけばよいと思います。
最後までお読みいただきありがとうございました。
私たちは一緒に働いてくれる仲間を募集しています！
高い品質が要求されるミッションクリティカルなソフトウェア開発を一緒にやりませんか 【金融×IT】プロジェクトマネージャー 【金融×IT】システム アプリケーション・アーキテクト
執筆：Ishizawa Kento (@kent)、レビュー：@nagamatsu.yuji
（Shodoで執筆されました）
