| |
| |
| 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フェイズとして、いろいろな開発方法論の中でそれぞれのやり方が紹介されることが多いが、本書は特定の手法を紹介するのではなく、各方法論やツールをふかん的に取り上げて、要求定義と呼ばれる工程のはらむ本質的な課題を浮き彫りにする。
要求定義というのは難しい。ユーザーの要求を正確に導き出すのが困難なだけではなく、その要求が正当で、効果的であるかどうかも分からないからだ。それだけにさまざまなアプローチが提唱されてきたわけだ。
本書はいう。「要求定義工学のような複雑な仕事のコンサルタントは、まず最良の概念や理念を理解することを心がけ、その後にツールや技術の数々に精通し、最後に実践としてこの分野で何を使い、何を使わないかについて自分自身の意見を形成するようにすべきであると思う」。ソフトウェア開発の上流工程にかかわる人にとっては、非常に示唆に富む良書である。 |
| ■ブックガイド記事がメールで読めます■ |
ブックガイドの記事は毎週水曜日にメールでお届けしています。
下の「＠IT情報マネジメント メールマガジン」からお申し込みください。
|
|
|
|
|
プリンタ用ページ表示
kee<p>ointで保存
ERP導入効果が見えず、アップグレードもできずに失敗
