医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ

© Hitachi, Ltd. 2020. All rights reserved.
医療機器ソフトウェア開発を対象とした
包括的アセスメントのケーススタディ
情報処理学会ソフトウェア工学研究会
ソフトウェアエンジニアリングシンポジウム 2020
一般論文トラック
金子昌永，石川誠，森拓郎
株式会社日立製作所

本ケーススタディの概要
1
包括的な
ソフトウェア
エンジニアリング
アセスメント
において
何を工夫する
ことが適切か？
軽量な自己評価
チームビルディング
成果物の特定，
絞り込み，分析
プロセス推定
IT環境整備
プロセス領域の評価
観測の円滑化
アセッサーによる評価
IT環境整備施策
の実施 (クラウド
ツール導入)
• 対象：医療機器ソフトウェア
• アセッサー：3名 (本論文著者，開発組織外)
• 期間：2019年4月～8月
会議の傍聴

背景 1/2 – 診断，確立の工夫とは？
2
• プロセス領域とレベルは CMMI, SPICE が参考になる
• 診断(Diagnosing), 確立(Establishing)
において何を工夫することが適切か？※IDEALモデル
– 例:情報の在り処として定番のものは？プロセスをどう図示するか？
ヒアリング項目をどう設計するか？
改善施策
改善施策
改善施策
改善施策
改善施策
改善施策
診断,確立

背景 2/2 – IT環境整備プロセスが必要では？
3
プロジェクトマネジメント
リポジトリホスティング継続的インテグレーション
コミュニケーション
• 昨今で欠かせないツールチェーンはWebアプリ
• 関連プロセスの成熟に重要 (例: 構成管理, 問題管理)
• 選定，運用，構築のプロセスは既存標準で扱いなし
要求
→ブランチ→コミット
コミット→
ビルド+テスト
新たな要求,
開発優先度
開発組織内のリアルタイムな情報共有

方法：チームビルディング
4
“最初は，経営・マネージメント層からの号令で組織一体となった活動を行う方がよい”
ソフトウェアプロセス改善と組織学習．2003, 121p
事業部門幹部層，
開発組織マネージャー
アセッサー
ソフトウェア
開発組織
アセスメント実施号令
方針
説明
アセスメント
実施の合意
協力
事業横断部門事業部門

方法：軽量な自己評価
5
• 日立では34のプロセス領域を4段階で自己評価
できるアセスメントモデルを開発，活用している
• 本ケーススタディでは，より深い評価の前段に用い，
各領域のレベルとプロセス全体像を軽量に知る方針
CMMI
SPICE
IEC61508
PMBOK
ISO/IEC27000
34
プロセス
領域

方法：成果物の特定，絞り込み
6
リポジトリファイルサーバー
Bugspots
https://github.com/
igrigorik/bugspots
高スコアファイル
キーワード検索：
組織標準の成果物名,
ESPR2.0の成果物名
https://www.ipa.go.jp/sec/
publish/tn07-005.html
整理された成果物
それが属する
コンポーネント
そのコンポーネントに
関連する成果物
バグトラッキング
サーバー
関連するバグ
まず，ソフトウェア開発組織から在り処を得る
• Bugspots はバグ予測に利用されるのが通例だが，
今回は分析する成果物の絞り込みに応用
• 静的コード解析対象は絞り込まず，全てを分析

方法：プロセスの推定，個人へのヒアリング
7
成果物A
プロセス
成果物B
成果物D
成果物C
組織標準
で既定
実際に
参照している
と推定された
もの
組織標準で規定されたプロセス，
ファイルやリポジトリに示された作成時期,
参照関係から推定，作成者にヒアリング
絞り込んだ成果物についてプロセスを推定し，作成者にヒアリング．
プロセスは Process Flow Diagram (PFD) で図示．
Dはこのプロセスで作られるもの？
A, Bから作ると規定されているがそうか？
C も参照しないと作れないのでは？
他に参照しているものはあるか？
https://affordd.jp/koha_hp/process/PFDform3.pdf

会議の傍聴
8
• 開発組織で日常的に行われる会議を傍聴し，
有用な事実に辿り着くことをねらう
• マネジメント方法を直接観測できる機会
• 成果物，プロセスの名称を得られる機会
• 何の会議があるか，予定表から入手
• 許可を得て，傍聴に徹する (邪魔をしない)
ソフトウェア
開発組織
における
会議
アセッサー観測，記録

方法：IT環境整備プロセスの評価
9
• 評価プロセス
– ソフトウェア開発に関係するIT環境の特定
– それらの利用状況の把握
– アセッサーの持つプラクティスの知識と
利用状況の比較による問題点の特定
• 評価観点
– 関係者全員が機能的に使用できるか
– マシンやネットワークの性能が十分か
– 障害があることを認識して復帰できるか
– アップデート，ユーザー管理，バックアップなどの
保守をできているか

結果：チームビルディング～軽量な自己評価
10
• チームビルディング後，1週間以内に
– サーバーのアセッサー向けアカウント発行
– 会議傍聴の許可
各プロセス領域の自己評価結果と理由
・
・
・
当該ソフトウェア開発の概要が明らかに．
どれほどの大規模かが明らかに．
成果物の在り処，IT環境の情報も
入手．
・～年に～を導入したが～～とはいえず，
現在はレベル2と判断する

結果：成果物の特定，絞り込み
11
リポジトリファイルサーバー
Bugspots スコアと
ファイルパスの表を作成
高スコアファイル整理された成果物
それが属する
コンポーネント
関連する成果物
バグトラッキング
サーバー
関連するバグ
開発組織の協力を得て
特定可能に．
アーキテクチャ，トレーサ
ビリティ情報が必要．
コンポーネント毎ではない
成果物は絞り込みせず．
例: 開発計画, アーキテ
クチャ, 開発環境

結果：ヒアリング
12
• Bugspots で絞り込んだコンポーネントについて
2名がヒアリングに応じた
• 要求～設計～実装～テストという一連のPFDを
もとに，2名作成の現物を題材に質問
リポジトリファイルサーバーバグトラッキング
サーバー
• 推定したプロセスの誤り，一部不明であった参照
成果物の用途が明らかとなった
• 1名あたり1時間で実施

結果：IT環境整備プロセス
13
• 軽量な自己評価，成果物の特定 (開発環境を示
した文書)，会議の傍聴によって使用されている
IT環境が明らかに
• それらを観測し，利用状況を調査
– バグトラッキングサーバーは海外拠点から利用できず
エクスポート，インポートが必要である
– 継続的インテグレーションの一部のジョブは
マシンスペック不足によって実行回数が制限
– サーバー管理者はソフトウェア開発者と兼任

結果：改善の提言と実施
14
• これを機に，クラウド型統合マネジメントツール
Azure DevOps Services の導入と
自動テストの推進を開始

議論
15
軽量な自己評価
チームビルディング
成果物の特定，
絞り込み，分析
プロセス推定
観測の円滑化
会議の傍聴
協力，連絡先特定
概要把握, キーワード特定
絞り込みによる効率化
題材設定による効率化
キーワード, 人物特定
IT環境整備
プロセス領域の評価
IT環境整備
施策の実施
(クラウドツール導入)
リポジトリ, CI などに関連する
個々のプロセスの成熟度を上
げようとしても出てこない．
インフラの視点ならでは．
診断
結果
診断
D
確立
E
アセッサーの能力による
ところが大きく手法化は
道半ば．※GQM, ブレ
スト,ほかには？
※ソフトウェアプロセス改善の基本定石, 2005

展望
16
• 観測の円滑化，IT環境整備について功を奏した
一方で，問題と改善施策導出の方法は道半ば
• サーベイを続ける余地あり
– 参考文献がやや古い．新しいものはあるか？
• CMMによるプロセス改善入門，2001
• ソフトウェアプロセス改善と組織学習，2003
• ソフトウェアプロセス改善の基本定石，2005
• CMMI標準教本，2005
– 類似のケーススタディを見つけられていない．
• 市場でのプロセスを含めたサイクルの全体最適を扱う
DevOps の隆盛に伴い，包括的なプロセス改善の
ニーズが増しているのではないか

医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ

医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ

Ähnlich wie 医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ (20)

医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ