HOME > 活動報告 > イベント報告 > JaSST'21 Kyushu

イベント報告
 ソフトウェアテストシンポジウム 2021 九州

2021年12月18日(土) 於 オンライン開催

ソフトウェアテストシンポジウム 2021 九州

オープニング

JaSST'21 Kyusyuはオンラインで、福岡市天神からライブにより行われた。
司会を務めた実行委員の前畑氏によると「気温が5℃と雪が舞う中、運営スタッフは元気満点絶好調」とのことで、良い雰囲気を感じさせながら、実行委員長の松谷氏によるオープニングからシンポジウムが始まった。

基調講演
「ソフトウェア産業の技術的負債と経年劣化について」
 細川 宣啓人 氏(日本IBM)

はじめに
  • 技術的なモダナイゼーションの未来を話したい
  • テストと品証との関係性については、技術の一片性として話したい
  • 歴史の中に色々なヒントがある
技術的負債とは

積み重なったソフト、システム上の問題のことを指す。言葉は古くからあるものである。

古いシステム自体は決して悪いことではない。
使い慣れているため変えられると困る、という場面も少なくない。

  • Windows 3.1(1985年)が数年前にイタリアでは現役で動いていた
  • フロッピーディスクが兵器の発射装置でまだ使われている
  • 1974年にOSの原型になったものの中の予約語(スペシャルワード)が、眠っていたコードとして2018年に発見された
    ⇒ 人命に関わると問題になってしまう、負の遺産である。

古く、長く使っているシステムは機能を増やし続けていることで潜在的にバグが増えており、テストしきれない。

歴史に学ぶ

1976年に発表された『リーマン法則』におけるテストケースの話。
点と線でプログラムをモデルに描いた場合、プログラムの点を1つ増やすと、テストはどれだけ増えるか?
コード量の生産性は直線的に増えるが、テストは指数関数的に伸びる。
これらの管理について、コード量を変えずに適切な区切り方をするとテスト量は少なくて済む。
こうした分割統治、構造化設計といった考え方は一時期日本でも流行ったが、今は叫ばれていない。

技術的負債という考え方

最初に使ったのは1992年 Ward氏。
「コードを出荷することは借金するようなもの、危険なのは負債が返済されないこと、正しくないコードのために費やされた1分1秒が負債の利息として積み重なっていく」

毎日負債を返済する、ということをWard氏も言っているが、リファクタリングなど、コツコツやれているか?

システムを作った時は、ビジネス価値が最大になっているが、市場の変化は必ず起きるので下がってくる
 ↓
ビジネス価値に合致させるために機能が追加される
 ↓
保守性が下がる
 ↓
時間の経過にて再び機能が追加される

安直に速くリリースしようとするクイックFix、クイックリリースが中心だと上記の傾向になる。
経年劣化の話は、David L.Parnas氏により1994年の時点で既に叫ばれていた。

ソフトウェアエイジングとは?

ソフトウェアエイジングによる問題、経年によって起きるバグ(ARB)は以下のようなものである。

  • メモリリークが突然起きる
  • ファイルロック
  • データ不整合
  • ログフルによるシステムダウン
  • 銀行ではよくある、切り捨てた1円単位の積み重ねで数千万円
    ⇒ 数値誤差の蓄積など

『ソフトの老化』と言ってよい、これを管理していくには測ることが重要である。

経年劣化をどう測るか?

  • 欠陥の多さ
  • 成長率
  • 変更した件数

エイジングに対して測ることで気付かなければならない。
日本の社会では測定に関する文化の理解がなく(予算が出ない)、結果、知らぬ間に老けてしまった。
しかし今、ソフトウェアの若返り(リジュベネーション)が流行りつつある。

そもそもなぜ、技術的負債を考えなかったのか?
技術的負債を考えるとシステムは長持ちしてしまう ⇒長持ちされると困る、これはメーカー責任である。
ソフトウェアの長持ちを考えたチェックリストがあるか?
どうやっていけば経年劣化しないと言えるのかを考える。

2010年以降の技術の進化~DXの話が起きる際に、私たちが目指す長持ちのシステムとは何か。

  • ビジネスの変化に早く対応できること
  • TAT(ターンアラウンドタイム)の時間が短いこと
  • 機能の追加・変化し続けられること
技術的負債を返済できない理由
  • エンジニアは機能追加や変更を"思い付き"でしてしまい、数学的に説明や証明せずに進めてしまいがちである
  • 習慣に関する問題も大きい
  • 冗長になればなるほどお金が掛かることを知らない
    ⇒ 文書化のコストは3~4割を占めたりする
  • 行動をしている際のスタンダードがない
    ⇒ 全員が優秀なエンジニアであるという原則で仕事をすることの怖さ
  • リファクタリングをしない
  • 外注化

レガシーモダナイゼーションはどんなものか、可視化した例から見ていく。

<ゴッホひまわり>

COBOLとアセンブラのコードが緊密に結び付きすぎたモジュール呼び出し図が、"ゴッホのひまわり"の絵のようなものになってしまった。
30年、部分最適化と機能追加を繰り返したようなシステムではよくある事象である。

<カビきのこ>

サブシステムのコピペを繰り返すことで"カビきのこ"と呼ばれるモジュール構造図になった。
これでは入れ替えや、置き換えが困難になる。
結果、システムは塩漬けとされ、ブラックボックス化でコストが掛かってしまう。

<一本17000行のコード>

経路のパスは意外にたいしたことがなく、30本に分割できるのに1本にまとめたがる。
本数が増えるのを嫌がった結果、こうなってしまった。

技術的負債の返済方法

よく観察すること。
静的解析はデバッグツールとして結果を"なかったもの"にしてしまいがちだが、出した結果の分析をした方が良い。
例えば、欠陥種類数や欠陥数を見ると、コピーして作ったかが読み取れる。
コピーの繰り返しが経年劣化傾向になるが、これを無くすと"品質上のスリム化"になる。

内部構造をコール図などで出せるが、ここからどうすればいいかは思いつきにくい。
安定した"塊"は数学的に出すことができる。塊=機能の単位、とすることもできる。
こうしたプログラムの数学的安定を探しながら分析するやり方があってもいい。

マイクロサービスの切り出しでは、業務的な観点でやる人が多いが、構造安定や長持ちできるかを数学的な回答を得てから考察する方が良い。
⇒ デザインセンスは凄くない、という前提でシステム設計をする。

人間の判断の前に、機械的なサポート(補助的なレコメンド)を受けるような世界に行かないと、レガシーなシステムは、システム移行や設計検討に何年も掛かってしまう。

フローチャートでものを考えなくてはいけない世界もある。
分割によってどう切り出せるか。
巨大なフローチャートを静的解析しているか?
水平な条件を統合できないか?
自分たちで内部がどれくらい複雑かをコツコツ追うこともせず、マイクロサービス化といった会話になってしまう。

システムの中を見ていく世界は面白い。

フローチャートや構造図に、類似した形状や共通化したロジックを見つけることもできる。
⇒ 隣接行列から類似度を求めるようなやり方で見つかる。

テキストマイニングや、コードを主成分分析してプログラムの種類を大別するなど、システムの中を歩けるよう可視化する世界を作りたい。

数学的、業務的な分析の前に、予備段階で数値データを取った方が良い。
医学の世界では検査データなしで所見を述べることはないのに、なぜかIT業界は属人的に進めてしまうシーンが少なくない。

技術的負債の最大の敵「悪習」

技術面より文化面の方が問題だと思っている。
ルール、プロセスに起因する悪習が多い。

2000年代のIT開発は、コードの生産性を最大にするプロセスを考えた。
リーマンショック後、生産を増やしたいのか?と考えるようになった。
本当に必要なものだけを作れば生産量を抑えられる、と気付いた。

ところが、プロセスやルールを変えないまま、長持ちさせようとした。

昔の人達は、前のプロセスを変えたくない。
新しい技術が出てくれば、最適なものへテーラリングしなければならないのに、そうしたことをやりたがらない。
新しいパラダイムが出てきて、やっと品質に目を向け始めた。
それを好景気時代のルール、プロセスが阻んでいる。

いいものを、長持ちしたいものを作りたいならば、なぜこういう習慣があるのか?と疑問を持ちながら、経年劣化対策を丁寧にやっていくことが大事。

プロセスの世界においても、「習慣化する良いプラクティスは、長持ちに向いているか?」と頭に描きながら毎日を過ごすと良いシステム作りになるのではないか。

エンジニアリングの歴史は若い人が作る。ルール、プロセスを疑ってほしい。
その際は、2つのことを大事にする。

  1. 対案が出せるなら出してほしい
  2. 作る時には、戻せるようにする

時代はそろそろ新しいアナーキストを求めている。
今までの鎖を断ち切って、歴史を築いてほしい。
テスターはプログラマー以上に勉強や工夫がいるが、それが報われる世界である。

筆者感想(全体)

これまで自分がソフトウェアやシステムを見ていたのは都合の良い一側面でしかなく、従来の分析手法を、視点を変えてコツコツ行うことで見えてくるものがあるのだと理解できた。
また、ルールやプロセスに疑問を持たずに受け入れている、この考えをアップデートすることこそが、技術的負債を返済していくための第一歩なのではないかと思った。

招待講演
「1番役に立った定番のソフトウェアテスト」
 秋山 浩一 氏(ソフトウェアテスト技術振興協会)

1. ゴールと道筋
初級者:JaSST nano で卒業

なぜか? 自分が発表となると調べが必要になる。

中級者:海外で発表を目指してほしい

日本に閉じこもらない。
何かの既存技術を極める。自分の軸を持つ。
⇒ 学習のスピードも上がる。

上級者:ゴールはない

極めると先が見えるのでゴールがなくなる。

【結論:1番役に立ったものは"層別"】

テストやマネジメントを分ける、同じものを見極める。そうしないとだんだん複雑になっていく。
"捨てる"ことができるのはマネージャの特権。分けて捨てることを考える。

2. 初級者(0~3年)の時に知っておきたかったこと
100点を目指さない

正解を目指して失敗を恐れ委縮してしまうことがよくない。
やってみることが重要である。

正しいことだけの蓄積
  • 間違ったことを覚えると直すのが大変。
  • 最近できた規格は良い。
  • 本とWebには間違いもあるため、頭から信じない。
仕事は面白いのが当たり前
  • 面白くない理由は"やっていないから"。
  • 「石の上にも三年」などと言うが、これは嘘である。
時間の浪費に気を付ける
  • トートロジーに騙されがち
    ⇒ 一段掘り下げて考える
  • テストだけに頼らず、皆で品質を上げる好循環なメカニズムを考える
3.中級者(4~9年)の時に知っておきたかったこと
知識を増やす
  • 『安心』と『信頼』の違い
  • 安心は新技術で無駄になってしまうこともある、お金も時間も掛かる
  • 信頼することを理解する
    ⇒ エビデンスといった証拠は信頼には必要ない
柱を持つ
  • CMMI:やることと価値が分けて書かれているのが良い
  • ソフトウェア工学
    ⇒ 考え方を理解した1つの柱を持つと、他の理解にも繋がる
ゼロをイチにする心掛け
  • チャレンジ:ゼロのことに取り組む勇気を持つ
  • 英語は読み、新しい知識に触れる
  • TPI NEXTのアセスメントで0点だった1つをやってみる 
  • 健康一番:健康に良いことを始めてほしい
  • 過剰コミュニケーション:自分より上(20歳くらい上とか)の人や新人と積極的に行う
自信を持つ
  • 自分の能力を信じる
  • 褒められた時も自虐は言わず、ストレスを溜めない。
  • "つよつよエンジニア"と呼ばれる人も好きなことを続けてきた結果、そうなっている
4. 上級者(10年~)に知っておいてほしいこと
芯を外さない
  • 無駄な仕事をしていると感じたら、止めたらどうなるだろうと考える
  • 好循環・悪循環なメカニズムを探す
    悪循環は一つのポイントを変えるだけで全部が変わることもある。
  • 皆が楽しくなること、を考える
  • 皆が生き生きと働けるようなことを考える
  • 上手くいってない場合の対処:間隔を短く刻み問題点を見つけて直していく
他部署との調整

開発者本人に、機能を使った業務のデモをしてもらうと「何のために」がわかる。
要求を開発者本人に自慢していただく場を作る。

サイロになるな!

自分がうまくいっているところは横展開する。

おすすめのテストの作り方

テストの仕方を4つのステップで説明する。

(1) 準備

バージョンを確認する:対向ソフトウェアも含める。
前工程の品質状況を確認する。

(2) 分析1

フィーチャーツリーを作る:特徴を木構造に分解する。
自分が説明できるレベルまで詳細化することで、テストが見えてくる。
テスト技法の前に、テスト対象の理解が先である。

(3) 分析2

テスト観点を追加していく。
テスト観点も分解し、詳細化し、繋げていく。
良いテスト観点を出すために、"良い"とはどういうことか、そのためにどうすべきかを考える。

(4) 設計実装

テスト技法を使いながら、どうやって効率化するかを考える。

テストケース表を作成する。

  • あいまいな書き方はしない。作成者の思い込みが入ってしまう
  • "任意な値"の書き方:本当に任意なら具体的に書いた方がいい
  • "異常な値"の書き方:実行する時に考えさせるのでなく、テストケース表でタイミングなどを記載しておく
筆者感想

前半はテストエンジニアのキャリアを丁寧に説明頂き、自分の経験と照らし合わせて興味深く聴けた。
後半のテストの作り方については、テスト設計に至るまでのプロセスを具体的な形で聴くことができた。
総じて濃い内容だったが、新人テスターやキャリアが浅い方に向け公開された資料を展開したいと思った。

ライトニングトークス

以下の4つの発表があった。

  • 「VSTePのテスト観点出しで失敗した事例についての紹介」
  • 「テスト活動におけるコミュニケーション戦略の研究~キックオフのベストプラクティス」
  • 「Apple Silicon Mac + Rosetta 2 + Dockerで arm64(aarch64)/x86_64 とmacOS/Linuxの組み合わせで自動テストする方法(Elixirだけじゃなく汎用の方法も紹介するよ)」
  • 「テストコードのないレガシーアプリケーションとの向き合い方」
筆者感想(全体)

事前に基調講演と招待講演で内容の住み分けがされていたことで多方面から気付きがあり、約半日のイベントと思えない濃密さがあった。
また共通点の一つとして『面白さ』というワードがあった。
技術的負債の返済も、テストという仕事も、結果は面白さの捉え方次第で変わったものになるだろう。
あらためて自分がそこをどう捉えているか、振り返ってみたい。

記:堀川 透陽(ASTER)

[ページトップへ]