日本取引所グループシステム部門の取組み

～システムトラブルからの学びと今後の挑戦～

株式会社日本取引所グループ（JPX）が運営する取引所ビジネスは装置産業であり、ビジネスとITは不可分の関係性にあります。
今回の講演では、安定的なマーケットインフラを提供するために、JPXが「発注者」の立場から行ってきた様々な取組みをご説明すると共に、システムトラブルを契機に開始した「独自のシステム開発能力、設計監理力、保守運用力をさらに高めるため」の取組みついてご紹介させていただきます。

組織的にシステムテスト自動化を推進する体制の構築

昨今、ソフトウェア開発サイクルが短くなり、ソフトウェアテストにおいても、スピード、正確性、および費用対効果を求められている。弊社では、従来の手動テストだけでは品質の維持および時間効率に課題があるため、システムテストの自動化を進めている。

しかしテスト自動化は製品個別で推進されるため、担当者の力量に左右される傾向が大きい。そのため、①テスト自動化の活動が継続しない、②重複した検討作業を行い非効率、③自動化の推進に消極的、といった問題を抱えていた。

このような属人的な状況を打破するためには、組織的にテスト自動化に取り組む必要があると考えた。まずは、部門としてテスト自動化戦略を作成し、組織としてのテスト自動化の実現を目標として掲げた。加えて、テスト自動化の普及および定着を実現するための実行部隊としてWorking Groupを結成し活動を推進した。

【主な活動】

• テスト自動化する目的の共有、およびコミットメント
• テスト自動化ツールの検討、導入
• 得られたノウハウの蓄積、共有　など

この活動により、現在も継続的にテスト自動化の成果を出しつづけている。
今回の発表では、自動化を推進するためにやったこと、およびそこから得られたテスト自動化のノウハウを共有する。

失敗から学ぶ自動テストの設計プロセス

自動テストは開発スタイルや要望、取り巻く環境の変化で、市場ニーズは高まっており、導入を試みた人は多いですが、定着したプロジェクトは一部です。
失敗したプロジェクトを見てみるとどの現場もほぼ同じ要因で失敗していることが多いです。

数々の現場を分析したところ、３つ失敗の分類に分けることができます。

• 「実装スキル」の失敗(→必要な試験が自動化できない)
• 「進め方(プロセス)」の失敗(→手戻りが多く進まない)
• 「人・組織」の失敗(→チームの意見が纏まらない)

今回この中で導入に影響する内容は「進め方(プロセス)」の失敗になります。
その導入プロセスを以下の４つに分類分けしました。

1. ①計画　　　：自動化の方針を決める
2. ②設計　　　：自動化の内容、処理構成を決める
3. ③実施　　　：スクリプト作成、実行確認
4. ④振り返り　：実績検証と改善

このプロセスに従って進めることでリスク/失敗を回避し成功率を高めることができると考えます。
各プロセスの説明には実際にあった現場の失敗を交えて説明します。

個人の見解になりますが自動テストの成功基準を以下のように考えています。

• 1回の実行で手動に比べ最低３０％以上の効率化/工数削減ができる
• 必要なテストが自動化できている
• 数百件のシナリオが連続で実行出来る
• 誤判定などなく全て正しく実行出来る
• 実行から結果確認まで人間の手を入れずに最後まで実行出来る
• メンテナンスやリスクの対策済み

この成功基準を満たせる自動テストの導入プロセスを説明します。

状態遷移モデルの一部が明示されていない場合における
自動テスト生成手法

本発表では、昨今のソフトウェア開発における規模の増大や短納期化に対応するため、品質担保の効率化に有効である、状態遷移に関する自動テスト生成手法について提案する。
システム開発において、ユーザが直接操作するアプリケーション（以下、アプリ）は仕様変更が頻発する。そのため、設計ドキュメントへの記載は最小限に留め、頻繁に修正が必要な状態遷移図は記述しないことがある。
その場合、アプリの状態遷移モデルが明示されていないため、入力に対する期待動作を機械的に記述できないことから、アプリの状態遷移テストを自動生成することは難しい。
そこで、複数アプリの共通機能である、アプリケーションフレームワーク（以下、フレームワーク）に着目した。アプリ開発者への情報提供の観点からフレームワークの状態遷移モデルは明示されていることが期待できる。従って、フレームワークの状態遷移モデルが常に満たすべき性質を記述することにより、アプリの状態遷移テストの成否を判断する方法を検討した。
また、テストケースについても、フレームワークの状態遷移モデルを活用することで、不具合を効率的に発見するためのテストケースの生成方法についても検討した。
以上、状態遷移モデルが部分的に明示されていない場合における状態遷移テストを自動生成する方法について検討した内容に対して、実験を行い検証したので、その結果について報告する。

ODC分析実践の2つの壁を乗越える取り組み

開発現場で現状品質をどう捉えるか、悩みを持たれている方は多いと思う。バグ分析の一手法であるODC分析が非常に役に立つので、ODC研究会では、ODC分析を広めため基礎的な活動を行ってきた。しかし、ODC分析を現場に展開しようとしている人、やってみて悩んでいる人から、「思うようにうまくいかない」という声を聞いている。このことを打破しようと昨年、実践的ワークショップを行った。
そこには２つの壁がある。１つは分類を正しく行うこと、２つ目はどう分析するかである。
それらを乗り越えるために行ったこととは、実際のバグ情報を使うこと。経験者と議論すること。分類と分析を繰り返すことです。
これらを実際どう行ったか、どんなことが分析分類のコツだったのか、そしてどんな成果があったか、を発表します。

ODC分析を導入する際のハードルを下げた取り組み事例

ソフトウェアの欠陥分析には統計的手法や根本原因分析などの手法が用いられるが、ソフトウェア品質の可視化については解決できていない。
ソフトウェア品質の可視化の効果が実証されている手法としてODC分析があるが、導入にはいくつかの障壁がある。
ODC分析の導入を検討している、または導入したが壁にぶち当たっている開発者たちが、組織の壁を越えて事例を研究する機会があり、成功事例や失敗事例から導入障壁について調査した。
その結果以下のことがわかった。

• 既存の不具合管理システムにはODC分析に必要な情報を入力する仕組みがない
• ODC分析の精度に直結する、正しい属性情報付与の知識がない
• ステークホルダーにODC分析の効果を説明することが難しい

これらの導入障壁を解消する取り組みとして、以下の2つの組織に対して各アプローチを実施した。

• ■ODC分析の有識者が不在、環境準備も完了していない状況で導入を決定した（組織A）。
  ⇒既存の不具合管理票の未使用フィールドの活用や入力ルールを適用
• ■ODC分析の有識者はいるが、導入に対して開発者の協力を得にくい状況である（組織B）。
  ⇒ODC分析の属性に変換する「読み替え表」を適用

本発表では、ODC分析導入の敷居を下げるアプローチや使用したツールおよびその結果から得られた知見について紹介する。

サービス特性観点でのサービス品質指標の明確化
およびサービス品質の見える化

弊社では社会課題の解決に貢献するため、人とITによる各種サービス（クラウド、データセンタ、運用・監視、コンタクトセンタ、BPOなど）を提供している。サービスはモノとは異なり目に見えにくい特性（無形性）を持つため、何らかの方法でサービスを見える化し、定量的な品質評価を行うことが課題であった。
サービス品質に問題があるのか否かは、見えにくい状態のままでは確認することが困難な為、サービス品質の『指標』を定義し、上流工程である企画フェーズから提供後の運用フェーズまで全範囲に指標を導入した。そして、指標の測定結果を各フェーズで評価することでサービス品質の見える化を図った。
本発表ではサービスの品質を各種指標により可視化し、高品質なサービスを継続的に提供するために立案、推進した品質確保施策について報告する。また、本施策を適用したプロジェクトの事例と過去発生した事故への適用シミュレーションによる効果測定の結果についても報告する。

ウォーターフォール開発が浸透した組織へのアジャイル開発導入

弊社では請負受注型のウォーターフォール開発を生業としてきた。しかしながら、市場要求の変化が激しくなり、ウォーターフォール開発では市場変化に追いつけず、当初必要と判断し開発した機能がソフトウェアリリース時には必要とされていなかったり、実際には一度も使われなかったりすることがある。そのような変化への対応力をつけるためにアジャイル開発の導入を検討し、昨年度からアジャイル開発推進部門としてアジャイル開発環境の整備、全事業部へのアジャイル開発情報発信や支援提案活動を開始した。しかしながらウォーターフォール開発が根付いた組織に対してアジャイル開発を導入することは一筋縄ではいかず、以下のような問題が浮上した。

• 問題１：ウォーターフォール開発を主軸としてきたためアジャイル開発の知識・ノウハウが無い。
• 問題２：プロセスに沿った開発に慣れているため、受動的な考え方や行動になる。
• 問題３：ウォーターフォール開発で愚直にやってきた実績があるため、強いこだわりがあり変革を受け入れにくい体質になっている。

これらの問題を解消するためにどのような試行錯誤を行ってきたか取り組んだ内容について紹介する。

アジャイル開発の生産性とは

〜リードタイムのメトリクスを3階層に分けることで見えた生産性の指標〜

アジャイル開発を成功させるには、限られた予算の中で、イテレーティブさを保ちながらユーザー価値を提供する開発プロセスが必要となってくる。プロセスの中で「何を証明したいのか」を仮説として考える。施策を実行する中においては、できるだけ速く機能開発を行い、ユーザーフィードバックをもとに、どれだけ柔軟に対応できるかが、とりわけ求められる。
そこで、よくボトルネックとなるのは、リードタイムの問題である。
「開発が遅くてリリースができない」「組織内の承認がおりず、手戻りが発生した」等の問題に対して、どこに問題の根源があるのか、何に時間がかかっているのかの詳細な洗い出しが困難な現場が多い。または、それらの問題に対して定量的ではなく定性的で感覚的な意思決定を下すことも多い。
本研究では、それらのリードタイムの可視化難化について、定量的であり且つチームに伝えやすい粒度で改善が進むように可視化するアプローチを行った。また、そこから派生する形で、リードタイムを可視化するだけではなく、アジャイル開発における生産性の指標についても見えてきた部分があるのでご紹介できればと思う。

MicroService, AIによる
エッジデバイス判定システムの品質向上

当社では、原価低減・品質向上を目的に、自動車部品製造工程における目視外観検査の自動化を推進している。従来、外観検査システムは対象に応じた専用システムを個別開発しており、横展開拡大には以下の課題がある。

• ルールベース判定ロジックは構築に時間を要し、環境に応じた判定精度の維持管理が難しい。また特定のケースではその構築自体が困難である。
• モノリシックなシステム構成のため一部を改修すると他の機能に影響が及び予期せぬトラブルが発生する。
• 開発と運用の環境不一致により、運用時に想定外のトラブルが発生する。加えて、バージョン管理ミス等の人為的ミスが生じやすい。

そこで当社では、「ソフトウェアからくり」をコンセプトに、コンテナを中心とした技術を活用したマイクロサービスによるAI判定システムを構築し、エッジデバイスに実装した。これにより、工場からくり改善のパーツのようにAI判定モデル等のコンテナ化されたソフトウェアパーツを組み合わせ、検査対象に応じたシステムを柔軟に構築可能となった。また、DevOpsに基づく開発手法を取り入れることで、AI判定モデルを含めたサービスの更新を迅速かつ自動に行えるようになり、システムの信頼性向上と判定精度の維持管理を容易にした。
本発表では、これらの考え方を外観検査システム開発に取り入れ適用した際の要点として、システム構成・使用ツール・フレームワーク等を紹介する。

メタモデルによる設計情報定義を活用した
トレーサビリティ記録方式の提案

ソフトウェア開発において、段階的に進む開発の一貫性を担保し、製品の品質保証や安全性確保のためにトレーサビリティ管理が広く用いられている。トレーサビリティ管理により、設計・検証の抜け漏れ確認による不具合予防が期待できる。この効果を最大限享受するには、設計と同時進行でトレース情報記録することが重要である。しかし、度重なる設計変更が発生する現場では、トレース情報記録にかかるコストのため、開発後にまとめてトレース情報記録しているのが実情であった。
本発表では、度重なる設計変更が発生する現場でも、設計と同時進行でトレース情報が記憶できるトレーサビリティ記録方式として、「メタモデルによる設計情報定義とマルチビューを活用したトレーサビリティ記録方式」を紹介する。本手法を適用することで、トレーサビリティ管理にかかるコストが大幅に削減され、かつ、開発終盤で設計の抜け漏れ発覚し大きな手戻り工数が発生するリスクを減らす効果が期待できる。

ニューロンカバレッジ技法を用いたAIモデル特性分析
およびガイドワード抽出によるテスト十分性向上施策

AIモデルの品質要件の一つに様々な外乱要素に耐え得る「頑健性」があり、メタモルフィックテストは頑健性評価に有効な手法として知られる。昨年のSQiPシンポジウムでは、弊社の帳票認識ソフトウェアを題材に、本テスト技法の課題であるテスト十分性向上の施策として、ニューロンカバレッジ技法を用いたAIモデルの特性分析を提案した。
提案手法では、発生頻度が高いと想定される外乱要素に着目してメタモルフィック関係を導出したが、さらにテスト十分性を向上させるためには、発生し得る外乱要素をより網羅的に検討することが有効である。本報告では昨年の報告内容に加え、弊社で研究を進めているガイドワード抽出技術を用いて様々な外乱要素を洗い出す手法をご紹介する。

アジャイル開発における欠陥検出の
フロントローディングのための品質チェック方法の提案

アジャイル開発において、イテレーションの中で欠陥検出のフロントローディングができれば、イテレーションの期間中に品質の高いプロダクトを開発することが可能になる。本研究では従来のウォータフォール型の開発で行われているフロントローディングの方法に着目し、従来型の方法を応用した、アジャイル開発における品質チェック方法を提案した。過去プロジェクトの欠陥を対象としたケーススタディにより、バックログ作成やバックログリファインメントのタイミングで品質チェック方法を適用すると実装前の早期段階で欠陥を検出可能であることが分かり、アジャイル開発における欠陥検出のフロントローディングが可能になることを確認できた。

ソフトウェア・ファーストから考えるソフトウェア品質

世界が大きく成長する中、日本だけが取り残された状態が続いている。「失われた」時代も30年となり、これがいつ終わるのかも見えない。日本の国力低下とも言えるこの状況は日本のIT力の低下と見事に相関する。IT力の本質はソフトウェア力。ソフトウェア力を高めるにはソフトウェアを「手の内化」することが必須。それを提唱した書籍「ソフトウェア・ファースト」は日本のビジネスパーソンの興味関心を引きつけ、結果、多くの企業がソフトウェア・ファーストに舵を切った。本セッションでは、この「ソフトウェア・ファースト」の概説をするとともに、ソフトウェアが事業の成否を決める時代におけるソフトウェア品質のあり方を提案する。

組織にテストを書く文化を根付かせる戦略と戦術（2022秋版）

自動テスト（Automated Test）を書いてこなかった組織にテストを書く文化を根付かせるのは、一朝一夕では成し遂げられません。本講演では、組織にテストを書く文化を根付かせるために、まずテストを書く意義について改めてまとめた上で、いつ、どこに、どのようなテストを書くべきか、原理原則を踏まえた戦略から現場での戦術までお伝えいたします。

【講演】
ソフトウェア人材のエンゲージメントを高める組織づくりと、
SQuBOK/JCSQE活用への期待

近年、人的資本経営への関心が高まっており、従業員エンゲージメントの向上が課題となっています。
それには、人材の心理的エンパワーメントを高める取り組みを組織的に行うことが鍵となります。
そして、ソフトウェア人材の品質知識、スキル、意識を高めることが心理的エンパワーメントに結びつき、その過程でSQuBOKとJCSQEが果たす役割があるものと考えています。
本講演では、この一連の流れについてお話しします。

【JCSQE企業実践事例】
日立グループにおけるJCSQE資格試験,SQuBOKの活用について

日立のデジタルシステム＆サービスセクターでの、JCSQE資格試験、および本試験の主参考書籍であるSQuBOKの活用事例についてお話します。
日立では、ITサービス・ソリューション提供に関する社内資格制度として、「ITプロフェッショナル認定制度」を運営していますが、その中で、「品質管理エキスパート」という品質管理のスペシャリストも認定しています。当該資格認定をその認定要件にするなど、具体的な資格認定の活用方法について説明します。

ベリサーブにおけるSQuBOKなどを活用した技術者教育について

ベリサーブはソフトウェアの品質保証サービスを提供しています。
多くの、またさまざまなドメインの業務にあたるソフトウェア品質保証技術者を育成するために、JCSQEおよびその参考になっているSQuBOKや、ソフトウェアテスト技術者の資格認定であるJSTQBなどをどのように活用しているのかを含め、社内の技術教育についてお話します。

ミニパネルディスカッション

野中 誠 氏

東洋大学

手塚 聡子 氏

株式会社日立製作所

長谷川 聡 氏

株式会社ベリサーブ