‘ドキュメント’ カテゴリーのアーカイブ
2009 年 1 月 7 日 水曜日
タイトルの通りなのですが、みなさん
「インフォーマルコミュニケーション」ってご存知ですか?
最近ではオフィスレイアウトを考えるときにも取り入れられたりします。
インフォーマルコミュニケーションのイメージをお伝えすると、
・会議中に話し合いをする ⇒ フォーマルコミュニケーション
・喫煙室でたまたま会った人と話す ⇒ インフォーマルコミュニケーション
といった感じで、
「前もって予定されていないフェイスtoフェイスの会話やコミュニケーション」をいいます。
最近弊社でもグループウェアのブログ機能を通じて情報共有がされるようになったのですが、
全く別の部署の人が何をやっているのか、何を考えているのかが見えるようになって
とても面白いなーと思いました。
フェイスtoフェイスではないですが、
これも広い意味でのインフォーマルコミュニケーションと考えています。
プロジェクトメンバーとのコミュニケーションも、いつも会議室で行うのではなく、
わざとインフォーマルな形式で行ってみると、普段は見えない得意分野や性格が
見えるかもしれません。
皆さんも取り入れられてはいかがでしょうか。
—-
タグ:コミュニケーション
カテゴリー: ドキュメント, プロジェクトマネジメント | コメントはまだありません »
2008 年 12 月 18 日 木曜日
最近お客様やプロジェクトメンバーをはじめ、
いろんな人から質問をされることが多いのですが、
いつも相手に確認したいと思うのが
「どこまで理解できているのか?」
という部分です。
全体を10とすると、9まで理解できていてあと残り1なのか、
全く理解できてなくて0の段階なのか、
それをまず説明してほしいなーと思います。
それによって言い回しや説明にかける時間、
そのときに説明したほうがいいのか、別の時間を確保して
説明の機会を設けたほうがいいのか、
いろんなパターンがあります。
あまりにも質問の数が多いと、個別に回答するのが
煩雑になるので「質問確認会」
を開催する場合もあります。
「何を知りたいのか」はだいたい僕も質問されたら分かるのですが、
「どこまで理解できているのか」は言われないと分かりません。
質問をするときは相手の時間をもらうので、
「自分が理解できている範囲をまず伝え、その後に質問をする」
を心がけましょう。
—
カテゴリー: ドキュメント, プロジェクトの現場から, プロジェクトマネジメント, 基本設計 | コメントはまだありません »
2008 年 12 月 9 日 火曜日
お客様はプロジェクトメンバーがどれだけがんばっているのか、
というのはなかなか分からないものです。
働いている拠点が違っていたりして、WEB制作やシステム構築の現場の実態は
リアルには想像できないですから。
「メンバーが提供している価値をお客様へ最大限アピールする」
部分はプロマネの腕の見せ所と考えています。
実力以上にアピールする必要はありませんが、
正しく自分のチームを評価してもらうことは重要だと考えています。
たとえば、、
・お客様のためにメンバーが夜遅くまで対応をしていたり
・お客様からの要望を上回る結果をメンバーが出したり
・お客様のミスをメンバーが自発的にフォローしていたり
というような縁の下の力持ち的なメンバーって必ずいますよね。
その努力、がんばりってそのままにしておくとあまりお客様には
伝わらないものだと思っています。
そこはプロマネがきっちりメンバーのかげの努力を伝えられるように
ならないといけません。
メンバーにとってお客様からの感謝の声が一番のモチベーションの源泉です。
メンバーのがんばりをお客様へアピール
↓
お客様から「ありがとう」をたくさんもらう
↓
メンバーへお客様からの声をフィードバック
(もしくはお客様と交流する場をセッティング)
このサイクルを回し続けるとどんどんいいプロジェクトになります。
長期的な友好関係はこのようなサイクルから生まれます。
–
タグ:アピール
カテゴリー: ドキュメント, プロジェクトマネジメント | コメントはまだありません »
2008 年 11 月 26 日 水曜日
やさしさには
①甘いやさしさ
②厳しいやさしさ
の2つがあると思っています。
たとえ話で説明します。
幼稚園の運動会でかけっこの途中で園児が転んだとします。
園児が自分ひとりでは立ち上がれず、ワンワン泣いているときに
①すぐに走っていって助けてあげる保母さん
②自分の力でゴールまで走りきってほしいと思って助けてあげない保母さん
前者は甘いやさしさで後者は厳しいやさしさだと思います。
プロジェクトメンバーが困っているときに、
すぐに助言をして解決案を出すのは甘いやさしさ、
自分の頭で考えて解決案を出してもらい、わざと助言しないのが厳しいやさしさ、
だと思っています。
社内で気難しいと言われている人が、本当は一番やさしさのあふれた人だったりします。
プロジェクトマネージャーにとってやさしさは必要不可欠なものなのですが、
その使い方には気をつける必要があります。
–
タグ:やさしさ
カテゴリー: ドキュメント, プロジェクトの現場から, プロジェクトマネジメント, 基本設計 | コメントはまだありません »
2008 年 11 月 14 日 金曜日
すごーく知識が豊富で頭の回転が速い人と話をすると、
こっちがついていけなくて、「????」となることがあります。
「あー、理解できなくてごめんなさい」と感じちゃいます。
でも自分も知らず知らずのうちに伝えたいことだけ
伝えて終わっていて、相手は「????」状態のことが
あるかもなー、とも思います。
誰でも自分が得意な領域と不得意な領域があるので、
分からない(理解できない)状態というのは当然あると思っていて、
それは伝える側にも責任があると思う今日この頃です。
「何で分からないの?」という姿勢ではなく、
相手が「分からないことを分かる(理解する)」
自分が分からない側になることもあるので、
そのときの気持ちを忘れずにいきたいと思います。
もうこの歳になるといきなり天才にはなれないですから。
分からない自分のことを分かる、ってのも大切です。
–
カテゴリー: ドキュメント, プロジェクトマネジメント | コメントはまだありません »
2008 年 11 月 5 日 水曜日
以前は「結果論」と「結果が全て」の2つは
全く違うことだと思っていました。
イメージとして、
■結果論 ⇒ 終わってからこじつけで理由を考えて結果を正当化するイメージ
( どちらかというと悪いイメージ )
■結果が全て ⇒ 過程(プロセス)は関係なく結果を出した人が正解というイメージ
( どちらかというと良いイメージ )
のような感じでとらえていました。
でも最近はその考えが変わってきて、
「結果論」と「結果が全て」は結局同じことなのでは?と思うようになりました。
なぜそうなったかというと、テレビで会社経営者のインタビューを見たり
著名な方の本を読んでみると、確かに言っていることはもっともなのですが、
「同じ方法で失敗した人もいるのでは?」
と同時に思ってしまうのです。
これはオリンピックで金メダルを取った人が何を語っても「やっぱりすごい!」
とマスコミから評価されるのですが、星野JAPANのように結果を残せなかった場合、
「選手村に入らず五つ星のホテルに泊まるとはなにごとだ!」
とバッシングがされます。
結果が全てだし、でも結果論でもあるよなー、と思ってしまいます。
言い方を変えると、結果を出さなければ全てが言い訳っぽく聞こえてしまうし、
結果が伴うと、言っていることの説得力が増します。
プロジェクトの進め方にも
要件定義⇒設計⇒開発⇒テスト⇒リリース
といった王道の進め方がありますが、
「結果が全て」の視点に立つと、最後のリリースが問題なく実施できればOKとなります。
そして成功したらそのプロセスを大いに再利用し、「結果論」を語りながら次も成功させればいい。
失敗したら言い訳せず成功するにはどうすればいいか、を突き詰めればいい。
世の中結局は「結果論」であふれていて、王道なんて存在しない、
と考えると、プロジェクトマネジメントにも幅が出ると思っています。
–
タグ:結果が全て
カテゴリー: ドキュメント, プロジェクトマネジメント, 基本設計 | コメントはまだありません »
2008 年 10 月 20 日 月曜日
さて、今日は弊社の社員にブログに書いてほしいネタを聞いてみました。
そこで出たお題が「仕事に取り掛かる上で何を考えて始めるのか」です。
これ、重要ですね。
ではズバリ何を考えているかですが、
その仕事で「成果が出た」状態はどんな状態かを考える、ですね。
・売上が上がった
・コストが下がった
・お客さんが喜んでくれた
・次のフェーズの契約が取れた
等々色々とあるのですが、自分の中で「成果」を定義します。
その次に、成果を80点、100点、120点の3段階くらいに分けます。
・80点 ⇒ 必ず達成しなければならない成果
・100点 ⇒ お客様に喜んでもらえる成果
・120点 ⇒ お客様に驚かれる成果
のイメージです。
もちろん狙うは120点です。
80点と100点の違い、100点と120点の違いはどこから来るかと言うと
ちょっとした気遣いだったり、自分のがんばりだったり、メンバーの協力だったりします。
いかによく考えて行動したか、ともいえます。
プロジェクトが終わったときにお客さんが
100点の成果だったら拍手をしてくれます
120点の成果だったらスタンディングオベーションをしてくれます
一度スタンディングオベーションを味わうと、必ずもう一回味わいたいと思います。
オーケストラやオペラの出演者の気分ですね。
120点の成果は成功体験となり、1度成功体験を得た人は、また次の成功体験を
得るためにがんばります。
同じやり方では満足できず、またさらに創意工夫を持って仕事に取組みます。
といったことを考えて、仕事に取り掛かってます。
自分だけでなく、メンバーにも成長してもらうには、
成功体験を得てもらうのが一番いいと思います。
—
タグ:成果
カテゴリー: テスト, ドキュメント, プロジェクトマネジメント, プロジェクトマネージャー | コメントはまだありません »
2008 年 10 月 7 日 火曜日
「強かさ」
これ、何と読むか分かりますか?
僕も最初漢字でこう書くのは知らなかったのですが、
「したたかさ」と読みます。
辞書で意味を調べたところ、
1 粘り強くて、他からの圧力になかなか屈しないさま。しぶといさま。「世の中を―に生きる」「―な相手」
2 強く、しっかりしているさま。「―な後見役」「―な造りの家」
3 強く勇猛であるさま。
だそうです。
プロジェクトマネージャーは”したたか”でないといけないですね。
ここでのしたたかは辞書どおりの「強い」にプラスして、
「しぶとい」「一筋縄ではいかない」というイメージも含みます。
時にはステークホルダーとのハードな交渉を強いられる場面もありますので、
そういうときには、ポジティブさや責任感だけではなく、したたかさ
という部分が重要になってきます。
ビジネスの場では「いい人」だけでは成り立ちません。
外部と折衝する仕事は「したたかな」人間なら安心して任せられます。
なかなか伝えるのは難しいのですが、重要な要素だと日々感じます。
私が以前いた会社では、「明るく、元気に、したたかに」
というスローガンがありました。
よく考えられているなー。と思います。
—–
タグ:したたか
カテゴリー: ドキュメント, プロジェクトマネジメント, 基本設計 | コメントはまだありません »
2008 年 9 月 5 日 金曜日
最近本当にコミュニケーション能力って大事だなーと痛感しています。
・お客様の要望を開発エンジニアに伝える
・プロジェクトの状況を社内で共有する
・新規営業先にECサイトの仕様を説明する
日々コミュニケーションの連続です。
そのときの僕の心がけは、
「まず前提を合わせること」
です。
・開発エンジニアはお客様の業務を知りません
・社内メンバーは僕のプロジェクトの内容をよく知りません
・新規営業先はそもそもECという言葉を知っているかわかりません
まず何より自分の言いたいことを伝えるよりも、
「相手と自分の前提は合っているか?」
を先に考えます。
その考えがあると
・どこまでさかのぼって話をするべきか
・どのような言葉を選んで伝えればよいか(専門用語は避ける)
・相手が分かりやすいたとえ話はないか
というところに意識が向きます。
たまに仕事で、コミュニケーション能力の高い人に出会うと、
その人はまず前提を合わせることに注力していることに気づきます。
「要件の前にまず前提から」
コミュニケーションの基本中の基本ではないでしょうか。
–
タグ:コミュニケーション
カテゴリー: ドキュメント, プロジェクトマネジメント | コメントはまだありません »
2008 年 8 月 21 日 木曜日
プロジェクトマネージャーは視野が広くなければなりません。
また、物事を色々な角度から判断しなければなりません。
バランス感覚が非常に重要です。
たとえば、、
・Aさんのコメント:「あの人は意志が強い」
・Bさんのコメント:「あの人は頑固だ」
この場合、Aさんはポジティブな視点で「あの人」を判断し、
Bさんはネガティブな視点で「あの人」を判断しています。
プロジェクトマネジメントでも
・もしうまくいけば、、、(ポジティブ視点)
・ここがリスクなので、、、(ネガティブ視点)
といったように、視点を切り替えて判断していく局面がたくさんあります。
1つの視点にこだわっていると、最適解を見失うので、
わざとこれまでの考え方を捨てないといけない場合もあります。
・「優柔不断」と「思慮深い」
なんていうのは、まさしく視点の違いだけで、
どちらにも取れるものです。
・人に接するとき
・課題の解決策を考えるとき
常に2つの全く異なる視点を持っていると、
よりプロジェクトの成功確率が高まるのでは?と思ってます。
–
カテゴリー: ドキュメント, プロジェクトマネジメント | コメントはまだありません »