国際標準(ISO/IEC 15504)に適合したプロセスアセスメントモデルである「SPEAK」を開発・活用している立場から、プロセス改善を推進するためには、アセスメントモデルや教育など改善活動を支える基盤がどうあるべきかという視点から報告する。

1.SPEAKご紹介
・開発の背景
・対象とするプロセス
・主要なアウトプット
・アセッサの役割
2.SPEAK基盤整備とプロセス改善の歩み
・2002年のSPEAK開発から、現在に至るまでの歩みや課題について、
アセスメントモデル、教育、アセスメント、プロセス改善活動の４つの観点からご紹介
・プロセス改善の活動開始（2002〜2003年度）：
アセスメントモデル｢SPEAK｣の開発、アセッサの養成、適合アセスメントのスタート
・プロセス改善の活動展開（2004〜2005年度）：
アセスメントモデルの拡充、適合アセスメントの展開
・プロセス改善の活動拡大・質向上（2006〜2007年度）：
教育の再編成、現場主体のプロセス改善活動のスタート
・プロセス改善の支援強化（2008年度〜）：
全社方針としてプロセス改善活動を強化、アセスメントの定着化
3.教育とアセスメントの実績
・教育と適合/簡易アセスメントの実績、現在の教育体系、アセッサ能力の維持・向上について
4.プロセス改善の現状と今後の展望
・プロセス改善活動の推進状況と活動の成果、今後の展望について

キーワード：アセスメントモデル、アセッサ教育、プロセス改善教育、アセッサ制度


以上

当社では品質向上を目的に、CMMIモデルに添った開発プロセス改善活動を実施し、その結果、
2008年9月に開発主要3部門が同時期にCMMI成熟度レベル3を達成した。
通常、複数事業所でレベル3を達成する場合、1組織が先行して、他の組織がそれに追随するアプローチが一般的にとられ、全社展開までに時間がかかることが多い。当社のように同時期に達成することは難易度が高く、非常に稀であるといえる。

全社的にプロセス改善を進めることが出来たポイントは、過去の標準推進での失敗を生かし、以下の活動に注力をした結果だと考える。
・柔軟なテーラリング
・品質保証の強化
・トレーニングの徹底
上記の活動事例について報告する。

2005年、当社では組織能力の向上・PM力向上を目標とし、SPEAKをベースとしたSPI活動を開始した。
SPI活動の失敗事例、それを反省とした現在の活動事例を紹介し、現状の成果、今後の取組・課題について報告する。
１．SPI活動の歩み
（１）第1回SPI活動（2005.10〜2007.9）
第1回SPI活動は、NBOK室（開発技術部の前身）が主体となった。
3モデル部店からSPI委員を選定し活動を開始したが、次第にSPI委員のみの活動になっていった。
（２）第2回SPI活動（2007.10〜現在）
第2回SPI活動は、前回の反省点を踏まえ、各本部から選出されたSPI委員で構成するSPI-CFTが主体となった。SPI-CFTは活動方針の策定を担当、実際の活動は開発技術部が担当した。
SPI全社展開の開始を社長から全社員に向けて発信するというトップダウンアプローチと、全社員を対象にSPI説明会を実施するというボトムアップアプローチの両面から活動を再開した。　
２．アセスメントの実施とその成果
（１）アセスメント実施
SPEAK IPA版 第2部アセスメント手順書をもとに、アセスメント実施手順を策定。
2008年度下期には、現状能力の把握を目的とし、社内17PJを対象にアセスメントを実施、2009年度活動に向けて、改善計画への提言を行った。　
（２）成果
・作業実態、改善テーマの明確化
会社全体、本部・部単位、PJ単位の強み・弱み、改善テーマが明らかになった。
・参加者の意識の変化（アンケートから）
活動開始当初と比較して、SPIに肯定的・前向きな感想が多く聞かれた。
３．PJ管理ツールとの連携
当社PJ管理ツールに標準プロセス（標準手順書・テンプレート）を掲載している。
SPI活動を通して、この手順・テンプレートの活用を進めている。　
４．今後の取組みと課題
（１）今後の取組み
各部店にて、アセスメントで明らかになった課題・問題点に対して、改善計画を作成、活動を行う。2009年度下期、改善効果の定量的測定のため、再度、アセスメントを実施する。　　
（２）課題
・SPI活動結果を、スピーディに社内にフィードバックする仕組み作り。
・アセッサ育成の仕組み作り。

弊社では個々のプロジェクトの成功を目標とした全社活動としてPLM/SIA活動（Project Life-cycle Management/SI Assurance）を実施している。PLMは案件の発生からプロジェクトの立上げ・実行・終結まで全工程にわたってプロジェクトに関する事象の見える化を通してプロジェクトを成功に導くための活動であり、SIAはプロジェクトのリスク管理を中心に、案件審査・成果物の品質保証のための監査を行い、評価する活動である。
全社での運用は全社PM推進室が推進し、各事業部が個々の事業部にて運営する形になっている。
私の役割は事業部のマネージャーとして複数プロジェクトのマネジメントを行いながら、PLM/SIAの事業部担当としてプロジェクト監査等を行っている。

PLM/SIA活動は根付いてきており、成果も出ている。
しかし、PLM/SIA活動を行っていても、プロジェクトで問題が発生する場合がある。
プロジェクト期間の短縮などプロジェクト自体の難易度もあがってきており、なかなか問題が発現するまでの予兆を察知し、対応することが難しくなっている。
現在実施している全社のPLM/SIA活動＋αの活動が必要ではないかと考えている。

複数プロジェクトのマネジメントからの視点、また、現場リーダーの視点として、
問題発生の予兆をどのようにキャッチし、マネジメントしていくかという部分の改善をプロジェクト計画からの「変化・変更」という点に焦点をあて改善施策を事業部で行った。
リスクマネジメントの開始やチェックのポイントを分かりやすく簡易な形で進められるような改善施策を実施中ではあり、今後も＋αとなる評価・改善を進めていく予定である。

　客先常駐率８０％以上、複数部門の合併、東京大阪２拠点分散、このようにロケーションも、文化も、歴史も、バラバラなメンバが第一ブロードバンド事業部として同じ事業部員となった。お互いを知らず、対応プロジェクトも勤務場所もバラバラなメンバが３年にわたり、『勝つんや活動』と命名した活動を通じ、強く楽しく挑戦する個人と組織を実現し、現在ではＯｎｅＮＥＣ（*1）として「勝つんやマインド」を基点とした積極的な現場改善活動が定着するようになった。どのようにベクトルをあわせ、組織文化をつくりあげたかについて全体推進の工夫点を中心に、現場推進自体の推進や現場改善成果例も交えご紹介します。

＝第一ステップ＝　お互いを知る
第一ステップとして、まずはどういったメンバが同じ組織内にいるかを知る事を目的とし、『Ｋ−１グランプリ』という施策を実施した。これは所属プロジェクトも役職も勤務場所もバラバラなメンバを約１０名程度の小集団としてくくり、指定テーマを１年間議論し、成果を発表しＮｏ１を決定するというもの。互いを知る施策としては成功をおさめ、チーム編成やテーマはもっと自由に決めたいとの要求があがり、次年度の施策へとつなげた。
＝第二ステップ＝　基礎を固める
第二ステップとしては「強く楽しく挑戦する個人と組織」を文化として定着させる事を目的として『勝つんや２．０』という施策を実施した。これはチーム編成もテーマも自由とし、自発的な小集団で1年間活動し成果を発表するというもの。若手中心に楽しく活動する文化が定着し、交流を深めたことで組織としての一体感が出来た。楽しいだけでなく、成果を出していきたいとの要求があがり、次年度の施策へとつなげた。
＝第三ステップ＝　成果を出す
第三ステップとしては「強み（組織文化）を活かし、弱み（基礎力）を解消して結果を出す」事を目的とし『勝つんや３ｒｄ』という施策を実施した。成果に注力する現場小集団と文化醸成目的の自発小集団の２本立てとし、１年間活動して成果を発表するというもの。計測や改善活動が当たり前として定着するだけでなく、他社交流会や他事業部とのコラボ小集団などＯｎｅＮＥＣとしての輪も広がった。
以上、３ステップ施策はどれも着実な成果に結びついた。その成功要因は、全員参加にこだわり、若手中心の運営メンバで企画運営を実施し、全員アンケートで得た現場の声を基にして、次の施策につなげてＰＤＣＡをまわしていることと考える。
『勝つんや活動』で得られた「強く楽しく挑戦する文化」が醸成し、具体的な現場改善成果に結びつくために、更なる挑戦を続けたいと思う。

*1　ＯｎｅＮＥＣ：ＮＥＣグループ一丸に向けてのスローガン

高品質のシステムを効率的に開発するためには、上流工程の品質の向上がキーとなる。上流工程の成果物であるドキュメントは、図形表記法による記述と日本語自然文による記述に大別できる。前者は標準化が進み、解釈のずれが少ないのに対して、後者は解釈によって意味が大きく変わる危険性を内包する。富士通FIPシステム技術推進部では、日本語自然文による仕様書の課題を解決するため、入力支援ツールを作成した。本論文は、入力支援ツールによる設計書の品質向上への取組、成果、課題について説明する。
入力支援ツールの主機能は、定型文挿入機能と登録要素挿入機能の２つである。定型文挿入機能は、順次実行、条件分岐、反復の３つの論理構造とプロジェクト特有の構文を登録しておき、設計書に定型文を利用することで表現の統一を狙ったものである。登録要素挿入機能は事前に作成された情報を登録しておき、ドロップダウンリストから選択できるようにすることで、用語の転記ミスを防止することを意図している。
Ｈ道路プロジェクトにおいてこの二機能を適用した。生産性については、ツール使用のオーバーヘッドが大きく、課題を残す結果となった。品質については表現の統一、転記ミスの減少など想定通りの効果が表れた。また、想定外の品質向上効果も認められた。入力支援ツールは厳格に定義され、かつ誤りのないデータの登録を必要とする。それによって、ツールに登録するドキュメントに対して念入りにレビューが行われ、結果として登録ドキュメントの品質は高まった。
今後は、明らかとなったツールの課題を解決するとともに、設計ドキュメントの規約・標準・体系や能力開発の側面からもドキュメント品質の向上を進めていきたい。

弊社関連インドオフショア会社ICIL社（現ZenSar社）1999年に世界初の全社レベルCMMレベル5を取得、2004年にCMMIレベル5を取得した。これ以来オフショア開発品質管理はCMMIレベル5に基づき実施してきた。オフショアには「カースト制度」の伝統があり、プロセス／役割分担の明確なCMMIは相性がよく、「教科書通りのCMMI」が厳格に実施されている。しかし、肝心の品質は格段に良くなったと言えるほどではなく、SIプロジェクトのオフショア開発をこの10年間以上実施してきた経験を通して、「教科書通りのCMMI」のみでは品質向上に限界があると感じ、CMMI＋αを模索してきた。SEIは事業改善の3側面として、人間、手順と手法、ツール／機器を示し、その中心にプロセスを置き、プロセス管理を具現化したCMMIを構築した。「＋α」を考えるにあたり、3つの側面のうち「人間」に着目し、「不具合を恥じ、自発的に品質改善を願う力＝『人間力』を引出すこと」を現場改善に活用する基本コンセプト＝「人間重視のCMMI」の観点からオフショア開発現場改善を実施した結果、品質向上、顧客満足度向上に効果が高く、現場にこの改善の文化が根付いた。「人間重視のCMMI」は日本国内開発現場改善の実践例として堀田勝美氏、関弘充氏、宮崎幸生氏により「人間重視の品質マネジメント〜ソフトウェア品質保証システムの構築と実践」として出版されている。本報告は、この国内実践例の考え方や活動がオフショア開発でも適用でき効果的であるということを、オフショア開発での事例により示すものである。
オフショア開発CMMIの最大課題に「あいまいな顧客要件」がある。明確に定義された顧客要件はCMMIで「継続的改善」の文化が根付いていたが、「あいまいな顧客要件」には改善の文化が根付いていなかった。このため上記の「人間重視のCMMI」の基本コンセプトに基づき、(1)CMMI＋人間力、(2)現場のボトムアップ活動の導入、を具体的仕組み構築の「2つの方向性」とした。既存のオフショアCMMIの仕組みを分析し、課題を明確化した上で、上記2つの方向性に基づき、具体的に以下の5つの仕組を導入した。(1)第三者品質検証結果から「気付き」を得てそれをチーム内に横展開させる活動。(2)「あいまいな顧客要件」にも踏み込んだ定量的品質管理。(3)リスクに対する前向きな対応策を考える「リスク管理」。(4)現場での自主的品質改善活動（不具合を生成しない活動と全員参加型改善提案活動）。(5)「人間重視のCMMI」を推進するプロジェクト型QMの現場チーム内への設置である。（注：オフショアの品質管理部門（独立型QM）は、顧客が求める客観性／中立性確保のために原則第三者の位置づけでチーム内品質向上活動にはタッチしないため）。この仕組の最初の導入事例であるA政府様プロジェクトが本報告事例である。成果として777項目の「あいまいな要件」を明確化し取込むことができた。この要件を含めて最終顧客テスト結果は0.03/1Kステップで目標の0.05/1kを上回る品質を実現できた。お客様からは「大変使い安く、期待どおりで気に入った」との評価を得た。このシステムは現在まで、無停止で稼動。「人間重視のCMMI」の仕組みは現場に根付き現在、弊社日本顧客向けオフショアプロジェクトで更に強化して実施中。「人間重視のCMMI」を今後多くの国内／オフショア開発事例で検証し、現場改善の文化を根付かせていく所存である。

企画プロセスですべきことと要件定義プロセスですべきことを切り分け、前者の完了基準を明らかにした。さらに、企画プロセスについて実務経験や文献をもとに詳細プロセス、成果物を見直し、実用性を考慮した上で標準化を行った。また、プロセス実施におけるステークホルダ間の合意形成手段として、論理的側面において「リザルトチェイン」を取り上げ、情緒的側面では「ヒューマンリレーションシップピクチャ」技法を考案し有効性を検証した。

１．背景
ソフトウェア開発の大規模プロジェクトでは仕様確定の遅延や多発する仕様変更が原因で、スケジュール延期やコスト超過などのプロジェクト状況が悪化する問題が発生することが多い。このような問題へ対応するためにはプロセス改善が必要と考えられる。大規模プロジェクトの特徴として、以下の点が挙げられる。
(1)仕様が確定しにくく、かつ、開発期間が長期となるため、仕様変更が発生し易い。
(2)オフショアを含む多くのパートナー会社と協調した開発となり、分散開発が適用される。
(3)一般的に計画性・安定性を重視したウォーターフォール型開発プロセスが適用される。
(4)ドキュメンテーションにより情報共有・情報伝達を図るため、ドキュメントが重要視される。
特に(1)の仕様確定や仕様変更に関して解決する方法として、変化への対応を重視したアジャイル開発プロセスの適用が考えられるが、(2)〜(4)にはアジャイル開発プロセスと相反する考え方があり、アジャイル開発プロセスとの融合・適用が可能であるか検証が必要となる。
本報告では、大規模プロジェクトのプロセス改善を最終目標とし、(2)に示したオフショア開発と連携した分散開発に着目して、アジャイル開発プロセスを実際のプロジェクトにて実験的に適用し、評価結果について報告を行う。

２．適用プロジェクトと開発プロセス
オフショアと連携したアジャイル開発プロセスを実験的に適用するプロジェクトとして、社内システムの開発プロジェクトを選択。中国ベンダと連携したオフショア開発を実施し、アジャイル開発プロセスとしてスクラム、ＸＰの開発プラクティスを適用した。

３．オフショアと連携したアジャイル開発実践
オフショアと連携したアジャイル開発を実践するにあたり、コミュニケーション面と品質面に着目し、実施した施策内容とその効果、見直し点等について述べる。

４．評価
実践結果を生産性・コストの観点で評価を行う。また、アジャイル開発実践の結果、既存の開発プロセス改善として適用可能と考えられる点を述べる。

５．まとめ
オフショアと連携したアジャイル開発の実践・評価を行い、一定の成果を得ることができた。今後はアジャイル開発の更なる実践、および、ウォーターフォール型開発プロセスとの融合について実践・評価を進めていきたい。

１．なぜ、「現場担当者の作業品質」なのか
・第三者品質検証はプロダクト（主要生産物）を対象にするのが一般的である。しかし、第三者のスキル的な制約等により形式レベルのチェックに止まるケースが多く、効果が局所的であった。プロダクトを検証対象にする限り付き纏う課題であり、これを解決するため、第三者品質検証の対象として「人（作業品質）」それも、リーダではなく「現場担当者」に着目した。
・現場担当者が作業プロセスを実行した結果としてプロダクトが作成される。したがって、やるべき作業がキチンとやられてなければ（作業品質が悪ければ）プロダクト品質は低下する。現場担当者の作業品質はプロダクト品質を大きく左右する。
２．「現場担当者の作業品質」を検証する要素
「現場担当者の作業品質」に大きな影響を与える４つの要素を検証する。
３．「現場担当者の作業品質」を検証する方法
三現主義・・・現場（現地）に行き、現物（レビュー記録等）を検証しながら、現場担当者にインタビューし、現実（作業品質）を把握する。検証結果は報告書としてプロジェクト側にフィードバック（提言含む）する。
４．「現場担当者の作業品質」検証を実施するタイミング
作業品質問題を早期に摘出するため、工程途中での実施を原則とする。具体的には担当者の１本目の作業が完了したタイミングで実施する。
５．「現場担当者の作業品質｣検証が効果的な工程
マネジメント難易度が大きく、現場担当者の作業実態が見えなくなるリスクが最も大きくなる中流工程に対する検証が最も効果的である。
６．中流工程における第三者品質検証の事例
「現場担当者の作業品質」に着目した第三者品質検
証の中流工程での適用事例を、プロジェクト現場の実態を交えながら説明する。７．最後に・・・第三者品質検証マインド
プロジェクト品質向上のため第三者品質検証という有効なツールをもっと上手く活用していきたいものだ。そのためには、検証される側／する側双方の第三者品質検証マインド（ポジティブに考える／当事者意識で対応）が重要である。

本論文ではアジャイルソフトウェア開発に生じる問題を解決する目的で導入したチケット駆動開発(TiDD)とその効果について報告する．TiDDはRedmineやTracといったBTS(障害管理ツール)を開発作業の管理に用いる方法である．TiDDは特にアジャイルを意識したものではなかったが，本論文ではアジャイル開発が細かな作業の組み合わせによって実施されていることに注目し，BTSのチケットをアジャイル開発のタスクカードの代わりに用いた．

プロジェクト期間中に随時行われたふりかえりの結果に基づくインタビューの結果，

(1)多くの作業が容易に管理できた，
(2)個人毎の作業が一覧できるので日々の作業が計画的に行えた，
(3)複雑な構成管理作業の抜けが生じなかった，

などプロジェクトリーダや開発者の負担を軽減することがわかった。また，BTSとテスト管理ツールの併用によって進捗管理が容易になること，構成管理ツールとの連携によってソースコードの変更理由の特定が容易になることも確認できた．

デンソークリエイトでは、2006年より「トレーニング指向アプローチによるプロセス改善」に取り組んできた（SPES2007・2008で発表）。また、CMMIレベル３達成に向け「エンジニアリングプロセス（以下、EPと略す）の自己履行検証方式」を考案し、その方式を浸透・定着させるためトレーニング指向アプローチの仕組みを活用してきた。本稿では、「EP自己履行検証活動」をトレーニング指向アプローチの適用事例として取り上げ、「”自己”にすると検証活動が”自己トレーニング”となる」図式と仕組みの活用効果について発表する。
(1)背景
組み込みソフトウェア開発の多くは派生開発・変更開発であり、仕様が曖昧・未定のまま開発が進み、終盤に仕様変更が多発することが多い。この結果、開発は品質問題を抱えながら納期に追われ、高負荷状態が続く中、不平不満とともにチームは疲弊してしまう。多くの組織では、この状況を解決すべくプロセス改善に取り組むことになるが、「やらされ感」のもと形式的・表面的な活動に陥る危険性が高い。当社でも、1996年よりトップダウンによるプロセス改善に取り組んできたが、前述のような状況に陥ってしまった（失敗経験）。「２度と失敗させない」という思いの中、プロセス改善の本質は「人が育つこと」であると気づき、「トレーニング指向アプローチ」と名付けた活動を実施している。活動は、徐々に開発現場に浸透し、改善活動を常態とする改善マインドが芽生えてきた。
(2）当社の課題（CMMIレベル３に対する取り組み）
現場の改善マインドが醸成される中、「CMMIレベル３達成」を顧客から要求され「会社目標」として目標達成を強いられることになった。レベル３ではエンジニアリング領域も対象となるため、未熟な若手担当者にEPを与えることになり、「プロセスに従い、ただ仕事をこなすだけ。結果として、人が育たない」という「失敗シナリオ」に陥る危機に直面していた。
(3)EP自己履行検証方式による課題解決
この問題に対し、”自己”履行検証方式を取り入れた。自らの履行を自らが確認することで「現場の一人ひとりがプロセス自体を学び、主体的に考え、自己改善・現場改善につないでいく」ことを狙った方式である。若手担当者に与えられたプロセスを”自分のプロセス”に変化させる方式である。
(4)トレーニング指向アプローチの仕組みの活用
EP自己履行検証方式を現場に浸透・定着させるために、トレーニング指向アプローチの中核となる「仕事の質のモデル化」や「現場密着型SQA」などの仕組みを活用した。
”自己”ゆえに、はまりやすい落とし穴から現場を守り、現場の主体的な改善活動を引き出している。
(5)効果の確認
全社26プロジェクトに対しEP自己履行検証方式を適用した。
SQAの診断結果より、仕組みを活用できるPMが2.5倍に増え、若手担当者の主体性・活用度合いも40％〜50％程度の向上が確認できた。さらに、定着が進むにつれ、「手戻り工数が1/2以下、作り込み欠陥の数が1/3以下」に削減され、現場が実効を体感できている。