1月にやったプロジェクトマネジメント勉強会が消化不良だったこともあり、社内で再び喋る機会を頂いたので喋ってみました。
しかし何となくまた消化不良。なんでやねん。
■■■■■ 以下、勉強会のために用意した原稿 ■■■■■■
[note]_プロジェクトマネジメント勉強会（PMBOK概要）20100824
■P1
はじめます。
・このイラストの説明
・今日の勉強会に何を期待しているのか？
・PMBOKについてどの程度のことを知っているのか？
■P2 プロジェクトマネジメント勉強会（PMBOK概要）
技術部の嵩原です。
よろしくお願いいたします。
■P3 注意
最初にみなさんに注意です
■P4
注意①「この勉強会には新しい知識はありません」
この勉強会を通じて、皆さんは新しい知識を得ることはありません。
全て、実際のプロジェクトを通じて、もしくは書籍やWebの記事を読んで、
みなさんが経験や知識としてすでにもっているものです。
注意②「集中してください」
資料は後で差し上げます。
コンセプト③「わからない単語はその場で質問してください」
でも私が応えられなかったら、雰囲気でつかんでください。
コンセプト④「私はウソをつきます」
疑ってかかってください
■P5 はじめに
はじめに
■P6 プロジェクトマネジメントって何？
プロジェクトマネジメントって何？
はい、なんだと思いますか？ って聞きたいところですが、
■P7 っていう漠然としたテーマで～
っていう漠然としたテーマではじめるとドツボにはまるので、
今日はPMBOKに沿ってお話しします。
■P8 PMBOKって何？
そうすると「PMBOKって何？」ってなりますよね。
■P9 Project ～
PMBOKはプロジェクトマネジメントの知識体系、
Project Management Book of Knowledgeの略で、最新は第4版です。
PMBOKとはPMI、プロジェクトマネジメント・インスティチュートが編
纂をした知識体系で
■P10 ウィキペディアによると
ウィキペディアによると
■P11 PMBOK －－－－－－－－
こんな説明があり、一言に縮めると、
■P12 先人達の知恵
こういうことになります。
じゃ、なぜこのようなものが生まれたのかというと、一昔前まで、
プロジェクトマネジメントの手法が属人的だったことがあります。
人によってやり方がずいぶん違っていますと。
あと同じ事を言っているのに名称が違うとかね。
そしてPMBOKにはどういったプロジェクトでも共通して
適応できそうな手法や考え方をまとめています。
これは非常に便利で良いぞってことで
■P13 多くのフォロワー？が生まれた
多くのフォロワーというか、派生体系が生まれ、今では
■P14 SWEBOK ～
こんな感じでいろいろあります。
（必要であれば、各項目を簡単に説明）
こんなに派生体系が生まれるくらい、よくできた編纂方法だったんですが、
ちょっと問題というか
■P15 ここで注意
注意があって、PMBOK自体はどういったプロジェクトにも共通して
有効な手法や考え方をまとめただけあって
■P16 この知識体系に専門知識はついていません
PMBOKだけあっても何も解決しません。
これは一頃言われた「PMBOKは現場で役にたたない」という風評被害の
一因になったんじゃないかと思います。
でもそれは間違いで、PMBOKはあくまでプロジェクトマネジメントの知識
体系であって、専門知識を扱ったものではありません。
しかし専門知識なきマネジメントなどあり得ないので、
■P17 ※用法用量は守ってお使い下さい。
用法用量は守ってお使い下さい。
私、個人的にはSWEBOKとの併用がお奨めです。
■P18 PMBOKによるプロジェクトの定義(特性)
さてプロジェクトマネジメントを学習する上で、必ず押さえておいてほしい
こと、それはそもそもプロジェクトってなんなんですか、という話です。
これにはプロジェクトが共通してもっている特徴を押さえるとわかりやすい
です。
それには3つあって
■P19 1.有期性 2.独自性 3.段階的詳細化
1.有期性 2.独自性 3.段階的詳細化 です。
■P20 1.有期性
1.から順に簡単に説明すると、
■P21 始まりがあって～
有期性は始まりがあって、終わりがあること。です。
毎日やる業務とかも、厳密に言えば始まると終わりがあると言えなくも
ないですが、プロジェクトは明確（時にはあやふやに定められます）
■P22 2.独自性
次の独自性ですが、これは
■P23 同じ物はない
同じ物はない。
プロジェクトは二つとして同じものはありません。
作り出そうとするプロダクトは二つとして同じものはありません。
仮に何かのプロダクトやサービスのパクリ構築プロジェクトだとしても、
オリジナルメンバーをそのままでやることはあり得ません。
■P24 3.段階的詳細化
次に段階的詳細化ですが
■P25 細かいことは（本当のことは）～
こうやって書くとちょっと嫌な感じがしますけど、最初から全部わかっ
ていることはありません。
個人的にはこの言葉は好きで、プロジェクトはわからないことをわかる
ようにしていく活動と言い換えることもできます。ある意味、学習の過程
であり、終わった時には知らなかったことを知ることになります。
だいたい今までの3つをまとめると
■P26 プロジェクトとは、ある一定の期間において～
「プロジェクトとは、ある一定の期間において、唯一の成果物
(モノ/サービス)を生み出すための活動である。」
とも言えます。
そこであらためて
■P27 プロジェクトマネジメントって何？
プロジェクトマネジメントって何？な話を
■P28 あえて
あえて
■P29 一言で表すと
一言で表すと
■P30 フォースに調和をもたらすこと
フォースに調和をもたらすこと、かなと。
■P31 説明しよう
いちおう説明すると
■P32 ウィキペディアによると
ウィキペディアによると
■P33 （画像）プロジェクトマネジメント
■P34 プロジェクトマネジメント（プロジェクト管理）
「プロジェクトマネジメント（プロジェクト管理）とはプロジェクトを
成功裏に完了させることを目指して行われる活動のことである。
これにはプロジェクトを構成する各活動の計画立案、日程表の作成、
および進捗管理が含まれる。」
と書かれています。
もちろん間違ってはいませんが、個人的な想いとしては
■P35 ちょっと足らない
ちょっと足らないと思っていて、何故かというのを説明すると
■P36 （画像）ビジネス、エンジニアリング、プロジェクトマネジメントの図
これは業務システムやソフトウェアの開発プロジェクトに必要な知識や
スキルをざっくりとわけたベン図です。
ビジネスはプロジェクトを通じて生み出されるプロダクトやサービスを用
いて利益を生み出すことが主な目的です。
これはビジネスアナリスト、システムアナリスト、ITストラテジストと
いった役割の人が考え音頭をとります。
クラスメソッドの場合はお客さまがやることが多いです。
エンジニアリングはそれを実現するための活動全般です。どうやったらそ
れができるのかを考え現実世界に適応していきます。いわゆるアーキテクト
やシステムデザイナーの仕事です。
ビジネスとエンジニアリングは敵と書いて「とも」と読むような関係です。
放っておくとすぐ闘い始めます。
しかし、現実の世界ではビジネスの方が権力をもっていることが多く、
エンジニアリングが泣きをみることが多いです。
しかししかし、世界は因果応報、エンジニアリングに泣きを見させると生み
出されるプロダクトやサービスが低品質なことが多く、結果的にビジネスも
泣きを見ます。
「誰得」なことになります。
■P37 プロジェクトマネジメント（プロジェクト管理）
それを踏まえた上で個人的な追記をさっきのウィキペディアにすると
「プロジェクトマネジメント（プロジェクト管理）とはプロジェクトを
成功裏に完了させることを目指して行われる活動のことである。
これにはプロジェクトを構成する各活動の計画立案、日程表の作成、
および進捗管理が含まれる。
また、利害が相反する関係者の意見を集約し、制約を利用しつつ、
プロジェクトにおける共通目的を達成するために行うあらゆる活動。」
となるため、
■P38 だから
だから
■P39 フォースに調和をもたらすこと
「フォースに調和をもたらすこと」となるわけです。
（ここで一呼吸置く。気分転換にスターウォーズの話を振ってみる）
プロジェクトマネジメントとジェダイの関係について、皆さんにご理解
いただけたところで、先に進めます。
PMBOK、プロジェクト、プロジェクトマネジメントがだいたい何なのかが
わかったところで
■P40 じゃあ、何をするの？
じゃあ、何をするの？となると思うですよ。
そういうときのために、
■P41 プロセス順に説明
プロセス順に説明をします。が、
■P42 でも「プロセス」っていうと
でも「プロセス」っていうと、
■P43 こういうのとか（滝）
こういうウォーターフォールなやつとか、
■P44 こういうのとか（スクラム）
スクラムとかアジャイルみたいなやつとか、
■P45 こういうイメージがあると思うんです。（ラップ）
RUP、言い換えると統一プロセスみたいのを連想すると思うんです。
（RUP、アジャイル、スクラムについて知っているか確認しておく）
■P46 PMBOKのプロセス～
今、出てきたのは基本的には「ソフトウェアの開発のためのプロセス」
なので、あらゆるプロジェクトに共通して使える汎用的なものとは
ちょっと違います。
違いますって言っておいてなんですが、ここは話し始めると長いから
この場ではそういうことにしておいてください。
PMBOKのプロセスはもうちょっと汎用性のある(抽象的)なものです。
■P47 （画像）5つのプロセス
PMBOKではプロジェクトのプロセスを5つに分類しています。
・立ち上げ
・計画
・実行
・終結
・監視コントロール
立ち上げ
プロジェクトを公式に認可し、ステークホルダーを特定します。
さらに何を持ってステークホルダー、この場合は顧客がメインになり
ますが、の期待を満足することができるのか、要求事項を文書化する
プロセスです。
この立ち上げフェーズでは、プロジェクトマネジメント憲章という文
書を作成することがあります。
計画
作業全体のスコープを確定させ、アクティビティ、WBSを洗い出し、
プロジェクトの計画を策定します。
この際、プロジェクトマネジメント計画書という文書を作ることがあ
ります。
ていうか、できれば作ってください。
扱う情報は多岐にわたり、というかプロジェクトに関わる物事のほぼ
全部となります。
営業さんを含めプロジェクトマネジャーやプロジェクトリーダーで考
えます。
実行
プロジェクトの仕様を満たし、プロジェクトマネジメント計画書に
規定された作業を完了するための活動です。
プロジェクトマネジメント計画書に沿って、人と資源を調整し、
プロジェクトのアクティビティを統合し、実行します。
プロジェクトマネジメント計画書に従って活動をします。
主にプロジェクトリーダーによる作業指示と進捗管理が該当します。
このプロセスにおいて変更管理をきちんとしないと痛い目にあいます。
終結
プロジェクトの契約上の義務を公式に完結するために、またアクティ
ビティを終了するプロセスからなる。
納品から請求支払いが該当します。
終結は他のプロセスに比べて、情報量こそは多くありませんが、完了
条件を現実的で実行性のある内容にしておかないと、先立つものが先
立たなくなってしまう原因になりかねません。
わたしも苦労した経験がありますが、特に、納品、検収、請求、
支払いサイトについてはしっかりとした確認を行ってください。
そしてプロジェクトのレビューや教訓の文書化なども行います。
そこまでやってプロジェクトです。
監視コントロール
プロジェクトマネジメント計画書で定義されたパフォーマンス目標を
達成するため、進捗をチェックし、レビューし、統制する活動です。
プロジェクトチーム外から、プロジェクトの運営について適切である
かどうかチェックすることもあるでしょう。
■P48 確かに抽象的だけど、どんな～
「確かに抽象的だけど、どんなプロジェクトであってもこの5つは共通して
必要。」
です。
ウォーターフォールとかアジャイルとかRUPを簡単に紹介した後に、PMBOKの
抽象的なプロセスの説明をしているのには理由があって、それは
■P49 プロセスの偏重は罠
プロセスの偏重は罠という思いです。
というか、○○プロセスを採用したら上手くいくとか、○○プロセスを
やってますとかは単純で分かりやすいから飛びつきたくなる気持ちはよく
わかるんですけど、罠です。
これを
■P50 身近な例
身近な例である、
■P51 ガンプラ
ガンプラで説明すると
■P52 （ガンダム）
例えばガンダムを組み立てるプロセスをこうしたとします。
１．頭 ２．胴体 ３．手 ４．足 ５．シールド ６．ライフル
しかし、同じガンプラでも種類が違うと
■P53 （ジオング）
ジオングに至っては足ない、シールドない、ライフルないで冗長なプロセス
を採用することなります。
しかも、よく見てください。
足の代わりに台座があります。見えますか？
■P54 プロジェクトは「独自性」の特性を備えている～
「プロジェクトは「独自性」の特性を備えていることに注意し、
プロセスを盲信しないこと。
アジャイルだから上手くいく、ウォーターフォールだから失敗する
わけではないこと。」
ということをしっかり頭に入れましょう。
これはPMBOKでは
■P55 （～略）これにより、
こういった文章で解説されています。読みます。
「これにより、本書で述べる知識、スキル、プロセスを常にすべての
プロジェクトへ画一的に適用すべきであるといっているわけではない。
プロジェクト・マネジャーは常に、プロジェクト・チームと協力して、
当該プロジェクトでは、どのプロセスが適切であり、各プロセスをどの
程度の厳密さで実施すべきかを決定する責任がある。」
ある意味、これが全てです。
■P56 何をやるのか？
結局「何をやるのか？ やらないのか？」をはっきりさせることが最低限
大事で、プロセスはそれから考えても良い話です。
イメージとしては
■P57 曇りなき眼で見定めてプロジェクトを計画すること。
「曇りなき眼で見定めてプロジェクトを計画すること。」
であると強調しておきます。
で、
■P58 「計画？」
計画をたてるわけですが、さっきの5つのプロセスを思い出してください。
■P59 5つのプロセス
粒度は違えど、計画立案は立ち上げプロセスから始めます。
ここでお伝えしておきたいのは、計画というのはメンテしながら使うもの
であることです。一回たてたら終わりじゃなくて、状況状況に合わせて、
変更していくことが大事です。
絶対計画通りになるというのは、段階的詳細化に反しますし、そもそも
そんなものは計画ではなくて、予言です。ありえません。
■P60 何をどう計画する？
さて、何をどう計画するのか？
■P61 PMBOKにはほとんどのプロジェクトで共通する知識領域が9つ
PMBOKにはほとんどのプロジェクトで共通する知識領域が9つ用意されてお
り、
■P62 1．統合 2．スコープ ～
並べるとこんな感じ。それらを更にブレイクダウンすると、それぞれ
こんなプラクティスを持っています。
P63～70はさーっと飛ばす
■P71 プロジェクト統合マネジメント
で、ここまで8つの知識領域を統合するのが、この
「プロジェクト統合マネジメント」の領域です。
この辺は9つの項目だけなんとなく憶えてもらって、プラクティスは
都度考えるとかでもとりあえずは大丈夫です。
それとどのプラクティスも
■P72 インプットとアウトプットに注目し、
「インプットとアウトプットに着目し、シンプルに考えること。
全て下記のパターンでできてる。
○○のインプット
○○のツールと技法
○○のアウトプット」
インプットとアウトプットに注目してください。
かならずこのパターンになっていますし、プロジェクトの計画を立てたり
実際に作業をするときは、かならずインプットとアウトプットがあるはず
です。
そしてアウトプットの行き先に留意してください。
行き先のないアウトプットはムダな作業かもしれません。
もしくは利用者のことを考えてアウトプットをだすことも大事です。
これぐらいの情報を押さえれば、しっかりとした計画を立てられるで
しょう。でも、
■P73 いきなり全部細かにかくのはしんどいから、簡単なところから。
「いきなり全部細かにかくのはしんどいから、簡単なところから。」
でも大丈夫です。
■P74 顧客名 ～
私がプロジェクトに関わるのは立ち上げから計画に相当する時期が多い
のですが、だいたいこれぐらいの情報は把握し、その推移を管理するよ
うにしています。
■P75 このレベルでもしっかり書く(把握する)だけで～。
このレベルでもしっかり書く(把握する)だけで、プロジェクトの見通し
は随分違います。不足があれば都度、考えて追加してください。
（確認）
■P76 ここまでの内容に補足
ここからはサマった知識だけじゃなくて、ちょっとした注意点とか
TIPSをご説明します。
■P77 コミュニケーションについて
コミュニケーションは仕事をする上でもっとも大切な事の一つですが、
仕事をしていく上で最もムダな事の一つです。
なぜムダと言っているかというと、コミュニケーション自体がものを
つくるわけでありません。
しかし、私の数少ない経験上、コミュニケーション・マネジメントは
どこ行っても適当な扱いで、適当にしてしまったがためにプロジェクト
に重大なオーバーヘッドを発生させる原因にもなります。
クライアントが何気なく納品を求めたドキュメントはそのわかりやすい
例ですが、日常においても「なんでそんなこと知らないの？」みたいな
事は思いの外、時間をムダにするものです。
コミュニケーションに無理、ムダ、抜け、漏れ、冗長さがないか、根本
に立ち返って考えてみるのも悪くないはずです。
コミュニケーションをデザインすることを心がけてください。
■P78 コミュニケーションパス
それとコミュニケーションパスのはなし。
コミュニケーションパスの求め方を知っている人いますか？
n(n-1)/2ですね。
プロジェクトの人数が増えるときはコミュニケーションの時間も工数も
増えます。
1パスが1日当たり15分ほど時間を使うと仮定すると3人までなら管理者は
作業者兼務でいけますが、5人くらいから管理者は管理業務専門になり、
10人とかになると管理者を手伝う人が必要なります。
ちなみに1パス15分は楽観値です。
おそらく30分から1時間くらいはかかる可能性があります。
またステークホルダーとのコミュニケーションもバカになりません。
結構、もっていかれます。
定例MTGなんかもそういった活動に該当します。
余談ですが、営業の世界では、上長の下に付けられるメンバーの数は
7人程度だそうです。
7人はけっこうがんばってもらう感じ。
できれば5人くらいで勘弁してあげた方が良く、10人は管理しきれない
そうです。
この例でもあるように、マネージャー一人で10人も20人も、はてはそれ
以上のメンバーを管理する話は無理があります。
■P79 このパスは空間軸(他人)だけでなく、時間軸(未来の自分)にも発生する
またパスは空間軸(他人)だけでなく、時間軸(未来の自分)にも発生します。
未来の自分、未来の他人とのコミュニケーションは主にドキュメントに
なります。
それを踏まえた上で、どうするえばコミュニケーションしやすいか
考えましょう。
■P80 「計画」
あらためて計画に関する話。
■P81 不確実性のコーン
段階的詳細化を一目見てわかってもらえるグラフが不確実性のコーンと
呼ばれるグラフです。
プロジェクトに対してどの程度の工数が必要であるのか、フェーズごとに
その振れ幅を表しています。
諸説ありますが、プロジェクト計画時点では最大400%、最小25%ずれると
いう説があります。
契約締結の際、前半を準委任契約、後半を請負契約にすることの理由は
こういうところにあります。。
■P82 ブルックスの法則
「ブルックスの法則」はプロジェクトメンバーを増員しても縮められる
期間には限度があることを表しています。下手すると、余計に時間が
かかります。
プロジェクトは規模に応じて、適切な人数と期間があり、がんばって縮め
ようとしても限度があります。
■P83 PERT図
パート図はタスクの手順と関連を表した物で、古典「計画の科学」で詳しく
解説されています。
■P84 ガントチャート
ガントチャートはPERT図よりも全体の流れを俯瞰しやすく、またその作業
にかかる期間をイメージしやすい表現になっています。
私は好きなんですけど、これを使って進捗管理をすると、本当の進捗率を
隠蔽してしまったり、もしくは実態をよりも進んでいると錯覚を起こす
ことがあるので注意が必要です。
本来の目的はあくまで計画の見通しを知るためのモノです。
■P85 バーンダウンチャート
「アジャイルな見積もりと計画」という書籍に詳しい使い方が紹介されて
います。
簡単に説明すると、タスク総量を積み上げて少しずつ減らしていく
チャートです。
タスク総量と生産性（ベロシティ）と期間の3つのパラメータしか
ありません。
①タスク総量が把握しやすい。追加、変更による積み上げがすぐわかる。
②ベロシティを管理しているため、ペースを把握しやすい。
タイムボックス、スプリント、イテレーション、呼び方は何でも
良いが、期間を区切って使うと便利です。長くてせいぜい1ヶ月くらいです。
■P86 SWEBOKから一つだけ抜粋
あと、SWEBOKから紹介したい小ネタ。
■P87 「瑕疵」
瑕疵についてですが、瑕疵って一言いっても4種類あります。
よく計画たてたり、契約するときに、どっからどこまでが瑕疵なのか
という話になります。
■P88 1．エラー 2．フォールト ～
上から順に。
1.エラー (error)："計算された結果と正しい結果との間に存在する差異"
2．フォールト (foult)："コンピュータプログラムにおける不正なステッ
プ、プロセス、またはデータ定義"
3.故障 (failure)："フォールトが及ぼす[不正な]結果"
4.間違い (mistake)："不正な結果をもたらす人のアクション"
それぞれの意味を補足すると、まずわかりやすい「４．間違い」について
ですが、これはユーザーの操作ミスによって引き起こされる欠陥
（現象といった方が適切だと思うが）であり、運用上の問題です。
「２．フォールト」「３．故障」は場合によってはテスト中、検収中に
発見するのは難しいかもしれません。
プログラムレベルの欠陥が紛れ込んで発生するのが希少な場合は実際に
使ってみるまで発覚しなかったります。
複数の欠陥が偶然重なり合って呼び起こされる場合もあるでしょうし、
ハードウェアの性能向上がもたらす欠陥もあったりします。
個人的には、想定された使用方法の中でおきたフォールトと故障に関して
は瑕疵扱いでかまわないと思います。
「仕様通りに動かない」のであれば「エラー」も瑕疵に含まれるでしょう
が、これはちょっと考えてほしい。
つまり「"計算された結果と正しい結果との間に存在する差異"」はテスト
と検収で十分、発見できるはずであるし、できないのであればその方法に
問題があると言えます。
言い換えれば検収自体がエラーでし、そういった計画を立てたこと自体が
問題です。
一応、検証責任は利用者、発注者側にあるので、お客さまにご迷惑を
かけないように現実的な計画立案を心掛けましょう。
■P89 そろそろまとめ
結構良い時間なはずなので、まとめます。
■P90 プロジェクトは人が為すこと
知識とかモノ的な話を中心にしてきましたが、言ってもプロジェクトを
やっているのは人間です。
■P91 知識も大事だけど、相手の気持ちを推し量ることも大事
知識も大事だけど、相手の気持ちを推し量ることも大事です。
そこで関わる人、メンバーとお客さまに対してどういったスタンスで
望むのが良いか、私なりにお伝えします。
■P92 メンバーに対するプロジェクトマネジメント
まずメンバーに対してですが、
■P93 正しい管理の四つの本質
「正しい管理の四つの本質
1．適切な人材を雇用する。
2．その人材を適所にあてはめる。
3．人びとの士気を保つ。
4．ﾁｰﾑの結束を強め、維持する。
(それ以外のことは全部管理ごっこ)
「デッドライン―ソフト開発を成功に導く101の法則」
トム デマルコ (著), 伊豆原 弓 (翻訳) 日経BP社」
MS-Projectできれいな予実線を引いて、それをメンテナンスすることは
プロジェクトマネジメントではありません。
参加しているメンバー全員で協調的な仕事ができるよう歩み寄りましょう。
■P94 って
って
■P95 （ジャック・スパロウ）
こんなPMの人も言ってましたよね。
■P96 お客さまに対するプロジェクトマネジメント
次にお客さまに対してですが、私なりに腑に落ちた話を紹介します。
■P97 “AgileConference2009”
“AgileConference2009”というイベントで聞いた話が元ネタで、
想い出補正が付いてます。
これはQ&Aコーナーで挙手した人が、スピーカーに、たしかThoughtWorks社
のコンサルタント氏に質問をしていました。
■P98 質問者
「アジャイル型の開発プロセスを導入したいが、日本では請負契約で
ウォーターフォール型の開発が主流となっている。どうすれば良いか？」
これ、実は私も手を挙げようかと思って、ビビって上げなかったんですが
同じようなことを思っていた人がいたんですね。
会場中、よくぞ聞いてくれた、みたいな雰囲気。
■P99 回答者
その質問に対する回答はこの後です。
■P100
そういう問題は私たちも経験している。契約書はテンプレート化されて
おり、現場と接点の薄い調達部門で処理される。よって変えられない。
■P101
しかし、私たちが柔軟な開発を望むように、顧客だって柔軟な対応を
望んでいるのではないか？
■P102
そこで(アジャイルにある)、ショートサイクルリリースを行い、
少しずつ顧客の信頼を得ていくことを心掛けている。
実はこの日、このコンサルタント氏の話って、アジャイルに関して
興味を持って勉強をしている人にはごくごく当たり前の話だったん
ですね。
なんで今更こんな話してんの？ みたいな。
でも、この質問の回答を聞いて腑に落ちました。
つまり「信頼の獲得」には当たり前のことをしっかりやりきること
が大事ですねと。
つまり
■P103 信頼関係の構築
信頼関係の構築。これにつきるよな。と。
しかし、ただやればいいってもんじゃありません。
信頼を得るために何でも言われたとおりに実装すればいい、
とかそういうことではないです。
これも良い言葉があって紹介します。
■P104 １対１もオフェンスの選択肢の～
「１対１もオフェンスの選択肢の
一つにすぎねぇ
それが わからねぇうちは
おめーには負ける気がしねえ」
お客さまの抱える課題を本質的に改善するためには、言われたとおりに
実装するだけじゃなくて、プロジェクトの予算や技術的な実現性も含めて
より良い選択をしていく必要があります。
そうしていくのがプロの開発者であるし、そうしていくためには
■P105 「顧客要求の本質」を掴むことが大事!
「顧客要求の本質」を掴むことが大事になってきます。
つまり顧客をもっと理解しろ、ということですね。
しかし、顧客を理解するのは簡単ではありません。
先ほどの○○BOKでも顧客要求に関連する知識体系はBABOK、SABOK、REBOK
と3種類もありました。
かなり奥深いし、業務を理解しているSEが長生きできるのもそういう
ためです。
しかし日本にはBOK系よりも前から実践されていた優れた手法があります。
それが
■P106 （白本）
要求開発であり、つまり
■P107 次回 「要求開発」編
次回は「要求開発」編になるというわけで
■P108 乞うご期待
乞うご期待、と言い切ったところで、
■P109 完
今日はおしまいです。
■P110 （thankyou mario）
ご静聴いただきありがとうございました。
0 件のコメント:
コメントを投稿