SlideShare a Scribd company logo
1 of 7
Download to read offline
PBL タイトル:ソフトウェア開発プロジェクトのマネジメント方法論
主担当教員:中鉢欣秀 准教授
副担当教員:
この PBL の目標(教育理念、教員からのメッセージ)
 この PBL では短納期・少人数のソフトウェア開発プロジェクトにおけるプロジェク
トマネジャーを育成するためのトレーニングメソッドを確立することを目標にします.
プロジェクト管理の知識体系として PMBOK が有名です.しかしながら,近年主流と
なりつつあるアジャイル型のソフトウェア開発に PMBOK をそのまま適用することは
困難です.一方で,アジャイル型の開発プロセスをマネジメントする手法を適用するた
めの確たる方法論がないこともまた事実であり,技術者教育を困難にしています.
 そこで,本 PBL ではアジャイル型の開発に適応できる人材育成にふさわしい,コー
チング法や教材などを作成することを目標とします.その上で,この成果を実際のソフ
トウェア開発プロジェクトに適用して有用性を検証します.


プロジェクト課題(プロジェクトテーマ)
 本年度の前期(1,2Q)では,簡単なソフトウェア開発プロセス(ミニプロジェクト)
を実施します.目的はソフトウェアを作ることではなく,アジャイル型のイテレーショ
ンサイクルを上手に回すための方法について検討することです.特に難しいソフトウェ
アを作るわけではないため,ソフトウェア開発のためのスキルはさほど必要としませ
ん.これらの開発経験を通して,アジャイル技術者育成のための教材に必要なコンテン
ツを明らかにします.
 後期(3,4Q)では,前期で得た知見を生かし,短納期・少人数のソフトウェア開発
をマネジメントします.ここでは,前期で検討した教育法をプロジェクトに対して適用
し,その効果について評価します.マネジメントをする対象としては,学部の学生(ベ
トナム国家大学および慶応義塾大学 SFC)を予定しています.
 以上の活動を通して,自分自身がアジャイル型のソフトウェア開発におけるエッセン
スを身につけると共に,最終的には,他の技術者を教育するためのトレーニング教材を
作成して公開することを目標とします.


プロジェクトの特徴(特長)
 アジャイル開発を実際にコーチングしている専門家のアドバイスがもらえる予定です.
 ソフトウェア開発プロセスの方法論を,実際のプロジェクトマネジメントを通して身につける
ことができます.
 VNU との活動を通して,英語によるコミュニケーションスキルが向上します.
 この PBL の活動はプロジェクトマネジメントに関する研究として捉えることもでき
ますので,希望する学生がいれば, PBL の主たる活動のほかに学会発表のための論
                本
文指導も行います(ただし,学会発表の成果のみで単位を認めることはありません)
                                     .
 和気藹々と楽しく活動することがモットーです.飲み会や合宿も企画します.


過去の実績など
 2011 年度は,前期にプロジェクトマネジメントガイドブックを作成しました.後期に
は,5 つのプロジェクトを各メンバが分担してマネジメントを行いました.Facebook
アプリ,Android アプリ,Web アプリなどを開発しました.


プロジェクト実施により身に付けるべき達成目標、到達目標(評価軸として利用)
 少人数のソフトウェア開発を通し,PMBOK などの関連知識も踏まえた上で,技術者
教育のためのトレーニングメソッドをまとめること
 実際のソフトウェア開発プロジェクトのマネジメントを経験し,そこから学んだ知見
を整理してまとめるすること.


履修条件(プロジェクトメンバになるための前提条件)
 必ずしもプログラミングができなくてもよいですが,過去に何らかのソフトウェア開
発プロジェクトに所属して仕事を行った経験があることが望ましいです.不安な方は
事前に相談してください.
 プロジェクトの活動は水曜日をコアタイムとし,土曜日は作業やレビューの時間にし
ます.
 なお,慶應義塾大学の PBL のマネジャーを担当する場合に限り,毎週金曜日の午後に
湘南藤沢キャンパス(神奈川県藤沢市)でのミーティングに参加して頂く予定です(た
だし,このことの可否はプロジェクトメンバになるための必須条件ではありません)


メンバ決定ルール(プロジェクト配属における優先順位の決定方法)
 成績順(2010 年度 4Q 終了時点の GPA を利用します)


提示したテーマを実施するための最少メンバ数
3 名




                         2
PBL 全体のアクティビティ(プロジェクトを遂行していく際のアクティビティ)




※プロジェクトの実施体制は次のとおりです.




                   3
各アクティビティの説明(1Q,2Q)


番号 アクティビティ名    活動内容               主な成果物        修得できるスキル,コン
                                               ピテンシー
1   プロジェクト計画
2   プロジェクト計画   プ ロ ジ ェ ク ト 課 題    プロジェクト計画    ビジョン設定力
               を確認する              書             プロジェクト定義力
               プ ロ ジ ェ ク ト チ ー    全体工程表       プロジェクト管理力
               ム,メンバ,プロジ           コスト,リソース
               ェクトが必要とす           分析
               る役割を確認する
               プ ロ ジ ェ ク ト 計 画
               を作成する
3   ミニプロジェクト
4   ツールと技法の調   ア ジ ャ イ ル 開 発 マ    調査報告書       情報収集力
    査          ネジメントの技法                         研究動向調査力
               を調査する                            関連研究調査力
               ア ジ ャ イ ル 開 発 の
               ツールを調査する
5   トレーニング     ア ジ ャ イ ル コ ー チ    トレーニング成果    アジャイル開発能力
               からトレーニング
               を受ける
6   開発プロジェクト   プ ロ ジ ェ ク ト マ ネ    アジャイル型ソフ    文書作成力
               ジメント技法の検           トウェア開発体験      課題設定力
               証とトレーニング                         課題解決力
               方法の検討
7   トレーニングメソッド
8   トレーニングメソ   ト レ ー ン イ グ の 内    トレーニングメソ    文書作成力
    ッドの開発      容を検証する             ッド(教材等)       課題設定力
                                                課題解決力
                                                課題まとめ力




                              4
各アクティビティの説明(3Q,4Q)


9    メソッドの適用
10   トレーニングを実   プ ロ ジ ェ ク ト メ ン    トレーニング経験    トレーニング能力
     施する        バ候補に対して,ト
                レーニングを行う
11   プロジェクトマネジメント
12   プロジェクトマネ   ソ フ ト ウ ェ ア 開 発    ソフトウェア      プロジェクトマネジ
     ジメント       プロジェクトのマ            仕様書・設計書等   メント力
                ネジメント               プロジェクトマネ    システム設計力
                                   ジメント報告書       詳細仕様作成力
                                                 システム実装力
                                                 開発環境構築力
                                                 設計書作成力
                                                 テスト計画作成力
13   メソッドの評価
14   トレーニングメソ   実 施 し た ト レ ー ニ    トレーニングメソ    分析力
     ッドの評価・検証   ングメソッドが有           ッドの検証         整理力
                効に機能したかど
                うかを検証する
15   発表準備       最 終 発 表 の 準 備 を    プレゼンテーショ    省察力
                する                 ン             発表力
                                    パネル




                               5
修得できるスキル、コンピテンシーと7つの基本コンピテンシーとの関係(まとめ)
基本コンピテンシー   修得できるスキル、コンピテンシー
発想力         ビジョン設定力
            課題設定力
            課題解決力
            課題まとめ力
            要求実現力
            研究成果総括力
マーケット感覚     情報収集力
            市場動向調査力
ニーズ分析       情報収集力
            研究動向調査力
            関連研究調査力
            関連技術調査力
ドキュメンテーシ 仕様書作成力
ョン          方式記述力
            設計書作成力
            開発計画書作成力
            報告書作成力
モデリングとシス 要求モデル作成力
テム提案        実現性検証力
            システム設計力
            詳細仕様作成力
            開発環境構築力
            システム実装力
            テスト計画作成力
            評価モデル作成力
            評価計画作成力
            評価実験実行力
            実験結果分析力
マネジメント      プロジェクト定義力
            プロジェクト管理力
ネゴシエーション    共通認識構築力
            プレゼンテーション力




                        6
成績評価方法
 本 PBL では,主に下の表に記した各項目について,表中の%を目安に総合的に成績
を評価します.具体的には,活動ごとに,それにかけた時間と,かけた時間に見合った
成果物が作成されているかどうかを評価します.また,以下の 4 項目の評価基準のうち,
担当教員が 2 項目以上を満たさないと判断した場合は不合格とします.


             質的評価項目                  量的評価項目

                      (25%)                   (25%)
      適切なプロジェクト管理を実施した  プロジェクト活動時間(週 18 時間以下
      か?(PM として/メンバとして)        の場合は不合格)
活動  プロジェクトにおける自分の役割を理  週 1 回のコアミーティングへの出席回数
      解し,チームに貢献できたか?           (70%以下は不合格)
      プロジェクトの円滑な運営を支援する  月 1 回以上の教員レビューへの出席回数
      ための活動を実施したか?             (70%以下は不合格)

                      (25%)                   (25%)
      プロジェクトで定義した全てのドキュ  プロジェクトで定義した全てのドキュ
      メントの内容が,合格基準を満たして        メントに対し,一定量以上を作成した
      いるか?教員レビューにより合否を判        か?
      定する.                     発表会に関する成果物に対し,一定量以
成果
      ドキュメントの構成が適切であり,文       上を担当したか?
      章として読み易いものになっている  合格基準はメンバ数に依存するため,プ
      か?                       ロジェクト開始後に通知する.
      ソフトウェア開発プロジェクトのマネ
      ジメントが円滑に行えたか?




                          7

More Related Content

What's hot

失敗しないパッケージ導入5
失敗しないパッケージ導入5失敗しないパッケージ導入5
失敗しないパッケージ導入5小島 規彰
 
テストの視点を活用した TDD アプローチの検討とその検証
テストの視点を活用した TDD アプローチの検討とその検証テストの視点を活用した TDD アプローチの検討とその検証
テストの視点を活用した TDD アプローチの検討とその検証Akira Ikeda
 
テストスキルを測ってみよう
テストスキルを測ってみようテストスキルを測ってみよう
テストスキルを測ってみようAkira Ikeda
 
アジャイルクオリティの探求
アジャイルクオリティの探求アジャイルクオリティの探求
アジャイルクオリティの探求atsushi nagata
 
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するアジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するMakoto SAKAI
 
5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems
5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems
5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the ProblemsTakanori Suzuki
 
失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化
失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化
失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化Teruki Obara
 
ザ・ジェネラリスト #5000dai
ザ・ジェネラリスト #5000daiザ・ジェネラリスト #5000dai
ザ・ジェネラリスト #5000daikyon mm
 
配布用_仕様整理のためのテスト設計入門afterJaSST
配布用_仕様整理のためのテスト設計入門afterJaSST配布用_仕様整理のためのテスト設計入門afterJaSST
配布用_仕様整理のためのテスト設計入門afterJaSSTTetsuya Kouno
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)Hironori Washizaki
 
LINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 TrailerYasuharu Nishi
 
Automated testingindevopsstrategy.20210506
Automated testingindevopsstrategy.20210506Automated testingindevopsstrategy.20210506
Automated testingindevopsstrategy.20210506Toru Koido
 
テストプロセスについて
テストプロセスについてテストプロセスについて
テストプロセスについてKosuke Fujisawa
 
失敗しないパッケージ導入3
失敗しないパッケージ導入3失敗しないパッケージ導入3
失敗しないパッケージ導入3小島 規彰
 
Kaizen process with test #hackt
Kaizen process with test #hacktKaizen process with test #hackt
Kaizen process with test #hacktkyon mm
 

What's hot (16)

失敗しないパッケージ導入5
失敗しないパッケージ導入5失敗しないパッケージ導入5
失敗しないパッケージ導入5
 
テストの視点を活用した TDD アプローチの検討とその検証
テストの視点を活用した TDD アプローチの検討とその検証テストの視点を活用した TDD アプローチの検討とその検証
テストの視点を活用した TDD アプローチの検討とその検証
 
テストスキルを測ってみよう
テストスキルを測ってみようテストスキルを測ってみよう
テストスキルを測ってみよう
 
アジャイルクオリティの探求
アジャイルクオリティの探求アジャイルクオリティの探求
アジャイルクオリティの探求
 
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現するアジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現する
 
5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems
5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems
5WCSQ(CFP) - Quality Improvement by the Real-Time Detection of the Problems
 
失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化
失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化
失敗しない 3 次元 CAD 選びのポイントと Inventor を活用することで出来る作業の効率化
 
はじめてのPRD
はじめてのPRDはじめてのPRD
はじめてのPRD
 
ザ・ジェネラリスト #5000dai
ザ・ジェネラリスト #5000daiザ・ジェネラリスト #5000dai
ザ・ジェネラリスト #5000dai
 
配布用_仕様整理のためのテスト設計入門afterJaSST
配布用_仕様整理のためのテスト設計入門afterJaSST配布用_仕様整理のためのテスト設計入門afterJaSST
配布用_仕様整理のためのテスト設計入門afterJaSST
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
 
LINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 Trailer
 
Automated testingindevopsstrategy.20210506
Automated testingindevopsstrategy.20210506Automated testingindevopsstrategy.20210506
Automated testingindevopsstrategy.20210506
 
テストプロセスについて
テストプロセスについてテストプロセスについて
テストプロセスについて
 
失敗しないパッケージ導入3
失敗しないパッケージ導入3失敗しないパッケージ導入3
失敗しないパッケージ導入3
 
Kaizen process with test #hackt
Kaizen process with test #hacktKaizen process with test #hackt
Kaizen process with test #hackt
 

Viewers also liked

Open book & close book
Open book  & close bookOpen book  & close book
Open book & close bookBoom ReeDsmit
 
20111106 innovation and market
20111106 innovation and market20111106 innovation and market
20111106 innovation and marketHendrik de Lange
 
20111026 octrooi en veiling
20111026 octrooi en veiling20111026 octrooi en veiling
20111026 octrooi en veilingHendrik de Lange
 
ビジネスアプリケーション特論 2013-09-02
ビジネスアプリケーション特論 2013-09-02ビジネスアプリケーション特論 2013-09-02
ビジネスアプリケーション特論 2013-09-02Yoshihide Chubachi
 
Patents or open source, are patents good for us?
Patents or open source, are patents good for us?Patents or open source, are patents good for us?
Patents or open source, are patents good for us?Hendrik de Lange
 
20121127 innovation is like sex
20121127 innovation is like sex20121127 innovation is like sex
20121127 innovation is like sexHendrik de Lange
 
S curve presentation www.crowd-funders.nl
S curve presentation www.crowd-funders.nlS curve presentation www.crowd-funders.nl
S curve presentation www.crowd-funders.nlHendrik de Lange
 

Viewers also liked (8)

Open book & close book
Open book  & close bookOpen book  & close book
Open book & close book
 
20110606 apen-chubachi
20110606 apen-chubachi20110606 apen-chubachi
20110606 apen-chubachi
 
20111106 innovation and market
20111106 innovation and market20111106 innovation and market
20111106 innovation and market
 
20111026 octrooi en veiling
20111026 octrooi en veiling20111026 octrooi en veiling
20111026 octrooi en veiling
 
ビジネスアプリケーション特論 2013-09-02
ビジネスアプリケーション特論 2013-09-02ビジネスアプリケーション特論 2013-09-02
ビジネスアプリケーション特論 2013-09-02
 
Patents or open source, are patents good for us?
Patents or open source, are patents good for us?Patents or open source, are patents good for us?
Patents or open source, are patents good for us?
 
20121127 innovation is like sex
20121127 innovation is like sex20121127 innovation is like sex
20121127 innovation is like sex
 
S curve presentation www.crowd-funders.nl
S curve presentation www.crowd-funders.nlS curve presentation www.crowd-funders.nl
S curve presentation www.crowd-funders.nl
 

Similar to 2012年度中鉢PBLシラバス

【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用智治 長沢
 
19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューションDevelopers Summit
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?Kiro Harada
 
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」Yusuke Suzuki
 
ID説明資料20130107ver1.0
ID説明資料20130107ver1.0ID説明資料20130107ver1.0
ID説明資料20130107ver1.0Norihiro Oku
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 智治 長沢
 
採用と育成スキームの科学13(配布用資料)
採用と育成スキームの科学13(配布用資料)採用と育成スキームの科学13(配布用資料)
採用と育成スキームの科学13(配布用資料)Yohei SUZUKI
 
博士論文公聴会
博士論文公聴会博士論文公聴会
博士論文公聴会Makoto SAKAI
 
Id説明資料20130107Ver1.1
Id説明資料20130107Ver1.1Id説明資料20130107Ver1.1
Id説明資料20130107Ver1.1Norihiro Oku
 
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsakaビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka智治 長沢
 
プロジェクト管理ツール
プロジェクト管理ツールプロジェクト管理ツール
プロジェクト管理ツールAtsushi Heito
 
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~mafujiwara
 
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps智治 長沢
 

Similar to 2012年度中鉢PBLシラバス (20)

To be sn agile enterprise
To be sn agile enterpriseTo be sn agile enterprise
To be sn agile enterprise
 
【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用
 
Xp2
Xp2Xp2
Xp2
 
19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション
 
Xp2 2014版
Xp2 2014版Xp2 2014版
Xp2 2014版
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?
 
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
 
Scrum"再"入門
Scrum"再"入門Scrum"再"入門
Scrum"再"入門
 
Xp2 2013版
Xp2 2013版Xp2 2013版
Xp2 2013版
 
ID説明資料20130107ver1.0
ID説明資料20130107ver1.0ID説明資料20130107ver1.0
ID説明資料20130107ver1.0
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
 
採用と育成スキームの科学13(配布用資料)
採用と育成スキームの科学13(配布用資料)採用と育成スキームの科学13(配布用資料)
採用と育成スキームの科学13(配布用資料)
 
博士論文公聴会
博士論文公聴会博士論文公聴会
博士論文公聴会
 
Id説明資料20130107Ver1.1
Id説明資料20130107Ver1.1Id説明資料20130107Ver1.1
Id説明資料20130107Ver1.1
 
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsakaビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
 
プロジェクト管理ツール
プロジェクト管理ツールプロジェクト管理ツール
プロジェクト管理ツール
 
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
 
Enterprise DevOps
Enterprise DevOpsEnterprise DevOps
Enterprise DevOps
 
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
 
20050809
2005080920050809
20050809
 

More from Yoshihide Chubachi

豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」
豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」
豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」Yoshihide Chubachi
 
協創型ソフトウェア開発 ガイダンス資料
協創型ソフトウェア開発 ガイダンス資料協創型ソフトウェア開発 ガイダンス資料
協創型ソフトウェア開発 ガイダンス資料Yoshihide Chubachi
 
2012年度中鉢PBL説明会資料
2012年度中鉢PBL説明会資料2012年度中鉢PBL説明会資料
2012年度中鉢PBL説明会資料Yoshihide Chubachi
 
財務局プレゼンテーション
財務局プレゼンテーション財務局プレゼンテーション
財務局プレゼンテーションYoshihide Chubachi
 

More from Yoshihide Chubachi (6)

豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」
豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」
豊橋技術科学大学特別講演「PBLによるソフトウェア工学教育」
 
AIIT Scrum
AIIT ScrumAIIT Scrum
AIIT Scrum
 
協創型ソフトウェア開発 ガイダンス資料
協創型ソフトウェア開発 ガイダンス資料協創型ソフトウェア開発 ガイダンス資料
協創型ソフトウェア開発 ガイダンス資料
 
2012年度中鉢PBL説明会資料
2012年度中鉢PBL説明会資料2012年度中鉢PBL説明会資料
2012年度中鉢PBL説明会資料
 
財務局プレゼンテーション
財務局プレゼンテーション財務局プレゼンテーション
財務局プレゼンテーション
 
PM勉強会2010
PM勉強会2010PM勉強会2010
PM勉強会2010
 

2012年度中鉢PBLシラバス

  • 1. PBL タイトル:ソフトウェア開発プロジェクトのマネジメント方法論 主担当教員:中鉢欣秀 准教授 副担当教員: この PBL の目標(教育理念、教員からのメッセージ) この PBL では短納期・少人数のソフトウェア開発プロジェクトにおけるプロジェク トマネジャーを育成するためのトレーニングメソッドを確立することを目標にします. プロジェクト管理の知識体系として PMBOK が有名です.しかしながら,近年主流と なりつつあるアジャイル型のソフトウェア開発に PMBOK をそのまま適用することは 困難です.一方で,アジャイル型の開発プロセスをマネジメントする手法を適用するた めの確たる方法論がないこともまた事実であり,技術者教育を困難にしています. そこで,本 PBL ではアジャイル型の開発に適応できる人材育成にふさわしい,コー チング法や教材などを作成することを目標とします.その上で,この成果を実際のソフ トウェア開発プロジェクトに適用して有用性を検証します. プロジェクト課題(プロジェクトテーマ) 本年度の前期(1,2Q)では,簡単なソフトウェア開発プロセス(ミニプロジェクト) を実施します.目的はソフトウェアを作ることではなく,アジャイル型のイテレーショ ンサイクルを上手に回すための方法について検討することです.特に難しいソフトウェ アを作るわけではないため,ソフトウェア開発のためのスキルはさほど必要としませ ん.これらの開発経験を通して,アジャイル技術者育成のための教材に必要なコンテン ツを明らかにします. 後期(3,4Q)では,前期で得た知見を生かし,短納期・少人数のソフトウェア開発 をマネジメントします.ここでは,前期で検討した教育法をプロジェクトに対して適用 し,その効果について評価します.マネジメントをする対象としては,学部の学生(ベ トナム国家大学および慶応義塾大学 SFC)を予定しています. 以上の活動を通して,自分自身がアジャイル型のソフトウェア開発におけるエッセン スを身につけると共に,最終的には,他の技術者を教育するためのトレーニング教材を 作成して公開することを目標とします. プロジェクトの特徴(特長)  アジャイル開発を実際にコーチングしている専門家のアドバイスがもらえる予定です.  ソフトウェア開発プロセスの方法論を,実際のプロジェクトマネジメントを通して身につける ことができます.  VNU との活動を通して,英語によるコミュニケーションスキルが向上します.  この PBL の活動はプロジェクトマネジメントに関する研究として捉えることもでき ますので,希望する学生がいれば, PBL の主たる活動のほかに学会発表のための論 本
  • 2. 文指導も行います(ただし,学会発表の成果のみで単位を認めることはありません) .  和気藹々と楽しく活動することがモットーです.飲み会や合宿も企画します. 過去の実績など  2011 年度は,前期にプロジェクトマネジメントガイドブックを作成しました.後期に は,5 つのプロジェクトを各メンバが分担してマネジメントを行いました.Facebook アプリ,Android アプリ,Web アプリなどを開発しました. プロジェクト実施により身に付けるべき達成目標、到達目標(評価軸として利用)  少人数のソフトウェア開発を通し,PMBOK などの関連知識も踏まえた上で,技術者 教育のためのトレーニングメソッドをまとめること  実際のソフトウェア開発プロジェクトのマネジメントを経験し,そこから学んだ知見 を整理してまとめるすること. 履修条件(プロジェクトメンバになるための前提条件)  必ずしもプログラミングができなくてもよいですが,過去に何らかのソフトウェア開 発プロジェクトに所属して仕事を行った経験があることが望ましいです.不安な方は 事前に相談してください.  プロジェクトの活動は水曜日をコアタイムとし,土曜日は作業やレビューの時間にし ます.  なお,慶應義塾大学の PBL のマネジャーを担当する場合に限り,毎週金曜日の午後に 湘南藤沢キャンパス(神奈川県藤沢市)でのミーティングに参加して頂く予定です(た だし,このことの可否はプロジェクトメンバになるための必須条件ではありません) メンバ決定ルール(プロジェクト配属における優先順位の決定方法)  成績順(2010 年度 4Q 終了時点の GPA を利用します) 提示したテーマを実施するための最少メンバ数 3 名 2
  • 4. 各アクティビティの説明(1Q,2Q) 番号 アクティビティ名 活動内容 主な成果物 修得できるスキル,コン ピテンシー 1 プロジェクト計画 2 プロジェクト計画 プ ロ ジ ェ ク ト 課 題  プロジェクト計画  ビジョン設定力 を確認する 書  プロジェクト定義力 プ ロ ジ ェ ク ト チ ー  全体工程表  プロジェクト管理力 ム,メンバ,プロジ  コスト,リソース ェクトが必要とす 分析 る役割を確認する プ ロ ジ ェ ク ト 計 画 を作成する 3 ミニプロジェクト 4 ツールと技法の調 ア ジ ャ イ ル 開 発 マ  調査報告書  情報収集力 査 ネジメントの技法  研究動向調査力 を調査する  関連研究調査力 ア ジ ャ イ ル 開 発 の ツールを調査する 5 トレーニング ア ジ ャ イ ル コ ー チ  トレーニング成果  アジャイル開発能力 からトレーニング を受ける 6 開発プロジェクト プ ロ ジ ェ ク ト マ ネ  アジャイル型ソフ  文書作成力 ジメント技法の検 トウェア開発体験  課題設定力 証とトレーニング  課題解決力 方法の検討 7 トレーニングメソッド 8 トレーニングメソ ト レ ー ン イ グ の 内  トレーニングメソ  文書作成力 ッドの開発 容を検証する ッド(教材等)  課題設定力  課題解決力  課題まとめ力 4
  • 5. 各アクティビティの説明(3Q,4Q) 9 メソッドの適用 10 トレーニングを実 プ ロ ジ ェ ク ト メ ン  トレーニング経験  トレーニング能力 施する バ候補に対して,ト レーニングを行う 11 プロジェクトマネジメント 12 プロジェクトマネ ソ フ ト ウ ェ ア 開 発  ソフトウェア  プロジェクトマネジ ジメント プロジェクトのマ  仕様書・設計書等 メント力 ネジメント  プロジェクトマネ  システム設計力 ジメント報告書  詳細仕様作成力  システム実装力  開発環境構築力  設計書作成力  テスト計画作成力 13 メソッドの評価 14 トレーニングメソ 実 施 し た ト レ ー ニ  トレーニングメソ  分析力 ッドの評価・検証 ングメソッドが有 ッドの検証  整理力 効に機能したかど うかを検証する 15 発表準備 最 終 発 表 の 準 備 を  プレゼンテーショ  省察力 する ン  発表力  パネル 5
  • 6. 修得できるスキル、コンピテンシーと7つの基本コンピテンシーとの関係(まとめ) 基本コンピテンシー 修得できるスキル、コンピテンシー 発想力 ビジョン設定力 課題設定力 課題解決力 課題まとめ力 要求実現力 研究成果総括力 マーケット感覚 情報収集力 市場動向調査力 ニーズ分析 情報収集力 研究動向調査力 関連研究調査力 関連技術調査力 ドキュメンテーシ 仕様書作成力 ョン 方式記述力 設計書作成力 開発計画書作成力 報告書作成力 モデリングとシス 要求モデル作成力 テム提案 実現性検証力 システム設計力 詳細仕様作成力 開発環境構築力 システム実装力 テスト計画作成力 評価モデル作成力 評価計画作成力 評価実験実行力 実験結果分析力 マネジメント プロジェクト定義力 プロジェクト管理力 ネゴシエーション 共通認識構築力 プレゼンテーション力 6
  • 7. 成績評価方法 本 PBL では,主に下の表に記した各項目について,表中の%を目安に総合的に成績 を評価します.具体的には,活動ごとに,それにかけた時間と,かけた時間に見合った 成果物が作成されているかどうかを評価します.また,以下の 4 項目の評価基準のうち, 担当教員が 2 項目以上を満たさないと判断した場合は不合格とします. 質的評価項目 量的評価項目 (25%) (25%)  適切なプロジェクト管理を実施した  プロジェクト活動時間(週 18 時間以下 か?(PM として/メンバとして) の場合は不合格) 活動  プロジェクトにおける自分の役割を理  週 1 回のコアミーティングへの出席回数 解し,チームに貢献できたか? (70%以下は不合格)  プロジェクトの円滑な運営を支援する  月 1 回以上の教員レビューへの出席回数 ための活動を実施したか? (70%以下は不合格) (25%) (25%)  プロジェクトで定義した全てのドキュ  プロジェクトで定義した全てのドキュ メントの内容が,合格基準を満たして メントに対し,一定量以上を作成した いるか?教員レビューにより合否を判 か? 定する.  発表会に関する成果物に対し,一定量以 成果  ドキュメントの構成が適切であり,文 上を担当したか? 章として読み易いものになっている  合格基準はメンバ数に依存するため,プ か? ロジェクト開始後に通知する.  ソフトウェア開発プロジェクトのマネ ジメントが円滑に行えたか? 7