Book Guide

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

■ソフトウェア開発プロセス、方法論
 
アーキテクトの審美眼
●萩原 正義=著
●翔泳社 2009年3月
●2400円+税 978-4-7981-1915-1
これまで、ソフトウェアアーキテクチャやアーキテクトの重要性についてについてたびたび論じられてきたが、どうしたら見通しの良い優れたソフトウェアアーキテクチャが構築できるかといった点で解説されることは少なかった。そこで本書では、アーキテクチャスタイル、ソフトウェア開発パラダイム、設計手法などの基本ソフトウェアの機能や機構を考慮しながら、アーキテクトの姿勢や思考の方向性を解説する。
ソフトウェアシステムのアーキテクチャを「縦と横」(縦は構造要素、横はサービスあるいはアプリケーション個別機能)という観点から掘り下げていくと、変更頻度や共通性の基準に自由度があるため、この2つを分離する境界はあいまいだと分かる。もちろん、2つに分離する必然性もないため、3つ以上に分離しても構わないが、分離しすぎると構成要素の位置付けが複雑になる。2つに分離することは、UMLクラス図が「箱」と「線」という2種類の記号で表現されることからも妥当性を持つ、と説く。
構造変更への対応という点では、オブジェクト指向という技術がコードの冗長性を減らし、再利用性を高めることを目指したものとして存在する。しかし、オブジェクト指向は、要求の変更に対して「散乱」と「もつれ合い」という2つの複雑な対応を強いられる。その欠点を克服するものとして、「アスペクト指向」と「サブジェクト指向」の2つの技術を考えていく。これらはオブジェクト指向に置き換わる技術ではない。オブジェクト指向とは別の分割単位を導入することで、その欠点を補完するものだ、と指摘する。
筆者が目指すのは、ソフトウェアを工学的に扱い、残りを工芸で扱うこと。工芸は絶対の真理ではないにしても、思想や哲学を高額に吹き込むアーキテクトの目指す目標になるという。「ソフトウェア工芸」への審美眼よりも、変化に対応する抜け漏れのない設計手法を模索した内容になっている。(ライター・生井俊)
 
アジャイルな見積りと計画づくり――価値あるソフトウェアを育てる概念と技法
●マイク・コーン=著/安井 力、角谷 信太郎=訳
●毎日コミュニケーションズ 2009年1月
●3200円+税 978-4-8399-2402-7
アジャイル開発が、アーリーアダプターだけでなく、メインストリームにも受け入れられるようになったことで、アジャイル・プロジェクトにおける見積もりと計画づくりがより一層重要になってきている。本書では、アジャイル開発プロセスで、いかにして目標の不確実性と方法の不確実性の両方を軽減させるかを整理している。
アジャイル・プロジェクトの規模の見積もりには、ストーリーポイントとベロシティを用いる。ストーリーポイントは、ユーザーストーリーやフィーチャ、そのほかの作業の大きさを表わす単位だ。ストーリーポイントの数値は、ストーリー全体の規模を表わすもので、ほとんどのストーリーを1から10の範囲に収めるために、中くらいのストーリーには5ポイントを付ける。この単位を持たせずにプロジェクトを進めるときは「ベロシティ」を導入する。これは、チームの進む速度を表わすものだ。
プロジェクトでは何もかもをやれるだけの時間があることはほとんどないため、「金銭価値」「コスト」「開発を通じて学べる知識の量とその意義」「リスク」という4つの観点からフィーチャの優先順位付けをする。この4つの要素の中でも、第1に考えるのはフィーチャの価値と、そのフィーチャをいますぐに開発するのにかかるコストを比較すること。テーマごとに暫定的な優先度をつけ、その結果、コストに対して最も高い価値を持つテーマから着手すると良い、と説く。
このような価値のための計画づくりやスケジュールの立て方、トラッキングと情報共有のほか、なぜアジャイルな計画づくりがうまくいかないかにも言及する。本書は300ページを超えるが、身近な例を紹介しながら分かりやすく、利用しやすい体裁に仕上がりになっている。(ライター・生井俊)
 
ソフトウェアプロダクトラインエンジニアリング――ソフトウェア製品系列開発の基礎と概念から技法まで
●K・ポール、G・ベックレ、F・vd・リンデン=著/林 好一、吉村 健太郎、今関 剛=訳
●エスアイビー・アクセス 2009年1月
●5000円+税 978-4-434-12706-9
「ソフトウェア製品系列開発」(Software Product Line Engineering=SPLE)は、低予算、短期間で、高品質なソフトウェア製品およびソフトウェア集約システムの開発を実現する方法論だ。本書では、その方法論の基礎から導入事例までを6部構成、22の章で解説する。
第2部では、SPLEを特徴付ける「可変性」の文書化と管理を扱う。SPLEの可変性とは、モデル化されたものだ。その目的は、あらかじめ定義された調整可能な成果物を再利用し、個別化されたアプリケーションが開発できるようにすること。可変性情報を十分に文書化するためには、「誰のために文書化するのか」という視点が大切で、内部可変性か外部可変性かを区別することにより、可変点や変異体を誰が規定される。また、可変性を明示的に文書化することで、より良い意思決定・情報伝達・追跡ができる。
SPLEでは、さまざまな種類の要求成果物を、独立した可変性モデル1つに文書化することが求められる。可変性モデルにより、開発者が可変要求成果物のさまざまなビューの整合性を維持することが容易になる。同様に、アプリケーション要求開発においては、可変性モデルを用いることで、互いに整合しているアプリケーション要求成果物を作成できる、と説く。
本書で扱うのはSPLEの可変性管理と、ドメイン開発およびアプリケーション開発のプロセスに関する知識が中心だが、組織構造と移行戦略、将来の研究にも言及する。(ライター・生井俊)
 
はじめての設計をやり抜くための本――概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで
●吉原 庄三郎=著
●翔泳社 2008年12月
●2380円+税 978-4-7981-1706-5
システム設計がはじめての人や、見よう見まねでやってきたが基礎から学び直したい人。そんなエンジニア向けに、本書はユースケース、概念モデル、データベース設計、アーキテクチャ設計の4つを中心に、設計を「やり抜く」ためのノウハウをまとめる。
設計は、要件定義の内容をシステムでどのように実現するかの検討、明確になっていない外部仕様の検討、メンテナンスのために設計情報を残す、といった目的で行われる。要件定義したものを、どのようにシステムで実現するかを記述するだけでなく、開発するシステムの品質を定義したり、複数人のプロジェクトで開発する場合に情報を共有できることもその目的に含める。
開発プロジェクトでは、みんなが必要最低限の情報を必要最低限の相手にだけ見せようとする。また、誰かが全員にメールを書いても誰も返信しようとはしない。それで十分ではないかと思うかもしれないが、情報量も相手も少し多めにしておくのがコミュニケーション(情報共有)のコツだ。そういったコミュニケーションがシステムの品質を高め、作業効率を上げる、と説く。
本書は、ユースケースモデリングやデータベース設計などを紹介しながら、どこかに特化するのではなく、設計工程の最初から最後までをきちんと解説している点が優れている。難解なIT用語も丁寧に解説してあり、設計初心者でもすいすい読み進められる参考書だ。(ライター・生井俊)
 
SUBJECT TO CHANGE――予測不可能な世界で最高の製品とサービスを作る
●P・マーホールズ、B・シャウアー、T・ウィルケンズ、D・ヴァーバ=著/高橋 信夫=訳
●オライリー・ジャパン 2008年10月
●1800円+税 978-4-87311-385-2
未来を予測することが容易だったことはないが、いまほど難しい時代もない。見極めることがますます困難になる中で必要なのは、質の高い未来予測ではなく、急激な変化にも対応できる「道具箱」(アプローチ)だ。本書では、変化へ適応できる柔軟性を持つサービスや商品を作る道具箱を紹介する。
この世界は日を追うごとに不確実性が高まり、長い間とても役立っていた道具がもう使えない。テクノロジだけでは不十分で、機能追加だけでは客が呼べない時代で製品やサービスを送り出すためには、顧客とその能力、ニーズ、要求をうわべだけでなく真摯(しんし)に肝に銘じておくことだ。これができたとき、そして顧客に心から共感できたとき、顧客にとって「体験こそが、われわれが送り出すべき製品」だと気付く。
開発プロセスを通して体験への集中を促進、維持する方法がいくつかある。1つはスティーブ・ジョブズを連れてくること。だが、ジョブズは多忙なため、どんな仕事のオファーも受けそうにない。そこで、自力で組織として成功するための鍵になるのは「体験戦略」(Experience Strategy)を採用することにある。体験戦略とは、明確に示された基準で、技術・機能・インターフェイスのいずれの決断にも影響を与えるものだ。「航海を導く星」の役目を果たす体験戦略により、企業が外から内へ、つまりこれから届ける製品やサービスを使う人たちの視点に立ってデザインするように仕向けることができる、と説く。
体験戦略はさまざまな形態をとるが、中心になるのはやはり「ビジョン」。複雑さをとらえながら共感を生む手法や、デザイン論なども本質をついていて有益だろう。(ライター・生井俊)
 
リーン開発の本質――ソフトウエア開発に生かす7つの原則
●メアリー・ポッペンディーク、トム・ポッペンディーク=著/平鍋 健児=監訳/高嶋 優子、 天野 勝=翻訳
●日経BP社 2008年2月
●2400円+税 978-4-8222-8350-6
 ソフトウェア開発をいかに改善するか──。本書では、リーン生産で実証されているアイデアから理論や実践法を導き出し、ソフトウェア開発に応用した方法を紹介している。手法というよりも原理原則を述べたもので、「7つのリーンの原則」と「ソフトウェア開発での7つのムダ」としてまとめている。
リーンソフトウェア開発の原則とは、「1.ムダをなくす」「2.品質を作りこむ」「3.知識を作り出す」「4.決定を遅らせる」「5.速く提供する」「6.人を尊重する」「7.全体を最適化する」の7つ。本当に「品質」を手に入れたいのであれば、事後の検査をするのではなく、最初から欠陥が入り込まないようにする。また、「決定」に対しては時間枠を設定し、時間枠の終わりまで行動に移さずに待つ。つまり、待てるだけ待つことで、最も多くの情報を得ることができ、不確実性が減るからだ。
一方、ソフトウェア開発特有の問題として「1.未完成の作業」「2.余分な機能」「3.再学習」「4.引き継ぎ」「5.タスク切り替え」「6.遅れ」「7.欠陥」の7つのムダを挙げる。7つのムダのうち最悪なムダは、顧客がいまある仕事をするのに必要でない「余分な機能」を追加すること。人々が職場に持ち込んだ知識を、開発プロセスに組み込まずに放置するのは知識の浪費で、生み出した知識を見失うよりも、はるかに深刻な問題だ(「再学習」)、という。
各章の冒頭に、グーグルやボーイングなどが経営課題に対してどう取り組んだかを載せ、内容の理解を深める工夫をしている。リーンなマネジメントについて簡潔にまとまっているため、ソフトウェア開発関係者以外の経営層からプロジェクトマネージャ、エンドユーザーまで一読をオススメする。(ライター・生井俊)
 
「派生開発」を成功させるプロセス改善の技術と極意
●清水 吉男=著
●技術評論社 2007年10月
●2580円+税 978-4-7741-3249-5
 ソフトウェアのトラブルによる混乱が、毎日あちこちで起きている。そのトラブルのほとんどは、改修作業に起因するものだ。ソフトウェア開発の大部分は「派生開発」で、新規開発の機会が少ないにもかかわらず、方法論としては新規開発のものしか提供されていないのが現状だ。本書では重要度が増している派生開発に焦点を当て、派生開発に特化したプロセス「XDDP」を紹介する。
 XDDPの最大の特徴は、「変更要求仕様書」を導入していること。それは、「“変更してほしいこと”について、関係者間で特定できたことがまとめられた文書」で、変更方法をレビューを通じて特定していく。また、ソースコードは「仕様を具現化したもの」と考え、ベースのソースコードを変更することを「変更仕様」として書き出す。これにより、「該当箇所を見つけ次第にソースコードを変更する」ようなやり方から解放されるほか、派生開発特有の「部分理解の罠」にはまらないで済む。
 仕様変更の場面で大きな威力を発揮するのは「トレーサビリティ・マトリックス」(TM)だ。XDDPでは変更要求仕様と組み合わせて「変更要求TM」と呼んでいるが、このマトリックスにより、個々の変更仕様が実際にどのモジュールで変更されることになるか一目瞭然となる。担当者が認識した「Where」の情報が表現されるため、レビューなどにより重大な勘違いを発見できる、と説く。
 後半は、XDDPによる変更や機能追加のプロセス、XDDPを支えるものを扱う。ソースコード変更に携わる方からPL・PMまで、幅広く活用できる内容になっている。(ライター・生井俊)
 
CMMIモデルではじめるプロセス改善実践ガイド
●臼井 孝雄、橋本 隆成=著
●日刊工業新聞社 2007年9月
●2500円+税 978-4-526-05939-1
 プロセス改善活動は、組織の改善活動戦略や文化、開発する製品などを考慮し、各組織にフィットするように「テーラリング」していくことが大切だ。本書は、テーラリングを自らが実施できるよう、CMMIによるプロセス改善活動をまとめる。
 第3章では、ソフトウェア開発プロジェクトを例に、よくある失敗を取り上げる。例えば、担当者の作業計画が不明瞭で、進ちょくが定量的に測れていないケース。これは、CMMIモデルと比較すると「プロジェクトの計画策定」と「プロジェクトの監視と制御」の2つのプロセス領域と関連する。この問題を解消するためには、担当者のタスクを1週間単位に分け与え、0/1(できた、できない)で進ちょくを管理してはどうか、と指針を示す。
 第4章では、プロセス改善を段階的に進めるための体制作りから現状把握・実行・評価までを扱う。体制作りでは、プロセス改善の目標を明確にするだけでなく、事業目標を達成するためとはいえ「プロジェクトが楽になる」ことを優先するといい。そのためには、現有のリソースで、現在の納期で、プロジェクトをうまく回すために何をすべきかを考えるのがカギになる、と説く。
 第3章以降はボトムアップがテーマになっているが、第1章、第2章ではトップダウンでCMMIを活用した改善活動を取り上げる。また、事例と分析、それに対するTIPSのように構成された章もあり、プロセス改善について理解が深まるだけでなく、「逆引き」のような使い方ができ便利だ。(ライター・生井俊)
 
TSPガイドブック:リーダー編
●ワッツ・S・ハンフリー=著/秋山 義博=監訳/JASPIC TSP研究会=訳
●翔泳社 2007年1月
●3600円+税 978-4-7981-1290-9
 チームソフトウェアプロセス(TSP)は、その名が示すとおり、ソフトウェア開発チームをガイドする手法だ。この概念とガイダンスの多くは、あらゆる種類の開発チームに適応できる。本書では、チームとリーダーシップの側面において、TSPがどう役立つのかを紹介する。
 自立的なチームを構築し、リードし、動機づけるのに役立つTSPは、チーム編成、チームの立ち上げ、進行中のチームの運営と、大きく3つの部分から成り立っている。そのTSP立ち上げプロセスには、「1.製品ゴールとビジネスゴールの確立」から「9.マネジメントレビュー開催」まで、9つのミーティングがある。ミーティング1と9では、チームとマネジメントがミーティングをするが、その他のミーティングは、チームがコーチと一緒に作業をし、外部からのオブザーバーは入れないことがポイントとなる。
 計画が不正確になったり、変化する問題に対処するために、TSPチームは、「動的計画法」を利用する。このときチームメンバーは、これまで割り当てられた仕事から学んだことを反映して計画を調整する。そうすることで、チームは変化を計画に確実に反映できるようになり、チームの作業をきちんとガイドするようになる、という。
 平易な文章で書かれ、示唆に富んだ豊富な事例により、チームやリーダーシップの在り方についての理解を深めることができる。プロジェクトマネージャには欠かせない1冊だろう。(ライター・生井俊)
 
「幸せなシステム」のつくり方──真のWIN-WINを実現するシステム構築アプローチ
●渡部 広志、楠 徳生=著
●翔泳社 2006年12月
●1780円+税 4-7981-1130-9
 タイトルにある「幸せなシステム」とは、お客さま、システム開発者の双方が「幸せ」と感じるシステムのことだ。それはお客さまが「あたたかい気持ち」を持て、システム開発者が「作ってよかった」と思えるものだ、と本書では定義する。
 幸せなシステムを作るためには「そのシステムに関係するすべてが納得できるようなシステムを目指してシステム開発を進める」という強い意思が必要だ。そこには、関係者間で共有すべきこと、理解し合うことなどが山ほどあり、ものすごくエネルギーを要する。それゆえ「仕様調整者」は、メッセンジャーボーイになることなく、伝えることだけでなく、そこにいない人の立場になって意見を聞き、いうことが必要だという。
 また、本書では幸せなシステムを作るための手法を紹介するのではなく、視点を変えることに注力する。当たり前のようで、できていないことだが「お客さまには自分が良いと思うものを勧める、作る」という姿勢、「チャンスはピンチの顔をしてやってくる」という考え方、「見えない部分、小さな部分について適切に判断できるのがプロ」など、さまざまなプロジェクトを経験してきた筆者ならではの金言が散りばめられている。
 RFPは幸せなシステムに通じるのかや、価格が適正かどうかについても言及している。プロジェクトの中で、自分が歯車の1つだと感じている人が、モチベーションを高めるために良さそうだ。(ライター・生井俊)
 
情報処理システム開発の改革!──情報処理システム開発の失敗撲滅に向けての取り組み ユーザーとベンダー双方が認識し実行すべきこと
●工藤 秀憲=著
●ブイツーソリューション 2006年8月
●2095円+税 4-434-08033-4
 失敗プロジェクトの多くは、技術上の問題ではなく人的原因で起こる。それゆえ、失敗プロジェクトの多くは阻止することができる。そうした考えに基づき、プロジェクト遂行をスムーズに行うために、ユーザーとITベンダ双方が実行すべきノウハウをまとめたのが本書だ。
 システム開発に関する契約方式は、民法に定める委任契約または請負契約により成立する。ユーザーが主体的な作業を行い、指示・内容の決定権がユーザーサイドにあるような作業でも、仕事の完成をベンダサイドが責任を持つ請負契約が多々見られる。不公平を是正するために、ユーザーとベンダは、作業工程ごとに作業の主体・指示・命令権がどちらにあるかを吟味し、委任契約と請負契約を厳格に適応する習慣を培う必要がある。
 開発規模の見積もりミスを最小化するために、対象業界と業務に精通したエンジニアによる業務機能をベースにした手法、これまでの開発事例のデータベースを利用する手法、開発ステップ数と機能により金額を算出する手法などを利用する。システム開発が未経験なビジネス領域の見積もりについては、ベンダができるだけ詳細に新しいビジネスモデルの機能をユーザーから聞き出すかがポイントで、ここには類似システムを経験したSEによるヒアリングが欠かせない。
 業種や業務ノウハウを蓄積し活用したいベンダ、目的に沿った機能の絞り込み、スピーディな意志決定を行いたいユーザー企業に向けた1冊。(ライター・生井俊)
 
ジョエル・オン・ソフトウェア
●ジョエル・スポルスキ=著/青木 靖=訳
●オーム社 2005年12月
●2800円+税 4-274-06630-4
 ソフトウェア業界で豊かな経験を持つ著者が、プログラミングとそのマネジメント手法についてブログで書きつづったもの。最高の人々をどうやって雇い動機付けるかや、仕様書などを実際に役立つものにするためのテクニックを中心に紹介する。
 まず、良いプログラムへの12ステップとして「ジョエルテスト」を取り上げる。これは、「ソース管理してる?」「ワンステップでビルドできる?」「仕様書はある?」「採用面接のときにコードを書かせてる?」など、12の質問にyes/noで答える簡単なもの。これらの項目をきちんとやることで、堅実に製品をリリースできる統制が取れたチームができるという。
 また、ほとんどのプログラマはやりたがらないが、スケジュールを作る必要があるとその重要性を指摘する。正確なスケジュールを作る簡単でやさしい方法として、Excelを使い、標準フォーマットを「単純」に保ち、タスクを日単位ではなく時間単位で計測するなど「粒度を細かく」し、経過時間を「毎日アップデートする」といった、13のポイントをまとめている。
 ソフトウェアに関する数多くの事例を挙げながら、ユーモアたっぷりの文章で楽しませる本書は、多くの示唆に富んでおり、読むたびに違う感動がありそうだ。(ライター・生井俊)
 
図解 よくわかる ソフトウェア・ジャストインタイム
●甲斐敏治=監修、前田卓雄/橋本隆成=著
●日刊工業新聞社 2005年2月
●2400円+税 4-526-05410-0
 トヨタ生産方式の基本思想は「徹底したムダの排除」だ。その柱は、必要なときに、必要な部品が、必要な数だけ生産ラインに到着する「ジャストインタイム」と、作り過ぎないよう頭を働かす「ニンベンのついた自働化」の2つで構成される。本書は、生産と開発という違いはあるが、この手法をソフトウェア開発に導入することで、短期間で高品質かつ低コストの開発ができ、また、組織や人材のスパイラル成長に結び付くと主張する。
 第2章では、「21世紀のソフトウェア開発戦略」を説く。ユビキタスや組み込みソフトウェアの市場は拡大し、ビジネスチャンスが多く存在する。その中で余力のあるライバル企業に負けない事業提案をするために「核となる人材の確保と育成」「大幅な生産性向上」「リードタイムの大幅な短縮」など、8つの戦略目標を肝に銘じておく必要がある。
 第3章では、プロセスの「見える化」に言及する。在庫ゼロを目指すのではなく、人・チーム・組織の創造力と実現力(働き)を高め、世界で勝つ競争力を獲得することを目的とする。見える化を妨げているのは、工数ベースのソフトウェアビジネスの慣行と、それに起因した極める意欲が失われていることだと指摘する。
 ソフトウェアビジネスの市場や開発プロセス、トヨタ生産方式をソフトウェア開発にどう生かすかなど、図表を交えて解説する。ソフトウェアビジネスを大きくカイゼンしたい経営者や情報システム部門のマネージャにお勧めする。(ライター・生井俊)
課題・仕様・設計──不幸なシステム開発を救うシンプルな法則
●酒匂寛=著
●インプレスネットビジネスカンパニー 2003年12月
●2200円+税 ISBN4-8443-1866-7
 ソフトウェア開発プロジェクトの失敗はよく伝えられるが、その原因として語られるのは、「仕様変更が相次いだ」「要求が明確でなかった」など、上流工程にまつわるもの。本書はその上流工程におけるプロジェクトの進め方を具体的に技術面から語ったものである。
 タイトルにもなっている課題・仕様・設計の各フェイズについて、それぞれの役割の違いと相互関係性を繰り返し(ウォーターフォールではなく、各フェイズの並行作業を前提としているので、各章で繰り返し)語っていく。この課題・仕様・設計の各フェイズの役割をきちんと認識すること──これが本書のテーマだ。
 すなわち課題とは「解くべき(ビジネス上の)課題を明らかにすること」、仕様とは「その解決のために必要なシステム(仕組み)の定義」、設計は「そのシステムを最適な形で実現する方法」であり、課題に対する仕様の妥当性、仕様に対する設計の正当性を検証(validation/verification)することを強調する。OCLやVDMといった形式仕様記述言語についても簡単に触れられている。
 大規模プロジェクトのメンバーに、それぞれの役割の分担と相互作用を再認識させてくれる1冊になるかもしれない。

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

この記事に対するご意見をお寄せください managemail@atmarkit.co.jp

キャリアアップ

@IT Sepcial

「ITmedia マーケティング」新着記事

博報堂DYメディアパートナーズ「メディア定点調査2019」 スマホ接触時間は1日117.6分に
メディア総接触時間は初の400分台、過去最高の411.6分に。

「Tableau 2019.2」発表、コミュニティーからリクエストが多かった新機能を多数追加
位置情報に基づく意思決定を支援するベクターベースのマッピング機能も。

スマホのQRコード決済サービス、半数近くの人はキャンペーン終了後も「利用する」――ナイル調べ
キャンペーンに注目が集まるスマホのQRコード決済サービス。実際にはどの程度利用されて...