本書で伝えたいことは一つ「UMLを使う技術」です。UMLを学び始めたときは、すべての仕様書をUMLだけで書けてしまうと思いがちです。でも、これはほとんどの場合間違いで、プロジェクトの進捗にあった適切なドキュメントを、一番コストがかからない方法で作成する方がよいのです。
本書では、「UMLを読む技術」、「UMLを描く技術」、「UMLで検証する技術」、「UMLで進捗管理する技術」を学ぶことができます。"プロジェクトマネージャのための" とタイトルにあるように、プロジェクト管理にUMLを使う方法を学べるのが特色です。
UMLを読む技術、UMLを描く技術と言うと、かなり濃いところまで説明されているように感じる人もいると思います。しかし、本書では設計段階に落とす前までの、つまり業務分析や業務モデリングの段階で使える程度の知識を学ぶところに焦点が当てられています。なので、決して技術者向けということは無い感じです。
プロジェクトで、UMLを導入してみたいと思っているプロジェクトマネージャーや管理者、業務分析や業務モデリングで作られたドキュメントを読む必要の在る設計者におすすめします。とても分かりやすい言葉で書かれていて、理解しやすいです。入門書として活用するのが効果的だと思います。
特徴
本書は、プロジェクトの上流段階でUMLをどのように使うかを解説した本になっています。対象読者はプロジェクトマネージャや管理者になっています。
UMLを読む技術、UMLを描く技術として、業務分析や業務モデリングの段階でUMLを利用する方法について述べられています。UMLで検証する技術、UMLで進捗管理する技術として、お客様の要求をチェックしたり、現在の進捗を可視化する方法について解説してあります。
読み書きのレベルとしては、ユースケースを導出したり、クラス図やアクティビティ図を描いたり読んだりすることができるようになります。そうしてできたユースケースやクラス図を使って、要求のチェックや進捗の管理を行っていきます。
ぶっちゃけた話をすると開発者としては物足りない部分もあります。本書に書かれているUMLの使い方ではモノ(プログラム)はできないからです。しかし、プロジェクトマネージャや管理者がどうしてこういう分析結果になったのかということを理解するための知識を身に付けるにはいいと思います。
読みやすく技術書にしては安いので、読み物として購入するのがいいと思います。僕にとっては、値段と中身を比較したらプラスになったかなという感じです。
覚書き
システムに必要な情報
システムを作るために必要な情報というのは、ベンダー側ではなくユーザ側にある。足りない情報は随時ユーザから聞き出さなければならない。足りない情報を補完するために要件整理をUMLで行う。
ウォーターフォールモデルのメリットとデメリット
ウォーターフォール型モデルは、各フェーズ(要件定義・分析・設計・実装・テスト)で契約をコミットするという事が前提条件となる。つまり、後戻りがしづらい。しかし、要件定義以外は、時間とパワーさえあれば後戻りは可能である。
追加案件や機能追加は、ウォーターフォールモデルではできないと考えている人も多い。しかし、実際には要件定義、分析、設計のフェーズが増えるだけで、実装とテストに組み込めばいいだけである。シンプルであるのでほとんどデメリットらしいものはない。
僕の考えでは、確かにプロジェクトマネージャの視点で見るとデメリットはないと思う。むしろ使いやすくていいと思う。しかし、開発者の視点で見ると、実装の段階で無理やり組み込むイメージがあり、設計が破綻してしまう可能性が高いように思う。力のある技術者がいれば何とか形になるものの、保守の段階でコストが膨らむ可能性があるように感じる。
要件定義で行うこと
システムとは、ユーザ企業の何らかの戦略の一部であることがほとんどで、要求されている機能にはそれぞれ意味があり、機能同士にはなんらかのつながりがある。まずはじめにしなければならないことは、要件に書かれている機能同士のつながりを把握することだ。
機能の把握にはアクティビティ図が使える。
参考
- UMLを使ってEAを理解するための本(PM向け)
- オブジェクト指向でなぜ作るのか？その疑問の答えはここに(開発者向け)
- 要求を見逃さないための一冊(PM向け)