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年6月 | トップページ | 2008年8月 »

2008年7月

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

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

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

2008年7月26日 (土)

【共通フレーム2007】「当初」の契約要求事項

P86「1.2.5.4 外部委託先の管理」において、「当初の契約要求事項どおりに・・・」とある。
この「当初の」とは「外部委託先との契約」と対比される、供給者がまず締結する「取得者と供給者との契約」のことであり、決して外部委託先と締結する契約のことではない。

これは「ガイダンス」において「当初の契約事項とは、取得者と供給者が当初結んだ主契約(prime-contract)の要求事項を言う」と断り書きしていることからわかる。

色々制約はあろうが、「当初の契約要求事項どおりに・・・」は「取得者と供給者が結んだ契約要求事項どおりに・・・」と書けば、わざわざガイダンスに注意書きを書かなくとも理解できると思われる。

しかも、ガイダンスで「取得者と供給者が当初結んだ主契約」と「当初」などという言葉をいれているので余計に混乱を招きかねない。
「取得者と供給者が当初結んだ主契約」以外に「取得者と供給者が結んだ契約」が当然にあるかのように取られる可能性のある文となっている。

2008年7月25日 (金)

【共通フレーム2007】品質に関する計画は別途策定してもよいとは

P84「1.2.4.5 プロジェクト管理計画の立案」において(d)として「品質に関する計画は別途策定してもよい」と書かれている。

計画で考慮する項目として(d)の品質を含め(a)から(o)まで挙げられているが、「別途策定してもよい」としているのは(d)の品質と(e)の安全性及びセキュリティに関する計画の2つである。

なぜこの2つが「別途策定してもよい」のかと、「別途策定」とはどのタイミングのことかが記述されていないので困る。
「別途策定」とはいえ、「いつまでにすべき」というものはあるはずである。

「共通フレームに従っっていること」をうたう開発を行うのであれば、「別途策定してもよい」の記述は無いものとして取り扱うことが無難である。

2008年7月24日 (木)

【共通フレーム2007】計画に対する要求事項と計画のための要求事項

P84「1.2.4.4 供給方法の選択肢の検討」において、「計画のための要求事項が確定したならば・・・」とある。その前の1.2.4.3は「計画に対する要求事項の確定」となっているが、ここの「計画のための」と「計画に対する」は同じ意味であると捉えるべきである。

なぜ、違う表現としているのか不明である。
共通フレームを文字通り「活用者共通」の「フレーム」とするならば、同じ意味の表現は統一すべきであろう。

2008年7月23日 (水)

【共通フレーム2007】契約における構成管理

P83「ガイダンス」において、「契約で取決め、共同レビューで相互に合意した基準線(ベースライン)に対して、大幅な要求仕様の変更で契約内容との差異がでた場合などを指す。差異の管理を行うのが構成管理である。契約の要求については・・・」と書かれている。

「差異の管理を行うのが構成管理である」というのは、単体の記述としては異論はない。
しかし、なぜこの場所に書かれているのであろうか。

これでは「要求仕様」と「契約内容」との差異を管理することが「構成管理」の代表例と取られてしまうであろう。
ソフトウェア開発において、「構成管理」といえば「成果物」構成管理のほうがピンとくるはずで、契約の話で、説明調で「差異の管理を行うのが構成管理である」と書かれると、「なぜここで書くのか」と戸惑うのではなかろうか。しかも、この文の前後で「構成管理」と言う言葉は出てこない。

この一文は外しても全く問題がないので、外して理解するとよい。

2008年7月22日 (火)

【共通フレーム2007】契約変更の要求は誰のタスクか

P83「1.2.3.4 契約変更の要求」では「供給者は、変更管理の一環として、契約の変更を要求してもよい」とある。

これも「1.2.3.1 契約内容の文書化」と同じく「供給者」のみのタスクとなっている。

確かに、開発現場においては、契約の変更を要求したいのは「供給者」の方が多いであろう。
しかし、「発注者」側が望むことも容易に考えられる。例えば、何らかの理由から開発規模を減らす場合等。

このような場合は、「供給者」は、変更管理の一環として、契約の変更を要求してもよいと思うのであるが・・・。

やはりそれは「テーラリング」しないといけないのであろうか。

契約締結・変更に関しては、取得者も供給者もともに対等であることを前提とすべきで、どちらか一方に「権限」を与え「義務」を負わすのは好ましいことではないと思われる。

2008年7月21日 (月)

【共通フレーム2007】取得者組織

P83「1.2.3.3 交渉と契約締結」では「供給者は、システム、ソフトウェア製品又はサービスを提供するために取得者組織と交渉し、・・・」と書かれている。

ここで「取得者組織」という語が出てくるが、供給側は「供給者」であり「供給者組織」となっていない。

ガイダンスにおいても、「1.2.3.1:供給者は、提案書に基づき、取得者組織と交渉し、・・・」とあり、「取得者組織」という語の使用が1箇所だけではないので、明らかに使い分けを行っている。

「取得者組織」と「取得者」との違いは何であろうか。
「取得者組織」という語はあるのに「供給者組織」と言う語が無いのは何故なのだろうか。

これは定義・説明されないと分からないので共通フレームとして定義すべきであろう。

2008年7月20日 (日)

【共通フレーム2007】契約内容の文書化は誰の仕事か

P83「1.2.3.1 契約内容の文書化」では「供給者は、契約内容を明確化し文書化する」とある。

「供給者は、契約内容を明確化し文書化するとよい」でさえなく、「契約内容を明確化し文書化する」のは「供給者」の作業だと言い切っている。

これは明らかに不適切であると言える。
「契約内容を明確化し文書化する」ことは契約当事者双方の協力で行うべきことであろう。

では、なぜこのような「言い切り」になったのか。
おそらく、現実の契約現場では、「供給者」は契約を得たいために、契約に関する事務を進んで引き受け、取得者側はそれに甘えているというのが実態であろう。

しかし、これを「共通フレーム」としてのタスクとするのは、「取得者」側に立ちすぎた定めという感じがする。

この定義のままだと、「取得者」が「契約内容を明確化し文書化する」のはテーラリングになるのであろうか。

2008年7月19日 (土)

【共通フレーム2007】契約受入れを決定することが望ましい

P82「1.2.1.2 入札又は契約受入れの決定」において「供給者は、入札意又は契約受入れを決定することが望ましい」とある。

これはどういう意味なのであろうか。
決定しなければ先に進めないのであるから「決定」は「望ましい」のではなく「必須のプロセス」であろう。

「望ましい」のであるから「いくつもの可能性の中から一つを推奨」しているわけであるが、では推奨はされないが実施しても構わない可能性は、

「供給者は、入札意又は契約受入れを決定なくてもよい」

しかないと思われるが・・・。

2008年7月18日 (金)

【共通フレーム2007】供給者が定義した指示

P80「備考」にて「取得者は、供給者が定義した指示に従って、システムまたはソフトウェア製品を導入するか、ソフトウェアサービスを実行してもよい」とある。

当たり前の記述にしか見えない。
「してもよい」のではなくてしなかったらせっかくのシステム・ソフトウェアを使用できないではないか。

「してもよい」のであるから、「しなくともよい」わけであるが、ここでいう「しなくともよい」ケースはどのようなものであろうか。せっかく開発したのに導入・実行をしなくてもいというのは理屈上はありえるが、わざわざそれを「備考」で書くほどのことではないので、

「取得者は、供給者が定義した指示に従わずに、システムまたはソフトウェア製品を導入するか、ソフトウェアサービスを実行してもよい」

くらいしか、文面を眺めているだけでは思いつかない。
実は、しなくてもよいケースは、上の言語上想定されるものではなく、導入・実行は「通常は供給者が行うもの」という暗黙の前提がこの共通フレームにはあるようであり、それを基にすれば次のように解釈できる。

「取得者は、供給者にシステムまたはソフトウェア製品を導入させるか、ソフトウェアサービスを実行させるのみでなく、供給者が定義した指示に従って、自ら導入、実行してもよい」と。

2008年7月17日 (木)

【共通フレーム2007】受入れ後の構成管理

P80「1.1.5.4 受入れ後の構成管理」において、「受入れ後、取得者は、納入されたシステム、ソフトウェア製品の構成管理責任を持つことが望ましい」と書かれている。

どういう意味であろうか。

受け入れたらそのシステム、ソフトウェアは取得者の責任で管理しなければならないのではないか。
だから整斉と管理するためには「構成管理」責任は一義的には取得者が負うべきであろう。
ここでの、「取得者が構成管理責任を持つことが望ましい」というのは、「構成管理」業務を委託することで内部的な責任関係は委託先に負わせることが可能であるということである。

故に、構成管理に起因する障害により顧客に不都合な自体を招く等の、対外的責任に対しては、「構成管理は委託先に任せているから」と言い逃れることは当然できない。

「取得者が構成管理責任を持つことが望ましい」の「責任」はあくまで内部的なものであることに注意。

2008年7月16日 (水)

【共通フレーム2007】テストデータだけなぜ自ら作成するのか

P79「1.1.5.2 受入れ」において「受入れのためのテストは、・・・、テストケース、テストデータを定義し、自らテストデータを作成し、テストを実施することが望ましい」とある。

動作の主体が書かれていないが、受入れなので「取得者」とすると、なぜ「取得者」は、「テストケース、テストデータの定義」「テストデータの作成」「テストの実施」の中で「テストデータの作成」のみ自ら実施する必要があるのか。

「テスト結果の検証」は挙げられていないので、「テストの実施」に含まれると思われるが、であれば先の3つの作業から「取得者自ら行うべき」ものを一つだけ選べというのであれば、「テストの実施」ではないかと思われる。

「望ましい」としているので、「取得者自ら行うべき」ものを一つだけに絞る必要はなく、全て自ら実施することが望ましいというように表現しても良かったと思えるが、何らかの理由があると思われるので、なぜ「テストデータの作成」のみ自ら行う必要があるのか共通フレームに記述する必要があると思われる。

2008年7月15日 (火)

【共通フレーム2007】受入れ時の供給者の参加範囲の定義

P79「1.1.5.1 受入れの準備」において「受入れにおける供給者の参加範囲を定義することが望ましい」とあるが、これは取得者目線での記述と言え、供給者から見れば、あれやこれやと作業指示を受けたくないので「受入れにおける供給者の参加範囲を定義すべき」と読んだ方が良い。

取得者としても、受入れに供給者を参加させる予定であれば、ちゃんと希望通りの参加をしてもらうために、予め定義すべきと考えられるのだが、なぜ「望ましい」にとどめているのだろうか。

受入れは、そもそも取得者・供給者の協力なしにはできないものであり、かつ契約上必須の行為であるから、細かく定義してそれに縛られるより定義しない方法もあると考えることはできる。

2008年7月14日 (月)

【共通フレーム2007】受け入れ準備は「望ましい」ことなのか

P79「1.1.5.1 受入れの準備」において、「取得者は、定義された受入れ方針及び基準に基づいて、受入れの準備をすることが望ましい」とある。

少なくとも、「取得者は、受入れの準備をすることが望ましい」というのはおかしい。準備なしに受け入れることは不可能かもしくはあまりに受入れ側のリスクが高くなるから「すべきである」のはずである。

では、「望ましい」となっているのは、「定義された受入れ方針及び基準に基づいて」の部分についての記述ということになる。

よって、「取得者は、定義された受入れ方針及び基準に基づいて、受入れの準備をすることが望ましい」というのは、
   ・受入れの準備をすること
は、実施すべき事項であるが、
   ・定義された受入れ方針及び基準に基づいて準備すること
は、実施することが望ましい事項と解釈することになる。

2008年7月13日 (日)

【共通フレーム2007】「連絡協議会」と「定例会議」

P79「ガイダンス」において、「1.1.4.2:供給者への協力では、業務の流れ、データ量などに関する確実な情報提供の他、問題解決のための定例会議の設定などを含む。」とあり、次に「経済産業省の『情報システム・モデル取引・契約書』では、第12条で連絡協議会の設置を求めている。」とある。

さて、「連絡協議会」とは、「確実な情報提供」のための定例会議なのか、「問題解決のための定例会議」なのか。
それとも「連絡協議会」とは「定例会議」とは別物か。
そもそも第一文と第二文の関係はどのようなものか。

定義・説明無しに「連絡協議会」と「定例会議」が出てきたわけだから、名前が違えば別物であるはずだ・・・と言われても仕方がないのでは。

「経済産業省の『情報システム・モデル取引・契約書』の第12条で設置を求めている連絡協議会も定例会議の例である。」位に補って読めばよいであろう。

2008年7月12日 (土)

【共通フレーム2007】「供給者への協力」は、「供給者の監視」なのか

P79「1.1.4.2 供給者への協力」において、取得者は供給者に協力せよとの記述がある。

これが、「1.1.4 供給者の監視」に入っているのは少々違和感を覚えるが、別立てとする必要もないと判断されたのであろう。

尚、P75「ガイダンス」の1.1.1.3の記述はこれと重なっている。
念のため。

2008年7月11日 (金)

【共通フレーム2007】将来の事項

P78「ガイダンス」の「1.1.3.6」に「契約内容に将来の事項、予測に基づく事項などが多い場合は、基本契約と個別契約により、契約行為をやりやすくする方法がある」と書かれている。

「契約内容」に「将来の事項」が多いのは当たり前ではないのだろうか。
契約内容は締結後に行うことが書かれているのであるから。

この「契約内容に将来の事項、予測に基づく事項などが多い場合は」は、「契約内容に将来決定する事項、予測に基づく事項などが多い場合は、」という意味にとらえればよいだろう。

2008年7月10日 (木)

【共通フレーム2007】非機能要求

P78「ガイダンス」の「1.1.3.4」において、「1.取得に関する要求事項には、費用、納期、性能、品質の間にトレードオフの関係がある。これを考慮して、取得に関する要求事項をまとめることが望ましい」とある。

しかし、調達者が要求事項をまとめる際に「費用、納期、性能、品質の間のトレードオフ」まで考えてまとめることはできるのであろうか。
供給者とのやり取りの過程で、考慮することはありうるが、自力でまとめることはかなり難しい作業であると思われる。

ここは、「1.取得に関する要求事項には、非機能要求を考慮して、取得に関する要求事項をまとめることが望ましい」のように書けば良いような気がする。 

共通フレームには「非機能要求」という言葉は出てこないのであるが。

2008年7月 9日 (水)

【共通フレーム2007】供給者の提案するプロセスを評価すること

P78「ガイダンス」の「1.1.3.3」において、「取得者はプロジェクト用に独自にプロセスを修正するというよりは、むしろ供給者組織のプロセス標準に基づいた提案書を請求し、供給者の提案するプロセスを評価することも一案である」と書かれている。

しかし、「供給者組織のプロセス標準に基づいた提案書を請求し、供給者の提案するプロセスを評価する」ことは、評価側に相当のスキルを必要とする。

まず、「供給者組織のプロセス標準に基づいた提案書」だけで、「供給者の提案するプロセス」を評価することは可能なのであろうか。
次に、「供給者の提案するプロセス」を客観的かつ正確に評価することは可能なのであろうか。

組織によって「プロセス」は様々で、かつ何百ページにもわたる定義がされていることは珍しいことではない。それを全て提出させて評価するならばともかく、提案書だけで評価するのはたやすいことではない。

取得者は自力で評価することは難しく、結局「ウチはCMMIレベル5達成しています」等を評価するしかないのであろうか。

共にwin-winの関係を構築すべく、取得者側の供給者を見る目が問われる文章である。

2008年7月 8日 (火)

【共通フレーム2007】「供給者の能力」と「(供給者の)システム構築の能力」の違い

P78「ガイダンス」にて、「1.1.3.2 供給者の選択」に関し、「その他の考慮すべき要素の例」が備考として書かれている。

その中に「システム構築の能力、成熟度(補足説明集「8.CMM,CMMI」を参照のこと)」とある。
しかし、「1.1.3.2 供給者の選択」本体では「取得者は、供給者の提案書、能力、その他の考慮すべき要素の評価に基づいて、供給者を選択することが望ましい」とある。

この「その他の考慮すべき要素」に「システム構築の能力、成熟度」を入れてみるとこうなる。
「取得者は、供給者の提案書、能力、システム構築の能力、成熟度の評価に基づいて・・・」となるが、「能力」と「システム構築の能力」とはどう違うのだろうか。
前者が後者を包含するように見えるのだが。

この違和感ある記述はなぜ起きたかを推測することはたやすい。
CMMが「能力成熟度モデル」と和訳されることから、CMM、CMMIについて言及する場合、「成熟度」だけを書くことに不自然さがあるため「能力」も書いたと思われる。しかしそうすると、本体を含めた全体で不自然さを招いてしまったということであろう。

この「ガイダンス」について加えれば、「CMM,CMMI」だけでなく、共通フレームとあわせてIPAから公開された「SPEAK-IPA」についても言及してあげるべきであろう。

2008年7月 7日 (月)

【共通フレーム2007】「契約」と「合意」の使い分け

P78の「備考」において、「取得者は、この共通フレームの適用のときに、”契約”または”合意”のどちらの用語を使用するかを決める」とある。

これはどういう意味であろう。
普通考えると、「”契約”または”合意”は同じ意味なので、どちらかを使用するか決めよ」というように思われる。
現にP45では「組織の内部の適用では、契約という言葉は合意と読み替える」と書かれている。つまり、P78の「備考」はわざわざ記述するのではなくP45を参照せよと書けばよかったわけであるが、それで問題無しというわけでは無い。

この「備考」に書かれている数行前に「合意された契約」と書かれている。
これは組織の内部の適用では「合意された合意」、外部の適用では「契約された契約」と読み替えることになるが・・・。「合意されない合意」などあるはずが無いので当たり前のことを言っていることになるのであるが。

そもそもというのも変な気もするが、「組織の内部の適用では、契約という言葉は合意と読み替える」というのであれば、基本は原則「組織の外部の適用」を基本として「契約」をP45以降使い、「合意」の語は「組織の内部の適用」のみでしか行わない場合に限るべきである。
しかし、P45以降も「組織の外部の適用」もあり得るケースで「合意」は使用されている。

共通フレームを読むにあたっては、このあたりを注意しておく必要があろう。

2008年7月 6日 (日)

【共通フレーム2007】契約の記載内容について契約締結するとは

単なる国語の問題なのですが。

P78「1.1.3.6 供給者との契約締結」において「取得者は1.1.3.4 (供給者との契約準備及び交渉)によって合意された契約の記載内容について契約締結する」と書かれている。

「合意された契約の記載内容について契約締結する」というのは少しおかしい気がする。

契約は「合意によって成立する」ものなので、「合意された契約」という段階ですでに締結が完了しているはずだ。それを更に「契約締結する」というのは日本語としておかしい。

更に言えば「契約の記載内容」というのもおかしく、契約は文書である必要は無く口約束でも成立するので「記載」されているとは限らない。

このアクティビティは「取得者は1.1.3.4 (供給者との契約準備及び交渉)によって合意された内容を契約書に文書化する」と解釈すれば良いであろう。

2008年7月 5日 (土)

【共通フレーム2007】タスクの順番

P77「1.1.3.4 供給者との契約準備及び交渉」は「次に取得者は」で始まる。

他のタスクにおいては、この「次に」のような順序を表す言葉は入っていない。これは何を意味するのであろうか。

直前に書かれているタスク「1.1.3.3 修整への他者の参加」の次に絶対行えという意味なのであろうか。

ここの「次に」は取っても構わないように思われるのだが・・・。

2008年7月 4日 (金)

【共通フレーム2007】取得に関する要求事項を秘密にして良いことはあるか

P77「1.1.2.4 要求事項の提示」において「取得に関する要求事項は、その取得アクティビティを実施するように選任された組織に提示することが望ましい」とあるが、これは「いくつもの可能性の中から一つを推奨する際に使う」「望ましい」で良いのだろうか。

「取得に関する要求事項を、その取得アクティビティを実施するように選任された組織に提示しない」というのも有りということか。

確かに内容によっては「提示しない方がよい」こともあろうが、それが例外的ケースであり、通常は「提示すべき」なのではないだろうか。

「取得に関する要求事項」が提示されずに要求事項を満たす行為を行うことは、「その取得アクティビティを実施するように選任された組織」には非常に難しいことでは無いだろうか。

2008年7月 3日 (木)

【共通フレーム2007】供給者への協力の種類

P75「ガイダンス」の1.1.1.3に対する補記であるが、「供給者を雇った場合は、取得者側が、供給者に協力することが大切である。このことは、このタスクに限らず、すべてのプロセス、アクティビティ、タスクにおいても同様である」と書かれている。

これは、わざわざ記述するのではなく、P79「1.1.4.2 供給者への協力」が定義されているので、共通フレームとしての自己完結性からP75「ガイダンス」では「1.1.4.2を参照のこと」程度に書いておくべきではないだろうか。

それとも、「供給者を雇った場合は、取得者側が、供給者に協力することが大切である。このことは、このタスクに限らず、すべてのプロセス、アクティビティ、タスクにおいても同様である」という記述は、「1.1.4.2 供給者への協力」とは別途の意味なのであろうか。ならばその差がわかるように書かれていないと理解が難しい。

2008年7月 2日 (水)

【共通フレーム2007】開発の一部の発注は「常に」なのか「こともある」のか

P75「ガイダンス」において、「1.1.1.1 概念又はニーズの記述」に対する補記がなされている。その内容は「取得プロセスは、開発の一部を発注することもあるため、発注部分の仕様固めを行うことを意図する」と書かれている。

「取得プロセスは、開発の一部を発注することもある」というのは「取得プロセスは、開発の一部を発注しないこともある」わけで、それなのに後に続く文が「発注部分の仕様固めを行うことを意図する」というのは「1.1.1.1 概念又はニーズの記述」の補記としてどういう意味なのであろう。

「1.1.1.1 概念又はニーズの記述」は「開発の一部を発注しない」場合には要らないということであろうか。そんなことはあるまい。

この部分は「取得プロセスは、開発の一部を発注することもあるが、その場合、1.1.1.1は、発注部分の仕様固めを行うこととなる」くらいに解釈すればよいのであろう。

2008年7月 1日 (火)

【共通フレーム2007】供給者との共同作業と予定

P75「1.1.1.8 取得計画の作成と実行」で、取得計画に含むことが望ましいものとして挙げられている。

その内で、1つよくわからない点がある。

「取得者の作業と予定」には「予定」があるのに、なぜ「供給者との共同作業」には「予定」はないのか。

相手がいることだから、とも考えられるが、取得者の予定に合わないならその供給者は採用すべきでないとも言え、なぜ「予定」がないかは説明が欲しいところ。

« 2008年6月 | トップページ | 2008年8月 »