アーカイブ動画
上流工程における“少しの手間”で、品質とコストを大きく改善
バルテス株式会社
テスト・アライアンス事業部 事業部長
石原 一宏氏
まず、石原氏はテストフェーズで不具合が発生した場合、その不具合が混入したフェーズに戻らなくてはならず、手戻りが多いという問題点について言及した。なお、スライドではウォーターフォールの問題点と書かれているが、アジャイル開発でも本質は同様だという。
PM/SEが開発で直面するお悩み例
- システム開発に関わるコストを減らしたい
- テストでバグが多いのでなんとかしたい
- 上流工程の品質が悪く、後工程を圧迫する
- テスト工程まで来てから手戻りが発生する
最小限のコストで開発を進めるポイントについては、「上流工程で“一手間”かけること」と、力強く結論を述べる石原氏。後工程にいけばいくほど、バグや問題が発生した際、指数関数的に修正に時間がかかると指摘した。
「後工程、下流のテストで不具合を見つければいいという考え方がそもそも間違っていますし、手痛いしっぺ返しを食うことをこれまで数多くの現場で経験してきました。テスト工程を前倒しする『シフトレフト』がポイントです」（石原氏）
一方で、上流工程で開発コストをかけることが難しいクライアント、プロジェクトもある。そこで、コストを減らす戦略として、以下の3つのポイントを挙げた。今回のテーマで「上流工程であいまない仕様をつぶす」について語られた。
上流工程であいまない仕様をつぶすにはどうしたらよいのか。石原氏は以下の3つのポイントを挙げる。
- 「見えない仕様」を可視化する
- 「できないこと」を考慮する
- 「図表」を活用する
「そもそもバグはどこで作り込まれるのか。各工程で不明瞭・曖昧なものが先の工程に伝搬していく際に生まれ、同時に拡大していきます。つまり、上流工程でできるだけバグが出なければ、その後の過程でも防ぐことができます」（石原氏）
だが、100％の仕様書を書くことは難しい。そもそも完璧な仕様書など、30年以上のキャリアを誇る石原氏でも見たことがないし、テストしなければいけない領域を100％と考えると、30％ほどの完成度であることが平均だという。
では、どのような仕様書を書けばよいのか。石原氏は6つのポイントを挙げた。いずれも多くの仕様書で見受けられる「ミスのパターン」である。中でも仕様書に書かれないことが多いのは「非機能系の考慮」であり、今回のテーマでも忘れてはならない点でもあると指摘する。というのも、仕様書や設計書で明確に書かれている機能については、実装工程やテスト工程でも配慮されるため不具合が少なくなるからである。
非機能系を含め、仕様書に書かれていないことは、開発者も含め上流工程で意識されにくいため、バグが発生しやすい。
しかし、ひと手間かけるという法則を知っているPMやSE、石原氏の言葉を借りれば「上手い人」は、下流工程で行うテストの発想で仕様書を書いている。「100％ではなく、何をテストするべきなのかを発想することが重要だ」と、石原氏は改めて強調した。
上流工程が原因で炎上した事例２選と対策ポイントを紹介
バルテス株式会社
エンタープライズ品質サービス事業部 東日本ソリューション部
金融ソリューションサービスグループ 副部長 畠山塁氏
【事例1】特定条件の仕様漏れをデシジョンテーブルで解決
一つ目は、ECモールにクーポンの機能を新たに実装し、クーポン対象を検索する機能も併せて実装した事例だ。
機能を実装後にテストを行ったところ、クーポン対象を検索したものの、対象となる商品がストアに1つもない場合にエラーが発生。検索機能が動作しないバグがあることが判明した。その結果、リリースは延期になった。
では、ここからが本題。上流工程のどこに気をつけておけばよかったのか。石原氏の言葉を借りれば、どこにひと手間かければよかったのだろうか。
「デシジョンテーブルが有効です。開発側はクーポンあり、つまり要件として提示された機能の前提で仕様を考えてしまうと、クーポンなしが、漏れやすいからです。デシジョンテーブルで可視化すれば、このようなヌケモレをなくすことができます」（畠山氏）
実際、デシジョンテーブルで可視化したところ、まさにクーポンなしの場合の挙動が漏れていることが分かった。
【事例2】「Must」「Never」で“できない”事象も可視化する
続いては、パソコンもしくはスマートフォン1台につき1アカウント契約とする、サブスクでの事例が紹介された。
パソコン2台での同時利用はできないことは、事前に仕様に盛り込まれており、実際に制御されていた。だが、パソコンとスマートフォンが同時にサービスを利用する仕様で、制御はできていなかった。
テストにより発覚したからよかったが、そのままリリースされていたら不正利用はもちろん、売上にも大きく影響した問題であったと、畠山氏は振り返る。
この対策については「Must」「Never」どちらも把握し、洗い出すことが重要だ。Mustとはできることが正しい。Neverはできないことが正しい、というロジックである。
「今回の例に当てはまれば、1台の端末でサービスを利用できるのがMustです。その上で考えられる動作を仕様に盛り込みます。Neverは複数端末の同時利用であり、今回のケースではまさにこちら、パソコンとスマートフォンの同時利用が漏れていました」（畠山氏）
実際にはMustもNeverもより多くのパターンがあり、その枝葉をすべて書き出すことで、抜け漏れている仕様を見つけ出していく。
見えない、気づいていない仕様を可視化するという点では、先のデシジョンテーブルと根本的には同じアプローチと言えるだろう。
さらには、先の6つのミスに陥りやすいパターンそれぞれに対しての、対処方法の一例も紹介された。
チャットなどを通じて、視聴者からの関心が高かった「非機能系」についても、ISO/IEC 25010のソフトウェア品質モデルのSQuaREを参考に挙げて詳しく解説。具体的には、非機能系の領域は広く、同モデルであれば、8個のカテゴリーのうち、機能系以外の７つすべてが非機能に当てはまると石原氏は語っている。
このように範囲が広いからこそ、抜け落ちないように品質のカテゴリーをテーブルにまとめて整理する、テンプレート化することが改めて大切なのだという。
同じく関心が高かったNever・Mustについては、次のように補足した。
「Must・Neverの考えはシステム全体だけでなく、機能・画面・モジュール単位でも活用できるなど、応用範囲が広いことも特徴。正常系のMust、異常系のNeverをセットで考えるクセをつけておくことが重要です」（石原氏）
【Q＆A】参加者からの質問に答えるセッション
視聴者からの質問に答えるQ＆Aセッションも設けられた。その一部を紹介する。
Q．デシジョンテーブルが大きくなり過ぎてしまう場合の対応法について
石原：条件をあれもこれも加えていくと、どうしても天文学的な数字になってしまいがちです。そこで、優先順位の高い要素から記載していきます。一方で、漏れた要素も明確に把握しておくことも重要です。
今回は○と△の条件で行うけれど、次回は漏れた要素で改めて作成する、といったことができるからです。テーブルを別にして行うのもひとつの対処法です。
一方で、1024マスぐらいのデシジョンテーブルであれば作成しますし、作成に3日ほど要しますが、その3日のおかげで手戻りの量が圧倒的に減る場合は迷わず作成します。
Q．充実した仕様作成が行えるようになる訓練方法があれば知りたい
石原：画面単位やメッセージボックスといった具合で、まずは小さな単位で考えること。3分程度の短い時間で考えることもポイントです。複数人で同じトレーニングを行い、作成した仕様書を見せ合う振り返りも重要です。
畠山：身近な事例でトレーニングするのも分かりやすいでしょう。例えば電子レンジを例にとればMustはタイマーが設定できることであり、Neverは途中でドアを開けたら運転が停止する、といった具合です。まずは、思考のクセをつけること。その上で他人と共有することで、さらなる観点も身につけていきます。
Q．逆に、品質の低いものができてしまった場合にはどうしたらいいか
石原：なぜ、品質が下がってしまったのかを考えるよりも、「たられば分析」がお勧め。「もしも○○があれば、不具合は起こらなかった」という観点で実際の製品で品質が下がってしまった原因を、あぶり出していきます。
Q．バグを叩きにいくコツがあれば教えてほしい
畠山：何が実現できればOKなのかを明確にします。そうすると優先度がつきますから、高い箇所から徹底的に叩いていきます。見つけ出す際も、Must、Neverの思考であぶり出していきます。
石原：テストは大きく分けて2種類あります。1つは品質保証型で、通常の使用では問題がないまでテストしていきます。もう1つは不具合検出型のテスト。バグの潜んでいそうなところを狙って、徹底的にバグを洗い出します。ただし、その際もリスクの高いところから行います。
たくさんのバグをあぶり出すには、対象となるソフトウェアやシステムの同じドメイン内での過去のバグが出た情報などを参考に、バグ多発地帯を把握します。その上で、テストを行うメンバーに周知するのが、PMの腕の見せどころでもあると思います。
バルテス株式会社
https://www.valtes.co.jp
バルテス株式会社の採用情報
https://www.valtes.co.jp/recruit/
関連するイベント
PM/SEのための上流工程戦略会議 ～「手戻りを減らし」「効率的に」「品質を上げる」には？～
2022/08/29（月）