 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||
|
||||||||||||||||||||
| 会議のモチベーションを考える | ||||||||||||||||||||
|
「顧客側のモチベーション」と「開発側のモチベーション」があります。まず「顧客側のモチベーション」ですが、開発側ができることとしては、日頃から「滑舌よく、明るく」話をするという、当たり前のことが基本です。 そして、「顧客業務の徹底理解」「ユーザの現場」といった情報と「開発の現場」の情報を組み合わせて、できることはできる、できないことはできないと、明確に根拠を持って納得が行くまで説明します。 もっと細かくいえば、「どういう条件が揃えばできるとか、どういう前提条件でできるといっている」「全部はできないが、運用をこのように変えて、システムをこう変更すると、期待の80%は実現できる」、あるいは、何らかの見通しを示して、調査期間をもらうなどの様々な考え方ができます。 そうすれば、顧客側としても「ここまでできるのであれば、それでよしとしましょう」「これはダメでもこれができるなら、よいかもしれない」などと思ってもらうことも可能となり、「そういうことならば、これだけの期間延長はよしとして、やってもらおうか」「それなら、この分コストを多くかけてもよいだろう」など、少しずつ提示できる条件も増えてくると思います。 これは、顧客側は待ちの姿勢でいてよいという意味ではありません。開発側には、どれだけの前提条件が変更できるのかということがまったく見えない場合もありますから、顧客側から「この前提条件が、このように変えられれば、目的を達成できるだろうか？」などのアイデアの糸口を提案するなど、できることはいくらでもあります。 過去にスムーズに運んだプロジェクトは、プロジェクトに接する顧客側の人々が建設的、前向きであったことが、その大きな要因だったと考えています。顧客側の建設的な姿勢がなければ、開発側がいくら人材を揃えて頑張ったところで、プロジェクトを成功させることはできません。 |
||||||||||||||||||||
| 「できないこと」を曖昧にしないために | ||||||||||||||||||||
|
開発側が「できないこと」を曖昧にしていると、「できる」といっていることも顧客側に信用してもらえなくなります。目に見えるものを作っているわけではありませんので、顧客側としては開発側の窓口となっている人の態度などから、できあがってくる成果物の信頼度をおしはかるしかありません。ですから、顧客の立場に立って少し考えれば、「できないことこそ、曖昧にしてはならない」ということがわかるはずなのですが、どうしてもマイナス要因をいいにくくなるということも事実です。 このような場合、許されたコストや時間で可能な調査など、できることは行って自分たちなりの見解や代替案などを準備して、その表現をじっくり考え（スペックパターン開発プロセスでは、基本的に「仕様策定者」とプログラマの代表である「インプリメント・リーダー（IL）」の２名で行います）、正面から向かっていくことを考えましょう。ほとんどの場合、顧客側からの協力が得られるなど、よりよい状態へ向かうものです。 開発側のマネージャーや仕様策定者としては、自分たちの配下で働く開発側の者のモチベーションを考えるよりも前に、自分自身と顧客側のモチベーションを考える必要があります。本連載を時間をかけて読んでいる読者であれば大丈夫だと思いますが、正直なところ、開発側のマネージャーやマネジメントも行っている仕様策定者たちが大したモチベーションを持っていないということが、失敗するプロジェクトの大きな原因です。 というのは、これまで様々な問題に遭遇してきた進め方を、「そんなもの」と、最初から改善しようともせずに、そのままやっていることもあるのです。それは、上司から文句をいわれない程度に、会社として最低限やらなければならないことだけを行い（例えば、あってもなくても意味がないとわかっているドキュメントをとにかく揃えるとか）、それで上手くいかないのであれば、「まぁいいか」と諦めてしまう考え方です。 一方、一緒に仕事をしている人々や上司に「何としてでも、今回はこの問題を起こさないようにしたい」とやる気をみせれば、メンバーは様々なアイデアをだしてくれるかもしれないのに、それすらしていなかったりします。「マイナス要因について見解・代替案を準備し、表現を吟味した上で、正面から向かっていく」という当たり前のことが意外と行われていないのです。 確かに当たり前のことでも、実際にやろうとするとなかなかむずかしいものです。いつもと違うことをやって上司に何かいわれそうだったり、配下に面倒くさがられたりしそうだからとか、様々な理由があると思います。 これは、元をたどると組織の上層部が何をもって仕事やマネージャーを評価しているのかということにつながります。 立場が違うことによって少し行動などへの表れ方が違ってきますが、「組織の上層部の評価、考え方によって言動が決まってくる」という事実は、顧客側担当者や承認者も同様です。 複数の会社から数名ずつ要員が参加しているプロジェクトでマネジメントを行うと、物事の見え方や考え方、仕事に対する姿勢など、個人のキャラクタがまさに会社ごとにまとまっていることがわかります。 ですから、デミング（品質マネジメントの世界的権威）のいう「品質コストの85%はトップマネジメントの直接の責任である」という言葉は、まさに言い得て妙と感じることがしばしばです。 同様に「組織成熟度」という視点も極めて的確だと思います。多くの場合、会社など組織の単位でプロジェクトが頻繁に火を噴くか、ほとんどが問題なく完了するかが明白に分かれます。 著者自身は自衛官として「考えなくても体が動く」的な教育を（とても明示的に）受けました。組織の目的から見て必要なことだという実感です。だからこそ、余計に感じるのかも知れませんが、読者の皆さんには意識しないうちに自分自身の考えではないまま、「成功できない進め方でしか脳と体が動かない」ということになってしまわないよう、気をつけていただきたいと思います。 「もっとよい方法があるのではないか？」「今の感情の本当の理由は何か？」「自分はどうありたいのか？」「上手く行かない方法しか知らないまま、一生を終わるのか？」など、常に自問自答を意識しましょう。 次回は「会議の現場」での「開発側のモチベーション」をどのように考えるかということなどを紹介します。 |
||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
