デンソークリエイトは組み込みソフトウェアの請負開発を主な事業としているが、長期間に渡り常に開発に追われメンバーが疲弊する、という状況を繰り返していた。その状況から抜け出すには”素早く”動くことが有効であると気づき、組織の素早さを引き出す仕組みを築いてきた。本稿では、”素早さ”を持つ組織になるための仕組みと、その効果・事例について発表する。

【1】背景・問題
組み込みソフトウェア開発は年々大規模化している。製品評価のフェーズでは仕様変更や不具合対応が多発し、開発終盤に特に負荷が集中する。その結果、次の開発の立ち上げを始めることができない場合が多い。また、開発の初期段階では、仕様の曖昧さが多い。更に顧客側での動き様が見えないことも加わり、プロジェクトの立ち上がりの遅れを助長する。
このように立ち上がりの遅れが常態化し、結果的に開発終盤に負荷が集中するという悪循環に陥っていた。
そのような状況に対し、現場は「仕様が決まらない・変わる」「無理な要求を強いられる」等の不平・不満を常に抱き、被害者意識でいっぱいのまま、悪循環から抜け出すことができずにいた。

【2】課題
現場は他責・被害者意識が強く、悪循環を断つために顧客をはじめとした周り（他人）に変わってほしいと望んでいた。
しかし、他人のことを変えるには限界があり、変わらないことにより一層不平・不満が強くなっていた。そこで、発想を変え、仕様が曖昧・変わる等の周りが大きく関係することに対し、”そういうものだ”と受け入れ、自分たちが出来ることをやって、問題の状況を軽減するアプローチを考えた（変えられないことを前提とした）。　そして、曖昧なもの・変わるものに対し我々が出来ることは「早く始めることである」と気づき、”素早さ”を持つ組織になることが課題であると考えた。

【3】”素早さ”を持つ組織を作る仕組み
まず、”素早い”組織となるための要件として(1)「攻めの気持ち」を持ち、行動するための(2)「機会を持つ」、そして、それらの定着を支える(3)「モニタリング」の3つを掲げた。

(1)「攻めの気持ち」：標準プロセスで「上位活動への参画」を明示し、顧客活動に入り込む覚悟を決めさせた。そして活動の中心となるPM層と、PM層を支える若手メンバーのそれぞれに対し、意識付けのトレーニングを行った。

(2)「機会を持つ」：いくらプロセスがあり意識付けをしただけではうまくいかない。コミュニケーションが元々苦手な人が多いため尚更である。そこで、強制的に機会を持たせる「Catch Ball Meeting(CBM)」の仕組みを導入した。

(3)「モニタリング」：気持ちや機会があっても、元々苦手な活動であるため、人の弱さが出てしまい、やらなくなる・できなくなる可能性がある。そのため活動状況を定期的に確認できる「モニタリング」の仕組みを構築し、人の弱さに歯止めをかける仕組みとした。
また、周りは変えられないことを前提として築いた仕組みだったが、自分たちが”素早く”行動することにより、周りをも動かすことができることにも気づいた。(副次効果）

【4】効果の確認
(1)仕組みが機能しているか：活動状況で判断
以下の状況から仕組みが機能しており、”素早さ”を持つ組織となる仕組みが構築できたと判断している。
・CBMの実施状況：活動開始から3年間実施率は90%以上を維持し、年間の実施回数も全プロジェクト合わせて1000回を超えるようになった。
・上位活動への参画：PM自身の自己診断と第三者によるアセスメントの診断結果ともに1年から1年半で満点近くに向上し、活動の定着が見られた。

(2)問題が解決しているか：仕組みを取り入れたプロジェクトの結果（事例）で判断
仕組みを取り入れた実際のプロジェクトで効果が確認されたため、”素早さ”を持つ組織がとなることが問題解決につながると評価している。
・初期から「上位活動への参画」を積極的に行い、活動量は過去の同規模のプロジェクトより格段に多い。
・「上位活動への参画」を基盤とし、過去の同規模プロジェクトの約4倍の課題・リスクを活動初期から素早く抽出し、素早く解消し、終盤の混乱を抑制した。
・結果的に、顧客評価での不具合は過去の同規模プロジェクトの約1/3に削減できた、品質も向上した。

近年、IT業界ではコスト削減や要員確保を目的としたオフショア開発が広がりつつある。当社も中国でのオフショア開発を推進しており、その中で様々な課題に直面し、克服してきた。本論文ではオフショア開発の中でもドキュメントの日本語化という課題について当社の取り組みを説明する。

中国オフショア開発においてもドキュメンテーションは日本語で行われることが通常である。日本語スキルに優れた要員を揃えることが理想ではあるが、日本語スキルが低い要員が開発チームに加わることもある。すなわち、ドキュメントの翻訳という作業が避けられない。ドキュメントの翻訳方法については様々な方法があるが、検討の結果、今回は翻訳ソフトの活用による翻訳を試行した。

翻訳ソフトは安価かつ高速に翻訳することが可能であるが、翻訳精度が課題となる。事前の検証結果でもシステム用語や文章については特に翻訳精度が芳しくなかった。そこで、翻訳ソフトを活用するために、(1)システム用語や設計項目などの用語を翻訳辞書に登録する（約３０００項目）、(2)長文ではなく短文の翻訳に限定するといった対策を講じた。これらの対策の結果、単体テスト仕様書の翻訳については、日本語として問題のないレベルで訳せることができた。課題となるのは、翻訳辞書に登録されている単語のみを利用させることである。日本側で用意した単語を利用してもらわない限り、翻訳の精度は向上しない。そこで、「入力支援ツール」というドキュメント作成の補助ツールを開発し、これを使用してもらうことで翻訳精度を確保した。

「入力支援ツール」はExcelのアドインであり、Excel上で文章を作成する際の補助ツールとして活用する。主な機能はあらかじめ登録した語句をリストより選択し、セルに入力するというものである。単体テスト仕様書は定型的な文章で記入することが可能である。すなわち、定型文章、単体テスト頻出単語、定義情報（画面項目定義、テーブル定義など）を入力すれば単体テスト仕様書が出来上がる。今回は「入力支援ツール」の入力用辞書に上記の３つを中国語・日本語の両方で追加した。その上で、日本語があまり得意でない要員１名に「入力支援ツール」を使って単体テスト仕様書を中国語作成してもらった。すなわち、単体テスト仕様書作成フローは以下の通りとなる。

(1)中国で「入力支援ツール」で単体テスト仕様書を中国語で作成する、(2)翻訳ソフトを使い単体テスト仕様書を中国語から日本語に翻訳する、(3)日本語に翻訳された仕様書を日本の要員がレビューする。

成果としては以下の３つが挙げられる。
(1)ツールに対する慣れが必要であったが、最終的には日本語スキルがある要員と同等の生産性で単体テスト仕様書を作成することができた。すなわち、日本語スキルが低い要員が日本語の仕様書を作成するより大幅に生産性は向上した。
(2)作成された中国語仕様書を翻訳ソフトで翻訳した結果、ほぼ問題なく日本語に翻訳できた。
(3)仕様書の表現が統一され、読みやすくなった。

今後は辞書の作成など事前準備の効率化に取り組むと共に、一層使いやすいツールへと改良を加えていく予定である。

ソフトウェア開発チームのリーダーという立場で、基幹系個別開発ソフトからコンシューマ向けサービス開発へ転向したという経験から後者の開発を行うに当たり、 両開発のプロセスや目的の違いを対比しつつ直面した問題やその解決のための活動を通して「目的を共有する」ことと「継続して改善し続ける」ことの大切さとその成果について述べる。

基幹系個別開発でははじめにやることをすべて決めなければいけないという難しさがある反面、目指す効用や価値はある程度決まっている事が多い。

しかしコンシューマ向けサービスでは状況の変化が大きく、また一般的な解もない、もしくは定義出来ない場合が多い。

そのような領域の開発を行うにあたり、理想的な姿を定義するがその実現には多くの障害がある。

理想的な姿に近づくために、自分たちの現場である開発チームで取り組んできた内容や価値観、手段を使いどのようにチームを育て、理想に近づけていったかという事例を共有する。

システム開発の上流工程では要求分析に基づき「要求仕様書」が作成され、レビューによりその適切性を確認することが多い。しかし、多くの場合「要求仕様書」には要求分析結果である”システム仕様”だけが記載されていたり、システムにより解決すべき事項や解決後の状態（システムゴールやユーザゴール）が不明確なまま、分析・検討過程が何も表現されていないなど、レビューによる適切性判断（主に、妥当性確認）が難しい状態であることが多いと推察している。

当初からこれらの事項を明確化したうえで要求仕様書に記載することが理想ではあるが、実務ではそうできない理由や背景にあふれており、今後も上記のような結果だけを示した要求仕様がまかり通る可能性が高い。

そこで、実務の現場で提示された「要求仕様書」の内容から、利用時の品質（利用者像・利用時コンテキストを含む）やソフトウェア品質特性をリバースした情報をもとに「要求仕様書」レビューを実施し、的確なフィードバックを提供する方法を提案する。

もともとはテスト設計方法論を検討する過程で生まれたものであるが、システム導入により解決する課題や、求められるソフトウェア品質特性などを階層的に整理・明確化することで、要求仕様の適切性を判断する根拠が明確となるだけでなく、システムに対する非機能要求事項の明確化、利用者の課題に対するITシステムと人間の適切な役割分担の採用、過剰な機能付与・機能不足の防止、システム稼働終了までのライフサイクルを意識したシステム開発の促進、などの効果が期待できる。

本発表は、オフショア開発へのアジャイル開発導入に関する取り組みを説明し、アジャイル開発プロジェクトを評価するためのメトリクスを選定し、定量的な結果を示し、定性的な効果を紹介する。

アジャイル開発は、欧米のソフトウェア開発の現場で広く適用されている（※2）。日本のソフトウェア開発業界では、WEBサイト開発やゲーム開発など、ビジネスや技術の変化へのすばやい対応が要求されている領域でのアジャイル開発への移行が進んでいる一方、SIerの領域では、組織の体質や多階層の請負契約による開発体制といった業界の慣行に、アジャイル開発が前提とする開発のやり方がなじみにくく、その事例は依然として小規模案件にとどまる傾向がある。当社は、90年代から大規模反復の開発を実践してきた。2011年からは開発方法、測定や契約を含む体系である「OGIS Scalable Agile Method（OSAM）」を社内の開発プロジェクトに適用・推進している。（※3）

オフショア開発については、「グローバルデリバリ」の動き下で、当社は2007年10月に、日中合弁の形で上海欧計斯軟件有限公司（SOT）を設立し、グローバル事業展開の一環として上海にオフショア開発拠点を持つに至った。設立以来の数年間で、オフショア開発プロセスの整備や、開発経験の蓄積によって、当社同様にコスト削減の効果を上げている（※1）。しかし、国内のパートナー企業との協力と比べ、仕様に関する説明、合意の形成、詳細な仕様書の作成、現地出張の費用、品質管理/トラブルの対応、進捗管理/遅延の対応コストなどは、依然大きな課題のままである。これらのコスト増加の要因の低減を目的として、当社はオフショア開発へのアジャイル開発の導入を試みた。

要求の主導権の観点から分類すると、SOTでは、以下2種類の受託開発を行っている。
1. 当社の要求を満たすための開発
2. 当社の顧客の要求を満たすための開発

上記2の開発に関しては、日本で上流設計を行い、中国に詳細設計〜結合テストの工程を発注、日本で成果物を受け入れ、システムテストを実施するという典型的なオフショア開発である。上記1の開発に関しては、当社の社内システムの開発やパッケージ開発になるが、当社が推進しているOSAMの一部を導入した。具体的に開発手法はScrumを導入し、技術的なプラクティスとアジャイル開発をサポートするツールを開発に導入した。

アジャイル開発の導入結果に関し、定量的なプロジェクトのデータを収集した。また、現地で関係者が一堂に会してのプロジェクト振り返りを経て、開発関係者の定性的な意見を収集した。定量的なデータの分析と定性的な感想から、アジャイル開発の導入によって、オフショア側のチームの一体感及び、人員の定着率が向上し、生産性と品質の安定化などの効果がもたらされた。また、課題についても顕在化してきた。

今後の取り組みとして、1)オフショア開発とアジャイル開発のプロセスをSOTの開発標準に盛り込み、また、2)当社の要求を満たすための開発以外に、当社の顧客の要求を満たすための開発へのアジャイル開発の導入を予定している。

※1　独立行政法人 情報処理推進機構、『IT人材白書2011』

※2　VersionOne, 2010 State of Agile Development Survey Results

※3　オブジェクト広場　2011年9月、『OGIS Scalable Agile Method の真髄』

(1) 背景
昨今の組み込みデバイスは、製品競争の激化により、高機能、高品質、短納期、低コストへの要求が強く、これらの課題解決が急務となっている。しかしながら、長きに渡る景気低迷によりヒト・モノ・カネといったリソースが潤沢に割かれるわけではない。派生開発においては、新規開発に比べて更に強い傾向にある。では、どうすれば迅速かつ最適の人員で、高品質なソフトウェアを開発することができるのか。個々の力では、限りがあるので、技術手法とチーム力で解決していきたいと考える。

(2) 課題
・派生開発において、迅速かつ最適の人員で、高品質なソフトウェアを開発したい
・派生開発におけるQCDの同時達成を目指したい
・様々な変化に対応できる下地を作りたい
・少しでも現場を良くしたい

(3) 実施方法
[技術的なアプローチ]
派生開発に特化した手法であるXDDPを適用した。
[チームによる継続的改善アプローチ]
アジャイル開発手法の一つであるSCRUMを適用した。
[開発フェーズの分割]
開発フェーズを２つに分けた。
前半フェーズ：基本構造に関する（H/Wに影響のある）変更要求をXDDPを適用して品質を固める
後半フェーズ：新規機能追加部分をIteration開発で進める

(4) 結果 (Q)QA検査不具合指摘件数 ：軽微な内容の不具合数件のみ ○
(D)納期遅延０日：現時点で計画通りである ○
(C)予算超過無し：現時点で予算内である ○
メンバの充実感：プロジェクト終了後のアンケートからも充実していると思われる。 ○

派生開発プロジェクトにおいて、派生開発に特化した手法(XDDP)を適用することは、品質面、納期面、開発コスト面において効果があった。また、アジャイル開発手法の一つであるSCRUMを適用することで、チーム内に一定のリズムが生まれ、チーム全体で改善意識を最後まで保つことができた。理に適った手法を適用し、チームメンバが自律して改善を繰り返しながら開発を進めて行くことで、迅速かつ最適の人員で、高品質なソフトウェアを開発することができると言える。

要求工学知識体系REBOKの要求工学プロセスは，要求獲得，要求分析，要求仕様化，要求の検証・妥当性確認・評価から構成される[1]．著者の所属している組織では，要求分析、要求の検証・妥当性確認・評価の支援技術を開発している．要求分析の支援には，要求として定義すべき項目をメタモデルとして定義し，要求の定義漏れの防止や均等化に取組んでいる[2]．要求の検証・妥当性確認・評価に対しては，要求品質チェックシートと呼ぶチェックシートを用いて要求仕様書の定義網羅性を確認している．しかしながら，要求の検証・妥当性確認・評価にあたり，次のような課題に直面した．

課題1：要求獲得プロセスの品質評価のやり方が属人的

課題2：簡単に利用できなければ要求獲得プロセスの品質評価が定着しない

課題1に対する解決策として，メタモデルを用いて成功事例の要求仕様書を分析し「理想的な要求獲得プロセス」（以降，理想モデル）を定義する．理想モデルと対象プロジェクトの要求の定義過程を比較することで品質評価をする手法として定義する．課題2に対する解決策として，要求品質チェックシートを利用した評価ツールを作成する．

上述した解決策を実事例に適用し，課題1，2を解決できるか確認した．確認の結果，理想モデルと異なる要求の定義過程となっている場合、要求仕様書に不整合があることが発見できた．要求仕様書の不整合が発見できたことで，要求獲得プロセス検証手法は要求獲得プロセスの評価に効果があることが確認できた．作成した要求品質チェックシートを利用した評価ツールにより、要求獲得プロセスの品質評価のやり方を統一することが可能であり，課題1に対して有用である．

既存の取組みである要求品質チェックシートを利用することにより，低コストで要求獲得プロセスの検証を実現した．プロジェクトに高い負荷をかけることなく要求獲得プロセスの品質評価が可能になり，課題2を解決することが出来る．今後は，複数のプロジェクトへの適用を通して，本手法を継続的に改善していく．

【参考文献】

[1]情報サービス産業協会REBOK企画WG, 要求工学知識体系 第１版, pp.31, 2011.

[2] 北川貴之，橋本憲幸，吉田和樹，位野木万里：要求定義における暗黙知の形式知化手法，コンピュータソフトウェア，Vol.27，No.3，2010年8月，pp.93-98，2010.

富士通エフ・アイ・ピーではアウトソーシングサービスの一つとしてBPOサービスを提供している。本稿では、BPO業務運用の現場で発生する様々な課題（「属人化」「手順の陳腐化」「運用ルールの変更」など）を通し、課題解決のための改善手法に焦点をあて、現場主導で実施可能なその方法と効果について発表する。

1.背景

お客様（社員：約2,200名）の管理部門業務の一部を2009年10月から当社がサービス提供している。

当社初の本格的な管理部門の業務BPOであったが、2009年9月までは他社（A社）に委託されていた為、お客様は委託先変更の意識がなく、短納期でかつこれまでと同様の安定した運用を期待された。当社は,、品質確保の為、旧委託先（A社）の業務システム・運用手順をそのまま移行（As-Is To As-Is方式）を実施。その結果、立ち上げから半年間は、安定運用によりお客様から高評価を頂いた。

2.課題

本稼働後、半年間は安定稼働していたがその後お客様によるチェックのエラー検出数が増大。2009年度は32件であったが、2010年度では112件にのぼった。お客様から得た信頼を喪失しかねない状況にあった。更に、メンバのモチベーションも低下傾向にあった。

3.課題解決に向けた取り組み

これらを解決するために本プロジェクトに「Lean(※1)活動」を適用した。

（※1）Leanとは、価値を生み出し、ムダを排除して継続的改善の文化を構築するという働き方

具体的には、以下サイクルを展開した。（※2）以下括弧内は活動ポイント
(1) メンバが運用中に気付いた点を付箋紙に書き、壁に添付（問題の可視化）
(2)(1)の内容についてメンバ全員でアイディアを出し、壁に添付（否定はしない）
(3)改善担当者が(1)と(2)の内容を取り纏め、一覧表を作成（既存運用への負荷軽減）
(4)メンバ全員で一覧表を元に改善内容を決定し、合意（メンバ主体の運用へ）
(5)本番運用
(6)改善担当者が改善成果の計測（KPIの測定）

ソフトウェア開発プロセス改善など，関係者の多い改善活動を行う際には，関係者の合意形成が非常に重要である．この合意形成が不十分だと，改善施策の意図を歪曲したり，勝手な解釈をしたりし，改善が十分な効果を上げることができなくなる．しかし，このような合意形成は重要であるものの困難なことが多い．複数の関係者が関わる場合，改善対象となる問題点は複数存在することがあり，関係者の立場によって，それら問題点の重要度が異なってくる．また，それら問題点は相互関係を持つことも多く，ある関係者一方の立場で重要と考えられる問題点を解決しようとすると，別の関係者が重要と思っている問題点に悪影響を及ぼすようなことが起こる．このように複数の問題が相互関係を持ち，関係者がそれらについて異なる重要度を持っていることが，関係者の多い改善活動における改善施策の合意形成を困難にしていると考えられる．

本報告では，このようなソフト開発プロセス改善における改善施策の合意形成に対して，TOC思考プロセスの現状構造ツリーの導入を提案する．TOC思考プロセスは，制約条件の理論(Theory of Constraints)の手法の一つであり，目的を阻害している中核の問題を発見・解決することで最小の労力で最大の改善効果を得る，体系的な問題解決手法である．このTOC思考プロセスの中の現状構造ツリーは，改善対象の問題の因果関係を構造化したもので，このツリーを用いて，中核の問題を1つか2つに絞り込んでいく．この現状構造ツリーは，上述のように立場によって重要度の異なる複数の問題が存在している場合であっても，それらの因果関係を見える化することができ，集中して改善すべき中核問題を明確にできる．このように現状構造ツリーは，改善施策の合意形成を困難にしている要因を排除できるため，複数の関係者が関わる改善活動において非常に有効な道具であるといえる．

本報告では，日立グループのある組込みソフトにおけるテストプロセス改善に対して，TOC思考プロセスの現状構造ツリーを用いた事例を報告する．改善対象組織では，テストが不十分になり，不具合の抜け漏れが発生しているという問題があり，ソフト設計者と品質保証部の担当者等で構成したワーキンググループ(全16名)を組織して，この改善に取り組んだ．報告者は，このワーキンググループによる改善施策の検討に現状構造ツリーを用いた．結果，集中すべき中核問題は，全てのテスト結果の客観的証拠を保存しなければならないという方針であることを明確にした．この中核問題を明確にすることで，不具合摘出のためのテストを定義し，そのテストのためにテスト観点レビューという改善施策を，ワーキンググループメンバー全員が納得する形で導出することができた．本改善施策は，実際に試行・評価し，多くの不具合を摘出できることも確認した．

日立ソリューションズでは、２００７年より「超上流プロセス対応力の強化活動」として、企画・要件定義工程で適用する技術とプロセスの整備、それを活用する人財育成を推進してきた。今年４月には、活動成果の一つとして、要求開発手法「HyThologyTM」を社内外に発表し、実務での適用を進めている。

本稿では、HyThologyTM開発において技術体系化のベースとした要求工学知識体系（REBOK）の活用を中心に、当社の取り組みを紹介する。

（１） 取り組みの背景と課題

IT活用によるビジネスでの価値創造とプロジェクト成功のためには、超上流工程が重要である。しかし、適用する手法や方法論には、コンサルティング・メソドロジからモデリング手法まで、多種多様な技術が紹介されており、取り組むべき全体像が把握しきれない状況が続いている。現場で実践する為にプロセス・作業と手法を標準化する事が必要である。併せて、超上流工程の専門家たる高度IT人財（超上流人財）を広く育成し、超上流工程の円滑な遂行と要求品質の確保を図る事が重要である。

（２） プロセスと技術の体系化

顧客企業側の体制やプロジェクトの特性により作業プロセスは様々に変化する。共通フレーム（SLCP）をもとに、作業プロセスをモデル化し、このプロセスを遂行する為の技術を、REBOKでの要求工学プロセスに対応付けてHyThologyTMとして規定した。

（３） 人財育成

ITスキル標準（ITSS）の考え方に沿って、遂行する業務・タスクや必要なスキルを、超上流人財モデルとして可視化した。検討にあたってはREBOKの共通知識領域（REBOK Core）の内容を利用した。さらにキャリア開発のために、スキル習得の為の選抜者研修を開発し、HyThologyTMとその技術・手法、REBOKの活用法等を現場のＳＥ・営業担当者に提供している。

（４） 効果

一年間の試行期間を経て、現場からは『従来は経験的に獲得してきたスキルが、HyThologyTMとして、SLCP・REBOK等の標準的な体系で整理されたことにより、ノウハウの充実や後進の育成に有益』との評価を得ている。顧客企業からも説明の依頼を受けており、顧客とベンダーが同じ言葉・考え方で超上流工程に取り組むためにも、有効な技術として適用を推進して行きたい。

ソフトウェア開発ベンダーにおいて、システム開発標準により、システム構築の手順や作法を標準化することは一般的である。最近では、REBOKやBABOK、IPAの機能要件の合意形成ガイド、非機能要求グレードなど、上流にフォーカスした各種標準が提供されるなど、システム開発標準は充実してきている。

著者の所属する組織においては、プロセス、テンプレート、ガイドから構成されるシステム開発標準を定義している。これらは、会社の戦略、組織、技術の変化に伴い、継続的改善が必要である。今回、リリースされた各種標準や、社内ノウハウを加味して開発標準の改善に取り組み、特に開発成果物を定義するためのテンプレートを開発・改善した。

しかしながら、テンプレートの開発・改善において、次のような課題に直面した。
(1)テンプレートの開発手順が非効率で遅れが発生。
(2)テンプレートに記述する項目の定義漏れが発生し、テンプレートの品質が低下。

そこで、上記課題の解決のために、(1)の課題の解決策として、テンプレートのフォーマット定義とグループ化によりテンプレート開発の作業を共通化することとした。(2)の課題の解決策としては、メタモデル（※1）を軸として、既存のシステム開発標準テンプレートや、仕様書作成支援ツールの仕様データで定義された項目と対応関係を取ることとした。(1)、(2)の解決策に基づき、テンプレート開発の効率化と高品質化を目指した。

上述した解決策をテンプレート開発・改善に適用した。本解決策の適用後、1テンプレートあたりの開発の生産性が3.2倍に向上した。また、開発した1テンプレートあたりの指摘件数も約6割減少した。このことから、考案した手法はテンプレート開発の効率化と高品質化に有効であると考えられる。この手法は、テンプレートの説明コメントや事例作成作業に対しても適用できると考えられ、継続的に改善していく。

（※1）「メタモデル」とは、要件定義書や基本設計書などの仕様書をモデルとビューに分け、モデルの構造を一般化したものである。

本プロジェクトでは、設計書の管理・情報の共有を目的とした基盤を開発しており、社内のSEが顧客プロジェクトのために活用している。開発の過程において、完成したシステムが設計の段階で想定したイメージと異なり、フィードバックを取り込みきれないことがあった。そのため、設計の段階で画面イメージの認識統一を行うべく、プロトタイピング手法を採用した。その結果、効果を得ることができた。

しかし、これまでの開発では、システムの完成後のイメージが伝わるレベルでプロトタイプを作成していたため、作成コストが大きく画面設計の開発効率が悪いという問題があった。また、プロトタイプの精度が高くなることで画面の細かいレイアウトに注意が向き、重要度の高いユースケースが十分に議論されないことも起きていた。これらの問題を解決し、画面設計の開発プロセスを改善する必要があると考えた。

そこで、画面設計の開発プロセスの見直しを行い、次の２点の改善に取り組んだ。
（１）ペーパープロトタイピングと実際に動くプロトタイプを組み合わせ、段階的に行うプロセスに改善
（２）上記で改善したプロセスに従った、画面設計作業とレビュー観点の整理

上記の取り組みにより、次の効果を得ることができた。
（１）予定外の再レビューの削減
（２）ユースケースの画面設計前半での認識統一
（３）画面設計の仕様漏れによる手戻り件数の削減

結果、画面設計の開発プロセスを改善することができた。本発表では、改善を通して得られた、画面イメージの認識統一の事例とその効果について紹介する。

要件定義書はシステム開発のプロジェクトを成功に導くために重要なドキュメントである．顧客とベンダは開発するシステムの仕様を要件定義書に記述し，記述内容について合意する．さらにベンダは要件定義書をもとに開発の見積もり，開発計画を作成する．

要件定義書に記述漏れや曖昧な記述があると，後工程で手戻りや追加作業などの問題が発生すると考えられる．例えば，設計の担当者が要件定義書の曖昧な記述を誤解したまま作業を進めると，誤りに気づいたときに大きな修正作業が必要になる．

そこで筆者らは要件定義書に起因するプロジェクトの問題を防止するために、要件定義書の品質を第3者が定量的に評価し、評価結果と改善提案をプロジェクトにフィードバックする取り組み（要件定義書の第3者レビューの取り組み）を開発し、当社内の開発プロジェクトへの適用を進めている．

要件定義書において記述すべき内容が記述されているか，曖昧でない書き方で記述されているかといった観点で要件定義書の品質を定量的に評価し，品質をスコアの形式で表現する．スコアが低いプロジェクトには要件定義書の改善提案もおこなう。これにより、プロジェクトは要件定義書に起因する問題を予防するための対策を取ることができる．

本報告では、当社の要件定義書の第3者レビューの取り組みの概要を紹介する。取り組みでは適用プロジェクトへの追跡調査をおこない、第3者レビューの適用効果に関するデータを収集した。そこで、要件定義書の品質の可視化・改善がプロジェクトの後工程での工数削減に有用との実証結果も併せて報告する。

COSMIC機能規模測定法はソフトウェアの機能規模を測定する手法である。COSMIC機能規模測定法で測定した機能規模は、労力や欠陥数など他の測定データと組み合わせて開発生産性や欠陥密度を求めることができる。これらの値を他のプロジェクトと比較して、開発プラクティスの良い点や改善点を明らかにすることで、よりよい開発を目指すことができると考えられる。

機能規模の測定を現場で展開するには、機能規模の測定コストを削減する必要がある。測定コストを削減すれば、これまで測定コストが妨げとなって機能規模の測定が難しかった大規模プロジェクトの測定も可能になる。

そこで、著者らは、COSMIC機能規模測定法の概算法の適用を検討した。COSMIC概算法は、COSMIC機能規模測定法に基づいて概算で機能規模を測定する方法であり、測定コストの削減が期待できる。COSMIC概算法を適用する場合は、COSMIC測定マニュアル応用編に記載されている概算法の例を元に、個別に調整する必要がある。著者らは概算法の例の中から、平均機能プロセス数法を元に概算法を定めることにした。

まず、平均機能プロセス数法の具体的な手順を決定して「サンプリング測定法」を定め、さらに平均機能プロセス数法を簡略化した測定方法である「過去データ参照法」を考案した。サンプリング測定法は、測定対象の一部の機能だけをCOSMIC法に基づいて精密に測定し、測定した結果を元に概算規模を求める方法である。過去データ参照法は、COSMIC法に基づく測定は行わずに、基本設計書から得られるテーブル数と過去の測定データを元に概算規模を求める方法である。いずれも通常のCOSMIC法に基づく測定に比べて、簡易な方法である。サンプリング測定法と過去データ参照法は実際のプロジェクトに適用して概算規模を測定し、測定した概算規模の妥当性と測定コストの削減率を検証した。

サンプリング測定法と過去データ参照法をプロジェクトに適用した結果、測定した概算規模は妥当であった。サンプリング測定法の測定コストは通常のCOSMIC機能規模測定法で測定した場合より、80%程度削減でき、過去データ参照法の測定コストはサンプリング測定法よりさらに50%程度削減できた。二つの概算法は、測定に求める確度や、確保できる測定コストによって使い分けることを考えている。

今後は、さらにCOSMIC概算法による測定件数を増やし、測定結果の検証を行う予定である。

野村総合研究所の社内システム（業務プロセス管理システム（ProArk/BPM））の改善の中で実施された計画策定サブシステムのRIA化を通し、NRI自身における業務システムRIA化の取り組みの紹介と実践におけるポイント・注意点を説明。

・業務プロセス管理システムの紹介
今回カイゼンの対象となったNRI社内業務システムについて、予備知識としてご紹介

・RIA化の経緯
従来の会計システムがExcelでフロント部分を開発していたため、操作性を考慮して当初はExcelで開発したが、Java（Web系）のシステム機能との業務的な分断が課題となり、全社での利用開始を機にRIA化を実施することとなった。

・RIA化の方式説明及び設計・開発時のポイント
Flexを利用してRIA化を行ったため、Flexをどのように既存システムと連携させているかという技術的背景の説明設計時点にユーザエクスペリエンスを向上させるために、業務的な機能については最初から見えるようにするなど考慮してUIを再作成した。開発時点（実装）では、工数を増加させない・品質を維持するといった観点からJava側機能と組み合わせてさくせいした。