| 顧客との懸案管理の共有化を常に行う。 |
光広 章文様 |
| 現在のプロジェクトではほとんど管理業務がありません。ですので個人的にこまめに周りとコンタクトをとって仕様や段取りの行き違いがないよう意識しています。 |
わんぱくボリス様 |
| 色々試しているが、良い方法が見つからず。模索中です。（会議開催、アフター5、立ち話などんど） |
カッキ-様 |
| 口頭でのやりとりは絶対に行わない。紙に落とし、双方で認識のズレがないかどうかを確認し、次に進める。当然の事ながら、タイムスケジュールも確認することが肝。 |
回答なし |
| 情報を常に表出化させるようにしている（まとまってから開示ではなく、なるだけこまめに）また重要なポイントが伝わるように1〜３つに要点を絞って伝えるようにしている |
Bon様 |
| ●できるだけ迅速に報告することを心がけています。また、コーチングを学ぶことにより、以前に比べ、●意思の疎通が良くなったように感じています。●報告書はマインドマップを使い、人目で理解できるようにしています。 |
うしがえる様 |
| やっぱり、コレ！という連絡は、メールでなく、対面か電話にすることですね。単純ですが、これが一番です。 |
ながと様 |
| webフォーラム（掲示板）の活用。会議召集にて１から話し合い無駄な時間をすごすより、ある程度意見を出してもらい会議の席では意思決定や更なる詳細決定などを行う。 |
原敬様 |
| 接触の機会を増やすにつきる。忙しいなら忙しいなりに、何が原因か？の情報収集を行い、各チームの情報を統合する事により、全体の問題点／課題を見出す。 |
lupon様 |
| ＰＭとメンバー、メンバー間で、些細なことでも声を掛け合うということを促しています。朝の「おはよう」、少し行き詰まった時の「ねぇねぇ、ここちょっと」という具合に。今年に入ってから、中国のソフトウェア会社と共に仕事をしましたが、この時には、相手が話をし易いように言葉を掛け合うように工夫しました。 |
なおぽん様 |
| まずコミュニケーションという曖昧な言い方をしない。コミュニケーションは一般的に理解されている「ヒューマンリレーション」の意味で使い、情報の伝達・共有は「インフォメーション・マネジメント」と名づけてプロジェクトの明確な管理対象という共通認識をメンバーが持てるようにする。 |
佐々木様 |
| コミュニケーションをとる相手の状況(時間、スキル)に合わせて、話法を変更しています。時間(多：オープン話法、中：クローズ話法、小：ヒアリングシートを用いて５分以内に完結させる話法)スキル(例えば、コミュニケーション対象者に、ITスキルレベルの差がある場合は、プレゼンに段階を設け、時間の節約と関係者への周知に配慮しています) |
エ-ソゥチオン様 |
| メイルよりは電話。さらに、電話よりは直接相手のところに自分から出向く。 |
まさき様 |
| 掲示板を使用してプロジェクトメンバー同士のコミュニケーションを図るようにしている。 |
べる様 |
| 過去のプロジェクトで、四半期予定表にこれまでの会議で決定したことの一覧を記したメモを加え、毎週のチーム会議で配布した。 |
ken様 |
| Face to Face |
匿名希望 |
| 情報共有ツールの活用。 |
匿名希望 |
| 伝えた事の理解度を確認する為に、さりげなく問いかけをする。 |
坂本様 |
アウトソーシングで海外のIT企業と連携する場合、相手側の"OK"."No problem"等のコメントは信用せず、理解したことを彼らの言葉で確認する必要がある。
両者のギャップは予想していないところで大きいケースがあり、コミュニケーションは難しい。 |
（も）様 |
| 特にない |
松川様 |
| 「一言多いコミュニケーション」を心がけている |
Inaba様 |
| コミュニケーション計画自体は、顧客もほとんど同じで、定例化しているゆえに作業化してしまっている部分がある。意識の問題を非常に大きく感じる。曖昧にならないよう、必ずできること、できないことをドキュメント化を心がけさせている。仕事を請けていることが、うまく仕事を進めるために曖昧さを許してしまう人間の弱い？ところもあり、問題が出るときには常にちゃんとやらなければいけないものができなかったというケースが多いのではと思う。どこかでフェールセーフが利くように担当者レベルだけでなく、プロジェクト関係者が認識を合わせられるオープンな開発環境の仕組みを検討中である。 |
白壁 誠様 |
| 定例会議の実施声掛け飲み会やイベントなどのインフォーマルコミュニケーション |
oldgeese様 |
| オフにゴルフを企画して 人間系でのコミニュケーション改善をした |
曽我 篤様 |
| 特にありません。 |
山脇静香様 |
| まずコミュニケーションの重要性について各PMに十分に理解させること。又、プロジェクトの状況/課題を可視化し、第三者(例えばPMO相当の組織)からコミュニケーション促進に関する指示等を行えるような仕組み(組織)を作ること。 |
nobuta様 |
| ほとんどのケースで一番年下のため，言いたい事を言いたい様に言うようにしています。それを聞いたほうがどのように判断するかは相手に任せます。とはいえ，誤解されたと感じた場合は理解されるまでしつこく説明しますが。ただし，直属の上司に対する説明の場合は一度言いたい事を言ってしまえば後は上司の判断に任せます。というか，どうせ上司は正しく理解できないし。 |
たむ様 |
| プロジェクトの規模に合わせて、メンバー全員でのコミュニケーションの場を数回は必ず設ける。必ずメンバー全員が発言し、現状に対する問題点や進捗方法に対する意見、技術的な面での浸透を図る。ユーザとは仕様確認についてはPG(システム)が作成前と作成途中、作成後に仕様が合っているかの確認が出来ればと思う。 |
匿名希望 |
| ドキュメント作成時に、・箇条書き・スクリーンショット等を作成し、仕様に関する間違いを極力なくし、・検討項目・追加仕様については、逐一、更新版をメールにて連絡している。 |
回答なし |
| 品質の要は上流工程から下流への展開であると考えているためシステム開発の上流工程では必ず懸案一覧を作成して当該工程だけでなく後の工程で懸念される問題点を含め記載することで社内外のメンバと早いタイミングでの問題共有を実現している。上流工程で多くの問題点を挙げるとお客様との打合せ当初は何かと煙たがられることもあるが、後々思わぬところから助け舟を出されて救われることも多い。 |
gyutyann様 |
| 何のためにコミュニケーションをとるのかを常に意識して、相手と接するように心がけている。 |
回答なし |
| その情報が、スコープの範囲において、決定事項なのか、検討事項か、どのようなアクションを必要としているのか、期限はいつか、等によってコミュニケーション手段が、メール、打合せ、面談、飲み会・・等適用が変化すると考えている。適材適所でツール選択は心がけている。しかし、プロジェクトリスクのうち、メンバーのモチベーションやモラル、実行意思の方向性など、心に起因する部分をないがしろに出来ない。そういった場面では、フェースＴｏフェースが重要である。ただ、ＰＭ全てが、そのような場面に付き合う事は非現実的である。したがって、要所（プロジェクトリーダ）の選定には、メンタル的な配慮を実施できるあるいは出来そうな方を考慮する。 |
匿名希望 |
| 遠隔地の事務所とは従来、ＥメールやＦＡＸ、電話等でコミニュケーションを取っていたが、やはり共通の書類、図面等をお互いのＰＣで共有し、顔を見ながらのＷｅｂ会議により、意志疎通を図るように工夫している。 |
TAKA様 |
| 伝達の仕組みを明確にする。ドキュメントの格納先を明確にする。ペアで連帯責任風にし、問題点が挙がりやすくする。プロジェクトに新しく参加するヒトのため用のオリエンテーション的なドキュメントを用意する |
gogopmp様 |
| 顧客に対しても、社内メンバに関しても定期的なコミュニケーションがとれるように、最低週１回はミーティング時間を固定して設けるようにしています。 |
五十嵐 克夫様 |
プロジェクト開始時にステークホルダ分析と、コミュニケーション・プランを作成しています。やや教科書的ではありますが、気合を入れすぎずに（気軽に）
1)まずプロジェクト開始前に作成すること
2）定期的に状況の確認、必要に応じて見直しをすること を心がけています。
コミュニケーション・プランの作成例
伝えるべき情報を縦軸に、ステークホルダを横軸にとって、交わったセルに、必要性と必要な場合頻度・方法を記入します。 |
匿名希望 |
| 2つの拠点による分散開発を行っています。プロマネに相当する責任者を拠点ごとに配置して、進捗や品質の管理に当たっています。責任者が各拠点の状況について正確に把握しているほか、二者の間で定期的に電話連絡をして全体の管理をしています。 |
あきひろ様 |
| 相手の考えを尊重し、「教えてもらう」つもりで情報のやり取りを行う。また、やり取りした結果は記録に残す。 |
匿名 |
| PJMが常にメンバーの仕事の進捗及びその内容を把握し、他部門とのコスト、製品性能、作業進捗度等の整合を考慮した指示を出すこと。 |
鯖井出様 |
| 週１回以上必ず打合せ（ミーティング）時間を設ける。大きな議題は「進捗管理」としていますが、その他１週間の間に気付いたことや思いついたこと等フリートークをする時間を必ず設けています。集まる対象は、全体（顧客・ベンダー等）であったり、ベンダーのみの打合せを必ず設けます。何度か回数を重ねるうちに、お互い言いたいことを言える様になり工事がやり易くなるというのが私の経験です。打合せのために進捗管理表の修正とか議事録の作成等が発生し、余計な仕事と感じ、必ずしもプロジェクト進行中の関係者は快く思っていないと感じますが、後になってその打合せがあったことによる効果は計り知れないものだと常々感じています。 |
祢津 明裕様 |
| 定例会と議事録他、情報共有システム |
意図無様 |
| アフターファイブで、飲食を共にしながら、ざっくばらんに、プロジェクトに関係ないことも話せるように気をつけている。 |
後藤様 |
| (1)メンバーとは常にコミュニケーションを取る。(2)口頭のみでの伝達を極力避け、紙、メール等の媒体を補助的に利用する。(3)全体への情報共有に努める。(4)作業の目的とスケジュール、品質について確認する。 |
江 修明様 |
| 対顧客：定期的なミーティングの実施、懇親会の開催対メンバー：定期的なミーティングの実施対外注：適宜なミーティングの実施 |
匿名希望 |
| 目新しいことではありませんが、ポータルサイトをたてて、メンバの状況を把握するために日報等を入力してもらっている。 |
KOO様 |
| 一見効果的な手段としてメールが迅速にみえるが、受け止め方（作業の受ける側）にとって都合のいいような解釈をしてしまい同じような品質を保つのが結構難しい。特に品質に対する各担当者の意識がまちまちなのでそれを改善するために事前に目的およびやり方の手法/指針を理解するための取り組み（進捗管理、課題管理を用いた定例ミーティング）実施している。 |
かずしおん様 |
| メンバ内で使用するメーリングリストを立ち上げ、情報を常に全員に流せるようにした。また、メンバ全員がアクセスできるサーバに、スケジュール表などをきいつでも見れるようにした。試験現場には、ホワイトボードを置き、マシンの使用スケジュールや不具合などを明示した。更にホワイトボードを活用し、簡単な議論をできるようにした。(Stand up meetingを含む) |
木村 良一様 |
| 本来プロジェクトにとって相手にすべきはシステムではなく、人間であると考えています。プロジェクトメンバーにはシステムありきではなく人間ありきなんだから、些細なことでも構わないからとにかく関係者に声をかけまくれと言っています。収拾が付かない、対象範囲が広がった時には私が間に入るなり仕切り直して関係者を集めています。 |
おば-様 |
| 決まったコミュニケーション計画に従って、会議などを行うのは勿論ですが、日頃からの声かけや他愛のない会話を大事に思っています。また、相手が話しかけ易いような雰囲気を作る（笑顔でいる等）を作るようにしています。 |
まあ様 |
| プロジェクトをレビューする機会にステークホルダーを呼び.プロジェクトへの要望を受け入れる機会を設けている。種々の階層で.コミュニケーションルートを確保すること. |
ミッキ-様 |
| 古臭い事を言う様だが、飲むにケーションは効果あると思います。メールだ、報告書だ、進捗会議だ。。と、やることはいろいろありますが、先ずは個人同士、普通に会話できるまでを早急にやらないと、その先で躓く事が多いです。それから、仕事の場とは言え、多少の冗談とかは良いと思います。全ては信頼関係が基本と考えています。 |
匿名 |
| 月並みですがプロジェクト単位で共有のファイルサーバ、メーリングリストを使用します |
諸永様 |
| ○グループ間調整計画を作成する。○進捗会議にステークホルダーを参加させる。○定期的な監査でグループ間調整をも検証する。 |
あいはら様 |
| 外注の作業進捗、意思確認は基本的には、その会社のリーダ、又はサブリーダとコミュニケーションを取れば事足りますが、実担当者のモチベーションを直接確認したり、担当者がリスクを抱えていないか確認したり組織体制に線を引かず、コミュニケーションすることも必要と考え実行しています。リーダの決断が間違っている場合もあり、担当者の理解がずれている場合のあります。もっと大切なことは、外注さんのＥＳです。リーダが問題ないと報告しても、担当者のモチベーションが下がっていたり、ＥＳ（作業に対する満足感）が無ければ、必ず後で障害の元になりますから。 |
choky様 |
| 強いて言えば、コミュニケーションが必要なメンバー同士の席を隣接させることでしょうか。実現はしていませんが、顧客にプロジェクトルームに常駐してもらうよう働きかけはしています。 |
匿名希望 |
| チームメンバーの役割分担表の公開と共有。そして4半期ごとの更新を全員の前で実施する。そうすることで各人の役割と目標がチームのミッションと連動し各人の役割の位置づけが明確になる |
ht様 |
| 責任の所在をはっきりさせながらも、定期的に打合せの時間を取り、意思の疎通を図る。 |
yu-ri様 |
| 電子メールによる情報共有に要する手間と時間を惜しまないこと。また、電子メールの記述ルール、情報共有ルールを関係者で統一すること。電子メールは、関係者全員に周知することができ、かつ履歴が残るので、顧客とのやり取りや、ＪＶのように職場が離れた環境での情報共有において重要な基盤となっている。 |
匿名希望 |
| 打ち合わせ時には、テーマを事前配信して１時間で終了することを宣言する。自分が怒って意見を言わないことを全員の前で約束する。 |
yokohama yasuhiro様 |
| とにかく、最初の時点での「プロジェクトメンバーの打ち合わせ」「クライアントとの打ち合わせ」などには「言った・言わないなどのトラブル」「仕様の見解の違い」などを無くすように、丁寧にヒアリングする、プロジェクトメンバーを多数参加させるなどの配慮をしています。スコープを決める（極力、変更が無いように）ことに関しても、かなり配慮するようにしています。後は、良好な関係を作る気遣いも見極めての話し合いに心がけています。 |
Taka様 |
| 常に中間レビューを実施し、常時発生する可能性のある意思相違に対して早期発見を実現する。コミュニケーションエラーは、理由いかんにかかわらず、伝えようとする側の問題と責任を明確にしている。 |
ぴろきち様 |
| ミーティングとたまの飲み会 |
かしいいい様 |
| コンセンサス会議を定期開催し、現時点の課題抽出とその解決の為のグループ討議を行う。又、同時に問題の先取りを行い、情報の共有化を図る。 |
橋本隆様 |
| 一日に数回、プロジェクトメンバの机の周りをぶらつき、どんな感じやと声をかけるようにしている。 |
奥田勝己様 |
| 定例会議以外に、１日１回は、声をかける。 |
もっちゃん様 |
| いくら工夫しても相手のやる気がなければどうにもならない。義理などで参加されるのは非常に困る。 |
寺下様 |
| 会議終了後の纏めの再確認と，次ステップの確認（タイムスケジュール、責任・役割、等など）次の会議の設定とそれまでの各担当が対応，処理すべき事項の確認 |
山下モ-造様 |
| 日々のコアタイム中での定例ミーティングしか行っていないです。 |
リトルトキオ様 |
| 直接・メール・電話の使い分け |
回答なし |
| 担当プロジェクトの規模が小さいせいか、コミュニケーションの問題は幸いにも無かったように思う。不要なものは除き、すべての情報をメールや会議で全メンバーに伝達するようにし、全メンバーが当事者となって業務を遂行できるようにした。コミュニケーション計画は重要であるが、しくみだけではカバーしきれないコミュニケーションの穴を埋めるのは、メンバーのプロジェクトに対する自発的取り組みによる部分が多いと思う。 |
本間佳子様 |
| 週末定期ミーティング開催。食事時ミーティング活用 |
黒田 修様 |
| メンバのその日の体調・顔色を見て、発言をさせたり、全体のモチベーションが上がるように、明確なゴールを決めて、自由に発言させている（より高品質に生産性をあげるために） |
でろろん様 |
| 工夫と呼べるかどうか分からないが、「会話での意思疎通」＋「メールでの確認」のセットで常に行なうこと。さらに社外者との折衝については、メールの際ＣＣでリーダーを入れること。リーダーへの連絡の意味も含むが、リスクの把握とそれに対する責任感の醸成が大きな意味合い。 |
長岡様 |
| なるべく顧客の近くで仕事を遂行するなど、状況の変化を敏感に察知できる環境作りに心がけている。 |
ケニイ様 |
| 問題発生後、1対1で話す機会を極力持つようにし、理解度を高めるようにしている。 |
nhoshi様 |
| 毎日，何も無くても話をする．但し，5分程度で切り上げる．会議は議題と決めるべき点を資料に書いて事前に提出する． |
岸田様 |
| ツールの導入バグトラッキングなど |
よしきみ様 |
| プロジェクトが追い込みにはいると、各チームとも自分の守備範囲のことに没頭し、当然しっかりやらなければならない、他のチームとの連携がおろそかになりがちである。私がＰＭをやったとあるＩＴ導入プロジェクトでは、カットオーバー3ヶ月前からＰＭとＴＭで毎日、夕礼（夕方の朝礼？）を18時から実施しコミュニケーションを半ば強制的に図った。ＰＭが進行およびメモを取り翌日の朝一番にそのメモをメールで各ＴＭへフィードバックするという形。ＰＭにとっては負荷のかかる作業であったが、チーム間に発生しがちな「抜け」が少なかったように思う。（それでも、抜けは発生したが.....） |
moh様 |
| ・プロジェクトBlogの活用・ＰＭミーティング（１／週）の出席必須化・段とび（１階層飛ばしたミーティング、飲みニケーション）・横断的なコミュニケーション対応組織の明確化・トラブル時のコミュニケーション観点の問題整理、議論の義務付け |
開 一弘様 |
| プロジェクト計画時にお客様（トップ、ＰＭ、メンバー）や開発側のＰＬ、メンバーに対して、報告内容、タイミング、コミュニケーション方法等の計画を事前にドキュメントして関連者に説明、合意をとっておく。 |
匿名希望 |
| 就業前後、休憩のわずかな時間に世間話をするように心掛け、本当に必要な会話が可能となるような基礎環境を作っている。 |
窓際席様 |
| 頻繁にミーティングやレビューを実施している。 |
ツンさん様 |
| 定期的（隔週）に顧客トップを交えたMTGを設定PJオーナーに必ず出席していただく |
回答なし |
| プロジェクトの目的意識を見失うことなく常に確認しあい、それぞれのモチベーションを高めるようにすること。 |
長谷川伸一様 |
| 息抜きに飲み会を開いて仕事以外の話で交流を深めています。 |
匿名希望 |
| 毎朝短時間で全員ミーティングを行う |
匿名希望 |
| 部下にマネージャを選ばせる。 |
キタムラ様 |
| チーム内で必要な情報が回っていない、もしくは誤解されて伝わっていると感じた時は、早めに必要であれば個別にでも対処する。 |
匿名希望 |
| プロジェクト専用ポータルサイトを開設し、出退勤・離席を含めた細かい情報から全体的な情報まで提供する。 |
あいと様 |
| 懸案事項や不安要素は常にメンバーで共有するよう徹底。短時間で解決できない問題は上司等に相談することを義務づけ。確認事項を関係者にE-Mail等でその都度送信する。 |
ひろきち様 |
| 顧客と仕様確認の為にレビューをしっかり行い記録を取る。顧客及び社内の進捗報告を定期的に行い記録を取る。 |
N.W様 |
| なにをどこまでどうやって等のいわゆるコミュニケーションの５Ｗ２Ｈを出来るだけ明確にする。 又、明確に出来ていない項目を確認とって置く。 |
堀 宰一郎様 |
| まずはプロジェクト開始時にステークホルダを特定することが基本かと考えています。顧客から組織図をもらって対象部署を確認しています。部署によっては担当者まかせで上司が打合せに出て来ない場合が結構ある（そのくせ問題が起きるとギャーギャー騒ぎ立てる）ので、担当者とある程度話せる仲になったら紹介してもらい簡単な報告をするなどして接点を持つ様にしています。 |
PMPビギナ-様 |
| 定期的にやること。メンバ・協力会社とは、レビュー会議・マイルストン会議を定期開催。シニアマネージャへは同タイミングでレポート報告。顧客へは月例会を開催。 |
カッシ-様 |
| 私の関わっている現場では、情報の共有を図るためにメーリングリストを活用し、また定期的な進捗会議を開催していますが、これだけでプロジェクトの状態を把握し、特に問題点を早期に検出するのは難しく、特に、常時１００人以上のメンバーが活動するプロジェクトでは、メールと定例という定型的なコミュニケーションだけでは、ＰＭが問題を把握することが遅れがちになる事例を、直接・間接に数多く見聞きしています。私は、プロジェクトの状況・問題点（進捗遅れ・顧客の状況・品質・作業内容等々）を把握するには、やはりプロジェクトメンバーの生の声を聞くことが一番と考えています。私は、最近肩身の狭い喫煙者ですが、喫煙ルームではプロジェクトのメンバー個々人とリラックスした状態で、より本音の部分や個人が疑問に思っている点等について聞けることが多いため、喫煙ルームをコミュニケーションの場として活用しています。また、一区切りついて「暇そうな」顔をしているメンバーを見つけては、こまめに状況を聞きにいくことも重視しています。そうしたメンバーを見つけるためには、こちらが「ぷらぷら」していなければなりません。そのため、自分での直接作業は極力少なくし、一見プロジェクトルームの中を「ぷらぷらしている」状態を意識的に作っています。（本当にさぼっている場合もありますが…）でも、こちらに余裕がないと、誰も相談に来なくなります。こちらが「余裕の顔」で「ぷらぷら」していると、問題を抱えて向こうから寄ってくるようになります。基本的なプロジェクト運営をした上で、さらにプロジェクトメンバーの中をＰＭが「漂って」いられるような状態ならば、そのプロジェクトは大きな失敗をすることもなく、なんとかなると思っています。 |
針谷 常雄様 |
| まずはしっかりと顧客の言うことを聞くこと。常に顧客が何を望んでいるかを考えて話をする。 |
梅田明由様 |
| 毎週月曜日のプロジェクトミーティングとステークホルダー、プロジェクトメンバーに対する議事録の送付。隔週火曜日のグループごとに分かれたより詳細なステータスミーティング。プロジェクトマネージャーはプロジェクトミーティングのファシリテータ。全てのグループミーティングに出席し全体を把握する。 |
TR/28 XH様 |
| ・（みんなやっていることでしょうが）進行管理表を作成し、計画と実績のずれがみんなでわかる様にファイルを共有する。・代表者MT（５名程度）を行い、特にスケジュールに関しての問題を調整する。全体MTではぼやけてしまったり、メンバーに言えない事があったりするため。・開発場所の終バス（23時頃）にメンバーが集まることが多いが、10〜15分前に集合し、バス停の前のコンビニで缶ビールを買ってみんなで討議する。（店の人にはちょっと迷惑？）一つの議題で異常に盛り上がる時も有り、バスが駅に着くまでに結構色々調整できたりします。 |
まこちゃん様 |
| PMを交えての進捗ミーティングを日々定例で開催している |
ヤマト様 |
| 情報共有の為にファイルサーバ(Prj関係者限定)を置く。進捗確認会を定期的(危機的状況だと毎日実施と言うように、状況に合わせて間隔を考える)に実施。Prjの立ち上げ時、kick-off飲み会を行い、右脳のインテグレーションを行う。 |
よこみぞ様 |
| ドキュメント共有のためにフォルダー、フォーマット、作成すべきドキュメントリスト、標準などの設定。報告、連絡、スケジュールのための掲示板、共通の場の設定。(アングラ通信の場。)ノミニケーション。行動・成果を評価に反映させる／させないの切り分け基準の設定、など。 |
ま-君様 |
| 回答のトラブルプロジェクトは前任のＰＭに問題が有り、途中から建て直しを依頼されたものである。原因を分析したところ、顧客の要件を正確に把握しておらず、それを確認もせずに見切り発進していた。又外注先へ丸投げ部分も有り、プロジェクト全体が機能しない状況に陥っていた。自分がマネージメントする場合に、一番注意する事は、プロジェクトの立上げと計画の前半で、各ステークホルダーの意識を統一させる方向に持っていく事である。プロジェクト体制の明確化、権限・責任分担の明確化、スコープの共有化等である。これをベースに、意識のズレを生じさせないように、進捗会議、レビュー、承認のタイミング等をマイルストーンで明示する事を心がけている。コミュニケーションの目的は、プロジェクトの目的とプロセス、成果物のイメージを共有し、共通のゴールを目指すと言う意識の醸成にあると考えている。これが上手く行っている場合は、非常に前向きな議論が行われ、プロジェクト活動が活気を帯びている。最後に、プロジェクトの成否は最初の段階で、如何にステークホルダーの意識統一が計れるかにかかっていると思う。そこで手を抜けば、必ず後から痛い目にあうことになるであろう。 |
鈴木 裕一様 |
一緒にものを食べることです。たとえば、喫茶店で軽食を取りながら打ち合わせを行なったり、昼食を一緒に食べたりしています。
そこで雑談などしながら相手の趣味・興味などを聞きだしたり、人となりを理解したりして、アイスブレークのネタにしています。
ただ、俗に言う飲ミュニケーションは使いません。酔ったときの話は、現実味が感じられず説得力も弱いからです。アルコールが入れば本音も聞き出しやすいという意見があるかもしれません。しかし、そうしなければ本音を聞き出せないのならば、自らの拙いコミュニケーション能力を磨くべきかと思います。 |
翠雨様 |
【１】（2wayコミュニケーションを基礎とした）FaceとFaceを第一にとる。
【２】進捗・品質管理等のプロジェクトにかかわる会議は、必ず代行者出席者義務および議事録作成と回覧の徹底。
【３】紙ベースの文書でなく、報告書や議事録類はプロジェクト全員が参照／提出可能なDBに集中収容。
【４】上下関係・経験等なく、自由な意思や思いつきによるコミュニケーションを心がける。
【５】プロジェクトの拠点が離れている場合は、相互に会議か出張等を試みるなどしている。 |
立花義博様 |
| 連絡文書の定型化、事前のスケジューリング、日頃の対話に心がけています。 |
高奥浩明様 |
| ・作業場所集結の段取り・とりあえず定例会議開催・メンバー間メーリングリスト登録 |
oki_jsa様 |
