商品の詳細

• Amazon.co.jp ランキング: #169233 / 本
• 発売日: 2007-10
• 版型: 単行本
• 305 ページ

内容（「BOOK」データベースより）
ソフトウェアおよびシステム開発工程や取引等一連のプロセスを定義し、ベンダとユーザの役割分担を明確化。今回の改訂では、「要件定義プロセス」を浮き立たせ、情報システムを利用する部門が自ら業務設計することの重要性を明示した。

カスタマーレビュー

誰に共通のフレームか？
経営者が参画するシステム開発においては、技術を使わないことが重要な視点になるとあるコンサルに指導を受けたことがあります。
経営者は、いかに技術を使わずに、人を組織化できるかが問われているかもしれません。

同じ文脈では、業務部門は、いかに顧客に満足を与えるかが問われていると考えるとよいかもしれません。

コンピュータシステムが顧客に満足を与えることは少ないと仮定して考えるとよいかもしれません。
お客さんがコンピュータが好きであれば、コンピュータを使うのは一つの手段です。
その際も、コンピュータシステム企業向けの仕事ではなく、最終的な顧客が何を喜ぶかを考えて仕事をすることが重要だと思います。

情報処理推進機構のシステムが、どのような開発および取引をしているかを、このフレームに基づいた事例の紹介があると、内容がより分かりやすくなるかもしれません。

国際規格適合と書いています。どう適合しているかが書かれていません。

ISO/IEC Directives, ISO/IEC 17000シリーズなどに照らして、どのように適合しているかなどがわからない点が残念かもしれない。

「企画プロセス」という用語がありますが、どう国際規格と適合しているかの説明がありません。
「企画プロセス」と呼んでいるものは、システム開発においては、プロジェクトマネージメントプロセスの実装プロセスになると思われます。抽象的なプロセス定義とその実装のプロセス定義の両方をモデルにあること自体は悪いことではありませんが、その関係の説明がない理由がよくわかりません。

国際規格のISO/IEC12207とISO/IEC15288とが整合していないために調整中であるとお聞きしています。
CMMなど国際規格ではない文書についての説明よりも、ISO/IEC15288の説明や、ISO/IEC15504の説明が希薄なのはなぜなんでしょうか。
CMMがどの国際規格への適合のためにCMMIになったという説明が詳細にないのは何故でしょうか。

読めば読むほど分からないことが沢山出てきます。
そういう意味で、勉強になる本かもしれません。

結局不明確
昨年、出版と同時に購入し、社内の標準プロセスを定義しようとしているが、未だに時系列的にプロセスを定義しようとすると、アクティビティやタスクがよくわからなくなってしまう。巻末に時系列的にプロセスを定義した表があるが、その作業をどの程度まで仕上げるのか、作業の深さが書かれていないため、自分たちで規定するしかない。共通の物差しで作業内容に意識ずれをなくすことが目的といっているが、内容は曖昧であり、このままの内容で双方が意識したときには、「ここまでやると思っていたのに」といった、成果物のレベル感が異なってしまい、問題になるだろう。
それに、ＩＰＡは自らが他で出版している著書で定義しているプロセスと、この共通プロセスとは異なっており、ＩＰＡ内でも統一されていない状況である。
今の版では、どうかわからないが、発売当初に買ったため、誤字誤植が多く、参照先が全く異なっていたといった間違いは非常に多く、チェックをしないまま出版したものと思われるぐらいである。

共通フレームの目的を果たしていない
あまりに抽象的すぎて、共通フレームとしての目的を果たしていません。
多くのプロジェクトを調査して、最大公約数的に開発プロセスをまとめると、こんな内容になるのでしょうか？
残念ながら、日本におけるシステム開発の共通フレームはこうあるべし、という著者の思いはここには入っていないようです。

・プロセスの定義
　一見、定義しているように見えますが、「〜してもよい」「〜が望ましい」のオンパレードで、結局定義できていません。
・開発関係者の役割分担
　当たり前のことしか、書いてありません。受け入れ試験での役割分担や、検収の基準くらいモデルとして定義してもいいのではないでしょうか。

※総じて実践的な内容は皆無です。