2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

書籍・雑誌

2008年10月13日 (月)

【共通フレーム2007】契約の変更要求が与える影響調査の重みの違い

P89「1.3.2 契約の変更要求」において、「当該要求がプロジェクト計画、費用、利益、品質及び予定に与える影響」に関する調査分析が、契約の変更要求者が「供給者の場合」と「取得者の場合」で異なる場所に記述されている。

前者は「1.3.2 契約の変更要求」に、後者は「1.3.3 影響の調査分析」に書かれているのだ。
前者は主となる文に対し付加的に、後者はそれ自体が主となる文になっている。

契約の変更要求者が「供給者の場合」と「取得者の場合」ともに「供給者」が調査分析をするのであるから、記述は分けずに一ヶ所にまとめた方が、モデルとしては良いであろうし、実用においても、理解しやすい。

【共通フレーム2007】契約と合意

P88「1.3 契約の変更管理プロセス」において、「目的」に「二者が合意する結論で終わる」とあるが、P78において契約と合意とは共通フレームでは同じ意味で使うことを示されているし、その他の部分では基本的に「契約」という語が使用され、「合意」と読み変えても良い構成となっている。

なぜここでは「合意」という語が使用されているのであろうか。説明すべきと思われる。
見出しで「1.3 契約の変更管理プロセス」と「契約」という語を使っているのにそのなかで「合意」を使用しているのであるから、なんらかの区別をしているはずだ。

おそらく、この部分では無意識的に「合意」と「契約」は別物として考えてしまい、P78の記述を鑑みなかったのであろう。

個人的には「契約」と「合意」は分けたほうが良いと考える。
「合意」のうち、何らかの形式的行為を伴うものを「契約」として捉えた方が分かりやすいであろう。

あえて同じ意味とするのであれば、「合意」で統一するべきであろう。
「契約」というと、現実のビジネスでは「契約文書の作成」と繋げて考えてしまうことが多いと考えられるが、共通フレームにおける「合意」すべき事項においては、「契約文書の作成」は必然ではないからだ。

2008年8月 3日 (日)

【共通フレーム2007】取得者への支援

P87「1.2.7.2 取得者への支援」において、「供給者は、契約で定めるとおりに、取得者へ納入されたシステム、ソフトウェア製品又はサービスに関する支援を行う」とある。

これは、「契約で定めるとおりに」とあることから分かるように、「契約の定めがある場合」に実施するべきもので、必然的に供給者がしなければならないと言うことではない。

1.2.7.2、「供給者は、契約で定めがなければ、取得者へ納入されたシステム、ソフトウェア製品又はサービスに関する支援を行う必要はない」ということも言っていることに注意が必要。

2008年8月 2日 (土)

【共通フレーム2007】取得者の設備視察の容認

P87「1.2.6.5 取得者の設備視察の容認」において、「供給者は、契約及びプロジェクト計画で指定するシステム、ソフトウェア製品又はサービスのレビューのために、取得者が供給者及びその外部委託先の設備にアクセスできるようにする」とある。

ここで言う「アクセス」とはどのようなことを言うのであろうか。

「レビューのために」というのは「何を」レビューするのであろうか。
システム、ソフトウェア製品又はサービスの成果物のことか。

そもそも「・・・製品又はサービスのレビューのために・・・アクセスできるようにする」とあるが、これが「設備視察」と直感的にむずびつかないのではないだろうか。

「設備視察」は、「製品又はサービス」が一定の水準のプロセスに基づいて開発・管理されていることを「レビュー」するための1方法として行うものとした方が良いと思われる。

だからこそ「取得者の設備視察」を容認するのであって、「・・製品又はサービスのレビュー」特に、「製品のレビュー」のために取得者による設備の視察を許容する必要性は考えづらい。

2008年8月 1日 (金)

【共通フレーム2007】公式な会議

P87「1.2.6.2 取得者への支援」の記述で、「供給者は、契約及びプロジェクト計画で指定する取得者との非公式な会議、受入れレビュー、受け入れテスト、共同レビュー及び監査を行い、支援する」とある。

ここには書かれていないが、当然「公式な会議」も含まれるべきであると思われる。
なぜ、わざわざ「非公式な」会議のみを「行い、支援する」のかは不明。

公式な会議は取得者への「支援」ではなく、自らのためにも実施するものであるからという理由であるのかもしれないが、そこまで容易に読み取れないのではなかろうか。

仮にそうであれば、ガイダンスで詳細に説明すると良かったと思われる。

2008年7月31日 (木)

【共通フレーム2007】契約レビュー

P86「1.2.6.1 取得者との調整」において、「契約レビュー」という語が出てくる。
定義はない。

これは、「契約に基づく取得者の組織が参加するレビュー」と解釈すればよい。
1.2.6.2で出てくる「受入れレビュー」「共同レビュー」が含まれると考えてよい。

契約前に取得者供給者が行う、「契約内容のレビュー」ではない。
「契約レビュー」というとそちらを思い浮かべる可能性も高いと思われるが。

2008年7月30日 (水)

【共通フレーム2007】プロジェクト管理計画の更新、修正は必須か否か

P86「ガイダンス」の「1.2.5.1」において次のように書かれている。

---------------------
1.プロジェクト管理計画は必要に応じて、更新、修正されることが望ましい。
2.取得者には計画の更新を通知されることが望ましい。
---------------------

1.は、「必要に応じて」という留保的言葉を既に入れているのであるから、「望ましい」ではなく「しなければならない」程度で考えて良い。「必要に応じて」も「必要か必要でないか」の取りようで誤解を生む可能性もあるので、「1.プロジェクト管理計画は、プロジェクトの状況に合わせて更新、修正されなければならない」と考えれば良い。

2.も同様に、「望ましい」のではなく、取得者の計画に影響を及ぼす場合は「通知すべき」ものであり、取得者には計画の更新を通知されることは、常に「望ましい」という選択の余地があるものは限らない。

「われわれは共通フレームに準拠しており、共通フレームでは『取得者には計画の更新を通知されることが望ましい』としか書かれていないので、今回は通知しませんでした」といって取得者が納得してくれるのであればそれでよいですが・・・。

「取得者には計画の更新を通知されることが望ましい」というのは、取得者の計画に影響を与えないような内部的な計画の更新について述べているものである。

2008年7月29日 (火)

【共通フレーム2007】検証確認者、妥当性確認者又はテスト担当者

P86「1.2.5.5 検証、妥当性確認又はテストの代行者との強調」において、「供給者は、契約及びプロジェクト計画で指定する独立した検証確認者、妥当性確認者又はテスト担当者と協調して作業を進める」とある。

一方、P84「1.2.4.5 プロジェクト管理計画の立案」において(h)として「検証及び妥当性確認。指定があれば、検証及び妥当性確認の代行者との協調作業も含める」と書かれている。

前者では「検証確認者、妥当性確認者又はテスト担当者と協調して」となっており、後者では「検証及び妥当性確認の代行者との協調作業も」となっている。

後者では「テスト担当者」が落ちている理由はなぜか。
直感的にはわからないので、記述されるべきであると考える。

2008年7月28日 (月)

【共通フレーム2007】「プロジェクト管理計画」と「プロジェクト計画」の違い

P86「1.2.5.5」において、「供給者は、契約及びプロジェクト計画で指定する・・・」とある。

これは1.2.4.5及び1.2.5.1でいう「プロジェクト管理計画」とどのように違うのかわかりづらい。

実は、「プロジェクト管理計画」は1.2.4.5で、「プロジェクト計画」は1.4.3.18で、比較的詳細に書かれてはいる。

その記述からは「プロジェクト管理計画」は供給者が、「プロジェクト計画」は取得者側で作成するように読めるしつじつまも合うようだが・・・いかんせん1.2.4.5と1.4.3.18は離れているのでこの使い分けは通常見逃してしまうであろう。

つまりせっかくの使い分けは意識されず、「プロジェクト管理計画」と「プロジェクト計画」は同じものと誤解されるケースが多いであろう。

2008年7月27日 (日)

【共通フレーム2007】必要なすべての契約要求事項を外部委託先に引き渡す

P86「1.2.5.4 外部委託先の管理」において、「・・・当初の契約要求事項どおりに開発又は実施されていることを確実にするために、必要なすべての契約要求事項を外部委託先に引き渡す」とある。

当初の契約要求事項どおりに開発又は実施されていることを確実にするためには、確かにその通りであろうが、当然、「当初の契約」における機密保持等の契約内容に縛られることは言うまでもない。

その上での「必要なすべて」である。

より以前の記事一覧