事例研究（公募）

稲崎 弘次

【概要】

本報告では、弊社の各部署で実践している生産革新活動(名称：２ｘ４活動)の中のベストプラクティスを「２×４Ｗｉｓｄｏｍ：効率化技法集」として、資産化(集約と汎化)しているので、その「集め方」、「作り方」、現場への「展開の仕方」、「効果の現状」について報告する。

＜狙い＞
通常、改善活動や生産革新活動では、その成果を事例報告や論文発表という形にして一段落、というのが一般的であるが、２×４Ｗｉｓｄｏｍでは、これらの活動を更に「技法」のレベルまで「まとめ上げ（編集）」、活用促進を図ることにより「効果の拡大」を狙うものである。

＜活動のポイント＞
１）巧く実践し、効果のあった活動の「発掘と編集」
２）その横展開のための演習を含めた「講習会」の実施
３）現場の「事後フォロー」

＜詳細＞
(1)集め方
現場で巧く実践している「活動の発掘」
（活動の定期的なフォロー、実践会、指導会、事例発表等を通して）
(2)作り方
その活動を他者が活かすことが出来るように「エッセンスを抽出・擬縮」し、
２×４Ｗｉｓｄｏｍとして体系化
「要領（概要）」
・ポイントとなる、手段と効果
・外せない点
・巧く実践するための「コツ」
・嬉しい点
「手順（本体）」
・Ｐｒｅｐａｒｅ（準備）
・Ｅｘｅｃｕｔｅ（実行）
・Ｃｈｅｃｋ（点検）
・Ｉｍｐｒｏｖｅ（改善）
・Ａｄｖｉｃｅ（助言）
(3)展開の仕方
それを「配布」（小冊子、ＰＤＦ）
演習を含めた「２×４Ｗｉｓｄｏｍの講習会」を開催（５拠点）
各部署の活動のフォローの場で「状況を把握し、指導」

稲崎　弘次（いなざき　こうじ）

ＮＥＣシステムテクノロジー株式会社　プラットフォーム事業本部
ソフトウエアエンジニアリングセンター　マネージャ

1984年　関西日本電気ソフトウエア株式会社
（2001年からＮＥＣシステムテクノロジー株式会社）入社
ソリューション系ソフトウエア開発に従事。

2004年　ソフトウエアエンジニアリングセンターに移籍。生産革新活動の推進業務に従事。

【概要】

デンソークリエイトでは、2006年より「トレーニング指向アプローチによるプロセス改善」に取り組んできた。「仕事の質のモデル化」は、その中核となる仕組みの１つである（SPES2007発表内容）。本稿では、この仕組みの適用事例として「「五月雨式な」大規模組み込みソフトウェア開発」を取り上げ、メトリクスを活用した品質向上事例について発表する。
(1)背景
組み込みソフトウェア開発の多くは「すり合わせ開発」であり、仕様が曖昧・未定のまま開発が進み、終盤に仕様変更が多発することが多い。また、試作という名の下で、途中段階では、しっかりとした評価が行われることは少なく、品質問題を抱えながら納期に追われることになりやすい。さらに、組み込みソフトウェア開発の大規模化・短納期化が進むにつれ、この状況はますます顕著となり、十分な評価ができないため、ソフトウェアの信頼性も確保できないまま市場に送り出され、品質問題が発生している。多くの組織では、この状況を解決すべく「作り込み工程重視」を方針にかかげ、レビュー・単体テストを強化したり、品質管理指標（メトリクス）による管理手法に取り組んでいる。しかしながら、トップダウンで収集した品質データや設定されたメトリクスでは、現場の状況にそぐわず使われない場合が多く、形式的・表面的な活動に陥る危険性が高い。
(2)当社の課題
当社でも、長年、品質データを収集・蓄積してきたが、開発現場ではうまく活用できない状況に陥っていた。特に、組み込みソフトウェアの大規模化・短納期化に伴い、五月雨式な部品の変更開発（五月雨式に発生する要求に対し部品の変更を繰り返すという開発スタイル）を強いられるようになり、開発全体が「小規模アイテム開発の大集合」となったことで、より「使えない」状況が大きな問題となってきた。これは、小さなアイテム単位では、品質データのバラツキが大きくメトリクスをうまく使えないからである（100倍以上の差が生じる）。
(3)トレーニング指向アプローチによる課題解決方式
この問題に対し、我々は「トレーニング指向アプローチ」を取り入れることで、メトリクスを使い、作り込み工程の品質を向上させることを考えた。トレーニング指向アプローチは、開発メンバーのひとり一人が「自ら考える業務スタイル」となることを支援することで、人の持つ能力を引き出し・引き上げていく方式である。品質データに振り回されることなく、メトリクスを活用することを考えていくアプローチであり、結果として品質データの質も高まっていく。
(4)適用事例
全開発アイテム（460アイテム）に対しトレーニング指向アプローチを適用した。
（総規模：約1000人月）
前プロジェクトと比較し流出不具合を約1/8に削減でき、また、手戻り工数も徐々に削減され、実効を体感できている。

 

石田 光明

【概要】

・｢品質経営｣宣言の下、ＳＷ-ＣＭＭモデルによるプロセス改善に着手した。
・組織の品質活動とプロジェクト（工事）の品質活動の仕組みを構築するとともに、品質指標の標準化に取組んで来た。
・これら３年に渡る活動から、品質指標値の計測精度が上がり信頼性が向上したこと、分散が減少してきていることからプロセス改善が定着して来た。
・今後は、より木目細かな目標設定のために、ビジネス分野毎の特徴を把握し、ビジネス分野個別の指標値を策定するなどの改善を図りたい。

・1981年　入社
　鎌倉分室（現鎌倉事業部）にて、主に官公庁向け組込みS/Wの開発に従事
・2002年　本社管理部門
　主に、技術管理、生産管理業務に従事
・2005年　関西事業部
　主に、品質保証、生産管理業務に従事

黒木 正美

【概要】

弊社ソリューション事業本部では、従来よりＣＭＭをベースとしたＳＰＩ活動を推進してきており、２００７年度からはＣＭＭＩをベースとしたＳＰＩ活動に切り替えようと進めていた。
また、２００６年度からは生産革新としてボトムアップによる小集団活動も強力に推進してきており、ラインからみれば非常に分かりにくくなっていた。
そこで、目的を同じくする２つの活動を融合した新たな活動モデルとして「ＧＡＩＡモデル」を定義し、このモデルに沿った形式で推進することにより、成果の「見える化」にも繋がり効果が得られた。

１．融合化に到った経緯
小集団活動は、現場の小さな活動単位（チーム）から改善を始める。
一方、ＳＰＩ活動は組織側から改善のアプローチを行なうため出発点は異なっている。しかしながら、目指す方向は《現場力を向上し、その流れをまとめてより強いものにしていく》ことであり、成長に伴い流れは一つになると考えられる。そこで、両方を融合したモデルを考えることとなった。

２．ＧＡＩＡモデルの概要
ＧＡＩＡモデルは、現場力の成長度とＣＭＭＩの概念（成熟度レベル）を融合し、現場力の成長度を、改善を始めた段階から改善がＤＮＡになるまでの４つのステージで表したものである。
各現場では、このＧＡＩＡモデルによって現場力を測り、自律的に把握した問題をトリガーに改善活動のＰＤＣＡサイクルを回し、成長し続けることを目指している。

なお、ＧＡＩＡモデルは活動レベルを地球の生物の進化になぞらえ、以下のように定義した。

１９８０年関西日本電気ソフトウェア（現ＮＥＣシステムテクノロジー）入社。
以降、主に金融系のＳＥとしてシステム開発業務やプロジェクトマネジメント業務を担当。
また、アウトソーシング子会社の立ち上げ等にも携わる。
２００６年以降、現在の部署にてプロジェクトマネジメント力強化施策の推進、
生産革新活動の推進、ＩＳＯ等品質マネジメントシステムの推進、等に従事。

堀口 誠

【概要】

組み込みソフト開発のスタイルは事業領域毎に異なっています。一方で『お客様からそのソフト開発の品質状況が見えるようになっているか？』ということが共通の課題であり、出荷製品品質の妥当性確認の上からも重要です。ツールを活用し『品質の見える化』に取り組んでいますが、事業領域によってはまだまだ改善の余地がある状況です。
今回、対象とした医用部門は、お客様と密接な関係の中で、医用機器組み込み用ソフトを開発するスタイルが２０年以上継続されているため、体制・環境等含めメリットも多々ありますが、その反面、開発要員のローテーションも部門内に留まり、ほぼ固定化している現実があります。
従来の品質改善への取り組みに疑問を持ち、お客様のＶＯＣを直接ヒアリングしてみようという着想を取り入れて改善に繋げました。その結果、『顧客満足のための意識改革』という成果を挙げることができました。
当社エンベデッドグループの顧客満足への取り組みの紹介と、医用部門の品質向上に向けた活動について事例報告します。

１９８０年に東芝情報システム株式会社入社。ＦＡＸ、ＰＢＸ、ＰＨＳ等の組込みソフト開発に従事。
２０００年に事業部品質管理門に配属となり、現在に至る。
事業部の品質マネジメントシステム活動を推進する立場となり、開発部門と連携して品質改善に取り組んでいる。

桜庭 恒一郎

【概要】

ソフトウェア生産性は，ソフトウェア開発プロジェクトにおける定量的管理指標の一つとして使用されている．ソフトウェア生産性は，生産性向上施策の評価や新規プロジェクトの見積り・計画策定の際に用いられるが，基礎尺度である規模や工数の精度のほか，開発環境やメンバーのスキルなど様々な要因によって影響を受ける．このため，プロジェクトごとにソフトウェア生産性のばらつきが大きく，その実績数値を評価・活用する場合には留意すべき点が多い．
本発表では，当社におけるソフトウェア生産性指標の具体的な評価・分析および活用事例を報告する．

・1978年 入社　制御用計算機のオペレーティングシステム開発に従事。
・2004年より、CMMIを適用したプロセス改善活動に従事。(2006年2月にレベル5達成)
・現在、全社共通部門である生産技術部に所属し、ソフトウェアプロセス改善活動を社内で展開するとともに、社外向けのソフトウェア開発プロセス改善コンサルティングにも従事。

日改 徳雄

【概要】

弊社では、プロジェクト品質の向上を目指し、組織的リスクマネジメントの導入を行った。その導入に到る背景と、リスクマネジメント活動の内容や仕組みを紹介する。また、導入効果について考察する。

組織的リスクマネジメント導入の背景
近年のシステム構築プロジェクトは、システムの高度化・複雑化が進み、顧客からの短納期要求が高まっている。プロジェクトはリスクを抱えた状態で進行することになり、リスクへの対応を間違えるとプロジェクトは失敗する。弊社でも、プロジェクト危機に際してお客様から戴いたご意見が契機となり、プロジェクトで発生するリスクを組織的に管理するための部署（プロジェクト推進グループ）を発足させ、プロジェクト品質の向上へ取り組んだ。

組織的リスクマネジメントの概要
プロジェクト推進グループでは、リスクマネジメントプロセスを定義した。また、全社で共通のリスク分析ができるように、リスク管理指標を整備した。
活動の中では、リスク対応策の実施が最も重要であり、難しい。リスクが認識されても、プロジェクトマネジャーが問題を抱え込んでしまう等、対応策の実施遅れは致命的である。組織として確実に対応策が実施されるよう、プロジェクト責任者や上位マネジメントも含めてリスク状況を共有する必要がある。そのために立ち上げた社内のリスクポータルサイトを紹介する。

導入効果の考察
組織的リスクマネジメントを導入した効果について考察する。ひとつには、多くのプロジェクトにおいてリスクへの取り組み姿勢が変わったことがあげられる。また、リスクのあるプロジェクト数の減少、赤字プロジェクト減少による事業部門収益への貢献について考察する。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上

業務アプリケーションの受託開発に従事したのち、技術本部
アプリケーションソリューションセンター（現NSIセンター）にて、
プロジェクト推進グループの立ち上げに参画。現在も同グループで、
受託開発プロジェクトを支援する業務に従事。PMP。

船原 慎大郎

【概要】

経験の少ない大規模工事で、出荷後の不具合発生に苦慮した経験を基に、プロセス改善を実施した事例を紹介する。
緊急で実施した集中コードレビューの結果から、次の問題点を洗い出した。
・コードが見づらい。制御構造が深い、長い
・行数が多い。同じ表現の繰り返しがある
対策として静的解析ツールを導入して、コードを定量的に評価したうえで、コードレビューに活用することにより、コード品質を向上することができた。
静的解析の導入にあたっては、キーマンを指名して体制を明確にすることを手始めに、階層ごとの教育の実施やコードレビューのルール作りを実施した。
結果として、メンバが成功体験を得たことが大きな要因と考えるが、その後の活動が維持・継続されている。

１９８７年三菱スペース・ソフトウエア株式会社入社。
宇宙分野でのシステムエンジニアを経て、２００４年より当職。
品質保証活動、現場改善活動に従事。

八尋美徳

【概要】

ＮＥＣソフトウェア九州では、全員参加で生産革新活動を進めています。
特にボトムアップ活動の推進に力を入れており、現場改善の流れをいかに作っていくかという課題に対して、以下のような会社としての取組を行なっています。
(1)現場改善活動プロセス成熟度を見える化した、現場改善レベルピラミッドを活用して推進。
(2)トップダウンの標準化でなく、現場で改善された物を、Ｐ＆Ｐ（プロセス＆プラクティス）として残していく活動。

また、各現場ではさまざまなアイデアで現場改善を進めており、代表的な事例を紹介。
(1)Ｐ＆Ｐ（プロセス＆プラクティス）を、アナログの見える化とデジタルの仕組みを組み合わせて改善。
(2)プロジェクトの全体進捗と、個人の相関が一目で分かる見える化として「パッと図」を考案し、ＰＪメンバーのベクトル合わせに活用。

１９８５年　熊本大学卒業後、ＮＥＣソフトウェア九州入社。
以後、オープンシステム、Ｗｅｂ系開発に従事。
２００３年〜　事業企画部　グループマネージャー
２００６年〜　生産革新推進室　室長

日野 祥幸

【概要】

■システム運用総点検の背景について
トラブルが続き、お客様の信用を失いつつある中、さらに重大なトラブルが発生してしまった事により、お客様の信用を失墜させプロジェクト自体の信用も無くしてしまいCS（顧客満足度）を低下させてしまった。
トラブルの原因は、システム運用の仕組みの関係で手作業とデータ量が多く長時間労働になってしまう事と、これ以上ミス・トラブルを起こせないというプレッシャーが作業者を疲弊させていた為、ES（従業員満足度）が低下しミス・トラブルに繋がってしまった。そして、抜本的な改善が必要と考え、システム運用総点検の実施が決定した。
　
■本プロジェクトについて
口座振替収納代行業務を行っている。作業内容は、(1)各種マスターメンテナンス、(2)請求明細、(3)請求データの受付、(4)請求処理、(5)結果処理、(6)請求データ発送、(7)結果データの到着、(8)結果データの発送、(9)個別作業
以上の９作業をSE３人、オペレータ５人の少人数で業務を行っている。
　
■システム運用総点検の流れ
マトリクス図を元に９項目の作業内容を細分化し25の工程に分割した。さらにマトリクス図より『作業洩れ』、『作業ミス』から改善ポイントを抽出した。次に工程毎に４つの観点から誘発されるミス・トラブルの想定や過去に発生したミス・トラブルから点検・分析をして改善策を検討した。

■改善前と改善後の比較
総点検前と総点検後のミス・トラブル件数を比較すると、年々効果が現れミス・トラブル件数が減少している。さらにシステム運用総点検後は見える化が実現し、安定した運用が可能となった。その結果、作業者の負担の軽減やプライベートの時間が増え、時間のゆとりと心のゆとりができた。そのため、顧客へ対応にもゆとりがうまれCSの向上にも繋がった。
　
■今後の目標について
(1)システム運用総点検で得た運用のPDCAサイクルを継続する事による改善活動の実施。
→改善活動の継続により、ノーミス・ノートラブルを目標とした安定した運用を提供する。
(2)システム運用総点検のノウハウを他プロジェクトへ横展開による運用品質の向上。
→システム運用総点検の成功事例として、他プロジェクトへのノウハウなどを提供し、自社の品質向上に貢献する。

プロジェクトサブリーダー
２００５年度４月、株式会社富士通ワイエフシー入社

担当している作業は、メインフレームでのオペレーション、システム保守、運用管理等です。
今年度はプロジェクトメンバーから挙がった改善提案事項の管理、また改善する為の施策の検討等も行っております。
今後は当プロジェクトで実施したシステム総点検でのノウハウやポイント等を纏め、他プロジェクトへの展開を行う予定です。

【概要】

通信キャリアをマーケットとする当開発組織において、以下のような事業環境の変化によって、事業拠点が首都圏にシフトし、地方拠点が空洞化していた。
・主要マーケットの首都圏集中
・多様化する開発手法、開発技術
・ＰＪおよび拠点の増大・分散化
・増す社会的責任
・求められる役割の変化（ＳＥ、プログラマ→ＰＭ、ＡＰオーガナイザ、アーキテクト）
・長期にわたる転勤によるモチベーションの低下

そういう状況の中で、地域の活性化を目的として、分散開発の拡大・推進の取り組みを始めたが、プロジェクト毎に異なる開発手法、業務量の山谷問題、適材適所のアサインの困難さ、などによる稼働率低下、低生産性などの課題があった。

そこで、分散開発による、生産革新の推進、実践として、以下のような施策を行った。
・専門チームを核とした水平型開発モデルの全体最適による、パフォーマンス向上の実現
・海外連携による役割分担の明確化、生産性向上
・各種エンジニアリング施策、見える化の促進
その結果として、エンジニアリングの確立、見える化の促進により、業務量の平準化、トータルコストパフォーマンス向上、エンジニアリング共通化などで、一定の成果を得た。

1964年 愛媛県生まれ
1987年 法政大学法学部法律学科卒業後、四国日本電気ソフトウェア株式会社入社日本電気株式会社に事務従事し、通信キャリア業種のシステムエンジニアとして、経験を積む。四国日本電気ソフトウェア株式会社復帰後も、主に通信キャリア業種のＳＥ、プロジェクトマネージャーとして従事。
2005年 四国拠点の分散開発への取り組みを始め、以後、首都圏マーケットのＰＭを兼務しつつ、地域分散開発に携わっている

【概要】

ソフトウェア開発は、大規模化、複雑化の一途をたどっているが、短納期や高品質、低価格への要求は相変わらずであり、厳しい状況である。
こうした中で、プロセス改善を成功させるために、今まではトップダウン型のアプローチでプロセス改善を実施していたが、改善自体が現場に定着せず、形骸化してしまう傾向にあった。
そこで、Web2.0に基づいた相互コミュニケーションの時代においては、現場技術部門の智恵も活用することが必要との認識のもと、従来のトップダウン型アプローチだけでない、経営者層をはじめ、中間管理者層から現場部門の担当者層にいたるまでの全社員による全社的な取り組みが不可欠である、との考えのもと、新しいプロセス改善へのアプローチを試みた。
その取り組みのスタイルは、トップダウン型とボトムアップ型のアプローチの融合とでも言うべきものである。
本報告は、当社鎌倉事業部全体で取り組んでいるプロセス改善活動における、現場主導で行われているプロセス改善の取り組みの一端を紹介する。

鈴木 誠

【概要】

ソフトウェアテスト技法は、数多く存在しますが、どれ１つとして万能なものはありません。

また、テスト者（開発者）が、いくら高度なテスト技法を身に付けていても、必要な情報を把握していなかったら、テスト設計時に考慮されず、不具合は検出されずに残ってしまいます。
大規模なプロジェクトでは、ひとりの人間がシステムの仕様を隅から隅まで把握することは殆ど不可能と言えます。効率化を狙って作業分担することによって、情報の欠落が発生します。
当社では、開発者本人による単体テスト（デバッグ）、開発チーム内の第3者テスト、別組織のテストチームによる第3者テストという三段階のテストを実施しています。
そこで、開発チームのどこで情報の欠落が発生しているかが分かる仕組みを構築し、「見える化」を図れば、効率的に不具合を検出出来るのではないかとの仮説に至りました。
オフィスの壁に、システムの全体像、及び、機能間の繋がりを表すマップを作成し、機能毎の品質、及び、機能間の品質を赤、黄、青の３色で表現しました。
このマップにより、次の効果を得ることが出来ました。
【直接的な効果】
1.どの機能が不安定であるかが一目瞭然になった。（≒誰が作成した機能が不安定であるかが一目瞭然になった。）
2.どの機能と、どの機能の連結部が不安定であるかが一目瞭然になった。（≒誰と誰の間で、コミュニケーションが上手く取れていないかが、推測出来た。）
3.開発工程上の問題（ボトルネック）が、どこにあるのかが分かった。
【副次的な効果】
1.現在の品質と、満たさなければならない品質、そして、納期迄の期間を考慮することで、 実施しなければならいテスト、及び、その実現性が推測出来、危機感を共有出来た。
2.マップを眺めて、どの機能は危険、どういうテストが必要という議論が自発的に起こった。
3.仕様変更など大きな修正が入った時に、テストし直す必要のある機能が分かり易かった。
4.システム全体の品質を確保するために、どの機能をいつ迄に安定させる必要があるか、 テストを終了させる必要があるかという風に、納期から逆算したテスト工程を引き易かった。
5.開発チームに対して、優先的に修正して欲しい内容を伝える事が出来た。
6.システム全体を把握することを助け、途中参加者をより短期間で戦力化することが出来る。
7.機能間の繋がりと、誰と誰の間で、コミュニケーションが上手く取れていないかが明確になる為、高い確率で不具合が検出される所に、テスト者を計画的に配置することが出来た。（≒担当者の境目、開発チームの境目、責任範囲の境目を補う様に、配置する。）
8.ボトルネックが分かるので、1ヶ月、2ヶ月先を見越したリスク対策を打つ事が出来た。
9.信頼度成長曲線、機能毎の不具合件数分析と併用することで、テストマネジメント上、有用な情報を得ることが出来、多角的な視野で品質を判定出来る。

2000年 (株)ビーイング入社
入社以来、主にソフトウェアテストに従事

【概要】

東京電力およびテプコシステムズでは、平成１８年にシステム化に関わるさまざまな課題を解決すべくシステム化業務見直しＷＧを立ち上げた。その中の一つ中規模ＷＧでは、中規模レベル（総委託費４億円以下を想定，最大は１０億円）の開発において，開発工程の見直しおよび設計物のテンプレート化，サンプル利用によって費用削減や開発の早期化を目的に取り組んだ。主な施策は以下の２点である。
（１）手続きの省略可
・基本設計工程および入出力設計工程の統合
・重複・類似成果物の削減
・一部の技術審査，レビューの統合または省略化
（２）設計物のテンプレート化（ひな型化），サンプル成果物の適用
・Ｈ／ＷやＳ／Ｗの基本構成、運用引継などをひな型化することによる、システム方式や運用方式の設計工数の削減
これらの取り組み結果を、中規模ガイド（仮称）としてとりまとめ、平成１９年度に２つの開発プロジェクトへ試行した。本報告によって、試行結果（金額面での評価、工期面での評価）および試行中に実施した追加施策についてとりまとめた。

石山 典子

【概要】

　当社では、検査工程(※)の不良密度（開発規模当り不良摘出件数）に対して、統一の目標を設定している。２００６年以降、この目標に対する実績に隔たりが大きく表れてきた。
この要因を追求すると、開発プロジェクトにおいて、品質目標値の設定が曖昧、あるいは、品質目標値を設定しているがプロジェクトの特性が考慮されていないなど、品質目標値の管理に問題があることが判明した。
このため開発プロジェクトにおいて適切な品質目標値を設定するための参考値を明示し、品質目標値の管理が高い精度で実行されるよう、「品質目標値設定ガイドライン」を制定することで改善を図ることにした。
先ず、精度の高いガイドラインにするための品質データ精査（標準偏差，偏差値を求め、異常データを除外）を行い、次に、当社の事業形態毎のカテゴリについて検討した。また、開発プロジェクトにおいてより使いやすいガイドラインとなるよう、カテゴリ別の参考値の導き出し方について検討した。
本ガイドラインは、下記構成となっている。
１．実績から導きだした参考値<業種別，言語別>
２．品質目標値の実績（全体）<開発形態別，業種別，言語別>
３．業種別の品質目標値実績（詳細）<開発形態別，言語別，契約形態別>
４．言語別の品質目標値実績（詳細）<開発形態別>

「品質目標値設定ガイドライン」を制定することで、「テスト計画／管理の徹底」「プログラム品質の向上」「問題プロジェクトの未然防止」を図り、品質目標値設定の精度／効率の向上、及び、テストプロセスの改善を目指した。
「品質目標値設定ガイドライン」を制定は完了したが、今後、ガイドライン適用の効果検証を行うとともに、「より効果ある品質メトリクスの検討」「品質データ収集の精度向上」の観点からガイドラインの継続した見直しを行うことで、更なるテストプロセスの改善を目指していく。

※ 設計とは独立した品質保証部門にて検査を行い、合否判定をすること

1991年 日立システムエンジニアリング株式会社（現：（株）日立システムアンドサービス）入社。
品質保証部に配属後、主に公共系のパッケージシステム（財務会計，図書館システムetc）の検査担当に従事。
近年は、同部門内、品質マネジメントグループに所属し、社内品質の管理/向上に向けた施策の検討及び推進に従事している。

伊藤正弘

【概要】

これまで社内の各組織でCMMなどを使用して数多くのソフトウェアプロセス改善活動が行われてきたが、開発現場に広く根付かせることは難しかった。この反省に立って、2004年２つの技術グループの有志により、「SPI推進室」というバーチャル組織を核とした新しい形の改善活動がスタートした。活動は次第に対象組織を広げて拡大し、2007年度からPSS全社組織を対象とした活動となった。

「SPI推進室」では、活動目標を「全てのソフトウェア開発現場を、技術者にCMMIを意識させずにレベル３水準に高位平準化する」ことに置き、SEPG、SQAG、PMOのメンバーが三位一体連携して以下の７つの戦略で活動を行ってきた。
１．バーチャル推進組織の構築
２．CMMIモデルの徹底分析
３．管理標準・技術標準の策定
４．プロジェクト管理ツールの開発
５．組織トレーニングの実施
６．組織ルールとの連携
７．内部アセスメントの実施

活動成果として、2006年度に約半分のソフトウェア組織がCMMIレベル３水準に到達したことを、内部アセスメントと公式評定で確認した。現在は全組織のCMMIレベル３水準への到達と、先行組織での高成熟度水準(レベル４、５)のパイロット施行を目指して活動を進めている。
　本発表は「SPI推進室」で進められてきた７つの戦略について、その取り組み内容を報告する。

伊藤 正弘 （いとう まさひろ）
松下電器産業株式会社 パナソニック システムソリューションズ社　(PSS社：社内分社）
インフラシステムビジネスユニット 所属
1989年入社以来、自営無線システムや公共デジタル無線システムなどの社会・公共システム分野で、組込みシステムのソフトウエアプロジェクトリーダを担当
1998年よりCMMによるソフトウエアプロセス改善活動を担当プロジェクトに導入
2004年に技術部門のワーキンググループ活動として立ち上げたバーチャル組織「SPI推進室」を母体に組織的なプロセス改善活動を開始
現在はPSS全社のソフトウエアプロセス改善活動の推進リーダを担当