SPI Japan2023 発表概要集
セッション順番 ＞ 発表順番に記載しています。
1A1 声がけで組織のさまざまな壁を越え、本領発揮を引き出すペップトーク 小坂 淳貴（KDDI アジャイル開発センター株式会社） .................................................................................................................................... 2
1A2 Quality Development 元年 松山 大（株式会社 PHONE APPLI） ................................................ 4
1A3 TIS インテックグループにおける、人と組織を開花・開化させる心理的安全性醸成をベースとしたチーム力向上の取り組み「kaika」 川野 いずみ（TIS 株式会社） ........................................................................................... 7
1B1 クラウドサービスのセキュリティ品質点検の仕組み構築と運用 堤 智也（TIS 株式会社） ............................. 16
1B2 設計ドキュメントから抽出した品質確保観点の活用によるソフトウェア品質の向上 内田 智也（株式会社 日立製作所） ..................................................................................................................................... 20
1B3 リーディング技法の適用によるレビュー効果の向上 下川 智士（キヤノン IT ソリューションズ株式会社） .............. 27
2A1 DevOps を実現するための Web アプリテンプレート開発とメンテナンス 三好 秀徳（株式会社日立ソリューションズ）.......................................................................................................................................... 35
2A2 サービス開発初心者チームの運用を意識した DevOps 開発について 木村 慎吾（株式会社インテック） ........... 38
2A3 デジタル・アシスタントによる測定の自動化 中村 伸裕（住友電工情報システム株式会社） .......................... 42
2A4 プロセステーラリングへのプロダクトライン適用の実践 池永 直樹（株式会社デンソークリエイト） ....................... 48
2B1 品質 CoE による品質向上の取組み 小林 一郎（ＳＯＭＰＯシステムズ株式会社） ................................ 54
2B2 クラウド型モデリングツールを活用したチーム全体でのプロジェクトの振り返りと改善 原 義典（リコーIT ソリューションズ株
式会社） ............................................................................................................................... 57
2B3 プロジェクトデータを活用したリスクプロジェクトの検知 常木 翔太（NEC ソリューションイノベータ株式会社） .......... 64
2B4 組織全体での EVM によるプロジェクト進捗管理 川崎 雅弘（パナソニック アドバンストテクノロジー株式会社） .... 67
3A1 越境人財を育てる！共創＆デジタル人財育成 Boost Program 開発 ４転５起 亀田 佳代子（株式会社 東芝） ..................................................................................................................................... 72
3A2 モノづくり力強化の取り組み 野尻 優輝（住友電工情報システム株式会社） .......................................... 82
3A3 安全工学由来のモデリング STAMP を用いた大学院 PSP 教育改善活動の促進 日下部 茂（長崎県立大学） . 89
3B1 続：事業変革を見据えた、品質マネジメントシステムの継続的革新 福田 秀樹（TIS 株式会社） ................. 95
3B2 ソフトウェア開発における DX 活動の道しるべ 寺村 幹夫（株式会社デンソー） ........................................ 98
3B3 アジャイル開発における品質保証移行モデルの提案と実践 石井 裕志（株式会社 東芝） ........................ 102

1

1A1 声がけで組織のさまざまな壁を越え、本領発揮を引き出すペップトーク 小坂 淳貴（KDDI アジャイル開発センター株式
会社）＜タイトル＞
声がけで組織のさまざまな壁を越え、本領発揮を引き出すペップトーク＜サブタイトル＞
AI には代替できない、あなたにしかできないこと＜発表者＞
氏名(ふりがな)：小坂 淳貴(こさか じゅんき)
所属： KDDI アジャイル開発センター株式会社＜共同執筆者＞
氏名(ふりがな)： なし
所属： なし＜主張したい点＞⚫ その人や組織の本領発揮を引き出すには、自分や相手への言葉の選び方や声の掛け方が重要であること⚫ 日頃使われる言葉や表現・伝え方は、その組織の土壌を生み出していること⚫ 人や組織への声がけは(まだ) Chat GPT のような Generative AI で代替されないこと(スポーツが始まりとなっているため誤解されやすいのですが、無理やりポジティブにしようという考え方ではないこと)＜キーワード＞
心理的安全性・内発的動機・本領発揮・ペップトーク＜想定する聴衆＞⚫ 組織でネガティブな言葉に遭遇する人⚫ 組織や目の前にパフォーマンスを上げたい人がいるマネージャー・リーダー⚫ 組織に言葉を届けたい・伝えたいと願っていてもなかなかうまくいかないと感じている人＜活動時期＞
2022 年 8 月〜（現在）＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)◽️ 改善活動を実施したが、結果はまだ明確ではない段階◽️ 改善活動の結果が明確になっている段階□ その他()

2

＜発表内容＞
1.

ペップトークとは⚫ 相手の心に響く声がけがしたい⚫ 自分自身への声がけの大切さ⚫ 自分も周りも大事にする

2.

組織を強化する声がけとペップトークの関係性⚫ 個々の内発的動機を高め本領発揮を引き出す⚫ チームでゴールに向かう⚫ お互いに心理的安全性を高める

3.

今日から始めるペップトーク⚫ 3 つの武器

4.

実践例⚫ メンター・1on1 での声がけ⚫ ネガティブフィードバックの場での伝え方⚫ メールの送信〜選手は体を鍛え技を磨くように、リーダーは言葉の力を磨く〜
ペップトークとは、アメリカで生まれた、スポーツの試合前で行われる選手に向けた激励のショートスピーチから始まっており、
現在、教育やビジネスの現場でも活用されるようになってきた自分や周りへの声がけのことを言います。
私自身、これまで散々ネガティブな言葉で人のやる気を奪ったり、(自分のためを思ってくださっている前提でも)上司や身近な人から奪われたと感じたりしてきた過去が何度もあります。
自分も親も学校の先生も上司の方も、実は励まし方を習ったこと、ないのでは・・・？
私たちがどれだけ組織のためを願ってカイゼンを促そうとしても、受け取る側の人に言葉が届かなければ、実現することができません。
このセッションでは、日頃から目の前の仲間を応援したいと組織に向き合ってきていた私がペップトークと出会い、1 年間、研修と実践を積み重ね自分自身や周りにどんな変化が起こったのか、そして組織にどんな効果があったのかについてご紹介します。
普段のコミュニケーションの範囲を超え、みなさんに個人や組織や課題の壁を越えるきっかけとなるペップトークを知っていた
だき、さらに自分や周りにかける言葉を磨くのに役立つ「3 つの武器」を手に入れていただきます。
A. 参考情報[1]ペップトークとは
https://www.peptalk.jp/%E3%83%9B%E3%83%BC%E3%83%A0/%E3%83%9A%E3%83%83%E3%83%97%E3%83%88%E3%83%BC%E3%82%AF%E3%81%A8%E3%81%AF/3

1A2 Quality Development 元年 松山 大（株式会社 PHONE APPLI）＜タイトル＞
Quality Development 元年＜サブタイトル＞
私たちにとってそれは「Development」だったという話＜発表者＞
氏名(ふりがな)：松山 大（まつやま だい）所属： 株式会社 PHONE APPLI＜共同執筆者＞
氏名(ふりがな)： なし
所属： なし＜主張したい点＞
品質保証や Quality Assurance（または QA）という言葉に追われ、定義や活動方針について
その言葉に縛られることから自身を開放し、全員スッキリと納得した状態から始めるという取り組みについて。
常識的な定義から見直して、自分たちが行っていることを明確に言語化することによって、納得感の高い状態で活動をしていく。
これによって、組織内での活動にどのような変化があるのか。
＜キーワード＞
品質保証、Quality Assurance、QA、文化、Quality Development、QD＜想定する聴衆＞
品質保証や、QA 活動に関わる人。自分の所属しているグループの文化的な側面で課題を感じている人。
＜活動時期＞
2023~開始、継続中＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
■ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

4

＜発表内容＞
1.背景
これまで、テストや品質にまつわる業務に 20 年近く携わってきました。
その中の結構多くの時間を「品質保証とは？」というような文脈から始まる議論で使ってきたと感じています。
また、現時点においてもその部分の定義や説明、その準備に多くのリソースが費やされていると感じています。
それはつまり「品質保証」という言葉が抽象的で、ただ一つの価値観を持つものではないあいまいなものであるということかと思います。
そして、その定義をそれぞれの組織で定義し常にぶれないように注意を払いながら活動をしていっているのかと思います。
（それは悪いことではないと思っています）
ただ、これまでは「品質保証とは」ということ自体に囚われすぎて、本当にそうである必要があるのかどうかという切り口で考えることがなかったので、今回そこに光を当ててみました。
2.改善したいこと「品質保証」や「Quality Assurance（QA）」という言葉の意味や、そのための活動の定義や、定義の組織内への浸透と運用をしていくためのモチベーションやコストを、より納得感のある文脈へ変えることで、活動のスムーズさが変わるのではないかと考えています。
3.改善策を導き出した経緯
もともと、個人的に「品質保証」（または QA）という言葉に疑念を抱え続けていました。
自分が行っている活動は品質を保証する、しているといえるのか？
その議論の末に、そもそも、品質保証という言葉である必要がないのではないかというところにたどり着きました。
4.改善策の内容
１．組織内の定義として「品質保証」（または QA）という言葉を使わない。
２．品質は作りこむものという意味で「Quality Development（QD）」という活動を定義する。
３．Quality Development というチームを作り、QD という活動を一人一人がしていく文化を浸透させていく役割をになう。
5.改善策の実現方法
１．QD エンジニアという役割の定義を決め、周知する。
- 2023 年を QD 文化元年と銘打って社内へ展開
２．QD エンジニアが組織内で活動していくことにより、QD をする文化が育まれていく。
6.改善による変化や効果
・ 品質を保証するという受動的であいまいな状態から、品質を作りこむという能動的で一人一人の具体的な活動へマ
インドが変わる（変える）
・

QA チームが品質を守るというようなイメージから、自分たちの行動で作りこんでいくというイメージへ

・

最終的には QD エンジニアがいなくても QD という文化が定着しているのが理想像

7.改善活動の妥当性確認
・ まだ明確に妥当性を確認できる結果は得られていません。
5

・

引き続き活動を続け、今後のレポートをしていきたいと考えています。

B. 参考情報[1]

6

1A3 TIS インテックグループにおける、人と組織を開花・開化させる心理的安全性醸成をベースとしたチーム力向上の取り組み「kaika」 川野 いずみ（TIS 株式会社）＜タイトル＞TIS インテックグループにおける、人と組織を開花・開化させる心理的安全性醸成をベースとしたチーム力向上の取り組み「kaika」＜サブタイトル＞
チームと人の成長のカギは本当に心理的安全性だった！働きがい向上にもつながる取り組み事例紹介。
＜発表者＞
氏名(ふりがな)：川野いずみ（かわのいずみ）
所属： TIS 株式会社 品質革新本部 エンハンスメント革新部＜共同執筆者＞
氏名(ふりがな)：
所属：＜主張したい点＞
人と組織の成長を生む取り組みをプロセス化できた。事例と共にご紹介。
① お互いの価値観や特性がわかる【話しやすさ】② お互いに興味関心を持ち、一体感が生まれる【助け合い】③ 思いを伝えることで、仕事の工夫が生まれる【挑戦】④ 強みや苦手を共有することで、互いの強みを組合わせた仕事ができ【新奇歓迎】、
従来とは異なるレベルの品質・生産性が実現する。
⑤④と同時に働きがいが向上し、品質・生産性向上・創造性の発揮につながる。
＜キーワード＞
働きがい、GPTW、健康度、
組織目標、基本理念、目指す姿、改善活動、振り返り、チーム、進化、
1on1、育成、利益＜想定する聴衆＞
組織の育成推進者、組織風土文化醸成の推進者、組織の管理者、チームリーダ＜活動時期＞
2021 年 12 月〜継続中ですが、2023 年 5 月までに十分な成果を生みましたので、5 月までの活動を発表。
＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階
7

■ 改善活動の結果が明確になっている段階□ その他()

8

＜発表内容＞
1. 背景【主体】推進組織：TIS 株式会社 品質革新本部エンハンスメント革新部＆人事本部【動機】①個人商店のような働き方で、チームと人の進化が課題の部門の改善活動。GPTW 働きがいのある会社調査の結果が芳しくなかったことをきっかけに取り組み開始。
②①の活動の全社展開【目的】組織と働く人の成長のための風土づくり
2. 改善したいこと
部員同士の横連携をつくり、個人商店のような働き方を見直し、人とチームが成長する組織をつくる。
部員の働きがいと健康度を向上させ、組織と人が進化を続ける仕組みを構築。
① 部員同士のつながりをつくり、相互理解を深める② チームの中に心理的安全性をつくり、意思と意見を表しやすくする
挑戦を生み出す③ 改善を続ける仕組みをつくる（毎月の振り返り活動）
この流れをワークショップ化し、全社展開。
3.改善策を導き出した経緯
2021 年度、モデル部門で 1 年で GPTW 働きがいのある会社調査の結果が 32％向上した成功した取り組みのその後を調査し、人とチームの成長についてヒアリングと調査を実施した。
仕組み化されていることで取り組みが問題なく継続され、人が成長していることがわかった。また、ヒアリングの結果、月１回の 1on1 も人の成長に寄与しており、チームと個人の「振り返り」が成長に寄与していることがわかった。
取り組みを全社展開した結果、取り組み後半年経過した部門で働きがいの数字が 14％向上する成果を上げることができた。現在、グループ会社も含め全社展開推進中。
4.改善策の内容
品質・生産性向上の現場支援をミッションとした品質革新本部が人事本部との協業で推進する取り組み。
2021 年度、モデル部門をつくり、成功した取り組みを 2022 年度全社に展開中。
A:取り組みについての啓蒙、共通認識づくり① 社長メッセージ動画作成と全社展開② 心理的安全性醸成の取り組みのロゴ作成と展開によるイメージ戦略③ 全 80 部門の部門長に 30 分づつ個別ヒアリングを行い、チームづくりと働きがい向上についての成功事例とお困りごとを収集しながら、活動の意義を啓蒙
B:情報の横展開① 各部の成功事例を収集。TIPS 集を作成
② 心理的安全性の e-ラーニング展開
C:取り組み開始の機会づくり①お題に沿って話をし、相互理解を促す Kirari☆Carta 会（14 部門 173 名）② もやもやしていること・心配なことをチームで吐き出す会③ チームが目指す姿・大切なことを言語化する会
をワークショップ形式で実施（2022 年 4 月〜2023 年 3 月まで、13 部門計 481 名）
9Ｄ：推進者の育成① 月１回の kaika ワーキンググループ（12 部門 24 名）で、心理的安全性浸透活動について人と各部事例の横つ
ながりづくり② 各部のチーム振り返り会推進者との横連携、推進者同士をおつなぎする
5.改善策の実現方法
短期間に成果をあげることができた要因として以下をあげることができる。
なお、４．の改善策それぞれについての具体的な実現方法は以下のとおりである。
A:TIS インテックグループの基本理念（OUR PHILOSOPHY）との紐づけ
理念との紐づけにより、活動の一貫性を持たせた。
関連性は＜図表１＞参照。
＜図表１＞

部門長ヒアリングで現場の生の声をきき、現場間の情報流通のかけはしとなった
B：統一フォーマットに、お困り別に事例をまとめ、全社品質ポータルで公開＜図表 2＞のように、お困りごとに事例を一覧化し、詳細は別資料とする、TIPS 集を作成。全社で共有されるポータルサ
イトで公開している。

10

＜図表 2＞

D：浸透施策を品質本だけで推進するのではなく、仲間を増やし、推進者を増やして広げようとしている。
【取り組みが素晴らしいところ】
・全社施策として、一貫性を持たせた取り組みである。
基本理念 OP を体現し、品質・生産性を向上させるチーム力向上の取り組み（re:Born KI）のベースとして位置付けた。結果として、働きがいの向上にも・少人数（1〜4.5 名）の体制で推進してきた平凡な取り組みで最高のチームが増殖している成功事例が拡がり、真似していただくことで、日本企業の働くしあわせ・生産性・品質が向上していく

6.改善による変化や効果
各種アセスメント結果を利用① 働きがい：GPTW 働きがいのある会社調査 ＜図表 3＞② ウェルビーイング：TIS オリジナル調査 ＜図表 4＞③ チームの状況：TIS オリジナル調査＜図表 5＞④ プロジェクトのリスク：TIS オリジナル調査＜図表 6＞11

＜図表 3＞＜図表 4＞＜図表 5＞

プロジェクト健康診断（リスク分析）の結果、リスクを感じる要員の割合が減った（モデル部門 A:2020 年 5 月 32％→2023 年 2 月 10％（22％減））＜図表 6＞③ GPTW 働きがい調査結果（後続部門 B:１年目+14％）＜図表 7＞12

＜図表 8＞③取り組みについてのアンケート結果（代表者の 65％が、チームに具体的な変化が起きた、54％が心理的安全性が高まったと回答。）④ モデル部門の経年利益率＜図表 9＞13

7.改善活動の妥当性確認
以上の取り組みが、組織と働く人の成長のための風土向上に寄与したと言うことができる。
「振り返り」を日常の仕事に組み込むことがポイント。
＜図表 10＞

パーソル総合研究所と慶應大学前野隆司教授の研究結果にある、働きがいと生産性に影響する大きな要素、「組織目標の落とし込み」「肯定的で公正なフィードバック」の機会をつくることが、働きがいに影響し、幸せに働く人の生産性が高い、ということが実証できたと考える。

A. 参考情報・TIS インテックグループ基本理念（OUR PHIROSOPHY）
https://www.tis.co.jp/ir/policy/philosophy/index.html
・TIS 組織図
https://www.tis.co.jp/company/organization/
14[参考情報 1]パーソル総合研究所＋慶應大学前野隆司教授の「はたらく人の幸福学プロジェクト」研究結果
https://rc.persol-group.co.jp/news/202007150001.html

15

1B1 クラウドサービスのセキュリティ品質点検の仕組み構築と運用 堤 智也（TIS 株式会社）＜タイトル＞
クラウドサービスのセキュリティ品質点検の仕組み構築と運用＜サブタイトル＞
多様なクラウドサービス基盤を活用し、迅速にサービスを立ち上げて安全に価値提供するための要点＜発表者＞
氏名(ふりがな)：堤智也(つつみともや)
所属： TIS 株式会社
＜共同執筆者＞
氏名(ふりがな)： 安永実(やすながみのる)
所属： TIS 株式会社
＜主張したい点＞
クラウドサービスをセキュアに提供し顧客に価値を届けるためには企画・設計段階から公的規格に沿った実践が必要になります。当社では規格に基づいたチェックリストを設け審査体制を整えることでセキュリティ品質を確保しています。
＜キーワード＞クラウドサービス、クラウドセキュリティ、ISO27017、審査、品質監査、＜想定する聴衆＞
クラウドサービス企画・開発・提供者
セキュリティ担当者＜活動時期＞
2020 年 10 月〜現在
＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

16

＜発表内容＞
1.背景
1)当社ではクラウドサービスの提供、利用が本格化しており、2017 年に ISO27017 に準拠したクラウドセキュリティ基
準（クラウドサービス提供編および利用編）を制定しているが、基準未達のままローンチする事例が散見された。
2)クラウドセキュリティ認定制度として、以下の制度が運用開始されていたが、「質で語られる信頼のトップブランド」を目指す当社として、早急に導入する必要がある。
・「ISMS クラウドセキュリティ認証制度」(通称：ISO27017 認証)/JIPDEC
・「クラウド情報セキュリティ監査制度」(通称：CS マーク)/JASA
3)クラウドセキュリティ基準の遵守性確認、監査制度の導入を推進する体制がなく、人材も不足していた。
2.改善したいこと
1) ローンチ時点でのクラウドサービスの品質向上
2) ISO27017 外部認証の取得
3) 内部監査体制の確立と要員育成
3.改善策を導き出した経緯
1) クラウドセキュリティ基準だけでは難解であり、現場に浸透しづらいことから、チェックリスト形式で判断基準を明確にする
ことで現場への定着を図る。
2) いきなり ISO27017 認証を取得するのではなく、まず社内基準での内部監査・審査を実施し、段階的にレベルアップを図ることで現場のハレーションを回避する。
3) 専門組織を品質革新本部内に設け、知見のある有識者をアサインすることで体制を確立する。
4.改善策の内容
1)クラウドセキュリティ基準をベースにクラウド情報セキュリティ監査制度の内容を加味したチェックリストを作成。
a) 基準の条文をわかりやすく表現を変えて記載。場合によっては複数の確認項目に分けて記載。
b)確認項目の文中で説明を要する用語等に関連する例示や補足を記載
c)「対応不要」、「対応見送り」の選択肢を設け、セルフチェックのハードルを下げたd)提供中サービスから複数選定して試行を依頼
2)クラウドセキュリティチェックリストによるセルフチェックと第三者組織による審査の運用定着a)組織長をその気にさせる・・・トップダウンの力を借りる経営層が参加する会議で趣旨説明して賛同を得る・・・経営の意思化
組織長に趣旨を理解してもらい、配下部門に指示してもらう・・・組織の施策化
各組織の品質マネジメントシステム責任者に趣旨を理解してもらう・・・展開力増幅b)支援活動を充実・・・ダメというだけでなく、じゃあどうすればいいのに応える活動
セルフチェック結果の確認後、即審査ではなく、改善ポイントを伝え、改善を促すことに注力
ローンチ前の点検だけでなく、企画・設計段階でも相談に乗ることを表明
ISO27017 認証取得支援活動開始
c)雰囲気つくり・・・取り組んだ方がいいかなと思わせる
認証サービスの一覧公開
認証ロゴの制定（現在作成中）
3)審査を実施する第三者組織を立ち上げ（「品質監査室」立ち上げ）
17a)セキュリティに関する有識者を他組織から招聘
当社に ISMS を導入した際の中心人物、セキュリティの知見がある人物
b)セキュリティコンサル外販部隊との協業体制構築
セキュリティコンサル外販で培った知見・ノウハウを社内向けに注入
社内向け点検で経験を蓄積し、外販ビジネスのレベルアップに寄与
5.改善策の実現方法
1) チェックリストの作成にあたって⚫

「品質監査室」の体制が充分でないため、すべての審査項目を審査員がチェックするのではなく、現場(クラウドサー
ビス提供者)がセルフチェックにより自己確認した上で、その結果の妥当性を審査員がチェックする方式を採用した。

⚫

審査項目ごとの確認事項を明確に定義した他、問い合わせの多い項目などについて例示・補足欄に記載を追加するなど、試行や実運用を通じて改善サイクルを回している。

2) セルフチェックと審査の運用定着にあたって⚫

施策開始当初は認知不足もあり、また現場側の当事者意識も低く、クラウドサービスを提供していてもセルフチェッ
クを実施しない事態が散見された。
4. 2) a) に示したように経営層・組織長層・品質マネジメントシステム責任者の層別アプローチのほか、当社ホームページでサービス紹介しているものを対象に個別アプローチしてセルフチェックの実施及び品質監査室への提出を促した。

⚫

品質革新本部(品質監査室の上部組織)の主催する、システム品質に関する会議体に上程されたサービスに対して、個別に案内・支援することでセルフチェックの実施及び提出を促した。

3) 審査実施組織の立ち上げにあたって⚫

従前の監査部体制では技術的専門性の観点から充分な監査が実施できず、また単なる審査(OK/NG の判定)
のみならず改善支援という役割を重視したことから、品質マネジメントシステムの主幹本部である品質革新本部の部内室として「品質監査室」を新たに設けた。

6.改善による変化や効果⚫

クラウドセキュリティチェックリストによるセルフチェックと品監審査の運用定着
クラウドサービスに該当するサービスは全件審査実施（2022 年度対象サービス数：33）
毎年必ずセルフチェック結果が提出されている
新規サービスについても自発的な提出が増えている⚫

平均遵守率が向上 2020 年度：68%⇒2022 年度：96%
フォローアップ審査回数が減少
フォローアップ率：77%(2020 年度)⇒36%(2022 年度)⚫

ISO27017 認証取得するサービスが年々増加
2023 年度はさらに 2 サービスに対し、認証取得に向け支援中⚫

グループ会社にもセルフチェック及び審査が徐々に浸透
2022 年度よりグループ会社 2 社に対して審査開始

7.改善活動の妥当性確認⚫

クラウドセキュリティ基準を遵守するという文化が根付いてきている
チェックリストでセルフチェックして、品監に提出して指摘・助言をもらうということが当たり前になりつつある。
18

⚫

クラウドセキュリティ点検がサービスの価値を上げることにつながるという共通認識が芽生えた
ローンチ前のセルフチェック・提出だけでなく、企画や設計段階でチェックリストを確認して、品監に相談する事例が増えてきている⚫

提出されたチェックリストに対し遅滞なく、適切な指摘・助言ができる体制は確立できた

B. 参考情報[1]19

1B2 設計ドキュメントから抽出した品質確保観点の活用によるソフトウェア品質の向上 内田 智也（株式会社 日立製作所）

＜タイトル＞
設計ドキュメントから抽出した品質確保観点の活用によるソフトウェア品質の向上＜サブタイトル＞
テキストマイニング技術を活用した設計ドキュメント分析＜発表者＞
氏名(ふりがな)：内田 智也（うちだ ともや）
所属： 株式会社 日立製作所 デジタルプラットフォーム事業部 ミドルウェア本部 生産技術部＜共同執筆者＞
氏名(ふりがな)： 香西 周作（こうざい しゅうさく）
所属： 株式会社 日立製作所 デジタルプラットフォーム事業部 ミドルウェア本部 生産技術部＜主張したい点＞
大規模ソフトウェアの開発において、設計ドキュメントに記載された内容から品質確保観点を抽出し、その情報をテスト作業で活用するために、テキストマイニング技術を活用した施策①仕様書からの品質確保観点の抽出、②テストドキュメントのテスト観点チェック、③仕様書とテストドキュメントのテスト観点突合せ、を考案し、実際のソフトウェア開発プロジェクトに適用した。効果としては、施策②については実際のプロジェクトにおいてテスト観点
漏れの検出および潜在不良摘出といった効果があった。また施策①および③についても実際のプロジェクトで試
験適用を実施し結果が妥当であることが検証できている。他開発プロジェクトからも利用要望の声を多くいただ
いており、今後多くのプロジェクトに適用し、効果をあげることが期待できる。
＜キーワード＞V 字モデル、品質確保観点、テスト観点、仕様書、テストドキュメント、テキストマイニング、KH Coder＜想定する聴衆＞
・製品開発担当者
・SEPG 部門の方・品質保証部門の方＜活動時期＞
2017 年〜継続＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

20

＜発表内容＞
1.背景
筆者の所属する事業部では、ミッションクリティカルな社会 IT 基盤で使用されるソフトウェア製品(DB 製品、データコミュ
ニケーション製品、アプリケーションサーバ製品等)や、メインフレーム向け OS 等の開発、保守を行っている。これらの製品は、停止すると社会的にも大きな影響を与えることから、品質の確保が重要となっている。
2.改善したいこと多くの製品開発プロジェクトでは、品質確保に関する基本的な考え方として V 字モデルを採用している。V 字モデルは、設計作業で検討した設計内容に問題が無いかをテスト作業で確認することにより品質を確保するモデルである。 (図 1
V 字モデル)
当事業部の製品は古いもので 1970 年代から開発、エンハンスをし続けてきており、仕様書の量も膨大であり、また考慮すべき観点も多いため、テスト作業において、設計作業で考慮した内容を漏れなく品質確保観点としてあげるのが困難という課題がある。また、各製品のテスト観点は各製品の熟練担当者のノウハウに依存する面も多いが、定年による退職や、事業シフトにともなう担当者の変更等により、こうしたノウハウがすべて引き継がれず、引き継ぎ後に漏れる可能性がある。テスト観点が漏れてしまうと不良摘出がされないまま製品がリリースされてしまい、不良がある製品がリリースされることで、それを使用するシステム環境の安定稼働に重大な影響を与えてしまう可能性がある。

図 1

V 字モデル

3.改善策を導き出した経緯
設計作業での検討内容を記述した仕様書から考慮すべき品質確保観点を抽出、およびテストドキュメントに記述されているテスト観点を抽出することで、テスト観点の漏れを防止する施策を考えた。
筆者の所属する事業部では、これまでの障害事例等をまとめた事業部共通のテスト観点集、テスト事例集が存在する。
テスト観点集、テスト事例集の内容を基にして製品に必要な品質確保観点・テスト観点を設定して、設定した品質確保
観点・テスト観点を仕様書やテストドキュメントから抽出する。
抽出の流れとして、まず仕様書の記載を分析して、テスト観点集、テスト事例集の主要キーワードと照合して、その製品の仕様検討時、設計時に品質面で考慮すべき項目を抽出する。次にテストドキュメントに対して同様の分析を実施して抽出した品質面で考慮すべき項目(テスト観点)と比較することで、設計作業での仕様検討時において考慮した品質確保観点が、漏れなくテストドキュメントに反映されているかを機械的にチェックできるようになる。
21

4.改善策の内容
4.1 改善策の全体像
テキストマイニングツール(OSS のテキストマイニングツールである KH Coder)を活用して、仕様書の記載内容に含まれる品質確保観点、およびテストドキュメントに含まれるテスト観点を抽出する。そして、仕様書から抽出した品質確保観点の結果と、テストドキュメントから抽出したテスト観点の結果を突合せて相互チェックを行うことで、仕様書検討漏れやテスト
観点漏れを検出する。抽出にあたっては事業所共通のテスト観点集の内容に基づいて観点項目のチェックルールを作成しておき、KH Coder を通してチェックを行い、チェックルールに該当するキーワードが含まれて居る場合には、その品質確保観点またはテスト観点があると判断する。改善策の全体像を「図 2 改善策の全体像」に示す。
改善策は下記の３つの施策から成る。
① 仕様書からの品質確保観点抽出② テストドキュメントのテスト観点チェック③ 仕様書とテストドキュメントのテスト観点突合せ

図 2 改善策の全体像
4.2 ①仕様書からの品質確保観点抽出
本施策では、設計内容が記載された仕様書の記述を分析し、仕様書の記述内容に含まれる品質確保観点を抽出する。本施策の抽出結果にもとづき、その製品の仕様書に記載が必要な品質確保観点が漏れていないか見直しをすることが可能となり、仕様検討漏れの防止や、テストに必要な観点を挙げることが可能となる。
4.3 ②テストドキュメントのテスト観点チェック
本施策では、設計者の作成したテスト仕様書やマトリクスチェックリストが、事業所共通のテスト観点集に記載のテスト
観点をどの程度網羅できているかを可視化する。本施策のチェック結果にもとづき、該当製品で必要なテスト観点が網羅できているか確認することが可能となり、観点が不足している場合は、テスト項目の追加を検討する等の対策を実施することでテスト観点の漏れを防止することが可能となる。

22

4.4 ③仕様書とテストドキュメントのテスト観点突合せ
本施策では、「①仕様書からの品質確保観点抽出」による仕様書に含まれる品質確保観点の抽出結果と、「②テストドキュメントのテスト観点チェック」によるテストドキュメントに含まれるテスト観点チェックの結果とを突合せて比較をすることで、設計内容とテスト内容の相互チェックが可能となる。相互チェック結果に差異がある場合、仕様書にあってテストドキュメン
トにない観点については、実施するテストに観点漏れがないか、逆に仕様書になくテストドキュメントにある観点についは、仕様書での検討漏れがないかといったことを確認することが可能となり、テスト観点漏れや仕様検討漏れを防止することが可能となる。
5.改善策の実現方法
5.1 実現方法の全体像
施策の実現方法の全体像を「図 3 施策の実現方法の全体像」に示す。

図 3 施策の実現方法の全体像
当事業部のテスト観点集には、過去に発生した障害事例の情報と、同様の障害の発生を防止するためのテスト観点とその解説が記載されている。このテスト観点は品質確保観点と捉えることもできる。これらの情報からテスト観点毎に主要なキーワードを抜き出し、それらのキーワードが仕様書やテストドキュメントに含まれているかをチェックすることで、テスト観点集に含まれるテスト観点がどの程度、テストドキュメントに含まれているかを確認することができるようになる。
キーワードが含まれているかのチェックは、OSS のテキストマイニングツールである KH Coder の「コーディングルール機能」
を活用している。この機能は、複数のキーワードの論理式で表現される「コンセプト」を数え上げる機能である。例えば、「資源のリーク」というコンセプトに対して、( メモリ and ( 確保 or 解放 ) )のような論理式を定義しておくと、「メモリ」と「確保」、「メモリ」と「解放」のような記述を抽出できる。
本施策において、「コンセプト」には、テスト観点集に記載されている「テスト観点」を設定した。また、このテスト観点(コンセプト)毎にテスト観点集から抽出したキーワードを用い、いくつかのプロジェクトで試行しながらコーディングルールの論理式を作成した。
5.2 ①仕様書からの品質確保観点抽出
本施策では設計者にチェック対象となる仕様書を提供していただく。それらの仕様書から当部署にて KH Coder のコー
ディングルール機能を用いて含まれている品質確保観点を抽出する。
23

KH Coder のコーディングルールに合致する記述の有無を分析する際、１回の分析におけるルールの適用範囲をどのように設定するかを、分析対象のドキュメントに合わせて適切に設定する必要がある。仕様書の場合は、仕様が文章として記述されているため、コーディングルールの判定に必要なキーワードは、文章を文単位に分割して判定する必要がある。な
ぜなら、文章中に含まれるキーワードは多彩であるため、複数の文に個別に記載されているキーワードにヒットし、誤検知してしまう可能性が高まるためである。
例えば、分析対象の文章が「このプロセスはメモリ管理を実施する。・・・・。ファイルの更新が完了すると排他制御によりロックを解放する。・・・・・。」という文章に対し、先の例にあげた「資源のリーク」のコーディングルール( メモリ and ( 確保or 解放 ) ) で判定を行う場合、文章全体で判定をしてしまうと、このルールにヒットしてしまうが、実際にこの記述はシス
テム構成変更に関する記述ではないため、誤検知となってしまう。
そこで仕様書に対しては、文単位で判定をするように設定した。
また、仕様書の記載方法は、プログラムの機能項目や機能内容毎に章・節・項、さらには必要に応じて項より下位のチャプターに区切って記載されている。そこで、分析結果はチャプター単位でまとめるようにし、設計者にどの箇所に該当する記述があるかを提示できるようにした。
5.3 ②テストドキュメントのテスト観点チェック
本施策では設計者にチェック対象となるテストドキュメントを提供していただく。それらのドキュメントから当部署にてテスト
項目の記述を抽出し、KH Coder のコーディングルール機能を用いて含まれているテスト観点を抽出する。
また、他の類似製品との比較を行って、不足しているテスト観点があれば、それらを別途報告資料にまとめ、設計者に伝えるようにした。
テストドキュメントは、テスト対象となる機能やテストの着眼点(性能評価、デグレード防止等)などにもとづいて記載されている。例えばテストドキュメントが Excel に記載されている場合はそれらの分類が１行ごとや１シートごとに記載されている。
そこで、分析の観点に沿うよう、分析対象テストドキュメントの構成を分析して考慮してから、テスト項目を抽出し、テスト
項目単位でコーディングルールに合致するかどうかの判定処理を行うようにした。
5.４ ③仕様書とテストドキュメントのテスト観点突合せ
本施策では「①仕様書からの品質確保観点抽出」と「②テストドキュメントのテスト観点チェック」の結果に対して、双方の品質確保観点とテスト観点の観点あり・観点なしの結果を突合せて比較を行い、仕様書とテストドキュメントの両方の結果が一致(観点ありで一致もしくは観点なしで一致)、仕様書のみにある観点、テストドキュメントのみにある観点の結果を表の形式にまとめた。（図 4 ③仕様書とテストドキュメントのテスト観点突合せ）
またその結果から、仕様書のみにある観点についてはテストドキュメントにテスト漏れがないか、テストドキュメントのみにある観点については仕様書に記載漏れがないかを見直していただくよう、設計者に提示した。

24

図 4 ③仕様書とテストドキュメントのテスト観点突合せ
6.改善による変化や効果
6.1 施策全体の適用効果「①仕様書からの品質確保観点抽出」施策および「②テストドキュメントのテスト観点チェック」施策については、それぞれ単体でも適用し効果をあげることが可能である。特に「②テストドキュメントのテスト観点チェック」施策は、先行して 2017
年から先行して当事業部内で展開しており、テスト観点漏れを抽出する等の成果をあげている。
「①仕様書からの品質確保観点抽出」施策および「③仕様書とテストドキュメントのテスト観点突合せ」については
2022 年から展開を開始した施策であるが、多くのプロジェクトに興味を持っていただいており適用拡大中である。
6.2 ①仕様書からの品質確保観点抽出施策の適用効果
本施策を当事業部の１つの基幹ソフトウェア製品の仕様書に対して試験的に適用した。仕様書の記載内容と抽出した品質確保観点の一致性を調べたところ、ほぼ記載内容に沿ったテスト観点を抽出できていることが検証できた。この結果をもって、その製品では、現在開発中のバージョンにおいて正式に適用することとなった。
開発中のバージョンへの適用にあたっては、製品全体ではなく、開発項目ごとに品質確保観点を抽出してほしいという要望をいただいた。そこで、前バージョンの仕様書との差分を抽出し、各差分を各開発項目に分類した上で、5.2 節で説明した施策を適用した。本結果については、開発部署に報告し、仕様書の記述の見直し等において活用いただいている。
また、他の多くのソフトウェア製品開発プロジェクトにも本施策に興味をもっていただいており、現在適用プロジェクトを拡大中である。
6.3 ②テストドキュメントのテスト観点チェック施策の適用効果「②テストドキュメントのテスト観点チェック施策」は、本施策単独でも、当事業部の基幹ソフトウェア製品のテスト作業で活用している。その結果、あるプロジェクトでは 9 件のテスト観点漏れを検出することができ、同時にチェック結果を活用したソースコードレビューにおいては 2 件の潜在不良を摘出することができた。また、観点の不足が検出されなかったプロジェクトにおいても、テストドキュメントの作成、レビュー結果に問題がないというエビデンスが得られたので有用であるとの評価をいた
だいている。
他にも他事業部から移管された製品について、当事業部で求める品質レベルに達しているかの検証のため、過去バージョンのテストドキュメントをチェックしたいという用途や、次バージョン開発のため前バージョンのテストドキュメントをチェックして観点の過不足をチェックしてほしいという用途等、幅広い用途で活用されている。
25

6.4 ③仕様書とテストドキュメントのテスト観点突合せの適用効果
6.2 節で説明した「①仕様書からの品質確保観点抽出」施策の正式適用プロジェクト(現在開発中のプロジェクト)において本施策を適用し、仕様書から抽出した品質確保観点と、テストドキュメントから抽出したテスト観点の突き合わせを実施したところ、大部分は一致していたが、一部、差異があるという結果になった。
この差異がある項目について分析をしたところ、主にヒートラン確認や過去の障害事例の確認等、製品全体の動作に関する品質確認観点・テスト観点であった。今回の開発中プロジェクトへの適用においては、6.2 節で述べたように開発項
目単位での分析に絞ったため、製品全体の動作確認に関する観点は突き合わせの対象外となっていた。開発項目単位に絞った観点の分析結果については、仕様書とテストドキュメントで観点はほぼ一致していた。
以上のことから、分析対象を絞った部分については的確な分析ができており、また、分析対象から外した部分については、漏れとして検出ができていることから、本施策が狙いとする効果が得られている。
7.改善活動の妥当性確認
施策「②テストドキュメントのテスト観点チェック」については、既に施策を事業所内に正式サービスとして展開しており、いくつかのプロジェクトで適用いただいている。エンハンス時に継続して利用したい旨の依頼をいただいており、施策の適用リピート率も高い。また新規適用プロジェクト数も年々増加している。
施策「①仕様書からの品質確保観点抽出」および「③仕様書とテストドキュメントのテスト観点突合せ」については、試行を実施したプロジェクトでは正式採用されていたり、他製品開発プロジェクトからも多くの説明依頼や引き合いをいただいていたりしており、ニーズの高いことが分かっている。
以上のことから、これら３つの施策は大規模ソフトウェア開発における品質確保の視点で製品開発プロジェクトのニーズに応える的確な施策であったと考えている。
C. 参考情報[1] 香西 周作、内田 智也、北川 福太郎 (2022). 設計資産分析による大規模ソフトウェアのエンハンス作業効率化〜熟練者/前任者ナレッジの活用〜 SPI Japan 2022
https://www.jaspic.org/event/2022/SPIJapan/session1B/1B2_004.pdf[2] 樋口 耕一 (2020). 社会調査のための計量テキスト分析 第 2 版 ナカニシヤ出版[3] 保田 勝道 (1995). ソフトウェア品質保証の考え方と実際 日科技連出版

26

1B3 リーディング技法の適用によるレビュー効果の向上 下川 智士（キヤノン IT ソリューションズ株式会社）＜タイトル＞
リーディング技法の適用によるレビュー効果の向上＜サブタイトル＞
現場ではたらくエンジニアによる レビュー技法の調査・研究・現場への適用＜発表者＞
氏名(ふりがな)：下川 智士（しもかわ さとし）
所属：キヤノン IT ソリューションズ株式会社＜共同執筆者＞
氏名(ふりがな)： 岡崎 和生（おかざき かずき）、見藤 宏治（けんどう こうじ）、
小林 真人（こばやし まこと）、菅 良輔（かん りょうすけ）
所属：キヤノン IT ソリューションズ株式会社＜主張したい点＞
現場ではたらくエンジニアが改善したいレビュー課題を持ち寄り、参加者から最も共感が得られた課題「レビュー精度が一定ではない」に対し、効果が期待できるレビュー技法調査して選出した「パースペクティブ・ベースド・リーディング」技法を研究し、実際の現場へ適用した結果とその評価。
＜キーワード＞レビュー、パースペクティブベースドリーディング、PBR、リーディング技法＜想定する聴衆＞
プロジェクトマネージャ、プロジェクトリーダ、レビュー計画者、レビュー担当者＜活動時期＞
2022 年 3 月〜12 月＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

27

＜発表内容＞
1.背景
キヤノン IT ソリューションズ株式会社（以下、CITS と略記）では、現場で行われている改善活動を活性化させ、現場主導による改善活動を企業風土として定着させる事を目的として、2021 年度に社内の分科会活動を開始した。年初に掲げた２つのテーマのもと、各部門の中堅技術者を主体とするメンバが集まり、テーマに造詣の深いアドバイザ（社外有識者）の助言をもらいながら、持ち寄った現場の課題について年間 10 回の会合でディスカッションを行い、年末に成果を報告するスタイルで活動を継続している。
今回は 2022 年度第一分科会レビューグループが分科会活動で得た知見および成果について発表する。
CITS 分科会活動
年度

テーマ

グループ（サブテーマ）

人数2021 年度

第一分科会（品質技術と品質マインド）４グループ（詳細割愛）

18 名

第二分科会（デザインとアジャイルの融合）

３グループ（詳細割愛）

13 名第一分科会（品質技術とメトリクス）

レビュー

6名

テスト

5名

基盤構築

3名

C＋１

4名

育メタ

4名

レビュー・技法

6名

レビュー・メトリクス

5名

テスト・メトリクス

7名

基盤構築

7名

アジャイル・ガイドライン

5名

アジャイル・品質

4名

2022 年度

第二分科会（顧客価値とアジャイル開発）
2023 年度

第一分科会（品質技術とメトリクス）

第二分科会（顧客価値とアジャイル開発）

2.改善したいこと2022 年度第一分科会レビューグループが選定した課題は下記の通り。
＜課題＞
レビュー精度が一定ではない＜原因＞
・有識者がレビューに参加できないことが多い。
・レビューアの知識不足により、十分なレビューとならない。
また、有識者が実施する視点・観点でレビューができていない。

28

発表テーマ

3.改善策を導き出した経緯
各現場から持ち寄った困りごと（レビュー課題・問題点）の中から、参加者から最も共感が得られた課題が「レビュー精度が一定ではない」であり、その原因である「有識者のレビュー不参加」「レビューアの視点・観点のバラつき」を解消するために効果が期待できる解決策として「チェックリスト・ベースド・リーディング」「パースペクティブベースドリーディング」を候補として選定、さらに、現場適用するまでにハードルが低い技法を検討した結果「パースペクティブベースドリーデ
ィング」を適用することにした。
＜持ち寄った課題＞
No.

課題

原因

1

レビューの精度が一定ではない

有識者がレビューに参加できないことが多い。
レビューアの知識不足により、十分なレビューとならない。また、 対策課題
有識者が実施する視点・観点でレビューできていない。

2

開発工程間での仕様不整合

レビューを成果物だけで行っている。

開発工程間(要件定義⇒外部設計等)⇒成果物のインプットとなる資料との比較・整合性確認を行ってで、作成した成果物に記載漏れや認識齟いない。

齬による仕様不整合をレビューで検知できない。
3

似通った語句の認識齟齬

レビューの確認観点が不明確となっており、注意すべきキーワー『似通った語句』を誤って用いている箇所をドに着目していない。

レビューで検知できない。
例）「年度」ではなく「充当先＿年度」＜各課題に効果が期待できる技法の選出＞
No.

課題

解決策

1

レビューの精度が一定ではない

チェックリスト・ベースド・リーディング
チェックリストを利用して読む方法でレビュー漏れ、
レビュー観点のブレを抑制できる。※ただし、リストが肥大化に注意
パースペクティブベースドリーディング
ユーザー、設計者、開発者のような特定の立場・視点に基づいて読む方
法で、多様な視点・観点からレビューが可能。

2

開発工程間での仕様不整合

V&V(Verification & Validation)
インプット資料と見比べて、要求と合致しているか妥当性確認(Validation)とインプットに対してアウトプットが正しいかの検証(Verification)を行う

3

似通った語句の認識齟齬

チェックリスト・ベースド・リーディング
前述と同じ。

29

適用技法参考）その他、対策候補として検討したレビュー技法、リーディング技法
No.

レビュー技法概要・特徴

1

インスペクション

最も公式なレビュー。仕様書や要件書などのドキュメント・確認事項のリストなどを元に、レビューアやモデレーターなど各役割を担う関係者を参加させてレビューを行う。レビュー結果を記録し、チームや組織全体にフィードバックしてさらなる改善を図るような取り組み。

2

チームレビュー

チームにより実施されるレビュー。
障害摘出以外に、チーム内の知識共有・教育などの副次的な効果が期待できる。

3

テクニカルレビュー

技術の専門家が参加するレビューで、仕様書やソースコードなどの成果物の問題を主な目的として実施。

4

ウォークスルー作成者が数人のレビューアを招集し、成果物の内容を順に説明する形式をとる。障害発見だけでな
く、参加者の理解促進や問題に対する解決アイデア抽出等にも活用される。

5

ラウンドロビンレビュー

レビュー参加者全員が順に司会者とレビューアの役を持ち回りで務める方式のレビューで、回転式レ
ビューとも呼ばれる。

6

ペアプログラミング

2 名が一つのマシンを共有して共同でプログラミングを行う方法であり、レビュー方法の一つとしても位置付けられる。

7

ピアデスクチェック

成果物の作成者に机上での障害の発見にたけたレビューアを 1 名加えて実施するレビュー。

8

パスアラウンド

成果物を複数のレビューアへ配布、または回覧を行うことにより、障害の指摘を行う。
対面で行う必要がなく、タイムマネジメントの面で有用。

9

モダンコードレビュー

専用ツールまたは SNS などの利用を前提としたコードレビューの総称。例えば、開発者はツールを介してレビュー依頼し、レビューアはツールを用いてソースコードへの指摘を残すという方法がある。

10

アドホックレビュー

非公式なレビュー。第三者の視点から指摘を得ることにより、客観的に問題を把握して解決を図ることを目的とする。即時実施されることから即席レビューとも呼ばれる。

No.

リーディング技法

概要・特徴

1

アドホックリーディング

・特定の手順に従わない読み方。
・気軽に実施できる。レビューの成果はレビューアに依存する。

2
3

チェックリスト・チェックリストを利用して読む方法。

ベースドリーディング・レビュー漏れ、レビュー観点のブレを抑制できる。リストが肥大化しがち。

シナリオベースド

・利用シナリオ、品質シナリオなどに基づいて読む方法。

リーディング

・具体的なシナリオに基づいてレビューができる。
・シナリオ作成に手間がかかる。

4
5
6

ディフェクトベースド・障害が混入しやすい箇所を含むシナリオに従って読む方法。

リーディング・特定の障害検知には有効。シナリオ作成に手間がかかる。

パースペクティブベースド・ユーザー、設計者、開発者のような特定の立場・視点に基づいて読む方法。

リーディング・多様な視点・観点からレビューが可能。

ユーセージベースド・ユースケースシナリオ等の利用者の利用手順に従って読む方法。

リーディング・ユースケース作成後に作成されたドキュメントレビューに有効。

30

4.改善策の内容
パースペクティブベースドリーディング（PBR）を実際に現場で適用し、レビュー品質向上に効果があるかを評価する。
PBR は、各レビューアに特定の視点を割り当てて、その視点でレビュー対象物をずっと読んでいく方法。
特定の視点のなかで、必ず設定したほうがよいのは、設計者、テスター、顧客の３つの視点。
3 つ以外の視点は、レビュー対象物の特性に合わせて設定すればよいと言われいる。
例）運用が難しいシステム特性がある場合は、システム運用者の視点を設定する【設計者の視点】
今後それを詳細化して設計していく人の視点であり、ウォーターフォールモデルでいえば、次の工程でその機能を設計する人の立場で、その記載内容で、次の工程の設計・開発ができるかという視点で読んでいく。
【テスターの視点】
その記載内容で、その仕様のテストができるかという視点で見るということで、設計内容をテストの視点で読むと、抜け漏れや不明点が見つかることがある。
【顧客の視点】
その仕様で、顧客が満足するかという観点で見るということ。顧客の立場での仕様の十分性を確認する。

＜PBR の特徴＞
・多様な視点・観点からレビューが可能
・チェックリストを用意する必要ないため、導入のハードルが低い。
・レビューアの知識が無くても導入可能。
＜PBR の現場適用状況＞
・現場適用されているケースが少ない。（少なくとも分科会参加メンバ内ではなし）
出典：https://ideson-worx.com/レビューのリーディング方法/

31

5.改善策の実現方法
１）架空の要求仕様書「話題沸騰ポット」を題材に PBR の適用実験
現場への適用機会が作れない参加メンバもいるため、架空の要求仕様書「話題沸騰ポット」を題材に PBR の適用実験を実施した。

※出典
組込みソフトウェア管理者・技術者育成研究会（SESSAME） 組込
み系システム教材 「話題沸騰ポット」要求仕様書
https://www.sessame.jp/workinggroup/WorkingGroup2/P
OT_Specification.htm■評価方法
・ PBR とアドホックリーディング（AHR）で担当を分けてレビューを実施、指摘件数を比較する。
・ 架空の要求仕様書「話題沸騰ポット」を使用■評価結果１：レビュー指摘件数
リーディング技法

指摘件数（1 人平均）（1 時間あたり）PBR(パースペクティブベースドリーディング)

4.5 件

7.3 件

AHR(アドホックリーディング)

5.6 件

7.1 件

⇒PBR と AHR の指摘件数、生産性に大きな違いは見受けられない。 ※指摘総件数はむしろ少ない■評価結果２：レビュー指摘内容
PBR、AHR の指摘内容をみると、以下の傾向が見受けられた。
リーディング技法
PBR(パースペクティブベースドリーディング)

指摘内容の傾向・利用者視点等の定義した観点・視点の指摘ができている。
・レビュー視点を絞るため、指摘数は少なくなる傾向。

AHR(アドホックリーディング)・指摘内容に偏りがある。
(開発者が行ったため、設計・開発者観点での指摘がほとんど)・利用者、品質特性視点：安全性を考慮した製品としての最低限担保すべき部分の指摘は全くできていない。

⇒PBR を活用することで、定義した視点・観点での指摘が可能。
２）分科会参加メンバが自身の現場へ持ち帰り、PBR を実際に適用したレビューを実施
各メンバのプロジェクトで、レビューに PBR を適用
適用フェーズは要件定義、外部設計、内部設計、結合テスト、問合せ(QA)対応※結果は次章以降に記載
32

6.改善による変化や効果
実際の現場で PBR を適用したときの効果（良い点）と内容は下の通り。
効果

内容

レビュー指摘の検出

ユーザー、テスト担当者視点でレビューすることで設計書、テストケースの漏れ、
曖昧さを指摘できた。

テストを意識した設計書

テスト担当者視点でレビューすることで、テストを意識した設計書の記載につながった。

ユーザー向け資料の品質向上

ユーザー視点でレビューするとで、ユーザー向けの問合せ(QA)資料の品質向上(見やすさ、分かりやすさ向上)につながった。

特に効果が見られた対象工程

上流工程(要件定義、外部設計)のレビューに適用しやすい。
関係するステークホルダーが多いため、複数視点でレビュー指摘が検出しやすい。

7.改善活動の妥当性確認
実際の現場で PBR を適用した際に検出できた課題（悪い点）を考察した結果は下の通り。
課題と考察
課題

内容

レビュー人数・工数

視点・観点毎にレビューアを確保できない。
⇒少人数のプロジェクトには向いていない。
レビューアが１人の場合、複数視点でのレビューはやりづらい、またレビュー時間も要する。
⇒通常、PBR はレビューア複数人で行う前提とされている。

不慣れな視点・観点

不慣れな視点・分野でのレビューは難しい。どのような箇所に注意すべきポイントが分からない。

効果の薄い対象工程

下流工程(内部設計、開発)への適用はあまり効果がなかった。
理由として、開発者視点またはテスト担当者視点で十分なことが多かった。
その他の視点ではレビュー指摘があまり検出できなかった。

効果（良い点）と課題（悪い点）を総合的に判断した結果、下のまとめとなった。
現場適用の評価まとめ
現場適用結果よりまとめ目的に応じたレビュー指摘の検出

レビュー目的に応じた視点・観点でレビューを行うことで、質の高い指摘の検出が可能。

レビュー観点・ポイントの整理

不慣れな視点・観点でレビューを行う場合を考慮して、レビュー観点・ポイント等があれば、効果的にレビューを行うことが可能。
レビュー経験の浅いメンバのレビュー品質のボトムアップにもつながる。

レビューア人数の制約

複数の視点・観点でレビューを行うため、レビューアは２人以上が望ましい。
小規模なプロジェクトではレビュー負荷が高くなる懸念がある。

推奨工程

上流工程（要件定義、外部設計）に適用するのが効果的。

⇒複数人でレビューを行うような中〜大規模のプロジェクトの上流工程で効果を発揮する。
33

・現場適用へ向けた提案（現場適用するには）より効果的に現場適用するには、各立場での「観点リスト」の作成→立場や視点が明確化し、実施しやすくなる。
PBR レビュー観点リストの例
視点

読み方

共通

割り当てられた視点からそれることなく、常に視点を定めてレビュー対象を読んでいく

設計者の視点

レビュー対象の成果物を引き継いで、自分が次の工程の設計をするつもりになって、現在の設（レビューア①）

計内容で十分かという視点で読んでいく例）・機能要件と非機能要件は具体化しているか
・動作条件やメッセージなどは明確か
・用語の揺れやあいまいな記載は無いか

テスターの視点V 字モデルで、現工程に対応するテスト工程のテスト担当者になったつもりで、現在の記載内（レビューア②）

容でテストできるかという視点で読んでいく例）・エラー時の処理は明確か
・非機能要件をテストできるか・動作条件や入力値の文字種などにあいまいさはないか

顧客の視点

レビュー対象のソフトウェアを利用する顧客の立場で、利用時に問題ないかという視点で読んで（レビューア③）

いく例）・あらかじめ検討したユースケースがきちんと動くか・細かいところで動作に不明な点はないか
・非機能要件は利用条件を満足しているか
出典：お勧めのレビュー方法のご紹介 - 株式会社イデソン (ideson-worx.com)

D. 参考情報[1] レビューのリーディング方法 - 株式会社イデソン (ideson-worx.com)
https://ideson-worx.com/レビューのリーディング方法/[2] 組込みソフトウェア管理者・技術者育成研究会（SESSAME） 組込み系システム教材 「話題沸騰ポット」要求仕様書
https://www.sessame.jp/workinggroup/WorkingGroup2/POT_Specification.htm[3] お勧めのレビュー方法のご紹介 - 株式会社イデソン (ideson-worx.com)
https://deson-worx.com/お勧めのレビュー方法のご紹介/34

2A1 DevOps を実現するための Web アプリテンプレート開発とメンテナンス 三好 秀徳（株式会社日立ソリューションズ）＜タイトル＞
DevOps を実現するための Web アプリテンプレート開発とメンテナンス＜サブタイトル＞＜発表者＞
氏名(ふりがな)：三好 秀徳（みよし ひでのり）
所属： 株式会社日立ソリューションズ＜共同執筆者＞＜主張したい点＞
DevOps に必要な要素を盛り込んだ Web アプリのサンプル実装を開発し、4 年以上メンテナンスを行い、DevOps を当社内に浸透させることに尽力した＜キーワード＞DevOps Twelve-Factor Docker コンテナ＜想定する聴衆＞
ソフトウェアエンジニア＜活動時期＞
2019 年 4 月〜継続中＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

35

＜発表内容＞
1.背景
弊社では、DevOps 実践するためのツールや環境を長きにわたり社内に提供し続けています（SPI Japan 2018『新しい IT サービス開発への取り組み、DevOps 実践を目指して！』参照）。
2.改善したいことDevOps を実現するためのツールや環境は社内提供し続けていますが、社内においては DevOps を実践に移すプロジェ
クトは一部に限られている状況でした。
3.改善策を導き出した経緯
DevOps を実践に移さない理由は様々なものがありましたが、具体的にどのように実践してよいかわからず、また、その定量的な成果も分かりにくいという声がありました。
4.改善策の内容
そこで、弊社案件にて取扱うことが多いプログラミング言語である Java 言語を題材に Web アプリケーションを作成し、DevOps の実践に必要なツールや環境の使い方を実例と文書を作成・公開することにしました。
5.改善策の実現方法
Java 言語での標準的な Web アプリケーションフレームワーク（Spring Boot）を基盤フレームワークとして採択し、簡易的な Web アプリを作成した（下図 Fig.1 参照）

Fig. 1
また作成した Web アプリに対して自動テストの実装や自動デプロイの実装を行った。このための基盤として、SPI Japan2018 で紹介した GitLab や Pivotal の実行基盤を利用している（下図 Fig. 2、Fig. 3 参照）。

Fig. 236

Fig. 3
また、弊社内にて手作業にて情報取得をしているステップカウント／カバレッジ／ライブラリバージョンアップ確認／ライセンス
情報取得などの自動化も併せて実施している。
また、弊社内でクラウド利用が増えてきたこともあり、クラウド上でのアプリケーション実装の留意点である Twelve-Factorを踏まえた実装を取り組んでいる。具体的には、Java 言語のビルドツール Gradle の依存関係の明確化、ログの標準出力化・機械可読化、アプリケーションのステートレス化、コンテナ技術の対応を実現した。これらの留意点は従来の開発手法では実装できていないことが多く、しばしばアプリケーションをクラウド上に移行した場合に課題となることが多いため、サンプル実装として提示することで課題化を防止している。
使用したツール（Git、Docker、Gradle、SpotBugs、Jib、Flyway など）や基盤ソフトウェアである Java や Spring
Boot のバージョンアップ実施時に発生した課題についてはそれらを説明したドキュメント 10 本も併せて作成し全社公開を行った。これらのツールについて体系的にまとめられた資料が英語版しかないことが多く、ツール利用における障壁となっていると考え、日本語で読める資料を作成し利用を促した。
6.改善による変化や効果
従来手作業等で実施していた内容に対して、DevOps を実践したことに依る定量的な数値を獲得した（例：基盤フレームワークや言語自身のバージョンアップ対応が 3 日〜1 週間→3 時間〜3 日）。
また、サンプル実装や必要となるツールに関する資料を作成・公開することで、類似の技術基盤を使うプロジェクトに対してセルフラーニング化を推進した。結果として、公開している資料のアクセス数が 1,000view 以上、サンプル実装を参考実装として定常的に利用しているプロジェクト数は 3 件である。
7.改善活動の妥当性確認
妥当性確認ができるまでには至っていない
E. 参考情報[1] Spring Boot を 使 っ た Web ア プ リ ケ ー シ ョ ン の テ ン プ レ ー ト を 社 内 OSS と し て 開 発 ・ メ ン テ ナ ン ス（https://qiita.com/hidenori-miyoshi/items/e95d4f639ebc98a93084）
37

2A2 サービス開発初心者チームの運用を意識した DevOps 開発について 木村 慎吾（株式会社インテック）＜タイトル＞
サービス開発初心者チームの運用を意識した DevOps 開発について＜サブタイトル＞＜発表者＞
氏名(ふりがな)：木村 慎吾（きむら しんご）
所属： インテック＜共同執筆者＞
氏名(ふりがな)：
所属：＜主張したい点＞
サービス運営をしたことないチームがサービスリリース後からサービスをスムーズに運用するために、DevOps を採用して開発を進めた。開発時に２つのポイントを意識して開発を実施したことで、リリース後スムーズに運用ができた。リリース後２年経過したが、開発時にしっかりと指針を設けていたおかけで、それをベースにその後も改善は続いており、運用を安定させることができた。
＜キーワード＞・アジャイル開発
・DevOps・ITIL
・ISO2000・システムテスト＜想定する聴衆＞
これからクラウドサービスを開発する、マネージャおよび開発者＜活動時期＞
サービス開発・運営状況の概要は以下になる (ID 認証サービス：https://id-auth.jp/)
・開発期間は 2019 年 11 月～2021 年 1 月
・2021 年 2 月よりサービスの運営を開始している＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

38

＜発表内容＞
1.背景
これまでサービス運営の経験がないチームが自社の新サービスの立ち上げにあたり、サービスリリー
ス直後からサービス運用を問題なくできることを目標としてサービス開発に取り組んだ。
そこで今回はその初心者チームがサービスの安定化に向けてどのようにサービス運用を改善してきたのかについて、サービス開発時に想定していた取り組みや状況などと比較しながら、サービス開発時にポイントおいた 2 点を中心に結果を紹介する。
また、チームの概要としては以下となる。
・私はサービスマネージャとしてこの開発・運用に携わっている・パッケージ開発をしているチームが母体であり、サービス運営の経験はほぼない。
・ただし、アジャイル開発はパッケージ開発で経験している。
・現在サービス運営として 2 年経過している。その間 SLA を満たして運営できている
2.改善したいこと当社の文化では開発と運用は従来別々に行われており、サービスリリースが始まると別部隊に引継ぎというような流れがあった。そのため、引継ぎがうまくいかなかったり、組織間の問題でバラバラに動いてしまったり、サービス運用がなかなかうまくスタートできないといった問題があった。
今回のサービス開発においてはそれらを改善し、サービススタート時から運用を安定させていきたいと考えていた。
3.改善策を導き出した経緯
サービスの安定稼働のために開発と運用の垣根をなるべくなくす活動を開発時からしたいと考えていた。
そこで、その当時出始めた DevOps の考え方を用いて、サービス開発開始時点から運用も意識した開発を実施していくことにした。
ただ、DevOps を実践するといっても社内に事例がなかったため、自分たちで施行錯誤しながら進めていった。その中で以下の 2 つの取り組みが課題であった DevOps をどこから進めてよいかの解決の糸口になったと考えている。
１：サービスマネジメントシステムを意識した取り組み
２：システムテストの取り組み
4.改善策の内容
今回はこの糸口になったポイントにおいて実施した内容について記載する。それぞれの改善策については以下のようになる。
１：サービスマネジメントシステムを意識した取り組み
サービス運営が初めてだったこともあり、どこから手をつけてよいかわからなかったので、社内のサービスマネジメントシステムに準拠していくことで進めていった。具体的には ISO20000 や ITIL を参考にサービス運営を組み立ていった。その中で「リリース管理」、「構成管理」、「インシデント管理」が、開発側と運用側で一体となっていくことが重要あると考えて対応していった。
２：システムテストの取り組み
サービス開発はアジャイル開発を基本として進めていたが、特に負荷テストの確認など非機能を見ることを機能ごとに行うことが、時間や能力的に難しく、最後の工程で集約して実施した。

39

5.改善策の実現方法
２つのポイントにおける具体的な取り組みは以下のことを実施していった。
１：サービスマネジメントシステムを意識した取り組み
まずはインシデントフローを考えて、それに対応できる、ログ設計、監視設計を行った。そして、インシデント検知から SLA で取り決めた時間内でリリースできるような方法を検討していった。また、過去のサービス運営では改修が続くとインフラ面の構成管理のずれが起こるという課題も聞いていたので、今回はクラウドネイティブ開発ということもあり、インフラ面もソフトウェア化しソフトウェアの構成管理を活用して運用後も考えて設計開発を進めていった。
２：システムテストの取り組み
DevOps の中で、要件定義、設計、単体・結合開発においてはアジャイル開発の流れで実施していった。
ただし、リリース前にシステムテスト工程を設けるといった、ウォーターフォール開発のようなハイブリットの形を採用した。
それというのも、経験があり技術力があるチームであれば、教科書どおりリリースを最初から頻繫にすればよいが、私たちチームはサービス運営が初めてということもあり、リリース・運用について一度、工程を止めて確認することで品質を担保することを考えたからである。
6.改善による変化や効果
２つの取り組みによって以下のような効果があった。
１：サービスマネジメントシステムを意識した取り組みの効果
サービスマネジメントシステムを活用してサービス開発を進めたことで、リリース後の運用に対しても開発・運用が一体になって対応できていると考えている。
例えば、サービスリリース後に本当はエラーではない誤報のアラートを検知することがある。過去の事
例だと開発側と運用側で壁ができ、それらの誤報アラート検知を運用回避ということで、放置されることがよくある。このような誤報アラートが増えるとノイズになるため、ほんとの問題がわからなくなることもある。今回は開発・運用が一体となっていることで、その場しのぎの運用回避にせずに、根本的なログの見直しから行えている。そのため、ノイズもなく見通しがよい運用ができるようになっている。
また、リリース管理を開発時から意識してフローを作成したが、リリース直後は、開発と運用が管理するチケットが別れていて、リリース後にどのようなつながりがあるか、わかりにくいなどの問題が発生した。そのため、そのフローをその都度改善してインデントが発生して、開発側でバグなどを修正した結果と、それが本番にデプロイされリリースされた結果が残るまで、一貫通関でわかるような間を取り持つチケットを作成し改善をはかった。そのため、急な修正などにおいても、あとから何をやったか
明確にわかるようになった。無駄な棚卸などもなくなり現状ではサービスとしては常にどのような状態になっている把握できるようになった。これは、開発時からリリース管理を意識していたおかげで、最初の基準があったため、改善しやすいようになっていたからである。
２：システムテストの取り組みの効果
開発時はシステムテスト工程を置いたことによって、通常のアジャイル開発とは異なる流れになってしまいかつ工数を使ってしまったが、そのかわり、サービスをリリースする前にサービスリリース後の運用についても時間をかけて１つ１つ確認することができた。
具体的には、運用の流れであるインシデント発生からリリース作業への一連の流れをしっかりと確認することができた。問題点はこのテスト期間で解決できたため、リリース後に不慣れな作業によって発生するミスによる新たなインシデントを作り出してしまうようなことを避けることができたと考えている。初期リリース前にいったんサービスを俯瞰する必要があるため、必要な工程だったと考えている。
40

運用開始後のテスト環境においては、単体テスト環境や結合テスト環境レベルの環境はあったが、負荷テストを行えるまでの環境は常時用意していなかった。しかし、開発時のようなシステムテスト工程を設けてビックバンリリースをするとサービスのエンハンス速度が落ちる。そこで、負荷テストが常に必要な機能ばかりではないので個別で負荷テストできるように考えた。
具体的には、クラウドネイティブ開発によって、インフラもコード化していたため、負荷テストを実施したいときだけ、本番環境と同一のインフラをつくることにした。これによって、環境をシンプルに保ち、かつコストも最小限にすることができた。
これは、開発時にインフラもコード化して、再現性を高めることを意識していた結果によって、作り上げることができた。開発中はまだこの辺のノウハウがなく、さぐりさぐりであったので、開発中にこのような高度なことができず、システムテスト工程をつくった。しかし、開発を通してノウハウがたまり、このようなスポット的な環境をつくることが可能になった。これはチームとして常に継続してサービスの開発・改善に取り組んでいる DevOps の成果だと考えている。
7.改善活動の妥当性確認
現在サービスを運営して 2 年経過している。その間 SLA を満たして運営できている。もちろん最初から100％うまくいっていたわけではなく、最初の半期は約 30 件のインシデントを出してしまった。しかし、上記のポイントおさえて改善することで、直近の半期ではインシデント 0 件と安定した運用に近づけることできた。安定運用にしていけたポイントは、開発当初からベースを決めてそれを軸に改善していけたことがよかったと考えている。
また、サービスとしては今でも新規機能を開発し続けているので、新しいヒヤリハットレベルの課題
は発生しつづけている。直近半期では 26 件とインシデントにならなかったが、まだまだ多い数字である。そのため、日々の監視モニタリングでの障害対応への意識づけや、内部監査などによるサービスマ
ネジメントの改善などを継続的に行い、これまでの施策を形骸化させずによりよいサービスになるように改善を続けている。その結果については、またこの場において発表したいと考えている。

F. 参考情報[1] DevOps 教科書 日経 BP 社
[2] ITIL と ISO/IEC20000 がよ〜くわかる本 秀和システム

41

2A3 デジタル・アシスタントによる測定の自動化 中村 伸裕（住友電工情報システム株式会社）＜タイトル＞
デジタル・アシスタントによる測定の自動化＜サブタイトル＞
設計サブプロセス測定の取り組み＜発表者＞
氏名(ふりがな)：中村 伸裕（なかむら のぶひろ）
所属： 住友電工情報システム株式会社＜共同執筆者＞
氏名(ふりがな)：
所属：＜主張したい点＞
・手間のかかる時間測定を自動化した・ツールの有効性をツール自体が測定できるようにした。
＜キーワード＞・設計工数、自動測定、データ分析、Digital Assistant＜想定する聴衆＞
設計・製造プロセスを改善したい開発者、改善推進部門の方＜活動時期＞
2023/4〜＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

42

＜発表内容＞
1.背景
外部設計、プログラム設計、コーディングの生産性は全体の投入工数に対する成果物量で測定しており、改善活動の成果は試行で確認することになっている。しかし、20〜30 件程度の試行データでは設計・開発した機能の個別事情によるばらつきが大きく、平均値が動いたことを示せないケースが多かった。 “測定していないものは改善できない” という言葉の通り、設計・製造プロセスのサブプロセスを測定する必要がある。しかし、プログラム設計は半日程度で完了するものも多く、その中でさまざまなサブプロセスを短時間で切り替えながら作業しており、組織の開発者全員が例えば 5 分単位で測定することは現実的ではないと考えている。
一方、当組織では Digital Assistant（以下、D.A.）[1] というロボットが開発者を支援する仕組みの構築を進めて
おり、D.A.が測定を支援できないか検討することになった。
2.改善したいこと(1) プロセス実績の自動測定
D.A.による生産性向上、品質改善の成果を定量評価するために、工数、成果物量を細かくかつ効率的に測定したい。
測定したデータはプロセス実績ベースラインの確立や改善活動の入力として活用する。
(2) D.A. 改善情報の自動収集
D.A.自身に対する改善情報はアンケート等で収集することができるが、感想的な要素が多く、定量的な評価ができない。
開発者の負荷にならないように D.A.の出力に対するフィードバックを自動収集し、貢献度や改善点を定量的に評価できるようにしたい。
3.改善策を導き出した経緯
D.A.はペアプロのように開発者と協業する仕組みであり、開発者のマウスやキーボードの操作イベントで動作するようになっている。この操作イベントのログを蓄積し、時系列データを分析することで作業時間の内訳を示せるのではないかと考えた。

43

4.改善策の内容(1) 設計工数の測定
D.A.はブラウザ上で活動し、図 5 に示すような画面上でマウス、キーボードを使って会話する。プログラム設計では、D.A.
が外部仕様を確認し、画面仕様から利用すると考えられるテーブルを一覧(CRUD)表示したり、使用する部品の一覧を表示したりする。設計者は提示された内容を確認し、修正していく。D.A.は修正作業のマウス操作等を記録する。
図 6 にシステム構成を示す。操作ログは開発拠点毎に設置されている文書サーバーに記録され、夜間に分析サーバーに集められる。分析者はデータ分析ツールを使って作業時間の内訳を計算し、ベースラインを確立したり、改善活動で活用したりする。

図 5

プログラム設計画面の一部

図 6

システム構成(2) 改善情報の測定
D.A. は外部仕様書の不整合やソースコードの問題点を指摘する。世の中にこのようなツールはたくさんあるが、正常に動作するプログラムであってもルールに従って大量の警告を出力するような開発者にとって迷惑なものもある。D.A.の指摘に対して開発者に実際に成果物を修正する指摘を選択してもらい、D.A.の欠陥検出能力を評価できるようにする。
44

5.改善策の実現方法
5.1 設計工数の測定(1) D.A.のスキルアップ
設計者はブラウザ上でこの画面を操作し、設計を進める。今回、この画面の全ての入力項目に対して onClick,onChange のイベントを設定し、操作ログをサーバーに送信するようにした。また、設計中の他の業務（メールの返信等）
が割り込んだ場合、これらの時間を除外できるようにブラウザのフォーカス状態も記録するようにした。具体的には設計ページが表示された際に “begin” のログ、ブラウザからフォーカスが外れた際に “onBlur” のログ、ブラウザにフォーカスが戻って際に “onFocus” のログを出力する。
(2) 試行
プログラム設計工数の自動測定が実用的かどうかを確認するために既存の外部仕様書を使って D.A.の支援を受けながらプログラム設計を行ってみた。比較のために工数を手動で表計算ソフトに記入し、設計終了後 D.A.のログと付き合わせた。試行で得られたログを図 7 に示す。”target” 列がどの部分を設計していたか示している。チェックボックスにチェックを入れたり、日本語で使用を記述したりと入力作業が発生している部分の工数は正確に測定できることがわかった。しかし、D.A.は外部仕様書からエラーメッセージを転記したり、画面レイアウトから CRUD を提案したりすることができ、その内容が正しい場合、開発者は特に画面操作をする必要がない。この部分のログが採取できず、時間計測ができないことがわかった。

図 7．収集した操作ログの例(3) 対策D.A.が提案した設計項目が正しい場合でも開発者は外部仕様書を閲覧し、内容を確認している。当組織では外部仕様書が HTML 形式で作成されているため、Apache Web Server のアクセスログに閲覧記録が残っていた。Apacheのログを挿入（図 8）することで D.A.のログ空白期間の作業が確認でき、工数がより正確に確認できるようになった。この対策で、実プロジェクトでの試行に使えると判断した。今後、設計項目に “確認済み” のチェック項目を追加したり、外部仕様書へのリンクを設定し、リンクのクリックを記録できるようにしたりし、測定精度を改善していく予定である。

45

図 8．Apache ログを挿入
5.2 成果物規模測定
測定した工数は成果物規模で割り、正規化する必要がある。そのため、完成した成果物のメッセージ数等、各要素の数を測定し、サーバーに送信するようにした。前述の試行の結果、成果物のラベルと操作ログの捜査対象が紐付けられる状態でなければ機械的に生産性が計算できないことに気づいた。成果物に合わせて HTML 上のタグの ID を統一する作業を行った。
5.3 改善情報
D.A.の指摘のうち、修正する価値のある指摘がどの程度あるか測定することは D.A.の貢献度を示す１つの指標となる。
有効な指摘を選択することが開発者にとっても意味のある作業にしたい。そのため、図 9 に示すような画面で対応すべき
指摘内容にチェックを入れて登録ボタンを押すとチケット管理ツール(Redmine)にチケットが自動登録されるようにした。

図 9

D.A の指摘内容とチケット登録画面
46

この操作で修正する、しないに分類された指摘内容をログに出力し、図 10 に示す流れで翌日には分析サーバーに記録が蓄積されるようにした。

図 10.Redmine 連携と改善情報蓄積
6.改善による変化や効果(1) 設計工数の測定
今回の取組で設計プロセスのサブプロセスの工数が見える化できるため、コスト削減観点での改善活動が定量的に評価できるようになった。
従来、外部設計、プログラム設計の改善では品質改善に注目するケースが多く、成果物量も作業量も増加する傾向にあったがデメリットは定量的に評価されなかった。今後、品質改善の活動でも作業量の増加を加味して総合評価できるようになり、品質とコストのバランスがとりやすくなる。
(2) 改善情報の測定
プロセス改善は D.A.の成長とともに進んでいくというコンセプトであるため、D.A.に対する改善情報の収集も重要である。
今回、D.A.の質に関するフィードバック情報を収集する仕組みができたことから改善効果を確認しながら改善が進められるようになる。
7.改善活動の妥当性確認
以前、コーディングの改善活動でビデオ撮影と画面キャプチャでプロセス分析[2]したことがあった。分析にはビデオ撮影時
間の２〜３倍の時間が必要で気軽には実施できない分析である。一方、今回の施策は開発者が D.A.とペアで設計す
るたけで作業内容がデジタルデータとして残るので効率的にプロセス実績ベースラインを確立したり、改善活動における目
標設定、施策立案の分析に活用したりできるようになる。
今回は、専用の設計画面が提供されていたため、測定機能は約２週間で実装でき、効果的な取組であったと考えている。
（10 月の SPI Japan 2023 までに設計サブプロセスのベースラインが確立できる予定）
G. 参考情報[1] SPI Japan 2022, “ソフトウェア・プロセス DX の提言”, 中村伸裕, 2022
[2] SPI Japan 2016, “ビデオ撮影及び画面キャプチャによる分析プロセスの改善”, 原田大輔, 201647

2A4 プロセステーラリングへのプロダクトライン適用の実践 池永 直樹（株式会社デンソークリエイト）＜タイトル＞
プロセステーラリングへのプロダクトライン適用の実践＜サブタイトル＞－＜発表者＞
氏名(ふりがな)：池永 直樹（いけなが なおき）
所属： 株式会社デンソークリエイト＜共同執筆者＞－＜主張したい点＞
プロジェクト目標達成のためには、組織標準プロセスをプロジェクト特性にフィットした形でテーラリングし適用することが肝要である。プロセステーラリングの仕組みをうまく構築することで、より適正かつ効率的なテーラリングの実施が期待できる。プロセステーラリングにソフトウェアプロダクトラインエンジニアリング（SPLE）の考え方を取り入れ実践し、効果が得られた。
＜キーワード＞テーラリング、修整、ソフトウェアプロダクトラインエンジニアリング、メタモデル＜想定する聴衆＞
プロセステーラリングに課題を持たれている方組織標準プロセスの記述方法・保守に課題を持たれている方＜活動時期＞
2019 年〜2023 年現在＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

48

＜発表内容＞
1.背景
車載システムでは、数多くのバリエーション展開開発に加え、製品特性や OEM 要求に応じた様々な業界標準・規格（Automotive SPICE1、ISO262622、ISO214483、ISO/SAE214344、ISO240895、など）への対応が求められるようになってきた。我々の組織では、組織目標、製品特性、業界標準・規格などを考慮した組織目標プロセスを定義し展開しているが、プロジェクトで実装されるプロセスは多様であり、テーラリングの重要性がより高まっている。
プロジェクト目標達成のためには、組織標準プロセスをプロジェクト特性にフィットした形でテーラリングし適用することが必要条件である。しかし、組織標準プロセスには、様々な業界標準・規格の要求事項や製品特性に応じたプロセスが混在している。プロジェクトでのプロセステーラリングにおいて、必要なプロセスを識別し、組み合わせた上でプロジェクトプロセス（テーラリングされたプロセス）を導出できるか懸念があった。
そこで全社 SEPG は、フル定義された組織標準プロセスからのテーラリングの正確性・効率性向上のために、代表的な（規格を軸とした）テーラリングパターンを定義し、テーラリング実施を支援するようにした[3]。
2.改善したいことテーラリングパターンを用いたテーラリングの効率化・適正化のアプローチは既に提唱されており [4][5] 、1.背景 の通り
我々も実装し運用した。
しかし、代表的なテーラリングパターンを用意したとしても、さらなる小修整が必要なプロジェクトがある。テーラリングパター
ンから適切な小修整を加えプロジェクトにフィットしたプロジェクトプロセスを定義できればよいが、不適切な小修整、あるいは、小修整されず、プロジェクトにフィットしないプロジェクトプロセスが実装されるケースが見受けられた。
そこで、適正かつ効率良くプロジェクト特性にフィットした形で組織標準プロセスのテーラリングが実施されるように、さらに改善に取り組むことにした。
3.改善策を導き出した経緯◼ 現状分析
プロジェクトおよび SEPG の両側面から現状を分析した結果、次の事実が明らかになった。
(1) プロジェクト：テーラリング実施者の力量
業界標準・規格対応の要否、対応時のレベル（ISO26262 の ASIL など）、アーキテクチャ、開発手法、規模、難易度、新規／派生など、プロセステーラリングの観点となるプロジェクト特性は多い。したがって、テーラリング観点から適切にテーラリングするテーラリング実施者の力量が求められる。しかし、どのテーラリング観点が、どのプロセス定
義情報（活動、成果物、品質基準など）に関係するのか特定できない／気が付かない、ということがあった。また、特定できたとしても、どう修整してよいのか分からない、という事例もあった。
(2) プロジェクト：テーラリング時の手間
次のようなプロセステーラリング時の手間に関わる意見が確認できた。
・

テーラリング内容を一つ一つ記録する必要があり、その記録が面倒である

1

Automotive SPICE：車載システム開発向けのプロセスモデル

2

ISO26262：自動車-機能安全3ISO21448：自動車-意図した機能の安全性

4ISO/SAE 21434：自動車-サイバーセキュリティ

5

ISO 24089：自動車-ソフトウェアアップデート

49

・数あるプロセス定義情報の修整要否を確認することに時間が掛かる

・

テーラリングされたプロセスの補正（例えば、活動を省略した場合、その前後の活動を適切につなぐ必要がある）が必要な場合がある(3) SEPG
あらかじめ用意しておくテーラリングパターンの数を増やすというアプローチも考えられるが、それを維持し続ける
SEPG の労力（工数）が上がってしまう。また、数多くのテーラリングパターンから自プロジェクトで適用するもの選ぶことになるが使い勝手が悪い。よって、テーラリングパターンは代表パターンに留めるのが妥当と判断した。
■ 課題
現状分析の結果から、以下の課題を識別した。
・

テーラリング実施者（プロジェクトマネージャ）のテーラリングスキルの向上

・

より効率的で適正なテーラリングの実施を支援する仕組みの確立

テーラリング実施者（プロジェクトマネージャ）のテーラリングスキルの向上／プロセス理解を促進することが本質と考える。
しかし、一朝一夕にはいかず長期的な活動となる。そこで、まずは即効性があり、テーラリング実施者の力量が上がったとしても効果が見込める「プロセステーラリングの仕組み面」の課題解決に取り組む。
4.改善策の内容◼ 解決策に対する要件解決策を検討するにあたり「より効率的で適正なプロセステーラリングの実施を支援する仕組み」には以下の要件が必要であると考えた。
(1) 標準的なテーラリング観点（＝プロジェクト特性）をカバーできること
組織標準プロセスの適用範囲が制限されないようにするため、テーラリング観点に制約が出ないようにする。
(2) 用意できるテーラリングパターンに制約がでないこと
もともと用意できていた代表的なテーラリングパターンの提供を継続する。
(3) 省略以外の修整ケースも実現できること”省略” だけでなく、”簡略化・追加・統合・代替”[4] の修整ケースにも対応する。
(4) プロジェクトプロセスの完全性を確保できること
テーラリング時のプロセス補正の手間の削減や放置を防止するために、テーラリング基準内で作成されたテーラリン
グされたプロセスの完全性を確保しておく。
(5) テーラリング結果の記録が手軽であること
従来のようにテーラリング内容を一つ一つ記録しなくてよいようにする。
◼

課題解決アプローチ

課題の課題解決アプローチとして、「組織標準プロセスのテーラリングへのソフトウェアプロダクトラインエンジニアリング（SPLE）の適用」を考えた。
プロセステーラリングは、ソフトウェアプロダクトラインエンジニアリング（SPLE）の考え方と共通性がある[1]。すなわち、プロセスのテーラリング観点（プロジェクト特性）をフィーチャ、組織標準プロセスのプロセス定義情報（アクティビティ／タスク、
成果物、ロール、利用するガイドライン・テンプレート・チェックリスト、など）をコア資産と捉えることで、プロセステーラリング
50

へのソフトウェアプロダクトラインエンジニアリング（SPLE）の適用が可能である。
■ 前提条件
ここで、プロセステーラリングへのソフトウェアプロダクトラインエンジニアリング（SPLE）適用を成功させるためには、次の前提条件を満たす必要があると考えた。
(1) プロセス定義情報が、テーラリングで調整したい粒度で分別できること
プロセス定義情報（活動、成果物、ロール、品質基準など）が明確に定義されていないと、テーラリングで調整したい対象を正確に特定できない。また、粒度がバラつくことでテーラリングされたプロセスの質が低下してしまう。
(2) テーラリング観点（フィーチャ）とプロセス定義情報（コア資産）間の関係が正確に定義できること
テーラリング観点と調整対象のプロセス定義情報との関係が定義されていないと、テーラリングされたプロセスが構築できない。調整したい粒度でテーラリング観点とプロセス定義情報間の関係を定義できる必要がある。
この前提条件に基づき、まずプロセス定義のデータ構造を定義した上で組織標準プロセスを記述し、プロセステーラリング
へのソフトウェアプロダクトラインエンジニアリング（SPLE）を適用ことにした。
5.改善策の実現方法◼

プロセス記述ツール

組織標準プロセス記述のツールには、自社開発のシステム・ソフトウェア設計ツールである Next Design[13]を使用する。
設計対象がシステム・ソフトウェア製品なのかプロセスなのかの違いであるため、設計ツールが活用できると考えた。そこで、前提条件を満たせる Next Design を採用する。
◼

解決策の実施ステップ
以下に、解決策の実施ステップと対応するソフトウェアプロダクトラインエンジニアリング（SPLE）の活動を示す。
Step
1

内容

対応する SPLE 活動

テーラリング観点とテーラリングパターンの定義

可変性分析

 テーラリングの調整観点となるプロジェクト特性の関係・構造を整理

コンフィグレーション

し、フィーチャモデルを作成する。
 代表的なテーラリングパターンを定義する。
2

プロセス記述のデータ構造定義

ドメインアーキテクチャ設計

 メタモデルを使い、プロセス記述のデータ構造を定義する。
 テーラリングで調整したい構成要素を考慮して定義する。
3

組織標準プロセスの記述

ドメインアーキテクチャ設計

 メタモデルに基づいて、全てのテーラリング観点（フィーチャ）で必要とコア資産開発なるプロセス（150%モデル）を定義し、文書化する。
4

プロセス定義情報へのフィーチャ割り当て

ドメインアーキテクチャ設計

 テーラリング観点（フィーチャ）と関係するプロセス定義情報を特定

コア資産開発し、フィーチャを割り当てる。
5

プロジェクトでのプロセステーラリング

コンフィグレーション

 プロジェクトに適用するテーラリングパターンを選択し、さらに小修整する。
51

6.改善による変化や効果
解決策の評価◼

改善点に対し、まず仕組み面の課題解決に取り組んだので、仕組み面を評価した。
仕組みに対する要件は達成できたか➢(1) 標準的なテーラリング観点（＝プロジェクト特性）をカバーできること


テーラリング観点のフィーチャモデル化では、あらかじめ定義できるテーラリング観点に制約はでなかった。

(2) 用意できるテーラリングパターンに制約がでないこと


もともと用意できていた代表的なテーラリングパターンは維持できた。また、仕組み上の制約もない。

(3) 省略以外の修整ケースも実現できること
150%モデルとしてあらかじめプロセス定義しておくことで、”簡略化・統合・代替” を実現できた。

“追加” など標準にない修整内容は、プロセス定義書に手を加えることができる仕組みになっている。

(4) プロジェクトプロセスの完全性が確保されていること
150%モデルの定義により、テーラリングされたプロセスの完全性が確保できるようになった。

(5) テーラリング結果の記録が手軽であること

コンフィグレーション結果がテーラリング記録となり、チェックボックスの操作で記録を残せるようになった。

プロセス定義の内容や標準プロセスの適用対象範囲は維持できたか➢

本アプローチを実践した標準プロセスでも、実践前と同じプロセス定義内容を維持できた。



また、テーラリングパターンによる適用対象範囲の変化はなく、同じプロジェクト・製品を維持できた。
本アプローチは十分運用可能であるか➢＜プロジェクト＞


プロセステーラリングをプロダクト適用およびコンフィグレーション（チェックボックスの選択）で実現でき、効率的かつ適正に実施できるようになった。また、操作も容易であった。

＜SEPG＞


ツールのサポートもあり、フィーチャ割り当て・テーラリングパターン定義の工数は、プロセス定義の総工数の中で無視できる程度であった。

あらかじめプロセス定義を補完（150%モデル定義）しておく工数は必要であった。これに関しては、標準プ
ロセス定義として本来必要な工数だったと認識している。

◼

副次効果

副次効果として、完全な状態のプロジェクトプロセス（テーラリングされたプロセス）を作成できるようになり、プロジェクトメ
ンバのプロジェクトプロセスに対する理解性が向上した。従来は、テーラリング記録と組織標準プロセスとを照合することでプロジェクトプロセスを識別していた。この方式の場合、テーラリング箇所が多いと理解が困難であった。
7.改善活動の妥当性確認
解決策を実践した結果、期待通りの効果を確認することができた。また、副次効果も得ることもできた。プロセステーラリ
ングへのソフトウェアプロダクトラインエンジニアリング（SPLE）の適用は、有効であり、十分運用も可能であると考える。
52

今度は次のことに取り組み、さらなる改善を進めていきたいと考えている。


テーラリング実施者（プロジェクトマネージャ）のテーラリングスキルの向上／プロセス理解を促進し、今回の仕組みとの相乗効果を図る。



仕組み面としての改良として、テンプレートやチェックリストも含めたプロセス資産全体を連動できるようにし、プロジェ
クトの利便性の向上を図る。

H. 参考情報[1] 林好一、 ソフトウェアプロダクトラインエンジニアリングをプロセステーラリングに応用する、 第 25 回ソフトウェア品質シ
ンポジウム 2006
[2] 池永直樹、 DX アプローチによるプロセス記述 ~プロセス記述の効率化、品質および使用性向上に向けた取り組
み~、 4th NSPICE Conference[3] 村上孝,小寺浩司,加藤拓也、 複合規格に対応する標準プロセスの構築、 5th NSPICE Conference[4] 2009 年度 SQiP 研究会 第 1 分科会、 プロセスは定着していますか Part2 〜テーラリングガイド作成の手法の提案〜[5] 2013 年度 SQiP 研究会 第 1 分科会、 現場作業に密着したテーラリングを実現する「標準プロセスの構造及びプロセス定義」[6] 相澤武、 プロセス定着への取り組み ~テーラリングからはじまるプロセス改善~、 SPI Japan 2008
[7] 西村隆,山路厚,伊藤善博,原健三、 「メタモデルによる設計情報定義とマルチビューを活用したトレーサビリティ記
録方式の提案」、 ソフトウェア品質シンポジウム 2021
[8] 堀内一，大林正晴，藤川泰之, 「メタモデル標準化の意義と最新動向，前編：-基本的概念と歴史的経過-，
後編：-MOF，XMI 仕様と応用-」 ，2002，情報処理 Vol. 43 No.11,No.12,（社）情報処理学会[9] Peter Haumer, An Overview to Eclipse Framework Composer Part1:Key Concepts[10] OMG, Software & Systems Process Engineering Meta-Model Specification Version.2.0[11] Method Park, Stages Documentation, https://doc.stagesasaservice.com/doku.php/start[12] OMG, Meta-Modeling and the OMG Meta Object Facility (MOF)[13] Next Design, https://www.nextdesign.app/

以上532B1 品質 CoE による品質向上の取組み 小林 一郎（ＳＯＭＰＯシステムズ株式会社）＜タイトル＞
品質 CoE による品質向上の取組み＜サブタイトル＞〜多様化が加速するシステム構築の品質向上に社内技術者集団が挑む！〜＜発表者＞
氏名(ふりがな)： 小林一郎（こばやしいちろう）
所属： ＳＯＭＰＯシステムズ株式会社 業務品質部＜共同執筆者＞
氏名(ふりがな)：
所属：＜主張したい点＞
近年、次々に発表され多様化してきた新しい製品やサービス等を用いて構築されるシステムの品質を適切に保つために、個々のシステム構築プロジェクトに特化した品質検査およびマネジメント支援を、社内の品質技術者を集めた組織にて実施しており、その内容について紹介する。
＜キーワード＞
品質向上、品質管理、品質検査、CoE（Center of Excellence：センターオブエクセレンス）＜想定する聴衆＞
品質管理部門の人、新しいＩＴ技術の品質管理に困っている人＜活動時期＞
2021 年 12 月から継続中＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

54

＜発表内容＞
1.背景
当社の近年のプロジェクトは、クラウドサービスやパッケージ製品、さまざまな IoT 機器等を用いて、プロジェクトの特性に合わせた開発・マネジメント手法を選択する形でシステム構築を行うケースが多くなっている。これに伴い、品質管理においても考慮すべき点の多様化（特定の製品に特化した制約事項の存在等）が進んでおり、品質管理の難易度は上がり続けている。この状況に対処するため、当社は 2021 年 12 月に、社内のすべてのシステム構築プロジェクトの品質を、中央集権型の管理によって向上することを目的とした CoE（Center of Excellence：センターオブエクセレンス。専門家を集めた部門横断組織）である「業務品質部」をあらたに設置した。
業務品質部は、ユーザー業務に精通した事業会社業務部門からの出向者（以下「業務目線メンバー」と記述）と、社内の高度技術者認定制度である「スペシャリティ認定制度」にて認定された品質管理技術者（以下「QM 認定メンバー」と記述）を含む、品質管理業務を専門とするメンバーでスタートし、現在も品質向上の取組みを続けている。
本発表は、業務品質部が行っているプロジェクト品質向上の取組みについて、QM 認定メンバーの 1 人である私が紹介するものである。
2.改善したいこと当社には品質マネジメント標準プロセスがあり、品質指標を用いた品質評価、業務要求のトレーサビリティ検証、残課題
評価、チェックリストを用いたフェーズゲートレビュー等の品質管理活動はすべてのプロジェクトで実施されているものの、「1.
背景」に記述した品質管理において考慮すべき点の多様化を完全にコントロールすることは難しく、品質低下につながるケース（システム障害の発生）があった。
3.改善策を導き出した経緯
当社はシステム障害再発防止（障害根本原因のなぜなぜ分析による究明および再発防止策の策定と実施）に力を入れており、再発防止は行えている。しかし、「1.背景」に記述した、品質管理において考慮すべき点の多様化をコントロール
できなかったことに起因する新しいパターンのシステム障害（例：新規採用した外部サービスの予告なしの仕様変更（サイレントアップデート）に影響を受けた当社システムの画面表示エラー）が増加傾向にあり、再発防止では新しいパターンの障害を防ぐことができないことから、品質向上（障害数減少）のためには未然防止のアプローチが必要であった。
また、障害未然防止は未経験の問題を摘出して対応するという難しさから、ユーザー業務目線およびシステム品質管理
目線の専門家を 1 つの組織に集結させ、システム構築に関わる知見を集中することが適切と判断し、業務品質部を新設
して取組みを行うこととなった。
4.改善策の内容
プロジェクト設置時に作成されるプロジェクト情報（プロジェクト憲章やプロジェクトマネジメント計画、品質管理計画、リス
ク特定情報等）を分析し、個々のプロジェクトで起こり得る品質低下要素を仮説として設定したのちに、プロジェクト期中に検査・摘出することで障害未然防止につなげる取組みを行うこととした。
5.改善策の実現方法
前述のプロジェクト情報を用いて、業務目線メンバーが業務目線での品質低下要素を分析・抽出し、QM 認定メンバーがシステム構築目線での品質低下要素を分析・抽出して仮説を定義し、その仮説に基づく検査計画を策定のうえプロジェク
ト成果物（設計書やテスト仕様書、欠陥管理表等）をもとに検査を行い、仮説に相当する品質低下要素を検出した
場合はプロジェクトに報告し、対策のアドバイスまたは直接のマネジメント支援を行っている。

55

（業務目線メンバーの取組み例）
システム化してもユーザーに使われない業務要求が発生した場合に、不要な機能を作ることによるシステムの複雑化が品質低下につながるという仮説を立て、プロジェクトの目的と業務要求の追加要望分を照らし合わせる検査を行い、システム化されてもユーザーに使われない可能性が高い業務要求を抽出してプロジェクトに意見し、システム化の見送りにつなげた。
（QM 認定メンバーの取組み例）
未知の不具合が発生するという仮説を立て、品質モデル（SQuaRE）の品質特性観点を用いたプロジェクト成果物の検査を行い、不足している品質特性観点に関連したテスト欠陥傾向等の品質低下要素を抽出し、プロジェクトに報告および対策の提言を行っている。
6.改善による変化や効果
当社のプロジェクト案件にて発生したシステム障害数は、本取組みを開始した年の前年と比較して減少している。ただしプロジェクト現場の品質向上取組み等も行われているため、本取組みが障害数の減少につながったとは必ずしも言えない。
ただし、検査の際に品質確認に必要な観点のアドバイスを行ったプロジェクト現場が、その次に同様の検査を行った際に、前回の検査でのアドバイス内容を盛り込んだ品質確認を行っている等、本取り組みがプロジェクト現場の品質向上活動に寄与していると思われる事象も見受けられた。
7.改善活動の妥当性確認
改善活動の妥当性については、各プロジェクトの PM、PMO 等のキーマン層を対象にアンケート（業務品質部の取組みは役に立ったか）を実施することにより確認することとした。
アンケートの結果は、過半数を超える回答者から「役に立った」に相当する回答が得られたため、一定の効果は出せたと考える。回答者からのコメントとしては、「障害未然防止につながる気づきを与えてくれた」等の品質向上に直接寄与できたケースに加え、「IPA（独立行政法人情報処理推進機構）が公開している教訓集を用いた検査手法等の新鮮な知見が得られた」等の、プロジェクト側のスキル向上に寄与できたと思われるケースもあり、システム品質向上だけではなく要員育成という、今後の当社プロジェクト品質のさらなる向上につながる副次的効果も出せたと考える。
その一方で、約３割の回答者からは「どちらともいえない」に相当する回答があり、回答者のコメントを分析した結果、品質向上に寄与できた点と寄与できなかった点（製品技術の習熟度等、プロジェクトメンバーのほうが優れた知見を持っていた場合等）が混在していたことが判明した。また 1 割弱の回答者からは「役に立たなかった」に相当する回答があり、回答者のコメントを分析すると、すでにプロジェクト側で一定レベルの品質管理が行われており、業務品質部の検査がその再確認
レベルに留まっていたこと等が原因であることが判明した。
品質向上に寄与できなかった点については真摯に受け止め反省し、取組み内容の振り返りと改善を繰り返すことにより、システム品質のさらなる向上を目指していきたい。
I. 参考情報[1]システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル JIS X
25010:2013[2]情報処理システム高信頼化教訓集 IT サービス編 独立行政法人情報処理推進機構（IPA）社会基盤センター
以上56

2B2 クラウド型モデリングツールを活用したチーム全体でのプロジェクトの振り返りと改善 原 義典（リコーIT ソリューションズ株
式会社）＜タイトル＞
クラウド型モデリングツールを活用したチーム全体でのプロジェクトの振り返りと改善＜サブタイトル＞＜発表者＞
氏名(ふりがな)：原 義典(はら よしのり)
所属： リコーIT ソリューションズ株式会社＜共同執筆者＞
氏名(ふりがな)：
所属：＜主張したい点＞
プロジェクト目標を実現するにあたり、「振り返り」ということは重要ではある。
「振り返り」のやり方を変えることによって、目標達成に向けていろいろ可視化されてきており、今後プロジェクト目
標達成等が期待される。
＜キーワード＞システム思考、モデリング、オンラインツール、振り返り、可視化＜想定する聴衆＞
SEPG 初心者、振り返り活動実践している方＜活動時期＞
2022 年 6 月〜活動、現在も継続中＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

57

＜発表内容＞
1.背景
筆者が所属している部署では、プロジェクト単位で半年に 1 度プロジェクトメンバーで振り返りを実施している。
プロジェクト運営していく上では、定期的な振り返りをする改善活動が重要であるが、実際には、「プロジェクト目標に対して、何が問題でどう進めているのかが可視化されていない(K/P/T や Y/W/T が紐づけされていない)」や「振り返り方が画一的ではなく、場当たり的な振り返りであり、かつ Try 項目が実行されていない」という状況であった。
さらに深堀していくと、・ノートやメモアプリを利用し、文字(文書)のみで振り返りしている。(振り返りの仕方を把握できていない。)
・振り返り期間が長いと、最初(半年前)にやったこと等を忘れてしまい、その時点で分かっていることベースに振り返りを実施していた。
・Try 項目が抽象的でアクションアイテム化されておらず、実行に移せていなかった。
ということがわかり、振り返りのための手法や考え方の習得が必要であった。
2.改善したいこと① 振り返った内容が一目でわかるようにしたい② 振り返り期間を短くし、改善活動を回したい、かつ振り返り自体がよりよくなるようにしたい③ Try 項目をアクションアイテム化し、実行させたい
3.改善策を導き出した経緯
筆者が所属している部署では、「自分の担当範囲から、全体像を導く手法を学び、システムの目的との関係性を把握する能力(システム思考)を習得」するための活動を 2022 年に実施している。その中で、クラウド型モデリングツールを利用した振り返り・ミーティング運用が世の中で利用されている。その実践を取り入れることにした。
振り返り・ミーティング運用の基礎やフレームワークを理解していくにつれ、① 振り返り内容が簡単に可視化できる② 振り返りに時間がかからないので振り返り間隔が短縮される③ 振り返りで出た Try 項目をアクション化し、管理できると考えた。
そこで、筆者が所属している部署内の全プロジェクトテーマに適用することで「2.改善したいこと」が実現できると考えた。
4.改善策の内容① クラウド型モデリングツールを利用し、振り返り内容を可視化する② 振り返り運用(ルール)を策定する③ クラウド型モデリングツールで、Try 項目をアクションアイテムにして、監視/実行する
5.改善策の実現方法
クラウド型モデリングツール「Balus」を利用することで改善策を実現する。
「Balus」とは株式会社 Levii が開発・提供しているオンラインツールであり、特徴としては以下が挙げられる。
「Balus」の特徴としては、以下が挙げられる。
・

誰でも簡単にモデリング・

チームの協調性を生み出す
58

・

モデルを資産として活用

世の中にはほかにもモデリングツールがあり、「Balus」よりも優れている点があるのだが、「Balus」を採用するに至った理由
は以下の通り。
・

デザイン/操作性がシンプル

・システム思考を実践できるようにパッケージ化されているフォーマット/実践例が豊富

・記載できる字数制限があることで、気づきを促す「Balus」では振り返りのフォーマットをいくつか有しており、そのフォーマットの内、KPT ベースと YWT ベースのフォーマットを適用する。(図 1、図 2 参照)

図 11 「Balus」の KPT フォーマット

59

図 12 「Balus」の YWT フォーマット

部署内のプロジェクトテーマは全部で 5 テーマであり、KPT ベースでの振り返りが 2 テーマ、YWT ベースでの振り返り
が 3 テーマとして、改善策を実施する。
① 「Balus」にプロジェクト目標を明記し、それに対してやったこと/わかったこと/よかった点/問題点等記載＆紐づけ
し、グルーピングする。(図 3、図 4 参照)② 振り返り運用(ルール)を以下のように策定。
・プロジェクトテーマ内の全体の振り返りは毎月 1 回実施
・振り返り自体の振り返りを 3 カ月に 1 回実施
・「Balus」で次回の振り返りフォーマットを用意し、やったこと/わかったこと/よかった点/問題点等を適宜記載③ Try 項目からアクションアイテムとして管理していく項目を紐づけし、適宜状況を記載する。(図 3、図 4 参照)

60

図 13 KPT での実践内容(抜粋)

図 14 YWT での実践内容(抜粋)特に図 3、図 4 は振り返りをよりよくするためにメンバーで振り返り活動自体の振り返り(通称ふりふり)を実施し、改善した結果となっている。(図 5 参照)

61

図 15 ふりふり実施前後でのアクションアイテム管理の変化(抜粋)6.改善による変化や効果
３つの「改善したいこと」についての変化・成果は、それぞれ以下の通り。
① 振り返りを可視化できるようになった。
プロジェクト目標に対して、どのように振り返りを実施したのかすぐにわかるようになり、③の改善策にもつながっている。
② 毎月 1 回以上は、全テーマで振り返りが実施できるようになり、かつ気づきがあれば適宜記載し、残すことができるようになった。
また、振り返り自体の振り返りによって、振り返り自体のスキル向上し、振り返りフォーマットの改修・1 回の振り返り
時間の短縮にもなった。
③ Try 項目の選別/アクションアイテムを管理し、小さくすぐに出来そうなものから改善を取り組んでいくことができるようになった。アクションアイテムの担当も割り当てることによって改善活動への意識が高まった。
さらに本改善により、メンバーの意識として、「振り返りの改善できてよかったという意識から、自ら問題提起して次にどう改善するかという意識」に変化しており、次のステップに進んでいる。
また、定量的効果としては、やったこと/分かったこと/Try 項目の記載が改善活動直後と現在で比較して 2 倍から 3 倍
洗い出せるようになり、振り返りの質の向上となっている。

7.改善活動の妥当性確認「6.改善による変化や効果」は出ているが、全プロジェクトで本格的に振り返り活動開始したのが 2022/11 と期間が浅く、プロジェクトが現在継続中のため妥当性確認できていない。
問題/課題の可視化、プロジェクト内の改善活動、プロジェクト目標に向けての改善が出来始めている段階である。
今後、本活動を継続し、今のようなプロジェクト振り返り・改善からもう 1 段階深堀した振り返り・改善を進めて高パフ
62ォーマンスのプロジェクトに成長することを期待する。

J. 参考情報[1] Balus 製品紹介 https://levii.co.jp/services/balus[2] Balus KATA MAP https://blog.levii.co.jp/entry/2023/04/03/101929

63

2B3 プロジェクトデータを活用したリスクプロジェクトの検知 常木 翔太（NEC ソリューションイノベータ株式会社）＜タイトル＞
プロジェクトデータを活用したリスクプロジェクトの検知＜サブタイトル＞＜発表者＞
氏名(ふりがな)：常木 翔太 （つねぎ しょうた）
所属： NEC ソリューションイノベータ株式会社＜共同執筆者＞
氏名(ふりがな)： 三浦 一成 （みうら かずなり）
所属： NEC ソリューションイノベータ株式会社
氏名(ふりがな)： 岩切 努 （いわきり つとむ）
所属： NEC ソリューションイノベータ株式会社＜主張したい点＞
プロジェクトデータを収集して BI ツールや AI を活用することでリスクプロジェクトを早期に検知する＜キーワード＞リスク検知、PMO、BI ツール、AI＜想定する聴衆＞
PMO＜活動時期＞
2021 年 9 月〜継続中＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

64

＜発表内容＞
1.背景
NEC ソリューションイノベータ株式会社では、全社横断的な PMO 機能をもつ組織を設置してプロジェクトのモニタリング
活動を実施している。月次でプロジェクトマネージャから報告される「プロジェクト状況報告」やプロジェクト管理システムに登録された QCD などの情報を収集して、品質、コスト、進捗、プロジェクト体制等の状況から不採算になるリスクのあるプロ
ジェクトの検知や対策の推進をしている。
2.改善したいこと○データに基づく PMO 活動の実現
・不採算となるリスクのあるプロジェクトを早期に検知したい・モニタリング業務を効率化したい
・モニタリング担当者のスキル依存や検知の漏れを防ぐ
3.改善策を導き出した経緯
前述の通り、これまでは不採算になるリスクのあるプロジェクトの検知やリスク対策の推進活動を実施しており、大規模
プロジェクトの不採算件数は減少してきた。
一方で、中小規模のプロジェクトにおける不採算件数はまだまだ存在しており、組織としては中小規模の不採算プロジ
ェクトに注力する必要性があったが、中小規模のプロジェクト件数は大規模プロジェクトに比べて件数も多く、PMO の人員も限られている状況がある。そこで、中小規模のプロジェクトをモニタリングするための業務効率化とそれを実現するためのツールを合わせて整備する必要があった。
4.改善策の内容
これまでは、PMO が人手で情報を収集して過去の経験やノウハウによりリスク検知を行うことが多く、モニタリング可能なプ
ロジェクト件数には限りがあり、リスク検知もＰＭＯのスキルに依存するという課題があった。
今回は、主に遂行中のプロジェクト状況を可視化し QCD に関する閾値を設けてアラームの表示や AI による判定をまとめて提供する「PJ リスク検知ビュー」というモニタリング用のダッシュボードを構築する。それにより、データ収集の自動化とアラーム/AI によるリスク検知をデジタル化して「リスクプロジェクトの早期検知」、「PMO 業務の効率化」、「不採算リスクの検知漏れ防止」を目指す。
5.改善策の実現方法
可視化するデータは、常に最新のデータを表示することが求められる。そのため、社内のプロジェクト管理システムからデー
タを日次で取得して QCD に関する情報の可視化を行った。また、リスクのあるプロジェクトを早期に検知したりＰＭＯのス
キルに関係なくリスクのあるプロジェクトを検知したりするため、PMO の知見をもとにした審査の遅れや工程の重なり状況、品質指標の超過などを監視するルールベースのリスク検知と AI を用いた判定結果を BI ツールで PMO に提供した。
6.改善による変化や効果
現在、ＰＭＯに提供した情報の有効性を確認中であるが 2022 年度の不採算プロジェクトや社内で要注意と判断されたプロジェクトのうち 67%を早期かつ漏れなくリスク検知ができた。
PMO の業務効率化という観点では、改善効果を検証中である。

65

7.改善活動の妥当性確認
全社横断組織として、ルールベースのアラームや AI を活用することにより早期かつ漏れなくリスク検知することに効果があった。
一方、実際には不採算の要因となる様々な状況変化がプロジェクト内部では起こっていると想定され、現場で収集しているデータと全社横断組織が収集できるデータには「データ更新頻度」や「粒度」という点で乖離がある。 現時点では、改善による変化や効果を継続検証中ではあるが、これらの点から本活動の妥当性を引き続き見極めていきたい。

K. 参考情報[1]66

2B4 組織全体での EVM によるプロジェクト進捗管理 川崎 雅弘（パナソニック アドバンストテクノロジー株式会社）＜タイトル＞
組織全体での EVM によるプロジェクト進捗管理＜サブタイトル＞
失敗しない EVM による管理術＜発表者＞
氏名(ふりがな)：川崎 雅弘(かわさき まさひろ)
所属： パナソニック アドバンストテクノロジー(株) 事業開発室＜共同執筆者＞なし＜主張したい点＞
EVM の SPI, CPI の２つの情報に絞って組織全体に展開することで、プロジェクトリーダだけでなく管理層から現場の担当者まで、さらにプロジェクトの規模や期間などに関わらず「共通指標」で全プロジェクトの状況が把握できるようになり、SPI,CPI の値から進捗状況の問題とその要因も推測できるようになった。また、組織的にこれらの値を監視するようになったことにより、PL の意識も変わり改善活動が進んだ。
＜キーワード＞EVM、SPI、CPI、進捗管理、プロセス改善、メトリクス、コスト意識、組織改革＜想定する聴衆＞
SEPG、マネージャ、プロジェクトリーダ、EVM 導入がうまくいかなかった方＜活動時期＞
2018/10〜継続＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階■ その他(ステップアップの活動も進めている)67

＜発表内容＞
1.背景
弊社は外部からの委託によるソフトウェアおよびシステム開発が主業務であるためプロジェクトの規模や期間が様々であり、組織全体で１００以上のプロジェクトが並行して活動している。
2.改善したいこと管理層から見て各プロジェクトの状況がわかりにくいという課題がある。
週報では順調と報告されているにも関わらず、実際には残業が多いプロジェクトや、問題が大きくなって初めて上位の管理層に伝わるケースも多い。
進捗管理において管理層が知りたいのは「順調なのか」「いつ終わるのか」であるが、プロジェクトからの報告は「今週、何があったか」であることが多く、報告して欲しい情報に乖離がある。また、現場レベルでは残業はコスト増になるので順調ではな
いということが十分に理解されておらず、コスト意識についても管理層と乖離がある。
管理層はこれらが課題であることは理解しているが、改善しろとは言えるものの具体的な手法にまで落とし込めないことが根本的な問題と考えられる。
これらの課題を解決して、プロジェクトの状況を客観的指標で見える化し、できるならば、問題が顕在化するより前に予兆を見つけて早めに手を打てるようにしたい。
3.改善策を導き出した経緯
プロジェクトの管理の技法の１つである EVM(Earned Value Management) (図１)は、経済産業省や IPA でも推奨されており[1]、プロジェクトの状況をコストに換算して予兆管理できるため、これらの問題を解決できると考えた。

EVM 活用型プロジェクト・マネジメント導入ガイドライン/経済産業省 情報処理振興事業協会より

図 16

EVM の PV,EV,AC の推移グラフのイメージ

ところが、EVM の考え方や手法に関する情報は多く見つかるものの、実際に導入してうまくいったという事例は意外と見つからない。その主要因としては、「理想論すぎて実態にあわない」「お金を扱うので現場向けではない」といった理由で、導入を敬遠したり、導入したが定着しなかったのではないかと推測される。
特にソフトウェア開発の進捗管理に EVM を適用しようとした場合、Earned Value(出来高の価値)を金額にすると、進捗管理表に金額が記載されることになり、現場で使うには馴染みにくい。
まずは EVM を理解した上で、自分達に適した使い方を考えることとした。

68

4.改善策の内容
EVM にはいくつかの指標があるが、このうち以下の４つの指標(表１)が今回の目的として使えるのではないかと考えた。
表 1 利用する EVM の指標の検討
用語 正式名称
SPI

解説

Schedule Performance Index SPI = EV / PV
スケジュール効率指数

CPI Cost Performance Index
コスト効率指数

各作業のスケジュール面から見た効率を示す。1.0 以上なら良好
CPI = EV / AC
各作業のコスト面から見た効率を示す。1.0 以上なら良好

EAC Estimate At Completion
完了時コスト予測
ETC Estimate To Completion
残作業コスト予測

現時点で見積った完成までの総コストの見積り。代表的な計算式はEAC = AC + (BAC - EV) / (CPI*SPI)ETC = EAC - AC
現時点から完成までに見積った残作業のコスト見積り。

また、EVM のポイントの１つである、Earned Value(出来高の価値)については、金額のまま使うのは生々しいので、「計画時に見積もった作業成果物の開発見積工数を、その作業成果物の(工数的な)価値とする」と定義した。例えば、100H の工数で作成すると見積もった成果物は、実際には 120H かかっても、価値は 100H と考える。これは、委託開発の考え方と同じで、これを WBS の WP(Work Package)単位で実施するというのが今回の方法である。
■Step０：机上での試行
これらの考え方を基に、実際のプロジェクトの進捗の実績データを使って EVM の指標をグラフ化し、机上で確認した(図２)。

図 17

机上での試行：実際のプロジェクトの実績のグラフ化「計画と実績(PV, AC, EV)」は良くある進捗状況のグラフであるが、縦軸のスケール的に乖離が分かりにくい。
「効率指数(SPI, CPI)」は計画通りであれば 1.00 になるが、ほとんどが下回っていて順調でないことが明確である。このプ
ロジェクトは途中で計画の見直しを数回実施しているが、SPI,CPI が落ち込んで翌週に改善しているタイミングとも一致する。すなわち、SPI<0.80 になると残業だけで期限に間に合うようにするのは困難で計画の見直しが必要と考えられる。
「残工数予測(EAC, ETC)」のグラフでは EAC がかなり早い段階でリスクマージンを超えて一向に減っていないので、再計画しても根本対策になっていなかったことが推察できる。但し、ETC がなかなか減らないので前半は嘘っぽい値に見える。
このように、計画と実績(PV, AC, EV)だけだと誤差レベルの乖離にしか見えないが、EVM の指標を見るとプロジェクト状況の見える化と、早い段階での異常の検出ができることがわかった。
但し、今回は、EVM の導入が目的ではなく、課題の解決が目的であるとして、「プロジェクトが順調なのか」「計画見直しが必要か」の観点に限定し、最も単純な方法として SPI(スケジュール効率指数)と CPI(コスト効率指数)のみを使用し、閾値として 0.80(残業 20%見合い)を適用することとした。

69

5.改善策の実現方法■Step1：特定部署での試行
進捗状況が見えづらいという相談を受けていた部署に EVM の導入を提案し、毎週の PL 会議にて、SPI と CPI を報告してもらい、数値が 0.80 未満の場合は原因を分析し計画を見なおすルールで運用を始めた。
複数プロジェクトでの試行の結果、週報では順調とあるのに SPI, CPI からわかる状況とは違うことが違うことがはっきりと見えるようになった。特に、プロジェクト終了時に SPI は 1.00 に近づくが CPI が悪いままとなる傾向が見えてきた。これは、PL
は責任感が強く、顧客と合意した日程を守ろうとして残業で対応するためで、当初想定していた「PL はどこから残業分の費用を持ってくるのかのコスト意識が薄い」という課題が数値としてはっきりと表れた。
このため、計画承認時に PL が使って良いリスクマージンを合意するようにし、それを超える場合は再計画&課長(部長)承認が必要というルールとした。これによって、PL はリスクマージンを意識するようになり、残業に対するコスト意識を持つとともに、CPI の悪化は残業では改善できないため残業以外の対策も考えるようになった。
SPI, CPI の値自体を細かく分析すると、プロジェクトの規模や期間、あるいは開始時から終了時まで同じ指標で判断できることがわかり、さらに、SPI, CPI の値から遅れの原因もある程度パターン化できた(図３)。
SPI, CPI < 1.00 であってもリスクマージン内であれば PL 管理で OK とするが、SPI, CPI > 1.00 であっても単純に順調とは言えず、見積り精度が低い、見かけ上前倒しに見えているだけといった問題があるケースもあることがわかった。

図 18 整理された SPI,CPI の閾値と原因■Step２：組織全体への展開
特定部署での実施の結果、見える化による高い改善効果が見られたため、組織全体に展開した。
同時に 100 以上のプロジェクトが動いているが、プロジェクトの特性に関わらず同じ指標／閾値で判断できるため、一覧化することで(図４)状況が一目でわかると共に、是正措置がとられていないプロジェクトも簡単に把握できるようになった。

図 19

部ごとの各プロジェクトの週単位の EVM データ一覧のイメージ(抜粋)70一方で、全プロジェクトが対象になったことで、不自然なプロジェクトがいくつか見つかった。
特に SPI, CPI = 1.00 が続くケースは見積り精度 100%ということであり、普通に考えてあり得ない。原因を確認すると、正しく実績を入力していないケースや、見積りとの差異が発生しやすい活動(準備、調査／検討、PL 自身の工数など)が計画に含まれていないケースなど、週報からでは気づきにくい課題も見つかったため、随時是正をした。担当者単位では、
早く終わっているのに、体裁修正や見直しなどで与えられた工数を全て使い切るなどの行動も見受けられた。
6.改善による変化や効果
弊社の全プロジェクトが共通の指標を使って「プロジェクトが順調か」を判断し、組織責任者が早い段階で予兆を見つけて是正指示ができるようになった。
プロジェクトレベルでは、PL の成熟度があがり、是正指示をされないように SPI, CPI < 0.80 になる前に対策が取られるようになった。これは閾値を超えると細かく聞かれるので、その前に対処しておこうという心理が働いていると推察される。
特に、PL が計画に対してスケジュールだけでなくコスト意識(残業=悪)も持つようになり、どこから残業分の費用を持ってくるかを意識し始めた点が大きい。
メンバについても計画通りに進めるようにするために、日々の進捗確認で計画との乖離の理由を問われるため、実質的に毎日「ふりかえり」をしているのと同様になり、個人レベルでの改善意識も高まり、実際に多くのプロセス改善がされている。
まさに、「管理層が知りたい形の見える化」と「現場の意識の差の改善」が実現できた。
7.改善活動の妥当性確認
プロジェクトの規模や特性に関係なく共通指標で判断ができるため、全プロジェクトを一覧にして確認できる点が管理層のニーズにも合っている。また、SPI と CPI の２つで、閾値も「<0.90 にならないように制御し、<0.80 になったら再計画」と、考え方が非常にシンプルであるため、EVM の深い知識がなくても利用できることから、管理層や PL だけでなくメンバにも考え方が広まり定着できたと考えられる。
単にメトリクス収集して見える化するだけでは、形骸化したり、正しく収集されなくなる可能性もあるが、管理層が毎週その値を使って確認／原因追及するため、活動自体は定着し、既に組織文化の１つとなってきている。
本活動だけの要因ではないが、導入前に比べて残業時間はあきらかに減ってきている。組織改革、働き方改革の一環としての導入も有効であると考える。
ここまで、約２年かかったが、次のステップとして EAC(完了時コスト予測)と ETC(残作業コスト予測)の展開を進めている。
EVM は単なる手法であり、それをどう利用するのかが重要である。
今回の取り組みにおいては、目的に合った効果を出すことを重視した。また、それを定着し継続するためには、現場に効果を実感させること。そのためには管理層の強い思いやプロセス改善担当者の細かなフォローが特に重要な要素であると感じた。
L. 参考情報[1]

EVM 活用型プロジェクト・マネジメント導入ガイドライン／情報処理振興事業協会（IPA）※現在は IPA のサイトからは削除されているが「国立国会図書館 インターネット資料収集保存事業 HP」で「evmguideline.pdf」を検索して入手可71

3A1 越境人財を育てる！共創＆デジタル人財育成 Boost Program 開発 ４転５起 亀田 佳代子（株式会社 東芝）＜タイトル＞
越境人財を育てる！共創＆デジタル人財育成 Boost Program 開発

４転５起＜サブタイトル＞
共創しながら育成する共創人財＜発表者＞
氏名(ふりがな)： 亀田 佳代子（かめだ かよこ）
所属： 株式会社 東芝＜共同執筆者＞
氏名(ふりがな)：伊藤 裕子（いとう ゆうこ）
所属： 株式会社 東芝
氏名(ふりがな)： 石井 裕志（いしい ひろし）
所属： 株式会社 東芝
氏名(ふりがな)： 戸谷 浩隆（とや ひろたか）
所属： 株式会社 東芝
氏名(ふりがな)： 山下 誠（やました まこと）
所属： 株式会社 東芝
氏名(ふりがな)： 田村 朱麗（たむら しゅれい）
所属： 株式会社 東芝＜主張したい点＞
東芝では、分野を超えた共創型の開発ができる人財育成を目的として、「共創＆デジタル人財 Boost Program」（以下、「本教育」と略す）を企画・開催した。本教育では、東芝グループの SPI 活動が進める共創の取り組みのうち、OSS（オープンソースソフトウェア）の開発スタイルを会社内にとりいれるインナーソースの取り組みをモチーフとした。
発表では、3 年間、5 回にわたる本教育の改善の取り組み成果を紹介する。
＜キーワード＞共創、デジタル人財育成、デザイン思考、プロトタイプ思考、ハンズオン、ハッカソン、アイデアソン、アジャイル開発＜想定する聴衆＞
SEPG、人財育成に取り組んでいる方＜活動時期＞
2020 年度〜2022 年度
72

＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

73

＜発表内容＞
1.背景
東芝グループでは、現在、経営方針として事業のサービス化やデータビジネスに重点を置いている[図 20] [1]。経営方針の実現のため、東芝グループの SPI 活動は、ソフトウェア技術センター※が推進してきた。ここで、SPI の方針へ、共創・サービス・ソフトウェア開発の新潮流の要素を取り込んでいる[2]。
※2023 年 4 月にソフトウェア技術センターは、「デジタルイノベーションテクノロジーセンター（以下、DITC と略す）」へ
組織改編した。本稿では構成の都合上、旧組織のソフトウェア技術センターと称す。

図 20

東芝グループ経営方針

経営方針で掲げる「つながる市場の新たな社会価値の創造」のために、既存の事業の枠組みや個々人の専門性や役割を超えた共創を行い、新たな価値を創造することが求められる。ソフトウェア開発においても、人々が分野を超えて協働し、共創することが不可欠である。ソフトウェアでの従来型の開発と共創型の開発の相違点を、表 2 に示す。東芝グルー
プの SPI 活動の中では、共創型の開発を実行するため、オープンソースの開発スタイルを企業グループ内で実施するインナーソースの制度設計やアジャイル開発の推進を行ってきた[2]。
表 2 従来型の開発 vs. 共創型の開発
従来型の開発共創型の開発要求

顧客が提示するともに生み出す開発スタイル

顧客の要求に沿って開発する。仕様

短いサイクルで小さなリリースをし、顧を確定させた後、仕様通りに開発す

客からのフィードバックをとって検証し、る。

検証から学び適応することを繰り返しながら開発する体制

役割分担（分業）

協働

ガバナンス

指示とコントロール

協調

コア要素

確実な品質、効率性、合理性

アイデア、スピード、柔軟性

行動指針

失敗を回避し、失敗しない

アイデアを試し、フィードバックによって検証と適応を繰り返す

そして、共創型の開発を進めていくためには、新しい開発スタイル・マインドセットを習得した人財が必要であると考える。

74

2.改善したいこと
共創型の開発では、従来とは異なる開発スタイルや体制、行動指針に基づいて行動することが求められ、これらを体現できる人財育成の重要性が増してきている。東芝グループにおいて、共創に関する取り組みはこれまでも実施されてきた。
しかし、東芝グループ横断的な視点で、共創型の開発のための人財育成することにフォーカスした教育プログラムが十分には提供されていなかった。このような背景から、東芝グループ横断的に共創型の開発を促進するための人財育成を目的とした教育プログラム「共創＆デジタル人財 Boost Program」を企画・開催した[3][4][5]。
3.改善策を導き出した経緯
我々は、東芝グループの SPI 活動で進めてきた共創の取り組みのうち、OSS（オープンソースソフトウェア）の開発スタ
イルを会社内にとりいれるインナーソースの取り組みが、サイロを壊す共創型の開発である点に着眼した。そこで、インナーソースをモチーフとして、部門横断のチームで開発をしてもらい共創を体験できる教育を企画した。図 21 に本教育のロード
マップを記す。
本教育の目的として、「共創視点の目的」と「開発者の視点の目的」を以下のように設定した。「開発者の視点の目的」
を達成することを通して、「共創視点の目的」を達成することを狙うこととした。
「共創視点の目的」•
共通課題の解決に向け協力して開発し改善し続ける新しい開発スタイルを定着させる。
•
協働体験により共創によるソフトウェア開発のマインドを醸成する。
•
共創によるソフトウェア開発（インナーソース）の協力者コミュニティを作る。
•
東芝グループのソフトウェア開発力を強化する。

「開発者視点の目的」•
アイデアを次々と素早く具現化するソフトウェア開発方法を実践し身に付ける。

共創人材育成のためのロードマップを図 21 に示す。2020 年度(第 1 回)は開始フェーズという位置づけで、DevRel6[6]を得意とする外部講師を招いて本教育を企画・開催し、実施効果と課題を検証した。2021 年度〜2022
年度(第 2 回〜第 5 回)は、実行フェーズという位置づけで、社内で DevRel 活動を自主開催することを狙い、デザイン
部門、DITC(IoT 基盤サービスを開発・運用している部門)と連携しコンテンツを内製化した。また、電子工作やハッカソンの経験があるメンバや 2020 年度の本教育の参加者を入れるなど、企画・運営に関わる人財を強化した。

図 21

6

共創人財育成のためのロードマップ

DevRel:Developer Relations、開発者との繋がりを強固にするマーケティング施策75

4.改善策の内容
第 1 回から第 5 回までの教育を開催しながら、以下の改善に取り組んだ。
(1) プログラム構成の見直しプログラムを「ハンズオン」「アイデアソン」「ハッカソン」といったモジュールで構成し、この順番で実施するのが効果的だと考えられた。「ハンズオン」によりスキルを習得し、スキルに基づく着想と発想の機会として「アイデアソン」を実施、「ハッカソン」では新たに獲得したスキルでアイデアを具体化する。
(2) 開催日数の最適化
受講生の業務への影響、参加日程の調整のしやすさを考慮すると、開催日数は短いほうが良い。そこで、教育の目的を達成しつつ短期間で開催できるように、教育を改善しながら開催日数を最適化した。
(3) 複数部門と連携しての役割分担
ソフトウェア技術センター単独で本教育の全てを実施することはできなかった。そこで、各モジュールについての専門性を持つ社内の部門を探し、連携した。教育の全体とりまとめはソフトウェア技術センターで担った。そして、各モジュー
ルを提供するのに最適な部門との連携を進め、手順・役割分担を明確にしていった。連携部門のデザイン部門は、共創を体験するためのツールとしてプロトタイプを利用する「プロトタイプ思考」を教育に取り入れる役割を担った[7][8]。連携部門の DITC は、IoT 基盤や機械学習基盤を教育に取り入れる役割を担った。部門ごとの主な専門領域を表 2 に記す。
表 3 部門ごとの主な専門領域
部門

主な専門領域

ソフトウェア技術センター

教育プログラムの設計、教育運営、全体取りまとめ

デザイン部門デザイン思考、教育プログラムの設計、デジタル工作機械

DITC

IoT 基盤、機械学習基盤、及びその開発環境

5.改善策の実現方法
Boost Program の開催内容を表 4 に記す。1 回目以降の主な改善策は以下の通りである。
（１）プログラム構成の見直し•
ハンズオンとハッカソンの連続性の実現
第 1 回目のハンズオンでは、ハードウェア(Raspberry Pi)とソフトウェアを扱った。第 2 回目のハンズオンで、ハードウェアを用いずソフトウェアのみ扱ったところ、ハンズオンで学んだことをハッカソンであまり使用されなかった。そこで、第 4 回目以降のハンズオンでは、ハードウェア(Raspberry Pi)とソフトウェアの両方を扱える教育コンテンツとした。
•
２種類のハンズオンを実施。それぞれのハンズオンで実施できるコンテンツの種類を増やした。
a)当社技術のソフトウェア開発環境のハンズオン２種類
１）IoT 基盤
２）機械学習基盤b)工作機械のハンズオン２種類
76１）3Ｄプリンター
２）レーザーカッター（２）開催日数の最適化
第 1 回目の 12 日間よりも短くした。3 日間では短すぎた。6 日間が最適であった。
（３）複数部門と連携しての役割分担
2 回目以降は、3 部門で連携して役割を分担した。全ての教育日程へ 3 部門から講師を出した。教育準備の内容ごとに担当部門をおき、準備を進めた。新たに作った教育コンテンツについては、リハーサルを実施することで他の部門の講師へ知識共有し、教育全体の連続性を高められるようにした。さらに教育実施の後に KPT を実施することで、運営の細かい手順や、教育コンテンツの見直しなどのアイデアを次回以降へ反映しながら改善できた。
本教育の概要を図 22 に、開催内容を表 4 に記す。まず、「ハンズオン」により、先端のデジタル技術を習得させた。続いて「アイデアソン」「ハッカソン」により、共創による開発体験、ビジネスアイデア創出とプロトタイプ作成を体験させた。

図 22 教育の概要[3]表 4Boost Program の開催内容

モジュール

第1回

第2回

第3回

第4回

第5回

2020 年

2021 年上期

2021 年下期

2022 年上期

2022 年下期

デザイン思考／ハンズオン（IoT

ハッカソン

ハンズオン（機ハンズオン（機械デザインエンジニ基盤）

械学習基盤と学習基盤とアリング／AI・

Raspberry

Raspberry Pi）

IoT(AI ロボットPi）カー)／3D CAD

ハンズオン（3Ｄ

ハンズオン（レーザ／アイデアソン／

プリンター）

ーカッター）

アイデアソン

アイデアソン

アイデアソン

ハッカソン

ハッカソン

ハッカソン

ハッカソン／プレゼン・動画作成／マーケティング・
プロモーション

77

開催日数

12 日間

5 日間

3 日間

6 日間

6 日間

人数

32 名

24 名

12 名

30 名

30 名

連携部門

ソフトウェア技術

ソフトウェア技術

ソフトウェア技術

ソフトウェア技術

ソフトウェア技術セセンター主催センター主催センター主催センター主催ンター主催

デザイン部門経

ソフトウェア技術

ソフトウェア技術

ソフトウェア技術

ソフトウェア技術セ

由で外部会社にセンター、デザイ

センター、デザイ

センター、デザイ

ンター、デザイン部

委託

ン部門、DITC

ン部門、DITC

ン部門、DITC門、DITC で分担

で分担

で分担

で分担

部門からの選

公募、主催者枠

アイデア募集、開

公募、主催者枠

公募、主催者枠

抜、公募、主催（デザイナー、開発者公募（デザイナー、開（デザイナー）者枠（デザイナ

発者）

募集方法

発者）

ー、開発者）
ふりかえり

受講生が共創を

受講生が共創を持ち込んだアイデ

共創として成功。

共創として成功。

体験できた。しか体験できた。しかアを咀嚼できるプ

ハードウェアハッカソンでも前回

し、開催期間がし、ハンズオンのログラムにでき（Raspberry

同様、ハードウェア

12 日間と長い、内容をハッカソン

ず、受講生が共Pi）とソフトウェアとソフトウェアを合東芝ビジネスとので使用されなかっ

創を体験できなをあわせたハンズ

わせて使えた。デつながりを説明でた。使用されなかかった。

オンをしたことで、ジタル工作機械のきない、という課

った原因は、ソフ

ハッカソンでもハーハンズオンの種類

題が明らかになっ

トウェアのみのハ

ドウェアとソフトウを増やせた。

た。

ンズオンとし、ハン

ェアを合わせて使ソースコードを含む

ズオンでハードウェ

えた。

教育成果物を、イ（Raspberry

ンナーソースとしてPi）を使わなかっ東芝グループ内でたからと考えた。

共有できた。

6.改善による変化や効果
本教育により、共創のための新しい開発スタイルを実践するための「共創に向いた思考法」や「最新の開発スタイル・開発環境での作業」を受講生へ体験させることができたか評価するため、受講後アンケートの総合評価の 4 段階のうち最上位「とても良い」の割合の推移を調べた。その結果、第 5 回の値が最も高く、改善による効果を確認できた。

78

100

79%

割合（%）

80

81%
68%

69%

60

40

53%

20
0
第1回

第2回

第3回

第4回

第5回

図 23 受講後アンケートでの総合評価の最上位「とても良い」の割合
各開催回の受講後アンケートの自由記述を以下に記す。

•
•
•

•

•
•

第1回
他部門の方との繋がりや先端技術を使ったモノづくりを体験でき、有意義であった分野の異なるメンバとの共創で自分だけではできないものが作れた。モチベーション向上につながった
周りにも勧めたいので継続開催して欲しい
第2回
エンジニアとの壁を取り払いフラットに正直に意見を交わしながらブラッシュアップして行く体験ができ非常に有益
第3回
少し時間軸やハッカソンの進め方についてガイドがあるともっと良い
1.5 日の中でハッカソンを行うのは非常に短いと感じた

第4回•
多様な技能を持ち合わせた方と交流し、ソフト・ハードの両面でデモを作成できるのが良かった•
長く仕事をしていると視野が狭くなる傾向があるので、若手から発想の刺激を受けることができ、良かったと感じました

•

•

第5回
様々な人が集まり、アイデアを考え、企画・開発・デモ・プレゼンと短期間に集中して作成する
流れを体験することができ、面白かったです。 新しい価値を生み出すきっかけを体験できたと思います。 今後、同部門の人にも勧めたいと思います
前回の成果発表会の動画を見た所、数日でこんな成果を出せるなんてすごい、自分にできるのかなと不安に思いましたが、事務局、Gr メンバの皆様のおかげもあり無事に形にすることができ、大変勉強になったとともに達成感も味わうことができました79

•

チームをどうやってまとめるのか、自分の分野での何をアウトプットにするのか、他分野への話し方などを学ぶことができてよかった

7.改善活動の妥当性確認
本教育の改善では、共創のための教育を行うために、教育の開発・実施でも共創を行った。ソフトウェア技術センター(SPI 推進部門)、デザイン部門、DITC(IoT 基盤サービスを開発・運用している部門)に所属している専門性の異なるメンバが共創することにより、単独では実現しえない教育を開発することができた。また、本教育の受講生へ「共創をやっている」姿を見せながら「共創の実践方法」を伝えることができ、受講生へ「共創を体験」してもらえた。
改善策として「開催日数の最適化」「プログラム構成の改善」「複数部門と連携しての役割分担」を実行した結果、本教育の目的として設定した、「共創視点の目的」と「開発者の視点の目的」の実現へ貢献できた。受講生へ、「共通課題解決に向け協力して開発し改善し続ける新しい開発スタイル」を体験してもらうことで、「アイデアを次々と素早く具現化す
るソフトウェア開発方法を実践」してもらい、「共創によるソフトウェア開発」のマインドを醸成できた。また、2022 年度（第5 回）には、ソースコードを含む教育成果物を、インナーソースとして東芝グループ内で共有できた。本教育の改善により、
東芝グループ横断的に共創型の開発を促進する人財を育成する教育プログラムを構成できた。更なる共創人財の創出に向けて、開催を継続しつつ、拡大フェーズへの展開に繋げていく。

・ Raspberry Pi は、Raspberry Pi Ltd の登録商標。

M. 参考情報[1]2022 年度東芝グループ経営方針資料
https://www.global.toshiba/jp/ir/corporate/pr/others/opr2022/opr20220602.html, accessed2023-05-25.
[2] 田中武志, 白井 保隆, 田村 朱麗, 艸薙 匠,

東芝グループにおける SPI 活動 20 年史と今後の展望について 〜トップダウンとボトムアップを両輪としたアプローチ〜, SPI Japan 2021, 2021.
https://www.jaspic.org/event/2021/SPIJapan/TimeTable/general_session/session2A/2A3_ID00
2.pdf, accessed 2023-05-25.
[3] ソフトウェア技術センター, 共創・デジタル人財育成を目指すアウトプット指向教育の実践, 東芝レビュー77 巻 2 号
p.25, 2022.
https://www.global.toshiba/content/dam/toshiba/jp/technology/corporate/review/2022/02/1-0.pdf, accessed 2023-05-25.
[4] ソフトウェア技術センター, Output-Oriented Training for Co-creation and Digital Human Resource
Development, Toshiba Review Shience And Technology Highlight 2022 p.41, 2022
https://www.global.toshiba/content/dam/toshiba/ww/technology/corporate/review/2022/toshi
ba-review-science-and-technology-highlights-2022/2201.pdf, accessed 2023-05-25.
[5]Toshiba

Clip, ソ フ ト ウ ェ ア ・ デ ィ フ ァ イ ン ド で 、 信 頼 の ハ ー ド を 生 か す 【 前 編 】 【 後 編 】 , 2022.

https://www.toshiba-clip.com/detail/p=8310

https://www.toshiba-clip.com/detail/p=8447 ,80accessed 2023-05-26.
[6]職業「戸倉彩」, 中津川篤司, 小島英揮, 大内孝子 (編集), DevRel エンジニアフレンドリーになるための 3C,
翔泳社, 2019[7]衣斐秀聽,

緒方啓史, プロトタイプ思考によるビジネス創出, ヒューマンインタフェース学会誌 vol.24 No.2 p.4-

7, 2022[8]CPSx デザイン, ヒューマンインタフェース学会の学会誌に「プロトタイプ思考によるビジネス創出」について寄稿しました,
東芝の共創 Topics & Event, 2022
https://www.global.toshiba/jp/co-creation/corporate/news/2022/20220630.html,
2023-05-26.

81accessed3A2 モノづくり力強化の取り組み 野尻 優輝（住友電工情報システム株式会社）＜タイトル＞
モノづくり力強化の取り組み＜サブタイトル＞＜発表者＞
氏名(ふりがな)： 野尻 優輝(のじり ゆうき)
所属： 住友電工情報システム株式会社 QCD 改善推進部 生産技術グループ＜共同執筆者＞
氏名(ふりがな)： 中村 伸裕(なかむら のぶひろ)
所属： 住友電工情報システム株式会社 QCD 改善推進部 生産技術グループ＜主張したい点＞
組織全体のモノづくり力を向上させるため、新人に対してトレーニングを行った。
その中で、プログラミング未経験者向けのアルゴリズム教育と、外部設計できる人材の養成に挑戦した。

＜キーワード＞新人トレーニング、アルゴリズム、外部設計、プログラム開発生産性＜想定する聴衆＞
教育担当者、教育プロセス改善担当者、開発者＜活動時期＞
2020/04〜2023/06＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□ 改善活動を実施したが、結果はまだ明確ではない段階■ 改善活動の結果が明確になっている段階□ その他()

82

＜発表内容＞
1.背景
住友電工では社内で DX 推進活動が開始されたこともありシステム開発案件が急増している。これらの案件に対応する為にパートナーの増員やキャリア採用、新人採用の人数を増やすなどの対策が取られたが、弊社開発ツール（楽々FrameworkⅡ 以降、FWⅡ）の開発経験が少ない状態で外部設計やプログラム開発を行っている開発者が増加し、
一部プロジェクトでは、外部設計の品質やプログラム開発生産性の悪化を招いてしまった。また、ベテラン社員に若手の指導を行う時間的余裕がなくなったため、組織のモノづくり力低下が加速すると懸念された。そこで、以下の二つの対策を打つこととした。
・パートナー、キャリア採用者に対する対策：FWⅡの e-Leaning 教材の提供 [1]・新人に対する対策：4.5〜6 ヶ月の新人トレーニングの実施
今回は新人トレーニングについて報告する。
2.改善したいこと(1)プログラム開発生産性の向上
パートナーを指導できるような上級プログラマを養成したい。しかし、採用人数増加により、プログラミングが得意でない
新人の人数も増加しているため、フォローしながら高度な教育も行う必要がある。
(2)外部設計者の養成
外部設計者を数ヶ月の新人トレーニングで養成するのは困難であるため、3 年後までに外部設計を担当できることを目標とした。
(3)組織全体のモノづくり力向上(1)(2)を実現できるトレーニングを 5 年、10 年と継続すれば、モノづくり力の高い開発者の割合が増加し、組織全体のモノづくり力を向上することができる。
3.改善策を導き出した経緯
3.1 プログラム開発生産性の向上(1)未経験者対策
未経験者の中には、二重ループのプログラムが理解できない者がいた。理解できないのは、変数が保持する値が処理中に変化している点かと考え、九九表を表示する JavaScript のソースコード用意し、1 行ずつ動かした場合の変数が保持する値と処理結果を示すアニメーション資料(図 24)を作成したが、理解が得られなかった。

図 24 二重ループ説明資料
83講師陣で議論し、そもそもコンピューターの動きがイメージできていないのだという仮説を立てた。対策は、逐一実行結果を確認しつつ試行錯誤しながらロジックを作成することであると考え、以下の条件を実現できる教材を探した。
・実行結果が逐次表示される
・試行錯誤を容易に実施できる（修正、再実行が簡単）(2) FWⅡ習得効率化
SQL、Java、FWⅡは繰り返し記述することでスキルが上達していくため、如何に長くコーディング演習を実施するかが習得効率化の肝であると考えた。従来の研修では、演習の前に各種ツールのインストール、演習環境準備（データ、サン
プルプログラム等）が必要であり、設定ミスなどで動かない人が一人いるだけで全体の進行が止まってしまう問題が発生していた。環境構築にかかる手間を省き、コーディング演習の時間を増加する施策を検討した。
3.2 外部設計者の養成
開発システムの目的や施策、期待される効果を把握できていない場合、ユーザーに言われたまま仕様書に記述してしまい、機能の目的から外れた質の悪い外部設計を行ってしまう。質の良い外部設計は目的、施策、期待効果の関係を深く理解できなければ作成できない。そこで、目的を元に施策を考えさせることで、目的に合った外部設計ができる様に誘導する。ミニプロジェクトを用意し、これらの体験をさせて外部設計の本質を体得させる。
4.改善策の内容
4.1 プログラム開発生産性の向上(1)未経験者対策
Google 社が提供している初心者向けのプログラミング学習ツールである Blockly Games を用いる。Blockly
Games は、用意された処理ブロックをマウス操作で組み合わせるだけで簡単に処理が実装でき、処理結果を視覚的に把握できる構成(図 25)となっており、イメージ通りの動きになるまで試行錯誤を繰り返すことで、コンピューターの動きに対する理解を深める。

図 25

Blockly Games(2)FWⅡ習得効率化
環境構築にかかる手間を省くため、SQL、Java、FWⅡの演習をブラウザ上で実施できるようにする。

84

(3)その他
初心者プログラマを中級プログラマに押し上げるために、以下の施策を実施
・ソート、マージ、再帰等のアルゴリズムを作成する 12 個の演習
・1 週間の SQL のトレーニング
・1 週間の Java、Java Servlet 等の基礎技術演習
・プログラミング構造図作成演習
4.2 外部設計者の養成
社内ユーザーを相手に要件定義、外部設計、実装を行う約 2 ヶ月のミニプロジェクトを行う。このミニプロジェクトは社内で候補を募集した、実際に使うシステムを対象とし、システム化の目的にあった施策の検討から設計、開発、テスト、本番化までを行うものである。
5.改善策の実現方法
5.1 プログラム開発生産性の向上(1)未経験者対策
未経験者は、コンピューターの動きがイメージできていないという仮説を立て、動作が目に見えるツールを用いた研修が必要と考えた。Raspberry Pi を用いたロボットや MIT メディアラボが開発した Scratch などを検討した結果(表 5)、製品価格や教材の有無から Google 社が開発した Blockly を用いることとした。
表 5 教材の検討
評価点

教材

ロボット

ScratchBlockly

製品価格

× (数千円/個)○ (OSS)○ (OSS)

教材準備工数△ (別途演習作成が必要)△ (同左)○ (教材あり)教育効果○ (動作が確認できる)○ (同左)○ (同左)

結論

×

×

○

(2)FWⅡ習得効率化
演習環境構築の手間を省くため、ブラウザ上で演習を実施すると自動的に個人別演習環境が Linux サーバー上に作成される仕組みを作成した。新人が操作する演習実行画面を図 26 に示す。資料を読みながらソースコードを作成し、実行ボタンを押下するとサーバー上に個人別演習環境が作成されコードが実行される。実行結果もブラウザ上で確認することができる。演習環境構成の仕組みを図 27 に示す。プログラム実行ボタンを押下するとサーバーの環境設定 API を
call し、サーバーに用意された複製用開発環境を複製することで個人別の開発環境が作成される。ブラウザ上で実行されたプログラムは個人別開発環境で実行されるため、他人のプログラムや環境の影響を受けることは無い。

85

図 26

図 27

演習実行画面

個人別演習環境作成の仕組み

5.2 外部設計者の養成
要件定義を全て実施すると演習期間に収まらない。その為、システム化の目的が明確になるところまでユーザーと事前準備を進めておいた。新人は明確になった目標を元に施策を検討できるので、短期間でプロジェクトが完了できる。
86

6.改善による変化や効果
6.1 プログラム開発生産性の向上(1)未経験者対策
トレーニングの初期に未経験者対策を実施したことで、未経験者もその後の研修についてこられた。
また、Blockly Games の回答を何人かに発表してもらったところ、迷路を歩くゲームでは、ゴールにたどり着く道順が人によって異なっていた。正解は一つではなく、効率的なアルゴリズムがあることを理解させることができた。
(2) FWⅡ習得効率化
施策を含めたカリキュラムで部門研修を実施した結果、研修完了時点のプログラム開発生産性は施策実施前と比較して 3 年間すべて上回っている。21 年以降はプログラム未経験者の割合が増加し、21 年は特に未経験者が多かったた
めプログラム開発生産性が下がってしまったが、未経験者フォロー施策を行った結果、22 年にはプログラム開発生産性が持ち直した結果となっている。

図 28

施策実施後のプログラム開発生産性

6.2 外部設計者の養成(1)研修中の成果
ミニプロジェクトの施策検討では、様々な施策案が提案され、検討された。多くのものは目標と合わないとチーム内で却下され、目的に整合したもののみがユーザーに提案された。この提案はユーザーに採用され、質の良い外部設計が実施されたことが確認できた。
(2)研修終了後の成果
研修終了後、新人の 8 割(21 人中 17 人)が配属後３年以内に外部設計を担当している。
7.改善活動の妥当性確認
6 章の結果により、新人のプログラム開発生産性向上と、外部設計ができる新人の養成という 2 つの成果で組織全体のモノづくり力向上に貢献できたと考えている。今後もこのトレーニングを継続し、組織全体のモノづくり力がどの程度向上するか確認したい。
87

N. 参考情報[1] 岡本優奈, 開発実習を含む集合研修の e-Learning 化と成果, SPIJapan2021, 2021
http://www.jaspic.org/event/2021/SPIJapan/TimeTable/general_session/session1B/1B2_ID00
3.pdf(2023/05/25 閲覧)88

3A3 安全工学由来のモデリング STAMP を用いた大学院 PSP 教育改善活動の促進 日下部 茂（長崎県立大学）＜タイトル＞ 安全工学由来のモデリング STAMP を用いた大学院 PSP 教育改善活動の促進＜サブタイトル＞＜発表者＞
氏名(ふりがな)：日下部茂(くさかべしげる)
所属： 九州工業大学(*投稿時は長崎県立大学)＜共同執筆者＞
氏名(ふりがな)： 梅田政信(うめだまさのぶ)
所属： 九州工業大学
氏名(ふりがな)： 片峯恵一(かたみねけいいち)
所属： 九州工業大学
氏名(ふりがな)： 荒木俊輔(あらきしゅんすけ)
所属： 九州工業大学＜主張したい点＞① 目的:産業界向け個人レベル開発プロセスのトレーニングコースのひとつである PSP for Engineer を用いた大学院でのプロセス教育を改善する② 手段:改善を要する状況の分析に安全工学由来のアクシデント説明モデル STAMP を用いた
③ 成果:STAMP を用いたモデリングは改善対象を効果的に抽象化できた。モデリングにより複数の指導者間で観点をそろえた状況の共有ができ改善に向けた取り組みが促進された。STAMP の代表的な分析法には設計時などに事前に行う STPA と望まない事象が発生した後に行う CAST がありそれらを併用した。質的アプローチのひとつであるインタビューも用い定性的な面での改善を確認した。PSP はプロセスデータを測定し分析するフレームワークを持っており我々もこれまでの受講者のプロセスデータを記録している。そのようなプロ
セスデータを用いた定量的な評価については今後の課題である。
＜キーワード＞個人レベル開発プロセス
プロセス教育モデリング＜想定する聴衆＞
プロセスの定着や改善を目標とした実務者・指導者＜活動時期＞
2018 年〜＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)89□ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階✓ その他(改善活動を継続的に実施中で一部の結果が出ている状況)

90＜発表内容＞
1．背景
九州工業大学(以降九工大と略)は、文部科学省「先導的 IT スペシャリスト育成推進プログラム」をきっかけに、情報化
社会を牽引する高度情報通信技術者の育成に取り組んできた。そのような取り組みの一つとして 2007 年よりカーネギー
メロン大学ソフトウェア工学研究所と連携してソフトウェア開発プロセスの教育を行ってきた。具体的には個人レベルの PSPとチームレベルのアカデミア版 TSPi の講義と演習を大学院で行ってきた。その指導は SEI が認定していた PSP インストラ
クタ資格の取得実績がある教員が行なっており一定レベルの指導がなされている。(※2018 年 10 月より SEI から
Creative Commons のライセンス管理に移行)
2．改善したいこと九工大の事例では、開発するソフトウェアの品質向上に必要なスキルの修得に PSP による教育が有効なことが示されている。その一方、PSP のトレーニングコースを想定期間内に修了できない学生や、ドロップアウトする学生がいるといった問題も生じていた。この問題は早期から認識されその改善の取り組みはなされていたが今回それをさらに改善（促進）したい。
3．改善策を導き出した経緯
九工大では以前から学生の修了に関する問題が認識され、専任教員の間では動機づけモデルの定式化[1]といった、教育改善に向けた取り組みがなされていた。 そのモデルは、組織論的期待モデルをベースに定義した基準状態遷移モデル
を拡張したものである。PSP 受講者を状態機械とみなし、動機づけに関わる状態と操作により動機づけプロセスを定式化している（図 29）。このモデルにより、PSP に関する知識やスキルの導入から定着の成功や失敗に至るまでの過程の形
式的な表現を試みている。

図 29

組織論的期待モデルに基づく動機付けプロセスの構造（文献[1]をベースに作成）

発表者は 2018 年度から非常勤講師として九工大での PSP の教育に参加した。その時点では状態遷移機械としてモデ91

ル化された学生の状態遷移が実際に望ましいものとなるような、具体的な指導シナリオはまだ確立していなかった。学外からの非常勤講師である発表者はこれまでの経緯や暗黙知を共有できておらず具体的な改善活動に参画するのも容易ではなかった。そのため、シナリオレベルでの指導の改善を具現化するために、各教員が実践している指導シナリオの形式知化や、改善のフレームワークの共有を通して改善活動を促進することを考えた。そのような形式知化や改善のフレームワー
クとして、安全工学由来の STAMP のモデリングが有用であり、特にミッション達成の観点を重視して適用するのが効果的と考えた。
4．改善策の内容
STAMP はコントロールの観点で系を抽象化してモデリングを行い、コントローラとコントロール対象の間の制御アクションとフィードバックに着目して、系が保つべき制約が破られないよう分析を行う。このような STAMP のモデリングを用いて指導シナ
リオを表現することで、改善に対する認識と改善活動の見通しを共有し、具体的な改善活動を促進することを考えた。九
工大の PSP 教育を、指導者と受講者の間の指示とフィードバックのやり取りでトレーニングを進めるという観点で抽象化しモデル化した。そのモデルをベースに保つべき制約が破られミッションが未達とならないように指導シナリオの改善を目指すというフレームワークを共有した。このようなフレームワークは、既存の学生の動機づけ状態遷移モデルと組み合わせ可能で（図 30 参照）、この組み合わせにより学生の動機付けを下げる要因を分析して対策を立てるというアプローチが可能となる。このようなアプローチにより、それまでの取り組みとの連続性を保ちつつ、引き続く改善活動に見通しを与えてその具体化を促進した。

図 30

状態遷移モデルと STAMP による改善フレームワーク

5．改善策の実現方法
PSP にはかつて SEI によるインストラクタの資格試験があり、九工大で PSP 教育を担当している教員(現在 4 名)はその資格取得経験者で、一定レベルの指導ができるといえる。しかしながら大学での実際の指導の詳細は、組織ごとのコンテク
ストや、個別の指導者と受講者の組み合わせによって状況が異なる可能性がある。改善にあたり現状を適切に把握するとしてもあり得るあらゆる具体的な指導のシナリオやコンテクストを自然言語表現で共有するのは容易でない。指導者と受講者のやり取りに着目した抽象化を通して安全工学由来の説明モデル STAMP を用いたモデリングを行い、さらに動機づけモデルと組み合わせて指導状況の表現と観点の統一を図った。図 31 に示すように、指導者に相当するモデル要素であるコントローラが持つプロセスモデルに、受講者の状態に対応するモデル変数を含めた。

92

図 31

受講者の状態を含めた指導ループ

次に STAMP のモデリングを用いる分析手法 STPA の適用を試みた。STPA は大きく四つのステップから構成される[2]。
これらのうちステップ 2 までは、前述の図 31 に示したモデリングと重なることが多く、その結果を流用した。
ステップ 3 では、指導アクションに対するハザードを、「与えることでハザード」、「与えないことでハザード」、「早すぎる・遅すぎることでハザード」、「長すぎる・短すぎることでハザード」という四つの観点で、ハザードにつながり得る指導アクションを分析する。例えば PSP のプログラム作成課題では受講者はプランニングフェーズの成果物をインストラクタに提出、インストラクタがプランニングのプロセスや成果物を確認し、問題がなければ設計を含む開発フェーズに進む。問題があればインストラクタは修正の指示を行い、受講者は修正後に再提出し再度確認をする。この「プランニングを承認する」という指導のアクションに関して、学生の動機づけの観点では、承認がなかなか出ないと動機づけが下がる可能性があり「遅すぎることでハザード」になり得る。しかしながら安易に承認するとプロセス教育の質が担保できない。
ステップ 4 として、そのような状況になりうるシナリオを過去の指導事例も含めて分析すると、プランニングで作成が求められている要求文書の作成がうまくできず複数回の再提出となっている例が複数あった。なぜそのような状況になったかを分析すると、PSP はもともと産業界のエンジニア向けのもので、日本の典型的な大学院生に対してトレーニングを行う際にはその差に注意を払う必要がある。カリキュラムなどと照らし合わせると、典型的な持ちあがりの九工大の大学院生の場合、要求仕様書を書くような講義がないことが確認された。要求文書の書き方を PSP トレーニングの中で行うのは現実的でないた
め、要求に関する支援を充実するなどして本質的なプロセス学習以外で躓く要因を低減するといった対策で改善を図った。
上記のような損失シナリオの分析では、失敗事例における学びを効果的に行い過去の知見を活用するのが望ましい。そのような失敗事例からの効果的な学習のために、事故発生後の事後分析法 CAST [3] での分析にも着手した。
6．改善による変化や効果
本アプローチを用いることで、以下のような効果があった。
⚫

指導に関する認識の共有が進み、学外の筆者も九工大の PSP 教育の改善活動に積極的に関与することができた。

⚫

九工大でのこれまでの取り組みに含まれる状態遷移による動機づけモデルを、STAMP でのモデリングに統合・活用した改善のフレームワークとすることができ、連続性を持った改善活動を推進することができた。

⚫

受講者の修了を妨げる要因やその要因から派生するシナリオについて、STAMP/STPA によって構造的な分析が促進され、分析の方法や結果についてのインストラクタ間の共有も促進された。
93

⚫

分析時以外での実際の指導時でも、指示（指導アクション）を出す際に、受講者の状態と置かれているコンテクス
トを意識するようになり、その結果、改善への気づきが増えた。

7．改善活動の妥当性確認
これまでの妥当性確認は、いわゆるアネクドータルなものが中心で、厳密な確認は今後の課題である。
⚫

体感的にはモデリングによる適度な抽象化や説明モデルをベースにしたシナリオの分析は、改善活動に対し効果があったと感じる。しかしながら厳密な測定はできておらず定量的な評価はできていない。

⚫

安全工学由来のモデリングを用いた改善活動と、学生の実際の PSP トレーニング受講時の動機づけ変化について、動機は直接的な値を測定できないためインタビュー調査などを行っていたが、コロナ禍で中断したままになっている[4]。

⚫

PSP トレーニングにおけるインストラクタの役割の評価を、PSP の受講者データと対応付けて定量的に行う試みも実施中である[5]。

O. 参考情報[1] Umeda, M., Katamine, K., Ishibashi, K., Hashimoto, M. and Yoshida, T.: Motivation Process
Formalization and its Application to Education Improvement for the Personal Software Process
Course, IEICE Transactions on Information and Systems, Vol. E97-D, No. 5, pp. 1127–1138(2014).
[2] Leveson, N. & Thomas, J.: STPA Handbook 日本語版 (JAXA 監訳), http://psas.scripts.mit.edu/
home/get_file2.php?name= STPA_handbook_japanese.pdf(参照 2023-09-26)[3] Leveson, N.: CAST Handbook (JAXA 他訳), http://psas.scripts.mit.edu/home/wp-content/uploads/2021/06/CAST_HandbookJPN.pdf(参照 2023-09-26)[4] 日下部茂 他: システム理論に基づくモデリングと質的研究を併用したソフトウェアプロセス教育の動機づけシナリオ
改善, ソフトウェア技術者協会ソフトウェアシンポジウム SS2018 予稿集[5] 梅田政信 他: ソフトウェアプロセスの自己改善は自学自習でも可能なのか？, ソフトウェア技術者協会ソフトウェア
シンポジウム SS2019 予稿集

94

3B1 続：事業変革を見据えた、品質マネジメントシステムの継続的革新 福田 秀樹（TIS 株式会社）＜タイトル＞
続：事業変革を見据えた、品質マネジメントシステムの継続的革新＜サブタイトル＞
現場の創意工夫と規格要求事項のバランスをいかに確保するか＜発表者＞
氏名(ふりがな)：福田 秀樹（ふくだひでき）
所属： 品質マネジメント革新本部 品質マネジメント革新部＜共同執筆者＞
氏名(ふりがな)：池田 敏昭（いけだとしあき）
所属： 品質マネジメント革新本部 品質マネジメント革新部＜主張したい点＞
・時代の変化を先読みし、品質マネジメントシステムを改善し続けることが重要・変化に耐えうる、レジリエンスな仕組みとすることで様々なノウハウを活用することができる
・内外のあらゆる知見を参考にしながら、「自分たちの言葉」として具体的活動に落とし込むこと
・現場の創意工夫と規格要求事項の充足との落としどころを見つけることが必要
・実務を回しながら時に大胆に、時に漸進的に改善をし続けることが重要・当社にとっての「品質」は単にシステムの品質だけでなく、お客様や社会に提供できる「価値」＜キーワード＞・サービス品質、ISO9001[1]/ISO20000[2]、品質マネジメントシステム、開発標準＜想定する聴衆＞
・開発標準を作成している SEPG の方・プロセス改善を推進している方・ISO9001,ISO20000 適用に関心のある企業の施策推進の方・マネジメントシステムの有効性に悩みをお持ちの企業の方＜活動時期＞
・2019 年 4 月〜継続中＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

95

＜発表内容＞
1.背景・企業の成長と一定以上の品質確保のために、品質マネジメントシステムの構築は欠かせない。顧客や社会ニーズの多様化や IoT をはじめとした「繋がる」システム化、SaaS 型ビジネスの伸長など、提供するシステムやサービスの品質確保の重要性はかつてないほど高まっている。こうした変化に追随し、陳腐化を防ぎ、品質マネジメントシステム自体も変化し続ける必要がある。
当社はこれまで ISO9001:1994 や 2000、2008 に準拠した品質マネジメントシステムを構築、現場の実情に合わせて改善を継続してきた。今回は、2021 年度発表の続編として、2018 年度から手掛けてきた、サービス品質の国際規格 ISO20000 に準拠した品質マネジメントシステムの構築に当たって前回発表以降に改善してきたこと、工夫したことを発表する。品質マネジメントシステムをはじめ各種の開発標準の構築を目指す組織にとって活動のヒントとなれば幸いである。
2.改善したいこと・前回発表時には改善効果の測定が未到来であり、効果検証が残課題となっていた。
その後の ISO 外部審査において、当社マネジメントシステムの特徴である「現場の創意工夫」を踏まえながら
ISO20000 規格要求事項の充足を目指すには、仕組みづくりの面で今一歩不足があることが判明。新たに課題化。
－ISO20000 で要求される管理項目が確実に実装できているか保証できない－サービス運用における ITIL の思想を全社的に理解させる必要がある
・上記の課題を解決し、現場活動を下支えできる仕組みに更にブラッシュアップする必要があることが分かった。
3.改善策を導き出した経緯
・ISO 外部審査により客観的、公的な視点で規格要求事項の実装ができているかどうかを評価、2 に掲げた課題を抽出。特に ISO20000 の定着に向けてより具体的な仕組みづくりが必要と判断。
・具体的な標準群を追加整備の上、外部コンサルタント等の知見も加味して標準化を図り、その内容を対象の現場に展開することにより、品質マネジメントシステムとしての完成度を更に高めることができると判断した。
4.改善策の内容
・システム開発部分を包含した、サービス企画〜開発〜運用までを網羅した品質マネジメントシステムの構築
・ISO9001 と ISO20000 の双方の規格要求事項に準拠し、一つのマネジメントシステムとして構築
・ISO 外部審査結果を踏まえてサービス運用領域の標準を整備
・実務に活かせる仕組みとなっているかを検証
5.改善策の実現方法(1)広範な知見を結集してマネジメントシステムを構築
・マネジメントシステムの構築には多くの知見が欠かせない。標準化を図る SEPG の組織メンバーのみならず
QA メンバー、現場有識者など多くのメンバーを巻き込み、「あるべき姿」を構築することにした。
・ISO20000 を先行で取得しているグループ企業のメンバーもマネジメントシステムの構築メンバーに加え、認証取得を目指す上での考慮事項や注意点等のノウハウを盛り込んだ。
・活動が独りよがりにならないよう、外部の規格要求事項や各種標準の要求事項を精査、求められている事項が漏れなく、適切に盛り込まれた状態にマネジメントシステムを作り上げた。
・定義内容が規格要求事項を満たしているか、外部コンサルタントの目で検証して頂いた。
96

(2)自分たちの「コトバ」で定義
・ITSMS ユーザーズガイド[3]をはじめ、外部の各種規格要求事項や標準を活用して標準を構築。ただしこれらの用語は比較的概念的かつ多義的な用語が多く、社内には馴染みにくい。当社は現場で活用されている効果的な仕組みをうまく活用し「生きたコトバ」として標準を構築。これにより現場への理解浸透を図りやすくした。
更に ISO20000 の規格で要求される管理手順を現場に展開しやすい形で構成しなおして標準化した。
(3)レジリエンスな標準化・標準化が行き過ぎると「融通が効かない」「工夫ができない」といった硬直化を招き、やがて利用されなくなってしまうことから、必須実施事項は必要最低限にとどめ、現場の創意工夫や知見を活用しやすい仕組みとした。
(4)時間をかけて理解浸透を図る
・全社一律に ISO20000 レベルの導入を図る方針を見直し。
当社のサービスビジネス上、重要と判断したサービスに対しては ISO20000 レベルの標準化を厳密に適用。それ以外のサービス・SI 運用には運用上必要最低限の遵守事項に絞って実装させる方針に切り替え、適用を推進。
・厳密適用先には ITIL の理解浸透、管理標準の支援等で理解浸透を図り、それ以外の先には e-learning などの教育ツールを用いて広く理解浸透を図ってきた。
6.改善による変化や効果・統合版品質マネジメントシステムは構築完了後、ISO 外部審査を踏まえて改善を図り、第 1 弾の普及展開は完了。2022 年度の外部審査にて「オーソドックスな手順ながら各段に進歩」との評価を得た。必須実施事項の見直しを更に図って全社への展開を実施中のため、改善効果は引き続き計測しているところ。
今年度より 3 か年の計画で以下の通り理解浸透を図る計画。
－2023 年度：ISO20000 レベルの厳密な適用サービスを徐々に拡大しながら、必須遵守事項の全社展開を図り、全社の運用レベルを底上げ－2024 年度〜2025 年度：サービスだけでなく SI 運用の中からも経営的に重要な案件について ISO20000
レベルの認証取得を拡大
これにより、サービスのライフサイクル全般での品質保証の仕組みを完成させる。並行してグループ企業への展開も図ることにより、グループ全体で「同じ考え方に基づくマネジメントシステムが回せる」ことにより、企業間のシナジー効果や品質意識の醸成を図ることができると考えている。
7.改善活動の妥当性確認
・今回構築した品質マネジメントシステム自体は、当社固有の要素が盛り込まれたものであるが、5 で示した改善策の実現方法は、他組織の標準化を進めるにあたっても適用可能な進め方と考える。
・改善活動による効果は徐々に出始めている。当社の事業構造転換に先駆けて、品質マネジメントシステムとして現場に対する方向性を示せたことで、今後の利益実感に繋がるものと確信している。
P. 参考情報[1]JIS Q 9001:2015(ISO9001:2015)[2]JIS Q 20000-1:2020(ISO20000:2018)[3]ITSMS ユーザーズガイド https://www.jipdec.or.jp/archives/publications/JIP-ITSMS111-30.pdf

97

3B2 ソフトウェア開発における DX 活動の道しるべ 寺村 幹夫（株式会社デンソー）＜タイトル＞
ソフトウェア開発における DX 活動の道しるべ＜サブタイトル＞
異なる事業部門間で情報共有を可能とする DX レベル定義＜発表者＞
氏名(ふりがな)：寺村幹夫（てらむらみきお）
所属： 株式会社デンソー ソフトウェア技術２部＜共同執筆者＞
氏名(ふりがな)： ―所属：―＜主張したい点＞
DX 活動は特定箇所の情報デジタル化や作業自動化だけでなく、これらの技術を活用し業務、プロセス、組織
風土を変革するような活動に昇華していく必要がある。
そのような活動の姿にするためには、異なる開発形態や価値観を持った人たちが集って議論しアイデアを創出することが重要と考えている。
共通のゴール、モノサシとなる DX レベルを定義し、社内で扱う多数の製品ソフトウェア開発がその DX レベルで目標や計画を立てて共有することで DX 活動を推進するための道しるべができた。
＜キーワード＞DX、 改善、 変革、 共通のモノサシ、 標準開発プロセス、 デジタル化、 自動化＜想定する聴衆＞
ソフトウェア開発者 特に改善推進者となる SEPG、PMO の方＜活動時期＞
2020/8~2023/3＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)■ 改善活動を実施したが、結果はまだ明確ではない段階□ 改善活動の結果が明確になっている段階□ その他()

98

＜発表内容＞
1.背景
2019 年時点の私は、とある事業部門のプロセス改善を担当してきた。
品質向上、コストダウン、開発スピード向上を地道な改善活動を行い、ソフトウェア開発力を向上させてきた。
2020 年に入り、経営層からの号令のもと全社レベルで仕事の進め方の変革活動が強力に動き始めた。
変革活動の手段として DX があがり、DX の推進活動が各事業部門内の製品開発単位で立ち上がった。しかし、開発現
場で情報のデジタル化や作業自動化は自部署内のこれまでの改善活動で実施し尽くしている感もあった。このような状況から改善活動を超えた活動に転換に課題を抱えていた。
2.改善したいことDX の意味する変革レベルに引き上げるには 自部署内の活動では変革レベルに到達しない可能性も高く、打破するために、多様な製品開発、多様な価値観をもった人材が集まり、共通ゴールを目指しアイデアが出しやすい DX 活動としたい。
デジタル化、自動化、再利用、AI 活用といった開発力向上の手段が存在するが、成果を手っ取り早く出そうとすればするほど個別最適になりがちになる。課題解決の良事例の展開のしやすさ、ツールの保守、人材の流動性も考慮し全体最適を考慮しながらの DX 活動としたい。
3.改善策を導き出した経緯
多くのソフトウェア開発者は日々の改善活動に自負がある中で、ソフトウェア開発自体もベースソフトからアーキテクチャの再構築を行わない差分開発が主流を占める PRJ も多く、変革レベルの活動の必然性に対する意識も低かった。
先ず、変革活動に必要なこととして“外を知る”ことから始め、社内の異なる担当製品間や事業部門間で交流することによって今回の変革レベルのテーマとした DX 活動の推進ができるのではないかと考えた。各事業部門の代表者が集まり DX
活動が開始するも各事業部門の視点で目標・課題・解決策の理解、共有するだけでも多くの時間を費やし、実りが少なかった。私は活動を推進するポイントとして共通のモノサシを作ることが最重要と考え検討を開始。
共通のモノサシづくりのアイデアとして、車載向けソフトウェア開発において欧州 OEM が複数のサプライヤに対し製品発注の可否を判断としてプロセスアセスメントモデル（Automotive-SPICE）を使用しており、そのモデルは俯瞰的で体系的となっており、その要素にヒントがあると考えた。
4.改善策の内容
・ボトムアップアプローチから事業部門横断のトップダウンアプローチ取り込みへのマインド改革
・課題解決の手段ベースでの議論から、普遍的な標準開発プロセスの工程を軸とした活動
・共通のモノサシとなる工程毎の DX 難度決定・DX レベルと解決策との紐づけ
・ガバナンスの効いた DX 推進体制の構築
5.改善策の実現方法
・事業部門別で算出した積み上げ方式の目標設定から 高いゴール思考からの目標設定に方向変換。
目標達成への難度が高く、事業部門内のみで課題解決が困難なことから、各事業部門リーダを集め、各課題共有し課題解決していくための DX 推進タスクフォースチーム（以下、TF）を結成。
・異なる製品の特徴や開発形態でも事業部門間で良事例を横展開するために各事業部門のローカル色（用語、開発
プロセス戦略に関連する手段）を除く必要があり。TF 内の議論においては、普遍的な社内標準ソフトウェア開発プロセ
ス定義を活用することで TF メンバ間が齟齬なく議論できるように TF 活動を進めた。
99

・また、車載向けソフトウェア開発でツール導入が先行する欧州流の開発スタイルも学ぶためにも、開発プロセスのアセスメ
ントモデルから工程と工程間の関係性の意図を読み解き、俯瞰的かつ体系的に出来ていることを TF メンバ間で確認。
・上記の理解が進んだところで、さらに各工程を分析し ①Input、Output の整理、②全体俯瞰の視点で各工程のInput と Output の関係性整理。（図１参照）（V 字プロセス上の縦方向 要求と要件の分離 要件と設計の分離と階層化、左辺と右辺の横方向の連結方法）
・上記のプロセス理解が進んだところで、デジタル化、自動化の観点で DX 難度レベルを工程毎に定義。 （図２参照）

図１： 基本の DX-Level 定義

図２：DX-Level 定義と成果物の関連図・定義した DX レベルに対して 各事業部門の現状と達成している解決策（プロセス＆ツール）の紐づけと今後の計画、課題を関係者間で共有する仕組みを構築。
6.改善による変化や効果
・全社規模での DX 活動体制構築。（事業部門代表メンバによる TF チーム体制＋経営層とのステアリングコミット）
・複数の事業部門に跨る、社内で扱う多数の製品ソフトウェア開発にて、共通の DX レベルを用いて現状レベル、目標、
課題、計画立案を立案。 各製品の活動が一枚の地図上で俯瞰した形で DX 活動が見える化。（図 3、4 参照）
・DX レベルアップ目標に向けて、事業部門跨いだ、解決策の横展活動及び議論の活性化
・DX 推進活動自体 及び、ＤＸを加速させるためのツール開発のリソース集中化
・ソフトウェア開発プロセスの理解が進み、人が頭を使うことが重要な工程と作業メインの工程との層別
XX

ドメイン
製品
①要件定義・アーキ設計

'YY/X
(現状)

②詳細設計・実装③テスト設計④統合・結合⑤テスト①要件定義・アーキ設計

'YY/X
(目標)

②詳細設計・実装③テスト設計④統合・結合
⑤テスト
①要件定義
アーキ設計
②詳細設計・実装

新規導入DX③テスト設計解決策④統合・結合⑤テスト

図３： DX-Level 向上の活動方針

A
ECU

Ｂ
ECU

Ｃ
ECU

Lv0.5
Lv2
Lv1
Lv1
Lv1

Lv0.5
Lv2
Lv1
Lv2
Lv2

Lv0.5
Lv1
Lv1
Lv1
Lv2

Lv1
Lv2
Lv1
Lv2
Lv2

Lv1
Lv2
Lv1
Lv2
Lv2

Lv1
Lv2
Lv1
Lv2
Lv2

Doors
Doors
Doors
ND(ESPRESSO)+EA
ND(ESPRESSO)+EA
ND(ESPRESSO)+EA
SVN|VBベース＋α
SVN|VBベース＋α
SVN|VBベース＋α
SVN|Jenkins|WinActor
SVN|Jenkins|WinActor|
SVN|Jenkins|WinActor|
|
MBD
MBD
各項目ごとに 実現するツールを記載
MBD
SVN|VBベース＋α
SVN|VBベース＋α
SVN|VBベース＋α
CATT
CATT
CATT
SVN|VBベース＋α
SVN|VBベース＋α
SVN|VBベース＋α
CICT標準FW
CICT標準FW
CICT標準FW
Jenkins、Python
Jenkins、Python
Jenkins、Python
CRAMAS＋CATT
CRAMAS＋CATT
CRAMAS＋CATTECU-TESTTECU-TESTTECU-TESTT

図４：各製品の DX-Level の現状、目標、解決策リスト

7.改善活動の妥当性確認
以下、全社規模での DX 活動の道しるべ的なものができた。それによって、単なるデジタル化、作業の自動化だけでなく、開発プロセスからも見直す、真の DX 活動としてスタートラインに立つことができた。
・DX 向上への解決策の横展が容易となり、かつ多様な人材との交流で変革活動ができる土壌が形成できた。
・DX 活動の共通モノサシである DX レベル定義で各事業部門の現状レベル、計画が関係者間で共有され、ガバナンスの100効いた推進活動が構築できた。
・DX 推進が戦略的となり、さらに変革時の活動と日々の改善活動と棲み分けすることで持続的な活動に昇華できた。
・人が頭を使う工程が特定でき、AI 活用も見据えたソフトウェア開発の DX 活動の方向性も定まってきた。
Q. 参考情報[1] 要求工学知識体系（REBOK）概説，独立法人情報処理推進機構（IPA），[2] ソフトウェア疲労をアーキテクチャ設計で ソフトウェア品質管理研究会 2019 年度第 8 回特別講義 山田大介,[3] A-SPICE Engineering Process の導入と活用の勘どころ 2019 K-SPICE プレゼンテーション資料 寺村幹夫
[4] 組み込みシステムの設計者向け要件定義ガイドラインの提案と評価：2020Sqip 研究会 研究５論文＆報告[5] 「要求と仕様品質」エンジアリングとコミュニケーション ソフト品質管理（Sqip）研究会 OpenDay 栗田太郎
[6] テスト自動化研究会 - テスト自動化の 8 原則 (google.com)[7] デジタルトランスフォーメーションに向けた要求管理知識，第 20 回知識流通ネットワーク研究会，
SIG-KSN-020-01 山本修一郎，[8] システム×デザイン思考とアーキテクチャ思考による新価値創造 ソフトウェア品質管理研究会 2019 年度
特別講義 白坂成功[9] Automotive SPICE Process Assessment Model V3.1

101

3B3 アジャイル開発における品質保証移行モデルの提案と実践 石井 裕志（株式会社 東芝）＜タイトル＞
アジャイル開発における品質保証移行モデルの提案と実践＜サブタイトル＞
ホップ！ステップ！ジャンプ！アジャイル開発における現実的な品質保証のあり方とは＜発表者＞
氏名(ふりがな)：石井 裕志（いしいひろし）
所属： 株式会社東芝 デジタルイノベーションテクノロジーセンター 戦略室 戦略推進部＜共同執筆者＞
氏名(ふりがな)： 夏目 珠規子（なつめ みきこ）
所属： 株式会社東芝 デジタルイノベーションテクノロジーセンター 戦略室 戦略推進部＜主張したい点＞
アジャイル開発を適用する組織において、ウォータフォール型の従来の開発スタイルが前提となっている品質保証活動から、アジャイル開発に適した品質保証活動へと、段階的にギャップを解消しながら移行する「アジャイル開発における品質保証移行モデル」を開発した。社内のアジャイル開発適用部門でモデルを適用し、現状の状態から無理なく改善を開始し、アジャイル開発においても品質保証ができる状態へと移行することができた。
＜キーワード＞アジャイル開発、品質保証、アジャイル開発における品質保証移行モデル、SEPG、SQAG＜想定する聴衆＞
アジャイル開発の推進者、アジャイル開発の品質保証に悩んでいる方、SEPG、SQAG＜活動時期＞
2019 年 4 月〜2022 年 4 月（現在も活動中）＜活動状況＞：発表内容に複数の事例が含まれる場合は複数選択可能です。
□ 着想の段階(アイデア・構想の発表)□改善活動を実施したが、結果はまだ明確ではない段階☑ 改善活動の結果が明確になっている段階□ その他()

102

＜発表内容＞
1.背景
東芝では SPI の活動を開発部門 SEPG／カンパニーSEPG／コーポレート SEPG の 3 階層 SEPG 体制で実施している。筆者らは、コーポレート SEPG として、コーポレートとしての SPI 推進施策の策定、SPI に関連する研究、教育実施、
開発部門／カンパニーSEPG の支援を担ってきた。
2020 年より、東芝グループは、”インフラサービスカンパニーを目指し、Cyber Physical System（CPS）テクノロジ
ーにより、新たな価値を提供し、社会課題を解決する”ことを経営方針として掲げている。この方針の実現のために、筆者
らはコーポレート SEPG として、アジャイル開発・サービス・OSS・AI などの「ソフトウェアの新潮流に対応した SPI 活動」を推進し取り組んでいる[1]。
その 1 つである「アジャイル開発」に関して、東芝グループでは 2013 年より取り組みを行っており[2]〜[10]、筆者らは、東芝グループにおけるアジャイル開発の普及展開、開発部門へのアジャイル開発導入支援を行ってきた。人々の生活を支えるインフラサービスの開発へアジャイル開発を適用する際は、顧客ニーズの変化や技術の進化に柔軟に対応することに加えて、高い品質を担保することが求められ、柔軟性と高品質の両立が必要である。本発表では、アジャイル開発における品質保証活動の取り組みを紹介する。
2.改善したいこと弊社内では、アジャイル開発の検討や適用を進める開発部門が増えつつある。筆者らアジャイル開発推進メンバへ、開発部門からは、「品質保証メンバにどう関わってもらえば良いかわからない。ウォータフォール開発のままの関わり方であれば、開発の邪魔になる可能性がある。」、アジャイル開発の導入を検討している部門や SQAG からは「アジャイル開発を適用して開発された製品・サービスをどのように、品質保証すればよいのかわからない。」といった問合せが増えている。弊社の製品・サービス開発に適したアジャイル開発における品質保証活動の枠組みの整備が喫緊の課題となっていた。
「アジャイル開発で開発された製品・サービスの品質保証に必要な活動は何か？」、また、「開発に対し品質保証メンバがどのように関わればよいか」を示し、各開発部門がアジャイル開発における品質保証の仕組みを構築できるようにする必要があった。
3.改善策を導き出した経緯
アジャイル開発に適した品質保証活動では、開発組織、品質保証組織といった組織間にある障壁を解体して、関係者全員で品質を作りこみ、また、自動化技術の採用や、継続的な品質の可視化により、品質を継続的に作りこむことが望ましいとされている[11]-[12]。
しかし、弊社の製品・サービス開発の品質保証活動や体制には、以下に示す３つの状況があり、弊社におけるアジャイ
ル開発に適した品質保証活動の枠組みを 1 つの理想形として示すことが難しかった。
⚫

状況１：長年かけて構築されてきた品質マネジメントシステム(QMS)は、従来の開発スタイルを前提となっており、
アジャイル開発に適したものとのギャップが大きい。従来の開発スタイルを前提とした多くのノウハウもあり、急に大きく変えることは難しい。

⚫

状況２：アジャイル開発の導入時点では、組織は、従来のウォータフォール型の開発スタイルに合わせた品質保証プロセスが定義され、それに合わせた体制・スキルとなっている。また、組織内では、従来の開発スタイルによる開発が主流の中であり、アジャイル開発に適したスキルを持った品質保証メンバのリソースが不足している。

⚫

状況３：弊社は、多くの製品・サービスを扱っており、求められる品質のレベルも製品・サービスの特徴によって様々であり、品質保証組織の関わり方も、試験中心、プロセス確認中心、第三者試験中心など、様々である。

103そこで、アジャイル開発と現行の品質保証活動とのギャップを段階的に解消する抽象モデルとして、「アジャイル開発における品質保証移行モデル」を開発した。段階的に移行するモデルとすることで、上に挙げた３つの状況の中でも、以下の狙いのように、アジャイル開発に対応した品質保証活動へ段階的に改善を進められると考えた。
⚫

狙い１：製品・サービスの特徴や現状の品質保証の状態から、適切な段階を選択できる。次に目指すべき状態を明確にして、アジャイル開発における品質保証活動の改善を進められる。

⚫

狙い 2：いきなり理想的な状態を目指すのではなく、段階的な活動とすることで、無理なく改善を開始しやすくな
り、アジャイル開発に適した品質保証活動へとスムーズに移行を進めることができる。

4.改善策の内容
アジャイル開発と現行の品質保証活動とのギャップを段階的に解消する抽象モデルとして、「アジャイル開発における品
質保証移行モデル(以降、品質保証移行モデル)」を開発した。品質保証移行モデルは、ホップ、ステップ、ジャンプの 3 つのステージと、各ステージの目指す状態、目指す状態を達成するために必要な活動を定義した。各ステージの目指す状態と必要な活動を表 6 に示す。必要な活動の実施により目指す状態を達成すれば、よりアジャイル開発に望ましい品質保証活動を行えるよう次のステージに進んでいく。
表 6：アジャイル開発における品質保証移行モデルの３つのステージ
ステージ

目指す状態

必要な活動

ホップ

アジャイル開発の活動を従来

従来の仕組みをベースとして、アジャイル開発の活動の開発の活動に変換して理が従来のどの活動にあたるか解釈をする。今までの規解する

程・仕組みを大きくは変えず、従来の活動にアジャイル
開発を対応づけるステップ

アジャイル開発の特徴を活か節目だけでなくスプリント内での品質保証活動を取りした仕組みにする

込んでいき、スプリント毎にもある程度の品質確保をできるようにする

ジャンプ

常時、品質を見える化し、改スプリント進行中にも常に品質を見える化し、維持し善の加速を促す

続けられるような活動を取り込む

また、主要な品質保証活動に対して、アジャイル開発の場合に必要な実施内容、品質保証メンバの関わり方を整理し、また、社内外のアジャイル開発での品質保証活動のノウハウ収集を行った。これらを品質保証移行モデルと併せて、「アジャイル開発における品質保証ガイド」としてまとめ、品質保証活動の改善を検討する際に、具体的な活動内容を参照できるようにした。主要な品質保証活動に対するステップステージでの実施内容の例を表 7 に示す。
表 7：主要な品質保証活動に対するステップステージでの実施内容の例
主要な品質保証活動

実施内容の例

品質計画・品質計画判定• 作成ドキュメント・作業の特定、レビュー計画、試験戦略、試験計画の立案といった作業の必要性は変わらない• Done の定義を決める• スプリント毎に品質計画の見直しをする

節目管理
7• 次のフェーズ(方向づけ、構築、移行)に進む時には実施する 7。

Disciplined Agile Delivery (DAD：アジャイル開発を対象にしたプロセス定義フレームワーク)で示されているフェー
104

期間が長い場合は、妥当なタイミングで設定する(スプリントレビューとは別に実施する)
試験• スプリント内でプロダクトバックログ項目ごとに試験を実施して、記録を残す• 品質保証メンバは、品質保証の立場から試験設計についてサポートする

測定と分析による品質確認•PJ 内の過去のスプリントのメトリクスの結果を活用し、品質の妥当性の判断や、スプリント毎のトレンドを見る

・・・

・・・

5.改善策の実現方法
弊社内に品質保証移行モデル、アジャイル開発における品質保証ガイドを公開し、アジャイル開発の適用を検討する開発部門が参照できるようにした。また、筆者らがアジャイル開発適用の支援する際もモデル、ガイドを参照し、各部門の状況に応じて段階的な改善をサポートしている。ここでは、部門 A と部門 B へ適用した２つ事例について紹介する。
5-1. 部門 A におけるホップステージでの改善事例：現状の仕組みの中でアジャイル品質保証体系を実現
部門 A は、組み込み機器で、また、セキュリティ等の規格の遵守が求められる製品の開発を行っている。ハードウェアのリ
ソースの制約や規格の遵守といったシビアな制約の元での性能要求の達成を求められる。技術的に不確実性が高く、テスト＆ラーンを繰り返しながら開発を進める必要があるため、2016 年度よりアジャイル開発を適用している。研究開発プロジ
ェクトから適用が進められ、開発工数削減等の効果が確認できたため、その後、製品開発プロジェクトにおいても、アジャイ
ルを適用することとなり、品質保証体系についても検討が進められた。アジャイル開発では、品質保証メンバを含め、開発に必要なメンバが１つのチームとして働く形を理想としているが、従来の開発においては、設計開発部門と品質保証部門が分担しながら品質を保証しており、品質保証部門は、特にプロセス通り開発が行われているかを確認するプロセス品質について責任を持ち、工程移行の節目のタイミングで直接的に関与していた。品質保証活動をアジャイル開発に対応していくため大きな課題は、品質保証メンバがアジャイル開発におけるプロセス監査を行う上での知識不足と、組織にアジャイ
ル開発用のプロセスがなく、従来規程とのギャップが大きいという 2 点であった。そこで、品質保証移行モデルを参照し、ホップステージから活動を開始し、4 つの施策を実施した。
⚫

施策 1：品質保証メンバへの教育を実施

アジャイル開発の考え方、手法やプラクティスについての知識を設計開発メンバと共有するため、品質保証メンバにも設計
開発メンバと同等のアジャイル開発の教育を受講してもらった。
⚫

施策 2：アジャイル開発用プロセスを定義

組織の規程や従来の開発プロセスをベースに、節目レビューのタイミング、作成する成果物を明確にしたアジャイル開発用のプロセスを定義し、組織として開発の進め方を定義した。
⚫

施策３：アジャイル開発用プロセスチェックリストを作成

プロセス品質を確認するための確認ポイントをチェックリストとしてまとめ、プロセス監査を実行できるようにした⚫

施策４：アジャイルメトリクスガイドを作成

節目レビューで品質や進捗を確認するために活用するメトリクスを整理した。メトリクスの解釈の仕方についてもガイダンスし、データに基づき、品質確認が行えるようにした。

ズを前提としている。
105

5-2. 部門 B におけるステップステージでの改善事例：品質保証メンバのスクラムへの参加
部門 B では、小売り事業に対するシステムの開発を行っており、新しい機能を顧客に提供していくため、開発の初期段
階で必ずしも要求仕様が明確でないといった特徴を持つ。また、ビジネス目標として、市場占有のために「上市時期の早期化が求められており、常に要求の優先順位を明確化し、短期間でリリース可能な動くものを作る」、「動くものを見ながら、顧客の不明確な要求の明確化や新たな価値を引き出す」必要があり、アジャイル開発の適用が検討されてきた。
検討開始時には、アジャイル開発適用 WG を立上げ、設計開発メンバと品質保証メンバが協力して、まずは開発・品
質保証のプロセスを構築し、品質保証移行モデルのホップステージにあたる活動を行った。アジャイル開発用の規程が整備されたことで、設計開発メンバが中心となってアジャイル開発を実践し始めたが、「計画した作業をスプリント中に完了できな
い」、「次のスプリントの準備が不十分になる」、「受け入れテストで不具合が多発する」といった状況が生じ、、開発を軌道に乗せることが難しかった。
そこで、品質保証移行モデルのステップステージの活動として、品質保証メンバがスプリント中も第 3 者視点で進捗や品質の確認をサポートできる体制を構築し、実践した。具体的な活動としては、品質保証メンバがスプリント中にタスクデータの分析を行い、進捗状況を可視化、未了タスクの規模感や想定外タスクの発生状況などを定期的に共有し、関係者でスプリント中に対応策を検討した。
6.改善による変化や効果
6-1. 部門 A 事例における改善による変化
アジャイル開発の教育を品質保証メンバが受講したことで、アジャイル開発の考え方や用語を理解した上で、アジャイル
開発適用プロジェクトに関わり、設計開発メンバとコミュニケーションが取れるようになった。また、プロセスの整備やチェックリス
ト、メトリクスガイドにより、従来から品質保証メンバが担っているプロセス監査を実施でき、アジャイル開発においても、従来と同等の品質保証活動が行えるようになった。
また、教育の受講や、アジャイル開発を適用した実開発に品質保証メンバが関わったことにより、アジャイル開発の利点や意義について理解が進み、現在行っている部門 A 内の他製品へのアジャイル開発の適用検討でも、品質保証メンバが積極的に参加している。適用検討では、アジャイル開発の利点を活かした開発・品質保証プロセスが検討され、ステップス
テージの検討に進んでいる。
6-2. 部門 B 事例における改善による変化
品質保証メンバによる客観的な分析が開発に加わることで、リスクや課題の早期発見につなげることができた。その結果、計画した作業をスプリントごとに完了させる意識の高まりへとつげることができた。
アジャイル開発における品質保証活動では節目での確認よりも、より早期に品質に関するフィードバックを開発へする必要があり、品質保証活動自体もスプリントの中で開発と同期を取っていく必要がある。ホップステージから、ステップステージの活動を取りいれたことにより、単純に時間を区切って繰り返す開発から、スプリント毎にプロセス品質やプロダクト品質を確認し、品質を確保していく開発スタイルを目指し改善を進めることができた。
7.改善活動の妥当性確認
品質保証移行モデル、アジャイル開発における品質保証ガイドを参照することで、部門 A では、アジャイル開発に望ましい形と現行のプロセスや体制、スキルに大きなギャップがある状態（ホップステージ）から、無理なく改善を開始し、アジャイ
ル開発においても品質保証活動を実施できるようになった。また、部門 B では、ホップからステップの次ステージへと、段階的に品質保証活動を移行していくことが可能だと確認できた。
品質保証移行モデル、アジャイル開発における品質保証ガイドによって、「2.改善したいこと」で述べた「アジャイル開発で開発された製品・サービスの品質保証に必要な活動」、「品質保証メンバの関わり方」を示し、「3.改善策を導き出した経106

緯」の狙いで述べたように、製品・サービスの特徴や現状の品質保証の状態に合わせて適切な段階を選択し、現状の状態から無理なく改善を開始し、アジャイル開発に適した品質保証活動へとスムーズに移行できることが、事例から確認できた。

R. 参考情報[1] 田中武志, 白井保隆, 田村朱麗, 艸薙匠. “東芝グループにおける SPI 活動 20 年史と今後の展望について〜トップダウンとボトムアップを両輪としたアプローチ〜”, SPI Japan 2021, 2021.10.
http://www.jaspic.org/event/2021/SPIJapan/TimeTable/general_session/session2A/2A3_ID00
2.pdf[2] 石井裕志, 丸屋宏ニ, 羽原寿和, 鷲崎弘宣. “プロジェクト特性を基にしたアジャイル開発適合性評価手法”,
第 187 回ソフトウェア工学研究発表会, 2015.03.
[3] 新井和洋, 石井裕志. “品質保証部門とアジャイル開発推進部門が一緒に歩んだアジャイル開発導入 〜DAD
ベースのアジャイル版開発プロセスの構築、実践と課題〜”, Agile Japan 2016, 2016.05.
https://2016.agilejapan.jp/image/C-3_HiroshiIshii_AgileJapan2016_2.pdf[4] 伊藤裕子. “アジャイル推進活動をアジャイルにやってみた 〜SPI 活動もアジャイルに〜”, SPI Japan 2017,2017.10.
http://www.jaspic.org/event/2017/SPIJapan/session1B/1B4_ID029.pdf[5] 石井裕志. “行動変容ステージモデルに基づく「見える化」「ふりかえり」の実践と定着 プロジェクトファシリテーション導入 1 年間の軌跡”, SPI Japan 2018, 2018.10.
http://www.jaspic.org/event/2018/SPIJapan/session2A/2A2_ID031.pdf[6] 大森麻理. "共創で価値の最大化を目指す、アジャイル開発プロセス, DiDiTAL T-SOUL Vol.28 (東芝デジタル
ソリューションズ株式会社), 2019.02.
https://www.global.toshiba/jp/company/digitalsolution/articles/tsoul/28/004.html[7] "アジャイル開発における品質保証手法", 東芝レビュー 75 巻 2 号 特集：2019 年の技術成果, 2020.03.
https://www.global.toshiba/jp/technology/corporate/review/2020/02.html[8] 宮田真紀子, 大森麻理. "迅速かつ継続的な改善を実現するアジャイル開発及び DevOps のプロセス標準化とVPP プロジェクトへの適用", 東芝レビューVol75 No.5, 2020.09.
https://www.global.toshiba/content/dam/toshiba/migration/corp/techReviewAssets/tech/revie
w/2020/05/75_05pdf/a05.pdf[9] 田中武志, 夏目珠規子, 石井裕志. “SQAG 進化チャートを用いた品質保証活動の実践〜SW 品質保証 Gr
立上げ、アジャイル開発品質保証導入を例に〜”, SQiP シンポジウム 2020, 2020.09.
https://www.juse.jp/sqip/symposium/archive/2020/day1/files/A1-4_ronbun.pdf[10] 梶田環嗣. "IT エンジニアが経験を通して感じたアジャイル開発成功のポイント", 特集記事 コラム(東芝デジタル
エンジニアリング株式会社), 2021.
https://www.toshiba-tden.co.jp/focuson/clms-agile-1/index_j.htm[11] Joseph W. Yoder,Rebecca Wirfs-Brock,Ademar Aguiar "AQ to AQ Patterns about transitioning
from Quality Assurance to Agile Quality", AsianPLoP 2014[12]パターン QA to AQ による Agile Quality（アジャイル品質）への変革と事例. VERISERVE Technical
Infomation
https://www.veriserve.co.jp/asset/approach/column/agile/agile02.html
107