SPES2009 事例研究(公募)

F4a-F5a
  7月16日(木) 15時20分〜16時35分 みらいCANホール
【講演種別】 チュートリアル
【講演タイトル】
派生開発を成功させる方法
− XDDP の考え方について −
【講演概要】
派生開発とは:
一般に認識されている「保守開発」のプロセスが派生開発の要求を満たさないことによって多くの混乱が起きています。たとえば「部分理解」の状況の中での作業が強いられているにも関わらず、該当箇所を見つけしだいにソースコードを変更したり、新たな機能の追加を受け入れるための変更については注意が払われていません。具体的な変更方法も一つとは限りません。でも思い込みと勘違いの中では、不適切な変更作業も見逃されてしまいます。派生開発にまつわる多くの混乱は、こうした派生開発特有の問題に適切に対応されていないところから生じています。

XDDP の特徴:
このような派生開発の要求にマッチしたプロセス(開発アプローチ)として提案したのが「XDDP(eXtreme Derivative Development Process)」です。
XDDP は機能追加の要求と変更要求の2 つのまったく異なる要求に対して、要求とプロセスをマッチさせるために2 種類の異なるプロセスで対応して、プロセスに起因するバグを大幅に減らします。また追加機能や変更の要求仕様はUSDM の表記法によって、要求と仕様を階層で表現することで仕様のモレを防いでいます。
最大の特徴は変更仕様を扱うための「変更要求仕様書」を導入し、トレーサビリティ・マトリクス(TM)と繋ぐことで、ソースコード上で該当箇所を見つけしだいに変更しなくても済むようにしたことです。
機能追加においては、「追加機能要求仕様書」の他に、新しい機能を追加するという「変更要求仕様書」を同時に用意することで、追加機能を受け入れる方法を変更要求仕様で明らかにし、今まで追加機能の担当者任せになっていた部分をレビュー可能な状態にしています。
また、変更仕様を「ソースコード」のレベルで表現することで、ソースコードを変更する前の早い段階で、いくつか考えられる変更の実現方法をレビューすることが可能になります。この実現方法の事前の検討作業は、新規開発や機能追加では、設計プロセスの中で行われるレビューで実施していますが、「変更」には設計プロセスが無く、この種のレビューが実現しません。XDDP ではソースコードレベルの仕様を変更仕様として扱うことで、仕様レビューのタイミングで変更の実現方法を検討する機会を確保しているのです。
XDDP では、変更要求仕様書、TM、変更設計書の「3 点セット」の成果物によって、変更内容や変更方法について十分に検討された後に一気にソースコードを変更します。そのため、ソースコードの実装プロセスの生産性は100行/時間にも達します。これは従来の方法の15?20倍です。この生産性が根拠となって、合理的な成果物を作りな がら作業を進めることができるのです。

XDDP の効果:
XDDP は派生開発の要求にマッチしたプロセスと成果物の合理的な連鎖(開発アプローチ)を提供していますので、 プロセスに起因するバグのほとんどが解消します。実際、KLOC あたりのバグ発生率は従来方法に対して1/10にな ることも珍しくありません。  また、合理的なプロセスの他に、品質が向上していることで手戻り作業も大幅に少なくなり、事前に確保した工数 に対して、30%前後余る状態になっています。時には「?65%」というケースもあります。  この他、ソースコードを変更する期間が非常に短く集中していることと、事前に変更箇所が明らかになっているこ とで、「並行開発」や「五月雨開発」も可能になります。
【講演者】
清水 吉男   しみず よしお
株式会社 システムクリエイツ
代表取締役
【プロフィール】
1968 年からソフトウェアの世界に入り、フリーの立場で汎用機時代は企業の一般的なビジネスシステムやオンラインシステムを中心に開発に携わる。1977 年に組み込みシステムの世界に転向し, レジスタのクラスターシステムによる世界で最初の5万アイテムの単品管理システムやインクジェットプリンターなどを手掛ける。1983 年に株式会社システムクリエイツを設立。
1990 年にCMM との遭遇を機にそれまでの自身の成功事例をもとにして、要求の仕様化(USDM) や派生開発に特化したプロセスによる開発方法(XDDP) などを開発し、1995 年にプロセス改善のコンサルティングに転向。「QCD」の改善を目標にしたコンサルティング活動に入り今日に至る。
著書: 「SEの仕事を楽しくしよう」(SRC刊)
「要求を仕様化する技術・表現する技術」(技術評論社刊)
「『派生開発』を成功させるプロセス改善の技術と極意」(技術評論社刊)
「わがSE 人生に一片の悔いなし」(技術評論社刊)
F4b-F5b
  7月16日(木) 15時20分〜16時35分 イノベーションホール
【講演種別】 チュートリアル
【講演タイトル】
〜プロセス改善初級〜
「人間重視のソフトウェア・プロセス改善実践法 」
【講演概要】
初心者にとって、品質改善のためのプロセス改善を開始しようとしても、何からどのように開始すればよいのか、そのコツがなかなか分らないものです。
例えば、「プロセスとは何か?」、「何故プロセス改善が必要なのか?」、「どう取り組んだらよいのか?」等の疑問が湧いてきます。改善のモデルとして著名なCMMI(R)を紐解いてみても難解な文章が続いており、ギブアップされた方々も多いのではないでしょうか。
また、いざ改善活動を開始されても、組織の人々が動いてくれずに「動機付け」に苦労されている方々も少なくないと思われます。
かつて、私は品質問題に喘ぐ本部組織のプロセス改善に携わり、SI分野で日本初となるCMM(R)レベル5達成に導き、高品質を実現した経験があります(2003.9)。
本チュートリアルでは、初心者の方々を想定して「プロセス改善の必要性」、「プロセス改善にどう取り組むか」、「品質効果を得る仕組み考案のコツ」、「プロセス改善の実践ポイント」等について、実践事例を盛り込み丁寧に解説いたします。
また、プロセス改善活動を浸透させるための仕組み考案の秘訣である「人間重視のポイント」についても具体的な実践例により理解を深めていただき、初心者の方々に充分お役に立てる内容にしたいと考えております。

■主だった内容(予定)
第1章 何故、人間重視なのか
1. 改善活動の限界
2. プロセス改善と人間
3. 人間重視のプロセス改善の必要性
第2章 プロセス改善にどう取り組むか
1. トップダウン型プロセス改善の実践例
2. ボトムアップ型プロセス改善の実践例
3. 組織的プロセス改善への動機付け
第3章 組織的プロセス改善カルチャーの醸成
1. 品質カルチャーの高い組織にするには?
2. 組織的プロセス改善と能力成熟度モデル(CMMI(R))
3. 組織的プロセス改善への動機付けと実践ポイント
(R) Capability Maturity Model and CMM ,CMMI are registered in the U.S. Patent and Trademark Office.
【講演者】
関 弘充   せき ひろみつ
富士通株式会社
ソリューション事業推進本部人材開発部
シニア・レクチャラー
【プロフィール】
・1967年富士通入社.ソフトウェア検査部門を経てシステム開発部門で大規模システム開発のプロマネを担当(途上、未来工学研究所主任研究員)。
・近年、システム開発本部組織のプロセス改善に従事し(主席部長、品質保証部長)、SI分野で日本初のCMM(R)レベル5を達成(2003.9)、社長賞等を受賞(その後CMMI(R)レベル5)。現在、プロの育成並びにプロセス改善コンサルに従事.特に人的側面「人間力」にこだわった活動に注力。
・上級教育士、九大大学院非常勤講師、日科技連、日本テクノセンタ、TH企画、SRC講師。
・著書 「人間重視の品質マネジメント ソフトウェア品質保証システムの構築と実践」(SRC)他
・ 情報システム学会、日本品質管理学会、日本工学教育協会 各会員。
F6a
  7月16日(木) 16時45分〜18時00分 みらいCANホール
【講演種別】 チュートリアル
【講演タイトル】
アプリケーション開発の工業化への取組み
〜開発現場における継続したプロセス改善の実態〜
【講演概要】
弊社は会社設立以来、富士通のソフトウェア・エンジニアリングの実践工場を目指して活動している。開発におけるプロ集団を目指すことは当然であるが、本当の現場視点での技術開発、技術検証、開発技術マネジメントの方法論の確立など広い視野を指向し現場と一体となり改善を進めている。
弊社では、基本的な行動指針である「四つの約束事と六つの仕掛け」を掲げ、組織的に自律した改善活動定着に向けて、技術面だけでなく、開発専業会社としてのマネジメント、人材育成など総合的な意味での「工業化された開発会社」を目指し活動している。 今回は、「四つの約束事と六つの仕掛け」の単なる解説でなく、約束事と仕掛けを現場に浸透させ、改善活動につなげ、品質(Q)、コスト(C)、納期(D)を達成するための苦労も合わせて紹介する。
「四つの約束事」とは以下のとおりである。

1.人月でなく時間で考える
2.仕事票は毎日正しく記入する
3.データで議論する
4.決められた場所に決められた形で格納する

なんだこんなことか・・・・と考える方が多数である。しかし、ちょっと考えてみてほしい。開発の現場で、これらの当たり前(普通のこと)が当たり前にできないために、ソフトウェア開発は相変わらず「属人性への依存」体質から脱皮できず、「真」のエンジニアリングの実践ができないのである。
「六つの仕掛け」は私共が技術の深耕が必要だと考えているものである。

1.ファンクションスケール(FS:富士通が開発したファンクションポイントの簡易法)を活用した見積方法
2.作業プロセスを設計し、基準作業時間を設定する方法
3.短期開発実現のための、プロセスの分割と並行開発の方法
4.設計書の標準化
5.4に基く開発資産の自動生成
6.作業実績管理システム

これらを事例をベースに解説し、各技術が現場の改善努力により成長する経過もあわせ、できる限りデータ等も活用して説明したい。
トヨタ生産方式で重要なことは、改善の文化を現場に浸透させ、そして、人材が確実に成長し、ムダ・ムラ・ムリが排除され、QCDが達成できる(証明できる)ことである。
【講演者】
丸山 富子   まるやま とみこ
富士通アプリケーションズ株式会社
ソフトウェアエンジニアリングセンター
取締役 兼)センター長
【プロフィール】
主な担当業務:アプリケーション開発における見積問題をはじめ、製造プロセス、開発技術マネジメント全体にわたる技術、方法論の開発・導入に取り組む。また、ソフトウェア開発におけるトヨタ生産方式の積極的導入を推進。
経歴:富士通に入社後、CADシステムの開発に従事。次に、第三次金融オンラインシステムの開発において、協力会社様マネジメントおよび品質保証活動を担当。これらの経験をもとに、ビジネス分野におけるソフトウェア開発支援ツールの「企画・開発・保守・プロモーション」に従事。
2002年にJavaアプリケーション開発専業会社の設立と同時に移籍し、複数の開発プロジェクトを経験。その後、現場課題をソフトウェアエンジニアリングの観点から解決すべく現在にいたる。
F6b
  7月16日(木) 16時45分〜18時00分 イノベーションホール
【講演種別】 チュートリアル
【講演タイトル】
ソフトウェアプロセス「定着する・しない」の分かれ道
〜CMMIレベル5組織の分析からわかったこと〜
【講演概要】
ソフトウェアプロセス標準を作ったものの定着が進まない、現場に定着させるにはどうしたらいいのか?という悩みは、よく相談を受ける質問の一つである。ソフトウェアプロセスが定着する組織と定着しない組織には、成果はもとより取り組み方に大きな違いがある。CMMIレベル5達成をリードするとともに、様々なソフトウェア開発組織の課題解決に取り組んだ経験に基づき、2つのCMMIレベル5組織の実データによる分析結果を交えながら、これらの違いを以下の観点より解説する。CMMIレベル5組織データを使用する理由は、高成熟組織の方がプロセスの整備が進んでいるため、データの精度が高く、分析しやすいからである。最後に、組織にソフトウェアプロセスを定着させるための秘訣を議論する。
1.「データによる判断」 は正しいか
2.正しい「基準値遵守」 とは
3.「プロセスの網羅性」 をどう考えるか
4.「なぜなぜ分析」 の持つ意味
5.ソフトウェアプロセスを定着させるために
【講演者】
誉田 直美   ほんだなおみ
日本電気株式会社
コンピュータソフトウェア事業本部
上席ソフトウェアプロセス&品質プロフェッショナル、統括マネージャー
【プロフィール】
・ サーバ/メインフレーム/ストレージ等の基本ソフト/ミドルソフトウェアの品質保証およびCS向上に従事。 CMMIレベル5達成(2004年12月)を中心的な立場で推進。2007年より現職。
<社外活動> 日本科学技術連名 SQiPソフトウェア品質委員会 副委員長 等
<主な著書・執筆活動>
・ソフトウェア開発 オフショアリング完全ガイド(日経BP社 共著)2004年10月発行
・ソフトウェア品質知識体系ガイド -SQuBOK Guide- (オーム社、共著)2007年11月発行等
<受賞>  第4回世界ソフトウェア品質国際会議(4WCSQ)最優秀論文賞受賞(2008/9)
S2a-S3a
  7月17日(金) 11時40分〜12時45分 みらいCANホール
【講演種別】 チュートリアル
【講演タイトル】
10年後のソフトウェア開発プロセス
〜「良いソフトウェア開発プロセス」とは何か?〜
【講演概要】
30年近くソフトウェアの品質保証、開発、管理業務を担当してきた経験から、ソフトウェア開発プロセスの分野で、今後10年間、どのようなブレークスルーがありうるか、それも、そのブレークスルーを日本から発信できないのか、というテーマでお話します。
ウォータフォール型のプロセスモデルが提唱されてから、来年で40年。スパイラルモデルは約20年。エクストリームプログラミングなど、アジャイル手法が提唱されてからでも10〜15年が経過しています。アジャイル型の開発スタイルが他のモデルを駆逐するといった、一時の期待は遠くなり、現在でもソフトウェア開発の一線では依然としてウォータフォール型のプロセスが多く使われています。
これまでのソフトウェア開発のプロセスモデルの多くは米国が起源です。しかし、日本のソフトウェア開発現場での、ソフトウェア要求、ソフトウェア開発環境、プロジェクト管理のスタイルなどは、米国と大きく異なっています。ソフトウェアプロセスに対する認識が高まってきている今、ソフトウェア開発プロセスの分野で、日本の強みとなるブレークスルーを生み出すためにはどうしたら良いのか、どこから手をつければよいのかを講演の目標とします。
本講演では、さまざまなプロセスモデルの差異を強調する、またはいろいろなモデルから選択するというアプローチではなく、既存のモデルとは独立に、「良い開発プロセス」または「悪い開発プロセス」というものがどのように定義できるかを示します。また、この考えに基づき、開発するソフトウェアの目的、特徴から最適なソフトウェア開発プロセスを導く方法を紹介します。
ソフトウェアプロセスのエキスパートが集う日本最大のイベントであるSPESの参加者と意見を交換し、今後のソフトウェア開発プロセスの進むべき道に対する共通認識を生み出すことを期待しています。
【講演者】
居駒 幹夫   いこま みきお
株式会社日立製作所
ソフトウェア事業部
主管技師
【プロフィール】
1980年に(株)日立製作所に入社以来、大規模ソフトウェアの品質保証、生産技術、プロセス改革業務に従事 
S5a-S6a
  7月17日(金) 15時10分〜16時15分 みらいCANホール
【講演種別】 チュートリアル
【講演タイトル】
工事進行基準
- プロジェクトマネジャーの実務
【講演概要】
プロジェクトマネジャー(以下PM)から見た工事進行基準と、その実務について整理を試みる。

会計基準(会社の会計ルール)の要請で、PMの仕事は増えることになるが、どこまでやらなければいけないのか。逆にそこまでやっていいのか、いけないのか。そんな疑問がたくさんある。このチュートリアルでは、その疑問にできるだけ回答すべく整理してみたい。具体的に言及する内容としては、会社の業務ルール(承認基準、契約書、購買契約など)に対するコンプライアンス、内部統制、関連する法規(SOX法、改正下請け法)などを取り上げ、PMがプロジェクトマネジメント規律(Discipline)として、それらにどう取り組むのかという視点で説明したい。
工事進行基準は会計のルールなので、コスト管理とそれにまつわるPMの仕事を整理し見直す、と言ってもいいかも知れない。さらにトラブルプロジェクトの場合はどのような対応が必要となるのかを考察する。

参照資料としてJISA発行の「情報サービス産業 工事進行基準適用マニュアル」(20-J002)を活用する。この資料は、とてもよく整理されていて工事進行基準に対しPMやPMO、品質管理、経理部門などサポート部門がそれぞれやるべきことを検討する際に最適のテキストになると考える。
【講演者】
高森 満   たかもり みつる
日本アイ・ビー・エム株式会社
グローバル・ビジネス・サービス リスクマネジメント
プロジェクトマネジャー
【プロフィール】
1988年日本IBM入社。建設業向け工事原価、経理システムの構築など業務パッケージの企画、開発、販売を担当した後、カスタム開発プロジェクトのプロジェクトマネジャーとして活動。1999年ごろからインターネットショッピングサイト構築や、Web/Java技術を利用した基幹業務構築などのプロジェクトのPMを担当、2005年CMMI L5 アプレイザルチームに参加、2006年以降はリスクマネジメントチームにおいてトラブル防止のための各種施策の展開、PM教育、啓蒙活動に従事している。
参加申込・問い合わせ