 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 最初の理解の重要性 | ||||||||||
|
何かしらの事柄について、最初に理解したことを後から切り替えるというのは、意外と大きなエネルギーを必要とします。勘違いに気づいても、最初の理解がどうしても先にでてきてしまい、過ちを繰り返してしまうというのは誰にでもある経験です。よく見ていると自分には甘く、配下には厳しく、ということを「常識だから」「自分もそうさせられてきたから」と、あまり深く考えずにやっている場合が多いようです。 ですから、最初から「顧客に確認済みの正確な理解」をチームメンバーと共有できるようにします。これは、後々の自分自身の仕事をなるべく増やさないためにも必要です。筆者自身は、「PMIが重要視している、Proactiveというのは、こういうことだよな」と思っています。 プロジェクトのあらゆる局面で、「最初から正確に」を実現しやすい手順を考えることは、極めて効果が高いという実感です。逆にいえば、「曖昧なままのことは、なるべく取りかからないようにうまく進める」必要があるともいえます。ハッキリさせることを最優先としたアクティビティを柔軟かつ明確に割り込ませ、具体的な作成の工程に「何となく入って」しまって、その中で「何となく解決しようとする」ということは阻止します。 「最初から正確に出来る手順を考える」ことは、品質マネジメントの観点やコストマネジメントの観点から見ても、大きな効果があります。この考え方は、「品質は計画、設計、作り込みによって達成するものであり、検査によってではない」という考え方に合致しますし、「是正コストは通常、予防コストを遙かに上回るものである」という考え方からみても重要です。何よりもそのまま「計画を重要視する」というPMIの考え方に合致します。 IT業界で良く耳にする「仕様変更は当たり前」とはまったく逆です。「仕様変更」は、仕様策定者にとって、プログラマでいう「バグ」です。せめて「仕様変更はゼロを目指す。ただ、どうしてもでてきてしまうことがある」程度に考えなければなりません。 業務分析にシッカリと時間を費やして正確な理解をし、それをなるべく時間的な厚みをとって、丁寧にチームメンバーに伝えれば、以降の顧客を含めたプロジェクト全体のコミュニケーションの品質や速度はとても高いものになって、あらゆることがうまく運びます。業務分析という、最初の工程からですから、とにかく高い効果が得られます。 過去経験したプロジェクトで、1ヶ月前からプロジェクトに入っていて、文書を読んでいるというメンバーに、パッと思いつく質問をしても、何一つ満足に答えられないという状況がありました。もちろんその人の責任ではありません。プロセスの問題です。多くの場合、どうしても顧客側システム部は、顧客側現場ユーザの手を煩わせたくないという意識が働きます。これは仕方のないことです。 「手伝ってくれるなら見学しても良いといっていたよ」という言葉尻をつかみ、「手伝いますから見学させてください」といって、半ば無理矢理現場に行って、一番最初に現場の責任者にいわれたのは「現場に来てくれて、ありがとう」という言葉でした。顧客側担当者の監視の下、実データで実業務をやらせていただきました。 余程のことでない限り、録音や画面ダンプを全て落としながら3日もあれば、かなりの業務が押さえられます。どの業務が面倒でどの業務は他のどの業務と関連があるか、紙で出力しないと効率が悪い業務は何か、それは改善が可能かなどと書面では全く解りようのない情報も得られます。実際に行われている作業が全て顧客にとって正しいとは限りませんから、もちろん注意が必要ですが、そもそも文書だけでそこまでの理解に到達すること自体が至難の業です。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
