本研究は、ソフトウェア開発の全工程（設計・実装・テスト）に適用可能な「トークン数」を用いた成果物規模計測手法を提案し、その有効性を評価したものである。従来、各工程ごとにページ数・行数・項目数など異なる指標が使われてきたが、これらはスタイルや形式の違いによるばらつきが大きく、生産性評価の信頼性に課題があった。そこで、本研究では、成果物をテキスト化・トークン化し、そのトークン数で統一的に規模を測定する方法を考案した。

提案手法は、成果物を収集後、非テキストの場合はMarkdown等へ変換し、トークナイザーでトークン分割、トークン数を計測するという流れである。差分計測時は、変更前後の成果物から増減分のトークン数を算出する。また、オープンソースライブラリ（OpenAIのトークナイザーやMicrosoftのMarkItDown等）を利用することで自動計測も実現できる。

評価では、実装に対して、自動計測の可否・差分計測の可否に加えて計測結果のばらつきを検証した。その結果、従来の行数ベースよりもトークン数ベースの方が生産性のばらつきが小さく、より客観的な評価が可能であることが示された。

今後は、設計・テスト工程への適用や、人間の主観的成果量との比較、実際の開発現場での有効性・満足度の確認、さらには品質分析など他のメトリクスへの応用も検討し、信頼性向上と活用範囲拡大を目指す。

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

例えば、

• LCP/NCP開発に有効な見積メトリクスが確立できておらず、妥当性確認や他者への説明が難しい
• LCP/NCP開発の設計～テストでは従来のStepベースの品質管理（例：テスト密度＝○○件/ks、バグ）は行えないため、テスト計画や結果を確認する観点・方法・手順が確立できてない
• LCP/NCP開発では機能量と不具合量に相関がなく、機能テスト完了時の工程前進を判定する観点・方法・手順が確立できてない

が挙げられる。

これらの課題を解決するため、日本ファンクションポイントユーザ会改めITシステム可視化協議会（以降、「MCIS」）ではローコード/ノーコード開発における会員有志の研究会（以降、「lcncSig」）を2021年度に立ち上げ、各社の実績データや有識者の知見をもとに、ファンクションポイント法による見積り、品質評価、開発プロセスの検討等を行い、課題解決に取り組んできた。本発表がローコード開発及び定量データ活用の一助となれば幸いである。

ソフトウェア開発プロジェクトでは、開発規模や分野(基幹業務システム、モバイルアプリ、組み込みシステム、Webサービス等)、技術要件の多様性により、既存の品質管理手法をそのまま適用することが難しい。この問題を解決するために本研究では、プロジェクト特性を体系的に分析して、それに基づきSQuaREを用いて品質特性の優先度を導出し、既存の概念「品質ボックス」を活用した最適な品質管理手法を選定するフレームワーク「Quality-Characteristicsコンパス(QCコンパス)」を提案する。

実際のプロジェクトにて有効性を確認した結果、プロジェクト品質方針に基づき品質特性の優先度を明確化することで、ステークホルダー間の合意形成が促進され、調整にかかる負担が軽減されることを確認した。また、品質管理手法のテーラリングを実施した一部プロジェクトにおいては、リスク管理が効果的に行われ、品質向上とコスト削減の両立が可能である結果が得られた。

一方で、テーラリングの実施には品質特性以外の要素の検討や、利用者への教育・トレーニングの必要性も明らかとなった。今回は、研究の成果と課題、そしてQCコンパスの今後の展望について発表する。

ソフトウェア開発における不具合の「なぜなぜ分析」は、多くの場合「なぜミスをしたのか？」という設計者個人の追求に終始し、「注意不足だった」といった表面的な原因で終わってしまう。その結果、チェックリスト項目追加などの実効性の低い再発防止策しか導出できないことが多い。

本発表では、技術者の思考・判断の誤りを誘発する要因を体系的に整理した「不具合分析モデル」について、具体的な分析事例と導入効果を交えながら提案する。
このモデルにより、ミスの誘因を「設計要因」「流出要因」「マネジメント」「組織成熟度」の観点から構造化することで、従来見落とされがちだった背景要因が可視化される。

分析手順：

1. 故障・障害・欠陥・ミスの階層関係を明確化し、思考・判断の誤りが生じた対象を特定
2. 誤りの分類（スキル不足/過失/故意）と事実をヒアリングで確認
3. 不具合分析モデルにより技術的要因とマネジメント要因を分離し、ミスの誘因を抽出
4. 組織成熟度に応じた納得性の高い再発防止策の選定

モデルを適用した事例では、個人の注意喚起ではなく、「仕様の曖昧さ」「レビュープロセスの形骸化」等の組織的課題が明確になり、プロセス改善やマネジメント強化といった本質的な対策の導出が可能となった。
本手法は個別不具合の再発防止だけでなく、類似不具合の未然防止にも有効である。

実装エンジニアからＱＡエンジニアへ役割が変わり、元実装エンジニアの強みを活かし「いかに品質向上に寄与できるか？」を探求し、奮闘した日々とその成果を紹介します。

保守開発プロジェクトの実装エンジニアだった私は、５年前に同プロジェクトのＱＡエンジニアに任命されました。担当するソフトウェアは長年のレベルアップ（派生開発）により、多くの機能を実現できている一方、ソースコードは複雑化し、システム障害が継続的に発生し、開発速度も低下していました。これについて「システム障害の低減」と「開発速度の向上」という２つのミッションを設定しました。

これらのミッションに対して、①品質保証について学びつつプロジェクトの現状を捉えセオリーに従って対応する「現状把握期」、②現状の問題点から課題を特定し対応する「真因対応期」を経て、直近２年間でのシステム障害ゼロを達成することができました。また、品質向上による「手戻り減少」を原資とした「技術的負債解消」により、「開発速度の向上」に寄与できました。さらに、私自身もＱＡエンジニアとして大きく成長できました。これらの取り組みと成果について発表します。

航空機搭載ソフトウェアのような「大規模ソフトウェア開発」の課題として、開発関係者/関係部門の拡大による認識齟齬の増加と、手戻り期間の長期化による納期への影響が挙げられます。大規模ソフトウェア開発の目指すべきところとして、”認識齟齬を最小限に抑えた手戻りのない開発”があり、この目的を達成するためには、アジャイル型開発のような新たな開発プロセスを構築する必要があります。

新たな開発プロセスの構築にあたって、顧客との合意形成のタイミングや開発プロセスが厳格に定められている場合には、あくまでもその枠内での工夫が求められております。

本発表では、各種制約の中でアジャイル型開発を導入した事例として、プロセス、体制、レビューに関するテーラリングの内容と導入成果を紹介します。特に、ゲート管理に留まらない品質保証部門の新たな役割についても示します。

一般的なアジャイル開発とは異なる側面を持ちながらも、制約の中でのアジャイル型開発導入の実践例として、特に大規模開発における有効性を示すことで、アジャイル型開発導入に躊躇している方々にとって、新たな視点を提供できる機会となることを期待しています。

変化の激しい開発環境では、不確実性に起因する判断ミスやリスクの見落としが、重大な品質問題へと発展することがある。本発表では、私がQAエンジニアとして取り組んできた、そうしたリスクに向き合う考え方と実践について紹介する。過去には、曖昧な仕様や品質知識の不足により十分なテストが行えず、リリース遅延や品質低下を招いた経験がある。これを教訓に、リスクを「プロジェクトリスク」と「プロダクトリスク」に分類し、それぞれに応じた対応方針を整理したうえで、判断ベースでテスト戦略を調整する取り組みを行ってきた。さらに、リスク識別のための会議体を設け、開発チームと早期に情報を共有し、設計段階から品質を扱う体制を整備した。これにより、仕様検討段階での認識のずれや改善事項を前倒しで発見・対処できるようになり、リスクの顕在化を未然に防ぐ効果があった。不確実性が高まるなかで、マインドセットと戦略の両面から対応するQAの実践的アプローチを紹介し、現場で再現可能な品質改善のヒントを提供する。

開発現場のソフトウェア開発プロセスの状態や改善点を把握するために、ソフトウェア技術者自らが実施者となり、ソフトウェア開発プロセスのチェックリストを用いて自己診断の形式でプロセスアセスメント(セルフアセスメント)を行う方法がある。セルフアセスメントの課題として、結果が実施者のプロセスに関する知識に大きく依存してしまう点がある。高度な自然言語処理能力を持つ生成AIは、プロセスの側面でも効果を発揮できる可能性がある。本研究では、プロセスの知識が十分でない実施者を支援するために、生成AIを活用したセルフアセスメントアシスタント(AI-ProSaA)を考案した。実際のプロジェクトで実験した結果、生成AIが初級アセッサーレベルのアドバイスを出力でき、実施者のプロセス知識の補完に対する有効性が確認できた。

プロセス改善におけるデータ分析活動のコツ・ノウハウをパターン言語として記述することを提案する。本パターン言語は15のパターンを(1)データ分析の準備に関わるもの(2) データ分析そのものに関するもの(3)データを活用した改善活動に関するものに分類している。これはデータ分析では準備が重要であり改善活動の一部として組織全体でビジョンを共有し協力的に進めるべきであるという考えに基づく。
本パターン言語の問題発見・解決に対する効果を関係者間のコミュニケーション促進の観点から検証する。また、本パターン言語の受止め方が立場（EPG,QA,PLなど）によりどう変化するかを被験者による実験と生成AIを用いたシミュレーションを用いて考察する。

ソフトウェア開発の現場において重大なトラブル・事故を未然に防ぐためには、その予兆となるヒヤリハット(ヒヤッとした、ハッとした出来事)に対する再発防止を行っていくことが重要である。しかし、そのきっかけとなる不適切な行動の多くは複数要素によって引き起こされるため、様々な視点で要因を検討しないと対策が不十分なものとなってしまう。
そこで、発生したヒヤリハットの要因分析に必要な観点と、対策を立案するまでのプロセスを「ヒヤリハット分析フレームワーク」としてまとめ可視化した。
今回の講演では昨年度発表した当フレームワークの紹介および、対策立案においてその検討を補助する情報を拡充した内容を共有する。

ソフトウェア開発の現場では、手戻り防止や品質向上のためにレビューが重要なプロセスとされています。しかし、レビューアが本来検出すべき欠陥を見逃すことや、欠陥を指摘しても作成者がそれを受け入れず、指摘が反映されないことが少なくありません。
これは、レビューが属人性の高いプロセスであり、「レビューのスキル依存」の問題が常に存在するためです。
そこで我々は、最近注目を浴びている生成AIを活用することで、この問題を解決する可能性を探ることにしました。具体的には、ChatGPTを代表とする大規模言語モデル（LLM）の強みを活かし、レビューアをアシストすることを目指しています。

三菱電機グループは、デジタル基盤「Serendie」を活用した価値創造を推進している。「Serendie」は技術基盤、共創基盤、人財基盤、プロジェクト推進基盤の4つの基盤で構成されており、ソフトウェア開発にとどまらず、様々な活動に展開されている。私たちは、これらの幅広い活動を支えるために、アジャイル開発を前提とした品質マネジメントシステムを構築し、ISO9001認証を取得した。本発表では、特に重要な以下のポイントについて紹介する。

• 価値創造を促進するPoCにおけるアジャイル開発の勘所
• 品質確保のためテスト設計方針を組み込んだ完成の定義
• 客観的視点で品質保証を推進する品質技術者の導入

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

AIセーフティに対する国際的な関心の高まりを踏まえ、AIセーフティの評価手法の検討等を行う機関として、米国や英国と同様に、日本においても、内閣府をはじめ関係省庁、関係機関の協力の下、AIセーフティ・インスティテュート（AISI）を2024年2月に設立した。AIセーフティ・インスティテュート（AISI）の方針、直近の取り組みや世界の最新動向などについて講演する。

マーケティング理論における製品・サービスの品質と ISO/IEC25010:2011で定義されるソフトウェア品質の境界に着目し、 「情緒的品質」という概念を提唱する。
この情緒的品質は、顧客価値の高いソフトウェア開発を目指すエンジニアや品質保証担当者にとって重要な指標となる。リリース後も顧客の反応や受容を継続的に直接観察し、顧客が求める情緒的品質を考慮することで、品質活動はより創造的なものとなる。
なお、この情緒的品質は、昨年度までの研究で提案した「顧客体験品質」をさらに追究することで生まれた概念である。本発表では、情緒的品質の定義や効果、具体的な運用方法について報告する。

重大な不具合が発生した際、なぜなぜ分析などを通じて原因を特定し、チェックリストの整備やプロセス改善といった再発防止策を講じる取り組みは一般的に行われています。しかしながら、実際には同様の問題が繰り返し発生してしまうケースも少なくなく、その一因として、限られた工数や再発防止に関する知見の不足により、問題の本質に十分に迫り切れていないことが挙げられます。
こうした状況に対して、我々は生成AIを活用することで、従来よりも効率的かつ効果的に、本質を捉えた再発防止策の立案が可能になるのではないかと考えました。
本発表では、生成AIを活用したなぜなぜ分析の検討および実践結果を報告します。

DV（Software Defined Vehicle）は、DevOpsのコンセプトを自動車に適用したものであること、SDVによって自動車に対する価値観が変化しつつあることについて述べ、SDVに実現に向けた課題を整理する。講演後半では、サードパーティが開発したアプリケーションをインストールすることができるオープンSDVが、モビリティイノベーションを加速する可能性について述べ、オープンSDVの実現に向けて必須となるビークルAPIの標準化と、それに向けたOpen SDV Initiativeの取り組みについて紹介する。