4 件の資料が見つかりました。
ダウンロード数: 204回
SQuBOK分類 :
1.2.2 改善の考え方 、 2.3.2.3 ポストモーテム 、 2.3.2 ソフトウェアプロセス改善のためのマネジメント技法 、 2.12.1.2 プロジェクト&プログラムマネジメント(P2M) 、 2.19.2 プロセス品質の分析・評価
1.2.2 改善の考え方 、 2.3.2.3 ポストモーテム 、 2.3.2 ソフトウェアプロセス改善のためのマネジメント技法 、 2.12.1.2 プロジェクト&プログラムマネジメント(P2M) 、 2.19.2 プロセス品質の分析・評価
紹介文 :
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。
本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。
本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。
ダウンロード数: 177回
SQuBOK分類 :
1.2.2 改善の考え方 、 2.6 教育・育成のマネジメント 、 2.12.1.2 プロジェクト&プログラムマネジメント(P2M) 、 2.19.2 プロセス品質の分析・評価 、 3.1 メトリクス
1.2.2 改善の考え方 、 2.6 教育・育成のマネジメント 、 2.12.1.2 プロジェクト&プログラムマネジメント(P2M) 、 2.19.2 プロセス品質の分析・評価 、 3.1 メトリクス
紹介文 :
製品知識や開発情報・技術のノウハウは特定の担当者によって異なるが、偏りが進み過ぎると、伝達すべき情報や技術が継承されず,製品を改造・流用する際に製品仕様や設計、実装時の検討漏れや誤りなどの原因となって問題を引き起こす場合が多い。
本テーマは、この“いわゆる属人化状態”の分析に焦点を当て、プロジェクトチーム内の担当者同士による技術面での個人依存度の主観的な相互評価の値と、レビュー実施時の各担当者別の発言時間という客観的な測定値とを組み合わせ、担当者を「職人領域」,「属人領域」,「教育領域」,「点検領域」,「適正領域」の五つに分類し、チーム内の担当者の相対的な属人化の進行の不均衡さ(チームバランス)を可視化することによって、
管理者が各領域のバランス状態を確認し、必要な育成リソースに対する過不足を把握して、
問題発生前の事前対応計画作成に役立てられるよう、属人化状態の測定・可視化を通して改善する仕組みを構築しようとする研究である。
製品知識や開発情報・技術のノウハウは特定の担当者によって異なるが、偏りが進み過ぎると、伝達すべき情報や技術が継承されず,製品を改造・流用する際に製品仕様や設計、実装時の検討漏れや誤りなどの原因となって問題を引き起こす場合が多い。
本テーマは、この“いわゆる属人化状態”の分析に焦点を当て、プロジェクトチーム内の担当者同士による技術面での個人依存度の主観的な相互評価の値と、レビュー実施時の各担当者別の発言時間という客観的な測定値とを組み合わせ、担当者を「職人領域」,「属人領域」,「教育領域」,「点検領域」,「適正領域」の五つに分類し、チーム内の担当者の相対的な属人化の進行の不均衡さ(チームバランス)を可視化することによって、
管理者が各領域のバランス状態を確認し、必要な育成リソースに対する過不足を把握して、
問題発生前の事前対応計画作成に役立てられるよう、属人化状態の測定・可視化を通して改善する仕組みを構築しようとする研究である。
ダウンロード数: 174回
紹介文 :
ソフトウェア開発プロジェクトを円滑に進めるためには、コミュニケーション(情報伝達)は重要な要素である。プロジェクト内で「コミュニケーションに関する問題」が発生すると、プロジェクトは開発現場の諸問題に気づかずに適切に対処しないまま進行しがちとなり、メンバの士気低下やプロジェクト全体の雰囲気が悪化する。これは、さらに潜在する課題の増加を招くので、プロジェクトにとって大きなリスクとなり得る。
そこで本研究では、プロジェクトリーダ、チームリーダ、チームメンバ間のコミュニケーション問題,士気/雰囲気の問題を察知するための質問を「コミュニケーション問診票」として作成し提案し、試行している。そして、「コミュニケーション問診票」を適用して“問題点を検知”し、「コミュニケーション問題箇所特定図」にて“問題点を特定”し、PMOやSQAなどのプロジェクトの第三者の専門部門にて作成された「処方箋」提案をもとに、プロジェクトリーダ、チームリーダ、チームメンバが各範囲で“問題に対処”する流れを体系化した。コミュニケーションの問題は可視化が困難であるが、プロジェクト全体を俯瞰した図を活用し、見える化を図った興味深いテーマである。
ソフトウェア開発プロジェクトを円滑に進めるためには、コミュニケーション(情報伝達)は重要な要素である。プロジェクト内で「コミュニケーションに関する問題」が発生すると、プロジェクトは開発現場の諸問題に気づかずに適切に対処しないまま進行しがちとなり、メンバの士気低下やプロジェクト全体の雰囲気が悪化する。これは、さらに潜在する課題の増加を招くので、プロジェクトにとって大きなリスクとなり得る。
そこで本研究では、プロジェクトリーダ、チームリーダ、チームメンバ間のコミュニケーション問題,士気/雰囲気の問題を察知するための質問を「コミュニケーション問診票」として作成し提案し、試行している。そして、「コミュニケーション問診票」を適用して“問題点を検知”し、「コミュニケーション問題箇所特定図」にて“問題点を特定”し、PMOやSQAなどのプロジェクトの第三者の専門部門にて作成された「処方箋」提案をもとに、プロジェクトリーダ、チームリーダ、チームメンバが各範囲で“問題に対処”する流れを体系化した。コミュニケーションの問題は可視化が困難であるが、プロジェクト全体を俯瞰した図を活用し、見える化を図った興味深いテーマである。
ダウンロード数: 170回
SQuBOK分類 :
2.2.3.1 ウォーターフォールモデル 、 2.2.3.3 プロトタイピング 、 2.2.3.5 アジャイル開発 、 2.12 プロジェクトマネジメント 、 3.1 メトリクス
2.2.3.1 ウォーターフォールモデル 、 2.2.3.3 プロトタイピング 、 2.2.3.5 アジャイル開発 、 2.12 プロジェクトマネジメント 、 3.1 メトリクス
執筆者 :
市川 孝裕(株式会社インテリジェンス ビジネスソリューションズ)
、海野 和由(矢崎総業株式会社)
、小林 道央(株式会社インテック)
、山本 久代(サントリーシステムテクノロジー株式会社)
紹介文 :
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。
このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。
顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。
このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。
顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。