 |
■上司に恵まれないＳＥのために−自分戦略策定マガジン メルマガの発行者は、「ＰＭＢＯＫ準拠ＩＴプロジェクトマネジメント テキスト」（ＪＰＭＦ）なども共著されている プロのSIer（エス・アイアー：企業のための情報システム構築者）である中村文彦さん。「Ａｌｌ about Japan」のインタビュー記事 を拝見させていただくと、ＳＥの方々の「不器用さ」が好きになり、特に上司に恵まれない不運なＳＥを元気付けるためにメルマガを発行されているとのこと。面白い！ 「みんなを幸せにするＳＥ」になるためには「聴く力」が最も大事、というのも同感！です。中村さんの運営されているＳＥ支援サイト「メンターピン･コンサルティング」をリンクページに掲載しました。 |
| ＜上司に恵まれないＳＥのために−自分戦略策定マガジン＞ [No.030]「あきらめの壁」をぶち破れ！（2003.12.11） ●今年一番のお薦め本に出会いました 久々に感動的な本に出会いました。 その本のタイトルは、「あきらめの壁をぶち破った人々」です。 買ったその日に、一気に読んでしまいました。 今年読んだ本の中では、間違いなくベストワンのお薦め本です。 「あきらめの壁をぶち破った人々」 http://www.amazon.co.jp/exec/obidos/ASIN/4532311004/mentorpincons-22 この本は実話に基づく小説で、大手製薬会社を舞台にした情報化推進プロジェクト推進が題材です。 硬直化し、まるで全身を生活習慣病に侵されているような組織が、改革プロジェクトを推進する主人公の活躍によって活力を取り戻すプロセスが描かれています。 プロジェクトの行く手には、事なかれ上司やパワーハラスメント上司等、数々の困難や障害が現れます。 それらの幾多の壁にぶちあたりながら、プロジェクトリーダーである主人公とプロジェクトメンバー達は、その壁をぶち破っていきます。 そして遂には、この困難なプロジェクトを成功させる感動のドラマです。 当メルマガの読者であるＩＴエンジニアの方々にも是非読んで欲しい本です。 この本からは、実に多くを学べます。 （１）プロジェクトマネジメント実践のケーススタディになります。 ＩＴプロジェクトの場合、単にシステムを開発するというだけでなく、業務プロセスや意識改革をともなうことが多いのは、ご存知の通りです。 そのためＩＴプロジェクトを成功させるためには、人の心を動かし行動を変えるという点が重要になります。いわゆるヒューマンスキルやコンピテンシーが必要となるのです。 この本は、リーダーシップやコミュニケーション等、プロジェクトマネジメントにおけるヒューマンスキルやコンピテンシーの実践の書です。 この点に問題意識のある方であれば、多くの「気づき」を得ることができるでしょう。 （２）上司に恵まれない方にとっては数多くのヒントがあります。 この物語には、たくさんの問題上司が登場します。 主人公は、そのような上司に対してリーダーシップを発揮することで、これらの上司との問題を解決していきます。 上司との関係に悩むＳＥにとっては、共感する場面やヒントとなるエピソードがたくさんあります。 （３）改革プロジェクトの意味と全体最適を実感できます。 改革を目的とした情報化プロジェクトが顧客企業にとって、どのような意味を持つのか、また全体最適とは何かを実感することができます。 これは、プロジェクトを委託される側にいる私達には、頭では理解できても、なかなか実感できないことです。 顧客の立場や視点を理解する良い機会になります。 （４）プロジェクト推進のヒント 主人公の会議の進め方やコミュニケーション・ツールの活用方法等、私達のプロジェクトでも参考になる実践的手法が、数多く紹介されています。 以上、私自身が感じたことを上げてみましたが、皆さんであれば、もっと多くのことを読み取れるかもしれません。 |
| ●改革プロジェクト推進のポイント プロジェクトを進める点において、私が共感し参考になった箇所を紹介します。 （１）組織に問題を認知させる 舞台となった製薬会社は様々な問題があるにも関わらず、それを不問にしています。 問題があることを明確にすれば、誰かがそれをやらねばならず、そのための体制づくりやコストも発生するため、誰もが思考を停止させ行動をおこさないのです。 私達が所属する組織にも、多かれ少なかれ同様の状況があるのではないでしょうか。このような時に、私達はどのような行動を起こせば良いのでしょうか。 主人公は、この状態を打破するためにボランティアからなるランチタイムミーティングを開催します。ここで自分達の組織にある問題点を顕在化させ、上層部にその解決を提案することで、問題点の所在を公式に認めさせます。 この時点から、縦割り組織を横断し医薬品申請プロセスを改革するための『文書管理システム開発プロジェクト』がスタートします。 （２）正式名称は範囲を規定する 『文書管理システム開発プロジェクト』の発足にあたって主人公は、正式名称にこだわります。 プロジェクトの名称が、その範囲（スコープ）を規定するという考えがあるからです。 主人公は、以前『勤怠管理システム』の開発に従事した経験があります。 その時は、上位の役職職から様々な要望が出てきて事態を収拾するのに苦労しました。 主人公は、その原因の一つに『勤怠管理システム』という名称があったと分析しています。何でもできそうな名称が、システムのコンセプトを不明確にしてしまったという反省です。 主人公は、『勤怠管理システム』という名称を途中から、『電子出勤簿』に変更し、よけいな雑念が入らないようにします。 この経験を踏まえて、『文書管理システム開発プロジェクト』の正式名称は『申請文書業務改革プロジェクト』に決定されます。 ＩＴプロジェクトの提案段階において、企画を通したいがために、ついつい何でもできそうな名称をつけてしまいがちです。 そして、その後で膨らむユーザの期待を収拾できなくなってしまうのはよくある話ですね。 このエピソードには、私も反省しました。 （３）略称は判断基準となる 主人公は正式名称だけでなく略称にもこだわります。略称によってプロジェクトの判断基準を表すべきという思いがあるからです。 プロジェクトメンバーが単純で明確な判断基準を共有することで、同じベクトルに対し足並みをそろえ、組織効率を最大化できるようになるというわけです。 私達のプロジェクトには、単純かつ明確な判断基準はあるでしょうか。 最優先すべき項目は、ステークホルダー（利害関係者）の間で、共有されているでしょうか。 プロジェクトの略称で、その判断基準を明確にするというのは、実践的で優れた方法だと思います。 （４）やらされる側の心のコップ 『申請文書業務改革プロジェクト』は立ち上がりましたが、各部門代表で参加したコアメンバー達の動きは、組織の壁もあって、本腰ではありません。自覚的なメンバーほど、その壁にもがくことになります。 この状況を打破するために、主人公はコアメンバーの本音や愚痴をコンサルタントの女性にヒアリングさせます。 この行為に対して仲間から、「コアメンバーが言っていることは甘えにすぎないし、聞くことがその甘えを助長しているように思われる」という意見が出ます。 この意見に対して主人公は、「人間は意義と重要性をインプットすれば行動が変わるロボットではない」と反論します。 そして、「やらされる側が何か新しいことに取り組む時には、心のコップにストレスという水がたまってしまう。誰かがその水を受け止めてコップの中をいったん空にしてあげないと、新しい価値観は受け入れられない」と説明します。 私たちは他人に何かを変えてもらおうとする時に理論で説得しようとしてしまいがちです。まず相手の感情を理解し受け止めてなければ、どんな正しい理論も受け入れてもらえないということを忘れてはいけません。 この箇所は、改革プロジェクトを進めた経験のある方であれば、深く共感できると思います。 （５）聴くべきは現在のユーザの声でなく三年後のユーザの声 『申請文書業務改革プロジェクト』が運用準備段階に入ると、ユーザから様々な不平不満が発生します。 運用の責任者はユーザの声を大事にする人で、ユーザの不満の解消を最優先にしてシステムを変えようとします。 これに対して主人公は、ユーザの声を重んじるのは大切なことだが絶対に変えてはいけないシステムのポリシーがあることを訴えます。 運用責任者が毅然とし、現場でユーザとの攻防に踏ん張っている運用担当者をバックアップすべきだと主張します。 そこには「妥協することによって、変えるべき現実を延命させてはならない」という主人公の固い決意があります。 主人公は、この運用責任者に大して、聴くべきは現在のユーザの声でなく三年後のユーザの声であることを説明します。 これは、私達の周りにも、よくある話ですね。 新しいシステムを導入した時には、必ずユーザからの抵抗が発生します。 もちろん、こちらの意見を一方的に押し付けてはいけないのですが、どうしても譲れないポリシーのあることを忘れてはいけません。 その時は、「聴くべきは現在のユーザの声でなく三年後のユーザの声」という主人公の言葉を思い出すことにしましょう。 |
