紙の本
日経コンピュータ書評
2005/04/14 18:45
0人中、0人の方がこのレビューが役に立ったと投票しています。
投稿者：日経コンピュータ - この投稿者のレビュー一覧を見る
プロジェクトにおける一連の作業を分解し構造化する手法「ワーク・ブレークダウン・ストラクチャ（WBS）」を、入門者にも理解できるよう丁寧に解説する。WBSは1960年代に登場した概念で、特に新しいものではない。しかし、実務に使われ出したのは最近。著者が指摘するように、「ほとんどの人が、WBSの作成や利用における約束をきちんと理解していない」。例えば、ある作業を複数のサブプロジェクトに分解する際、元の作業を100％網羅するよう設計する「100％ルール」などの原則が守られていないとする。40年以上にわたって、米国政府や民間のシステム開発プロジェクトを指揮してきた経験に基づく指摘だけに説得力がある。
日本語版では、国内の事例として経済産業省を取り上げ、CIO補佐官である葛西重雄氏のインタビューを14ページにわたって掲載している。葛西氏は、プロジェクトの成否を分けるのはWBSだとし、「今後は入札時の要件としてWBSの添付を義務付ける」と語る。
紙の本
あなたの「インターネットが一番楽しかった頃」はいつですか？
2005/04/14 18:22
1人中、0人の方がこのレビューが役に立ったと投票しています。
投稿者：翔泳社 - この投稿者のレビュー一覧を見る
日本でインターネットの接続実験から約20年、商用インターネットサービス開始から約10年となる2005年春、あの伝説のウェブページ「教科書には載らないニッポンのインターネットの歴史」が教科書になって帰ってきました。
時流に合わせて生まれては消えていく個人サイトに焦点を当て、日本のインターネットをネットコミュニティの動向から振り返った民衆史です。
移り変わりの激しい個人ホームページの変遷を詳細に掘り起こした年表は、オリジナルのウェブページから大幅な加筆され、さらに各時代ごとにテーマ分けされた個人サイトの解説を、60万字にも達する膨大なテキストで書き下ろしています。
ニッポンのインターネットは、あなたが見知っているよりずっと広いかもしれません。
巻末解説：大森望氏
オビ推辞：竹熊健太郎氏
■目次
序章 JUNETとfj〜ワールドワイドウェブ以前
世界一簡単なインターネットの説明
教科書にも載るニッポンのインターネットの歴史——まずJUNETありき
ネットニューズの頃
第1章 ニッポンの商用インターネットの草創期（1992〜1995）
e-zine（だからパーソナルメディアなんだってば）
なぜ人はウェブ日記を書くのか
第2章 インターネットブームの光と影（1996〜1998）
テキストサイト誕生前夜（プレ・テキストサイト）
アンダーグラウンド考古学（僕らはみんな厨房だった）
WAREZの歴史（前編）
アングラ掲示板黄金時代
第3章 ウワサ話はネットにのって（1999〜2000）
インターネットのニューウェイヴ（個人ニュースサイトの夜明）
あめぞう２ちゃんねる（巨大掲示板群）
ネットラジオのように
WAREZの歴史（後編）
第4章 個人サイト新世紀〜そしてウェブログへ（2001〜2004）
個人サイトの飽和点
P2P革命
動画・FLASH（21世紀のコンテンツ）
ノー・ウェブログ、ノー・ライフ
もうひとつの序章 パソ通フォーエバー（1976〜2006）
日本パソコン通信史（知らないあなたとヤリトリしたい）
パソコン通信時代（主要大手商用BBS解説）
もう一つのニフティサーブ
アングラ神話の時代（UG系草の根BBS解説）
補章 資料
大事なことは、みんな雑誌に教わった
ネット考古学者のためのビブリオグラフ
投稿元：
レビューを見る
本の画像表示がされていませんが、パステルカラーに象のアニメの装丁の一見や「わらかそう」な本です。
でも、中身は「本格派」です。
投稿元：
レビューを見る
買っては見たものの、文章が読みにくくて苦手系。
この辺のことを知りたければIT Proのweb講座を読んだ方が
ずっとわかりやすいと思います。何より無料だし。
投稿元：
レビューを見る
PMP勉強とあわせ再読。改めて読むとWBSの説明2/3、残る1/3がPMBOKの記載といって過言ではない。
WBSについてはども読み進めづらいまとめかたとなっており、なぜか一問一答形式のPMBOKの解説のほうが掴みやすい。
また巻中にある経産省CIO補佐のインタビューがどうにも解せない。納入者に対し早期からのWBSを望んでおり、提案書やプロジェクト憲章にと同時期と言っている。ハイレベルのものでいいのかもしれないが、急に敷居を上げるのはこの本のコンセプトから遠いように思われるのだが・・・
投稿元：
レビューを見る
表紙は、象の肉マップでした（笑）。「象を食べるには、一口ずつ食べる（＝大きなプロジェクトなら小さなアクティビティやタスクにブレイクダウンして一つずつこなす）」というジョークから来ているようです。
WBSについて、丁寧に書かれています。それで、思ったのは、WBSをきちんと使ってないから日本ではMS Projectが売れていないんじゃないかなということ。
WBSはもう一冊買ったのでそちらと読み比べてみよう。
投稿元：
レビューを見る
タスクを漏れなくあげることと、タスク分解のやり方について詳しい載っている本。
これはこれで有益だと思うが、分解出来たタスクをどうスケジューリングするのかと、どうリソースアサインするかという点については詳しくないので、この辺を勉強出来る本も読みたい。
投稿元：
レビューを見る
WBSの作り方に関する著書である。WBSとは漠然とスケジュールを分割して管理するものだと思っていたが、実際はコツや決まりがあり、非常に参考になった。
・レベル１：プログラムWBSならばトップレベルには一連のフェーズの要素に加えてプログラムマネジメントの要素を持つ
・レベル２：プロジェクトはその成果物に応じてプロダクト、サービス、結果の３つのタイプに分かれ、それぞれに応じてWBS要素を分解する。
－プロダクトの場合、主な成果物要素とその作成を支援する横断的要素からなる、各成果物のレベル３以下の要素は各成果物の構造を反映。横断的要素には統合、分析、プロセスの３タイプがある（例：ソフト開発ではレベル２はソフト、マニュアル、トレーニング資料が成果物要素で統合及びテストが横断的要素、加えてプロジェクトマネジメント）
－サービスの場合、プロジェクトの目的達成に必要な作業分野を表す要素からなり、通常特定の組織や個人に割り振ることができる同種の作業グループがWBS要素になる。また新規作成ではボトムアップ手法で必要作業を概念的グループに振り分ける
－結果の場合も成果物はないが、結果達成に必要な標準プロセスであり、レベル3にて各プロセスの標準手順がはいる
・共通原則：WBSはプロジェクトスコープをすべて網羅しなければならなく、WBSにない作業はスコープ外。すべての成果物をWBSに示す。各レベルの要素の和は親レベルの作業を１００％含む。各WBS要素は個別作業単位を表し、その意味はWBS辞書に詳述するがSOWのベースとなる。WBS要素名はユニークな識別子をもつ。WBS要素名は修飾語＋名詞で表す（アクティビティ：動詞と混同しないこと）
・ワークパッケージ VS アクティビティ：WBSの最下位レベルをワークパッケージと呼び、この下にアクティビティを定義する。ワークパッケージごとに責任者または組織を決める、通常ワークパッケージ内の一連の作業はひとつの組織が実行する（例：PC開発プロジェクトーPC－基盤ー設計、調達、政策、組み立て、テスト（ワークパッケージ）ーテスト計画作成、基盤の調整、テスト機導入、テスト実施、QAによる承認（アクティビティ）
投稿元：
レビューを見る
”我流ではなく、ここできちんと学んでみよう！
---
T:7/31まで→○
P:チームの段取り力UPのため。ひっかかってたところ（WBS→Activity→NW図→ガントチャートの流れ）のコツをつかむ
O:次年度新人研修に向けて大線表をつくるところ。今こそしっかり学ぶのだ！
---
・(WBS作成の)目的は、あくまでこの便利なフレームワークを利用して作業項目を整理、定義、実行することにあるのです。(p.3)
・WBSの分解
プロジェクト成果物や中間成果物を、より管理しやすい小さな単位に分解し、計画、実行、コントロール、終結の各アクティビティ定義ができるぐらい十分詳細なレベルまで要素成果物を分解定義する (p.14)
＃計画、実行、コントロール、終結 らがアクティビティ
★３つのプロジェクト・タイプ(p.25-26)
- プロダクト(Product)…ソフトウェア、ビル、ダム、航空機、ユーザ・マニュアルなど
- サービス(Service)…会議、パーティ、結婚式、休暇旅行など
- 結果(result)…ガン研究、新薬開発、風土変革など
＃研修もサービスでいけそう！
＃必ず第２レベルには「プロジェクト・マネジメント」を入れる
・サービスの分解(p.28-30)
- 関連する作業要素を機能、スキルごとにグループ化するかたちで分解
- このタイプのWBSはボトムアップで作成する場合が多い
★サービス・プロジェクトのWBSは、同種のプロジェクトのテンプレートとして利用することができる。レベル2またはレベル3ぐらいまではどれもほぼ同じ
・WBS要素名は、ワーク・パッケージのレベルまで名詞で記述します。一方アクティビティは（中略）具体的な動作を伴う表現にします。(p.40)
・プロダクト、プロセス、システムのいずれの分解構造でも、WBSを順序設定に利用することはできません。
・100パーセント・ルール (p.55)
WBSのどの要素も次の分解レベルには、親要素を100パーセント含まなくてはならない。
・「アクティビティの特徴」より (p.56)
- アクティビティは、動詞、形容詞、名詞で記述される活動である
- ひとつのアクティビティに複数人が割り振られる場合も、アウトプットの納品責任者を決める。そうなっていない場合には、さらに分解するか、共同責任を明確にする
- WBS要素の各アクティビティの妥当性を確認し、違和感があれば、WBS構造かアクティビティのいずれかを見直す
- アクティビティは、プロジェクトの目的を支援する重要な作業のことであり、些細な作業や偶発的な作業を含める必要はない。
★展覧会プログラムのフェーズ定義(図3-2)、プログラムWBS(図3-3) p.62
＃研修プログラムの参考にできそう！
・各フェーズのすべての計画を、各フェーズのプロジェクトマネジメント要素とするのではなく、プログラム・マネジメント要素に入れることもできます。重要なのは、すべての作業を網羅することです。
＃★WBS分解方法は１つではない。
・ソフトウェア開発では、要件定義、設計、コーディング、テストなどのステップがあります。組織内のこのプロセスに慣れきってしまい、アウトプットが結果ではなくプロダクトの場合でも、これに沿ってWBSを構成してしまう場合があります。
結果プロジェクトだけが、レベル２でプロセス要素をもつということを忘れてはいけません。(p.67)
＃★基本はプロダクト成果物として、システム・テスト等は横断的要素をいれること！！ (p.69 図3-8)
・Ｑ：WBSを作成する際に使用するソフトウェアは？(p.127)
WBS Chart Pro (http://www.criticaltools.com)
★WBSのサンプル(p.158)
ソフトウェア・システム開発プロジェクトのWBSの基本設計フェーズの一部
＃WBSのワークパッケージに対して、成果物、作業分担、所要工数、コスト、備考（リソースについての注記など）が記述されている。”
投稿元：
レビューを見る
これまでの自分を含めて、どれだけの「現場」(何もシステム開発だけではない)が、「基本に忠実に」WBSを作ることができていなかっただろうか、と痛感する書。
特にSIerさんだと「なんとなく、成果物をプロットして終わり」になっていたり、「構築、設定作業」をプロットしていたり…。
改めて振り返るにも大事と痛感しました。
