組込みソフトウェア開発は、デジタル化を起点にして急速に大規模化してきている。しかし、開発現場では、コード中心の開発がおこなわれている場合も多く、全体像の把握が困難になってきている。このような状況を打開するためには、設計の上流であるアーキテクチャ設計を充実させ、開発しているソフトウェアの全体像を明らかにすることが重要となる。しかし、組込みソフトウェアの特性を反映したアーキテクチャ設計方法、アーキテクチャの可視化方法については、標準的な方法が決まっている状況ではなく、時間に追われる開発現場での導入を阻む要因となっている。本書では、設計の全体像を可視化する為の組込みソフトウェア向けのアーキテクチャ設計方法を具体的に提案している。

第一に、組込みソフトウェア開発の特徴である並行動作やパフォーマンスの観点を盛り込んだアーキテクチャ設計の具体的な手順を明確にした。そして、その設計内容を記載するための構造の表記方法などアーキテクチャ設計書のフォーマットを規定した。これにより、開発現場でのアーキテクチャ設計実施の負担の軽減を図っている。

第二に、日本の特徴である”擦り合せ”による高品質開発の良さを活かすために、コーディング段階でアドホックに擦り合せるのではなく、設計段階でプロアクティブに擦り合せるための手段として、”観点マトリクス”を提案している。観点マトリクスは、全体の一貫性の確保、設計の抜け漏れの低減、そして、トレードオフなど全体に関わる設計意図を明確にすることにも貢献している。

第三に、第一、第二の取り組みで得られた組込みソフトウェア向けのアーキテクチャ設計の可視化方法に基づき、研修コンテンツを開発し、アーキテクチャ設計ができる人材の育成に展開している。研修の評価として、受講者からは「今まで漠然としていたアーキテクチャ設計として行うべきことが明確になった」、「設計意図の伝達の重要性とその方法がよくわかった」などというアーキテクチャ設計の可視化方法の有効性に対する意見が出ている。今後は、複数機種への対応のための観点マトリクス、および、組込みアーキテクトの戦略的な育成のための仕組みを検討していきたい。

当社では、製品出荷後のトラブルや出荷前の開発プロジェクトでの品質状況、いずれを見ても様々な問題が起こり品質が安定しない時期があった。

そこで、開発部門から独立した我々品質保証部門が中心となり、様々な品質確保施策に取り組んできた。主な取り組み施策には次のようなものがある。

1） 品質確保プロセスチェック − QMPの適用

これまで、品質保証部門が開発プロセスの監査を行ってきたが、成果物中心のチェックに留まっていた。そこで、成果物に着目した監査に加え、マネジメントプロセス自体に着目した新しい監査手法「QMP（progress of Quality Management Process）」を確立し、各プロジェクトで適用した。

2） 品質評価技術の確立 − 「品質評価実施要領」の作成と適用

プログラムやドキュメントの品質評価はプロジェクトに依存する部分が多く、組織として各工程の品質を正しく評価するための考え方、手順は統一されていなかった。そこで、過去に実践したプロジェクトのノウハウを元に品質評価技術を確立し「品質評価実施要領」というガイドラインを作成し社内への適用を図った。

3）効果的な品質の「見える化」の実現 − 「品質モニタリングツール」の開発と適用

品質状態を正しく把握するためには、品質データの蓄積と現物管理を行い、この品質データを元に「見える化」を行っていく必要がある。当社の品質確保プロセスにマッチした品質データの蓄積、管理と「見える化」を効果的に実現するために「品質モニタリングツール」を開発した。

これらの施策を適用することで、事故発生件数は減少し、開発現場での作業ミスも低減する効果が現れるようになった。

今後は、更に品質確保プロセスを拡大し、超上流工程から運用・保守工程まで一環した業務プロセスを規定、管理、改善する活動が重要になってくると考えている。

デンソークリエイトでは、2006年より「トレーニング指向アプローチによるプロセス改善」に取り組んできた（SPES2007〜2009で発表）。失敗経験を通し、プロセス改善の本質は、「人を育てること」であることに気づき、現場の一人ひとりが自ら考え自ら行動する、”アジリティさ”を持つ人づくりを目指している。本稿では、人が育つための出発点となる「事実を捉える」ことに焦点をあて、現場主体に導く仕組み・方式とその効果について発表する。

(1)背景
組み込みソフトウェア開発の多くは「すり合わせ開発」であり、仕様が曖昧・未定のまま開発が進み、終盤に仕様変更が多発することが多い。この結果、開発は品質問題を抱えながら納期に追われ、高負荷状態が続く中、不平不満とともにチームは疲弊してしまう。多くの組織では、この状況を解決すべくプロセス改善に取り組むことになるが、「やらされ感」のもと形式的・表面的な活動に陥る危険性が高い。当社でも、1996年よりトップダウンによるプロセス改善に取り組んできたが、前述のような状況に陥ってしまった。これらの問題に対処するには、「状況に応じ素早くかつ適切に対応する」人、つまりは、”アジリティさ”を持つ人・チームづくりが大切と考え、2006年より取り組んできた。

(2）課題
自ら考え自ら行動するためには、考えるための材料が必要となり、現場一人ひとりの事実を捉えること（見える化）が活動の出発点となる。我々は工数に着目し、工数による一人ひとりの”仕事ぶり”を捉えることに取り組んできた。ところが、工数計測は、人の頭の中の情報を扱うというデリケートな問題を抱えており、トップダウンによる方式では、一人ひとりの”仕事ぶり”を捉えにくく、自ら考えるための材料とはならなかった（失敗経験、失敗の繰り返し）。そこで、現場主体の活動に導き、一人ひとりの日々の”仕事ぶり”を捉えるためのトータル的な支援の仕組みが必要と考えた。

(3)トータル的な支援の仕組み（現場主体に導く方式）
現場主体のボトムアップ方式を基本とし、現場が自力で取り組めるよう、１．方向性を示す　２．道具立てを揃える　３．密着支援する　４．風土・習慣とする などを支援する仕組みを構築した。

(4)仕組みの運用方式
仕組みを効果的に機能させるためには、「工数計測の難しさに手当てする/効果を体感させる/トレーニングにより風土・習慣化させる」を繰り返すことが重要と考えた。現場密着型SQAが中心となり支援し、現場に働きかけていくことで、活動を定着させていく方式を採用した。

(5)効果の確認
事業部門全員（約190名）で取り組み、工数計測（入力）は、徐々に定着してきた（習慣化）。 また、工数計測が定着するにつれ、事実の掌握具合の向上も確認できた（代替尺度で判断）。 結果として、「手戻り工数が半減、作り込み欠陥の数が1/3以下」に削減され、事実を捉えることの効果を体感できている。

アジャイルソフトウェア開発手法は、未知の要件や高頻度の要件変更に対するリスクの軽減や、必要機能の早期リリースなど、我々ソフトウェア開発者にとって非常に期待が高い手法である。

一方で、反復開発に伴い付帯工数が増加することによる生産性の悪化や、最終的なシステム仕様の確定に至らないことによる開発期間の長期化、場当たり的な開発に陥ることによる保守性の低下など、懸念事項の多い手法であると考えられる。

本稿ではアジャイル開発手法を社内システム開発に試行適用し、生産性や品質面から評価した結果について報告する。今回開発したシステムの規模は［8,119step, 99画面］であり、約３ヶ月の開発期間で、イテレーションを６回繰り返している。なお、開発言語はＲｕｂｙ（Ｒｕｂｙ　ｏｎ　Ｒａｉｌｓ）を使用した。

生産性面の評価では、システム全体で１画面あたり８２ｓｔｅｐ、６．４時間という指標が得られた。また、品質面において、本システムの全社リリース前後を通して１件あたりのバグ修正・新機能追加工数は約４時間と一定であることから、アジャイル開発による保守性の悪化は見られなかった。

本発表では、大規模／日本向けアジリティ開発手法「ReeL」について紹介する。ReeLは、日立システムアンドサービスが開発した要件変更に柔軟に対応するための開発手法である。

現在、日本国内の大規模システム開発では圧倒的にウォーターフォールプロセスが普及している。しかし、昨今アジャイルプロセスへの関心が再び高まりつつある。この背景には、これまでアジャイルプロセスは、小規模システム開発に適していると考えられていたが、海外では多くの大規模システム開発での成功事例が大きな影響を与えている。さらに企業の開発コスト削減と短期リリースに対応するための新たな開発プロセスとして注目されている。

日立システムは、アジャイルプロセスがブームとなり始めた2002年から社内システム開発を中心にアジャイルプロセスの評価を行ってきたが、アジャイルプロセスの適用は小規模システム開発が中心であり、大規模システム開発にはウォーターフォールプロセスをベースとしてきた。一部のプロジェクトでは、テストファーストなどアジャイルプロセスのプラクティスを部分的に取り入れたブレンド型のプロセスを適用した実績もある。

しかし、現状のウォーターフォール型の開発手法では複雑化したシステム要件の早期確定や世の中の変化スピードに対応するには限界があった。そのため、「大規模システム向け日本版アジャイルプロセス」の開発研究を行い、当社の標準開発プロセスのひとつとしてアジャイル開発手法を追加することとなった。

開発に当たっては、現状のアジャイルプロセスの大規模システム適用時の課題と日本文化の課題を洗い出し、海外の大規模アジャイルプロセス成功企業の視察とアジャイルプロセス先進企業からのコンサルテーションを受けながら行った。

本発表では、大規模システム開発に対応した当社のアジャイル開発手法についてプロセス、体制、契約とコスト管理、開発環境を中心に紹介を行う。

プロセスでは、大規模開発に対応するためフェーズを要求フェーズ、作成フェーズ、検証フェーズの３段階に分けながらも要件未確定部分の後送りと要件変更に柔軟に対応するようにした。

開発環境では、オフショア開発など分散開発でもクラウド環境を利用したセキュアな開発環境とコミュニケーションサービスを活用するようにした。現在は、本開発手法を実プロジェクトで適用中である。

本発表では、データの移動に基づいて機能規模を測定する手法であるCOSMIC法の概要を紹介するとともに、プロジェクトの生産性に影響を与える要因について述べる。さらに、そのようなプロジェクトの生産性に影響を与える要因が実際に生産性に影響を与えるかどうかを確かめるために、開発に要した労力を機能部分と作業種別の2つの観点で分類して記録した。その際に、直接的にソフトウェアの機能と対応しない開発作業をカバーするために、作業は以下の3種類に大別した。

□画面、バッチ処理、ユースケースなどのエンドユーザ視点での機能（アプリ固有機能）
□複数のアプリ固有機能から呼ばれる画面やバッチなどの共通機能（アプリ共通機能）
□ソフトウェアの機能に直接関係しないプロジェクト管理等の作業（プロジェクト共通）

さらに、ユーザインターフェース（UI）の難易度や実装技術の違いによる影響を調べるため、アプリ固有機能はUI部分（UI）、UI以外の部分（非UI）、それらの両者のどちらとも分類できないもの（どちらでもない）に作業を細分化した。

これらの分類に基づく労力の測定とCOSMIC法による機能規模測定値を用いて、ビジネス用ソフトウェアを開発する5つのプロジェクトを測定/分析した。今回測定したプロジェクトのプロフィールを以下の表に示す。

プロジェクトID	開発種別	処理の種類	開発プロセス	協力会社さん
A1	新規	オンライン	進化型	国内
B	新規	オンライン+バッチ	インクリメンタル	国内
C	新規	オンライン	ウォーターフォール	国内
A2	改修	オンライン	進化型	国内
D	新規	オンライン+バッチ	ウォーターフォール	国内+オフショア

これらのプロジェクトの測定/分析の結果、以下のような要因が生産性を大きく影響している可能性があることが分かった。

会議には、情報伝達、意思決定、知恵の創出などの重要な機能がある。また、あらゆる業種や業務において様々な会議がある。進捗管理、レビュー、朝会、お客様との折衝など、仕事における会議時間の割合は大きい。その一方で、会議が発散する、結論が出ないなど会議の不満は多い。しかし、不満は抽象的で、どれほど発散し結論が出ないのかについて具体的な把握や比較が難しい。

会議の不満を解消するために、遠隔地を結ぶシステムやデータ共有システムなどのツールや会議の手順を改善するためのファシリテーションなどの技術があるが、ツールや技術が用いられても、会議の不満は絶えない。また、従来のツールや技術は会議中の時間や手順といった形式的なプロセスに着目するものが多く、出席者の習慣や心理など無形のプロセスや“人”そのものに着目した方法は少なく、実用化はされていない。

そこで、文化人類学における現場観察法であるフィールドワーク、点と線のつながりを視覚的に分り易く可視化する方法であるネットワーク分析、ありのままの言葉を基に背景にある意味を把握する談話分析を応用し、会議スタイルを人間を中心に可視化する「会議フィールドワーク」をデザインした。

「会議フィールドワーク」は、会議を価値ある時間に変え、協力と知恵の統合の場とすることを目的に会議の改革を支援することをねらいとしている。

本研究では、会議フィールドワークの基となった先行研究であるフィールドワーク、ネットワーク分析、談話分析について解説し、それらの長所を生かし短所を補った経緯を説明し、実際の現場に適用した事例を紹介しながら効果を議論する。

日立ソフトでは、開発要員の安定的確保と開発コスト低減を目的に、２００３年に中国とベトナムに開発センタを開設し、オフショア開発を実施している。オフショア開発の拡大と生産性向上のため様々な施策を推進中だが、２００８年度には「パートナリンクサービス（PLS）」と呼ぶコミュニケーションツールを開発･導入し、当ツールの活用によってオフショア開発プロセスの大幅な改善を実現した。

当ツールの特長、ツール活用によるプロセス改善事例、改善効果について報告する。

１．パートナリンクサービス（PLS）の特長
当社のIT基盤サービス商品（SecureOnline）、国際専用線サービス、各種生産性向上ツールを組み合わせたネットワークベースの統合開発環境であり、国内・オフショア分散開発の生産性を飛躍的に向上させることを狙っている。次の特長がある。

（１）セキュリテイ強化
・開発情報は国内のデータセンタで安全に管理
・オフショアからはシンクライアントと専用線経由で利用

（２）コミュニケーションツール整備
・電子ボード、Web会議ツールを活用した遠隔会議（案件説明、進捗確認、レビュー等に活用）
・開発管理情報のリアルタイム共用（進捗･品質・懸案管理情報等）
・実現が困難だった結合テスト作業のオフショア化（テスト環境共用、テスト自動化ツール）

２．PLS適用によるオフショア開発プロセスの改善

（１）従来のオフショア開発
国内とオフショアの双方に開発環境を設置していたため、開発情報の転送待ちや更新の同期ズレ、仕様説明（オン→オフ）や結合テスト（オフ→オン）での要員移動などのオーバヘッドがあったのが実態。コミュニケーション品質に起因する効率低下もあった。

（２）PLS適用による改善
セキュリテイを確保しつつ、開発情報のリアルタイム共用を実現するため、従来のオフショアオーバヘッドを解消。 オフショア開発の計画段階から完了まで、国内・オフショア間のコミュニケーションプロセス全般の改善が図れる。

３．適用事例
PLSは２００８年度後半に導入、２００９年度末時点でオフショア開発の約２０％に適用している。三つの事例を紹介し、プロセス改善の具体的内容、改善効果について紹介する。

１．セキュリティ強化による金融系業務ソフト保守作業をオフショア化

２．結合テスト作業のオフショア化、及び、自動化

３．コミュニケーションツール活用による国内・オフショアでの同時並行開発（スパイラル開発）

以上

【はじめに】 開発コストの削減や開発要員の確保のために、オフショア開発を導入・推進している企業が増えている。しかし、様々な問題に遭遇している。特に、品質に関するトラブルについて課題として挙げる企業は多い。

【解決したい問題】 従来、、「テスト設計ガイド」「テストケースチェックリスト」などのガイドラインを作成していたが、想定したとおりの効果が得られていない。その原因として三つ考えられる。 １．テストケースを作成する手順が定義されていない。 　→　テストケース作成は個人のスキルと経験に依存しており、組織として手順を定義していない。 ２．テストケースとして挙げるべき観点が分からない。 　→　テスト技法の習得以前に、テストすべき観点が整理されていない。そのため、テストケースレビューに工数がかかっている。 ３．不具合情報が整理されていない。 　→　不具合情報を蓄積しているが、テストケース作成に活用していない。

【問題に対する施策】 上記の課題に対して、以下の施策を実施しオフショアにおけるテストプロセスの改善を図った。 １．テストプロセスのＷＢＳを作成した。 　→　既存のＷＢＳに比べ、「関係者との合意」と「テスト設計」に関するタスクを充実させた。 ２．テスト観点ツリー＆リストを作成した。 　→　テストすべき箇所をツリーとリスト形式でまとめた。 ３．不具合推測リストを作成した。 　→　過去のプロジェクトの不具合票を分析し、多くのプロジェクトで散見される不具合をまとめた。

【特に工夫した点・主張したい点】 １．５アクティビティ４８タスクを定義した。「関係者との合意」は過去のオフショア開発でのエッセンスを盛り込み、「テスト設計」ではテスト観点を用いた設計手順を定義した。 ２．テスト観点として７７観点を用意し、テスト初心者であってもテスト観点漏れが少なくなるようにした。テスト観点リストとして８９０個用意し、テスト観点とテストケースが紐付くようにした。 ３．よくある不具合を７４５個用意し、不具合情報を整理していないプロジェクトでもエラー推測によるテストができるようにした。

【過去の発表内容との違い】 JaSST'10 Tokyoでは試行途中の発表であった。本稿では、試行結果を踏まえた考察を述べる。

2007年度下期より、ISO/IEC27001（ISMS※）の認証取得活動を担当し、2008年度に本社地区システム部門10部署（430名）で認証取得、2009年度には支社・支店を含めた部門全体23部署（1022名）へと拡大認証の取得を実現した。

情報セキュリティは、システム開発における品質の一部であるという思いで取り組み、2年間の活動でISMSの理解が深まった。そのなかで、情報セキュリティとソフトウェアプロセスは別物ではなく、ソフトウェア開発業務の重要なプロセスのひとつであるということを確信した。

当社システム部門では、1995年にISO9001（QMS※）を認証取得して以来のマネジメントシステム（以下、ＭＳ）認証取得であり、ISMSの活動をきっかけに、QMSの品質向上（ソフトウェアプロセス改善）活動活性化への橋渡しをしたいと考えてきた。別物のように見えるISMS、QMSそれぞれのＭＳを有機的に統合して、ソフトウェアプロセスを自律的に改善できる組織へとステージアップさせる。具体的には、ＭＳを統合する活動に結びつけることを目標としてきた。

近年、ＭＳの統合運用を行う組織が増えてきているが、会議体や内部監査、審査、手順書などの共通部分を統合して、効率化やコスト削減を図り、現場の負担を軽減することが主な目的になっているように見受けられる。もちろん、現場の負担軽減は必要であるが、さらに現場の本業そのものの改善に資することができれば、全員参加でのプロセス改善活動を目指すことができる。全員が参加するためには同じ土壌で品質カルチャーを醸成することが必要であるとの思いから、ＩＳＭＳ活動と並行して「品質管理技術講座」と「品質向上のための人間力醸成講座」を導入し、人材育成も図ってきた。

2年間にわたるISMSの認証取得活動は完遂し、統合に向けては道半ばであるが、今後のロードマップも見えつつある。ＩＳＭＳの認証取得活動だけでなく、ＭＳの統合を活用し、ソフトウェアプロセスを継続的に改善できる組織を目指した活動を是非ご紹介させていただきたい。

プレゼンテーションの概要の一部を以下に列挙する。
・ＩＳＭＳ活動1年目とソフトウェア品質向上のための種まき
-複数のＭＳを適用している現場の負担を軽減する方策
-ソフトウェアプロセス関連の要求事項が多い、ＩＳＭＳとＱＭＳの高い親和性
-改善の土壌醸成のための品質教育導入と人材育成
・ＩＳＭＳ活動2年目と統合に向けたソフトウェア品質向上への芽吹き
-マネジメントシステムの統合化と、ソフトウェアプロセス関連の要求事項の活用
-ISMSの特徴である、リスクアプローチをQMSへ適用
-品質教育の本格導入と新規講座の投入で、統合に向けた土壌の醸成
・ISMSとQMS統合に向けた今後のロードマップと課題　等

※ISMS:Information Security Management System（情報セキュリティマネジメントシステム）
※QMS:Quality Management System（品質マネジメントシステム）