 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| 不十分な業務分析からの低品質／低速のコミュニケーション | ||||||||||
|
筆者自身が主に行ってきたのは、画面や帳票を中心とした業務システム開発です。直接、顧客やユーザと契約を交わして開発したこともありますし、大手メーカの下請けという形、上場企業や官庁の基幹システムの開発に携わったこともあります。 技術者冥利に尽きるのは、例えば上場企業での開発の最後の納品の際に顧客側担当者から「うちも○○さん（元請け）も大きい会社なので、通るかどうかはわかりませんけど、次も深沢さんのところでといいますからね」といっていただいたり、某官庁の開発を評価いただいた結果として、年に1回の全国のシステム担当を集めての研修で講師をやらせていただいたりしました。 別に自慢話をしたいわけではなく、これらのように極めて上手く行ったプロジェクトで共通している点は、筆者自身が仕様策定者として必要なだけの徹底的な業務分析を実際にやらせる、という「顧客側の決断があった」ということです。この決断がなければ、筆者が必死に頑張ったところで、うまくいかなかったでしょう。 うまく行かない大抵のプロジェクトは、初期段階で実作業者らに対し、説明なく何らかの書類だけを渡して「読んでおいて」となり、暫く期間が空きます。 筆者自身がプロジェクトマネジャーの立場で、誰かに読んでおくべき文書を渡すとするならば、間違いなく次のステップを踏みます。
表1：文章を渡す際のポイント つまり、自分のチームメンバーに対しても、何ら説明なく書類を渡すようなことはないようにしています。人それぞれで、過去の経験／学んできたこと／考え方などが違うわけですから、同じ文章を見たからといって、全く同じように理解することはあり得ません。 ましてや、顧客と直接接していない、現場も見ていないという状況に置かれていて、文書だけで具体的に正確なイメージができるかというと、難しいというよりほぼ不可能なはずです。何より、文書だけで表現できることは少ないですし、そもそも記述が正しい、あるいは記述の通りに行動しているという保証は実はどこにもありません。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
