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

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

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

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

【共通フレーム２００７】契約と合意

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｐ86「１．２．６．１　取得者との調整」において、「契約レビュー」という語が出てくる。
定義はない。

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

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

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

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

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

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

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

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

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

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

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

一方、Ｐ84「１．２．４．５　プロジェクト管理計画の立案」において（ｈ）として「検証及び妥当性確認。指定があれば、検証及び妥当性確認の代行者との協調作業も含める」と書かれている。

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

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

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

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

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

実は、「プロジェクト管理計画」は１．２．４．５で、「プロジェクト計画」は１．４．３．１８で、比較的詳細に書かれてはいる。

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

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

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

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

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

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

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

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

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

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

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

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

Ｐ84「１．２．４．５　プロジェクト管理計画の立案」において（ｄ）として「品質に関する計画は別途策定してもよい」と書かれている。

計画で考慮する項目として（ｄ）の品質を含め（ａ）から（ｏ）まで挙げられているが、「別途策定してもよい」としているのは（ｄ）の品質と（ｅ）の安全性及びセキュリティに関する計画の２つである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

尚、P７５「ガイダンス」の１．１．１．３の記述はこれと重なっている。
念のため。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

その中に「システム構築の能力、成熟度（補足説明集「８．ＣＭＭ，ＣＭＭＩ」を参照のこと）」とある。
しかし、「１．１．３．２　供給者の選択」本体では「取得者は、供給者の提案書、能力、その他の考慮すべき要素の評価に基づいて、供給者を選択することが望ましい」とある。

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

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

この「ガイダンス」について加えれば、「ＣＭＭ，ＣＭＭＩ」だけでなく、共通フレームとあわせてＩＰＡから公開された「ＳＰＥＡＫ－ＩＰＡ」についても言及してあげるべきであろう。

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

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

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

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

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

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

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

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

Ｐ78「１．１．３．６　供給者との契約締結」において「取得者は１．１．３．４　（供給者との契約準備及び交渉）によって合意された契約の記載内容について契約締結する」と書かれている。

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

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

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

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

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

Ｐ77「１．１．３．４　供給者との契約準備及び交渉」は「次に取得者は」で始まる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【共通フレーム2007】取得計画を準備することが望ましいの意味するところ

Ｐ74「１.１.１.８　取得計画の作成と実行」において「取得者は、取得計画を準備、文書化し、実行することが望ましい」とある。

この文を分解すると、
①取得者は、取得計画を準備することが望ましい

②取得者は、取得計画を文書化することが望ましい

③取得者は、取得計画を実行することが望ましい
となる。
Ｐ71では「望ましい」は、「いくつもの可能性の中から一つを推奨する際に使う」と定めているが、そのように考えると①と③は違和感がある。

①取得計画の準備はどんなときも必要でしょう
②取得計画の文書化は、無いと絶対ダメとまでは言えない
③取得計画の実行も、実行する積もりのない計画は立てる意味がないからどんなときも必要でしょう

「取得者は、取得計画を準備、文書化し、実行することが望ましい」は、次の文と同じ意味となるはずだが、共通フレームでは本当にそう言っているのだろうか。

「取得者は、望ましくはないが、取得計画を準備、文書化し、実行しなくても良い」。

【共通フレーム2007】ソフトウェアサービス

Ｐ73、74その他で出てくる「ソフトウェアサービス」という言葉。
分からない・・・と思って索引を調べても、Ｐ73、74としか書かれていない。

しかしＰ73、74には「ソフトウェアサービス」という言葉を当然のように使っているだけで定義が書かれていない。

だからといって定義されていないわけではなく、Ｐ16で、「ソフトウェアサービスとは、例えばシステムインテグレーションサービスを受けるような場合をさす」と書かれている。

何故、肝心の定義部分が索引に書かれていないのかは分からない。

その意味では、「サービス」と「ソフトウェアサービス」の使い分けもよくわからない。
例えば、以下の例が挙げられる。

Ｐ72「１．１　取得プロセス」の目的における「サービス」は「ソフトウェアサービス」のことなのか違うのか。

Ｐ73「１．１．１．１　概念又はニーズの記述」では「システム、ソフトウェア製品又はソフトウェアサービス」とあるが次ページの「１．１．１．６　選択肢の検討」では「システム、ソフトウェア製品又はサービス」とある。どのような意図で使い分けているのか。

【共通フレーム2007】ソフトウェア要件の定義と分析

Ｐ73から74にかけて、「システム要件の定義と分析」「ソフトウェア要件の定義と分析」が定められているが、なぜか記述方法が異なる。

「システム要件の定義と分析」が比較的丁寧に記述しているのに対し、「ソフトウェア要件の定義と分析」は、説明をはしょった感じがして、記述の粒が揃っていない。

これは、「ソフトウェア要件の定義と分析」は「システム要件の定義と分析」を転用するのは自明だからはしょっていると思われる。

ただ、共通フレームとしては、それならそうと書くべきだし、本来的には自明でも書くべきだと個人的には考える。

【共通フレーム2007】取得プロセスの概念又はニーズはシステム要件の定義で使うか否か

Ｐ73 １．１．１ で取得プロセスの開始アクティビティが示される。

１．１．１．１　概念又はニーズの記述
１．１．１．２　システム要件の定義と分析

この両者、「１．１．１．１　概念又はニーズの記述」で記述されたニーズに基づいて「１．１．１．２　システム要件の定義と分析」を行うはずであるが、そのことに言及されていない。ＩＳＯの記述を極力そのまま使うのであれば、せめてガイダンスにでも書いておいた方が良い。

【共通フレーム2007】システム要件定義とソフトウェア要件の定義

P72～73において「1.1.1.2　システム要件の定義と分析」と「1.1.1.4　ソフトウェア要件の定義と分析」について記述されている。これらは単に「システム要件」「ソフトウェア要件」と定義対象が異なるだけで、同じく要件定義をするプロセスであるはずであるが、記述方法が全く異なっている。共通フレームの「1.1.1.4　ソフトウェア要件の定義と分析」を活用する場合は、それ単独ではなく「1.1.1.2　システム要件の定義と分析」と「1.1.1.3　システム要件定義の依頼と結果の承認」の内容を「ソフトウェア要件」に準じて読み込んだ上で適用すべきであろう。

また、「1.1.1.2　システム要件の定義と分析」「1.1.1.3　システム要件定義の依頼と結果の承認」では、全社が「システム要件の定義」とあり後者では「システム要件定義」とあるがこれは同じと考えてよい。

同様にP25のV字モデルでは「システム要件定義」「ソフトウェア要件定義」とあるが、この２つのタスクを実際に定義しているのは1.1.1.2、1.1.1.4の「システム要件の定義」「ソフトウェア要件の定義」であると考えてよい。

【共通フレーム2007】取得プロセスの「ニーズ」

P72「１．１取得プロセス」において、４つの「ニーズ」表現があるがこれは同じか。

①顧客が示したニーズ
②顧客ニーズ
③取得ニーズ
④顧客が記述したニーズ

①④は同じであろう。
②が①④を含むが、顧客の潜在ニーズ等の「示されない」顧客ニーズも含むと思われる。
③は①②④とは切り口が異なるニーズであろう。

・・・、と国語上は区別できる。

実際の記述は、この区別を満たしているようにも見えるが、もう少しそれぞれの差をわかりやすく書かないと、「共通フレーム」に準拠しようとする者は間違えた解釈をしてしまうであろう。

そもそも、上で示した解釈が合っていたらの話であるが。

【共通フレーム2007】共通フレームにおける「顧客」

P72「１．１取得プロセス」の目的で「取得プロセスは、顧客が示したニーズを満足する製品及び／又はサービスを得ることを目的とする」とあるが、共通フレームにおける「顧客」とは何であろうか。

P22の表２－１に「共通フレーム上の役割、および共通フレームを利用する実際の組織／役割との関係の例」があるがここにも「顧客」は定義されていない。この表２－１で探せば、「取得者」か「利用者」のことであろう。

さらに、この「１．１取得プロセス」では、次のページで「所有者」という語も出てくる。
これも表２－１「共通フレーム上の役割、および共通フレームを利用する実際の組織／役割との関係の例」には無いのであるが、「顧客」と「所有者」とはどのような関係なのであろうか。

【共通フレーム2007】「発展的に解消」

共通フレーム２００７では散見されるのであるが、記述が主観的であるにも関わらず、十分説明されていないためよくわからないものがある。
特に著作者の「思い」がこめられていると思われる部分にそれが顕著に現れる。

P７２「ガイダンス」における記述もその一例。

「更に発注側の作業である開発プロセスの業務詳細アクティビティを発展的に解消し、企画プロセス及び運用プロセスへアクティビティ、タスクとして入れ込み強化を図った」

とある。
しかし、どうしてこれが「強化を図った」ことになるのであろうか。
「発展的に解消し」と「入れ込み」のどちらの行為が「強化を図った」ことになるのだろうか。

「発展的に解消し」の「発展的」の表現に「強化」のにおいは感じられるが、「発展的に解消し」という表現では読者は何がどうなったため「強化」されたのかわからない。

そもそも論になってしまうが、「そもそも何が強化された」のかわかりづらい。
よく読むと、強化されたのは発展的に解消した「開発プロセスの業務詳細アクティビティ」とも思われるが、「発展的に解消したものを強化する」というのも難しい文章である。

「更に発注側の作業である開発プロセスの業務詳細アクティビティを発展的に解消し、企画プロセス及び運用プロセスへアクティビティ、タスクとして入れ込んだ」では、なぜ駄目だったのだろうか。

共通フレームを共通のフレームとして活用する者には、「強化を図った」か否かは関係の無い話である点からも「強化を図った」の記述は要らなかったと思われる。

【共通フレーム2007】「Shall」と「Should」

P71では、共通フレームにおいて、「Shall」と「Should」は次のように日本語に訳されているとのこと。
英語では、その２つでしか書かれていないものが、日本語では複数で書かれていることを意識して読むと良い。

Shall　：　「とする」「による」「すること」「する」
　　　　　　　　　　　＝＞二人以上の当事者間で定められた規定を表す

Should　：　「することが望ましい」「ほうがよい」「するとよい」
　　　　　　　　　　　＝＞いくつもの可能性の中から一つを推奨する際に使う

・・・・、「Shall」と「Should」共に矢印以降の記述は「？」な気もする。
本当にその定義でよいのだろうか・・・と。

【共通フレーム2007】「要件」と「要求」

Ｐ４９で共通フレームの９８、２００７の新旧対比があるが、９８では「要求」となっていた一部が「要件」となり、「要件」と「要求」で使い分けられている。

この使い分けは、Ｐ３２で定義されているので再確認すると良い。

【共通フレーム2007】共通フレームの適用例

P47に「図2-16 共通フレームの適用例」という図がある。

しかし、図中のどこにも「共通フレーム」という言葉が出ていない。

この図は、それだけを見れば「共通フレームを適用しない場合の例」としか解釈できないのであるが、どのように見ると、共通フレームが適用されていることがわかるのであろうか。

図中の「JIS X 0160」と書かれた部分を「共通フレーム」と置き換えればしっくりくるので、共通フレームを活用しようとする者はそのように読み替えれば良い。

【共通フレーム2007】ソフトウェア製品の型

P44において「ソフトウェア製品の型」という語が出てくるが、これは何か。

「ソフトウェア製品の型が異なれば修正の仕方も変わってくるので、事前にその型を決定する」とまず書かれており、その「ソフトウェア製品の型の例」として、次の６つが挙げられている。

①新規開発
②既製のソフトウェア製品をそのまま使用する場合
③既製のソフトウェアを修正して使用する場合
④システムに埋め込まれたり、又は結合されたりするファームウェアを含むソフトウェア製品の場合
⑤単体のソフトウェア製品の場合
⑥非納入ソフトウェア製品の場合

まず、これらは排他的ではないので、②および⑤という考えが許される。

それは良いとして、①から⑥は列挙の粒が揃っていない感じがする。
何故①のみ「の場合」が付いていないのか。
①②③はそれぞれ相補関係にあるように見えるが、⑤や⑥については、「単体ではないソフトウェア製品の場合」や「納入ソフトウェア製品の場合」という相補関係となる型が書かれていないのは何故なのであろうか。

型の例はともかく、「ソフトウェア製品の型が異なれば修正の仕方も変わってくるので、事前にその型を決定する」という記述は重要であり、そのためには事前に型のパターンを良く整備しておくことも合わせて重要であることは留意すべきである。

【共通フレーム2007】・・・しているだけ

P43「（4）共通フレームの修正及び適用に際しての考慮点」において、「以下の項目は、主なプロジェクト特性を考慮しているだけであり、必ずしもすべてを言い尽くしているわけではない」とある。

「以下に、考慮すべき主なプロジェクト特性を列挙する」とだけ書いても良いように思われるが、何故このような回りくどい表現をしているのであろうか。

特定の開発対象では最優先で考慮すべきである一方で、別な開発対象では考慮すら不要というプロジェクト特性が、たくさんあるが、それらを列挙するわけにもいかないと判断し、ソフトウェア開発において普遍的に考慮すべきもののみを挙げたためこのような表現になったということが考えられるが、単に表現だけの問題かもしれない。

【共通フレーム2007】品質保証の品質保証

P42「(d)品質保証」では「品質保証は、ソフトウェアの開発又はプロセスの実行に直接責任を持つ者とは無関係の者が実施する」とある。

ここで、共通フレームでは明示的に書かれていないが、「品質保証」自体が共通フレームの「支援ライフサイクルプロセス」であることに注意が必要である。

つまり、「ソフトウェアの開発又はプロセスの実行」の中に「品質保証」プロセスが含まれる。
よって、「品質保証」に対する「品質保証」が共通フレームを「モデルとして厳格に適用した場合」必要となる。

尚、CMMIにおいてはこの「品質保証の品質保証」は明文化されている。

さて、言うまでもないことであるが、念のため品質保証を行える者について言及する。
「品質保証は、ソフトウェアの開発又はプロセスの実行に直接責任を持つ者とは無関係の者が実施する」とあるが、これは、対象プロセスに対して直接的な責任がなければ良いのであって、品質保証チームをプロジェクト内に置くことはもちろん構わないし、同一プロジェクト内で自分が実施・責任の担当となっていないプロセスに対して「品質保証」を行うことも構わない。

【共通フレーム2007】「プログラム」の意味

P39「（３）組織に関するライフサイクルプロセス（ｆ）再利用プログラム管理プロセス」において「組織として、資産（ソフトウェア、テストデータ、メトリクス等）を再利用する活動の計画、管理、制御、監視を体系的に実施するアクティビティからなる。ここでいうプログラムとは実施計画をさす」とある。

第２文の「ここでいうプログラムとは実施計画をさす」はつまり「プログラム」＝「実施計画」であり、ならば（ｆ）じは「再利用実施計画管理プロセス」となるが、何かピンと来ない。

ここでいう「プログラム」は、第１文中の「資産（ソフトウェア、テストデータ、メトリクス等）」と解釈して問題ないのではないか。

ソフトウェア開発関連の標準書の中で、わざわざ「コンピュータ用語」である「プログラム」を別の意味で使う必要はないと考える。どうしても何かの語で表したいのであれば、別な言葉で書くべきである。

「ここでいうプログラムとは実施計画をさす」とわざわざ書くのではなく「プログラム」と書かず「実施計画」と最初から書いておけば良いだけであると思うのであるが・・・何かそうすべき意味があるのであろう。

【共通フレーム2007】なぜISOにはあまり反映できなかったのか

P31「（１）共通フレームで拡張、変更した点（ｃ）作業項目の追加①」であるが、「これもISOの場で日本から提案した点であるが、国際規格にはあまり反映できなかった点でもある」とわざわざ書かれている。

これは何を意味するのか。
「なぜ国際規格にはあまり反映できなかったのか」が書かれていない。

この理由が無いと「どうしてISOでは採用されていないのに共通フレームでは勧めるのか」がわからないことになるのではないか。

付け加えると、「これもISOの場で日本から提案した点であるが・・・」とあるが、他の「ISOの場で日本から提案した点」がどこなのかこの文章の周辺では明示されていないため、どのような点のことであるかわからない。

【共通フレーム2007】個別フレームの定義

P28「共通フレームの位置づけ（１）共通フレームと組織標準との関係」において、「組織やプロジェクトには固有の作業標準が存在する」とあり、これを「個別フレームと呼ぶことにする」と書かれている。
そしてその直後に「個別フレームは各社ごとに存在する」と書かれている。

「個別フレーム」に対するこの２つの記述は矛盾しないか。

第一の文では「数社の共同プロジェクトの作業標準」は「個別フレーム」にあたるが、第二の文では「個別フレーム」では無いことになるように見える。

また、第一の文では「ある会社内の部署毎の作業標準」は「個別フレーム」にあたるが、第二の文では「個別フレーム」は会社に一つしか無いように見える。

第一の文と第二の文の意味するところは何なのであろうか。

【共通フレーム2007】動作の主体

P28「５．２共通フレームで取り決めていないこと」では２つのことが列挙されている。

（１）文書化の詳細を規定していない
（２）ソフトウェアの尺度を規定していない

そして、
（１）では、
　　　　　「共通フレームを適用する組織又はプロジェクトでは、
　　　　　　それぞれの特性に応じて文書化の規定を設ければよい」
とあるが、
（２）では、
　　　　　「共通フレームを利用する人達が、たとえば品質特性に関する
　　　　　　規格を利用して、自社の標準に組み入れていけばよいということになる」
と書かれている。

「（１）文書化の詳細を規定していない」のときの主体は「共通フレームを適用する組織又はプロジェクト」で、「（２）ソフトウェアの尺度を規定していない」のときの主体が「共通フレームを利用する人達」と異なるのは、単に繰り返しを避けたためか。

実は、（２）では「共通フレームの利用者」という表現もある。

もし、同じ意味であれば同じ語を使用した方がわかりやすいと思われる。

【共通フレーム2007】「この部分がとりわけ重要である」

P27「（９）修正（テーラリング）の採用」において「共通フレームの適用にあたり、アクティビティ、タスクを取捨選択したり、繰り返し実行したり、複数を一つに括って実行してもよい。この部分がとりわけ重要である」とある。

この「この部分がとりわけ重要である」という記述は何故あるのであろうか。
「共通フレーム２００７」における他の部分に比べ、何故「とりわけ重要」なのかが記述されずに重要と言われても読者は読み取れない。

共通化文書として、敢えて「価値的意味」を含む「とりわけ重要」というのであれば、その理由を明記すべきであろう。

【共通フレーム2007】「ソフトウェアに分解」に対する二重の意味付け

図２－６のV字モデルに対する解説において、「システム方式設計によってハードウェア、ソフトウェア、手作業に分解された後、そのソフトウェア部分に対して下段のソフトウェアの要件定義以下、ソフトウェアの開発に移る」とあるが、その４行後に「V字の左半分がシステムをソフトウェアに分解していく設計の過程」とある。

この両者での「ソフトウェアに分解」の意味は異なる。
後者の方が範囲が広い。
ほんの数行の間しかあいていないので注意が必要。

【共通フレーム2007】「システムはソフトウェアを包含する」は定義なのか検証が必要な事項なのか

P24において「『システム』は『ハードウェア』と『ソフトウェア』、『その他設備』から構成される」とある。これは、「システム」「ハードウェア」「ソフトウェア」「その他設備」の関係を定義したものと思われる。

一方、次のP25において、V字モデルの説明をしながら、最後に「この流れからソフトウェアを包含するものがシステムであることがわかる」とソフトウェアとシステムの関係を証明したかのような記述がある。

これは、どう理解すべきであろうか。
P24の定義を図式化したものの一例がV字であると考えることが自然な気がする。

P24の「『システム』は『ハードウェア』と『ソフトウェア』、『その他設備』から構成される」から、「システムはソフトウェアを包含する」というのは定義である。

そうなると、P25「この流れからソフトウェアを包含するものがシステムであることがわかる」というのは、定義をV字モデルを使って再説明した文ということであろうか。

【共通フレーム2007】ソフト・サービス業者とベンダ企業

ソフトウェアの供給者としての立場である企業を本書では、「開発ベンダ」または「ベンダ企業」と呼んでいる。

この２つはあちこちで出てきており、ほぼ同一の意味として区別されず使用されていると思われる。

一方、P18においては「ソフト・サービス業者」という語が出てくるが、これは他では使われていないようだ。

これも「開発ベンダ」、「ベンダ企業」と同じ意味なのであろうか。
よく読むと違うような気もしてくるので、同じなら「開発ベンダ」か「ベンダ企業」としてほしかったし、違うなら「開発ベンダ」、「ベンダ企業」との違いを書いて欲しい。

尚、「開発ベンダ」、「ベンダ企業」、「ソフト・サービス業者」の３つとも同じ意味であれば、どれか１つに統一するのがより良い選択であると思われる。

【共通フレーム2007】論理的に説明できるもの

Ｐ20「（３）責任範囲の明確化」において、

「企画者、開発者、運用者、保守者などは役割が明確である。しかし、企画した内容が運用に供するか、逆に言えば運用に供せられるように要求仕様を明示したか、それは本来、誰の責任かということを論理的に説明できるものは少ない」

とある。
この文の意味は何であろう。

「論理的に説明できるものは少ない」の真意がわからない。
「論理的に説明できるもの」は１つあれば良くて、複数は要らないと思うのだが。

しかも、「論理的に説明できるものは少ない」と書くだけでその少ないものの手がかりも提示されていないので、読者はそれにあたることもできない。

・・・と思うのであるが、自明であるのであろうか。

【共通フレーム2007】企画プロセスは誰が行うのか

Ｐ20「（３）責任範囲の明確化」において、

経営層は「事業」を行うと記述されている。
この括弧つき「事業」には、図２－２において「システム化の方向性・システム化計画」と「運用・評価」が含まれることが図示されている。
さらに本文中で「企画（システム化の方向性・システム化計画）」と書かれているので、つまり、経営層は「企画」を行うことになる。

一方で、

業務部門は「業務」を行うと記述されている。
この括弧つき「業務」には、図２－２において「要件定義」と「運用テスト」が含まれることが図示されている。

さて、次のページ（Ｐ21）まで読み進むと「企画プロセスは、業務部門を含むシステムの企画者の作業」と書かれている。

これは何を意味するのであろうか。

当初の定義では「企画」の主体は経営層であったはずだ。
そして業務部門の説明にサポートとしても「企画」が触れられていないのであるから、業務部門は「企画」に関与しないはずだ。

それが「企画プロセスは、業務部門を含むシステムの企画者の作業」となっている。

どういう意味なのであろうか。
「企画」と「企画プロセス」は別なのであろうか。

「企画」は経営層が主体であるが、サポートとして関与するために「業務部門を含む」と入れたのだ、という理屈は通らなくも無い、しかし、普通に「企画プロセスは、業務部門を含むシステムの企画者の作業」と書かれたら「企画プロセスは業務部門が主体」と逆の意味に取られなくもないはず。

さらに、P21を読み進むと、図２－３で「例」として役割が整理されているが、そこでは「この例では、企画プロセスにおける経営層や業務部門、あるいは情報システム部門がそれぞれ企画者として関与することを想定している」となっている。

前のP20では「ソフトウェア」「システム」「業務」「事業」の「ソフトウェアの４つの層」のうち、「事業」が「企画」の所管であったはずが、P21では例とはいえ、経営層・業務部門・情報システム部門がそれぞれ企画者として関与することになっている。

このあたりの関係はよく理解できない。

【共通フレーム2007】Ｖ字モデルを使って説明する必然性

Ｐ20「（３）責任の範囲の明確化」において、「事業」「業務」「システム」「ソフトウェア」各担当の責任を定義しようとしているのであるが、ここでＶ字モデルを使用して説明がされている。

しかし、これはＶ字モデルを使わなくとも説明できるものである。
なぜなら、このＶ字モデルに続く記述で、「企画者、開発者、運用者、保守者」という役割と「企画、要件定義、開発、運用テスト、運用・評価」という責任を負うべき範囲が書いてあるので、それらをマトリクスで表現すれば、ここで言いたかったことは言い尽くせるのではないか。

何故ここでＶ字をわざわざ使って説明しているのであろうか。
５ページあとでまたＶ字が出てくるのにも関わらず（しかもここで出たＶ字と違う表現で）。

【共通フレーム2007】サービス業者とユーザ企業の相互理解は誰のメリットか

Ｐ１８に「ソフトウェア・サービス業者の立場からすれば、仕事を受注する場合、作業内容や範囲をサービスメニューとしてユーザ企業に提示するときに共通フレームを参照すれば、相互の理解が深まることになる」とある。

この相互理解のメリットは、「ソフトウェア・サービス業者の立場」だけではなく「ユーザ企業の立場」でも同じく享受できるものであると思える。

何故これが「ソフトウェア・サービス業者の立場」のメリットなのであろうか。
「ソフトウェア・サービス業者の立場」は「ユーザ企業の立場」より弱いということが暗黙の前提にあるからなのだろうか。

もし、「ソフトウェア・サービス業者の立場」のメリットと敢えて書くのであれば、「ソフトウェア・サービス業者の立場からすれば、仕事を受注する場合、作業内容や範囲をサービスメニューとしてユーザ企業に提示するときに共通フレームを参照すれば、ユーザ企業の理解が深まることになる」とした方がしっくりくる。

【共通フレーム2007】国際取引への対応

Ｐ17「４．２　利用方法」に。「（共通フレームの）利用方法を通して、『取引の明確化』，『国際取引への対応』の道が開かれていくことになる」とあるが、何故「国際取引への対応」の道が開かれていくのであろうか。

共通フレームは、国際標準だからということなのであろうか。

もし、ＩＳＯ１２２０７を基盤にしていることを言うのであれば、共通フレームはＩＳＯ１２２０７そのものではないので「国際取引への対応」と、ＩＳＯに関し何の言及も無く書くのは、共通フレームをこれから学ぼうという者に対しては少々不親切な感じがする。

推測であるが、「共通フレームはＩＳＯ１２２０７そのものではない」ことを著作者も意識しているので「『国際取引への対応』の道が開かれていくことになる」という少々奥歯にモノがはさまったような表現をしているのかもしれない。

もしくはＩＳＯ１２２０７に関係なく「国際取引への対応」の道を開く何かがあるのかもしれない。

【共通フレーム2007】システム開発を直接に取得する組織

「システム開発を直接に取得又は調達する組織」とは何であろう。

Ｐ16「４．１（１）直接取引に関わる組織」において、「取得者」の説明に「システム開発を直接に取得又は調達する組織」とあるが、意味が把握しづらい。定義の原文が英語であるのかもしれないが、それならば出典を示したほうが良いと思われる。

これで定義が良いとして、次の（２）において、

「・契約関係作業（システム、ソフトウェア製品、サービスの取得、供給など）」

という記述がある。
ここでの「システム、ソフトウェア製品、サービス」の取得と先の「システム開発を直接に」取得とで、取得する対象範囲はどう違うのであろうか。

同じであれば、最初の記述は、

「システム、ソフトウェア製品、サービスを直接に取得又は調達する組織」

となっているはずなのだけれど・・・・なぜ記述を変えているのだろうか。

【共通フレーム2007】共通フレームの目的

共通フレームの目的についての厳格な解釈を考えてみる。

P15「１．共通フレームの目的」では、「『ソフトウェア開発及び取引の明確化』が可能となるだけでなく・・・」と書かれている。

一方、P17「4.2　利用方法」においては、「『共通フレーム』は、ソフトウェアを中心としたシステムの開発及び取引の明確化のために利用することが目的であるから・・・」と書かれている。

厳密に解釈をすると、「ソフトウェア開発及び取引の明確化」と「ソフトウェアを中心としたシステムの開発及び取引の明確化」では目的の範囲が異なる。

読み進めば「ソフトウェア開発及び取引の明確化」に限定されていると思われるが、これは単なる書き間違いか、それとも書き分ける意図があるのか。

【共通フレーム2007】Ｖ字モデル（その２）

共通フレーム２００７に掲載されているV字モデル（P20でもP25でも良い）は、良く見ると、矢印が書かれている。

一見「ウォーターフォール開発」を示しているように見えるが・・・・共通フレームは特定の技法やツールに無依存として定められている。

矢印が無ければ、仮にこの線が単に直線で結ばれているだけなら、横のレベルでの対応性を示す図として理解できる。しかし矢印であるので、何かの流れを表していることになる。

この矢印は何の流れを表すのであろうか。

実は、２つ目のV字では本文中に「一般的なシステム開発の流れを想定し」と断りがある。
さらに、共通フレーム９８では、図中にも矢印に関する注があり「一般的な開発の流れを表す」と書かれていた。

それだけ気にかけているのであれば、最初に出てくるV字の図でも矢印について言及するべきだと思うのであるが、どのような意図で最初に出てくるV字の図にはこの言及をしていないのであろうか。

【共通フレーム2007】Ｖ字モデル

Ｐ２０とＰ２５に２つのＶ字モデルの図が出てくるが、これがなぜか違う図になっている。
概念的には同じ図であると思われるが、対応項目が異なるし、同じ項目であっても名称が異なっている。

たとえば、一方が「システムテスト」という名称でもう一方が「システム適格性確認テスト」となっていたり、ソフトウェアに関する部分においては全く違う構成になっている。

同じ書籍の中で異なる図をわざわざ書くのであるから意図があるのであろうが、それについて言及されておらず、その理由は不明。

このV字、ページが進んだP238、241にも出てくる。
やはり、他のV字とは別物。

４種類のＶ時モデル。ここまで多いと、わざわざ書き分ける理由を示すべきであると思う。