ソフトウェア・シンポジウム2017 in 宮崎

コンテンツ開発プロジェクトとソフトウェア開発プロジェクトのマネージメント知見の類似性探究の試行報告
日下部 茂
長崎県立大学片平 梓
長崎県立大学要旨

青木 研
長崎県立大学の経験をもとにした段階的な実践力の養成をカリキュラ
ム内だけで実施することは困難である．図 1 に情報シス

創造性にもとづいて知的作業成果物を作成するというテム学科のカリキュラムツリーを示す．例えばプロジェ

観点から，ソフトウェアの開発と映像のようなコンテン

クトマネージメントに関して，座学が二年の後期，プロツの開発には共通点があると考える．例えば，開発支援ジェクト型のチーム型演習が三年開講されるものの，カ技術の進歩でルーチン作業の負荷は削減される傾向があ

リキュラム内で以前の経験の結果の振り返りを行いながると同時に，大規模複雑化が進み上流工程では明確な見らプロジェクトマネージメントの実践力を向上させるサ通しを得にくいけれども，上流工程での欠陥は後工程でイクルを複数実施することは難しい．

大きな問題となってしまう可能性が高い．本発表では，我々はこのような問題に対して，課外での開発・創作類似性がある領域のプロジェクトのマネージメントには活動を積極的に支援すると同時に，その知見の蓄積や共類似性があるとの仮定の下，大学での教育研究活動にお有も推進している．本発表では，そのような取り組みのいてコンテンツ開発プロジェクトにソフトウェア開発プ一つとして行っている，大学内でのコンテンツ開発プロロジェクト管理の知見を適用する試みと，その予備評価

ジェクトにソフトウェア開発のプロジェクトマネージメについて述べる．

ントの知見を適用する試みとその予備評価について述べる．
本稿の構成は以下の通りである．第 2 節で，今回の取1. はじめにり組みで対象とした映像コンテンツ作成プロジェクトについて説明する．第 3 節で，適用を試みたソフトウェア著者らが所属する長崎県立大学の情報システム学部・開発のプロジェクトマネージメントの知見を説明する．

情報システム学科は，平成 28 年度から改組新設された

第 4 節は，学生視点での振り返りを行う．また，第 5 節学科である．一般の情報工学系の学科と比べ，デザイン・は，考察と今後の課題を述べる．第 6 節でまとめを行う．

コンテンツ系の教員の比率が高く，IT 分野における「アイデアを形にする能力」を重視し，「デザインもできる技2. 映像コンテンツ作成プロジェクト術者」や「 技術もわかるデザイナー」の育成を目指している．創造性を発揮して知的作業成果物を作成すると

本節では，ソフトウェア開発のプロジェクトマネージいう点から，ソフトウェアの開発と映像を含む多様なメメントの知見を適用した，大学内でのコンテンツ開発プディアコンテンツの開発には共通点があると考え教育研ロジェクトについて説明する．

究を進めている．
教育研究内容については，要素技術の知識やスキルだ

2.1. プロジェクトの目的

けでなくシステム開発やプロジェクトマネージメントの実践力も重視し，カリキュラム内だけでなく課外の活動映像制作をおこなうには様々な技術やノウハウが必要も含めて継続的な改善に取り組んでいる．しかしながら，とされ，そのすべてを横断的に網羅して一度に教育するこ

様々な制約から，すべてに関して，座学だけでなく実際とは困難である．そこで，PBL(Project-Based Learning)

111

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 1. 情報システム学科のカリキュラムツリーの手法を用い，短編映画製作を企画して，学生と教員，ている．このような環境の中で，これらの作品に対抗し映像制作の専門家の共同作業による実践的な映像制作をうる作品作りのノウハウを，学生自ら経験的に学んでい試行する課外活動プロジェクトを実施している．その過く教育方法の確立を目指す．

程では以下を得ることを目指す．

2.2. プロジェクトの概要• 参加学生に対する教育効果

映像制作を後述のように，プリプロダクション（企画，• PBL による教育ノウハウの蓄積脚本，ロケハン），プロダクション（撮影），ポストプ• 教育のための教員の実践的技能の向上

ロダクション（編集，整音，色補正，CG 等）のフェーズに分けて考えた上で，プロジェクトを実施する．さら• 公的なコンペティションによる作品評価と実績に，用いる要素技術を段階的に高度化し，プロジェクト

教員や専門家との PBL 型の共同作業を通して学生が主を段階的に高度化，複雑化していく．

体的に学び，コンペティションで採択されるレベルの作品作りを目指しながら，定型的な教育が難しい映像制作

プリプロダクションの技術とノウハウの模索と蓄積を試行する．
現在，映像系コンペティションは，海外においては戦略的な国家予算をつぎ込んだアジア諸国の大学の作品，国内においてはプロモーション目的で映像プロダクショ• 短編映画作品企画：参加学生を募り，短編映画の作品企画を立てる．
• 脚本制作：企画に沿って脚本制作をおこなう．

ンが制作した作品といったものが，インターネットを通• ロケハン 脚本推敲：脚本から撮影場所を決定する．

して広く応募されており，極めてレベルが高くなってき

112SEA

ソフトウェア・シンポジウム2017 in 宮崎

ロケハンによる撮影条件の検討から，脚本の推敲を重要とされ，上流工程が重要視され上流工程からモデルおこなう．

を活用することも普及している．同様に，映像分野でもVFX(ビジュアルエフェクト) を用いた工程の複雑化が進プロダクション

む一方，上流工程からプレビズを活用するといった上流• 出演者決定 リハーサル 美術製作 撮影準備：出演者を決定し，脚本の読み合わせなどリハーサルをおこ重視の傾向が強くなっている．さらに，どちらも，プロなう．出演者には，一部プロを援用する．美術の設状況に応じてテーラリングや改善を継続的に行うことが計と製作をおこなう．美術製作には一部プロを援用重要という点でも共通点がある．

セスを一旦構築すればそれで終わりということはなく，する．カメラテストや撮影許可の申請など，撮影準

3.1. アプローチの概要

備をおこなう．

• 撮影：撮影をおこなう．撮影にあたっては，機材運

今回のアプローチでは，要素技術もマネージメント技

搬車，出演者とスタッフの移動用のロケバス等の車術も段階的に高度化させていくという前提で，最初の両をレンタルする．照明には一部プロの援用と機材段階では，プロジェクトで用いる要素技術も適用するマレンタルをおこなう．

ネージメントの知見も高度なバックグラウンドがなくとも取り組みやすいものを中心とした．まず，入門的な要

ポストプロダクション

素技術を用いて映像コンテンツを作成するプロジェクト• 撮影後の編集，整音，色補正，CG 制作等をおこなう．

を実施，その後プロジェクトマネージメントの担当者が，ソフトウェア開発プロジェクトのマネージメントの入門• コンペティション応募準備 上映会（公開講座）準
備：コンペティションのリサーチや英語字幕の制作など，コンペティション応募準備をおこなう．上映

的な教材を読み，自身の体験の振り返りを行い適用可能な知見について考察した．

会（公開講座）用のプレゼン準備と，開催場所の確

3.2. 教材の概要

保，上映機材の手配をおこなう．

今回は，入門的な教材として， トム・デマルコの「プ• コンペティション応募 上映会（公開講座）開催

ロジェクト管理」がわかる本 [1] を採用した．その書籍では，章の見出しレベルで，以下の内容が紹介されてい3. 探究アプローチる 1．

この節では，コンテンツ開発プロジェクトでも適用可

1. プロジェクト管理は心の管理

能な，ソフトウェア開発プロジェクトのマネージメント

2. 生産性を向上させるオフィス環境の知見を探究する今回のアプローチについて説明する．
我々は，類似性がある領域ではプロジェクトの効果的

3. チーム力を上げるなマネージメントにも類似性があるとの仮定にもとづいて取り組みを行っている．ソフトウェアの開発と映像

4. プロジェクトを成功させる組織のようなコンテンツの開発では，創造性にもとづいて知5. デマルコのプロジェクト管理術的作業成果物を作成するという点だけでなく様々な類似性があると考える．開発支援技術の進歩でルーチン作業

6. ソフトウェア開発におけるリスク管理の負荷は削減される傾向があると同時に，大規模複雑化

7. リスク管理の手順が進み上流工程で明確な見通しを得にくい上に上流工程での欠陥は大きな問題となってしまう，といった点など

プロジェクト管理については，プロジェクトマネジメ

共通点が多いと考える．ソフトウェア開発では，効率のント協会 (PMI: Project Management Institute) が発向上や品質の向上には要素技術だけでなく，ソフトウェ行している PMBOK ガイド (A Guide to the Project

アの開発プロセスも含めたライフサイクルプロセスが

1 節レベルの見出しは付録参照

113

SEA

ソフトウェア・シンポジウム2017 in 宮崎

Management Body of Knowledge)[2] をはじめとしてガイドや入門書が多数あるが，高度なバックグラウンドがなくとも読みやすいものを今回の教材とした．

4.2. 生産性を向上させるオフィス環境「生産性を向上させるオフィス環境」については，4 項目中，3 項目について共感し，1 項目は共感しなかった．

4. 事後分析
職場を楽しいところにするためには 「職場に小さな混
この節では，学内プロジェクトのマネージメントの担乱を導入」ということで，コンテストの開催やブレイン当者による振り返りを紹介する．また，各大項目ごとに，ストーミングが提唱されているが，これは積極的に行っ共感を感じた小項目と，共感しなかった小項目をカウンていきたい．12 月に開催したクリスマス会は，そのいトした結果を示す．特に学生が共感したものについてはい例だと感じた．そのときに行った「青春選手権」といその内容を引用 (一部改編) して示した．

う企画は，元々はまだあまり話したことないメンバー同士や，初めて参加したメンバーとの仲を深めることが目的だったが，私自身を含め，とても刺激になった．また，

4.1. 「プロジェクト管理は心の管理」

プロジェクトチームの今後の方針や動きについてのブレ「プロジェクト管理は心の管理」の 8 項目中，7 項目インストーミングを行ってみたいと思った．コンテスト，について共感し，1 項目は共感しなかった．というほどのことではないが，脚本，編集，撮影，演出などで競うということも今後やっていきたい．
」

管理者が陥る七つの錯覚 「『気をつけたい 7 つの錯覚』のような状態に実際に陥った．進捗管理をまめに行い，4.3. チーム力を上げる

各連絡はもっと確実に頻繁に取れ，もっと簡単により自動化したシステムでスケジュール管理や進捗管理が行え，「チーム力を上げる」に関しては，10 項目中，3 項目

多少厳しいことを言った方がいいはずだ，などをいつもについて共感し，4 項目は共感しなかった．3 項目につ考えていた． 部下を働かせるのではなく，働く気にさいてはどちらでもなかった．

せるとあったことに気づきを得た．
」

4.4. プロジェクトを成功させる組織
品質第一主義は開発者の自尊心 「『マーケットの要求』に対するものとして，プロジェクトチームの実績をはや「プロジェクトを成功させる組織」に関しては，6 項

く作りたい，という自身の気持ちや，後に延ばせば延ば目中，2 項目について共感し，2 項目は共感しなかった．

すだけ結局雑になるのでは，という疑問から，品質やメ2 項目についてはどちらでもなかった．

ンバーの意向を無視して『自尊心』を満たせていないと伝染する管理者の怒り 「怒りは恐怖の別の表現，とい感じた．作品でも，結果として詰め込んだスケジュールうことであるが，確かに私自身に当てはまる．このままでの撮影で疲労や焦りで後半はあまりいい演出を行えな完成できないのではないか，今更このような変更をしてかった．
」

うまくいくのだろうか，今の段階でこの話合いをして撮影までに間に合うのだろうが，というような不安からつ生産性向上に関する法則とリスク管理 「リスク管理が足りてないということは痛感した．無駄な時間が多い．

いイライラすることは頻繁にある．実際にその場で怒りを表現したことはあまりないが，恐らくメンバーは察知

しかし，映画制作から無駄をなくしていいのだろうかとして気を遣ってくれていると思う．私が感情的になっての懸念もある．楽しんでやること，遊び心が，より良いいては，円滑に動かないことも考えられるので，むしろ作品を生み出すとも考えられるので，バランスを意識し私がメンバーの心情を汲んで話合い等を進めていけたらなくてはいけないと考える．
」と思う．
」

114

SEA

ソフトウェア・シンポジウム2017 in 宮崎

4.5. デマルコのプロジェクト管理術

4.6. ソフトウェア開発におけるリスク管理「デマルコのプロジェクト管理術」に関しては，10 項「ソフトウェア開発におけるリスク管理」に関しては，目中，1 項目について共感し，7 項目は共感しなかった．

2 項目についてはどちらでもなかった．

12 項目中，共感する項目はなく，8 項目は共感しなかった．4 項目についてはどちらでもなかった．この結果は，ソフトウェア固有の事項が該当しないといった，領域の計画の変更を恐れてはならない 「今回の撮影でもあっ違いによるものなのか，まだリスク管理を考える域までたが，撮影の日になって突然脚本の内容や演出を変更す達していないためなのか，といったいくつかの理由が考ることがある．もちろん，必要なことであり，よりよいえられるため，今後より詳細な分析を続ける予定である．

作品とするため，その変更についてはむしろプラス方向で捉えている．しかし，その変更により，撮影時間が伸「大人」のプロジェクト管理 「リスクについては本当び，スケジュール通りに動かない．そこで，撮影も後日，に管理できないと感じている．起きてほしくないことを話合いも後日，と，日程が延期されていく．自分自身の，放置，または，なんとかなる，で片づけている．書き出実績を得なければ，もっと作品を作らなければ，というしてまとめて，対策を考えることも行いたい．
」

焦りも相まって，延期されていく（予定のスケジュールを変更する）ことにとても抵抗がある．抵抗はあるが，4.7. リスク管理の手順仕方ない，私の計画ミスだ，と考えてきたが，この節を読んで腑に落ちた．実際，撮影のスケジュールは，限ら「リスク管理の手順」に関しては，共感する項目はなれた時間で撮影を終えるため，詰め込んだスケジュールかった．この結果に関しては，領域の違いによるものなになっていた．疲労や空腹から，全体の空気も悪くなっのか，まだリスク管理を具体的に考える域まで達してていた．私のミスだ，と自分を責めることは簡単だが，いないためなのか，今後より詳細な分析を続ける予定でそれは責任と向き合っていない．より柔軟な対応を心掛ある．

けたい．
」

5. 考察と今後の課題
プロジェクト初期は少人数で 「設計段階では少数精鋭で会議を行う，ということは取り入れてみたい．各部でソ フ ト ウェア 開 発 の 領 域 で は ，例 え ばの責任者が全体の現状を把握できてないことで，部と部CMMI(Capability Maturity Model Integration)[3]2のようなプロセスモデルや TSP(Team Software Pro-での連携が取れていない．どの段階で少数でのミーティcess)/PSP(Personal Software Process)[4] [5] 3 のようなプロセステンプレートが提案され，実際に活用もさングを行うかは考える必要があるが，作品の初期段階で行いたい．
」

れている．当初はそのようなものを利用してコンテン
無駄な会議の減らし方 「よく『参加できなくてごめん』

ツ系のプロジェクトの教育を実施できないかとの検討とメンバーから言われる．プロジェクトチームの方針とも行った．しかしながら，ソフトウェアの開発とコンして，来られるとき，来られるメンバーが来る，というテンツ系の開発では考慮すべきことは必ずしも同じでことになっている．しかし，参加してもらわないと困るはない一方，コンテンツ領域において今回の趣旨にそっ人ももちろんいる．その一方，実際，無駄だと思うミーた形で利用できるテンプレートや参照モデルを見つけティングの時間もある．
「次のミーティングで何をする」

ることができなかった．という宣言により，誰が来なくても大丈夫か，というこまた，仮にそのようなものがあったとしても，プロとをはっきりさせたい．参加できないことを申し訳なくジェクト管理やプロセスの教育は，学生自らがある程度思わせることを減らすことで，より気軽な集まりにできの開発経験を経てその必要性を感じてからでないと，効たらいい．
」

果的に実施することが困難である可能性がある．著者の
2 CMM & CMMI are registered in the U.S. Patent and Trademark Oﬃce by Carnegie Mellon University.
3 TSP & PSP are service marks of Carnegie Mellon University.

115

SEA

ソフトウェア・シンポジウム2017 in 宮崎

一人は，個人レベルのソフトウェア開発 PSP(PersonalSoftware Process) のインストラクタとして大学でそのトレーニングコースを講義・演習として行った経験がある．PSP は，CMM(Capability Maturity Model, CMMIの前身) のレベル 5 相当の組織でのエンジニアを想定して提案されており [6] ，学生にとっても有用でないかと考えた．しかしながら，実際には該当科目を選択する学生数も多くなく，トレーニングコースの完了率も高くなかった 4 ．そういった経験もあり，モデルやテンプレートがあったとしても，学生がもつ知識やスキルのレベル，プロジェクトでの学生の役割やプロジェクトの特性などに応じて，プロジェクト遂行時に学生が実際にどのよう
図 2. PSP のプロセスフローなことに必要性や重要性を感じるのか，といった観点で知見を集めることは重要と考えている．
学生が納得しやすいという観点で，4 節のような振り返りは有用である一方，系統だった整理・分類という観点では十分ではない．最終的には，多数の初学者を念頭に置いた学内の教育研究だけでなく，一定の経験をもつソフトウェア開発者やコンテンツ開発者の双方にとって有用な一般化された知見の構築も目指すしている．そのような観点では，ソフトウェア開発領域で一定の評価を得ている CMMI-DEV(開発のための CMMI) といった参照モデルや PSP のようなテンプレートのフレームワークは有効と考えている．

PSP では図 2 に示すようなベースのプロセスフローと，プロセス要素が段階的に高度化されたプロセスのテンプレート 3 が定めれらている．また，CMMI では表 1のように複数のプロセス領域が系統的にモデル化されて図 3. PSP の段階的高度化いる．このようなソフトウェア開発領域で一定の評価を得ているものを参考にすることで，ソフトウェア開発と6. おわりにコンテンツ開発での類似点や相違点も含め，双方の領域の開発者にとって有用な知見を取りとめることができる創造性にもとづいて知的作業成果物を作成するという考えている．

観点から，ソフトウェアの開発と映像のようなメディアこのような取り組みが成功すれば，ソフトウェア開発コンテンツの開発には共通点があると考え，大学内でのにおいて例えば UX(ユーザーエクスペリエンス) が重視

コンテンツ開発プロジェクトにソフトウェア開発のプロされる場合はコンテンツ開発の知見が有用になり，コンジェクトマネージメントの知見を適用する試行とその予テンツ開発において例えばデジタル化が進展するとソフ備評価について述べた．ソフトウェア開発のプロジェク

トウェア開発の知見の有用になる，といったことが予想トマネージメントの知見であっても，おおむね，領域にされる場合に，どのようなプロセス領域を重視し，どの非依存ともいえるものは，メディアコンテンツの開発プようにチームや個人レベルのプラクティスに反映すればロジェクトのマネージメントにも適用できる可能性が高よいか系統的に取り組めると考えている．

いという評価を得た．しかしながら，ソフトウェア固有の事項に関連付けられていたり，種々の想定を必要とす

4 このような傾向は，PSP を採用している他大学でも類似の傾向があると聞いている．

116

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1. 開発のための能力成熟度モデル統合 (CMMI-DEV) のプロセス領域
段階表現での成熟度レベルとプロセス領域
2: 要件管理 (REQM: Requirements Management)
2: プロジェクト計画策定 (PP: Project Planning)
2: プロジェクトの監視と制御 (PMC: Project Monitoring and Control)
2: 供給者合意管理 (SAM: Supplier Agreement Management)
2: 測定と分析 (MA: Measurement and Analysis)
2: プロセスと成果物の品質保証 (PPQA: Process and Product Quality Assurance)
2: 構成管理 (CM: Configuration Management)
3: 要件開発 (RD: Requirements Development)
3: 技術解 (TS: Technical Solution)
3: 成果物統合 (PI: Product Integration)
3: 検証 (VER: Verification)
3: 妥当性確認 (VAL: Validation)
3: 組織プロセス重視 (OPF: Organizational Process Focus)
3: 組織プロセス定義 (OPD: Organizational Process Definition)
3: 組織トレーニング (OT: Organizational Training)
3: 統合プロジェクト管理 (IPM: Integrated Project Management)
3: リスク管理 (RSKM: Risk Management)
3: 決定分析と解決 (DAR: Decision Analysis and Resolution)
4: 組織プロセス実績 (OPP: Organizational Process Performance)
4: 定量的プロジェクト管理 (QPM: Quantitative Project Management)
5: 組織実績管理 (OPM: Organizational Performance Management)5: 原因分析と解決 (CAR: Causal Analysis and Resolution)

るリスク管理に関する知見は，今後の取り組みでより詳

連続表現での区分
プロジェクト管理
プロジェクト管理
プロジェクト管理
プロジェクト管理
支援
支援
支援
エンジニアリングエンジニアリングエンジニアリングエンジニアリングエンジニアリング
プロセス管理プロセス管理プロセス管理プロジェクト管理
プロジェクト管理
支援
プロセス管理プロジェクト管理
プロセス管理支援[3] CMMI, http://cmmiinstitute.com/ (2017 年 5月 19 日参照)

細な分析を行う必要があると考える．
どちらの領域の開発でも，今後も引き続き支援技術が[4] Team Software Process, http://www.sei.cmu.

進化しルーチンワークは省力されると同時に，より一層edu/tsp/ (2017 年 5 月 19 日参照)

大規模複雑化が進み，プロジェクトマネージメントの重要性も増すためこのような取り組みの重要性も増すと考[5] Watts S. Humphrey, A Self-improvement Pro-えている．また，外部環境の変化，要素技術の進展，開cess For Software Engineers, Addison-Wesley Pub,2005.

発プロセスの上流重視の傾向などもあり，一定の知見が確立したとしても継続的な見直しが必要と考えている．

[6] Watts S. Humphrey, Software Process Improve-

今後は，カリキュラム内外でのプロジェクト経験，「企業研究」や「インターンシップ」といった科目での実務者との交流や現場体験からのフィードバックなども通して，蓄積，共有される知見の高度化を目指す予定である．

ment A Personal View: How it Started and Where
it is Going, Softw. Process Improve. Pract. 12:
223-227, Wiley InterScience, 2007.
付録： トム・デマルコの「プロジェクト管理」がわ

参考文献

かる本

[1] 吉平健治，トム・デマルコの「プロジェクト管理」がわかる本，秀和システム，2007の知見 (大項目と小項目)

1. プロジェクト管理は心の管理(a) プロジェクト失敗の本当の原因は?
(b) 管理者が陥る七つの錯覚[2] Project Management Institute, PMBOK (ProjectManagement Body of Knowledge) Guide,(c) 「管理ごっこ」をしていませんか?
(d) 品質第一主義は開発者の自尊心

http://www.pmi.org/pmbok-guide-standards/
foundational/pmbok (2017 年 5 月 19 日参照)(e) パーキンソンの法則は当てはまらない(f) プログラムは夜できあがる

117

SEA

ソフトウェア・シンポジウム2017 in 宮崎(g) 生産性向上に関する法則とリスク管理(h) リスク図による日程の解釈(h) プレッシャーと生産性の関係(i) 不確かなものへの不安

2. 生産性を向上させるオフィス環境

7. リスク管理の手順(a) 仕事に集中できるオフィスとは(a) リスク管理の五つのステップ(b) オフィス環境進化論(b) リスク発見の方法(c) 職場を楽しいところにするためには(c) リスクを隠してしまう会社文化(d) 破滅シナリオの提案

3. チーム力を上げる(e) 見えないリスクを発見する(a) 最高の人材を揃える(f) ソフトウェア開発でのリスク(b) 退職にまつわる無駄なコスト(g) リスク・エクスポージャー(c) 結束したチームがもたらす利益(h) インクリメンタル手法によるリスク軽減(d) 自己修復システムを使う(i) EVR による進捗管理(e) 結束させるためのチームの潰し方(j) 感度分析(f) チームを形成するための不思議な作用(k) 臆病なマネージメント(g) 部下，チームメンバを好きになれ(h) 体を使った採用術

4. プロジェクトを成功させる組織(a) 脅迫は効かない(b) 匿名性を使い「悪い情報」を伝達(c) 病んだ政治は避けられない(d) 伝染する管理者の怒り(e) 対立が仕様書をあいまいにする(f) 対立は仲裁によって解決する

5. デマルコのプロジェクト管理術(a) 失敗プロジェクトを打ち切る勇気が必要(b) 管理者の直観をモデル化する(c) 計画の変更を恐れてはならない(d) ソフトウェアのサイズを測定する(e) 開発プロセスに対しての考察(f) デバッグ時間を削減するには?
(g) 間違いを知らないのは一番怖い(h) プロジェクト初期は少人数で(i) 無駄な会議の減らし方

6. ソフトウェア開発におけるリスク管理(a) リスクのないプロジェクトには手を付けるな(b) 「大人」のプロジェクト管理(c) リスク管理と危機管理(d) リスク管理を行う理由(e) リスクを無視すると(f) 不確定性を数量化する(g) 不確定な日程の見積もり

118

SEA