レビュー品質の可視化にむけたODC分析の応用

ソフトウェア開発における生産性向上において、上流工程から下流工程への欠陥流出を防止することの重要性はよく知られている。
V字モデルを前提としたソフトウェア開発プロセスの場合、基本設計から詳細設計工程が上流工程に相当し、これら工程からの欠陥流出を防止するにはレビューの実施が有効である。すなわち生産性向上のためにはレビュー品質の向上が重要であり、そのためにはレビュー品質の可視化が必要となる。
しかしレビューについては「時間あたりの指摘数」や「ページあたりの指摘数」など効率面で定量的に品質を分析することはできても、指摘の内容そのものすなわち「指摘の質」に対する定量的な分析を行うことが難しい。
そこで筆者ら研究チームは客観的に指摘の質を評価するのに、ソフトウェア欠陥分析手法の1つであるODC分析を応用できるのではないかと考えた。特にODC分析が用いる分類属性の中でも、その欠陥が検出された経緯に着目する「トリガー属性」を用いてレビューにおける指摘の質を評価できるのでないかと考えた。
ただし、ODC分析をレビューに適用した事例はまだなく、レビュー指摘を適切にトリガー属性で分類する手法も確立していない。そこでまずはレビューで得た指摘に対して「適切なトリガーを選択する方法」を確立することにした。
今回、実験により適切なトリガーが選択できる事が確認できたので、ここに報告する。

欠陥検出密度・テストケース密度で評価できないインフラ構築における品質向上への取り組み

インフラ構築では、ソフトウェア開発プロジェクトとは異なり、開発規模から評価測定ができないために、欠陥検出密度やテストケース密度のソフトウェア開発における品質評価方法は適用しづらい場合がある。そのため、インフラ構築ではテスト観点の網羅性確認が必須であり、これにより機能・セキュリティ・パフォーマンスの重要な要素を適切にテストし、その結果を保証できると考えている。

発表の背景として、今回リプレースを行った認証基盤はサービス利用型のため詳細な仕様は非公開であり、テスト観点の網羅性の担保が困難であった。そのため、認証基盤のインフラ観点とそれを利用する業務アプリケーションの両方の観点で、サービスを提供するビジネスパートナーの協力と、アプリケーションのリグレッションテストによりテスト観点の網羅性評価を行うことができた。
結果として本プロジェクトではリリース後の本番障害が0件であったため、1億円超のプロジェクト規模に対して「静かなリリース」として社内で高評価を得た。本発表では特にインフラ構築においての品質評価の取り組みを行っている参加者に対し、今回検討した品質評価の取り組みに十分な効果があったと評価できたため、その取り組みを紹介させていただく。

ソフトウェア開発の品質向上で成果が出た実践的な「なぜなぜ分析」の方法について

私は中規模の産業用機械メーカーのソフトウェア開発部門で長年開発業務に従事してきました。その中で、年々変化する市場要求への対応、新規技術の導入、コストダウン対応、継続して行われる多くの保守開発などにより、ソフトウェア開発の難易度が高まりました。それに伴い、不具合によるプログラム修正、すなわち手戻りが多く発生することになりました。
この課題に対して、手戻りを低減させるための改善活動を継続的に行い、その活動の柱の一つとして「手戻り事例についてなぜなぜ分析を用いて原因分析と再発防止を行う」ことを実施しました。
開始当初は分析件数が事例件数に追いつかず、多くの積み残しが発生しました。また、件数の消化を急ぐばかりに再発防止が現実的でなく、場当たり的になるなどの問題が発生し、効果を十分に発揮できませんでした。これらの課題に対して様々な試行錯誤を行い、工夫を重ねることで、継続的で効果的な取り組みが可能となりました。
ここでは、実際の開発現場で行い、現実に則し、効果を上げてきた手法について紹介します。

ローコード・ノーコードの製品選定の勘所と生産性・品質基準について

近年のDXや内製化ブームを受けローコードノーコード製品によるシステム開発（以降、『LCP/NCP開発』）が業務システム構築の選択肢となりつつある。そのような潮流のなか、LCP/NCP開発は年々増加傾向だが一方で課題も顕在化してきた。例えば、

• 開発初期段階でスクラッチ開発とするのかLCP/NCP開発とするのか、判断基準が不明瞭であり、また、多くの製品がある中でどのように製品選定していくのか、観点・方法・手順が確立できていない（①）
• LCP/NCP開発に有効な見積り方法が確立できておらず、見積の妥当性確認や他者説明が難しい（②）
• LCP/NCP開発ではソースコードが部品化され、リポジトリに隠蔽されるため従来のStepベースの品質管理（例：テスト密度＝○○件/ks）は行えず、テスト計画や結果を確認する観点・方法・手順が確立できてない（③）
• LCP/NCP開発では原則コーディングしないため特徴に合わせて工程定義をテーラリングする必要があるが、観点・方法・手順が確立できてない（④）※

などが挙げられる。これらの課題を解決するため、ITシステム可視化協議会（以降、『MCIS』）では会員有志の研究会を立ち上げ、各社の実績データや有識者知見をもとに、ファンクションポイント法による見積り、品質評価等の検討を行い課題解決に取り組んできた。今回は①②③の発表を行う。本発表がローコード開発及び定量データ活用の一助となれば幸いである。
※SQiP2023にて発表済み

技術開発現場の課題分析なしで改善施策の期待効果を広範囲で抽出する
「改善効果探索マップ」の提案

改善活動においては、改善施策が先行して決定した上で開始せざるを得ないケースがしばしば発生する。本研究では、改善施策を先に定めた状態で改善活動を開始する際に、経営管理層や開発現場の支持を得るためにできるだけ多くの改善効果の抽出を目的とした「改善効果探索マップ」を提案する。本マップの狙いは、起点となる「改善効果項目」から連鎖的に複数の階層に渡って項目を探索しながら改善活動担当者の視点では気付かなかった項目を発見していくことである。本マップを使って実際の改善現場で改善効果の抽出を実施した結果、従来の担当者が予測した場合と比べ改善効果をより広範囲に多数抽出することができ、その中から適切な効果を選定することでその有効性が確認できたので、その成果を発表する。

ソフトウェアプロセス改善を組織的、実証的にすすめるための
データ分析パターン言語の提案

ソフトウェア開発企業で組織的なプロセス改善を実施している状況を考える。改善を客観的・効果的に進めるには定性的／定量的なデータ分析を用いた実証的アプローチが有効であることは良く知られている。
しかし、ソフトウェア開発での定量的データの扱いには困難も伴う。人的要因や環境要因の影響が大きいため、統計的手法適用の前提条件とされるデータの安定化（雑音の低減）が難しい。さらに、人の活動（プロセス）データを扱うため、次のような問題が起こり得る：測定活動が形骸化して使用されていないデータが収集され続ける、人やプロジェクトの評価や叱責に使われるおそれから現場が警戒して測定活動に非協力的になる、極端な場合には虚偽の測定値が報告される。
本論文では、パターン言語の形で、プロセス改善のためのデータ分析に関する問題点を解決するコツや留意点を記述し伝えることを提案する。このパターン言語では(1)データ分析の準備に関わるパターン (2) データ分析そのものに関するパターン(3) データを活用した改善活動に関するパターンの3分類に沿い記述している。これはデータ分析では準備が重要であり、改善活動の一部として組織全体でビジョンを共有し協力的に進めるべきであるという考えに基づく。
本論文ではこのパターン言語の記述能力と適用効果・特性についての調査結果および評価実験の結果についても報告し、考察する。

上流工程からの継続的なテスト活動の実現

当社の強みは保険商品にあり、限られたリソースのなかで保険商品の早期提供を実現していくためには 社員・開発担当者はより上流工程にシフトする必要がある。
また全体工数に対するテスト工数の占める割合が高いため、テスト工程に対する改善の余地は大きい。
上記課題を解決するために2020年から以下三つの改善施策を開始し、ライフサイクルの早い段階での品質の作りこみ（欠陥の埋め込みの予防、および欠陥の早期検出）を強化してきた。

三つの改善施策

1. 開発とテスティングの分離の推進
2. 手動テストの改善
   ※「リスク」および「要件・設計要素」とテストケースとのトレーサビリティの可視化
3. テスト自動化の推進

これらの施策により、本番障害検出率と上流工程での本番障害埋め込み比率が減少し、品質の確認から品質の作り込みへのシフトレフトが実現した。今後はテスト実装、テスト実行部分の自動化だけではなく、テスト設計部分の自動化にもチャレンジしていきたい。テスト設計部分の自動化が実現できれば、テスト設計者がテストケース作成に要していた時間を短縮でき、テスト設計者はより上流のテスト分析に注力することができる。

数年に及ぶ三つの改善施策の実績を踏まえて、同様の課題を抱えている参加者に対して、取り組みのポイント、苦労した内容、およびその導入効果を紹介する。

保守改修（是正保守）プロセス構築による効果的な欠陥対策とリスク把握に関する取り組み

現代のソフトウェア開発は規模と複雑さが増しており、欠陥の発生は避けられません。
しかしながら、欠陥の対応を行うときにプロダクトの本来保証すべき品質の考慮を怠り、緊急的に特定の修正のみを行うと、後々プロダクトの成長を阻害することがあります。

そこで、欠陥を修正し品質を保証する活動しつつ、プロダクトの成長を阻害せずに、プロダクトの機能を追加・変更を行うための保守改修（是正保守）プロセスとして定義し実践をしました。

本発表では、このプロセスをどのように定義をして欠陥対応に臨んだのか。
また、これを利用し欠陥のリスク把握を行い、修正すべき品質の方針確認と合意（納得）をしたのか。
そして、このプロセスをりよして将来を考慮した欠陥の修正を行った方法について、事例を交えてご紹介いたします。

アジャイルテストの4象限を活用したリリース戦略の実践

昨今ではエンタープライズ向けのシステム開発や、ミッションクリティカル領域でのシステム開発でのScrumの適用事例が見受けられるようになりました。一方、Scrum開発を実践したが品質問題を起こしてしまったというケースや、品質保証への不安から重厚長大なテストプロセスを構築し、思っていたようなアジリティが出せないといった失敗例も散見されています。
本発表では、アジャイルテストの4象限をうまく活用し、サービスやプロダクトのリリース戦略を工夫することでScrumの良さを残しながら、マーケットでのリスクを適切にマネジメントする開発方法や組織の構築方法などを、事例を通じて発表します。
「ウチみたいなソフトウェアはScrumで開発できないよ」「アジャイル開発への挑戦はしたいが、品質への不安がぬぐえない」「アジャイル開発をしたつもりになっているが、何だか小さなウォーターフォールを繰り返しているだけな気がする」と思っている皆様がいれば、ぜひ聞いていただきたいとおもいます。

品質保証活動をアジャイルプロセスに溶け込ませるためのテスト活動の再構築と、それを支えるアジャイル・エンジニアリングの活用

本稿では「品質保証活動をきちんと行おうとすると開発開始からリリースまでのリードタイムが長くなるが、テスト実行の自動化だけでは解決しきれないような組織」がどのように取り組むとよいかを提案する。
開発がウォーターフォールからアジャイルにシフトしていく中で、品質保証をどのように変化させていくとよいか悩む組織は多いことと推察する。
具体的には、以下の2点が課題になる。

• テスト実行がボトルネックになる
• アジャイルのスピード感に追随するために導入した自動テストの施策が効果を発揮しない

これらの現象は、テスト活動の中でも目に見えやすい「テスト実行」にフォーカスしすぎていることで発生している。課題1,2の現象そのものではなく、その根本にある「テストプロセス全体ではなくテスト実行にフォーカスしすぎていること」が本質的に解決すべき課題であると考える。
本稿では、アジャイルのプラクティスに、テスト実行だけではなくテストプロセス全体を織り込んでいくためのプロセスモデルを提案し、その具体例を紹介する。このモデルの適用は、テストや品質保証の活動を、単なるフェーズゲートからチーム全体で行うタイムリーな活動に変容させる。結果として、アジャイルのスピード感を損なわずに品質を維持することができるようになる。
アジャイル開発におけるテスト活動として目指すべき方向性を提示し、アジャイル開発への適応を目指す組織へのヒントを示唆する。

スピード感と品質を両立したアジャイル開発に対応する
品質マネジメントシステムとは

～テスト設計方針を組み込んだ完成の定義と品質技術者の導入～

ビジネスとしての不確実性が高い現在のDX事業環境下では、価値創出のサイクルを素早く回し、テスト＆ラーンを繰り返しながら、顧客要求を探し当てる必要がある。この実現のため、ソフトウェア開発において、アジャイル開発の適用が不可欠となっている。しかしながら、日本においてアジャイル開発が普及途上という事情も影響し、アジャイル開発で確実に品質を確保することに不安があるのは事実である。一方、既存ビジネスにおいては、ISO9001認証取得により、提供する製品・サービスの品質に一定の信頼感を得ることが定着している。以上の状況を踏まえ、本活動の目標を以下のように設定した。

• アジャイル開発のスピード感と品質確保を両立するとともに、そのアジャイル開発に対応した品質マネジメントシステムを構築し、ISO9001の認証取得を目指す

品質向上の効果的なアプローチによる
小規模ソフトウェア開発の生産性向上の要因分析

ウォータフォール型ソフトウェア開発における品質の向上に関わる要因として、定量的に示された報告がある。以下2点示す。1. 信頼性向上に関わる要因として、上流工程での不具合摘出比率、設計レビューの指摘密度および工数密度、設計文書化密度を挙げている。2. 組織の開発成熟度別の要因として、上工程バグ数/KL、上工程バグ摘出率、テスト工程バグ数/KLなどを挙げている。ただし、品質良否を分ける第一要因は開発規模であり、小規模ソフトウェア開発であれば出荷後品質はほぼ良好であることを示している。
しかし、弊社の研究によると小規模開発に対象を絞った場合でも、上工程バグ摘出率や上工程レビュー工数比が品質に有用であり、さらに生産性にも寄与していることを示している。
一般的には品質と生産性はトレードオフと考えられがちだが、品質向上と同時に生産性が向上する研究結果が上がってきている。その要因を特定することで、品質と生産性を両立するための指針を示すことができる可能性があり、その意義は大きいと考える。本研究では、当社の研究で示されている品質向上が生産性に寄与している結果をさらに深堀分析し、ウォータフォール型の小規模ソフトウェア開発を対象に、品質向上の効果的なアプローチが生産性向上に寄与する要因を分析した結果を報告する。

スマートファクトリー（OT・IT・プロダクト）における品質確保

弊社では、ERP に代表される「基幹・計画系システム」から製造工程の状態を把握・管理する「実行系 システム」、さらにロボット自動化などを実現する「制御系システム」まで、OT・IT・プロダクトを掛け合わせ、お客様工場のスマートファクトリー化を推進している。

従来、弊社はお客様設備に対してデータ収集やデータの見える化を行ってきたが、2020年にロボットシステムの導入も含めたスマートファクトリー化プロジェクトを実施。ロボットシステム導入にあたり、業界開発標準プロセスである「RIPS（Robot System Integrtion Standard）」を適用し、最終的に品質を確保することができたが、弊社初のロボットシステム導入であったことから設計工程での手戻りが発生。今後の課題として以下が残った。

• 見える化の目的に応じた、OT・IT システムの連携仕様確定が必要
• 物理的な安全性を考慮した設計と評価手法が必要
• システム構築後に手戻りが発生しない仕組みが必要

この経験を受け、RIPSをベースにプロジェクト事例のナレッジ化と上記課題解決を目指しロボットシステムの品質確保プロセスを検討した。
本発表では、ロボットシステムの品質確保プロセスの検討事例と、プロセス導入後の効果について報告する。

STAMP/STPA,CAST分析を用いた安全設計評価手法とインシデント対応事例の紹介

ロボットと人が協働で作業するような環境においては、安全性の確保が重要な課題である。しかしながら、ソフトウェア主体になり複雑化したシステムでは、網羅性や十分性の検証が難しいことが安全性評価における課題となっている。加えて、人の意図しない行動や誤使用は予見が難しく異常動作の洗い出しも難しい。

これらの課題に対応すべく、従来のシステム評価手法に、安全性分析（STAMP/STPA分析）と事故要因分析（STAMP/CAST分析）の手法を新たに導入することとした。STAMP/STPA分析によるシステム開発時のハザード誘発要因の特定と、STAMP/CAST分析による稼働後のシステム有効性評価を行い、これらの分析結果をもとに事故要因を特定した。以降の開発でもこれらのサイクルを繰り返し、事故要因/対策のノウハウを蓄積していくことで、従来よりも効率良くシステムの安全性を高めていくことが期待できる。

本発表では、「産業用ロボットとAGV（Automated Guided Vehicle: 無人搬送車）を連携させるシステム」の開発において、STAMP/STPA分析によるハザード誘発要因の特定と対応する安全施策を行い、インシデント対応にSTAMP/CAST分析を活用して、関連する要因の洗い出しと再発防止策を立案した事例を紹介する。
STAMP：Systems Theoretic Accident Model and Processes
STPA： System-Theoretic Process Analysis
CAST： Causal Analysis based on System Theory

ユーザー企業におけるプロジェクトリスクの検知とコンティンジェンシープランの要所

近年のDXブームからユーザー企業におけるIT投資は高水準で推移しているが、高難度のプロジェクト（以下、PJ）を中心とした失敗（QCD未達）PJも後を絶たず、ユーザ企業においてもリスクマネジメント・品質管理の高度化が求められている。

失敗要因の１つとして、ユーザー企業のPJ担当者はベンダーのような開発作業やPJマネジメントは未経験であることが多く、ベンダーに比べ見える情報も限られることから、PJ推進およびPJの成功がベンダー依存となっておりPJを主体的にマネジメントできていないことが挙げられる。

本講演ではユーザー企業がPJの失敗を防ぐ上で重要となるリスクマネジメントについて、行っている施策とその要所を紹介する。各施策はユーザ企業で運用可能なことを重視しており、実際にあるユーザ企業においても自走しつつある。

(ア)　PJ開始時のリスク見極め（リスク定量化/可視化ツール）
(イ)　PJ開始時のリスク対策の計画（品質管理ルール/ツール）
(ウ)　PJ開始時のリスクを加味したコスト見通し（予備費算出ツール）

本講演をつうじ、ユーザー企業におけるリスクマネジメント・品質管理の高度化、ひいては日本のデジタル競争力向上に貢献していきたい。

ヒヤリハットの要因抽出と対策立案フレームワーク

～不適切な行動と周辺要素を整理するための要因抽出マトリクスと、
対策立案シートの考案～

ヒヤリハットのきっかけとなる不適切な行動の多くは複数要素によって引き起こされるため、様々な視点で要因を検討しないと対策が不十分なものとなってしまう。また、その検討が属人的に行われると、どのように再発防止策を導き出したかがブラックボックス化してしまい、適切な未然防止に繋がっているかの妥当性が判断できなくなる。
これらの問題を解消するために、発生したヒヤリハットの要因分析に必要な観点をまとめ、対策を立案するまでの思考のプロセスを可視化することを目指した。

発生したヒヤリハットの要因を抽出するためには、きっかけとなった個人行動とそれを引き起こした周辺要素の2つの視点から分析する必要があると考えた。個人行動は、その組織・チームにおける「ルール・標準・規則を知っていたか否か」を起点として4つのタイプに分類し、周辺要素の分析観点にはm-SHELLモデルを採用、この2つの視点を「要因抽出マトリクス」として整理した。そして、「要因抽出マトリクス」で得た情報をもとに再発防止策を立案するまでの流れは、「対策立案シート」として思考のプロセスの可視化を試みた。以上を現場の方々にも活用頂けるようまとめたのが今回考案した「ヒヤリハットの分析フレームワーク」である。
今回はその紹介と共に、社内での実践結果を共有する。

初心者にも理解しやすいソフトウェア品質管理教育の実現

普段身の回りにある様々な製品は製造者によってしっかりと品質管理がされており、そのお陰で安心安全な生活を過ごすことができています。この品質管理がないと、様々な製品を購入、利用する際に安全性に問題がないかを都度確認する必要が出てきてしまいます。ソフトウェアも同じことが言えるはずですが、なかなか品質管理が徹底されているという話を耳にしません。とりわけ、ソフトウェア製品を開発している企業のISO9001認証の取得率も国内でも低いのが現状です。国内では、ソフトウェア製品の調達に法令や製品品質認証が必須となっておらず、ソフトウェア業界の中で品質管理の知識のあるエンジニアの育成に力を入れている企業も少ないです。
一方、エンジニアが個人で品質管理を学ぶ場合、ソフトウェアの品質管理が初心者にとって取り組みにくいことは一つの課題です。今回この課題に対して品質管理の知識の習得、組織としての品質管理体制構築のあり方を自主的に行えるように、品質管理で使われている曖昧な用語を論理的に説明し分かりやすさを意識した研修プログラムを作成し、顧客向けに支援提供を始めました。
本セッションでは実際に実施した初心者向け教育の内容、研修の効果を解説します。こちらの発表を通し、ソフトウェア業界で品質管理を導入していくために、より多くの方々に品質管理を理解するにはどのようにしたらいいのかを考える契機となれば嬉しいです。

セキュリティリスクアセッサ任命制度の導入と効果
: トータルセキュリティ品質の向上に向けて

筆者の所属事業部では、情報システムのセキュリティ品質の確保を目的として「セキュリティリスクアセッサ任命制度」を導入しました。アセッサの活動はシステム開発の４フェーズ（企画、基本設計、テスト、運用）すべてを通じて行われ、トータル的なセキュリティ品質の向上に寄与しています。
アセッサは任命制であり、IRT（Incident Response Team）責任者が推薦し、事業部長が認定するルールを設けました。この任命制度により、アセッサの役割・定義が明確化し、セキュリティ人財の育成指標としても活用されています。本発表では、アセッサレビューの実施件数と改善ポイントについて報告し、セキュリティインシデント防止のためのPDCAについても紹介させていただきます。
セキュリティリスクアセッサ任命制度の導入により、有識者の明確化と、スキル不足によるセキュリティインシデントの軽減が実現しました。今後はセキュリティ品質の拡大に取り組む予定であり、セキュリティ人財の裾野拡大も検討しています。さらに、セキュリティトレンドや社内事例の情報共有会も実施し、アセッサのスキル向上を図っています。
この制度は、セキュリティ品質の向上に効果的であり、広くセキュリティインシデントを防止するための施策として活用できます。セキュリティリスクアセッサ任命制度の導入と効果についての詳細な報告を行います。

環境変化に即応する本社系品質管理組織への挑戦

～価値中心のマネジメントで自律した組織を作る～

企業はDX推進や生成AIの活用など、環境の変化に迅速に対応し価値を提供することが求められています。特にシステムインテグレーター（SIer）は、請負受注型ビジネスモデルから顧客価値を重視したサービス型事業への転換が急務となっています。これらの変化に対応するため、品質管理組織は全社の生産性や品質課題に迅速かつ柔軟に対応できる組織であることが必要です。

この課題解決のために、私たちの組織では大規模アジャイルフレームワークを導入し、下記の取り組みを通じて迅速な価値の提供を図りました。

• 複数のアジャイルチームがビジョンを共有し、迅速な計画変更を行う体制を構築、四半期毎のPDCAサイクルと2週間のスプリントで全チームが同期し連携
• ポストコロナにおけるコミュニケーション方法としてオンラインとリアルのハイブリッド形式を選択し、場所を問わない質の高い対話を促進
• リモートワーク時代に対応したチーム力・生産性向上を目指し、心理的安全性の醸成を重視

これらの取り組みに対するメンバーへのアンケート結果からは、エンゲージメントや生産性、品質の各項目で10～25%の向上が見られました。一方、アジャイルフレームワークの導入には、教育・支援体制の強化、役員層のコミットメント、メンバーの自律的な行動の促進などにも同時に取り組む必要があることが分かりました。
本発表ではこれらの取り組みと成果を詳しくご紹介します。

機械製造業での外販システム開発部署を中心とした組織行動変革

過去に成功体験を収めてきている機械メーカーにおいて、機械売りに最適化された組織行動からサービス売りを促進できる組織行動への変革が求められている状況です。
VUCA時代の継続的な付加価値提供を可能とする体制整備を目的とし、システム開発内製化を軸に、属人化低減・人材流動性向上を促進する組織行動マネジメントを試みています。
営業、商品企画、開発、開発委託先、協業他社、テクニカルサポートと連携して、顧客、代理店へと価値提供を行うSE部署を組織行動変革の核と捉え、当該部署にて次の３点を実施しました。

1. 暗黙知の形式知化
2. 形式知の資産化
3. 形式知化・資産化の躾

これらの取組みにより、これまでの属人的な顧客案件対応、他部署連携が標準化され、再現性のある形で集合知を応用した価値提供を行う体制が整えられます。
実施結果として、定量的効果、定性的効果、両方の側面を紹介いたします。永らく慢性的に属人化してきた組織文化においては、定量的効果よりも、定性的効果への期待が重要と考えます。
定量的効果としては、属人化低減・人材流動性向上の観点で、自部署で期待できる年間のコスト削減を紹介いたします。
定性的効果としては、取組みを継続する中で生じた、自他部署を巻き込む形での組織行動の再定義を紹介いたします。
業界や企業の文化に依存する話が多いかもしれませんが、本発表が皆さんの何かの参考になれば幸甚です。

SQuBOK （ソフトウェア品質知識体系ガイド）に関する情報発信

「ソフトウェア品質知識体系ガイド」SQuBOK V4 に向けた取り組み、最新情報

登壇者

手塚 聡子 氏

株式会社日立製作所
デジタルシステム＆サービス統括本部
品質保証統括本部

登壇者

辰巳 敬三 氏

一般財団法人
日本科学技術連盟
技術顧問

ソフトウェア企業が実践する失敗学のすすめ

みなさんの組織では、同じ失敗を繰り返していませんか？同じではないが、過去の失敗と似ていると感じたことはありませんか？再発防止だけでなく未然防止ができていますか？「水平展開」「なぜなぜ分析・原因の深掘り」という言葉はよく聞くけれど、実際にはできていないということはありませんか？
「人の振り見て我が振り直せ」と簡単に言うけれど、我が振り直すにはちょっとしたコツが必要なのです。そのコツを伝授するのが失敗学です。
本発表では、ソフトウェア会社にて失敗学を推進してきた経験をもとに

• ソフトウェア開発の「失敗分析」で陥りがちな間違い
• 基礎的な基本的な考え方と実践手順
• 我が社での取り組み

等について紹介いたします。

どのようなソフトウェア開発活動で生成AIが活かせるか？

好澤 聡 氏

業務上の経験や研究を主とした経歴

2020年4月　ベリサーブに新卒入社
2020年9月　沖縄のプロジェクトに配属、テスト自動化業務に従事
2022年4月　事業部内テスト自動化専門チーム立ち上げ
2023年4月　事業部全体の技術推進に従事
2023年7月　AIに関する技術習得・AIプロダクト開発に従事
2024年1月　AIプロダクト開発・AI人材育成・事業部内R&Dチーム立ち上げに従事

菅藤 佑太 氏

業務上の経験や研究を主とした経歴

自然言語処理によるShellのアノマリーディテクションの研究を前身として、現在はLLMの業務への適合を推進している。
SQLクエリの自動生成、レビュー、デバッグを自然言語との意味一致判定を組み込みながら精度を高める取り組みをや、LLMを利用したマーケティング分析のフレームワークの構築を行った。
直近では社内で利用できるようなプロダクトのPdMとして、様々な人がLLMを活用しやすい環境をLLM Web Platformという形態で構築・推進をする。

研究論文や著書

• 情報処理学会 第86回全国大会
  「テーブル推定及び指示文一致判定によるSQL自動生成の精度向上」
  https://www.ipsj.or.jp/event/taikai/86/WEB/data/pdf/5D-03.html
• 「低対話型 Honeypot のコマンド拡張による収集ログの変化の計測」
  http://web.sfc.wide.ad.jp/~nadechin/thesis/thesis.pdf

その他（学位、表彰、学会活動、その他特記事項）

慶應義塾大学 総合政策学部 総合政策学科 （村井純研究室）卒業

藤本 宏 氏

業務上の経験や研究を主とした経歴

株式会社東芝に入社以来、ソフトウェア開発技術の研究と実践に従事。複合機やデジタルテレビなど様々な製品開発においてソフトウェア設計・実装技術の導入と展開を実施。その後はソフトウェア設計に関する技術開発のリーダとして、形式検証やソフトウェア構造診断などの技術開発と社内展開を担当。2023年よりソフトウェア開発効率化のための生成AI活用技術のチームを構築し、有用な活用方法の確立と普及展開に向けた取り組みを進める。
製品開発で実践できる技術の整備を志して活動中。

松本 雅博 氏

業務上の経験や研究を主とした経歴

• 2017年 アマゾン ウェブ サービス ジャパン合同会社に入社
• AWS サービスの紹介、アーキテクチャ提案、運用改善などに従事
• オンラインセミナーやユーザーグループのイベントで開発者向けサービスの紹介やワークショップを実施

その他（学位、表彰、学会活動、その他特記事項）

• AWS Dev Day 2023 Tokyo に登壇
  コードレビュー辛くないですか？その原因と対策を考える.
• AWS Summit Japan 2024 のライブステージ Developers on Live に登壇
  AI アシスタントの利用が増えている今、改めてコードレビューについて振り返ろう

森崎 修司 氏

業務上の経験や研究を主とした経歴

博士取得後、インターネットサービスプロバイダでオンラインストレージサービスの開発に携わる。その後、奈良先端科学技術大学院大学、名古屋大などでソフトウェアエンジニアリングの研究に従事。ソフトウェア開発企業56社との共同研究、国内外の11人の社会人博士の学位取得支援や審査に従事。独立行政法人情報処理推進機構(IPA) 「つながる世界の品質指針検討ワーキング・グループ」をはじめ3ワーキング・グループの主査を務める。現在、ソフトウェア開発での生成AI活用にむけた試行、実験のテーマに取り組んでいる。