NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'21 Kyushu
HOME > 活動報告 > イベント報告 > JaSST'21 Kyushu
2021年12月18日(土) 於 オンライン開催
JaSST'21 Kyusyuはオンラインで、福岡市天神からライブにより行われた。
司会を務めた実行委員の前畑氏によると「気温が5℃と雪が舞う中、運営スタッフは元気満点絶好調」とのことで、良い雰囲気を感じさせながら、実行委員長の松谷氏によるオープニングからシンポジウムが始まった。
積み重なったソフト、システム上の問題のことを指す。言葉は古くからあるものである。
古いシステム自体は決して悪いことではない。
使い慣れているため変えられると困る、という場面も少なくない。
古く、長く使っているシステムは機能を増やし続けていることで潜在的にバグが増えており、テストしきれない。
1976年に発表された『リーマン法則』におけるテストケースの話。
点と線でプログラムをモデルに描いた場合、プログラムの点を1つ増やすと、テストはどれだけ増えるか？
コード量の生産性は直線的に増えるが、テストは指数関数的に伸びる。
これらの管理について、コード量を変えずに適切な区切り方をするとテスト量は少なくて済む。
こうした分割統治、構造化設計といった考え方は一時期日本でも流行ったが、今は叫ばれていない。
最初に使ったのは1992年 Ward氏。
「コードを出荷することは借金するようなもの、危険なのは負債が返済されないこと、正しくないコードのために費やされた1分1秒が負債の利息として積み重なっていく」
毎日負債を返済する、ということをWard氏も言っているが、リファクタリングなど、コツコツやれているか？
システムを作った時は、ビジネス価値が最大になっているが、市場の変化は必ず起きるので下がってくる
↓
ビジネス価値に合致させるために機能が追加される
↓
保守性が下がる
↓
時間の経過にて再び機能が追加される
安直に速くリリースしようとするクイックFix、クイックリリースが中心だと上記の傾向になる。
経年劣化の話は、David L.Parnas氏により1994年の時点で既に叫ばれていた。
ソフトウェアエイジングによる問題、経年によって起きるバグ(ARB)は以下のようなものである。
『ソフトの老化』と言ってよい、これを管理していくには測ることが重要である。
経年劣化をどう測るか？
エイジングに対して測ることで気付かなければならない。
日本の社会では測定に関する文化の理解がなく(予算が出ない)、結果、知らぬ間に老けてしまった。
しかし今、ソフトウェアの若返り(リジュベネーション)が流行りつつある。
そもそもなぜ、技術的負債を考えなかったのか？
技術的負債を考えるとシステムは長持ちしてしまう ⇒長持ちされると困る、これはメーカー責任である。
ソフトウェアの長持ちを考えたチェックリストがあるか？
どうやっていけば経年劣化しないと言えるのかを考える。
2010年以降の技術の進化～DXの話が起きる際に、私たちが目指す長持ちのシステムとは何か。
レガシーモダナイゼーションはどんなものか、可視化した例から見ていく。
COBOLとアセンブラのコードが緊密に結び付きすぎたモジュール呼び出し図が、"ゴッホのひまわり"の絵のようなものになってしまった。
30年、部分最適化と機能追加を繰り返したようなシステムではよくある事象である。
サブシステムのコピペを繰り返すことで"カビきのこ"と呼ばれるモジュール構造図になった。
これでは入れ替えや、置き換えが困難になる。
結果、システムは塩漬けとされ、ブラックボックス化でコストが掛かってしまう。
経路のパスは意外にたいしたことがなく、30本に分割できるのに1本にまとめたがる。
本数が増えるのを嫌がった結果、こうなってしまった。
よく観察すること。
静的解析はデバッグツールとして結果を"なかったもの"にしてしまいがちだが、出した結果の分析をした方が良い。
例えば、欠陥種類数や欠陥数を見ると、コピーして作ったかが読み取れる。
コピーの繰り返しが経年劣化傾向になるが、これを無くすと"品質上のスリム化"になる。
内部構造をコール図などで出せるが、ここからどうすればいいかは思いつきにくい。
安定した"塊"は数学的に出すことができる。塊＝機能の単位、とすることもできる。
こうしたプログラムの数学的安定を探しながら分析するやり方があってもいい。
マイクロサービスの切り出しでは、業務的な観点でやる人が多いが、構造安定や長持ちできるかを数学的な回答を得てから考察する方が良い。
⇒ デザインセンスは凄くない、という前提でシステム設計をする。
人間の判断の前に、機械的なサポート(補助的なレコメンド)を受けるような世界に行かないと、レガシーなシステムは、システム移行や設計検討に何年も掛かってしまう。
フローチャートでものを考えなくてはいけない世界もある。
分割によってどう切り出せるか。
巨大なフローチャートを静的解析しているか？
水平な条件を統合できないか？
自分たちで内部がどれくらい複雑かをコツコツ追うこともせず、マイクロサービス化といった会話になってしまう。
システムの中を見ていく世界は面白い。
フローチャートや構造図に、類似した形状や共通化したロジックを見つけることもできる。
⇒ 隣接行列から類似度を求めるようなやり方で見つかる。
テキストマイニングや、コードを主成分分析してプログラムの種類を大別するなど、システムの中を歩けるよう可視化する世界を作りたい。
数学的、業務的な分析の前に、予備段階で数値データを取った方が良い。
医学の世界では検査データなしで所見を述べることはないのに、なぜかIT業界は属人的に進めてしまうシーンが少なくない。
技術面より文化面の方が問題だと思っている。
ルール、プロセスに起因する悪習が多い。
2000年代のIT開発は、コードの生産性を最大にするプロセスを考えた。
リーマンショック後、生産を増やしたいのか？と考えるようになった。
本当に必要なものだけを作れば生産量を抑えられる、と気付いた。
ところが、プロセスやルールを変えないまま、長持ちさせようとした。
昔の人達は、前のプロセスを変えたくない。
新しい技術が出てくれば、最適なものへテーラリングしなければならないのに、そうしたことをやりたがらない。
新しいパラダイムが出てきて、やっと品質に目を向け始めた。
それを好景気時代のルール、プロセスが阻んでいる。
いいものを、長持ちしたいものを作りたいならば、なぜこういう習慣があるのか？と疑問を持ちながら、経年劣化対策を丁寧にやっていくことが大事。
プロセスの世界においても、「習慣化する良いプラクティスは、長持ちに向いているか？」と頭に描きながら毎日を過ごすと良いシステム作りになるのではないか。
エンジニアリングの歴史は若い人が作る。ルール、プロセスを疑ってほしい。
その際は、2つのことを大事にする。
時代はそろそろ新しいアナーキストを求めている。
今までの鎖を断ち切って、歴史を築いてほしい。
テスターはプログラマー以上に勉強や工夫がいるが、それが報われる世界である。
これまで自分がソフトウェアやシステムを見ていたのは都合の良い一側面でしかなく、従来の分析手法を、視点を変えてコツコツ行うことで見えてくるものがあるのだと理解できた。
また、ルールやプロセスに疑問を持たずに受け入れている、この考えをアップデートすることこそが、技術的負債を返済していくための第一歩なのではないかと思った。
なぜか？ 自分が発表となると調べが必要になる。
日本に閉じこもらない。
何かの既存技術を極める。自分の軸を持つ。
⇒ 学習のスピードも上がる。
極めると先が見えるのでゴールがなくなる。
テストやマネジメントを分ける、同じものを見極める。そうしないとだんだん複雑になっていく。
"捨てる"ことができるのはマネージャの特権。分けて捨てることを考える。
正解を目指して失敗を恐れ委縮してしまうことがよくない。
やってみることが重要である。
開発者本人に、機能を使った業務のデモをしてもらうと「何のために」がわかる。
要求を開発者本人に自慢していただく場を作る。
自分がうまくいっているところは横展開する。
テストの仕方を4つのステップで説明する。
(1) 準備
バージョンを確認する：対向ソフトウェアも含める。
前工程の品質状況を確認する。
(2) 分析１
フィーチャーツリーを作る：特徴を木構造に分解する。
自分が説明できるレベルまで詳細化することで、テストが見えてくる。
テスト技法の前に、テスト対象の理解が先である。
(3) 分析２
テスト観点を追加していく。
テスト観点も分解し、詳細化し、繋げていく。
良いテスト観点を出すために、"良い"とはどういうことか、そのためにどうすべきかを考える。
(4) 設計実装
テスト技法を使いながら、どうやって効率化するかを考える。
テストケース表を作成する。
前半はテストエンジニアのキャリアを丁寧に説明頂き、自分の経験と照らし合わせて興味深く聴けた。
後半のテストの作り方については、テスト設計に至るまでのプロセスを具体的な形で聴くことができた。
総じて濃い内容だったが、新人テスターやキャリアが浅い方に向け公開された資料を展開したいと思った。
以下の4つの発表があった。
事前に基調講演と招待講演で内容の住み分けがされていたことで多方面から気付きがあり、約半日のイベントと思えない濃密さがあった。
また共通点の一つとして『面白さ』というワードがあった。
技術的負債の返済も、テストという仕事も、結果は面白さの捉え方次第で変わったものになるだろう。
あらためて自分がそこをどう捉えているか、振り返ってみたい。
記：堀川 透陽（ASTER）