Software
Engineering
Center
Information-technology Promotion Agency, Japan

SPEAK-IPAプロセスコース

2010年10月1日

プロセスアセスメントモデルの活用...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

トイレが混んでいる場合は、別のフロアのトイレもご利用ください
建物の外へでた場合は、下でインターホンで入ってください。
喫煙は、部屋の...
目次

SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

1. 概要
2. 診断モデルの操り方
3. 演習の進め方

Copyright
2010.10.1 プロセスアセスメントモデルの活用コー © ...
SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

1.概要

Copyright
2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserve...
SE
C



Software Engineering
for Mo・No・Zu・Ku・Ri

13:30-13:35 会場の利用上の注意
13:35 – 14:00 概要説明
この資料
グループ分け
妥当性確認プロセス
プロジェクト管理プ...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

各自で設定してください。
想定:プロセスモデル(特にアセスメントモデル)を道具として操(あや
つ)る上で,何か1つ気が付く
自分たちの使い...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

プロセスモデル,プロセスアセスメントモデルを振り回して,書い
てある通りのことをやらせようとして困っている。
分けの分からない...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

モデルの背景,制約条件がモデルに書かれていない。
診断に時間と手間がかかる
書いてある通りのことをしていなくてもよいのは分かるが、...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

ソフトウェア設計も、モデルに基づいた診断も創造的な仕事を含んで
います。
創造的な仕事は、個人の能力によって、やり方は全く違います。
創...
SE
C



Software Engineering
for Mo・No・Zu・Ku・Ri

作業,手順,試験
作るもの
そこにあるもの
気が付かないもの(視点なので目に見えない)
人間の作業、手順,作業分担などを含むか含まな...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

プロセスの定義モデル(参照モデル)
プロセスの診断モデル(アセスメントモデル)
どちらも抽象度,粒度はさまざま

...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

ISO/IEC 15504で規定しているのは最低限のこと
規格適合は第1者(自己宣言),第二者(取引先の確認,第三者
(審...



視点2ではAはBの部分集合



Software Engineering
for Mo・No・Zu・Ku・Ri

視点1ではBはAの部分集合



SE
C

誤解:自分は正しく相手が間違い

Copyrigh...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

• 1つの用語を2つ以上の
意味で使っていないか。
– b: blue, bit
– 人間は文脈依存で理解
– コンピュータは場合による
...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

最適化

2,3は日本が弱い
4,5は欧米が弱い

4

確立

3

管理

2

実施

0

5

予測可能

1

実施してい...
SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

2. モデルの操り方

2010.10.1 プロセスアセスメントモデルの活用コー

Software Engineering Center

16




SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

2.0 診断モデルって何
2.1 プロセスの修整(tailoring)
2.2 プラクティス確認/代替プラクティス
2....


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

SPEAK/IPAとISOIEC 15504
診断モデル(1)
例題:ISO/IEC 15504 part5
診断モデル(2...
PEAIPAIIEC


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

NsolのSPEAKというモデルはISO/IEC 15504 Conformanceモデルです。
N...
IIEC



SE
C

t
Software Engineering
for Mo・No・Zu・Ku・Ri

ISO/IEC 12207 Software Life cycle Process を参照モデルにしている...
IIEC



SE
C

t
Software Engineering
for Mo・No・Zu・Ku・Ri

診断モデルでは修整の仕組みを陽に定義してない。
診断モデルの指標は、必須ではなく、診断員が参考にするもので...
IIEC



SE
C

t
Software Engineering
for Mo・No・Zu・Ku・Ri

診断モデルのプロセスの区切りで診断作業をする必要はない。
結果として報告する際の区切りであって、作業の区切...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

目的、目標によってやり方は千差万別である。
診断は監査ではない。
監査としてやることは可能。
監査と別にやるときは、監査がや...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

改善のために診断モデルを使いこなしてみる。
現場が深刻に受け止めている問題を解決しようと動き出してくれる。
現場が深刻な問題を一部の...


t
tailoring)

SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

仕立て屋さんのことを知ろう
デザイン画があります。デザイナが書きます。
型紙を作ります。型紙...
SE
C



Software Engineering
for Mo・No・Zu・Ku・Ri

既製服
S,M,L、LLなどに対応した型紙を作成
仕立て

型紙を起こすところから作成することもある
1つの型紙または可変型紙から作成

...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

http://ja.wikipedia.org/wiki/型紙
Copyright
2010.10.1 プロセスアセスメントモデル...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

細さに関する指示はある範囲ではすでに型紙にあります。
高さに関する指示はありません.
縦横比にあうものがあれば,伸縮できます。
柄を前...
SE
C

t(tailor)

Software Engineering
for Mo・No・Zu・Ku・Ri

型紙通りの大きさの顧客の場合は,裁断,縫製作業に進みます
型紙(モデル)を使って,型紙以外の大きさ,細さの...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

型紙の元になる設計をする専門家はいます。
プロセスモデルの基になるあるべき姿を設計する人はいますで
しょうか。...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

両方の経験がある人ならその人の頭の中で変換できる
大規模開発での指標(プラクティス)は小規模開発,特殊開発に置き
直さないと有効で...
SE
C



Software Engineering
for Mo・No・Zu・Ku・Ri

ハードウェアとソフトウェアの両方を設計している会社だからでき
る開発標準
5年ごとという目標が決まっている開発標準
100...
SE
C

water fall

Software Engineering
for Mo・No・Zu・Ku・Ri

3年,100人,1億円(100人が常時従事ではないため)
品質部門で次工程への進捗判定。
保留事項があっても先に進む...




SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

モデルに書かれているプラクティスは代表例
別のプラクティスで同じ成果があるのならそれでもよい。
代替のものを始めから認め...




SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

• どんな作業でも,目標のためにやらなければいけないことは,日
程,費用,品質などに対応して優先順位がある
• 日程が短い場合...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

論理回路設計の設計標準の運用例
STARC RTL設計スタイルガイド
各社の社内標準は,RTL設計スタイルガイドに優先順位付けして作る
よ...
例:MISRA-C

SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

RTL設計スタイルガイドのような命名規則,運用規則などがない
1998年版と2004年版の両方を並行して運用
それ以前の標準のコ...




SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

診断の方法には作業の一部に参加して,協力的に行う方法と,作業に
は参加せず,面談や文書調査による方法がある。
作業に参加する方法...





SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

調査対象の中に入って体験する
実際に体験してみると,外から見ているのとでは大違いのことがあ
る。
調査対象...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

内部の人に診断チームに入ってもらう
内部情報の確認,責任の所在の確認は内部の人だけで実施する
ことがある。
データ確認の横に情報責...




SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

作業責任者が明確になっていて,作業責任者が交代したら,引き継ぎ
があることが明確ならその作業責任者の署名で良いこともある。
面談の...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

文書で作業内容と作業責任が明確になっていて,関係者に周知してい
る。
文書で作業内容が明確になっていて,その都度責任者が明確になり,
関係...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

困ったことが起こったら,すぐに対応できる。
回避方法を示して,ひとまず困ったことを回避する。
解決方法を示して,解決に到達できる。
代替案...




SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

試験、文書化、レビュー、品質保証、プロジェクト管理、リスク管理
などの作業を分担しながら、診断結果を作成する...
SE
C



Software Engineering
for Mo・No・Zu・Ku・Ri

プロセス改善ナビゲーションガイド診断活用編の読み方
参考事例
参考文献

Copyright
2010.10.1 プロセスアセスメントモデルの...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

診断活用編の場合
知っているとよいこと:主な執筆者は3人
自社モデルを作った社内の改善の指導者
自社モデルも...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

一人1プロセスを担当して計画から報告までを実施。
他のプロセスの面談などに同席して関連する事項を聞き取る。
自分が関係者の場合には自分で依頼...
SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

3. 演習の進め方

Copyright
2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Re...
3. 演習の進め方

SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

演習資料は、3つを用意しています。資料でのプロセス名はIPASPEAKを想定しています。
1. 妥当性確認プロセス
2. プロジ...
進行例

SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

1. 参加者の仕事の内容とプロセスに対する理解を述べる自己紹介を実
施してください。
2. 仕事、組織、事業が異なる場合には、議論を何に絞る...
留意点

SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

1. 正解を求めるのではなく、やっていてよかったことを述べ会うよう
にしてください。やらずにうまくいかなかったことを述べてもかま
いません。...


SE
C

Software Engineering
for Mo・No・Zu・Ku・Ri

型紙 http://ja.wikipedia.org/wiki/型紙
パターンメーキング技能試験 http://www.fashionedu...
Upcoming SlideShare
Loading in …5
×

プロセスアセスメントモデルの活用 ー プロセス改善のモデルをあやつろう

324 views

Published on

プロセスの仕立て:修整(tailoring)は大事な技術である。モデルと現実との間を、対応付け(mapping), 仕立てという二つの手段をうまく使い分けることにより、現実に即して大事なことに焦点を当てることができるようになる。

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
324
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

プロセスアセスメントモデルの活用 ー プロセス改善のモデルをあやつろう

  1. 1. Software Engineering Center Information-technology Promotion Agency, Japan SPEAK-IPAプロセスコース 2010年10月1日 プロセスアセスメントモデルの活用 プロセス改善のモデルをあやつろう 工学博士・技術士(情報工学) 名古屋市工業研究所 小川清 Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center 1
  2. 2.  SE C Software Engineering for Mo・No・Zu・Ku・Ri トイレが混んでいる場合は、別のフロアのトイレもご利用ください 建物の外へでた場合は、下でインターホンで入ってください。 喫煙は、部屋の隅のドアの外で吸うことができます。 飲み物は自由にご利用ください。 携帯電話は無音でお願いします。 意見交換会を終了後に予定しています。お時間のある方はご参加くださ ると幸いです。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 2
  3. 3. 目次 SE C Software Engineering for Mo・No・Zu・Ku・Ri 1. 概要 2. 診断モデルの操り方 3. 演習の進め方 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 3
  4. 4. SE C Software Engineering for Mo・No・Zu・Ku・Ri 1.概要 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 4
  5. 5. SE C  Software Engineering for Mo・No・Zu・Ku・Ri 13:30-13:35 会場の利用上の注意 13:35 – 14:00 概要説明 この資料 グループ分け 妥当性確認プロセス プロジェクト管理プロセス+リスク管理プロセス 品質管理プロセス+測定プロセス 14:00 グループ議論:休憩はグループごとにばらばら 14:00-14:20 自己紹介と役割分担 リーダ、書記、発表者 14:20-14:30 資料の説明 14:30-16:30 議論 16:30-16:40 まとめ 16:4017:30 グループ発表と講評、グループでのふりかえりなど 発表内容: 検討した内容の報告 今日気がついたこと アンケートを実施 講評担当: 17:30-外での意見交換会(任意) Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 5
  6. 6.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 各自で設定してください。 想定:プロセスモデル(特にアセスメントモデル)を道具として操(あや つ)る上で,何か1つ気が付く 自分たちの使い方が当たり前だと思っていたけど,自分たちのよ うに使いこなしているところが無いらしい。 え,他社ではそんな使い方してたの? 業界が違うと全然違う使い方しているけど,自分たちの使い方本 当にこれでいいの? そんな使い方をしては駄目だと教わったけど,理由は考えたこと がなかった。 結局無駄なことしていて道具を使わない方がいいんじゃない。 素手(自分の頭)だって,立派な道具 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 6
  7. 7.  SE C Software Engineering for Mo・No・Zu・Ku・Ri プロセスモデル,プロセスアセスメントモデルを振り回して,書い てある通りのことをやらせようとして困っている。 分けの分からない人間が来て,いいかげんな判定をしていく。 経験がない人に説明するのに無駄な時間を取られるのはうんざり。 経験があれば見なくてもわかるはずのものを見たがる。 モデルに書いてあることが、用語定義、制約条件、背景などがさっ ぱりわからない。 例:妥当性確認と検証 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 7
  8. 8.  SE C Software Engineering for Mo・No・Zu・Ku・Ri モデルの背景,制約条件がモデルに書かれていない。 診断に時間と手間がかかる 書いてある通りのことをしていなくてもよいのは分かるが、どう判断 すればいいか分からない。 現場の壁があって実体が見えない。 本当のことを言ってもらえない 大事な資料を見せてもらえない やっていることを本人たちが自覚がない。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 8
  9. 9.  SE C Software Engineering for Mo・No・Zu・Ku・Ri ソフトウェア設計も、モデルに基づいた診断も創造的な仕事を含んで います。 創造的な仕事は、個人の能力によって、やり方は全く違います。 創造的でない仕事でも、個人の能力によってやり方は違うかもしれま せん。 同じことを繰り返すことが目標ですか、よりよくすることが目標です か?      Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 9
  10. 10. SE C  Software Engineering for Mo・No・Zu・Ku・Ri 作業,手順,試験 作るもの そこにあるもの 気が付かないもの(視点なので目に見えない) 人間の作業、手順,作業分担などを含むか含まないか。 コンピュータの処理を含むか含まないか。 抽象度,粒度の違いによって様々な書き下せる。    Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 10
  11. 11.  SE C Software Engineering for Mo・No・Zu・Ku・Ri プロセスの定義モデル(参照モデル) プロセスの診断モデル(アセスメントモデル) どちらも抽象度,粒度はさまざま   IPAPEA Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 11
  12. 12.  SE C Software Engineering for Mo・No・Zu・Ku・Ri ISO/IEC 15504で規定しているのは最低限のこと 規格適合は第1者(自己宣言),第二者(取引先の確認,第三者 (審査登録済み 課題を解決して改善に進めるきっかけになればなにをしてもよい P  P  Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 12
  13. 13.   視点2ではAはBの部分集合  Software Engineering for Mo・No・Zu・Ku・Ri 視点1ではBはAの部分集合  SE C 誤解:自分は正しく相手が間違い Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 13
  14. 14.  SE C Software Engineering for Mo・No・Zu・Ku・Ri • 1つの用語を2つ以上の 意味で使っていないか。 – b: blue, bit – 人間は文脈依存で理解 – コンピュータは場合による • 用語を階層構造で定義 – 集合関係 – is - a 関係 A is a B. • BがCであれば、AはCであ る。 – has - a 関係 B has a A. • BがCであれば、 (c){ogawa.kiyioshi,watabe.kinji}@nmiri.city.nagoya.j 2010.10.1 プロセスアセスメントモデルの活用コー Software Engineering Center 14
  15. 15.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 最適化 2,3は日本が弱い 4,5は欧米が弱い 4 確立 3 管理 2 実施 0 5 予測可能 1 実施している 不完全な プロセス プロセス • プロセス実 施 確立している プロセス 最適化している プロセス 予測可能な プロセス • プロセス変更 • 継続的改善 • プロセス測定 • プロセス制御 管理している • プロセス定 義 プロセス • 実施管理 • プロセス資 源 • 作業生産物 管理 2010.10.1 プロセスアセスメントモデルの活用コー Software Engineering Center 15
  16. 16. SE C Software Engineering for Mo・No・Zu・Ku・Ri 2. モデルの操り方 2010.10.1 プロセスアセスメントモデルの活用コー Software Engineering Center 16
  17. 17.   SE C Software Engineering for Mo・No・Zu・Ku・Ri 2.0 診断モデルって何 2.1 プロセスの修整(tailoring) 2.2 プラクティス確認/代替プラクティス 2.3 すべてのことに優先順位付け 2.4 調査方法としての協力v.s. 面談/文書 2.5 責任所在の明確化としての証拠,記録 2.6 支援作業を分担しながら診断する Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 17
  18. 18.  SE C Software Engineering for Mo・No・Zu・Ku・Ri SPEAK/IPAとISOIEC 15504 診断モデル(1) 例題:ISO/IEC 15504 part5 診断モデル(2) 例題:ISO/IEC 15504 part5 診断モデル(3) 例題:ISO/IEC 15504 part5 診断作業 わかるための挑戦 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 18
  19. 19. PEAIPAIIEC  SE C Software Engineering for Mo・No・Zu・Ku・Ri NsolのSPEAKというモデルはISO/IEC 15504 Conformanceモデルです。 NsolのSPEAKはISO/IEC 15504 Part2(JIS X 0154 第2部)に基づいて います。 ISO/IEC 15504 part5はモデルの例です。 IPA/SPEAKは、NsolのSPEAKを基に作っています。 Automotive SPICEもISO/IEC 15504 part5に基づいています。 SPICE 4 SPCEという航空宇宙のモデルもISO/IEC 15504 Part5に基づ いています。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 19
  20. 20. IIEC  SE C t Software Engineering for Mo・No・Zu・Ku・Ri ISO/IEC 12207 Software Life cycle Process を参照モデルにしている。 ISO/IEC 12207は、-20年前の開発部門の作業標準を中心に、支援部 門の機能を関数的に呼び出せるような仕組みにした。そのため、プ ロセスといっても異なる性質のものが混在している。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 20
  21. 21. IIEC  SE C t Software Engineering for Mo・No・Zu・Ku・Ri 診断モデルでは修整の仕組みを陽に定義してない。 診断モデルの指標は、必須ではなく、診断員が参考にするものであ る。 個別の手法では、計算の仕方、優先順位の付け方、評価の仕方など を細かく規定しているものもある。 規格は共通部分を決めたため、共通でない部分は、個別には重要な 事項であっも記載していない可能性がある。 指標の代替の手順を陽に定義していない場合がある。 代替プラクティスといわれているもの。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 21
  22. 22. IIEC  SE C t Software Engineering for Mo・No・Zu・Ku・Ri 診断モデルのプロセスの区切りで診断作業をする必要はない。 結果として報告する際の区切りであって、作業の区切りで はない。 工場などで作業標準がきちんと決まっているところは、現 場の規定と診断対象プロセスとの対応づけをしてからや る場合もある。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 22
  23. 23.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 目的、目標によってやり方は千差万別である。 診断は監査ではない。 監査としてやることは可能。 監査と別にやるときは、監査がやらないことだけに絞らないと無駄。 監査をやる必要がない場合には、監査との関係にこだわる必要はな い。 診断は横並びではない。 企業によっては部門間の比較や、契約相手の比較(benchmark)に使 いたい場合もある。 比較に使わない場合は、杓子定規なやる必要はない。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 23
  24. 24.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 改善のために診断モデルを使いこなしてみる。 現場が深刻に受け止めている問題を解決しようと動き出してくれる。 現場が深刻な問題を一部の人が悩んで隠してしまっていないか。 現場が上に相談したいのに、聞く耳を持ってくれていない。 現場が問題や解決策を一つに決め込んでいて、それ以外の問題を解 決すれば、よい方向に向かうかもしれない。 ものの見方、使い方にはいろいろあることを知る。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 24
  25. 25.  t tailoring) SE C Software Engineering for Mo・No・Zu・Ku・Ri 仕立て屋さんのことを知ろう デザイン画があります。デザイナが書きます。 型紙を作ります。型紙屋(modeler)さんが書きます。 仕立て屋(tailor)さんがお客さんの寸法を測ります。 デザイン画,型紙の指示と,布地の柄から,実際の形を作り ます。 柄,形が特別な場合は,新たな型紙を作り,立体にして みることがあります。 修整(tailoring)には,型紙と顧客の両方の測定データの比較を します。 型紙の制約条件,現実の制約条件が定量的になっている Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 25
  26. 26. SE C  Software Engineering for Mo・No・Zu・Ku・Ri 既製服 S,M,L、LLなどに対応した型紙を作成 仕立て 型紙を起こすところから作成することもある 1つの型紙または可変型紙から作成 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 26
  27. 27.  SE C Software Engineering for Mo・No・Zu・Ku・Ri http://ja.wikipedia.org/wiki/型紙 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 27
  28. 28.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 細さに関する指示はある範囲ではすでに型紙にあります。 高さに関する指示はありません. 縦横比にあうものがあれば,伸縮できます。 柄を前提とした型,布地を顧客が指定する場合には 布地の柄によっては形が崩れたり,形が切れてしまうかもしれませ ん。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 28
  29. 29. SE C t(tailor) Software Engineering for Mo・No・Zu・Ku・Ri 型紙通りの大きさの顧客の場合は,裁断,縫製作業に進みます 型紙(モデル)を使って,型紙以外の大きさ,細さの人に合うも のを作る創造的な作業をします。 原則に従う事と,その場の直感に頼ることがある 選択肢は無限にあり,一通りの答えしか無い訳ではない 正しい,正しくないの判定はできません。 お客さんが満足する場合と,不満な場合があります。 お客さんの周りの人が褒める場合と貶す場合がありま す。 標的(goal)はお客さん自身です。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 29
  30. 30.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 型紙の元になる設計をする専門家はいます。 プロセスモデルの基になるあるべき姿を設計する人はいますで しょうか。 型紙を作る専門家がいます。 プロセスモデルを作る専門家はいますでしょうか。 型紙を使う専門家を使う専門家がいます。例えば,柄に合わせた形 を作ります。 プロセスモデルを使う専門家はいますでしょうか。 どの仕事もすべて創造的な仕事で,単純な仕事とは限りません。 プロセスの場合だけ,最初の形だけあって,型紙すらないので はありませんか? 制約条件がない、規模の変化への対応がない。すべて修整 (tailoring)でやることになっている。型紙の記載事項に相当 するのは修整(tailoring)のガイドのはず。 NPT1が作っている道具は型紙に相当するかもしれません。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 30
  31. 31.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 両方の経験がある人ならその人の頭の中で変換できる 大規模開発での指標(プラクティス)は小規模開発,特殊開発に置き 直さないと有効ではないかもしれない 現場の合意を形成するためにプラクティスの優先順位付けをしてみま せんか モデルにあることより,もっと大切なことがありませんか Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 31
  32. 32. SE C  Software Engineering for Mo・No・Zu・Ku・Ri ハードウェアとソフトウェアの両方を設計している会社だからでき る開発標準 5年ごとという目標が決まっている開発標準 100人以上で作業するときの開発標準 開発単位が億円の開発標準 品質部門,技術部門などの間接部門が別組織である組織の開発標準  Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 32
  33. 33. SE C water fall Software Engineering for Mo・No・Zu・Ku・Ri 3年,100人,1億円(100人が常時従事ではないため) 品質部門で次工程への進捗判定。 保留事項があっても先に進む事ができる。 保留事項の影響範囲,保留の原因を明確に。 保留事項の原因の解決を分担し,定期的に確認。 保留事項の一部は教育として実施している。 何度か繰り返すことが前提の場合とそうでない場合 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 33
  34. 34.   SE C Software Engineering for Mo・No・Zu・Ku・Ri モデルに書かれているプラクティスは代表例 別のプラクティスで同じ成果があるのならそれでもよい。 代替のものを始めから認めている手法と,その都度アセッサが判断すれ ばよい手法とがある。 その都度判断した内容はモデルにフィードバックするとよい。 事前にモデルの確定を規定しているのは比較のためであって改善の ためではない。 1つの成果が2つ以上のプラクティス、2つ以上のプロセスに対応してい る場合あり。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 34
  35. 35.   SE C Software Engineering for Mo・No・Zu・Ku・Ri • どんな作業でも,目標のためにやらなければいけないことは,日 程,費用,品質などに対応して優先順位がある • 日程が短い場合にはやらないで先に進むこともある • 最後までやらなければそれには理由があり説明ができればよい。 • 日程,費用,品質に照らして妥当かどうかの判断が大切。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 35
  36. 36.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 論理回路設計の設計標準の運用例 STARC RTL設計スタイルガイド 各社の社内標準は,RTL設計スタイルガイドに優先順位付けして作る ように推奨 実際の事業ごとに Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 36
  37. 37. 例:MISRA-C SE C Software Engineering for Mo・No・Zu・Ku・Ri RTL設計スタイルガイドのような命名規則,運用規則などがない 1998年版と2004年版の両方を並行して運用 それ以前の標準のコードも現存 それ以前の標準のコードとの調整規則(あるいは標準的逸脱(standing deviation)の手続き)を決めて運用 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 37
  38. 38.   SE C Software Engineering for Mo・No・Zu・Ku・Ri 診断の方法には作業の一部に参加して,協力的に行う方法と,作業に は参加せず,面談や文書調査による方法がある。 作業に参加する方法では,その作業の入出力は作業の中で確認できる ので,余分な作業は発生しない。 例:品質管理プロセスの作業に参加して,品質管理プロセスの評価 をした。 課題:作業に参加しているので主観的な評価であることを記録して おくと良い。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 38
  39. 39.    SE C Software Engineering for Mo・No・Zu・Ku・Ri 調査対象の中に入って体験する 実際に体験してみると,外から見ているのとでは大違いのことがあ る。 調査対象の外から判定する 面談(interview) 相手の立場にたった聞き取りができることが大切。 文書確認(document check) 無駄な文書を作らせないような配慮が大切。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 39
  40. 40.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 内部の人に診断チームに入ってもらう 内部情報の確認,責任の所在の確認は内部の人だけで実施する ことがある。 データ確認の横に情報責任者名または確認責任者の署名 責任の所在が分かることが大切 実際の文書の内容が重要なのは水準5 その場で定量評価と一致しているかの確認 直接的な証拠を見るのは水準1。 水準2以降は間接的な証拠で良い。   Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 40
  41. 41.   SE C Software Engineering for Mo・No・Zu・Ku・Ri 作業責任者が明確になっていて,作業責任者が交代したら,引き継ぎ があることが明確ならその作業責任者の署名で良いこともある。 面談の結果を記録したものを文書としてもよい。(手法によっては駄 目といっているものもある。診断報告書の付属文書を文書とする場 合もある。) 他の監査が義務づけられている分野では,文書は見ない場合もある。 (二度手間なので) Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 41
  42. 42.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 文書で作業内容と作業責任が明確になっていて,関係者に周知してい る。 文書で作業内容が明確になっていて,その都度責任者が明確になり, 関係者に周知している。 文書で作業責任者が明確になっていて,その都度作業内容が明確にな り,関係者に周知している。 文書で作業責任者が作業内容を決めることが明確になっていて,その 都度作業責任者を決め,作業責任者が作業内容を決め,関係者に周 知している。 作業責任者が作業内容を決めることが習慣化していて,その都度作業 責任者が作業内容を決め,関係者に周知している。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 42
  43. 43.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 困ったことが起こったら,すぐに対応できる。 回避方法を示して,ひとまず困ったことを回避する。 解決方法を示して,解決に到達できる。 代替案を示して,乗り換える。 損害が発生したら,誰が負担すべきか説明できる。 損害以上の利益がでていることを示せる。(誰も負担しない) 相手方の責任が明確になっていて,その責任範囲であることを説 明できる。 保険などに加入して対応する。 自社で負担した方が次の案件で挽回できる機会があることを判断 できる。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 43
  44. 44.   SE C Software Engineering for Mo・No・Zu・Ku・Ri 試験、文書化、レビュー、品質保証、プロジェクト管理、リスク管理 などの作業を分担しながら、診断結果を作成する 利点:関連するプロセスの入出力の確認は作業中に終了している。 (インタビュー、証拠確認実施済み) 課題:担当したプロセスからの目線でみる可能性がある。(判定の責 任は能力のあるアセッサ) Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 44
  45. 45. SE C  Software Engineering for Mo・No・Zu・Ku・Ri プロセス改善ナビゲーションガイド診断活用編の読み方 参考事例 参考文献 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 45
  46. 46.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 診断活用編の場合 知っているとよいこと:主な執筆者は3人 自社モデルを作った社内の改善の指導者 自社モデルも作ったことがある独立系コンサル いろいろなモデルを使っている社内の改善推進者 3人の共通部分が載っている。 誰か1つの立場だけで読んでみるとよい。 なんとなく書き足りないと感じる部分があるはず。 追記して自社のやり方とするとよい鍵かも Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 46
  47. 47.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 一人1プロセスを担当して計画から報告までを実施。 他のプロセスの面談などに同席して関連する事項を聞き取る。 自分が関係者の場合には自分で依頼者になったことを想定して目標、 計画を立ててみる。 作業費用、診断費用を意識する。 診断プロセスは改善できる。 製品の品質目標を意識する。 品質管理プロセスは改善できる。 人材(担当作業、診断を含む)の能力向上を意識する。 プロセスが改善されなくても、人の能力がプロセスに追いついて くればいいかも。(人材管理プロセスの改善) Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 47
  48. 48. SE C Software Engineering for Mo・No・Zu・Ku・Ri 3. 演習の進め方 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 48
  49. 49. 3. 演習の進め方 SE C Software Engineering for Mo・No・Zu・Ku・Ri 演習資料は、3つを用意しています。資料でのプロセス名はIPASPEAKを想定しています。 1. 妥当性確認プロセス 2. プロジェクト管理プロセス&リスク管理プロセス 3. 品質管理プロセス&測定プロセス 組織の状況、参加者の問題意識、講師によって、どの資料を利用する かを最初に決めてください。 モデル、資料にこだわるのではなく、自分たちの仕事、組織、事業の 目標、目的が同一であるかを確認してください。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 49
  50. 50. 進行例 SE C Software Engineering for Mo・No・Zu・Ku・Ri 1. 参加者の仕事の内容とプロセスに対する理解を述べる自己紹介を実 施してください。 2. 仕事、組織、事業が異なる場合には、議論を何に絞るかを手短に決 めてください。プロセス、プラクティス 3. 資料の分からない用語を洗い出し、参加者で、手短に確認してくだ さい。 どの解釈が正しいかではなく、どういう風に理解すると、自分たちの 改善に役立つかを考えてください。 グループメンバでの意見が分かれた場合には、講師に助言を求めて ください。 4. なぜそうしているのかを考え、仕立て(tailoring), 対応付け (mapping),別の同等なやり方(代替practice)がないかを議論してみて ください。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 50
  51. 51. 留意点 SE C Software Engineering for Mo・No・Zu・Ku・Ri 1. 正解を求めるのではなく、やっていてよかったことを述べ会うよう にしてください。やらずにうまくいかなかったことを述べてもかま いません。できるだけ、後ろ向きにならないようにしましょう。 2. やり方をできるだけ複数紹介しあえるようにしましょう。どのやり 方は、どういう制約が関係しているかを、話をしましょう。 3. モデルの解釈を議論するのではなく、自分たちの改善のきっかけに なることに気がつくことがでるのはよいでしょう。 4. 振り返りでは、よかったこと、課題、今後挑戦しようとすることを まとめましょう。 5. いくつかの班に分かれて作業した場合には、それぞれの班ごとに成 果を報告するか、個人の振り返りの内容を報告しましょう。 Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 51
  52. 52.  SE C Software Engineering for Mo・No・Zu・Ku・Ri 型紙 http://ja.wikipedia.org/wiki/型紙 パターンメーキング技能試験 http://www.fashionedu.jp/pt/2009/1_02.png Copyright 2010.10.1 プロセスアセスメントモデルの活用コー © 2012 IPA, All Rights Reserved. Software Engineering Center 52

×