F3a 7月27日 13:40〜14:25 会議室A
事例研究 講演概要(この枠部分のみ)をダウンロード
清水 浩行
株式会社三菱総合研究所

情報技術研究センター

研究員

業務システムのユーザビリティ評価と品質向上に関する取組み
講演概要

インターネットサービスでは、システムのユーザビリティが来訪者数や売り上げに直結することが広く認知され、ユーザビリティテストやユーザビリティチェックシート等が開発されている。近年では使いやすさだけでなく使ったときの印象全体を考慮する「ユーザエクスペリエンス」という概念も重視されつつ在る。一方、業務システムのユーザビリティはこれまで軽視されてきた。その要因は情報システム部、システムインテグレータ、エンドユーザそれぞれに由来する。しかし、業務システムで適切にユーザビリティに配慮すると作業効率が上がりコスト削減につながる事例や、逆にユーザビリティが悪かったために大きな事故となってしまった事例は多く、筆者らは業務システムに対してもユーザビリティを配慮すべきと考えている。

このような背景のもと、筆者らは業務システム向けのユーザビリティチェックシート「UxDux」を開発したのでその概要を報告する。業務システムを対象としたユーザビリティ評価手法の研究はこれまであまり行われていない。本手法では業務システムのユーザビリティを7つのカテゴリに分け、評価対象システムの成績を「見える化」することができる。また、採点結果に応じて改善方法の案を提示することもできる。

本手法を実システムに適用した事例として、3事例を紹介する。設計段階のシステムに適用した事例では、本手法がユーザビリティ改善に有効であった。電子申請システムに適用した事例では、評価者やカテゴリごとの評価結果のばらつきを評価した。3つめの事例では、本手法を用いずにシステム改善を行ったシステムに対し、改善前後に対して本手法でユーザビリティチェックを行った。評価者数が少なかったため統計的に有意とはならなかったが、改善後のシステムの方が良い評価となることが確認された。

現在は本手法の有効性を定量的に示すため、これまでよりも多くの評価者によって評価を実施し、評価のばらつきに対する対応策を検討している。また、コスト削減や事故件数の減少など、ユーザビリティ改善効果の分析を進める予定である。

F3a 7月27日 13:40〜14:25 会議室A





F3b 7月27日 13:40〜14:25 会議室B
事例研究 講演概要(この枠部分のみ)をダウンロード
小金澤 純
富士通エフ・アイ・ピー株式会社

ICTソリューション本部 公共社会システム事業部 医療システム部

プロジェクト課長
チームによる保守業務改善の取組み
〜保守業務の『見える化』〜
講演概要

電子カルテや医事会計などの病院システムの保守業務において、これまでは各顧客担当SEによる属人的な対応が多かったため、
(1)SE間の作業負荷の偏り、
(2)保守作業の品質・進捗のバラつき、
(3)情報共有不足による保守サービスの品質低下・作業効率低下
などの問題が起きていた。

これらの改善策として保守業務の体制・方法を根本的に見直し、属人的対応からチーム対応への転換を図った。その一つの手段として、リモート接続を最大限に活用することとした。

このリモート保守改善の取組みにおいて3つの成果を得ることができた。1点目はリモート保守による顧客システム監視を継続実施することが、予防保守の1手法として確立できた。2点目はリモート接続記録ツールを新たに開発導入したことにより、作業状況の収集・分析が容易になり、状況をデータとして可視化(『見える化』)することが可能となった。3点目はプロジェクトウェブを活用した保守情報の共有化により作業の標準化・効率化を図ることができた。

今後は、保守作業を通じて得られた情報を分析し、予防保守対策・保守実績報告等を顧客に提示することで顧客満足度の向上や保守契約交渉に活用していく。

これらの取組みは、パッケージの種類や業種・部門を問わず、リモート保守サービス全般の品質向上と作業効率化に対し役立つと考える。

F3b 7月27日 13:40〜14:25 会議室B





F4a 7月27日 14:40〜15:25 会議室A
事例研究 講演概要(この枠部分のみ)をダウンロード
清 雄一
株式会社三菱総合研究所

情報技術研究センター

研究員

インシデントデータを活用したプロセス改善に向けて
講演概要

毎月100件を超えるシステム障害(インシデント)が全社で起きている。各インシデントに対して暫定対応や恒久対応は実施しているが、似たようなインシデントが継続的に発生してしまっている。各インシデントへの個別対応のみではなく、開発プロセスや運用プロセスそのものを改善する必要があると考え、プロセス改善のためのプロジェクトを立ち上げた。

今までに各インシデントの発生原因を記載したインシデントデータを6768件収集しており、プロセス改善のためにこのデータを利用できると考えられる。しかし現状はあまり活用されていない。発生原因は自由記述であり、数千件の自由記述のデータを読み込むことは現実的ではないためである。また、仮に各インシデントを逐一読み込み、それぞれに対してプロセス改善策を考えたとしても、全体を見渡した最適な改善を策定することができない。一方、インシデントデータには「表層原因区分」および「深層原因区分」をそれぞれ20項目程度から選択させ記載している。各インシデントがどのような原因で発生したかの大まかなカテゴリはわかるが、項目の抽象度が高過ぎ、具体的な対策案は見えてこない。


このような状況を踏まえ、本プロジェクトでは、共通の対策や対策方針を立てることができるほど詳細な原因区分を定義し、各インシデントに対してできるだけ機械的に精度よく付与することを目指している。詳細な原因区分のレベルで同一のインシデントの集合を抽出することにより、複数のインシデントを見渡した、より最適なプロセス改善策を策定できるようになる。また、プロセス改善策は部署ごとに策定するものとする。部署ごとの背景や環境等も考慮する必要があるからである。

まず20件のインシデントを読み込み、40種類程度の原因区分を定義した。原因区分の洗い出しのためには、さらなるデータ解析が必要であるが、人手の作業には限界がある。日本語解析ツールを利用し、インシデントの発生原因を端的によく表すキーワードの抽出技術を開発している。

また、各インシデントに対する原因区分の機械的な付与にあたっては、テキストマイニング技術を利用することにより、高速・高精度に実施することを目指している。新しい原因区分を機械的に付与する際には、現在既に付与されている原因区分を参考にする。しかし、原因区分が付与されているインシデント数は、全体の6768件に対し、わずか1542件のみである。特に部署ごとに見た場合、たとえば原因区分が付与されているインシデント数が50件以上の部署は、全29部署のうち、わずか7部署のみである。テキストマイニング技術を利用することにより、まず現状の原因区分を、未設定の各インシデントに機械的に付与した。その結果、表層原因が付与されているインシデント数が50件以上の部署は7部署から14部署に増加した。また、クロスバリデーションを実施したところ、80%以上の原因区分が一致しており、精度も高いと考えられる。


今後、新規の原因区分の定義を完了させ、各インシデントに機械的に付与していく。単語間の関係等のオントロジーを整備し、また、キーワード抽出手法の改善を行うことにより、マイニングの精度を高めるとともに、インシデントデータの更なる活用方法を模索していく。

F4a 7月27日 14:40〜15:25 会議室A





F4b 7月27日 14:40〜15:25 会議室B
事例研究 講演概要(この枠部分のみ)をダウンロード
村木 完多
株式会社 日立製作所

情報・通信システム社 プロジェクトマネジメント統括推進本部

企画員

仮想化技術を活用したシステム保守効率化施策の検討
講演概要

現在、弊社にて運用しているAシステムは、日立グループ内のシステム開発をサポートする基幹システムである。年々ユーザが増加しており、毎月1000を大きく超えるプロジェクトで適用され、毎日数千人が利用している。この利用増に対応するため、随時WEB/APサーバの増設を進めており、現在、9台のWEB/APサーバにて運用している。

本システム運用においては、システム保守作業の実施を目的として、月に1回日曜日を計画停止日としている。この日は、システムが全面停止するため、全ユーザが利用停止となる。運用者はこの1日の中で稼動中に実施できない保守作業を実施する。

こうした中で、多くのユーザからは月に1回のシステム全面停止についても短縮できないかという要望が多く寄せられている。また、運用者の中でも休日作業が必須となる状況が負担となっている。そこで、システム保守の効率化について検討を行った。

最近では、仮想化技術を本番環境に適用した事例を見かける機会も多くなってきた。現在運用しているシステムにおいても、テスト環境作成においてはサーバ仮想化によるメリットを享受しているが、本番環境においてはまだ有効な活用手段を見いだせていないのが現状であった。今回、仮想化技術を用いて、ユーザ視点、運用者視点双方でメリットが見込めるように、保守作業を効率化する方式をまとめたので、紹介する。

F4b 7月27日 14:40〜15:25 会議室B





S1a 7月28日 9:30〜10:15 会議室A
事例研究 講演概要(この枠部分のみ)をダウンロード
杉浦 聡
ヤマハ株式会社

半導体事業部商品開発部プロセス支援グループ

主任

簡易な調達先アセスメント方法の提案
- 共に成長する改善を目指して -
講演概要

リーマンショック以降、弊社ではコスト削減の観点から、開発に占める外部調達の割合が増えている。このことは、調達先の開発プロセスが製品の品質へ及ぼす影響が増していることを意味している。近年、調達に関する問題が散見され、製品の品質を維持するためにも、調達先の開発プロセスの成熟度を把握すること、更には調達先の成熟度を高めていくことが重要になっている。

調達先の開発プロセスを知るには、プロセスのアセスメントをすることになるが、本格的なアセスメントは準備から完了までにかかる期間も長く、アセスメントする側、される側ともに大きな負荷がかかる。

そこで、負荷を抑えた、簡易に実施できるアセスメント方法を検討し、試行した。アセスメントは、負荷を抑えるため、調査項目の数を絞り、各調査項目も簡単なものにした。また、調達先へのアンケートに1週間、現地ヒアリングに2時間、結果報告作成に1週間、その他準備、日程調整を含めて3週間〜1ヶ月程度で完了できるような工程にした。

調達先はソフト開発、ハード開発、ソフトウェアテストと多岐にわたることから、異なる業務内容の調達先に対して、同じ方法を用いてアセスメントを実施。試行の結果、以下のことが確認できた。

- 調達先のアセスメント結果と調達業務の質を比較したところ、関連があることが分かった

 これにより、アセスメントにより調達先のプロセスの評価が出来ていることが確認できた

- 期間は短いもので1ヶ月弱、実際にかかった工数は15時間程度

 アセスメントにかかる負荷を最小限に抑えることができた

- ソフト、ハードを問わず、同じ方法でアセスメントを実施し、評価できることが分かった


今後は、アセスメント方法の改善、結果の利用方法の検討を進め、調達先の開発プロセスと自社の調達プロセスを改善し、ひいては製品品質の向上につなげて行きたい。

S1a 7月28日 9:30〜10:15 会議室A





S1b 7月28日 9:30〜10:15 会議室B
事例研究 講演概要(この枠部分のみ)をダウンロード
矢島 彩子
富士通株式会社

フィールド・イノベーション本部 FI技術センター



人間科学と工学のアプローチによる要求獲得の質を上げるためのインタビュー手法の開発
講演概要

【概要】

システム開発プロジェクトにおける「要求獲得の成否」は、後続の開発工程に重要な影響を与える。要求獲得段階において、現場の業務を的確に把握すること、現場の人起点での行動や意識を理解することの重要性が問われている。要求獲得は、「業務遂行の目的を達成するために、システムやそれを使う人が現状どのように行っているか、どうあるべきかのニーズの把握」と考えられる。要求を獲得するためには、情報を受け取る側も伝える側も明確に”理解できるように表現される”必要がある。そのため、弊社のようなITベンダーでは、要求を「いかにして顧客視点で聞き出すか」が必要である。しかし、聞くことは属人的なスキルに依存しがちであり、聞くことから得られる情報の精度、粒度や内容の厚さに差が出てしまう(A Wolvin 1996)。そこで、本研究は誰でも、インタビューからできるだけ質の高い顧客の現状や問題意識など要求を獲得できるよう開発した「インタビュー・分析手法」を提案し、現場での適用例から、手法の効果を検証していく。

【開発したインタビュー・分析手法】

本手法は、社会学や人類学において、自身とは異なる文化背景における生活、慣習、文化をありのままに把握する「エスノグラフィー」と、「人」を情報処理の側面から、認知活動(知覚や記憶など)を予測し、解析する認知心理学の理論を組み合わせて、インタビューを体系化したものである(エスノ・コグニティブインタビュー)。できるだけ語る相手の観点や言葉を用いて、人、時間、空間など多面的な切り口で現状行動や問題意識について、相手の業務などに精通していない人でも、要求を獲得できるようにツールを準備することで、スムーズに聞き出しができる。1対1のインタビューで、1名あたり最大1.5時間で1回あたりのインタビューを完結できる。さらに、複数人のインタビュー結果を体系的に整理、分析し、要求の網羅性と集中度合い、ストーリー性等を確認・検証できるツールを提案する。

【本手法の特徴】

本インタビューの特徴として、

・顧客の現状や要求を獲得し、分析できることを前提としたツール類(聴き方の作法、エスノコグニティブインタビューの考えを埋め込んだ質問実施時に使う質問ワークシート、など)を整備し、インタビューを体系化したこと

・できるだけ語る人には短時間に記憶を想起しながら話してもらえる、人間関係軸、空間軸、時間軸 要求獲得に必要な仮説生成や検証が可能であることなどがあげられる。

【結果と考察】

本インタビューで獲得した内容を現場での適用例から抽出したノウハウをベースに、話の時制と業務プロセス、ステークホルダーなどの視点で検証した。その結果聞き漏れや解釈のずれを防止するだけではなく、予め質問文を提示するインタビューでは獲得できなかった、要求の背景やエピソードまで聞き出せることがわかった。

S1b 7月28日 9:30〜10:15 会議室B





S1c 7月28日 9:30〜10:15 会議室C
事例研究 講演概要(この枠部分のみ)をダウンロード
福田 朋紀
リコーITソリューションズ株式会社

リコーNBDセンター CPS開発部 第1グループ



人が作るソフト
〜経験的な開発手法の実践事例〜
講演概要

ソフトウェア開発は本質的に不確定な状況を制御しながら顧客満足の度合いを高めてゆくという側面を持つ。アジャイルと呼ばれる開発手法群には、ソフトウェア開発における経験的なアプローチを支援するものが多く含まれるが、実際のプロジェクトに適用する手順が存在するわけではない。

本論文では、コンシューマ向けのWebシステム(オンラインストレージサービス)を開発した事例の紹介を通して、経験的アプローチでプロジェクトを推進する際に重要となる点について述べる。

S1c 7月28日 9:30〜10:15 会議室C





S1d 7月28日 9:30〜10:15 会議室D
事例研究 講演概要(この枠部分のみ)をダウンロード
由崎 令子
三菱電機インフォメーションシステムズ株式会社

品質保証部 技術科



プロジェクト環境を考慮した設計品質評価手法についての考察
講演概要

下流工程(テスト段階)の品質評価方法は,過去の実績と経験から評価手法としてプロセスが確立されつつある.しかし,低コストでより良い品質のシステムを提供するためには,より上流工程からの品質確保が必要である.しかし,下流工程のテストによる検出障害をベースとした品質評価手法を単純に上流工程に適用しても,お客様との関係やメンバのスキルなどプロジェクトの環境に左右される要因が下流工程に比べ大きく,データの確度に懸念があり適切な品質評価を行うことが難しい.本稿ではプロジェクトの環境や特性に着目した設計品質の評価方法について,プロジェクトの環境条件を定量化した評価手法について提言し,適用結果について考察する.


【目次】

1. 問題提起(はじめに)

2. 品質評価の現状

  −レビューとテストの違い

  −フェーズと要求の安定度の関係

  −プロジェクト成果物に影響を及ぼす要因

3. 設計品質評価のプロセスと課題

4. プロジェクト環境を考慮した設計品質評価の提案

5. 設計品質評価手法の確立アプローチ

  −アプローチの概要

  −設計品質評価手法の確立

6. 設計品質評価手法の評価

  −第一次評価(完了プロジェクトでの適用)

  −第二次評価(進行プロジェクトでの適用)

7. 今後の課題(おわりに)

S1d 7月28日 9:30〜10:15 会議室D





S1f 7月28日 9:30〜10:15 会議室F
事例研究 講演概要(この枠部分のみ)をダウンロード
田中 満
NECシステムテクノロジー株式会社

ソフトウェアエンジニアリング推進部

センター長

知的技術の形式化による、SI開発業務の品質改善について
講演概要

1.背景

NECシステムテクノロジーは、首都圏及び関西圏を中心としたSI開発事業と製品開発事業があり、私が所属する組織はSI開発事業を担当している。その中で、私は30名のグループに在籍し、Javaを主要言語としたお客様システムの開発業務を担当している。本稿は、SI開発事業を通じ、開発業務での品質改善に向けた取組みと成果について発表する。


2.課題

当グループは、複数のお客様システムを同時期に、別々の地域にて開発しているが、いづれも低価格・短納期・高品質のシステム開発を行わなければならない。しかし、生産性/品質面に於いて、開発者によりバラ付きが発生し、特に品質面では、結合/総合テスト工程にて「単体テストにて改修されるべきバグ」が発生し、予定原価を超過する状況であった。

このような状況下、「人の課題」は、開発者の生産性と品質面での底上げと新規参入メンバのスムースな立上げであり、「物の課題」は、開発を支援するツールを使いたがらないメンバが存在していた。しかし、優秀な開発者ほど、独自にOSS等を調査し、日々改善し、ツール活用が当たり前と考えていた。「金の課題」は、開発予算がいづれも厳しく、開発を支援するツールを購入することは難しい状況であり、「情報の課題」でもあるが、OSS/技術情報等はインターネット上に乱立され、知らない情報は多数あり、同一のお客様システム開発者間の共有は行えても、他のシステム開発メンバとの地域を跨がった共有の難しさがあった。


3.対策と施策

投資費用を抑制し、効率的に要員育成を行う対策として、優秀な開発者の開発プロセスや活用ツール、技術情報等を形式化し、グループの標準開発基盤を整備・徹底活用とした。

「物の課題に対する施策」として、OSSの活用方法や活用シーン等を整備し、経験の浅い開発者でも活用できるようにガイド整備と勉強会を開催し、要員育成と活用徹底を図った。

「情報の課題に対する施策」として、優秀な開発者が日々アクセスしているサイトやOSS/トラブル情報等が掲載されているサイト情報を整理し、グループ共有技術サイトを構築した。


4.成果と適用効果

Java開発に於ける品質改善とSI開発業務毎の費用負担ゼロを狙い、OSS/内製にて構成した開発支援ツール群(機能数:10)を整備し、200プロジェクトに展開した。適用効果は適用プロジェクト平均、以下の品質改善が図れ、予定原価を超過するケースは低減した。

 (1)単体テスト後の移行判定バグ数が、KL当たり0.4件改善

 (2)システムダウンに繋がるバグを単体テスト完了時点にて10件以上摘出

 (3)開発環境がなくても品質状況が確認でき、管理者視点でのチェックが、いつでも可能。


5.まとめ

開発者個々の頭にある技術を形式化し、徹底活用することにより、各SI開発案件の品質改善が図れたことは大きな成果であるが、それ以上に、『個々の技術を結集し、開発プロセスを強化し続けることが重要』と共通認識でき、開発者の意識改革が行えたことが成果である。

今後、OSS継続調査と既存環境への組込、他開発工程/他言語への展開が重要と考える。

S1f 7月28日 9:30〜10:15 会議室F





S2a 7月28日 10:30〜11:15 会議室A
事例研究 講演概要(この枠部分のみ)をダウンロード
角野 幸子
NECシステムテクノロジー株式会社

第一ブロードバンドシステム事業部

マネージャ

「勝つんや活動」の発展
〜ビジョン共有と文化醸成〜
講演概要

対応プロジェクトも勤務地もバラバラなメンバが3年にわたり実践してきた活動「勝つんや活動 −強く楽しく挑戦する個人と組織つくり−」によって一体感をもちながら現場改善活動の当たり前化を実現してきた(2009年SPES発表)。その後この活動は「全員で勝つ」というゴールに向け次のステップへと発展し、自組織の文化醸成から会社全体への波及へと広がってきた。現場改善活動という直接的な活動から長期視点のゴールに向けどのように発展してきたかについてをご紹介します。

=ビジョンの共有=

現場改善活動は当たり前になったものの小さな成果の積み重ねや実質的な効化を実感できない中で改善活動の共有イベントに停滞感が出始めていた。そこで何のための活動なのかの根本的な意味をしっかり共有することを実施した。全員で勝つとはどういうことなのか?会社のビジョン、個人のビジョン、チームのビジョン、それぞれを摺り合わせてみて何が見えるのか?非日常に一旦身を置き、個々人のビジョン、チームのビジョン、会社のビジョンを映像を確認し、その後チームビルディングでチームとは何か?組織とは何か?を体感から感じとり、対話を通じてそれぞれの方向性を見つけアクションプランに落とし込んでいった。このような1年に一度のイベントにより、軸のぶれない活動に発展していった。

=文化醸成=

成果発表による情報共有とフィードバックは同様の施策や成果が増えるにつれ形式的になる傾向があった。そこで成果発表という形をやめ、自慢会というスタンスでの場としより本音でより具体的な情報の共有ができるようになった。この対話形式での意見交換は改善活動の成果共有のみならず予算キックオフの後の意見交換会や部会など会議の場でも応用され、短時間に楽しく効率よく具体的な情報共有が実践されるようになった。ワールドカフェ式の対話他東京大阪をTV会議で結んで一体感ある対話の場を創るなど毎回工夫がなされ、勝つんやによる組織文化が醸成されていった。また、現場改善活動という視点だけでなく「全員が勝つ」ための活動であれば良いとの発想で社会貢献活動やCS活動など活動の種類も広がっていった。

=組織をこえた発展=

外をもっと知り自分たちを知る、そして協働の輪をひろげていきたいという意思が芽生え自分たちの組織以外の部門や他社との意見交換会を活発に行うようになった。学びあうというスタンスで自分たちにない改善活動から学び自らの活動に活かしていくという流れが定着してきた。また協働として会社全体を活発化させようと働きかけ組織をこえた連携でのイベント企画を実施するようになった。

S2a 7月28日 10:30〜11:15 会議室A





S2b 7月28日 10:30〜11:15 会議室B
事例研究 講演概要(この枠部分のみ)をダウンロード
星野 武嘉
アヴァシス株式会社

開発・事業連携推進部 要素開発グループ

シニアマネージャー

派生開発における要求仕様書の品質向上活動
講演概要

当社では、20年近く組込みソフトウェア開発を行ってきているが、かなりの部分が派生開発といって良い。派生開発での要求開発は、2000年の前半に導入したUSDMという要求仕様の書き方をベースにしているが、10年が経過した現在でも当社の派生開発プロジェクトでは、未だに品質やコスト超過の問題を起こしている。このため、派生開発プロジェクトにおいて何が原因となって品質や生産性の悪化につながっているのかを調査し始めた。調査の結果、開発工程の上流で行われる要求開発や設計において実施するレビューが思うような効果を生んでいないことが分かってきた。これは要求開発で作成される要求仕様書が、日本語の文章として要求や仕様を記述しているため、レビューの方法やレビューアーのスキルによっては、要求仕様書の記述に存在する欠陥をうまく除去することができないためではないかと思われた。

本発表では、要求仕様書の品質とは何かを定義した上で、要求仕様書の品質向上施策を以下のように決定し実施した。

1.あいまいな文章の排除の実施

要求仕様書に記述される日本語のあいまい性を排除するために、文章をチェックするツールを導入してレビューの前に要求仕様書をチェックするようにした。これにより要求仕様書のレビューでは要求や仕様の本質についてレビューできるようにした。

2.トレーサビリティリンクを使った要求仕様書レビューの実施

派生開発の元になっている仕様書や設計書などを読んで、変更の仕様が元の仕様のどこに相当するのかを調べる際に、日本語の文章の類似度を使って記述場所を検索できるツールを導入した。この検索した結果をトレーサビリティリンクとして保存することにより、要求仕様書のレビューに利用して要求の漏れ・抜け・矛盾・ダブりを効果的に検出していくようにした。

3.要求管理の実施

Excelの要求仕様書は、作成者によっては日本語の文章の代わりとして画像を埋め込んだり、要求番号を文章に埋め込んだりして要求仕様を作成している。このため、要求仕様を文書として作成するのではなく、要求仕様の要素として管理するために、管理ツールを導入した。

これらの施策を実施した結果、要求仕様書のレビューにおいて欠陥除去率が向上し、設計工程の生産性が向上した。今後は、これらの施策を実施しているプロジェクトの終了を待って、プロジェクト全体の品質や生産性がどう変化したのかを分析することにする。

S2b 7月28日 10:30〜11:15 会議室B





S2c 7月28日 10:30〜11:15 会議室C
事例研究 講演概要(この枠部分のみ)をダウンロード
木村 めぐみ
株式会社オージス総研

技術部アジャイル開発センター



COSMIC法に基づくForce.com開発プロジェクトの生産性分析結果
講演概要

本発表では、まず、これまでの研究で行ってきたCOSMIC法に基づくプロジェクトの生産性分析手法について述べる。この中では、データの移動に基づいて機能規模を測定する手法であるCOSMIC法の概要を紹介するとともに、プロジェクトの生産性に影響を与える要因について述べる。さらに、そのようなプロジェクトの生産性に影響を与える要因が実際に生産性に影響を与えるかどうかを確かめるために、開発に要した労力を機能部分と作業種別の2つの観点で分類して記録している点について述べる。つぎに、実開発プロジェクトを測定した結果をもとに画面機能の生産性や労力などの測定分析値を比較し、画面生産性に影響を与えた要因を分析する。

今回、測定分析結果を紹介するのはForce.comで開発を行った2つのプロジェクトである。この2つのプロジェクトは開発期間が2.5カ月、開発要員が2名という短期間少人数開発であった。これらのプロジェクトの画面生産性を、過去に測定した他のプロジェクトの画面生産性と比較し、さらに開発に要した作業時間や機能毎の分析値の比較を行って、画面生産性に影響を与えた要因を分析した。

その結果、Force.com開発プロジェクトは他のプロジェクトより画面生産性が高いことが分かった。また、Force.comで開発した画面の生産性は画面の処理形式(マスタ管理系、参照系、更新系)によってバラつき、さらに類似機能の開発経験やForce.com開発の習熟度が生産性に大きく影響することが分かった。そして、更新系画面の生産性は画面部品の連動や画面連携など作り込みの度合いによってバラつく事が分かった。

これらの測定分析結果から、Force.com開発の画面生産性が高い要因は以下であると考える。

・フレームワークとサービス

 Force.comを利用した画面開発方法によって実装が効率化した

 Force.comアーキテクチャを利用によって設計労力が減少した

・類似機能の開発経験と習熟度

 類似機能の開発経験があったり、Force.com画面開発に慣れることで開発が効率化した

また、以下の要因が画面生産性に影響を与えたことが分かった。

・画面の処理形式に関わる作り込み度

・類似機能の開発経験

・習熟度

S2c 7月28日 10:30〜11:15 会議室C





S3a 7月28日 11:30〜12:15 会議室A
事例研究 講演概要(この枠部分のみ)をダウンロード
竹下 千晶
株式会社デンソークリエイト

プロジェクトセンター 現場改善推進室

デスク

トレーニング指向アプローチによるプロセス改善
−現場のキーパーソンを育てる「現場SQA」方式−
講演概要

デンソークリエイトでは、2006年より「トレーニング指向アプローチによるプロセス改善」に取り組んできた(SPES2007〜2010で発表)。本稿では、その中核に置いている「現場密着型・支援型SQA」の仕組みと、その機能によって現場のキーマンを確実に育てる「現場SQA」方式とその効果について発表する。

(1)背景

1996年頃よりソフトウェア業界の先駆けとなり、優秀なプロ集団となるべくしてトップダウンで始まったプロセス改善は、厳格なプロセス定義とその遵守を強いるあまり、「やらされ感」のもと、形式的・表面的な活動になり、現場は疲弊していた。同じ失敗を繰り返さない思いで活動する中で、プロセス改善の本質が人を育てることであると気づき「トレーニング指向アプローチ」と名付けた仕組みを構築してきた。日々の仕事の中で人を育てるためには、現場目線を持ち、現場のための支援を行うことがポイントと考え、一般的なSQA機能より幅を広げた現場密着型・支援型SQAを考案した。

(2)失敗させないための仕組み

過去の失敗の大きな要因の1つは、表面的・官僚的なプロセス遵守の強要であると考えた。現場は、活動や改善推進チームに対する不信感や誤解でいっぱいになっていた。それを打開し、現場のためになり、現場が嬉しい改善活動にしていくために、信頼される改善推進チームに変えることを考えた。

これまでの失敗を踏まえて、信頼される改善推進チームに必要な要件は「現場の本当の事実を知り」、「現場と一緒に汗をかき」、「高い視点で足は地に置いた判断ができる」ことであると考えた。それを実現する組織として、それらの要件を満たす三層構造から成る「現場密着型・支援型SQA」を構築した。

(3)課題

SQAの構造は決まったが、三層構造の1つである、現場のPMに密着して支援をする機能(2次SQA)に必要な人材確保の目処が立たなかった。信頼されるSQAとなるには、現場が”認める人”つまり”優秀な人”である必要がある。

しかし、適任となる”優秀な人”は少なく、かつ、現場でも手放せない人ばかりである。現場のためのSQAを機能させるためには、現場から”優秀な人”をSQAに持ってくる必要がある。しかし、”優秀な人”を抜いてしまうと、現場が回らなくなる。現場のためにと言って”優秀な人”をSQAに集めることが、逆に現場の不満となるのではないか。そのような矛盾が想像され、葛藤し、2次SQAの人材確保に悩んでいた。

(4)優秀な人を育てる

”優秀な人”が少ないからSQAの数になるし、SQAに持ってくるにしても対象者が少ない。”優秀な人”が多ければ解消するはずなので、なぜ少ないのかを考えてみたところ、若い時に”優秀”として期待されていた人が、期待通りには育っていないことが少なくないことが分かった。若い時の優秀は、技術的な側面が強く、技術力があるが故に、担当範囲内ではマネジメント力もあるように見えてしまう。しかし、PMになると技術的に経験したことがない範囲も見ることになり、技術的知識や経験ではカバーしきれない本来のマネジメント力の真価が問われることとなり、突然破綻しやすいことが分かってきた。また、本人も回りも”できる”と思ってしまうため、自ら学ぶことも怠り、周りも指導しない。優秀な故に、学ぶ機会を逸してしまっているのではないかと考えた。そこで、現場にいながらSQAを経験することにより、PMとしての業務を疑似体験し、スキルを身につける「現場SQA方式」を考案した。「現場SQA方式」はPMとしての疑似体験だけでなく、視点の変化や担当業務との兼務という制約の中で活動することにより、更にマネジメント力をのばせる有効な方式であることにも気づいた。

「現場SQA方式」は、現場SQA担当者にとっては優秀に育ち、SQAにとっては優秀な人材が確保できて現場の支援ができるだけではなく、現場の上司にとっても、自分の配下に置きながら優秀な人を育てることができる、という三者にとって嬉しい「一石三鳥」の仕組みとなった。

(5)効果の確認

全PMに対して実施する内部アセスメントではモデルに基づき診断することによりPMやプロジェクトの水準を定量化できる。

PMになる前に現場SQAを経験したメンバは、PMになった時に、同時期にPMになった他のメンバと比較すると高い水準を得られた。また、本人も感覚でも有効性が示されている。また、現場SQA方式の運用当初と比較すると、課題・問題を抱えるPMの割合が10%減少すると共に優秀なPMは倍増し、全体の半数になった。

S3a 7月28日 11:30〜12:15 会議室A





S3b 7月28日 11:30〜12:15 会議室B
事例研究 講演概要(この枠部分のみ)をダウンロード
位野木 万里
東芝ソリューション株式会社

IT技術研究所 研究開発部 システム開発・構築技術ラボラトリー



要件定義の生産性を向上させるための最適化への取り組み
講演概要

要件定義においては,要求獲得,要求記述,要求検証,要求管理のプロセスで構成され,さまざまな研究成果が提供されている[1].例えば,変更要求を意識した要求獲得計画の立案に対しては,要求の成熟度に着目したPRINCEモデルが提案され,要求獲得計画の立案に貢献しつつある[2].

著者の所属する組織においても,PRINCEモデルを用いて,要件定義をスムーズに行うことに取り組んでいる.しかしながら,発注者からの要望を可視化しステークホルダ間で合意を得る要件確定プロセスにおいて,次のような課題に直面した.

(1) 要望の起票方法が属人的であり要望の理解・確認にコスト発生

(2) 要件化の方法が属人的であり,重要な要望と、運用でカバーできる単純な要望の区別なし

(3) 要件の定義時期が特定時期に集中し作業効率が悪化

そこで,上記課題の解決のために,PRINCEモデルが提供する要求の分類とそれに基づく優先度決定ルールを用いることで,要件定義プロセスを最適化する手法の開発と適用を試みた.(1)の課題に対しては,要望の仕様記述基準を定義した.(2)の課題の解決には,PRINCEモデルが提供する要求の分類に基づき,優先度ルールを定義した.そして,(1)と(2)の課題の対策に基づき要件定義の業務フローを可視化し,関係者に徹底することで(3)の課題に対応することを考案した.

上述した解決策を実システム開発に適用した.本解決策の実施後,要件確定のリードタイムを平均1.15日に,要件確定のコストを従来より80%削減することができた.リードタイム短縮および要件確定コスト削減を実現できたことから,考案した手法は有用であることを明らかにした.今回は要求の抽出数と時期を観測し,優先度を決定するための,共通のものさしとして,すでに実績のあるPRINCEモデルを活用した.考案した手法は,あらゆるシステム開発でも汎用的に適用と考えられ,知識継承にも貢献できる.今後は,複数のシステムでの観測を通してデータを蓄積し,本手法を継続的に改善していく.


【参考文献】

[1] 大西淳,海谷治彦,中谷多哉子,佐伯元司 ウィンターワクショップ・イン・金沢報告要求工学,情報処理学会研究会報告 56:87-89,2001

[2] 産学戦略的研究フォーラム,統合型要求プロセス研究プロジェクト,PRINCEモデル(The PRINCE Model)−統合型要求プロセスへのアプローチ−,2010

S3b 7月28日 11:30〜12:15 会議室B





S3c 7月28日 11:30〜12:15 会議室C
事例研究 講演概要(この枠部分のみ)をダウンロード
茨木 良昭
株式会社 オージス総研

技術部



オフショア開発における アジャイル開発のプラクティス
講演概要

本発表は、オフショア開発にアジャイル開発のプラクティスを導入する事例について紹介する。

コスト削減を狙い、製造業の工場を人件費の低い地域に移転するのと同じ考えで開始した日本のソフトウエア業界におけるオフショア開発は、すでに20年以上の歴史がある。これを実践する多くの企業で20%〜30%のコスト削減(※1)を実現している一方、言葉、文化、地理、組織構造の違いによって、オフショア開発の現場は多数の課題を抱えている。(※2)しかしながら、日本のソフトウェア業界は少子化や高齢化による人材不足に直面する中、開発リソース確保のため、またグローバルな事業展開するためにも、各ソフトウェア企業におけるオフショア開発のさらなる推進は不可避と考えられる。

アジャイル開発は90年代後半から米国で適用され始めた。現在では、欧米の多くの企業のソフトウェア開発の現場で適用されている。(※3)アジャイル開発によって、反復開発による完成品の市場投入の早期化や仕様変更への機敏な対応などがもたらされる。また、人材面では、チームの自己管理によって、生産性や品質の向上が期待できる。

オフショア開発とアジャイル開発の組み合わせについては、米国−インド間のオフショア開発ではすでに多くの事例がある。(※4)しかし、日本のソフトウエア開発業界では、アジャイル開発の適用は小規模案件とどまる傾向があり、大規模案件への適用はまだまだ進んでいない。これは日本のソフトウエア会社の組織の体質や多階層の請負契約による開発体制といった業界の慣行に、アジャイル開発が前提とする開発のやり方がなじみにくいことに原因があると考えられる。

オージス総研は2007年10月に、日中合弁の形で上海欧計斯軟件有限公司(SOT)を設立し、上海にオフショア開発拠点を持つに至った。SOTでは、パッケージ開発と顧客の社内情報システム開発という2種類の受託開発を行っている。

情報システム開発に関しては、日本で上流設計を行い、中国に詳細設計〜結合テストの工程を発注、日本で成果物を受け入れシステムテストを実施するという典型的なオフショア開発である。

パッケージ開発に関しては、SOTでSES契約、情報システム開発と同じ一括契約などのさまざまな受託形態を試みた。しかし、いずれも日本側での受け入れ時の検査で発見される問題が多かった。しかも、日本側が発見した問題に関してSOTとの間で責任の帰属をめぐって合意することが難しいこともたびたびあり、問題に対する修正作業がはかどらないこともあった。

こうした課題を解決するため、SOTが担当するパッケージ開発ではアジャイル開発のプラクティスの導入を図った。具体的には要求を優先順位付きの「チケット」と呼ばれる単位での管理、反復開発、テスト駆動、アジャイルテストといったプラクティスを導入した。また、コミュニケーションツールを複数活用しながら、チームの自主性を尊重する工夫することで、一般的なオフショア開発にありがちな「受け身の態度」即ち指示を末だけで、言われたこと以外のことはやらない傾向を排除した。

これらのアジャイル開発のプラクティスの導入を経て、チームの一体感向上、人員の定着率向上、パッケージの品質向上などの効果がもたらされた。

今後の取り組みとして、1)オフショア開発とアジャイル開発の相乗効果を定量化、また、2)パッケージ開発のみではなく、毎回まったく異なる仕様を扱う情報システム開発へのアジャイル開発のプラクティスの導入を予定している。


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

※2 特定非営利活動法人UMLモデリング推進協議会 オフショアソフトウェア開発部会、 『オフショア開発向けUML適用ガイドライン Ver2.0』、2008年6月

※3 VersionOne, 2010 State of Agile Development Survey Results

※4 http://www.martinfowler.com/articles/agileOffshore.html

S3c 7月28日 11:30〜12:15 会議室C