TOP
＞
プロジェクト管理
＞ 不十分な業務分析からの低品質／低速のコミュニケーション
PMBOK2000と比べて覚えるPMBOK第3版
第４回：より、成功確率を高める記述になったPMBOK第3版
著者：
イマジンスパーク 深沢 隆司
2006/10/11
1
2
3
次のページ
不十分な業務分析からの低品質／低速のコミュニケーション
筆者自身が主に行ってきたのは、画面や帳票を中心とした業務システム開発です。直接、顧客やユーザと契約を交わして開発したこともありますし、大手メーカの下請けという形、上場企業や官庁の基幹システムの開発に携わったこともあります。
技術者冥利に尽きるのは、例えば上場企業での開発の最後の納品の際に顧客側担当者から「うちも○○さん（元請け）も大きい会社なので、通るかどうかはわかりませんけど、次も深沢さんのところでといいますからね」といっていただいたり、某官庁の開発を評価いただいた結果として、年に1回の全国のシステム担当を集めての研修で講師をやらせていただいたりしました。
別に自慢話をしたいわけではなく、これらのように極めて上手く行ったプロジェクトで共通している点は、筆者自身が仕様策定者として必要なだけの徹底的な業務分析を実際にやらせる、という「顧客側の決断があった」ということです。この決断がなければ、筆者が必死に頑張ったところで、うまくいかなかったでしょう。
うまく行かない大抵のプロジェクトは、初期段階で実作業者らに対し、説明なく何らかの書類だけを渡して「読んでおいて」となり、暫く期間が空きます。
筆者自身がプロジェクトマネジャーの立場で、誰かに読んでおくべき文書を渡すとするならば、間違いなく次のステップを踏みます。
顧客側担当者と最初に会った際に、「そもそも何で、このシステムを開発することになったのかを、一言でいうとどんな感じなんでしょう？」など、概要レベルの顧客側の背景と共に開発をはじめることになった（公式だけではなく非公式の）要因を可能な限り聞きだす
初回の会合とはいえ、ただ単に挨拶だけをして帰るのではなく、現行システムまたは業務について説明をしてもらう
説明の際には、可能であれば実際に操作を行っている人を呼んでもらって、開発の中心となる業務について、実際の伝票などもできる限りの情報を実物ベースで受け取り、改善したい現行業務の問題点などをより具体的に理解する（これをアバウトにしたまま、かなり先の工程まで進めてしまうプロジェクトマネジャーやSEが意外と多いようです。実は何をするのか、具体的にイメージできていません。細かい質問をすると発覚します）
資料をチームメンバーに渡す際には、必ず時間を取って、それまでに得ている情報と自分自身がどう進めていこうとしているのか、資料については特に重要な部分を中心に、時間の許す限り細部にわたって説明する
表1：文章を渡す際のポイント
つまり、自分のチームメンバーに対しても、何ら説明なく書類を渡すようなことはないようにしています。人それぞれで、過去の経験／学んできたこと／考え方などが違うわけですから、同じ文章を見たからといって、全く同じように理解することはあり得ません。
ましてや、顧客と直接接していない、現場も見ていないという状況に置かれていて、文書だけで具体的に正確なイメージができるかというと、難しいというよりほぼ不可能なはずです。何より、文書だけで表現できることは少ないですし、そもそも記述が正しい、あるいは記述の通りに行動しているという保証は実はどこにもありません。
1
2
3
次のページ
著者プロフィール
株式会社イマジンスパーク 深沢 隆司
株式会社 イマジンスパーク 代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。
INDEX
第4回：より、成功確率を高める記述になったPMBOK第3版
不十分な業務分析からの低品質／低速のコミュニケーション
最初の理解の重要性
解らないことが解らないままの計画
