Kindle 価格: | ¥2,376 (税込) |
獲得ポイント: | 24ポイント (1%) |
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
曖昧性とのたたかい Kindle版
大規模システム「マルス(世界初!「みどりの窓口」の鉄道予約システム)」を成功させたプロジェクト管理の秘訣とは?
PMの本というと、事例や理論を示しただけものが多いようだが、本書はまったく違う。経験豊富な著者が、現場で得たノウハウを整理し、丁寧に教科書的にまとめているのだ。経験に基づいた解説には「なるほど!」と納得させられてしまう。システムビジネスの流れを基礎から学べるので、これからプロマネになる人、スキルアップを目指すプロマネ、そしてプロジェクトを依頼する立場の人にも、ぜひ読んでいただきたい本である。
――矢沢久雄(グレープシティ株式会社 アドバイザリースタッフ 『プログラムはなせ動くのか』著者)
新幹線システムをはじめ日本の数多くのプロジェクトをリードしたSEならではのシステム化の想いやプロジェクト管理の心得え大きな感銘を受けた。コンピュータやOSなどのソフトは大きく変わったが、SEが学ぶべきシステム開発のプロジェクトのポイントは今でも変わらない。IT業界のSE・営業の方は勿論だか、一般のユーザーの方も是非読んでさらなる飛躍の糧にして欲しい。
――馬場史郎(グローバルナレッジネットワーク株式会社 副社長 『SEを極める50の法則』著者
※本電子書籍は同名出版物を底本とし作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
- 言語日本語
- 出版社翔泳社
- 発売日2005/3/17
- ファイルサイズ2248 KB
この本を読んだ購入者はこれも読んでいます
登録情報
- ASIN : B00DIYRKQW
- 出版社 : 翔泳社; 第1版 (2005/3/17)
- 発売日 : 2005/3/17
- 言語 : 日本語
- ファイルサイズ : 2248 KB
- Text-to-Speech(テキスト読み上げ機能) : 有効
- X-Ray : 有効
- Word Wise : 有効にされていません
- 付箋メモ : Kindle Scribeで
- 本の長さ : 292ページ
- Amazon 売れ筋ランキング: - 144,648位Kindleストア (Kindleストアの売れ筋ランキングを見る)
- - 5,335位コンピュータ・IT (Kindleストア)
- - 5,666位工学 (Kindleストア)
- - 10,206位コンピュータ・IT (本)
- カスタマーレビュー:
著者について
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
私たちの目標は、すべてのレビューを信頼性の高い、有益なものにすることです。だからこそ、私たちはテクノロジーと人間の調査員の両方を活用して、お客様が偽のレビューを見る前にブロックしています。 詳細はこちら
コミュニティガイドラインに違反するAmazonアカウントはブロックされます。また、レビューを購入した出品者をブロックし、そのようなレビューを投稿した当事者に対して法的措置を取ります。 報告方法について学ぶ
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
例えば、以下のような内容。
■システムビジネスの三大業病: 「契約時の曖昧性」と、それに起因する「仕様決定の遅れ」と「仕様変更と仕様の膨張」。これら三大要素が失敗プロジェクトの最大の原因。
■契約内容: SIビジネスの損益は、見積もり条件および契約条件で5~8割が決まるため、念入りに準備。要求内容に関しては、顧客に対して何度も質問し曖昧さを減らす。納期は、必要に応じて段階的稼働を提案する。納期の定義には「仕様凍結後○ヶ月」とか「○月×日、仕様凍結前提」などリスクを回避できるようにする。検収条件は、範囲または期間のいずれかで必ず有限の明示的条件を設定する(いくつテストしたら完了、この期間に出たバグに対応したら完了等)。受注価格は、総額値引きはしても単価値引きは絶対しない。
■見積もり: 後で再見積もりができるような条件にしておくのが、良い見積もり。見積もり対象を減らして、汎用品の活用や既存システムの流用を考える。業務仕様については、分かる範囲で極力詳細に記載する。その他、処理結果の合否判定に業務知識を要する、仕様の変動性が高い、コンバージョン作業量が多い、オンライン系で障害・例外処理が多いなど、難易度の高い開発の見積もりに注意する。
■スコープ: システム仕様は契約時の内容をベースにする。新たにゼロから起こすものではない。また、ベンダー側主導で仕様決定をリードすることが不可欠。膨張を防ぐためには、要求仕様を本質的な共通機能に絞り込む、代案を提示する、システム基本思想の再共有、そのシステムの致命的な事故の把握などが役に立つ。
■プロジェクト計画: 工程表は、プロジェクトマネージャー自身が作成することが重要。
■基本設計: バグが見つかりやすい設計やテストしやすい設計、運用しやすい設計を意識する。特に業務データの結果不正などは、システムダウンより悪影響を招くこともあるので摘出ロジックを組み込む。処理能力に関しては、ある日突然トラフィックが急増するようなシステムが難しいため、顧客とよく確認が必要。運用に関しては、システムの状態がわかりやすい、誤入力を起こしにくい、極力自動化することを意識。
■プロジェクトマネジメント: 定量的・定性的の両面から問題点の早期把握に努める。スケジュールの書き直しは極力やめるべき。仕様変更はどうしても発生するので、費用と日程の確保は最低限契約に盛り込んでおく。要員配置は重要。目につきやすいところは新人にやらせると、問題が早期に顕在化できる。大規模プロジェクトでは、先手を打って課題解決したり共通仕様の整備ができる統括部隊を極力設置する。報告は、事実、事実に対するコメント、事実に対する対策案の3つで構成し、はっきり分別する。独立テスト部隊を編成することで、全体の整合性の確認ができる。
■顧客との信頼関係構築: まずは自分の技術力を磨く。顧客の言ったことをそのまま迎合するのではなく、真の目的が何かを考え、その上で別提案を積極的に行う。顧客側には、最終意思決定者を最初から明確にしてもらうことが特に重要。
■問題が起きた時の対応: 第一に実体の把握。動き出す前に、まずは徹底的に整理・全貌把握する。その後、必要最低限の機能を選びだし、それに対して対策日程を練り直す。
プロジェクトが上手くいっていないことから、どのようにすればよいか考えるために読了。
読んでいて、自分の参画するプロジェクトに置き換えると、思わず納得してしまう部分が多々あった。
SEとして遭遇するであろう問題がかかれており、必ず参考になる部分があると思うので、特にリーダークラスで悩んでいるSEに薦める。
プロジェクトマネージャー向けのベストプラクティス読本、といった感じのまとめ方になっており、想定読者は情報システム開発プロジェクトのプロジェクトマネージャー、またはプロジェクトマネージャーを目指す人思われます。
著者も本文中に書いている通り、具体的なエピソードや背景は端折り気味です。「こうすべき」「こうすべきではない」という要点を列挙した感じの内容のため、プロジェクトマネージャーの経験がある程度ある読者でないと、「この箇所では具体的にどのような状況を想定しているのか」が分かりにくいのではと思いました。
一応、最終章に著者がJRのマルスシステムの開発時に経験した課題と対策を載せており、これが唯一具体的な事例かと思います。ただし前提となるシステムアーキテクチャが不明瞭なのと、技術的な詳細が端折り気味のため、現在の自分のプロジェクトでも起こりうる問題なのかの判断は多分に経験値や想像に依ることになります。
そのため、中堅~ベテランのプロジェクトマネージャーが、自分の担当するプロジェクトにおけるチェックリストとして使うのが効果的だろうと思います。
「中国拳法と同じで、いきなり奥義を教えられても何もできない」という話と同じで、経験の浅いプロジェクトマネージャーでは書いてある内容は理解できるかもしれませんが、「いつ、どういうときにこれが具体的に役に立つのか」が分からないだろうと思います。その場合は、他の書籍等で具体的な事例を細かく学んだ後に、まとめとしてこの本に戻ってくるのがいいのではないかと思いました。
WEB上の決済システムの営業から人事のコンサルタントとして転職して最初の仕事は大規模な人事に関するシステム構築の仕事。前職では当たり前のように動いていた”システム”と呼ばれるものを自分で作る楽しさがある。
質の高いものを作るためにはまっすぐ実直にまじめに走り続けるしかない。
システムを作る人間の一人にこの本はそう伝えてくれる。誰もが一度は使ったことがあるであろうみどりの窓口のシステム構築に関わってきた著者がソフトウェア開発についてメモをしていたことが1冊の本にまとまった。
タイトルにも使われている「曖昧性」という言葉は開発に関わったことがある人であればピンとくるでしょう。はっきりと文面化されておらず、様々な資料やインタビューから読み取ることで全てを言葉にすることが難しいシステムの仕様を決定し、お客さんにシステムの内容を承認してもらい、開発を行う。
完成するまで成果物が見えないシステム開発だからこそ”曖昧性”という言葉が使われている。開発を行う全ての人が”曖昧性”にどう向き合い、どう自分の答えをぶつけていくのかが大切になる。曖昧だからこそ、リスクヘッジをしないといけないし、苦労もある。難易度も高い。
だからこそ、やり遂げた時の喜びは大きくなるのだろう。
まだ、1つの大きなシステム開発をやりとげたことはないので、やり遂げた場にいたいと強く思うお仕事の日々。
【引用】
日立製作所に在籍していた筆者は、昭和39年に日本初の本格的オンラインリアルタイムシステムである国鉄のみどりの窓口システム(通称「マルス」)の開発に参加
プロジェクトマネジメントの妙薬や“銀の弾丸は存在しない
【メモ】
スコープの早期明確化、スコープの膨張抑制、スコープの変更(あるいは変動)抑制がプロジェクトをなんとか成功裏におさめる鍵となる。すなわち、スコープマネジメント
プロジェクト計画段階、基本設計段階から、「人は間違え、機械は壊れ、バグは残ると覚悟せよ」と考え、最悪事態への備え(prepare for the worst)と、どんな困難でも負けずに突き進む
受注合戦というのは、顧客、自社、コンペチタが、似て非なる三者三様のシステム仕様の解釈に基いて、最低契約金額を決めるプロセスになってしまうのである。これを「曖昧の三角関係」と呼ぶ
あとで予算増額を要請をせざるを得ないとしても、その場合には第三者を納得させることができる「予算増額要請の正当性」の論拠を、契約時から準備しておかなければならない。すなわち見積りおよび契約時には、その時点で「想定したシステム仕様」を可能な限り明確にすることである。この明確化を怠れば、予算増額要請の論拠が失われてしまう
「正体がよく見えず、ついつい巨大化しがちな、システムという怪獣をいかにして丈夫な檻に閉じ込めるか」が大口赤字回避の課題
どうせ契約後にはっきりさせるしか方法はないなどと最初からあきらめてしまうのは間違いだ。時間が許すかぎり、顧客に対して何度も質問し、要求事項のより正確な文書化に努めて、曖昧さを少しでも減らすべき
バリー・W・ベームは出荷までの最適スケジュール時間T(月)は であるとした。たとえば所要人月が64人月の場合には、10ヶ月の工期ということになる
納期の定義には「仕様凍結後○ヶ月」とか「○月×日、仕様凍結を前提として」というような文言を入れておきたい
プロトタイピング方式は、仕様確定までの要員派遣契約の間で最大限活用してもらい、早期仕様確定に役立てるのが最も有効な利用法であろう。そして、仕様確定後に請負契約としてもらうべき
ファンクションポイント法(Function Point Method):1979年にIBMのAllan J. Albrecht 氏が考案したシステム規模を測定する手法。それまでに主流であったステップ数(Lines ofCode:LOC)でシステム規模を測定する方法が適当な指標とはならなくなったために考案された。ファンクションポイント法では、システムが持つ機能(ファンクション)を切り出し、1つの機能がどれだけ複雑かを評価し、点数化(ポイント化)する。その点数に一定の係数を掛け、システム全体の規模を定量的に計測する。ここで使われる機能とはユーザー要件から導出されるものであるため、仕様が確定してから再度計測しなければ、見積り精度は上がらないとされている。
一般にシステムの機能とは、なんらかの入力(x)を与えて、しかるべき処理Fを行い、結果としてF(x)を出力することである。このようなシステムの完成度を検証するためには、入力xを変えてみて常に正しい結果F(x)が出力されることを検証しなければならない
スーパーSEとは、顧客予算に合わせて、顧客の希望業務をなんとかこなせるシステムを提案、設計できるSE
仕様確定は、できるだけ早く、かつ詳しく、そして小さく決めることがポイントである。時間がかかることも、仕様が膨らむことも、すべて、そのあとに続く開発に許される時間と予算を圧迫することになる
実現方式を云々する前に、まず業務仕様を固めることが第一歩であることを強力に顧客に訴えるべき
「最良の業務改善はその業務自体をやめることである」
レビュー時間も2時間以内に抑えたい。これは人間の注意力が持続する限界はほぼ2時間と言われているから
要求仕様決定段階における仕様変更コストを1としたとき、テスト段階で直すと20倍、納入時点で直すと200倍かかる
稼働前後の修正変更は絶対禁止 バグであれ仕様変更であれ、修正・変更は工程混乱の元凶である。システム開発の終盤、総合テスト工程以降では、厳重な変更管理が必要である。特にシステム稼働開始前後数ヶ月(最低2ヶ月)の仕様変更は稼働に不可欠の機能を除き、絶対禁止
悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違いない
遅れているプロジェクトに人員を補充するとスケジュールはさら に遅れる。 補充しないで放置するとプロジェクトは壊滅する
曖昧性が生じていたのは、「×××の場合は○○○する」という類の仕様の書き方にある。「それでは、×××でない場合はどうするのですか?」と問うと必ずしもすぐには答が出てこないという状況にあった。これは何も国鉄だけの問題ではなく、大半の顧客から最初に提示される業務プログラムの仕様はこういう個別事例の仕様、いわば「点仕様」となっていた。よくても、せいぜいいくつかの例の関連性を示す「線仕様」になっていた。 ところがプログラムを作ろうとするには、すべての場合を規定した「面仕様」になっていないと困るのである
【手に入れたきっかけ】
Kindleキャンペーン
特に5.2の後工程のくだりについては、もっと早くこの本を読んでおけばよかったと思うほど同じ経験をしており、身につまされる。