【共通フレーム２００７】｢支援ライフサイクルプロセス｣と｢支援プロセス｣

Ｐ146｢２．　支援ライフサイクルプロセス｣において、｢支援プロセス｣という語がある。
しかし、これは｢図２－１４　共通フレーム２００７体系｣には無いプロセスである。

読めば、｢支援ライフサイクルプロセス｣と｢支援プロセス｣とは同じ、もしくは｢支援プロセス｣は｢支援ライフサイクルプロセス｣を構成する個々のプロセスであろうことは｢推測｣できる。
しかしこれは｢推測｣であって、本当は違う意味で使われているのかもしれない。

共通フレームは、複数のステークホルダがお互いに｢共通の言葉｣で話すための｢共通の物差し｣を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っている。
｢共通の言葉｣で話すことは難しいことの反面教師的意義はある。

【共通フレーム２００７】監査において｢問題点｣か否かを判定するのは｢監査した者｣ではなく｢監査を受けた者｣

Ｐ170｢２．７．１．６　監査結果と対応策の報告｣には｢監査終了後、監査結果を文書化し、監査を受けた者に配布する。監査を受けた者は、監査で見つけられたあらゆる問題点及びそれらを解決するための計画を、監査した者に知らせる｣とある。

監査で見つけられたあらゆる問題点は監査を受けた者が監査した者に知らせるということは、｢問題点｣か否かを判定するのは｢監査した者｣ではなく｢監査を受けた者｣ということになろう。

ここでの監査と言うのは、警察的取り締まりの意味の監査ではなく、自律改善のための健康診断という位置付けのものと考えれば、これは納得できる記述である。

【共通フレーム２００７】選ばれた成果物及びプロセスとは

Ｐ169｢２．７　監査プロセス｣の｢目的｣では｢監査プロセスは、選ばれた成果物及びプロセスが、要求事項、計画及び合意に対して、適合しているかどうかを独立して決定することを目的とする｣とある。

ここでいう｢選ばれた｣とは何を意味するのであろう。

大きく分ければ、次の２つの考えがあろう。
　　｢対象とされた文書すべてを監査するのではなくサンプリングして監査する｣という意味
　　｢あらかじめ、何を監査するかを決定しておいて、対象はすべて監査する｣という意味

どちらなのか、それともさらに別な定義なのか。

ガイダンスに書かれるべきであろう。

とはいえ、常識的に考えれば前者であろう。

【共通フレーム２００７】「次の計画された活動の準備ができている｣ことの確認は「技術レビュー」なのか

Ｐ168｢２．６．３．１　技術レビューの実施｣では｢検討中のソフトウェア製品又はサービスを評価し、次の事項を明らかにするために、技術レビューを実施する｣とある。

そして列挙される｢次の事項｣の１つに｢（ｅ）次の計画された活動の準備ができている｣がある。

これは｢技術レビュー｣の対象なのであろうか。

１つ前の｢２．６．２　プロジェクト管理レビュー｣の方がしっくりする感じがする。

【共通フレーム２００７】予定の節目で、定期的なレビューとは

Ｐ167｢２．６．１．１　レビューの実施｣では｢プロジェクト計画で指定された予定の節目で、定期的なレビューを実施する。どちらか一方が必要と考えるときは、臨時のレビューを実施することが望ましい｣とある。

｢予定の節目で、定期的なレビュー｣とは何であろうか。

予定の節目でのレビューというのは、普通、工程の区切り等に実施されるものが想定される。
定期的なレビューというのは、普通、プロジェクト進捗とは別に定められた期間間隔で実施されるものが想定される。

｢予定の節目で、定期的なレビュー｣というのは、上記２つの要素を兼ね備えたレビューと読めるのであるが、わざわざ兼ねたレビューに限る必要はなかろう。

｢プロジェクト計画で指定された予定の節目にレビューを実施すると共に、定期的にレビューを実施する。どちらか一方が必要と考えるときは、臨時のレビューを実施することが望ましい｣
と書いても構わないはずである。

２つの要素を兼ね備えたレビューもこの中に含まれるのであるからこちらの方が良いと思う。

【共通フレーム２００７】共同レビューに関する３つの説明

Ｐ166｢２．６　共同レビュープロセス｣では共同レビューを行う期間に関する記述が３個所で書かれている。

本文中その１
｢共同レビューは、プロジェクト管理レベル及び技術レベルの沿う方で、プロジェクトの存在する間行われる｣

本文中その２
｢契約が有効である間は、共同レビューを実施する｣

ガイダンス
｢共同レビューは、管理面と技術面の両方からなり、契約期間中開催される｣

同じページの中で、何度も、しかも、内容をばらばらに記述する必要があるのだろうか。
一度書けばそれで良い気がする。

もちろん３つとも意味が異なるというのであれば、都度言及する必要があるが、そうであればすべてを｢共同レビュー｣という語で説明するのではなく、それぞれ語を使い分けるべきである。

【共通フレーム２００７】｢実環境の領域｣と｢適宜テスト｣

Ｐ165｢２．５．２．５　実環境でのテスト｣では｢実環境の領域をいくつか選び出し、ソフトウェア製品を適宜テストする｣とある。

｢実環境の領域｣とは何であろうか。

また、具体的に何をテストするかに関する記述が｢適宜テストする｣だけでは、淡白すぎると感じる。
ただし、テストに関しては、語るべきことが多すぎて、これ以上踏み込んだ説明を、共通フレームの中で、簡潔に記述することはそもそも無理なのかもしれない。

【共通フレーム２００７】｢代表利用者｣とは

Ｐ165｢２．５．２．３　テストの実施｣の（ｃ）には｢代表利用者｣という語が使われている。
この語は説明なしに使われているが、どのような者を指すかは自明なのだろうか。

ガイダンスで説明されるべきであろう。

【共通フレーム２００７】｢テストを行う｣と｢支援要請である｣との結びつき

Ｐ165｢２．５．２．３　テストの実施｣の（ｂ）では｢ソフトウェア製品から誤りの影響を分離し、最小化することができるかどうかのテストを行う。すなわち、故障時の穏やかな機能縮退、重負荷・境界状況・異常状態時の運用者への支援要請である｣と書かれている。
この中での２つの文は、｢すなわち｣でつながれている。
通常｢すなわち｣は、第１の文を第２の文でわかりやすく説明する場合に使われる。

しかし、
｢ソフトウェア製品から誤りの影響を分離し、最小化することができるかどうかのテストを行う｣
と、
｢故障時の穏やかな機能縮退、重負荷・境界状況・異常状態時の運用者への支援要請である｣
が同じことを指しているとは思えない。

動詞だけを見ても｢テストを行う｣と｢支援要請である｣とは通常結びつかない。

この本文の記述の意味は、ガイダンスにおいて説明されるべきである。

【共通フレーム２００７】品質システムの保証は任意のアクティビティなのか

Ｐ157｢２．３．４　品質システムの保証｣では、｢このアクティビティは、次のタスクからなる｣として、タスクが１つ挙げられている。
その唯一のタスクは、｢２．３．４．１｣として、｢さらなる品質管理活動は、ＪＩＳ　Ｑ　９００１の条項に従って保証されてもよい｣と書かれている。

｢品質システムの保証｣の唯一のタスクが｢されてもよい｣とされている。

｢品質システムの保証｣は任意のアクティビティなのか。
｢品質システムの保証｣は、｢すべきもの｣ではないか。

そして、これは、ＪＩＳ　Ｑ　９００１の条項に従うのみしか存在しないわけではなかろう。

｢品質システムの保証｣は、すくなくとも共通フレームとしては、任意実施項目とすべきではないと思われる。
ここは、記述が甘いと言わざるを得ない。

【共通フレーム２００７】外部委託先・協力会社・ベンダの使い分け

Ｐ157｢２．３．３．３　要求事項の外部委託先への引継ぎ保証｣において、見出しには｢外部委託先｣という語があるのに、本文には無い。変わりに｢協力会社｣という語が出てくる。

共通フレームには、更に｢ベンダ｣という語も出てくる。

｢外部委託先｣｢協力会社｣｢ベンダ｣は、どのように使い分けているのか、説明が必要である。

もし、仮に同じ意味であれば、統一すべきであろう。
共通フレームは、複数のステークホルダがお互いに｢共通の言葉｣で話すための｢共通の物差し｣を用意することであったはずであるが、共通フレーム内で既に同じことを３つの違う言葉で言っていることになってしまう。
｢共通の言葉｣で話すことは難しいことの反面教師的意義はある。

ただ、実際に活用するにあたっては、いこの３つを同じものとして扱っても実質的な弊害は生じないであろう。

【共通フレーム２００７】｢ソフトウェアに関する社内慣習｣とは何か

Ｐ157｢２．３．３．２　開発環境、ライブラリの保証｣において、｢ソフトウェアに関する社内慣習｣という句がある。
｢ソフトウェアに関する社内慣習｣とは何であろう。
なんとなく分かっても、どこまでが｢ソフトウェアに関する社内慣習｣でどこからがそうでないのかは分からない。

共通フレームでは｢社内標準｣という語もある。
これとの違いは何であろうか。

｢ソフトウェアに関する社内慣習｣に｢社内標準｣も含まれると思われるが、例示もしくは説明がないため、何のことか分かりづらい。
受け取り方による理解のばらつきが生じないように、ガイダンスで説明されるべきであろう。

【共通フレーム２００７】｢構成の評価｣とは何をすることか

Ｐ153｢２．２．５．１　構成品目の完全性の保証｣には、｢要求事項に対するソフトウェア品目の機能的な完全性及びソフトウェア品目の物理的な完全性（その設計及びコードが最新の技術解説書を反映しているかどうか）を決定し保証する｣とある。

そして、そのガイダンスとして｢構成の評価は、独立した活動としてあるいは契約で定められた監査プログラムの一部として実施してもよい｣とある。

これは、どういうことであろうか。

本文にない｢構成の評価｣についてガイダンスで言及しているのだ。

｢要求事項に対する・・・物理的な完全性を決定し保証する｣の｢決定｣が、｢評価｣に基づいて行われるということであろうが、もう少し分かりやすいように書かれるべきである。

【共通フレーム２００７】｢修正されたソフトウェア品目の実装｣

Ｐ152｢２．２．３．１　構成の変更管理｣において、遂行すべきものが列挙されている。

（１）変更依頼の識別及び記録
（２）変更の分析及び表化
（３）変更依頼の承認又は不承認
（４）修正されたソフトウェア品目の実装、検証及びリリース

さて、この中で明らかに異質なのは、（１）である。
これのみ、｢変更｣で書きだされていない。

なぜか。

（１）から（３）は、変更そのものではなく変更の管理作業であるが、（４）は変更そのものの作業なのである。

構成の変更管理という意味で列挙されたものは（４）を含め理解できなくは無い。

ただし、｢（４）修正されたソフトウェア品目の実装、検証及びリリース｣は、それ自体の意味がつかみづらい。

｢修正されたソフトウェア品目の検証｣
｢修正されたソフトウェア品目のリリース｣
これらは分かる。
しかし、
｢修正されたソフトウェア品目の実装｣
は、わからない。

｢変更が承認されたソフトウェア品目の実装｣と考えればよかろう。

これは、ガイダンスにて説明されるべきであろう。

【共通フレーム２００７】｢システム構成管理計画｣の一部としての｢構成管理計画｣

Ｐ151｢２．２．１．１　構成管理計画の立案｣において｢構成管理計画を立案する｣とある。
そして、その備考として、｢この計画は、システム構成管理計画の一部であってもよい｣とある。

｢システム構成管理計画｣の一部として｢構成管理計画｣があるというのは日本語的に違和感を覚える。
｢構成管理計画｣の一部として｢システム構成管理計画｣があるというのは日本語的に理解できる。
段階的詳細化の考えで理解できるからである。

｢システム構成管理計画｣については索引を見ても載っていないのでわからない。
両者の関係がよく分かるような説明が必要である。

【共通フレーム２００７】文書化されていない要件の構成管理は可能か

Ｐ151｢ガイダンス　２．２（４）｣において、｢要件の品目の例としては、システム化構想、システム化計画書、要件定義書、システム設計書等が挙げられる｣とある。

この例示の中に一つ異質なものがある。

｢システム化構想｣である。
他はすべて｢書｣が付いており、実際にモノである。

しかし｢システム化構想｣はモノではない。もしくはモノとは限らない。

モノでは無いものをモノとして捉えるのは無理があるのではないだろうか。
｢システム化構想｣は｢システム化構想書｣とすればよい。

｢システム化構想｣は文書化しなければ単なる頭の中のアイディアなのでこう考えれば良いはずであるが、なぜ｢｢システム化構想｣だけ｢書｣が付かないのだろうか。

【共通フレーム２００７】｢ハードウェア、要員、要件｣と｢ハードウェアや要員、組織、要件｣の差

Ｐ150｢２．２　構成管理プロセス｣の｢備考｣において｢このプロセスを他及びソフトウェア製品又は対象とするものに用いる場合、ソフトウェア品目という用語を適宜置き換えること。（例えばハードウェア、要員、要件）｣とある。
これはもはや日本語ではないので、だれも理解できないはずである。

｢他｣とは何か。
また、｢このプロセスを他及びソフトウェア製品又は対象とするもの｣における｢及び｣と｢又は｣はどう使い分けられているのであろうか。

更に、｢例えばハードウェア、要員、要件｣とあるのに、ガイダンスではなぜか｢ハードウェアや要員、組織、要件等｣と例示に｢組織｣が加わっている、しかも｢要件｣の前に。
これは共通フレームのモデルとしての性格上不整合と言わざるを得ないのではないだろうか。
実務上は１つ例が増えても困ることはないが。

更に更に、｢ソフトウェア品目｣を例に挙げている｢要員｣に実際置き換えるとしたらおかしなことになる。

置き換える元の文は次のとおり。

（１）システムのソフトウェア品目を識別し、定義すること
（２）品目の修正及びリリースを管理すること
（３）品目と修正依頼の状況を記録し報告すること
（４）品目の完全性、一貫性、及び正確性を保証すること
（５）品目の保管、取扱い、及び出荷を管理すること

これの｢ソフトウェア品目｣を｢要員｣に置き換えてみよう。

（１）システムの要員を識別し、定義すること
（２）要員の修正及びリリースを管理すること
（３）要員と修正依頼の状況を記録し報告すること
（４）要員の完全性、一貫性、及び正確性を保証すること
（５）要員の保管、取扱い、及び出荷を管理すること

（１）が辛うじて理解できるが、（２）以降は、何を言っているのであろうか。
無理に考えれば、それは要員の人格を無視してモノとして扱うことになろう。

例とはいえ、共通フレーム準拠をいう組織は、これを達成しているのであろうか。

もし、日本のどの組織においても｢要員｣がこのケースに当てはめられないのであるならば、例からは落とすべきであろう。
そして、これを適用する組織がＳＩｅｒであれば、業務を委託すべきではない。

【共通フレーム２００７】｢システム｣｢ソフトウェア製品｣｢データ｣の関係

Ｐ129｢１．７．３．１　移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守｣において、｢システム｣｢ソフトウェア製品｣｢データ｣の語の使い方が混乱している。

見出しでは、
　　　｢移行のためのソフトウェア製品及びデータ作成時の・・・｣
と書かれているが、
本文の始めには、
　　　｢システム又はソフトウェア製品（データを含む）を新しい環境に移行する場合・・・｣
と、｢ソフトウェア製品｣だけでなく｢システム｣が追加されているし、｢ソフトウェア製品｣の中に｢データ｣を含むことになってしまっている。
さらに、次に、
　　　｢いかなるソフトウェア製品又はデータも・・・｣
と、再度｢ソフトウェア製品｣と｢データ｣は別物になっている。

これは、見出しを含めてたった４行の記述の中で見出されるものである。
共通フレームは、複数のステークホルダがお互いに｢共通の言葉｣で話すための｢共通の物差し｣を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っているように思える。
｢共通の言葉｣で話すことは難しいことの反面教師的意義はある。

【共通フレーム２００７】移行を実施せずにシステム運用は実施できるか

Ｐ129｢ガイダンス　１．７．２．１｣において、
｢擬似運用環境で運用テストを実施した場合には業務及びシステムの移行（１．７．３）を実施してから運用を始める必要がある。実運用環境で運用テストを実施した場合にはシステム運用（１．７．４）を実施できる｣
とある。

これは、明らかにはしょりすぎた記述である。
この文は、
｢実運用環境で運用テストを実施した場合には業務及びシステムの移行（１．７．３）を実施せずに、システム運用（１．７．４）を実施できる｣
と解釈できるはずであるが、本当だろうか。

｢１．７．３　業務及びシステムの移行｣には、｢１．７．３．２　移行計画の作成及び移行｣が含まれるが、これを行わなくてもシステム運用を本当に実施できるのだろうか。

｢１．７．３．３　関係者全員への移行計画等の通知｣｢１．７．３．４　新旧環境の並行運用と旧環境の停止｣｢１．７．３．５　関係者全員への移行の通知｣｢１．７．３．６　移行評価のためのレビュー｣｢１．７．３．７　旧環境関連データの保持と安全性確保｣も不要なのだろうか。

結局、
｢擬似運用環境で運用テストを実施した場合であろうが実運用環境で運用テストを実施した場合であろうが、業務及びシステムの移行（１．７．３）を実施してから運用を始める必要がある｣
というのが正しいのではないだろうか。

推測であるが、ここで言いたかったのは恐らく次のことだったのではないだろうか。

｢実運用環境で運用テストを実施した場合は、テストでうまく運用ができることが確認できたら、そのまま本番運用を始めるべきである｣

ただし、これは｢１．７．３　業務及びシステムの移行｣を実施しなくとも良いわけではないのであるが、これを｢擬似運用環境｣との対比で記述し、こちらでは｢１．７．３　業務及びシステムの移行｣を持ち出して記述しているから、誤解を生むことになったのであろう。

と、善意で捉えたいところであるが、Ｐ130｢ガイダンス　１．７．３｣において、｢本アクティビティは、擬似運用環境で運用テストを実施したシステムを、実運用環境に移行する際に実施する｣と、わざわざ繰り返し書かれている。

重要であるからわざわざ二ヶ所に同じことが書かれているのである。

つまり、共通フレームでは、

実運用環境で運用テストを実施した場合には、
　　　　１．７．３．１　移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守
　　　　１．７．３．２　移行計画の作成及び移行
　　　　１．７．３．３　関係者全員への移行計画等の通知
　　　　１．７．３．４　新旧環境の並行運用と旧環境の停止
　　　　１．７．３．５　関係者全員への移行の通知
　　　　１．７．３．６　移行評価のためのレビュー
　　　　１．７．３．７　旧環境関連データの保持と安全性確保｣も不要なのだろうか。
を実施せずに、システム運用（１．７．４）を実施できる

と言っている。

なぜ、このように言い切るのか理解できない。とても自明であるとは思えない。
ガイダンスにおいて、その理由を詳細に書かれるべきである。

共通フレームからは外れることとなるが、テーラリングしてでも、
　　実運用環境で運用テストを実施した場合にも、｢１．７．３　業務及びシステムの移行｣を実施すること
を強く推奨する。

【共通フレーム２００７】すべての並行運転のための活動とは

Ｐ121｢１．６．１２．１　ソフトウェア導入（インストール）計画の作成｣において、｢導入するソフトウェア製品を既存のシステムと置き換える場合には、開発者は契約で要求するとおりに、すべての並行運転のための活動を支援する｣と書かれている。

ここでいう｢すべての並行運転のための活動｣の｢すべての｣とはいかなる意味なのであろうか。
｢契約で要求するとおりに｣という語で、既に｢並行運転のための活動｣の範囲が定義されるのであるから、｢すべての｣は不要であると思われる。

それとも、本当に｢すべての並行運転のための活動｣を対象にするという意味であろうか。
しかし、どう考えても、｢おたくの会社では共通フレームに従って開発していると言ってましたよね、なら『すべての』並行運転のための活動を支援するってことでしょう。だから・・・｣というように開発者がつけこまれるだけの意味しか持たないのではないか。
開発者の方、お気を付けください。

【共通フレーム２００７】｢契約｣がなくとも実施すべきことと｢契約｣がなければ実施しなくとも良いこと

Ｐ121｢１．６．１２．１　ソフトウェア導入（インストール）計画の作成｣において、｢契約｣がなくとも実施すべきことと、｢契約｣がなければ実施しなくとも良いことがうまく整理されていない。

ここでは、
｢開発者は、契約の中で指定された実環境にソフトウェア製品を導入するための計画を作成する。ソフトウェア製品の導入に必要な資源及び情報を決定し、利用できるようにする。契約で指定された場合、開発者は、立ち上げ作業について取得者を支援する。導入するソフトウェア製品を既存のシステムと置き換える場合には、開発者は契約で要求するとおりに、すべての並行運転のための活動を支援する。導入計画は、文書化する｣
と書かれている。
以下に整理して考えてみる。

・開発者は、契約の中で指定された実環境にソフトウェア製品を導入するための計画を作成する。
＝＞｢契約の中で指定された｣が、｢実環境｣にかかるか｢計画を作成する｣にかかるかでこの行為が｢契約がなくとも実施すべきこと｣か否かの意味が変わる。

・ソフトウェア製品の導入に必要な資源及び情報を決定し、利用できるようにする。
＝＞｢契約｣に関する記述がない。だから｢契約がなくとも実施すべきこと｣であると思われる。ただし、他の部分では書かれている｢開発者は｣という行為の主体が書かれていない。つまり、｢資源及び情報を決定し、利用できるようにする｣必要は有るが、他の部分と異なり、それは必ずしも開発者に負わされた義務ではないと言っている。

・契約で指定された場合、開発者は、立ち上げ作業について取得者を支援する。
＝＞｢契約で指定された場合｣と明示されているので、｢契約がなければ実施しなくとも良いこと｣である。

・導入するソフトウェア製品を既存のシステムと置き換える場合には、開発者は契約で要求するとおりに、すべての並行運転のための活動を支援する。
＝＞｢契約で要求するとおりに｣とあるので、｢契約がなければ実施しなくとも良いこと｣である。

・導入計画は、文書化する
＝＞｢契約｣に関する記述がない。だから｢契約がなくとも実施すべきこと｣であると思われる。ただし、他の部分では書かれている｢開発者は｣という行為の主体が書かれていない。つまり、｢導入計画は、文書化する｣必要は有るが、他の部分と異なり、それは必ずしも開発者に負わされた義務ではないと言っている。

共通フレームの記述からは、このように読み取れるが、本当にこの趣旨で書かれているのであろうか。
そして、一読しただけの読者がこのように理解できるであろうか。

せめてガイダンスで補足しないと読者によって解釈が変わってしまうと思われる。

尚、これは｢１．６．１２．２　ソフトウェア導入の実施｣についても同様に言える。

【共通フレーム２００７】「実現可能性」「適切性」というのは基準となりうるか

Ｐ120｢１．６．１１．２　システムの評価｣において、｢システムは、次の基準を考慮して評価する。評価結果は文書化する｣とあり、
次の基準が挙げられている。

（ａ）システム要件のテスト網羅性
（ｂ）期待した結果への適合性
（ｃ）運用及び保守の実現可能性
（ｄ）使用されたテスト手法及び標準の適切性

ここで、（ａ）（ｂ）は基準と言えようが、（ｃ）（ｄ）は基準と言えるかは微妙である。
特に、｢（ｄ）使用されたテスト手法及び標準の適切性｣は、観点とはいえるが基準とは言えないと考える。
基準と言うのは、何かを判断・評価する際に使用する物差し的なものであると考えるが、（ｄ）は、人による主観の面が強く、評価の差が他に比べて大きいからそのように考えるのである。

もちろんこれらを評価すること自体には意義が有ると言えよう。

【共通フレーム２００７】｢開発計画｣とは何か

Ｐ114｢ガイダンス　１．６．５．１｣において、｢開発計画｣という語が出てくるがこれは何であろうか。
｢開発計画｣とは｢開発プロセス実施計画｣のことと思われる。
しかし、なぜそう書かれていないのか分からない。

共通フレームは、複数のステークホルダがお互いに｢共通の言葉｣で話すための｢共通の物差し｣を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っているように思える。
｢共通の言葉｣で話すことは難しいことの反面教師的意義はある。

【共通フレーム２００７】｢詳細設計｣と｢ソフトウェア詳細設計｣

Ｐ114｢１．６．５．６　ソフトウェア方式設計の評価｣において、なぜか列挙項目に（ａ）（ｂ）・・・のような項番がついていない。
それはともかく、ここでは、かなり言葉の短縮がなされている。

｢要件｣や｢詳細設計｣と言われても共通フレーム上は何のことか一意に決まらない。

｢要件｣は｢業務要件｣なのか｢システム要件｣なのか。
｢詳細設計｣は、おそらく｢ソフトウェア詳細設計｣のことであろうが、なぜそのように書かれていないのか分からない。

共通フレームは、複数のステークホルダがお互いに｢共通の言葉｣で話すための｢共通の物差し｣を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っているように思える。
｢共通の言葉｣で話すことは難しいことの反面教師的意義はある。

【共通フレーム２００７】｢工程｣ではない｢詳細設計｣とは何か

Ｐ114｢１．６．５．１　ソフトウェア構造とコンポーネントの方式設計｣において、｢ソフトウェア品目に対する要件は、すべてソフトウェアコンポーネントに割り振り、更に細部を明らかにして、詳細設計をやりやすくしなければならない｣と書かれている。
ここに｢詳細設計｣という語が出てくる。

｢詳細設計｣とは、ソフトウェア開発においては、通常｢工程｣の一つとして使われる。

一方で、Ｐ23｢（４）工程、時間からの独立性｣にあるように｢共通フレームは、工程や時間に依存して定義されたものではない｣となっている。

では、｢工程｣ではない｢詳細設計｣とは何かということになるが、その他の場所で｢詳細設計｣という語があちこちに出てくることもないので、よくわからない。

｢工程、時間からの独立性｣は崩れることになるが、ここでは通常使われる｢詳細設計工程｣のことと理解して良いであろう。

【共通フレーム２００７】｢一貫性｣と｢外部一貫性｣

Ｐ112｢１．６．４．２　ソフトウェア要件の評価｣において、ソフトウェア要件の評価基準の一つとして｢システム要件との外部一貫性｣が挙げられている。

一方、｢１．６．２．２　システム要件の評価｣では、｢取得ニーズとの一貫性｣という基準が挙げられている。
また、｢１．６．４．３　システム方式設計｣では、｢システム要件との一貫性｣が挙げられている。

これらにおいて、｢一貫性｣と｢外部一貫性｣とはどのように使い分けられているのであろうか。

まず、｢１．６．４．３　システム方式設計｣の｢システム要件との一貫性｣について｢外部｣が付かないのは、一貫性を評価するレベルが｢システム方式設計｣と｢システム要件｣という共に｢システム｣という同じレベルであるからと解釈できる。

この考えを使えば、｢１．６．４．２　ソフトウェア要件の評価｣での｢システム要件との外部一貫性｣は｢ソフトウェア要件｣と｢システム要件｣という、一貫性を評価するレベルが上下の関係になるから｢外部がつく｣ということで理解できる。

しかし、この考えは、｢１．６．２．２　システム要件の評価｣の｢取得ニーズとの一貫性｣においては少し違和感が残る。
｢システム要件｣と｢取得ニーズ｣は同じレベルなのか、上下なのかで評価が分かれそうである。

｢一貫性｣と｢外部一貫性｣をわざわざ使い分けるのであるなら、その違いがわかるようにガイダンスにでも書かれているとよいと思われる。

そうでなければ、おそらく実際の活用においては、この区別は気づかれず考慮されないであろう。

共通フレームを、体系だったモデルとして使うのであれば、わざわざ使い分けている語を、意識してではなく無意識に混同して使用されることは避けなければならないのであるが、この｢外部一貫性｣については分かりづらいので、補記が必要であろう。

【共通フレーム２００７】システム方式とシステム方式設計

Ｐ111｢１．６．３．４　システム方式の評価｣とある。
また、次に｢１．６．３．５　システム方式設計の共同レビューの実施｣と続く。

一方、Ｐ114｢１．６．５．６　ソフトウェア方式設計の評価｣があり、｢１．６．５．７　ソフトウェア方式設計の共同レビューの実施｣が続く。

内容的にほとんど同じ構成のはずなのに｢１．６．３．４　システム方式の評価｣にだけ｢設計｣の語が付いていない。

他の３つにはあるのに。

わざわざ変える理由は分からない。

【共通フレーム２００７】システム方式設計の段階での利用者文書作成の実現可能性

Ｐ111｢１．６．３．２　利用者文書（暫定版）の作成｣において、｢開発者は、利用者文書の暫定版を作成し、文書化することが望ましい｣とある。

言いたいことは、分かる。
利用者文書を、開発が進むにつれて段階的に書き上げていけと言っているのである。

しかし、実際にこれをシステム方式設計の段階で作成を開始することは難しいのではないだろうか。

ソフトウェアがどのようになるか分からなければ、ほとんど書く内容が無いと思われる。
もしくは、書けたとしても、本番稼動後に利用者文書を活用する利用者にとっては不要な情報となる可能性が高くなるのではないだろうか。

しかも、共通フレームでは、｢１．６．３．２　利用者文書（暫定版）の作成｣が書かれている｢１．６．３　システム方式設計｣よりもV字モデルの順番としては後に来る｢１．６．４　ソフトウェア要件定義｣の｢１．６．４．１　ソフトウェア要件の確立｣において、｢利用者文書｣の要件を確立するとある。

素直に読めば、｢利用者文書｣の要件を確立する前に、利用者文書の暫定版を作成することを推奨していることになってしまう。

以上から、｢１．６．３．２　利用者文書（暫定版）の作成｣は、外して考えてよい。

尚、共通フレームでは、利用者文書の例として、システム運用マニュアル、システム運用マニュアルが挙げられている。

【共通フレーム２００７】開発者が契約によって実施又は支援しなければならないタスクとは

Ｐ111｢１．６．３　システム方式設計｣において、｢このアクティビティは、開発者が契約によって実施又は支援しなければならない次のタスクからなる｣とある。
ここで｢契約｣という言葉がわざわざ書かれているが、これは何を意味するのであろう。

｢１．６．２　システム要件定義｣においても｢開発者が契約に従って…｣という文言がある。

これは、普通に考えれば｢契約によって｣等の記述が無ければ｢契約｣は無くともよいと解釈できそうだが、開発プロセスにおける他の開発者の作業を見ても、そう言うわけでもないと思われる。

では、なぜ共通フレームの開発プロセスでは｢１．６．２　システム要件定義｣と｢１．６．３　システム方式設計｣は｢契約｣に基づくことをわざわざ記述しているのであろうか。

｢１．６．１０　システム結合｣｢１．６．１１　システム的確性確認テスト｣においては｢契約で要求されている場合には、開発者はこれらのタスクを行うか又は支援する｣という記述がある。
これは、｢１．６．１０　システム結合｣｢１．６．１１　システム的確性確認テスト｣は開発者が当然実施する作業ではなく、契約があ有ってはじめて実施すべきものであることを言っている。
この記述がヒントになるかもしれない。

共通フレームにおいては、｢１．６．１０　システム結合｣｢１．６．１１　システム的確性確認テスト｣ほど強くではないが、｢１．６．２　システム要件定義｣と｢１．６．３　システム方式設計｣は、開発者が当然実施する作業ではなく、契約が有ってはじめて実施すべきものであることをほのめかしているのであると推測可能である。

では、なぜ｢１．６．１０　システム結合｣｢１．６．１１　システム的確性確認テスト｣のように、はっきり書かなかったのか。
｢１．６．２　システム要件定義｣と｢１．６．３　システム方式設計｣の方が、｢１．６．１０　システム結合｣｢１．６．１１　システム的確性確認テスト｣よりも開発者が行うケースが多いため、控えめな表現になったということではないだろうか。

実際には、当然であるが、共通フレームにおける記述の有無に関わらず、すべての開発者作業は契約又は合意の上で行われなければならない。

【共通フレーム２００７】利用者｢集団｣とは何か

Ｐ110｢ガイダンス　１．６．２　システム要件定義｣において、｢何を要求されているかを十分に理解するためには、利用者集団からのヒアリングを行うとよい｣とある。
ここでは｢利用者集団｣という語が出てくる。

Ｐ22の表２－１に挙げられている｢共通フレーム上の役割｣には、｢利用者｣しか定められていない。

P22の｢共通フレーム上の役割｣で定める｢利用者｣は、ただ一人の利用者を想定しているとは思えないし、Ｐ296の用語集における｢利用者｣の説明も｢ある機能を果たす運用システムを利用する個人または組織｣と｢組織｣も書かれているので、ここは｢利用者｣と書かれても問題ないはずである。

なぜここでは｢集団｣という語を付け足されたのか。

システムの利用者といっても、大規模システムであれば、様々な利用者の階層があり、階層ごとに特化した要求も有れば、階層によって同じニーズに対する要求が異なることもあるだろう。

｢利用者｣というと単一のもしくは、きれいに正規化された要求をもつ利用者をイメージしやすいので｢利用者集団｣と書くことで、広範囲の利用者からヒアリングせよという意味を持たせたと思われる。

尚、｢利用者集団｣という語は、Ｐ１１３｢ガイダンス　１．６．４｣にも出てくる。
ここも、要求の聞き込みに関する記述であるので、上で記述した理解で問題はないと思われる。

【共通フレーム２００７】｢取得ニーズ｣を開発者はどこで入手するのか

Ｐ110｢１．６．２．２　システム要件の評価｣において、｢次の基準を考慮して、システム要件を評価する｣とあり、その基準として挙げられた５つの中に、｢取得ニーズへの追跡可能性｣｢取得ニーズとの一貫性｣がある。
索引で｢取得ニーズ｣を調べても、この１．６．２．２の記述のページしか載っていないので分わからないが、、この取得ニーズは、どこで入手するものであろうか。

｢取得ニーズ｣はユーザの視点でのもので、１．６．２．２で行う｢システム要件の評価｣は開発者の視点のものである。
両者は｢業務要件｣を仲介して関係しているものであるから、ここでは、｢取得ニーズ｣を｢業務要件｣と置き換えて考えれば良いのではないだろうか。

それともあえて｢業務要件｣は見るなというのであろうか。

【共通フレーム２００７】｢システム要件｣と｢システム要求仕様｣

Ｐ110｢１．６．２．１　システム要件の定義｣において、｢システム要件には、次のものを記述する｣とあり、また一方で｢システム要求仕様は文書化する｣とある。
つまり｢システム要件｣と｢システム要求仕様｣は別物のように書かれている。

一方で、P73｢１．１．１．２　システム要件の定義と分析｣では、｢システム要件｣に、様々な｢要求事項｣が含まれることが、記述されている。

｢１．１．１．２　システム要件の定義と分析｣における｢要求事項｣に｢システム要求仕様｣は含まないということであれば、つじつまはあうが、これはP73｢１．１．１．２　システム要件の定義と分析｣の考えを採用したほうが良いと思われる。

【共通フレーム２００７】｢システム設計｣とは何か

Ｐ110｢１．６．２　システム要件定義｣において、｢システム設計｣という語が出てくる。
共通フレームでは、｢システム方式設計｣｢ソフトウェア方式設計｣｢ソフトウェア詳細設計｣は、定められているが、｢システム設計｣は無い。
この語は、P１１２｢１．６．４　ソフトウェア要件定義｣にも出てくる。
しかし索引にはない。

｢１．６．４　ソフトウェア要件定義｣では、ソフトウェア要件定義の目的はシステム設計が可能な技術要件に変換することであるとしているので、ここでいう｢システム設計｣とは、｢システム方式設計｣のみではなく、｢ソフトウェア方式設計｣｢ソフトウェア詳細設計｣も含む概念であるといえる。

共通フレームのモデルとしての分かりやすさから考えれば、｢システム設計｣などという新しい語を追加するのではなく、既に定められた｢システム方式設計｣｢ソフトウェア方式設計｣｢ソフトウェア詳細設計｣を適宜組み合わせることで表現すべきであった。

【共通フレーム２００７】別の計画とは何か

Ｐ104｢１．６．１．４　開発プロセス実施計画の作成｣において、｢必要な場合、別の計画を作成しても良い｣とあるが、｢別の計画｣とは何か。
また、どのような時が｢必要な場合｣なのか。

これはガイダンスの場所でよいので、もう少し分かるように書くべきである。

【共通フレーム２００７】｢開発プロセスにおける開発者とは

Ｐ108｢１．６　ガイダンス｣において、｢開発プロセスにおける開発者とは、実際に成果物を作成する者のみならず、それを支援する者、要求を出す側の業務担当者、運用を行う運用担当者も含まれる｣とある。
これは、P22　表２－１でまとめられた｢開発者｣の実施の組織／役割とほぼ同じであり、わざわざ書かなくとも良いと思われる。

活用者の参考のために記述したというのであれば、この説明内容は、｢開発プロセスにおける開発者｣に限らず、全プロセスにおける｢開発者｣が対象であるので、｢開発プロセスにおける｣という修飾は不要であろう。

もし、他のプロセスと｢開発プロセス｣で、｢開発者｣の意味が異なるのであれば、それは別な語を当てた方が良いが、意味が異なることはないと思われる。

【共通フレーム２００７】｢プロセス｣と｢ライフサイクルプロセス｣

Ｐ93｢１．４．１．２　必要な支援プロセスの実施｣において、｢支援プロセス｣と書かれているが、次の｢１．４．１．３｣では｢支援ライフサイクルプロセス｣とある。
ぱっと見では、その違いはわからない。

両者の違いは、P１４６｢２．　支援ライフサイクルプロセス｣の記述から読み取ると、

｢支援ライフサイクルプロセス｣は、９つの｢支援プロセス｣の総体を指す

ことがわかる。

【共通フレーム２００７】プロセスを呼び出すとは

Ｐ91｢１．３．５．２　基準線の変更｣において、｢変更手続きは構成管理プロセス（２．２参照）を呼び出して行う｣とある。
｢呼び出して行う｣とはどのような行為なのか。
他の部分では例えば｢監査は２．７(監査プロセス)に従って実施する｣（P８７）のように｢従って実施する｣が使われているが、この｢従って実施する｣と｢呼び出して行う｣はどのように違うのか書かれるべきであろう。

尚、｢呼び出す｣という語は｢ガイダンス　１．６．４．１｣にも出てくる。

【共通フレーム２００７】影響の調査分析で望ましいこと

Ｐ90｢１．３．３．１　影響の調査分析の根拠｣において、ガイダンスで｢必要に応じて要件定義プロセス（１．５参照）、開発プロセス（１．６参照）を使用することが望ましい｣とある。

これに関し、次の二点が不明である。

｢１．６　システム要件定義｣の使用は不要なのか。

｢１．５　要件定義プロセス｣は、P22で見ると、ベンダは｢責任の主体｣のみならず｢支援｣の役割も担わない。
役割を担わないにもかかわらずプロセスを使用するとはどういうことなのかをもう少し説明されるべきであろう。

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

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

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

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

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

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

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

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

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

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

【共通フレーム２００７】「ソフトウェア製品」の範囲

Ｐ131｢ガイダンス　1．7．3．1｣において、｢共通フレーム２００７では移行のためのツールやデータも製品の一部としている｣とある。
｢1．7．3．1　移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守｣では、｢製品｣という語はなく、｢ソフトウェア製品｣しかないので、ここで言う｢製品｣とは｢ソフトウェア製品｣のことであろう。

尚、Ｐ16｢３．　共通フレームの適用分野｣においては、｢（１）に言うソフトウェア製品とは、製品として販売されるソフトウェア及び、家電製品に内蔵される組み込みソフトウェアなどを指す｣とあるが、｢（１）に言うソフトウェア製品とは｣とあるから、これはＰ１６｢３．　共通フレームの適用分野｣においてのみの定義ととらえなければならない。

｢1．7．3．1　移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守｣と｢ガイダンス　1．7．3．1｣では、同じ意味で違う語を使用し、｢1．7．3．1　移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守｣と｢３．　共通フレームの適用分野｣では、違う意味で同じ語を使用している。

共通フレームは、複数のステークホルダがお互いに｢共通の言葉｣で話すための｢共通の物差し｣を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っている。
｢共通の言葉｣で話すことは難しいことの反面教師的意義はある。

【共通フレーム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字とは別物。

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