【PM試験対策2】プロジェクト全般 その2
こんばんは、プロジェクトマネージャ試験対策の2回目です。
ところで、こちらの勉強の傍らでお金、というか資産形成の勉強をしています。
老後の心配とか今からしてもしょうがないと思うんですけど、まあ備えあれば憂いなしです。
巷では仮想通貨への投機（と暴落）が話題になってますが、まずは堅実に投信での積立からコツコツ勉強します。
本を読んでると断片的に聞きかじっていた情報の答え合わせのような感覚になりますね。
ちなみにこちらの本を使ってます。
マネジメントに全く関係ない話でした。今回もやっていきます。
プロジェクトマネジメント
- プロジェクトを難しくしている原因は期限付きかつ繰り返し性がないこと
- だからこそアジャイルなんて言葉が生まれるわけですね
- でも巨大システムだと予算の都合でWFになっちゃう
- プロジェクトマネジメントの方法論というのは、プロジェクト内での改善をほとんど行えないという性質を補うためのもの
- 賢者は歴史に学ぶ、ってことですかね
PMBOKとISO 21500
- PMBOK
- PMIの発行しているプロジェクトマネジメントの知識体系と応用のためのガイド
- これの試験もある（PMP）けど、実務経験が必要なのでIPAのやつにしたのでした
- そういえば前の会社の非エンジニアの先輩が読んでたような
- 第6版の日本語版はもうリリースされてる
- ISO 21500
- プロジェクトマネジメントの国際基準
- 認証を付与するものではなくガイドラインなので、空気
- たったの36ページに収まる
- PMBOKに準拠してマネジメントを説明していく
PMBOKのプロセス群と知識エリア
- プロセス
- するべき手順や手続きのこと
- 第5版では47プロセス
- 5つのプロセス群に分類可能
- 知識エリア
- プロジェクトマネジメントにおける概念、用語および活動の分野
- 「プロジェクト○○マネジメント」の形で10個の知識エリアが規定されている
- 統合
- スコープ
- タイム
- コスト
- 品質
- 人的資源
- コミュニケーション
- リスク
- 調達
- ステークホルダ
- プロセス群と知識エリアをマトリックスにしてみると、
- このマトリックスをみると、
- いかに計画と運用に重きが置かれているか
- いかに実行段階で人的資源が大事か
- いかに運用でスコープを守るのが大事か
- がよくわかる
PMBOKの特徴
- 以下の3点にまとめられる
- 世界標準なので、網羅性を重視
- 計画プロセスが重要なので、緻密な計画に則って進めていくやり方を想定
- 専門用語が多い
インプット、ツールと技法、アウトプット
- 各プロセスに定義されている
- 例示に過ぎないが、事前準備とゴール、実行プロセスがある程度明確になる
契約に関する知識
- 契約とは
- ある2者の公式の決め事で、書類に記載される
- 口約束での契約の成立ってどうなんですか、教えてエロい人
- 契約者になれるのは自然人と法人
- ある2者の公式の決め事で、書類に記載される
- 契約の原則1：契約自由の原則
- 当事者は契約を自由に決めることができる
- ただし、法律の強行規定を除く
- 例えば、麻薬取引の禁止など
- 引っ越したら突然やって来るなんとか協会は……？
- 契約の原則2：契約優先の原則
請負契約
- 以下の2点を満たす契約
- 請負人が注文者に対して、一定の業務の完成（例：ソフトウェアの完成と引き渡し）を約束
- 注文者が請負人に報酬を支払う
- ソフトウェア開発だと一番ポピュラーな契約
- ポイントは引き渡しがあること
- 民法に作業指示、状況報告、作業場所の規定がない
- 契約しないと、作業指示が出せなかったり、状況報告を強制できなかったりする
- つまり、さらに別会社に投げることが可能、ということに
- また、請負人には瑕疵担保責任がある
- ただし、請求は1年以内
委任契約と準委任契約
- 委任契約
- 当事者の一方が法律行為をしてもらうことを相手方に委託する契約
- 法律行為：意思表示によって法律的な効果が発生する行為
- 弁護士に代理で訴訟してもらうとか税理士に確定申告してもらうとか
- 準委任契約
- 法律以外の行為を相手方に委託する契約
- 民法上は委任契約と同じ扱いをされる
- 例えばITコンサルは準委任契約
- 以下の法的効力を与える
- 委任者は成果物の完成と引き渡しを約束しない
- 委任者は業務上の指示を出さない
- 受任者は管理者の注意義務を持って業務を遂行する
- 受任者は、委任者の依頼に応じて進捗報告の義務がある
- 受任者は、委任者に報酬を請求できる
派遣契約
- 以下を満たす契約
- 派遣元事業者が雇用している労働者を派遣
- 派遣先の指揮命令を受ける
- 派遣元事業者に指揮命令の権限がないというのもポイント
3つの契約の違い
- 直感的でないところを中心にまとめる
- 未完成責任、納期遅れ責任があるのは原則、請負契約のみ
- 委任契約にもありそうな気がするけど納期も委任ということに
- 状況報告の義務があるのは委任契約のみ
- この差はなんだろうか……
- 未完成責任、納期遅れ責任があるのは原則、請負契約のみ
偽装請負
- アクシアの社長がよく言ってるやつ
- 請負契約を締結しているのにもかかわらず、常駐先の指揮命令を受けるという業務実態のこと
- 人売の害悪は再度強調するまでもないでしょう
その他の契約
- ソフトウェアパッケージの使用許諾契約
- いわゆるライセンス契約
- 中が以下のように分かれる
- ボリュームライセンス契約
- インストール数を決めるやつ
- サイトライセンス契約
- 特定の施設で使い放題
- シュリンクラップ契約
- 標準の許諾をきめ、開封時に成立したとみなす
- 要は普通の店売りパッケージ
- ボリュームライセンス契約
- サーバ等のリース契約
- ファイナンス・リース契約
- 途中で解除できない契約
- ユーザの選んだものをリース会社が代わりに購入する
- オペレーティング・リース契約
- ファイナンス・リース以外のリース
- 普通にレンタルの契約
- ファイナンス・リース契約
- 守秘義務契約
- 別に説明しなくても良い気がする
- 守秘義務条項を請負契約に含める場合なども
請負契約における受注者のリスク削減
- リスクの数々
- 仕様変更しまくり
- 法改正などによる手戻り
- 発注側の仲間割れで要件定義遅延
- 新技術採用による性能不良
- このあたりの低減策を契約書に反映するのもPMのおしごと
- 契約範囲や期間の縮小
- 契約を細かく分ける
- 実装と単体テストだけ請負契約にする
- 低リスクな契約形態の選択
- 派遣契約はそもそも作業者に指示が出せない
- 委任契約は引き渡しを想定してないので適してない
- というわけで、要件定義や総合テストのフェーズのリスクが高い場合に委任契約にする場合が多い
- 逆に言えば、試験で準委任契約が選択されていたら何らかのリスク要因があるとみてよい
- 請負契約書に金額・納期の見直し条項を追加
- 仕様変更しまくることにリスクを乗せる
- フェーズを限定したり、定量的な表現に変えても良い
- けど、基本的にPMには不利
- 仕様変更が起きた場合は別契約を結ぶのもあり
- これなら確実にほぼ確実にカネが取れる
- また、契約形態の切れ目のリスクは慎重に担保しておくべき
- 外部設計を客に任せるなら、カネと納期を融通してもらう契約に
- 質問にすぐ答えてもらえるような契約に
- 契約範囲や期間の縮小
問題演習から
- ステークホルダは個人として特定できていなくても良い
- 例えば、新製品を購入する一般消費者もステークホルダ
- システム化計画書を作るのはITストラテジスト
- プロジェクトガバナンスを維持する組織はプロジェクトよりも上
- プロセス資産は「プロセスと手順」「企業の知識ベース」の2つに分かれる
- 請負契約の場合、客先作業の場合の指揮命令権は受注先にある
「プロジェクト全般」はここまで。次は「プロジェクト統合マネジメント」です。
