部屋の隅っこで書く技術ブログ

中の人は20代後半Web系エンジニアです。テーマは闇鍋ですが、マネジメント、Ruby/Rails、ブロックチェーンの話題が多めです。

【PM試験対策2】プロジェクト全般 その2

f:id:expajp:20180118010425p:plain

こんばんは、プロジェクトマネージャ試験対策の2回目です。

expajp-tech.hatenablog.com

ところで、こちらの勉強の傍らでお金、というか資産形成の勉強をしています。

老後の心配とか今からしてもしょうがないと思うんですけど、まあ備えあれば憂いなしです。

巷では仮想通貨への投機(と暴落)が話題になってますが、まずは堅実に投信での積立からコツコツ勉強します。

本を読んでると断片的に聞きかじっていた情報の答え合わせのような感覚になりますね。

ちなみにこちらの本を使ってます。

マネジメントに全く関係ない話でした。今回もやっていきます。

プロジェクトマネジメント

  • プロジェクトを難しくしている原因は期限付きかつ繰り返し性がないこと
    • だからこそアジャイルなんて言葉が生まれるわけですね
    • でも巨大システムだと予算の都合でWFになっちゃう
  • プロジェクトマネジメントの方法論というのは、プロジェクト内での改善をほとんど行えないという性質を補うためのもの
    • 賢者は歴史に学ぶ、ってことですかね

PMBOKとISO 21500

  • PMBOK
    • PMIの発行しているプロジェクトマネジメントの知識体系と応用のためのガイド
    • これの試験もある(PMP)けど、実務経験が必要なのでIPAのやつにしたのでした
    • そういえば前の会社の非エンジニアの先輩が読んでたような
    • 第6版の日本語版はもうリリースされてる
  • ISO 21500
    • プロジェクトマネジメントの国際基準
    • 認証を付与するものではなくガイドラインなので、空気
    • たったの36ページに収まる
  • PMBOKに準拠してマネジメントを説明していく
    • それが世界標準であり、PMPで問われることでもある
    • PMBOKの哲学を身に着けられるか、というものらしい

PMBOKのプロセス群と知識エリア

  • プロセス
    • するべき手順や手続きのこと
    • 第5版では47プロセス
  • 5つのプロセス群に分類可能
  • 知識エリア
    • プロジェクトマネジメントにおける概念、用語および活動の分野
  • 「プロジェクト○○マネジメント」の形で10個の知識エリアが規定されている
    • 統合
    • スコープ
    • タイム
    • コスト
    • 品質
    • 人的資源
    • コミュニケーション
    • リスク
    • 調達
    • ステークホルダ
  • プロセス群と知識エリアをマトリックスにしてみると、
    • 立ち上げフェーズは統合、ステークホルダ
    • 計画は全知識エリア
    • 実行は統合、品質保証、人的資源、コミュニケーション、調達、ステークホルダ
    • 監視・コントロールは人的資源を除く全知識エリア
    • 終結フェーズは統合、調達
  • このマトリックスをみると、
    • いかに計画と運用に重きが置かれているか
    • いかに実行段階で人的資源が大事か
    • いかに運用でスコープを守るのが大事か
  • がよくわかる

PMBOKの特徴

  • 以下の3点にまとめられる
    • 世界標準なので、網羅性を重視
    • 計画プロセスが重要なので、緻密な計画に則って進めていくやり方を想定
    • 専門用語が多い

インプット、ツールと技法、アウトプット

  • 各プロセスに定義されている
    • 例示に過ぎないが、事前準備とゴール、実行プロセスがある程度明確になる

契約に関する知識

  • 契約とは
    • ある2者の公式の決め事で、書類に記載される
      • 口約束での契約の成立ってどうなんですか、教えてエロい人
    • 契約者になれるのは自然人と法人
  • 契約の原則1:契約自由の原則
    • 当事者は契約を自由に決めることができる
    • ただし、法律の強行規定を除く
      • 例えば、麻薬取引の禁止など
      • 引っ越したら突然やって来るなんとか協会は……?
  • 契約の原則2:契約優先の原則
    • 契約内容は法律に優先する
      • これも強行規定を除く
      • 契約したからって麻薬取引やって良いわけがないよね
    • 例えば、瑕疵担保責任2年って書いたら法律の1年を上書きする
      • つまり、法律はデフォルト値

請負契約

  • 以下の2点を満たす契約
    • 請負人が注文者に対して、一定の業務の完成(例:ソフトウェアの完成と引き渡し)を約束
    • 注文者が請負人に報酬を支払う
  • ソフトウェア開発だと一番ポピュラーな契約
    • ポイントは引き渡しがあること
  • 民法に作業指示、状況報告、作業場所の規定がない
    • 契約しないと、作業指示が出せなかったり、状況報告を強制できなかったりする
    • つまり、さらに別会社に投げることが可能、ということに
  • また、請負人には瑕疵担保責任がある
    • ただし、請求は1年以内

委任契約と準委任契約

  • 委任契約
    • 当事者の一方が法律行為をしてもらうことを相手方に委託する契約
    • 法律行為:意思表示によって法律的な効果が発生する行為
      • 弁護士に代理で訴訟してもらうとか税理士に確定申告してもらうとか
  • 準委任契約
    • 法律以外の行為を相手方に委託する契約
    • 民法上は委任契約と同じ扱いをされる
    • 例えばITコンサルは準委任契約
  • 以下の法的効力を与える
    • 委任者は成果物の完成と引き渡しを約束しない
    • 委任者は業務上の指示を出さない
    • 受任者は管理者の注意義務を持って業務を遂行する
    • 受任者は、委任者の依頼に応じて進捗報告の義務がある
    • 受任者は、委任者に報酬を請求できる

派遣契約

  • 以下を満たす契約
    • 派遣元事業者が雇用している労働者を派遣
    • 派遣先の指揮命令を受ける
  • 派遣元事業者に指揮命令の権限がないというのもポイント

3つの契約の違い

  • 直感的でないところを中心にまとめる
    • 未完成責任、納期遅れ責任があるのは原則、請負契約のみ
      • 委任契約にもありそうな気がするけど納期も委任ということに
    • 状況報告の義務があるのは委任契約のみ
      • この差はなんだろうか……

偽装請負

  • アクシアの社長がよく言ってるやつ
  • 請負契約を締結しているのにもかかわらず、常駐先の指揮命令を受けるという業務実態のこと
    • 人売の害悪は再度強調するまでもないでしょう

その他の契約

請負契約における受注者のリスク削減

  • リスクの数々
    • 仕様変更しまくり
    • 法改正などによる手戻り
    • 発注側の仲間割れで要件定義遅延
    • 新技術採用による性能不良
  • このあたりの低減策を契約書に反映するのもPMのおしごと
    • 契約範囲や期間の縮小
      • 契約を細かく分ける
      • 実装と単体テストだけ請負契約にする
    • 低リスクな契約形態の選択
      • 派遣契約はそもそも作業者に指示が出せない
      • 委任契約は引き渡しを想定してないので適してない
      • というわけで、要件定義や総合テストのフェーズのリスクが高い場合に委任契約にする場合が多い
      • 逆に言えば、試験で準委任契約が選択されていたら何らかのリスク要因があるとみてよい
    • 請負契約書に金額・納期の見直し条項を追加
      • 仕様変更しまくることにリスクを乗せる
      • フェーズを限定したり、定量的な表現に変えても良い
        • けど、基本的にPMには不利
      • 仕様変更が起きた場合は別契約を結ぶのもあり
        • これなら確実にほぼ確実にカネが取れる
      • また、契約形態の切れ目のリスクは慎重に担保しておくべき
        • 外部設計を客に任せるなら、カネと納期を融通してもらう契約に
        • 質問にすぐ答えてもらえるような契約に

問題演習から

  • ステークホルダは個人として特定できていなくても良い
    • 例えば、新製品を購入する一般消費者もステークホルダ
  • システム化計画書を作るのはITストラテジスト
  • プロジェクトガバナンスを維持する組織はプロジェクトよりも上
  • プロセス資産は「プロセスと手順」「企業の知識ベース」の2つに分かれる
    • プロセスと手順:標準プロセス、ガイドライン、テンプレート、コミュニケーション要求事項等、標準化されたもの
    • 企業の知識ベース:過去のプロジェクトの知識ベースやファイルなど、ケーススタディ
  • 請負契約の場合、客先作業の場合の指揮命令権は受注先にある
    • ここまでは良いのだが、新たに雇用契約を結ぶとかいうひっかけ問題がある
    • 雇用契約を結ぶってことは発注元から給料をもらうわけで、常識で考えてありえない

「プロジェクト全般」はここまで。次は「プロジェクト統合マネジメント」です。