社会、経済 競争力強化 マネジメント ビジネス 企業改革 管理手法 CSR コンサルティング IT戦略 IT-ROI 組織・人材 思考法 SLCP 上流工程 方法論 ソフト品質 モデリング、SOA プロジェクト IT基盤 運用管理 内部統制 コミュニケーション  ナレッジ 情報理論 ERP SCM セールス、SFA マーケティング 製造業 流通業 サービス業 ネットビジネス  IT入門 SE ITソリューション ワークスタイル 今週のブックガイドへ

■上流工程

あなたはまだそんな「仕様書」を書いているんですか？――ダメダメ「仕様書」の改善提案書
●宮古 環＝著 ●秀和システム　2009年1月 ●1400円＋税　978-4-7980-2175-1
	2009年4月から、ソフトウェア受託開発にも工事進行基準が原則適用となる。これにより開発現場では、顧客との合意点やその妥当性を明確にする仕様書が必ず要求される。プログラミングではミスがあるとコードをコンパイルできないが、仕様書では「使えない仕様書」が作られ、使われてしまう場合がある。そして、プロジェクトで利用する技術に詳しくても使える仕様書が書けるとは限らない。本書は、こうした問題を解消する技法を紹介する。 現場の技術者が仕様書を書けない理由として「お客さまが悪い」（＝自分は悪くない）といったり、予算や技術要因を持ち出したりすることが多いが、「それは無理だが、○○の条件ならできる」「その方法ではなく、お客さまの欲しいものを作るには○○の条件で、○○すべきだ」といった前向き（全否定ではなく部分否定の）意見に変えなければ始まらない。 お客さまとのコミュニケーションは、キャッチボールのように相手に意見を投げてもらい、それを受け取って自分の意見を投げ返すことが必要だ。相手の言いたいことがよく分からないときは「つまり何が言いたいのでしょうか？」という「魔法の言葉」を投げることが有効だ。しかし、状況により相手の気分を害すだけに、「つまり、こういうことでしょうか？」と少し変形させて柔らかくし、相手の意見を代弁することが大事だ。もちろん、これでも気分を害する人がいるが、相手が気に入ってくれる答えを、自分が出せるまで続ける必要がある、と説く。 ほかに流れの把握、議事録の書き方、レビューを成功させるコツなど、基礎・基本を特に分かりやすく説明している。コミュニケーションや文章力が鍛えられるだけでなく、仕様書のメンテナンスにも言及していて有益だ。（ライター・生井俊）

はじめての設計をやり抜くための本――概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで
●吉原 庄三郎＝著 ●翔泳社　2008年12月 ●2380円＋税　978-4-7981-1706-5
	システム設計がはじめての人や、見よう見まねでやってきたが基礎から学び直したい人。そんなエンジニア向けに、本書はユースケース、概念モデル、データベース設計、アーキテクチャ設計の4つを中心に、設計を「やり抜く」ためのノウハウをまとめる。 設計は、要件定義の内容をシステムでどのように実現するかの検討、明確になっていない外部仕様の検討、メンテナンスのために設計情報を残す、といった目的で行われる。要件定義したものを、どのようにシステムで実現するかを記述するだけでなく、開発するシステムの品質を定義したり、複数人のプロジェクトで開発する場合に情報を共有できることもその目的に含める。 開発プロジェクトでは、みんなが必要最低限の情報を必要最低限の相手にだけ見せようとする。また、誰かが全員にメールを書いても誰も返信しようとはしない。それで十分ではないかと思うかもしれないが、情報量も相手も少し多めにしておくのがコミュニケーション（情報共有）のコツだ。そういったコミュニケーションがシステムの品質を高め、作業効率を上げる、と説く。 本書は、ユースケースモデリングやデータベース設計などを紹介しながら、どこかに特化するのではなく、設計工程の最初から最後までをきちんと解説している点が優れている。難解なIT用語も丁寧に解説してあり、設計初心者でもすいすい読み進められる参考書だ。（ライター・生井俊）

顧客の要求を確実に仕様にできる要件定義マニュアル
●神崎 善司＝著 ●秀和システム　2008年11月 ●2600円＋税　978-4-7980-2099-0
	あなたがもしプロジェクトリーダーなら、漠然としたシステムのイメージをどのようにまとめるだろうか？ 要件の定義は試行錯誤が常であり、作業をうまく管理しないと要件定義工程はすぐに混乱する。本書はUMLによる要件定義手法であるリレーションシップ駆動要件分析（RDRA）を解説し、作業特有の混乱をコントロールする手法を説明する。 RDRAの要件定義は、入れ子の構造で、外側が内側の前提条件を表す構造になっている。要件定義には網羅性と整合性が必要で、この前提条件を表した構造から導き出すことができる。この構造を一般化して、要件を定義するための枠組みとして活用していく。そのためにも、構造を「システムの価値を明確化する」「システムの外部環境を把握する」「システム境界を把握する」「システムを把握する」という4つのステップととらえ、各々のステップに目的と役割を与える。 この4つのステップを利用するとき、「システム」から「システムの価値」までの各ステップで、常に外側に向かって網羅性を確保しておく必要がある。そのためにはまず、機能とデータを導き出す前提であるシステム境界に明確さを求める。そして、システム境界に網羅性を持たせ、最終的にシステム価値の網羅性へと結び付けていく。システム価値がどのように網羅性を確保するかだが、システムやそれを取り巻くユーザーや利害関係者が網羅性を決めることになり、そこから導き出されたシステムの目的や役割を実現することがシステム化の目的だ、という。 本書は、理論編・モデリング編・実践編・リファレンス編から構成され、基本的にはUMLを知っていることを前提で話が進む。要件定義の悩みとその解決方法を模索しているエンジニアにとって有益な内容だろう。（ライター・生井俊）

RFP作成実践！ガイド――ベンダーに伝わる業務要件の書き方
●MPUF RFP研究会＝著／Microsoft Project Users Forum＝監修 ●アスキー・メディアワークス　2008年9月 ●2200円＋税　978-4-04-867369-3
	システム開発におけるトラブルが後を絶たない。それは、ユーザーの生の期待と、コンサルタントやベンダのフィルタを通ったユーザーの期待とが一致しないことに起因している。この原因を取り除くためにユーザー自身の手によってRFP（提案依頼書）を作成し、ベンダに提示することが求められている。本書は、ユーザーがテンプレートを使い、RFPを作成する方法をストーリー仕立てで紹介する。 「簡単！ RFPテンプレート」とは、業務要件を記述したり、課題を整理するためのシートなど、RFP作成に必要な雛（ひな）形と、それを使ってRFPを作成するためのガイドから構成されているもの。その中でカギを握るのが、「3点セット」といわれる業務環境図と業務記述書、業務フローの3つのシートだ。このテンプレートを使い、あるがまま（As-Is）とあるべき姿(To-Be）を作成していく。 As-IsとTo-Beそれぞれの「3点セット」作成で使用するテンプレートは同じだが、誰に向けて、何に使うのかが大きく異なっている。例えば、As-Is3点セットの目的は「業務の現状を可視化して、現状の問題点を洗い出す」ことで、To-Be3点セットなら「RFPの業務要件として、業務のあるべき姿を具体的に表現する」ことにある。これらは目的や閲覧対象、性質、用途の違いがあるほか、それぞれの「心構え」の部分が大きく異なる。そこを正しく認識していくことが3点セット作成の肝となる、という。 本書には「簡単！ RFPテンプレート（第2版）」などを収録したCD-ROMが付属。ストーリーを読みながら、この支援ツールであれこれ入力してみると理解が深まるだろう。RFPをどう作成すべきか、また業務要件がうまく作成できないなどで悩んでいるユーザー企業・組織の担当者向け。（ライター・生井俊）

上流工程UMLモデリング――業務・要求分析からプログラミングへのモデル化技法
●浅海 智晴＝著 ●日経BP社　2008年8月 ●2400円＋税　978-4-8222-8366-7
	モデリングは現状の業務の姿を浮き彫りにし、解決手段となるITシステムの姿を具体的に表現する技術だ。本書は、上流工程で作成したUMLモデルをプログラムに落とし込んでいくまでの過程を、著者が開発した「SimpleModeling」を使って解説する。 SimpleModelingでは、「業務モデル」「ドメインモデル」「要求モデル」「システムモデル」「設計モデル」の5つを作成し、企業のITシステムを構築していく。SimpleModelingの業務モデリングでは、達成すべき「業務の目標」とこの目標達成を阻害する「業務の問題点」を明らかにすることなどの側面から業務モデルを作成する。ここで作成した業務モデルは、中規模開発ではそのまま利用でき、大規模開発ではこれをベースに目的に応じて拡張することで有効に使える。 SimpleModelingは、ユースケースを重視する。その理由は、要求モデル、ドメインモデル（静的モデル）、アプリケーションモデル（動的モデル）を接続する要のモデル要素だからだ。業務ユースケースでのポイントは、「顧客が喜ぶ物語」を考えるスタンスで要求仕様を抽出すること。例えば、モデルの最重要項目の名前であれば、「商品販売」のような“機能”ではなく、「（クライアントは）安くて実用性の高い美術品を購入する」といったクライアントの“目標”を示す物語風にするといい、と説く。 本書は、オブジェクト指向プログラミングはできるが、オブジェクトモデリングはこれからという読者を想定している。本書で作成する成果物を参考に、オブジェクトモデリングの有効活用に結び付けたいところだ。（ライター・生井俊）

発注者ビューガイドラインに学ぶ失敗しない外部設計――ユーザー目線の設計ノウハウを伝授
●実践的アプローチに基づく要求仕様の発注者ビュー検討会＝著 ●日経BP社　2008年8月 ●1800円＋税　978-4-8222-6226-6
	受発注者間でのコミュニケーションの円滑化や、情報システムの仕様に対する誤解や認識のズレを予防する方法が確立しているとは言い難いIT業界。日本の大手ITベンダ9社は、この共通課題の解決を目指して「実践的アプローチに基づく要求仕様の発注者ビュー検討会」を立ち上げ、各社のノウハウを持ち寄って作ったのが「発注者ビューガイドライン」だ。本書は、このガイドラインを分かりやすく解説する。 ITエンジニアが書く設計書は技術用語ばかりで、レビューも内容を理解できないまま促される、といった状況がまま見られる。むろん好ましくはないが、発注者サイドも納期に追われてしぶしぶ合意しているケースがある。このとき開発者側に足りないのは、作ろうとしているもの（情報システム）を発注者の視点で表現するノウハウだ。これを支援するための作られたアンチョコが「発注者ビューガイドライン」だ。設計書の書き方やレビューの進め方に関するコツ（工夫）が全部で187個、掲載されている。 コツの適用例として、システム化業務フロー図に記述する業務の種類をパッと見で分かるようにするために「システム化する部分はシステム化業務を表す図記号を用いて記述する」というのがある。言葉は難しいが、要はアイコン（図記号）を分類し、統一するもの。たったこれだけでも、発注者の理解度が高まる、と説く。 中盤から後半では、「画面」での「分かりやすさに惑わされずに合意するテクニック」や、「論理データモデル」での「“分かりにくさ”を克服して合意に至るテクニック」をまとめている。いまの作業に「利用者視点が欠けているのでは？」と感じるときのチェックリストとしても使える。（ライター・生井俊）

システム開発を見える化するマインドマップ――6つのケーススタディから学ぶ応用例
●シンプル・ビジョン＝監修／渡邉安夫＝著 ●オーム社　2008年4月 ●1900円＋税　978-4-274-06719-8
	システムエンジニアにとって、顧客のあいまいな要求を理解するプロセスとそれを視覚化する技術は重要なスキルである。本書では、人々を目的地に導く地図のような、概念の見える化ツールである「マインドマップ」に着目、ケーススタディを用いながらその応用例を紹介する。 マインドマップは本来、手描きを基本としているが、PCでマインドマップが描けるツールが多数存在する。それを活用するメリットは、知的生産性と創造性のバランスが実現できること、編集・更新が素早く行えること、手描きと違いチームで情報共有ができること、情報活用スキルが高まることが挙げられる。 この見える化アプローチの最も大きな利点は、顧客に対して分かっていることと分からない部分を明確に示すことができること。分からないことを知れば、質問が生まれる。この分からないことを早期に知ること＝質問力はSEにとって重要なスキルだ。不明な点や掘り下げたい箇所が明確に示せることで、システム化の対象範囲や位置付けなどがより鮮明に見えてくる、と説く。 最後の章では、マッピングツールとして「MindManager」を紹介。基本テクニックから応用テクニックまで、システム開発の見える化に役立つヒントを盛り込んでいる。（ライター・生井俊）

「要求定義」の現場――成功する要求分析と文書化のメカニズム
●佐川博樹＝著 ●ソフトバン ククリエイティブ　2008年4月 ●2280円＋税　978-4-7973-4681-7
	ITの世界は、技術が発達したことで以前できなかったことができるようになった反面、技術者たちの技術革新への追随努力だけでは、システムトラブルをすべてつぶすことができなくなっている。本書では、システム構築する中で乗り越える壁や溝を低く、浅くしていくための要求定義の進め方を解説する。 建築では、注文住宅を発注する人はきちんと設計作業（システム開発でいう要求定義）にお金を払う。その設計図（要求定義）に沿って見積もりが行われ、合意を得て設計図どおりに建設（開発）される。これをメタファーと考えれば、要求定義工程も一級建築士同様、建築作業と切り離して考えるべきだ。「共通フレーム2007（SLCP-JCF2007）」で、システム企画や要求定義に関する支援業務を「準委任型」として紹介しているのは、注目に値する。 ヒアリングでは、顧客は受身になりがちだ。積極的に情報を開示したり、潜在的な要求に気付いてどんどん語ることは少ない。その潜在的な要求が後で問題になるため、顧客側の参画意識を高めるワークショップやブレーンストーミングを利用する。要求が出た後は、「機能要求と非機能要求の分類」「機能要求を単位業務や工程ごとに分類」「単位業務内で機能要求に近いものを収集」「非機能要求はソフトウェアの品質要件ごとにグルーピング」という方法で整理していくとよい、と説く。 後半では、要求定義作成のステップを必要に応じて修正する「テーラリング」の必要性とポイントをまとめる。ほかにも、ユーザーが満足し、喜びにつながるシステム開発を目指す人向けのノウハウが満載だ。（ライター・生井俊）

はじめての上流工程をやり抜くための本――システム化企画から要件定義、基本設計まで
●三輪 一郎＝著 ●翔泳社　2008年3月 ●2280円＋税　978-4-7981-1437-8
	「上流工程とは？」という問いに、どのような答えをお持ちだろうか。われわれが認識すべき「システム」とはコンピュータ・システムだけでなく、「情報」も画面や帳票だけでない。目の前の案件に取り組む際にこうした考え方を持てるか、をテーマに、上流工程の理解を深め、上流工程をリードするためのノウハウをまとめたのが本書だ。 見積もりの段階で「予算はいくら？」と聞くのは愚問だ、という。コストの見積もりだけでは、上流工程で行うべき見積もりの一側面しか見えないからだ。上流工程のフェイズ1「システム化企画」の目的はフィージビリティスタディであり、そこで行われるのは「コスト・効果分析」となる。特に、効果の面では「コスト削減」と「新たな価値の創出」の2つの面から見積ることが不可欠といえる。 現場の要求を聞くインタビューでは、知恵を借りる準備が必要だ。SEに求められているのは教えられたことを学ぶことではなく、その先を提案すること。そのために、早く・深く学ぶ方法として「間違うのは当たり前だと割り切って事前に考え抜く」ことだとする。また、御用聞き型のSEは“初心者向けのバッティングセンター”のようなもので、プロとしては“ダメもと”でもお勧め案を示し、3割打者を目指せと、説く。 難しく語られがちの上流工程。それを具体的な事例と分かりやすい言葉で表現しており、初心者のSEでも十分読みこなせる内容になっている。（ライター・生井俊）

SEのための図解の技術、文章の技術――ユーザ、顧客に理解される秘訣、誤解されない極意
●谷口 功=著 ●技術評論社　2007年12月 ●1980円＋税　978-4-7741-3286-0
	SEが作成するユーザー・顧客向けの文書は、システム開発や運用において非常に重要な役割を果たす。その文書を軽視すると、手痛いしっぺ返しを受けることはご存じの通りだ。本書では、SEがユーザーや顧客に提示する文書を、読みやすく分かりやすいものにする指針を示す。 読み手は、文脈に沿って順番に文や図解を読んで、書かれたものを理解していく。1つ1つの記述の理解を積み重ねて、結果としてまとまった全体を理解する。そこで、読みやすく分かりやすい内容にし、記述を進めやすくするためには、文書の構成と展開を考えてから、実際の記述を始める必要がある。読みやすい文章は、典型的には「章−節−項」「大見出し−中見出し−小見出し」のように、階層構造に構成された文書だ。このように全体を分割することで、文脈や要点が明確になる利点がある。 正確に意味を伝える文の表現技術として、まず、可能な限り文を短くすることが求められる。文を短くすると、書き手は1つの事柄のみを的確に表現する必要があるが、読み手は1つの明確な意味に解釈できる。また、読み手は主語と述語の関係を理解できて、はじめて文の意味を了解できる。そのため、述語はできるだけ主語の近くに置くと理解しやすくなる、と説く。 本書の後半では、図解表現技術を扱い、図解表現と文章表現の補完関係を説明する。文書作成に苦手意識を持っていたり、誤解が少なく分かりやすい表現方法を模索している技術者に、ぜひ文章トレーニングやその技術の再確認に利用してほしい。（ライター・生井俊）

SEならこれだけは知っておきたい 業務分析・設計手法――ビジネスプロセスエンジニアリングと問題解決法
●大川 敏彦=著 ●ソフト・リサーチ・センター　2007年12月 ●2700円＋税　978-4-88373-250-0
	企業にとって経営・業務・ITのギャップは永遠の課題だ。本書では、「経営と業務とITをつなぐ方法論」として、業務分析・設計を体系的、かつ実践的に整理することを試みている。 　ビジネスプロセスモデリングのように、複雑な現象や情報を整理していく手法としては、フレームワークに基づきトップダウンで整理していく方法と、ボトムアップで1つ1つの情報を収集・分類していく方法がある。これらの2つの方法に加えて、業務の概形をドラフティングし、それを少しずつ精密に記述していく「芸術的なアプローチ」が必要だ。この考え方は、散発的で、全体感や論理的な整合性が欠けていると見られるが、業務、ビジネスあるいはビジネスプロセスが、人間とシステムという曖昧性と厳密性の2面性を持っていることなどの理由から有用だと説明する。 　後半では、業務分析・設計のアプローチ手法の1つである問題解決法の概要をまとめる。問題を解決へ導く手法として、科学的思考法や発想法、意志決定法などに触れ、問題の定義からあるべき姿の確定、現状の姿の調査、問題点の決定など一連の流れを把握することができるつくりになっている。 　業務分析の全体像から問題把握・解決、業務分析・設計の実践まで、数多くの要素とキーワードが登場する。情シスの新人や、多角的な視点を探しているPMが基礎をさらうのには便利かもしれない。（ライター・生井俊）

ソフトウエアの要求「発明」学――誰も書かなかった要求仕様の勘違い
●スザンヌ・ロバートソン、ジェームズ・ロバートソン=著／河野 正幸=訳 ●日経BP社　2007年8月 ●2400円＋税　978-4-8222-8321-6
	成功したプロジェクトには備わっていて、失敗したプロジェクトに欠けているもの──それは、要求への十分な配慮だ。ところが、大半のプロジェクトマネージャは、マネジメントツールとしての要求を最大限に活用しているとはいえない。本書では、要求アクティビティが持つ潜在的な可能性について解説する。 　要求に投資するとは、正しい要求を発見するために時間、労力、スキルを投資することを意味する。プロジェクトのステークホルダーが力を合わせて作業すれば、既存のルーチンワークの自動化などといったありふれた要求をはるかに超越した「キラー要求」を生み出せる。キラー要求は結果的に素晴らしいビジネス資産となり、投資に対する莫大な見返りを生み出す。 　プロジェクトの初期段階で要求に注力することは、もっとも有用な要求アクティビティの1つだ。プロジェクトの初期に十分な情報収集ができない問題を解決したい場合、最初にできるだけしっかりとプロジェクトの重要成果物（スコープ、ステークホルダー、ゴール）を確定するしか手はない。というのは、要求調査の「スコープ」はどのステークホルダーが参加すべきかを決定し、「ステークホルダー」はプロジェクトのゴールを決定し、「ゴール」はスコープに影響を及ぼすように、これら3つのターゲットが常に互いに追いかけあっているからだ、という。 　ほかに、ソフトウェアの機能性を測定するために開発されたファンクションポイント算出法を、要求アクティビティの見積もりに応用する方法などを扱う。本書には、プロジェクトを成功に導くためのノウハウが数多くあり、あらゆるシーンで役立つことだろう。（ライター・生井俊）

要求開発ワークショップの進め方――ユーザー要求を引き出すファシリテーション
●エレン・ゴッテスディーナー=著／三島邦彦、前田卓雄、宗雅彦=監訳／成田光彰=訳 ●日経BP社　2007年7月 ●3200円＋税　978-4-8222-8323-0
	ソフトウェア・プロジェクトを成功させるためには、要求が明確であることと、開発チームが協調的なことが必要だ。本書では、ユーザー要求を効率よく定義することと、積極的かつ生産的な協力関係を築くためのワークショップを計画し、実施する方法についてまとめる。 　ワークショップとミーティングの主な相違点は、ワークショップはあらかじめ具体的に定義された成果物が想定されていることだ。その中には、要求モデルのように、目に見える成果物がある。また、相互学習および理解、意志決定、モチベーション、チームワークの向上といった、目に見えない成果物も含まれる。1日のワークショップのファシリテーターを務めるには、少なくとも1日の計画時間を必要とする。それはかなりの量の投資ではあるが、得られる利益も大きい。 　ワークショップの基本ルールは、誰の目にも見える（室内に掲示されている）ものでなければならない。基本ルールを設定する際は、グループ・メンバーの意見を聞き、メンバー全員の同意を得なければならない。また、基本ルールに融通性を持たせる必要もある。生産性を向上させ、参加を促進し、個人の貢献や経験を尊重すべく協調し合う基盤として「すべての参加者からの情報を等しく評価する」「参加者は関連するすべての情報を共有する」など、基本ルールのリストを利用すると効果的だと説く。 　要求ワークショップの概要からフレームワーク、戦略設計まで、実践に基づいた詳細な解説があり、ワークショップだけでなく、プロジェクトのさまざまなシーンで利活用できそうだ。（ライター・生井俊）

戦略マップによるビジネスモデリング――ビジネスとシステムをシームレスにつなぐモデリング手法
●内田 功志、羽生田 栄一=著 ●翔泳社　2007年6月 ●2500円＋税　978-4-7981-1313-5
関連記事	ビジネス環境の変化にビジョンや戦略だけが対応しても、ビジネスはうまく回らない。ビジョンや戦略の変化に追随できないITシステムは、情報活用どころか、むしろ足かせになってしまう。本書では、バランス・スコアカード（BSC）とラショナル統一プロセス（RUP）を使い、状況の変化にマッチする有効なシステムの導き方を紹介する。 　通常は単純にトップダウンで行うように考えられている企業における「ビジョンの策定」だが、夢とビジョンとを履き違えて、「絵に描いた餅」になりかねないものが多い。夢には根拠がないが、ビジョンとは達成することを前提としたもので、当然根拠がある。それだけにビジョンは、トップだけでななく社員1人1人がそれぞれの立場で会社の内部・外部を分析し、それを基に策定していくことが必要となる。 　基本的なビジネスユースケース図を基に、その詳細を検討するためには、各ビジネスユースケースに対して、ビジネスのワークフローをビジネスユースケース定義書という形で作成する。内容を詳しく見ていくことで、いままで見えていなかった共通のビジネスユースケースを見つけたり、大きなビジネスユースケースを分割したりすることができる。この構造化を行うことで、ビジネスユースケース図が洗練されていく、と説明する。 　そのほか、筆者が提唱する「（4＋1）×1ビュー」──「概念」「コンテキスト」「プロセス」「ソリューション」および「ゴール」「ビジネスシナリオ」の視点で、ビジネスモデルを整理するフレームワーク──を使ったモデルの妥当性をトレース・検証する方法などを織り込んでいる。（ライター・生井俊）

ドキュメント・レビュー！！ 要求仕様書・設計書のレビュー実践とチェックポイント
●青島 弘幸=著 ●ソフト・リサーチ・センター　2007年6月 ●2600円＋税　978-4-88373-244-9
関連記事	システム構築プロジェクトでは「ドキュメントをレビューしている時間があったら、1行でもコードを書いて先に進みたい」となりがちだが、それこそがデスマーチへの第一歩だ。本書は「時々ちょっと立ち止まって地図を見直す」きっかけになるドキュメント・レビューについて詳述する。 　システムの出来具合と進ちょく状況を、適宜報告を受けるのはリスク管理の面から当然である。重要なポイントでは、自らの目で確かめることが必要だ。システム構築における検査に当たるのがレビューであり、レビューなしで行うのは羅針盤なしで荒波に乗り出すようなものだ。レビューをマイルストーンごとに実施することで、品質と進ちょく状況の両方をチェックすることができる。また、PMBOKではいわゆるQCDのほかに、さまざまな状態をマネジメントするようになっているが、ドキュメント・レビューはその点でも有効だ。 　システム構築プロジェクトにおける主なリスクは、認知的リスク、人的リスク、技術的リスク、組織的リスクの4つがある。常にリスクに対してアンテナを高くして、品質・コスト・納期に与える影響度や発生確率によってリスク強度を計算し、優先順位をつけ早めに対策を打つ必要がある。アンテナを敏感にするためには、ドキュメント・レビューを適宜実施し、3現（現場・現物・現実）主義を尊重することだ、と説く。 　第4章に要求仕様書のレビュー、見積書のレビューでそれぞれ16ずつ、設計書のレビューで8つの計40のチェックリストを挙げており、実務面で大いに役立ちそうだ。（ライター・生井俊）

プロセス改善ナビゲーションガイド──なぜなに編
●情報処理推進機構 ソフトウェア・エンジニアリング・センター=編 ●オーム社　2007年3月 ●1429円＋税　978-4-274-50131-9
	3編でシリーズを構成予定の『プロセス改善ナビゲーションガイド』。そのなぜなに編では、プロセス改善とは何を目指すのか、どのようなアプローチがあるのか、プロセス改善の基本的な概念を整理する。 　ソフトウェアプロセスの現状と問題点として、ソフトウェアにも工業製品と同等（以上）の品質が求められているが実現できていない点、プロセス改善をエンジニアリングや組織の問題として扱っていない点などがある。ソフトウェアコミュニティから見ると、要求する側が要求仕様を明確にできない点、ソフトウェアが原因でない変更もソフトウェア部隊が対応している点なども課題である。これらは、仕組み（プロセス）に従って作業を実施することで、ソフトウェア開発における結果のバラツキが小さくすることが可能だ。 　プロセス改善を進めるうえで重要なのは「改善サイクル」を回すこと。本書では、PDCAではなく、Check→Act/Action→Plan→Doとフェイズを回す「CAPDo」をその一例として挙げる。プロセス改善は、上からも（トップダウン）下からも（ボトムアップ）、自分の問題として提案し、そのバラエティを尊重することが重要だ。その改善を実際に行うのは、プロセスの担い手である現場のメンバーと、プロセスオーナーであり、これらの担い手が本気に取り組まなければ意味がない、と説く。 　プロセス管理の手法やツール、事業目標とプロセスのニーズなど、企業の競争力確保に役立ちそうなテーマも扱う。プロセス改善の初歩からサプライチェーンを含めた総論まで、大局的につかみたい方向け。（ライター・生井俊）

TSPガイドブック：リーダー編
●ワッツ・S・ハンフリー=著／秋山 義博=監訳／JASPIC TSP研究会=訳 ●翔泳社 2007年1月 ●3600円＋税　978-4-7981-1290-9
	チームソフトウェアプロセス（TSP）は、その名が示すとおり、ソフトウェア開発チームをガイドする手法だ。この概念とガイダンスの多くは、あらゆる種類の開発チームに適応できる。本書では、チームとリーダーシップの側面において、TSPがどう役立つのかを紹介する。 　自立的なチームを構築し、リードし、動機づけるのに役立つTSPは、チーム編成、チームの立ち上げ、進行中のチームの運営と、大きく3つの部分から成り立っている。そのTSP立ち上げプロセスには、「1.製品ゴールとビジネスゴールの確立」から「9.マネジメントレビュー開催」まで、9つのミーティングがある。ミーティング1と9では、チームとマネジメントがミーティングをするが、その他のミーティングは、チームがコーチと一緒に作業をし、外部からのオブザーバーは入れないことがポイントとなる。 　計画が不正確になったり、変化する問題に対処するために、TSPチームは、「動的計画法」を利用する。このときチームメンバーは、これまで割り当てられた仕事から学んだことを反映して計画を調整する。そうすることで、チームは変化を計画に確実に反映できるようになり、チームの作業をきちんとガイドするようになる、という。 　平易な文章で書かれ、示唆に富んだ豊富な事例により、チームやリーダーシップの在り方についての理解を深めることができる。プロジェクトマネージャには欠かせない1冊だろう。（ライター・生井俊）

実践！！ ファンクションポイント法の導入と効果的活用
●荒木 貞雄、後藤 卓史=著 ●ソフト・リサーチ・センター 2006年11月 ●2300円＋税　4-88373-234-7
	ソフトウェアの持つ機能に注目して、その量を測るファンクションポイント（FP）法。FP法による定量化は、ほかの工学における定量分析とは異なる特徴と困難さを伴う。このような状況を踏まえ、本書では計測マニュアルだけでなく、その運用に関しても解説する。 　ソフトウェア開発企業にとって、開発プロジェクトの成功がFP法導入の目的になる。そのためには目的を明らかにし、関係者の理解を得ていく綿密な準備が必要だ。導入のためには尺度法の選択だけでなく、ユーザー会であるJFPUGの利用を勧める。また、FP法の導入に際し「試行」されることが多いが、FP法は開発技法ではなく、「ものさし」であるため、その必要性は低い。もし、導入の判断が必要であれば、「業界で広く使われているか」「客観的で基準がしっかりしているか」「測定値から指標は客観性と信頼性があるか」などの視点から判断すべきと説く（第2章）。 　計測したFP値を基に、見積もるプロセスを組織やプロジェクトで構築していれば、プロジェクトの初期に工数や工期の確実な見積もりが可能だ。見積りには、初期、計画、機能仕様書確定、仕様の変更・追加時、納入時というように段階があり、それぞれのタイミングで適用する手法が異なる。発注者側もFP規模計測能力を身に付け、フィードバックするような、発注者と開発者のお互いの努力があってこそ、競争に打ち勝つソフトウェア開発が可能になる（第4章）。 　第6章で、FP計測演習があり、本編で概要を理解するだけでなく、実践への道筋をつけるために参考になるだろう。（ライター・生井俊）

成功する要求仕様 失敗する要求仕様
●アラン・M・デービス=著／萩本 順三、安井 昌男=監修／高嶋 優子=訳 ●日経BP社　2006年11月 ●2200円＋税　4-8222-8291-0
	優れた要求仕様を書くのは難しい。要求文書が持つあいまいさの問題は、形式的手法を多く導入することで対処できる一方で、拒否反応を示す人も多い。そこで、時間的な制約がある中で、いかに要求を発見し、吟味し、「顧客の言葉」で文書化していくかをまとめている。 　要求とは、求めるシステムの見た目に分かる特徴のことだ。要求が実現されているか、システムの外側から見て分かることと、そのシステムを使う顧客やステークホルダーの何らかのニーズを満たすのに役立っていることの2つの側面を満たさないといけない。その要求が妥当なものか判断できるは顧客やユーザーだけであり、要求の詳細さが適当かどうかは、ニーズと照らし合わせてはじめて決まるものだ。 　「ちょうど十分」な要求を導き出しを行うコツとして、目標を見失わないだけでなく、自分の方が顧客よりも問題をよく理解していると思わないこと、1人のステークホルダーがすべてのステークホルダーを代表した意見をいえるとは限らないこと、ステークホルダーには考えを変える権利があるという事実を受け入れることなどを挙げている。 　ほかに要求マネジメントで重要な要求のトリアージ、仕様化についても多くのページを割いて解説する。難しい内容ながら、ポイントが明快で、ユニークなたとえ話も見どころになっている。（ライター・生井俊）

戦略的「要求開発」のススメ
●安井 昌男=著 ●翔泳社　2006年3月 ●2200円＋税　4-7981-1048-5
	システムを開発する場合には、「どう作るか」と「何を作るか」の2つのことを考えなくてはならない。本書は、この「何を作るか」を明らかにするための要求開発方法論「Openthology」の準備フェイズを中心にまとめている。 　ビジネスITシステムは、単独では価値を持たず、「手段の連鎖」によりビジネスユニットの目標および全社の目標を達成するために稼動して、はじめて意味を持つ。実行された結果は検証され改善されることで、さらによい結果を導く。このように、経営計画から個々のビジネスユニットの「個別システム（ITシステムも含む）」に至るまで、全社規模のスケールで「決めること・実行すること・検証すること・改善すること」というマネジメントシステムが構築されなければならない。そして、「最適」であるためには、全社の役に立つことが必要である（第2章）。 　Openthologyのプロセスの考え方は、横軸に「準備」「立案」「デザイン」「シフト」というフェイズを、縦軸にPDCAというディシプリンズを収めた2次元マトリックスになっている。そしてOpenthologyは、その具体的な内容としてモデリングの方法論や成果物サンプルなど、各種のコンテンツを有している。それを簡単に参照できるように「プロセスキャビネット」という知識ベースの形で整理している。実際に要件開発プロジェクトを行う際には、プロジェクトの進ちょくに合わせて、プロセスキャビネットから各種コンテンツを引き出して利用する（第3章）。 　後半は、戦略マップなどを例示し、PDCAの個々について多くのページを割く。本書が扱う準備フェイズは、役立つシステムを開発するための最も根幹になる部分だけに、経営層からSEまで、ユーザー、ベンダを問わず生かしてほしい。（ライター・生井俊）

システム開発見積りのための 実践 ファンクションポイント法 改訂版
●児玉 公信=著 ●日本能率協会マネジメントセンター　2006年2月 ●3500円＋税　4-8207-4334-1
	FP法とは、「システムの機能規模」を「ファンクションポイント」という尺度で計測するための手法だ。FP法を使用する目的は、工数見積りによって情報システムの開発原価を予測するだけでなく、プロジェクトにかかわる資源の配分、スケジューリングや進ちょくの把握などの原単位となり、意志決定のための基礎データの器となる。 　まず、入門編の第1部でファンクションポイント法の概要とその計測方法に触れる。それを受けて実践編の第2部では、実際の開発プロジェクトの結果からFP値を逆算し、ここから予測される工数が、実績の工数とどの程度一致するかを検討している。その結果をふまえ、FP法とファンクションタイプ別ファイル数モデルは、ともにうまく当てはまると述べる（第3章）。 　FP法で最も重要なのが「ユーザーの視点」や「要素処理」だ。これらについて、主観的な基準や判例の蓄積によるのではなく、できるだけソフトウェア工学的な根拠を明確に与えるため、DFDとER図を書くための基礎知識を紹介する（第5章）。その準備が終わったところで、見積もりモデリングとFP法の対応関係を述べる（第6章）。 　唐突に専門用語が出てくるところもあるが、基本的に平易な文章で、多くの図表を挿入するなど、この分野の初心者でも分かりやすい構成。また、いくつかの章に演習問題があり、内容の理解を深めることができる点も良い。（ライター・生井俊）

図解 よくわかる要求エンジニアリング
●木ノ下 勝郎、野代谷 亨、櫟 恵子、前田 卓雄=著 ●日刊工業新聞社　2006年1月 ●2400円＋税　4-526-05584-0
	本書は、「納得できないままITを使い続けて困っている」ようなユーザー企業が、主体的にIT調達を実施し、業務改革にITを徹底活用し、業績向上に結び付けることを最終目的にしたもので、特にユーザー企業がRFP（提案依頼書）を作成することを中心にまとめている。 　序章で、ユーザー主導のIT調達プロセスのアウトラインを紹介する。ここでは、新業務要件をまとめ、ITベンダを呼んでRFPの説明会を実施するところから始まり、ベンダの決定、出来映えの計測、新システム本来の効果の確認など、一連の流れを管理者と実務者の会話で構成し、またプロセスごとの概要を図示している。 　第2章でRFPの作成、第3章でその適切な伝達方法を扱う。本書のRFPは、一般的に使われる要件定義書とシステム仕様書を「業務要件」「システム要件」「プロジェクト要件」の3つに分けたのが特徴で、業務要件の中の「大きな業務要件」を、ITに熟知していないユーザーでも書けるよう「職務環境図」「職務分掌」「業務フロー」の3点に限定する。また、社内でのレビューを済ませ、ベンダ各社へRFPを提示するときには説明会だけでなく、質問についてもメーリングリストを立ち上げるなどし、ベンダ各社へ情報を「公平に」伝えることが必要だと説く。 　要求の実現検証まで含め、ユーザー企業の情シス部門が行うべきことを簡潔に記しており、大規模なシステム構築、リプレースなどを行う前にご一読をオススメしたい。（ライター・生井俊）

初めて学ぶソフトウエアメトリクス──プロジェクト見積もりのためのデータの導き方
●ローレンス・H・パトナム、ウエア・マイヤーズ=著／山浦 恒央=訳 ●日経BP社　2005年10月 ●2800円＋税　4-8222-8242-2
	本書では、効率よくプロジェクトを制御する上で必要となる「開発時間」「工数」「機能量」「信頼性」「生産性」という、5つの中核「メトリクス」（測定基準）を取り上げる。この5つは相互に関係するため、いくつかが分かれば、残りが推定できる。これが見積もりの基本になり、予測値と比較することで、現行プロジェクトがコントロール可能となる。 　4部構成の第I部では、開発プロセスの中でキーとなるメトリクスをうまく融合させ、予測精度を高めているソフトウェア開発事例を検証する。それを受け第II部では、5つの中核メトリクスを定義し、数学的に扱えるようにしている。 　第III部、第VI部ではより具体的に、問題プロジェクトの再計画や人員配置管理、ソフトウェア開発プロセスの改善など、開発フェイズやプロジェクトマネジメントでのメトリクス利用方法を紹介する。 　イントロダクションで、ソフトウェア開発の歴史を振り返り、メトリクスがどう進化してきたかをまとめているほか、メトリクス作りに役立つデータが多く、示唆に富んでいる。分かりやすい内容で、プロジェクトマネージャだけでなく、経営者やビジネスマンにも役立つ1冊だ。（ライター・生井俊）

［入門＋実践］要求を仕様化する技術・表現する技術〜仕様が書けていますか？
●清水 吉男=著 ●技術評論社　2005年11月 ●2580円＋税　4-7741-2523-7
	ソフトウェア開発のトラブルの多くは、要求仕様に起因しているのだが、設計プロセスの問題と認識している人が意外と多い。その要求仕様の問題点をふまえながら、「要求」を書き「仕様化」するまでの手法を中心に紹介する。 　3部構成の第1部は、どこで、なぜ問題が起きているのかをひも解く。要求仕様書はいまや必要性や有効性を失った状態だ。それに対してほかの手法で代用するのではなく、要求仕様書の構成や書き方を変えて有効性を高めることを本書では勧める。例えば、ワープロソフトで要求仕様書を書くと、散文になり、仕様モレが起きやすい傾向にある。また「要求」が表現されていないことがある。「説明」なのか「仕様」なのかはっきりしないと、仕様書としての役を果たさない。そんな状況でも、「要求の仕様化」と「プロセスの明確化」だけでもあるレベルまで行えば、混乱は一気に解消する、という。 　第2部では、Microsoft Excelを使った要求仕様の書き方を説明する。Excelを使った仕様書は、「機能要求と品質要求とでシートを分ける」「機能が多いときにシートを分割する」「仕様の変更履歴などを記録したシートを設ける」といった面でも便利。また、要求仕様をそのまま「トレーサビリティ・マトリクス(TM)」と一体化することで「要求TM」として効率よく運用できるほか、要求書と要求仕様書を一体化することができる、とメリットを強調する。 　要求仕様書で泣かされることの多いマネージャ、情シス担当者、開発者はご一読を。（ライター・生井俊）

RFP＆提案書 完全マニュアル
●永井昭弘=著 ●日経BP社　2005年7月 ●2100円＋税　4-8222-2973-4
	「RFP（Request for Proposal＝提案依頼書）は大切だ」といわれるが、書き方が分からないユーザーが多い。一方、提案書を書くために役立つはずなのに、ユーザーから突然RFPを受け取ると混乱してしまうベンダもある。RFPと提案書のやりとりにより、ユーザーとベンダとがスムーズにコミュニケーションを取るためのテクニックをまとめているのが本書だ。 　RFPに必要なのは、「何を」「いくらで」「いつまでに」という3つの要求を明示すること。業務要求はシステムの趣旨を明確にする具体性より網羅性が、予算は先に提示することが大切と説く。予算を先に提示するメリットは、複数社の見積もりを取ったときに金額が違い過ぎて単純に比較できないということを避けるため。 　RFPを受け取ったベンダが提案書を書くときは、「漏れなく」「重なりなく」「少なく」「分かりやすく」の4点がポイントになる。分厚いだけの提案書を受け取っても、ユーザーは内容がよく分からないので、提示価格が一番安いベンダを選定してしまうことがある。4点を意識することで、ユーザーは質の悪いベンダにだまされずに済み、ベンダも最適なシステムを適切な価格で受注できるWin-Winの関係構築が可能になるという。 　システム発注を担当する人向けの分かりやすい解説書になっている。（ライター・生井俊）

図解入門 ソフトの契約と見積りの基本がよ〜くわかる本──実践・ソフト取引契約文書作成の手引き
●谷口 功=著 ●秀和システム　2004年11月 ●1600円＋税　4-7980-0916-4
	企業システムで使われるビジネス・ソフトウェアは極めて実用的なプロダクトだが、著作権法で保護される対象である。本書では、ソフトウェア開発委託取引などの契約の条項を詳しく説明し、その作成例をまとめている。 　まず、著作権に関しては、著作財産権と著作人格権の2つがあること、プログラムとほかの文書類は別々の著作物として扱われること、などを注意点として挙げている。また、契約書に盛り込む内容としては、保証、責任、瑕疵（かし）を契約で規定しておくことが重要だという。こうした点を明確にしておかないと、問題が発生した場合に民法の規定に従って解決が図られる。民法ではバグなどの瑕疵があった場合、瑕疵担保責任、または債務不履行が問われることになる。また契約書では、基本的にコンピュータ、情報・通信などの専門用語を使うのはなるべく避け、誰にでも分かる言葉を使うことを勧めている。 　第4章以降は、ソフトウェア開発委託契約の基本契約書などを例示しながら解説し、最後の第8章で見積もりの技法について扱っている。見積もりの参考書としては食い足りないが、契約のために必要な知識や例文は、システム発注側／受注側双方に有用だろう。（ライター・生井俊）

要求定義のチェックポイント427
●本園明史=著 ●翔泳社　2004年10月 ●2400円＋税　4-7981-0698-4
	ソフトウェア開発モデルがウォーターフォールでもRUPでも、作業要素として「顧客から要求を獲得する」→「獲得した要求を分析する」→「分析に基づいて設計を行う」→「設計に基づいてプログラミングを行う」→「製造物を試験する」という基本的な流れは変わらない。本書では、要求定義をこの流れでいう「顧客から要求を獲得する」ことに限定し、詳説していく。 　タイトルにあるように、要求定義のヒアリングを行う際に欠かせない427のチェックポイントを、準備、基盤整備、要求獲得のフェイズに分類する。チェック項目が羅列されているわけではなく、要求定義担当者の心得（第1章）などの読み物も充実する。「こちらの知識、理解レベルを顧客に正しく理解してもらうことも重要」「本当にお金をかけてまでやる必要があるのか」といったノウハウが太字になっているので、見落とすことがない。 　キックオフミーティングでは、「あなたはどのような質問を想定していますか」と、相手が想定している質問の具体例を挙げてもらうことから始まる。そのひと言が、開発側の思い込みを修正するよいきっかけになるという。このような形でヒアリング項目が紹介されているほか、付録で「一歩踏み込んだフェイズ別チェックリスト」も掲載する。 　管理者、プロジェクトマネージャだけでなく、要求のヒアリングに関わるセールスSEの方にも読んでほしい好著だ。（ライター・生井俊）

図解入門 よくわかる最新上流工程の基本と仕組み
●谷口功=著 ●秀和システム　2004年6月 ●1500円＋税　ISBN4-7980-0820-6
	システム開発の中の“設計図”作成段階といえる上流工程。芸術作品ならぬ“製品”を作るうえで設計図を描く工程を疎かにしては、品質の高いモノを作り上げることはできない。その上流工程について、システム開発における位置付けから仕様のまとめ上げまでの、一連の流れを解説する。 　当然のことだが、上流工程では、開発側と顧客・ユーザー間のコミュニケーションが欠かせない。そこで大切なのは、要求定義書や外部設計書などの成果物を、顧客・ユーザーが簡単に理解できる表現にすること。顧客・ユーザーが内容を正確に把握できれば、その後の工程での齟齬（そご）が減少するという。そのための、現状把握と要求の明確化に多くのページを割く。また、付録では、ソフトウェア開発能力成熟度モデルCMMについても言及する。 　図や表をふんだんに盛り込んだ本書は、システム導入を考える企業のマネージャや情報システム担当者が、上流工程の理解を深めるために役立つだろう。（ライター・生井俊）

業務システムのための上流工程入門──要件定義から分析・設計まで SE&プログラマ必読！
●渡辺幸三=著 ●日本実業出版社　2003年10月 ●2400円＋税　ISBN4-534-03655-8
	システム開発のボトルネックは何か──本書では“上流工程”にあるという。その上流工程の3局面「要件定義」「基本設計」「現状分析」の中でも、「基本設計」に重点をおいて解説する。 　第1章、第2章は上流工程の位置付けとその概念についてまとめている。基本設計のためには、手書き図面が重要であること、しかしそこには文法が存在することなどを、ふんだんに図表やイラストを挿入し、分かりやすく紹介する。 　核になるのが第3章「基本設計入門」だ。基本設計は、「概略設計」「モデリングセッション」「とりまとめ」「レビュー」の4つ手順で進められるが、モデリングについて多くのページを割くだけでなく、第4章でも引き続き「モデリングパターンと用例」と題し、より具体的に手法を解説する。また、「モックアップ」を作ると、ユーザー・ニーズを的確にとらえることができ、開発時間の短縮にもつながると推奨している。 　上流工程に深く関わるプロジェクトマネージャやSE（あるいはシステム発注者）だけでなく、下流工程を支えるプログラマが仕事の流れや自分のポジションを掌握するためにも役立つ1冊だ。（ライター・生井俊）

要求定義工学入門
●Pericles Loucopoulos、Vassilios Karakostas=著、富野 寿=監訳 ●構造計画研究所　1997年10月 ●3300円＋税　ISBN4-320-09719-X
	システム工学の1領域で、システム構築の最上流工程である要求定義を工学的に扱う要求定義工学（要求工学）の教科書ともいえる本。 　要求定義はソフトウェア開発ライフサイクルの1フェイズとして、いろいろな開発方法論の中でそれぞれのやり方が紹介されることが多いが、本書は特定の手法を紹介するのではなく、各方法論やツールをふかん的に取り上げて、要求定義と呼ばれる工程のはらむ本質的な課題を浮き彫りにする。 　要求定義というのは難しい。ユーザーの要求を正確に導き出すのが困難なだけではなく、その要求が正当で、効果的であるかどうかも分からないからだ。それだけにさまざまなアプローチが提唱されてきたわけだ。 　本書はいう。「要求定義工学のような複雑な仕事のコンサルタントは、まず最良の概念や理念を理解することを心がけ、その後にツールや技術の数々に精通し、最後に実践としてこの分野で何を使い、何を使わないかについて自分自身の意見を形成するようにすべきであると思う」。ソフトウェア開発の上流工程にかかわる人にとっては、非常に示唆に富む良書である。

各書評にあるボタンをクリックすると、オンライン書店で、その書籍を注文することができます。詳しくはクリックして表示されるページをご覧ください。