李商隠の「曲江」をどう読むか?ーその「傷春」の意味ー 下 …chinese.art.coocan.jp/shangchun.pdf1 李商隠の「曲江」をどう読むか?ーその「傷春」の意味ー
プロセスアセスメントモデルの活用 ー...
-
Upload
kiyoshi-ogawa -
Category
Technology
-
view
442 -
download
2
description
Transcript of プロセスアセスメントモデルの活用 ー...
Information-technology Promotion Agency, Japan
SoftwareEngineeringCenter
1Software Engineering CenterCopyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved.
工学博士・技術士(情報工学)名古屋市工業研究所 小川清
SPEAK-IPAプロセスコース
2010年 10月 1日
プロセスアセスメントモデルの活用プロセス改善のモデルをあやつろう
Software Engineering Center 2
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
会場利用のご注意
トイレが混んでいる場合は、別のフロアのトイレもご利用ください建物の外へでた場合は、下でインターホンで入ってください。喫煙は、部屋の隅のドアの外で吸うことができます。飲み物は自由にご利用ください。携帯電話は無音でお願いします。意見交換会を終了後に予定しています。お時間のある方はご参加くださると幸いです。
Software Engineering Center 3
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
目次
1. 概要2. 診断モデルの操り方3. 演習の進め方
Software Engineering Center 4
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
1.概要
Software Engineering Center 5
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
日程
13:30 -13:3 5 会場の利用上の注意13:3 5 – 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-外での意見交換会(任意)
Software Engineering Center 6
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
今日の目標
各自で設定してください。想定:プロセスモデル(特にアセスメントモデル)を道具として操 (あやつ )る上で,何か1つ気が付く
自分たちの使い方が当たり前だと思っていたけど,自分たちのように使いこなしているところが無いらしい。え,他社ではそんな使い方してたの?業界が違うと全然違う使い方しているけど,自分たちの使い方本当にこれでいいの?そんな使い方をしては駄目だと教わったけど,理由は考えたことがなかった。結局無駄なことしていて道具を使わない方がいいんじゃない。
素手(自分の頭)だって,立派な道具
Software Engineering Center 7
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
想定課題(設計・保守担当)
プロセスモデル,プロセスアセスメントモデルを振り回して,書いてある通りのことをやらせようとして困っている。
分けの分からない人間が来て,いいかげんな判定をしていく。経験がない人に説明するのに無駄な時間を取られるのはうんざり。
経験があれば見なくてもわかるはずのものを見たがる。モデルに書いてあることが、用語定義、制約条件、背景などがさっ
ぱりわからない。例:妥当性確認と検証
Software Engineering Center 8
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
想定課題(アセッサ)
モデルの背景,制約条件がモデルに書かれていない。診断に時間と手間がかかる書いてある通りのことをしていなくてもよいのは分かるが、どう判断すればいいか分からない。
現場の壁があって実体が見えない。本当のことを言ってもらえない大事な資料を見せてもらえないやっていることを本人たちが自覚がない。
Software Engineering Center 9
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
作業って何
ソフトウェア設計も、モデルに基づいた診断も創造的な仕事を含んでいます。
創造的な仕事は、個人の能力によって、やり方は全く違います。創造的でない仕事でも、個人の能力によってやり方は違うかもしれません。
同じことを繰り返すことが目標ですか、よりよくすることが目標ですか?
目標がよりよくすることであれば、まずよりよくできることを考えてください。繰り返しできるかというのは目標の一つかもしれませんが、こだわらないようにしてください。
Software Engineering Center 10
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
プロセスって何
作業,手順,試験作るものそこにあるもの気が付かないもの(視点なので目に見えない)人間の作業、手順,作業分担などを含むか含まないか。コンピュータの処理を含むか含まないか。抽象度,粒度の違いによって様々な書き下せる。
今日は議論しません。今日来た人がどう考えているかは、全体の議論の中で分かり
ます。
Software Engineering Center 11
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
プロセスモデルって何
プロセスの定義モデル(参照モデル)プロセスの診断モデル(アセスメントモデル)どちらも抽象度,粒度はさまざま
今日は何でもありです。議論の中心では日本語で利用可能な IPA/SPEAKを使います。
Software Engineering Center 12
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
診断(アセスメントプロセス)?
ISO/IEC 15504で規定しているのは最低限のこと規格適合は第 1者(自己宣言),第二者(取引先の確認,第三者(審査登録済み
課題を解決して改善に進めるきっかけになればなにをしてもよい
今日は特定の診断手法に限定した議論はしません。(例示としての紹介は歓迎しますが、それだけがいいという限定はしないでください。)
Software Engineering Center 13
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
視点の違いによる誤解 視点1では Bは Aの部分集合 視点2では Aは Bの部分集合 誤解:自分は正しく相手が間違い
Software Engineering Center 14
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
(c){ogawa.kiyioshi,watabe.kinji}@nmiri.city.nagoya.jp
用語の木
• 1つの用語を2つ以上の意味で使っていないか。
– b: blue, bit
– 人間は文脈依存で理解– コンピュータは場合による
• 用語を階層構造で定義– 集合関係
– is - a 関係 A is a B.• Bが Cであれば、 Aは Cである。
– has - a 関係 B has a A.• Bが Cであれば、
Software Engineering Center 15
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
能力水準の意味
2,3は日本が弱い4,5は欧米が弱い
01
2
4
5
3
実施しているプロセス•プロセス実施
管理しているプロセス•実施管理• 作業生産物管理
確立しているプロセス•プロセス定義
•プロセス資源
予測可能なプロセス•プロセス測定•プロセス制御
最適化しているプロセス•プロセス変更• 継続的改善
不完全なプロセス
実施
確立
予測可能
最適化
管理
Software Engineering Center 16
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
2. モデルの操り方
Software Engineering Center 17
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2. 診断モデルの操り方
2.0 診断モデルって何2.1 プロセスの修整 (tailoring)
2.2 プラクティス確認 / 代替プラクティス2.3 すべてのことに優先順位付け2.4 調査方法としての協力 v.s. 面談/文書2.5 責任所在の明確化としての証拠,記録2.6 支援作業を分担しながら診断する
Software Engineering Center 18
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.0診断モデルって何SPEAK/IPAと ISOIEC 15504
診断モデル (1)例題: ISO/IEC 15504 part5
診断モデル (2)例題: ISO/IEC 15504 part5
診断モデル (3)例題: ISO/IEC 15504 part5
診断作業わかるための挑戦
Software Engineering Center 19
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
SPEAK/IPAと ISO/IEC 15504Nsolの 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に基
づいています。
Software Engineering Center 20
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
ISO/IEC 15504 part5ISO/IEC 12207 Software Life cycle Process を参照モデルにしている。ISO/IEC 12207は、 - 20年前の開発部門の作業標準を中心に、支援部門の機能を関数的に呼び出せるような仕組みにした。そのため、プロセスといっても異なる性質のものが混在している。
Software Engineering Center 21
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
ISO/IEC 15504 part5診断モデルでは修整の仕組みを陽に定義してない。診断モデルの指標は、必須ではなく、診断員が参考にするものである。
個別の手法では、計算の仕方、優先順位の付け方、評価の仕方などを細かく規定しているものもある。
規格は共通部分を決めたため、共通でない部分は、個別には重要な事項であっも記載していない可能性がある。
指標の代替の手順を陽に定義していない場合がある。代替プラクティスといわれているもの。
Software Engineering Center 22
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
ISO/IEC 15504 part5
診断モデルのプロセスの区切りで診断作業をする必要はない。結果として報告する際の区切りであって、作業の区切り
ではない。工場などで作業標準がきちんと決まっているところは、
現場の規定と診断対象プロセスとの対応づけをしてからやる場合もある。
Software Engineering Center 23
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
診断作業はどういう道具
目的、目標によってやり方は千差万別である。診断は監査ではない。
監査としてやることは可能。監査と別にやるときは、監査がやらないことだけに絞らないと無駄。
監査をやる必要がない場合には、監査との関係にこだわる必要はない。
診断は横並びではない。企業によっては部門間の比較や、契約相手の比較 (benchmark)に使いたい場合もある。
比較に使わない場合は、杓子定規なやる必要はない。
Software Engineering Center 24
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
わかるための挑戦
改善のために診断モデルを使いこなしてみる。現場が深刻に受け止めている問題を解決しようと動き出してくれ
る。現場が深刻な問題を一部の人が悩んで隠してしまっていないか。
現場が上に相談したいのに、聞く耳を持ってくれていない。現場が問題や解決策を一つに決め込んでいて、それ以外の問題を
解決すれば、よい方向に向かうかもしれない。ものの見方、使い方にはいろいろあることを知る。
Software Engineering Center 25
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.1 プロセスの仕立て ( 修整: tailoring)
仕立て屋さんのことを知ろうデザイン画があります。デザイナが書きます。型紙を作ります。型紙屋 (modeler)さんが書きます。仕立て屋 (tailor)さんがお客さんの寸法を測ります。デザイン画,型紙の指示と,布地の柄から,実際の形を作ります。
柄,形が特別な場合は,新たな型紙を作り,立体にしてみることがあります。
修整 (tailoring)には,型紙と顧客の両方の測定データの比較をします。
型紙の制約条件,現実の制約条件が定量的になっている
Software Engineering Center 26
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
型紙の利用
既製服S,M,L、 LLなどに対応した型紙を作成
仕立て型紙を起こすところから作成することもある
1つの型紙または可変型紙から作成
Software Engineering Center 27
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
一つの型紙があります
http://ja.wikipedia.org/wiki/ 型紙
Software Engineering Center 28
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
型紙の例の特徴
細さに関する指示はある範囲ではすでに型紙にあります。高さに関する指示はありません .
縦横比にあうものがあれば,伸縮できます。柄を前提とした型,布地を顧客が指定する場合には
布地の柄によっては形が崩れたり,形が切れてしまうかもしれません。
Software Engineering Center 29
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
修整 : 仕立て屋 (tailor)さんの仕事
型紙通りの大きさの顧客の場合は,裁断,縫製作業に進みます型紙(モデル)を使って,型紙以外の大きさ,細さの人に合うものを作る創造的な作業をします。原則に従う事と,その場の直感に頼ることがある選択肢は無限にあり,一通りの答えしか無い訳ではない
正しい,正しくないの判定はできません。お客さんが満足する場合と,不満な場合があります。お客さんの周りの人が褒める場合と貶す場合があります。
標的 (goal)はお客さん自身です。
Software Engineering Center 30
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
プロセスモデルは型紙ほど成熟していますか?
型紙の元になる設計をする専門家はいます。プロセスモデルの基になるあるべき姿を設計する人はいますで
しょうか。型紙を作る専門家がいます。
プロセスモデルを作る専門家はいますでしょうか。型紙を使う専門家を使う専門家がいます。例えば,柄に合わせた形を作ります。
プロセスモデルを使う専門家はいますでしょうか。どの仕事もすべて創造的な仕事で,単純な仕事とは限りません。
プロセスの場合だけ,最初の形だけあって,型紙すらないのではありませんか?
制約条件がない、規模の変化への対応がない。すべて修整( tailoring)でやることになっている。型紙の記載事項に相
当するのは修整( tailoring)のガイドのはず。NPT1が作っている道具は型紙に相当するかもしれません。
Software Engineering Center 31
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
評価モデルの完成度
両方の経験がある人ならその人の頭の中で変換できる大規模開発での指標(プラクティス)は小規模開発,特殊開発に置き
直さないと有効ではないかもしれない現場の合意を形成するためにプラクティスの優先順位付けをしてみませんか
モデルにあることより,もっと大切なことがありませんか
Software Engineering Center 32
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
メインフレーム開発標準の場合
ハードウェアとソフトウェアの両方を設計している会社だからできる開発標準
5年ごとという目標が決まっている開発標準100人以上で作業するときの開発標準開発単位が億円の開発標準品質部門,技術部門などの間接部門が別組織である組織の開発標準そのまま使って有効ですか?
Software Engineering Center 33
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
落水 (water fall) 例
3年, 100人, 1億円( 100人が常時従事ではないため)品質部門で次工程への進捗判定。保留事項があっても先に進む事ができる。保留事項の影響範囲,保留の原因を明確に。保留事項の原因の解決を分担し,定期的に確認。
保留事項の一部は教育として実施している。何度か繰り返すことが前提の場合とそうでない場合
Software Engineering Center 34
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.2 代替プラクティス
モデルに書かれているプラクティスは代表例別のプラクティスで同じ成果があるのならそれでもよい。代替のものを始めから認めている手法と,その都度アセッサが判断すればよい手法とがある。
その都度判断した内容はモデルにフィードバックするとよい。事前にモデルの確定を規定しているのは比較のためであって改善のためではない。
1つの成果が 2つ以上のプラクティス、2つ以上のプロセスに対応している場合あり。
Software Engineering Center 35
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.3 優先順位付け
• どんな作業でも,目標のためにやらなければいけないことは,日程,費用,品質などに対応して優先順位がある
• 日程が短い場合にはやらないで先に進むこともある• 最後までやらなければそれには理由があり説明ができればよい。• 日程,費用,品質に照らして妥当かどうかの判断が大切。
Software Engineering Center 36
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
設計標準の場合
論理回路設計の設計標準の運用例STARC RTL設計スタイルガイド各社の社内標準は, RTL設計スタイルガイドに優先順位付けして作るように推奨
実際の事業ごとに
Software Engineering Center 37
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
例:MISRA-C
RTL設計スタイルガイドのような命名規則,運用規則などがない1998年版と 2004年版の両方を並行して運用それ以前の標準のコードも現存それ以前の標準のコードとの調整規則(あるいは標準的逸脱 (standing
deviation)の手続き)を決めて運用
Software Engineering Center 38
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.4 協力,面談診断の方法には作業の一部に参加して,協力的に行う方法と,作業には参加せず,面談や文書調査による方法がある。
作業に参加する方法では,その作業の入出力は作業の中で確認できるので,余分な作業は発生しない。例:品質管理プロセスの作業に参加して,品質管理プロセスの評
価をした。課題:作業に参加しているので主観的な評価であることを記録しておくと良い。
Software Engineering Center 39
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
背景:社会調査法 (field work)
調査対象の中に入って体験する実際に体験してみると,外から見ているのとでは大違いのことがある。
調査対象の外から判定する面談 (interview)
相手の立場にたった聞き取りができることが大切。文書確認 (document check)
無駄な文書を作らせないような配慮が大切。
Software Engineering Center 40
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
診断での実際の例
内部の人に診断チームに入ってもらう内部情報の確認,責任の所在の確認は内部の人だけで実施することがある。
データ確認の横に情報責任者名または確認責任者の署名責任の所在が分かることが大切実際の文書の内容が重要なのは水準 5
その場で定量評価と一致しているかの確認直接的な証拠を見るのは水準 1。水準 2 以降は間接的な証拠で良い。
2.6 支援作業などを分担しながら診断する(別項)
Software Engineering Center 41
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.5 証拠,記録
作業責任者が明確になっていて,作業責任者が交代したら,引き継ぎがあることが明確ならその作業責任者の署名で良いこともある。
面談の結果を記録したものを文書としてもよい。(手法によっては駄目といっているものもある。診断報告書の付属文書を文書とする場合もある。)
他の監査が義務づけられている分野では,文書は見ない場合もある。(二度手間なので)
Software Engineering Center 42
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
責任の明確化
文書で作業内容と作業責任が明確になっていて,関係者に周知している。
文書で作業内容が明確になっていて,その都度責任者が明確になり,関係者に周知している。
文書で作業責任者が明確になっていて,その都度作業内容が明確になり,関係者に周知している。
文書で作業責任者が作業内容を決めることが明確になっていて,その都度作業責任者を決め,作業責任者が作業内容を決め,関係者に周知している。
作業責任者が作業内容を決めることが習慣化していて,その都度作業責任者が作業内容を決め,関係者に周知している。
Software Engineering Center 43
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
責任とは
困ったことが起こったら,すぐに対応できる。回避方法を示して,ひとまず困ったことを回避する。解決方法を示して,解決に到達できる。代替案を示して,乗り換える。
損害が発生したら,誰が負担すべきか説明できる。損害以上の利益がでていることを示せる。(誰も負担しない)相手方の責任が明確になっていて,その責任範囲であることを説明できる。
保険などに加入して対応する。自社で負担した方が次の案件で挽回できる機会があることを判断できる。
Software Engineering Center 44
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
2.6 支援作業を分担しながら診断する
試験、文書化、レビュー、品質保証、プロジェクト管理、リスク管理などの作業を分担しながら、診断結果を作成する
利点:関連するプロセスの入出力の確認は作業中に終了している。(インタビュー、証拠確認実施済み)
課題:担当したプロセスからの目線でみる可能性がある。(判定の責任は能力のあるアセッサ)
Software Engineering Center 45
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
付録
プロセス改善ナビゲーションガイド診断活用編の読み方参考事例参考文献
Software Engineering Center 46
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
プロセス改善ナビゲーションガイドの読み方
診断活用編の場合知っているとよいこと:主な執筆者は 3人
自社モデルを作った社内の改善の指導者自社モデルも作ったことがある独立系コンサル
いろいろなモデルを使っている社内の改善推進者3人の共通部分が載っている。
誰か1つの立場だけで読んでみるとよい。なんとなく書き足りないと感じる部分があるはず。追記して自社のやり方とするとよい鍵かも
Software Engineering Center 47
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
参考事例
一人1プロセスを担当して計画から報告までを実施。他のプロセスの面談などに同席して関連する事項を聞き取る。自分が関係者の場合には自分で依頼者になったことを想定して目標、計画を立ててみる。
作業費用、診断費用を意識する。診断プロセスは改善できる。
製品の品質目標を意識する。品質管理プロセスは改善できる。
人材(担当作業、診断を含む)の能力向上を意識する。プロセスが改善されなくても、人の能力がプロセスに追いついて
くればいいかも。(人材管理プロセスの改善)
Software Engineering Center 48
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
3. 演習の進め方
Software Engineering Center 49
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
3. 演習の進め方
演習資料は、3つを用意しています。資料でのプロセス名は IPA-SPEAKを想定しています。
1. 妥当性確認プロセス 2. プロジェクト管理プロセス&リスク管理プロセス 3. 品質管理プロセス&測定プロセス組織の状況、参加者の問題意識、講師によって、どの資料を利用するかを最初に決めてください。
モデル、資料にこだわるのではなく、自分たちの仕事、組織、事業の目標、目的が同一であるかを確認してください。
Software Engineering Center 50
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
進行例
1. 参加者の仕事の内容とプロセスに対する理解を述べる自己紹介を実施してください。
2. 仕事、組織、事業が異なる場合には、議論を何に絞るかを手短に決めてください。プロセス、プラクティス
3. 資料の分からない用語を洗い出し、参加者で、手短に確認してください。
どの解釈が正しいかではなく、どういう風に理解すると、自分たちの改善に役立つかを考えてください。
グループメンバでの意見が分かれた場合には、講師に助言を求めてください。
4. なぜそうしているのかを考え、仕立て (tailoring), 対応付け(mapping),別の同等なやり方 ( 代替 practice)がないかを議論してみてください。
Software Engineering Center 51
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
留意点
1. 正解を求めるのではなく、やっていてよかったことを述べ会うようにしてください。やらずにうまくいかなかったことを述べてもかまいません。できるだけ、後ろ向きにならないようにしましょう。
2. やり方をできるだけ複数紹介しあえるようにしましょう。どのやり方は、どういう制約が関係しているかを、話をしましょう。
3. モデルの解釈を議論するのではなく、自分たちの改善のきっかけになることに気がつくことがでるのはよいでしょう。
4. 振り返りでは、よかったこと、課題、今後挑戦しようとすることをまとめましょう。
5. いくつかの班に分かれて作業した場合には、それぞれの班ごとに成果を報告するか、個人の振り返りの内容を報告しましょう。
Software Engineering Center 52
SECSoftware Engineeringfor Mo ・ No ・ Zu ・ Ku ・ Ri
2010.10.1 プロセスアセスメントモデルの活用コース
Copyright © 2012 IPA , All Rights Reserved.
参考文献
型紙 http://ja.wikipedia.org/wiki/ 型紙パターンメーキング技能試験
http://www.fashion-edu.jp/pt/2009/1_02.png