NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'21 Shikoku

Opening

実行委員長の高木氏より冒頭、2008年から四国においてJaSSTを実施していて、例年であれば香川大学のキャンパスを借りて実施していたと挨拶があった。昨今は、オンラインでの開催となっている。学生向けには、初心者プログラムで学習してほしいという思いもあるとのこと。
参加人数は、約100名であり、うち学生は、17名で大盛会である。

講演1
「質とスピード（2021秋版）～ソフトウェア開発の典型的な誤解を解く～」
　和田 卓人　氏（タワーズ・クエスト）

はじめに和田氏から「質とスピード」は、トレードオフにあるとみなさんは思っている。私は、新人研修も実施していて、新人のエンジニアもそのように思っており、そこに切り込んでいく講演である。
私は、テストドリブン開発を15年やっていると自己紹介があり、講演が始まった。

概要

ソフトウェア開発は、与えられた時間に対してやるべきことが多すぎる場合があり、スコープを削ったり、人を増やしたり、リリース日を延期したり、品質を犠牲にしたりすることがある。和田氏は、「私たちは、なぜ、品質を犠牲にして先を急いでしまうのか」を問い、「私たちが内部品質を犠牲にして、先を急いでしまうことでどのようなことが発生するのか」を説明している。

１．品質を犠牲にすればスピードは得られる？

品質を犠牲にして先を急ごうとする雑な選択をわれわれがした時どうなるのか。
G.Mワインバーグは、「品質とは誰かにとっての価値である」と言っている。
有名なところでは狩野モデルがある。物理的な充足度と顧客の満足度で顧客が求める品質を当たり前品質、魅力品質、一元的品質に分けている。
SQuaREの品質モデルでは、内部品質、外部品質という用語が出てくる。外部品質は、例えば、Usability,Efficiencyなどであり、内部品質は、Maitainability,Flexibilityなどがある。
われわれは、内部品質と外部品質があるが内部品質を犠牲にして先を急ごうとしてしまう。なぜなら、内部品質を犠牲にする場合は、開発チームでやっていて調整コストが少なくて済むからである。外部品質を犠牲にする場合は、外部の人への責任説明も発生し、調整コストがかかるからである。

２．「内部品質とスピード」

和田氏は、「質とスピード」は言い換えれば、「内部品質とスピード」のことであり、どのような内部品質を犠牲にしているのかを説明した。
和田氏は、23の品質構造（出展:Boehm, Brown, and Lipow's 23 Quality Characteristics (1976) https://www.thomasalspaugh.org/pub/fnd/ility.html）に含まれる保守性を犠牲にしていると言い切っている。保守性を構成するものは、テスト容易性、理解容易性、変更容易性である。例えば、ソフトウェア開発の現場で「テストコードを書かないで先を急ごう」、「ドキュメントを書かずに先に進もう」、「コピーアンドペーストでゴリゴリとコードを書いてしまうと同じようなコードが複数の箇所で書かれてしまう」。というようなことが発生する。
つまり、内部品質を犠牲にしているということは、保守性を犠牲にしているということである。「内部品質とスピード」は、「保守性とスピード」ということになる。

３．「保守性とスピード」

参考図書：「Clean Architecture 達人に学ぶソフトウェアの構造と設計」

ロバート.C.マーティン氏は、「現場は、コードをクリーンにすることを後回しにして市場に出してしまう。あとでクリーンにすればいいよ。と現場は、言ってしまう。」と書いている。
ここでクリーンにすることを後回しにした現場は、保守性が悪いためコード解析が終わらず、変更箇所を調べるのに時間がかかったり、修正の影響が予想外のところに出たり、ひとつひとつの変更に余計な時間がかかってしまうことになる。つまり、保守性を犠牲にすれば短期的にはスピードは得られるが、中期的には逆効果になり、長期的には致命傷になる、と和田氏は説明した。

４．スピードを落とせば保守性は上がる？スピードから質への影響はどうか？

それでは、スピードを落とせば、保守性は上がるのか？という問いについては、技術力がある人は、一定以上の品質のコードを書くし、逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質を保ったコードは書けない。保守性（品質）とスピードは、トレードオフではない。スピードを落としても保守性（品質）は上がるわけではない、と和田氏は力説する。
参考図書：「レガシーコードからの脱却―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」では、開発者のレベルが高い場合＝速く開発するプログラマーは、雑なプログラマーだと考えていた。それは、間違っていて、コードを扱いやすいように保つことに特に注意を払っていた。と記載されていてコードの品質を高く保っていた「からこそ」スピードが速いということになる。
品質が悪いと基本的に手戻りを生むのでスピードに跳ね返り、手戻り時間は学びを生まない時間となる。スピードを上げると仮設検証のスピードを上げられるため早く市場にリリースしていくことができる。
良いものを作れば売れるというわけではないが内部品質がスピードを生み、スピードが学びのループを生む。学びのループは外部品質を生み、競争力を生み、売上を生む。そして、サイクルとして売上が内部品質を育むことになる。

５.さいごに

和田氏は、再度、保守性を犠牲にすればスピードを得られるのか？を問うた。短期的にはスピードは、得られるが、１か月後には逆効果になり、長期的には致命傷になると説明した。品質とスピードについてのトレードオフが意識されるとき、プロジェクト全体の品質とスピードが天秤にかけられている。言い換えれば、プロジェクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が天秤にかけられているのではないかと思うと締めくくった。

質疑応答

Q:

「品質とスピード」は、損得や苦楽の問題であることと頭では理解できていても実践していくのは勇気が必要。周りを巻き込んでいくプラクティスなどあるでしょうか。特に偉い人を巻き込んでいく場合。

A:

事例を集めて理論武装し、もうみんなやっていると偉い人を動かす。変えない理由を説明するということを依頼する。(JaSST'20 新潟（https://jasst.jp/symposium/jasst20niigata/report.html）で講演した内容を参照してほしい。)

Q:

内部品質の意識を高めるために参考になる書籍はあるか。

A:

「LeanとDevOpsの科学」、「レガシーコードからの脱却―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」など本講演の中で引用している本が参考になる。

Q:

崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅いというお話がありましたが考える時間も含むのか。

A:

認知負荷が高いコードは、短期記憶におさまらないため、時間がかかり、考えることになる。考える時間も含む。

Q:

自動車業界ではソフトウェアリリーススパンが長い。環境的にプロダクトのソフトウェア開発がローパフォーマンスになってしまう可能性は考えられるか。

A:

アーキテクチャのほうが影響する。SoE、組み込みというところは関係しない。

筆者感想

私は、JaSST北陸実行委員を担当しており、2021年6月にJaSST'20九州の和田氏の「質とスピード」の講演資料を確認していた。私自身も、随分、過去にはなるが「品質をないがしろにし、スピードを優先し、その後のコストがかかってしまった。」経験があり、反省している。
本講演で「質とスピード」のメカニズムを理解し、今後の品質を上げる活動に活用していきたいと考え、受講させていただいた。私自身が実施する社内研修では、「品質とコストは、トレードオフであり、どこまで品質保証するのか。」といった問いかけをすることがあったがそうではないということを本講演で知った。これからは、改めていきたい。また、「手戻り時間は学びを生まない時間となる。」というのが本講演で大きく響いた。保守性について品質メトリクスでどのようにすれば良いのかを考えていきたい。

講演2
「レビューのキキメ～Part2「レビューの成功要因」はどの程度のキキメがあるの？」
　安達 賢二　氏（Software Quasol@HBA）

はじめに安達氏から自己紹介があった。
2016年に高松にレビューのワークショップでお邪魔した。
JaSST'19 新潟（https://jasst.jp/symposium/jasst19niigata/report.html）でレビューのキキメを講演したため、今回は、Part2とした。
企画、営業、チームのパフォーマンスを上げるための仕事をしていると前置きし、講演が始まった。

概要

テスト技術者資格制度Foundation Levelシラバス（http://jstqb.jp/syllabus.html）に掲載されている「レビューを成功させるための組織的な要因」と「人的な要因」がレビューの問題構造を本当に解決するのか。Foundation Levelシラバスを実際に検証してみるという内容である。具体的には、①レビュープロセス、②レビューの効果図式、③レビュー成功のためのシナリオにマッピングすることによりレビューを成功させるための要因を検証している。レビューの成功とは何かがぼけていることがあるため、その点についても説明する。

１．「レビューを成功させるための組織的な要因」と「人的な要因」

「レビューを成功させるための組織的な要因」と「人的な要因」は、テスト技術者資格制度Foundation Levelシラバス（http://jstqb.jp/syllabus.html）を確認してほしい。
安達氏は、テスト技術者資格制度Foundation Levelシラバスに掲載されているレビュータイプとレビュー技法について説明した。そして、その中でパースペクティブベースドリーディングは、役割でレビューするロールベースと、何かを作ってみるということが含まれると説明した。

２．レビュープロセス上に成功要因をマッピングした場合

レビューの計画においては、目的を定義し、適切なレビュー技法、レビュータイプを選択する。そして、適切な要員を計画するが成功要因である。
レビューの開始においては、開始基準を決め、高度なレビュータイプへトレーニングを提供する。
個々のレビューにおいては、十分な準備時間や適切な時間割当による詳細なレビューをする。
これらのことをマッピングしてみた。

３．レビュー問題構造

安達氏は、2009年から全国各地で収集したレビューの困り事、問題点との関係性を分析した。
（関係性分析（因果関係の作成方法）は、JaSST'19 北陸（https://www.jasst.jp/symposium/jasst19hokuriku/report.html）そのレビュー、大丈夫ですか？～ 現状レビューの問題発見・解決 を参照してほしい。）
レビューの効果図式とレビュー成功のためのシナリオ例をマッピングしている。
さらに安達氏は、レビュー成功のためのシナリオ例にレビューの成功要因をマッピングし、レビューの成功要因がシナリオ例に効果的かを点数で評価している。結果、67点/100点となった。7割くらいは、われわれが抱えているレビューの問題点を、「レビューの成功要因」はカバーできているということになると説明した。
では、カバーできていないところは、どの成功要因なのか。安達氏は、レビューの対象となる対象物が和田氏の講演にもあったように保守性の悪い書き方だとレビューのパフォーマンスが落ちると力説した。レビューのパフォーマンスは、実験でも裏付けられているがレビューの仕方のみならず、インプットの品質がとても影響を与えることになる。

４．レビューの成功に最も外せない要因

レビューの対象物が変わっているのに毎回同じレビューをしているというのが多いとのこと。レビューの対象物やリスクなど鑑み、レビューを変えることが重要である。
みなさんは、レビューの成功に最も重要で外せない要因は、どれか？これを考えることがわれわれにとってなぜ、レビューが必要なのかというところでとても重要になる。
JaSST'16 東京（https://www.jasst.jp/symposium/jasst16tokyo/report.html）の事例発表「レビュー目的・観点設定の効果と課題」で安達氏は、分析している。レビューの指摘の質と量が伴わないと、レビューアはレビューへのモチベーションも上がらず、レビューで何を確認しないといけないのかというところに影響が出てしまう。ということである。

５．レビュー観点導出アプローチ

レビューの準備においては、レビュー観点図を作っておくと良い。テスト設計チュートリアル　テスコン編資料（講義編）を参照してみてほしい。観点設定優先度（おおまかな方針）を決めておくと良い。安達氏は、和田氏の講演にもあったように内部品質が満足すると外部品質が満たされると説明した。観点の関係性も決めておくと良い。
また、保守性が悪いと競争力が低下してしまう。改修スピードが鈍り、お客様もオーナー企業も不幸になってしまうのである。レビューメタ観点図活用イメージで要求仕様書のレビューをどのようにするかを説明しているのでぜひ、みなさん参考にしてみていただきたい、と安達氏は説明した。

６．さいごに　レビューパフォーマンス改善とレビューファーストによるシフトレフト

テストファーストがあるようにレビューファーストで手戻りを防ぐ。例えば、5ページの資料が完成したら、すぐにレビューし、注意事項の改善をしていく、ということである。レビューとテストの協調と連携でQAをかけていくと良い。
さいごにいつも同じやり方で、ぼんやり何となく実施する、参加するのが辛い、効果が実感できない、このようなレビューから脱却してみんなで価値あるシステム／ソフトウェアを世に送り出しましょう！と安達氏は、熱いメッセージで締めくくった。

質疑応答

Q:

レビューにおけるファシリテータの評価や育成等のアドバイスをお願いしたい。

A:

育成は、いろいろあるが評価はない。トレーニングはご紹介できる。

Q:

心理的安全性は、要素としても入るのか。（攻撃的なレビューはしばしば悩まされる）

A:

信頼できる雰囲気は、とても重要。

筆者感想

JaSST北陸初開催の時に、安達氏には講演いただいた。個人的にテストの前のレビューで、まずは、品質を作り込んでいくことをしていきたく、レビューとテストの両方の講演をテーマとして実行委員としても取り組んでいる。安達氏がどのように「レビュー成功要因」のキキメにアプローチするのか、ワクワク感でいっぱいであった。
私たちが実践しなければいけないことは、安達氏が見える化したマッピングや点数化したレビューの成功要因の効果を活用し、成功するレビューである。今後、本講演の内容を整理し、活用していきたい。

Closing

実行委員の大場氏から閉会の挨拶があった。
和田氏の講演からこれまでテストというと外部品質をみることが多く、内部品質をみることが少ない。質のいいコードを作る、について理解した。
安達氏の講演から現場にいると同じようなやり方、役割でレビューしている。（そこを変えていかないといけない。）
他の地域のJaSSTにも参加してみて下さい。と締めくくった。

筆者感想（全体）

プログラム構成は、２講演と参加しやすく、説明を聞きながら、とても理解しやすい内容であった。私も含め、受講されたみなさんには、多くの気づきがあったのではないだろうか。私は、和田氏と安達氏に教わったことを今までは深く考えてこなかったシステム開発の一部のタスクに対して新しいアセットに仕立てて活用していきたいと考える。