{{tag>book}} ====== Managing Virtual Teams: Getting the Most From Wikis, Blogs, and Other Collaborative Tools ====== 街、国、世界を超えたコラボレーションは珍しいことではない(世界では)。 作業環境を整えることではるかに生産性を上げることができる。しかし現実より帯域幅が狭いため、仮想環境での取り組みをより明確にする必要があるなど、リアルとは異なる作法が必要となる。 そのためのチーム作りについての本。 ===== Chapter 1 ===== バーチャルなチームの力学を理解する。 * Tuckmanのモデル、チームのライフサイクル * 形成。アゲアゲ、ハネムーン状態。 * 嵐。方法、ビジョンの差異を発見し、話しあう。 * 標準。役割がきまり、活動がやりやすくなる。 * ゾーン。うまく連携しており、どこに行くか、どうやってやるかを理解している。 * テスト。修正？ * 中断。締めくくり。評価し、次のことに備える。 * ツールだけでは不十分で、リモートチームワークの方法を学ばないといけない。 * 5つの必要不可欠な部品 * 共有されたチームの目的 → SMARTである必要がある。 * 何をするかの知識 → 何をするか、制約、資源を理解する。 * それをする装備 * それをする能力 * それをする願望 → 意欲は、ときに生死を左右する。困難、能力不足を、乗り越える力を持つ。 * それぞれに高度な自治権が求められる。メンバーはそれぞれ同じタイムゾーンとは限らず、レスポンスは遅れる可能性が高いためだ。いちいち許可を取っていては進まない。 * リーダーに必要なことの一つに、メンバーごとに得意なことを見つけ、任せることがある。役割は以下のようなものがある。 * コーディネーター * デザイナー * 種をまく人？ * 技術マネージャー * 人的マネージャー * 最高責任者 * 文化の違いは氷山に似ている。目に見えるよりずっと深くに根付いているということだ。 * 仮想チームを構築するときは、すべてのことを明確にする必要がある。コミュニケーションの時間、マイルストーン、休日のスケジュール、不在通知のルール、wikiへの投稿の形式。 * コミュニケーションは非言語が70％を占める。だからバーチャルコミュニケーションで勘違いは容易に起こる。フィードバックループを着実に回し、ユーモアのセンスを忘れないようにしないといけない。 * バーチャルチームはプロジェクトの最初に多くのコストを必要とする。 * バーチャルの人員はオフィスで働く人よりもモチベーションが高く、自主性が高い傾向がある。さらに生産性が高い傾向もある。 ===== Chapter 2 ===== バーチャルチームを立ち上げる。 * 人を雇う。探すにもいろいろあり、人材会社の紹介だけではない。同僚の知り合い。大学のメンター制度。他業界からの流入。 * 必要とするスキルを明らかにする。 * 職務記述を特定のスキルに特化したものにする。 * 雇用する優先順位をつける * SWAT分析。強さ/弱さ、機会/脅威でビジュアル化する。 * 求めるものを明確にする。コミュニケーション、プロジェクトのビジョン、ふるまい、仕事の優先順位、階層、成功度を測定するための方法。 * コアチームはプロジェクトを最初から最後まで取り組み、中核を担う。必要に応じてメンバーを追加する。 * 最初が重要。プロジェクトの前に全員で話しをする機会があれば、多くの時間を省略できる。共有した経験は信頼関係を作る最も早い方法である。 * 最初の会議でやる課題… * 1.自己紹介、プロジェクト自体の紹介、チームビルディング * 2．主なタスクの特定、マイルストーンの設定、メンバーの担当範囲、目的 * チームビルディングにおいては、 * 個人的な歓迎感 * チームに計画させる * 仲間をランダムに決める。派閥を作らない。 * 社会的孤立の予兆を見る。多くの人はグループ活動を嫌がり、特に知らない人だとなおさらだ((外人でもそうなんだな))。何が起こっているのか把握する。 * 平等な機会 * さまざまな活動が含まれる…それぞれの得意分野を活かせるようなもの * 活動のあとの社交の時間を作る…活動を振り返って面白かったときなどの話しをする。 * 困難な状況でもユーモアを維持する * バーチャルチームビルディングは、wikiなどを利用する。 * 公に賞賛し、指摘に注意する。 * チームの取り組みを認識するときは、すべての人を含める。 * 24/7 → 年中無休で。24時間7日間すべて、という意味。 * プロジェクトの情報を集約するリポジトリを提供する。 * 集団文化は、顔を重視する傾向があり、個人主義は顔を重視しない傾向がある。 ===== Chapter 3 ===== 何が必要か明らかにする。 * ツールを得る前に、何が必要か理解する。 * 成そうとしていることは何？ * 今の能力は何？ * チームはだれ？ * それぞれのタスクに最適なものは何？ * ハードウェアとソフトウェアの問題。買えば解決するというわけでもなく、メンバーが使えるかどうかも問題になる。 ===== Chapter 4 ===== チームとコミュニケーションする。 * プロジェクトの最初にまずガイドラインを作るのが必要。何の情報を共有するか、頻度は？ * eメールは楽だが、文字だけで誤解も起こりやすい、ガイドラインが必要だ。応答時間、読む頻度についても。 * eメールのガイドラインのサンプル * 一対多、多対多の違い * 何のための会議か？によって方法を変える。たとえば情報を共有したり、報告を集めるだけならファイルを共有したほうがいいかもしれない。話し合う必要性があるとき、会議とよぶ。重要なのは、会議の目的や目標を理解し、会議の全員がその目標に向かって作業できるようにすることである。 * 事前に話し合う内容などを共有しておく。当然、方法や時間なども。 * 議事録をとる人を決めて、あとで共有できるようにしておく。 * VoIPの会議では誰が話してるかわからなくなるので名前を言う。 * テキストの会議では:メッセージが非常に早く流れる。参加者に早い接続速度が必要。 * 確実に時間どおりに終わらせる必要がある。終わらないなら、次回の予定を決める。 ---- Sample Meeting Minutes Meeting Lead: Brenda Huettner Attendees: Kit Brown, Char James-Tanny Location: Skype (voice) and Wiki (file sharing) Date & Time: August 1, 2006, 1 p.m. Eastern, 2 p.m.Central, 4 p.m. Pacificn * All required forms completed and submitted to the publisher * Wiki set up; all co-authors have login IDs and have been able to edit page * Files uploaded: NBI, style guide, co-author schedule * Assignment of authors to chapters posted to wikiTOC page * Tentative schedule established and posted to wikihome page * Action Items:nEach author to write draft of assigned chapters byAugust 30 * Char will update schedule page by end of businesstoday ---- ===== Chapter 5 ===== プロジェクトの計画とトラッキング。 * 二人以上が働くときは、打ち合わせが必須だ。そうでないと重複や誰も必要なことをしていないことが起こる。 * よいプロジェクトは以下をもつ: * プロジェクトの範囲 * 計画の前提条件 * プロジェクトの成功に必要なこと * プランに含まれるタスク * それぞれのタスクを達成するスケジュール * コストの予測 ---- * 調査する * 聴取分析 * 製品トレーニング * 要望を分析 * 情報プランを作成 * 情報をデザイン * 文書をデザイン * スタイルガイドを作成 * カバーデザインを作成 * アートワークのデザイン * アートワークのレビュー * アートワークの訂正 * 在庫と色を明確にする？ * 印刷 * コンテンツの仕様書を書く * ユーザーガイドの内容 * リファレンスマニュアルの内容 * クイックリファレンスカードの内容 * ヘルプシステムの内容 * コンテンツ仕様書のレビュー * コンテンツ仕様書の訂正 * 締めくくる * ユーザーガイドを書く * 草稿 * 1章 * 2章 * 3章 * 4章 * 5章 * 導入 * 草稿のレビュー * 技術レビュー * 編集レビュー * 索引を作成 * リファレンスマニュアルを書く * 最初の草稿を書く * A-E * F-J * K-O * P-T * U-Z * 導入 * 最初の草稿をレビュー * 技術レビュー * 編集レビュー * 二次草稿を訂正して書く * 二次草稿をレビュー * 技術レビュー * 編集者レビュー * 索引を作成 * クイックリファレンスを書く * レイアウトをデザインする * テキストと図表を追加する * カードをレビュー * カードを訂正 * プリンターを用意する * ヘルプシステム * メイントピック * トピックのテキストを書く * トピックのテキストをレビュー * トピックのテキストを修正 * リンクをチェックする * 「これは何？」トピック * トピックのテキストを書く * テキストをレビュー * テキストを修正 * リンクをチェックする * 生成物 * 開発者の成果 * エンコードのトピック * リンクをチェックする * プロジェクト後のタスク * ドキュメントの保存 * メンテナンスの手順を構築 * 成功/失敗を評価 * プロセスの改良を進める ---- * バーチャルチームではコミュニケーションの時間が余計にかかる。それを計画に入れる。 * 国ごとの祝日を考慮に入れて計画をたてる。また、季節によって停電しやすい場所…なども考慮する。 * チームメンバーは、自分の努力が大きなプロジェクトのどこに当てはまるか、ほかのメンバーと比較してどのように進んでいるか、最初の見積もりと比較してどのように進んでいるか知る必要がある。そのために必要なこと: * 個々のタスクを更新する。 * 全体的なプロジェクトの状態が見れる。 * プランを修正する * 行動と決定を文書化するための記録を維持する？ * これらはソフトウェアを組み合わる必要がある…ワードプロセッサ、カレンダーソフト、スプレッドシート、ファイル共有。 * さまざまなプロジェクトソフトウェアがある。まずそれを選択しないといけない。 * 承認されてからも、現実の進捗を捕捉して計画との違いを知り続ける必要がある。 * 計測: インプット(かけた時間、費用、その他コスト)、プロセス(レビューをした数、ミス、修正…)、アウトプット(完成したプロジェクトの総行数、アプリケーションの数…)。 * **計画のステータスを最新の状態に保つことが重要。**時間、書き込まれた行数などの測定値を記録する。単に情報を保存するんでなくて、分析する。 ===== Chapter 6 ===== コラボレーションとトラブルシュート。 * チームで分かれて開発した成果物は、ある段階で統合する。 * バーチャルチームは、共同作業について想像的である必要がある。 * プロジェクトによっては外部のサービスを利用しないといけないときがある。たとえば執筆ではプリンター、家庭用ゲームではCDやパッケージなど。これらを採用するまえに、あらかじめタスクの詳細と範囲を明らかにしておく必要がある。CDベンダーは中身を責任を持つか？締め切りはどれくらいか？など。 * タスク定義をしていくつかベンダーに見積もる。明確化や仕様の変更を要求する準備をする。非常に学習経験になる可能性がある。 * 同意を契約として書く * 考慮すべきこと: * ローカリゼーションと翻訳 * RFPの書き方: * 委託業務が開発プロセス全体のどの位置にあるか、など。 * 範囲 * スケジュール * 必要なツール * サンプルファイル * テンプレート、スタイルガイド、用語集 * 提出フォーマットと締め切り * 著作権は誰がもつか * 画像の責任は誰が持つか * 通信状況 * 文化によって理想とするリーダーは異なる。 * 対立意見が出たとき。リアルだとあとで個人的に話せばいいが、バーチャルではそうはいかない。かといって放っておくとあとで失敗の原因になる。 * 目標は紛争を管理することであって、解決することではない。対立は新しい方法考えるうえでは避けられない。 * セクハラなどの対立には素早く対応する必要がある。文化によるパーソナルスペースの違いにも見られるように、不快となるのは大きく異なる。あらかじめガイドラインを定めておく必要がある。 * 紛争に対処するコツ: * 事実を得る * 個人と分離する * 関係者全員と集まる(できればリアルで) * 個人攻撃を避け、冷静に対処するよう求める。質問する。 * 必要なら、時間を空けてクールダウンする * 人々とうまくやっていく10つ(Active Voice誌から): * 他者についてネガティブな話しをしない。噂をしない、聞かない * 寛大になる * 批判は真実があるかどうかを確認し、ない場合は無視する * 人に何か言うとき、真実か、理解があるか、必要か考える * 約束を控え目にして信頼を保つ * 褒めたり励ます機会を逃さないようにする * 何か言う前に10数える。問題を悪化させる可能性があるときはさらに数える。 * あなたの美徳は他人に言わせる * オープンマインドを保つ。**議論はするが主張はしない。** * ===== Chapter 7 ===== レビューの実施。((何の話しなのかわからない箇所多し。英語力と集中力、プロジェクト経験のなさの問題か)) * レビューは避けたくなることもあるが、品質のために必要なプロセスである。 * レビューが成功するためには: * チーム、管理者、自分のコミットメント * プロセス全体の積極的なコミュニケーション * 一貫性 * 組織化 * コンテンツレビューは3つの種類がある: * テクニカルレビュー(専門家たちによる) * ローカルレビュー * 承認レビュー * 期待と合意の文書化。リーダーシップとチームワークに対する態度の文化的違いを吸収する。 * すべての専門分野で構成されるレビューチームを組む。製品、文書、開発。 * レビューとは何かの合意。 * それぞれに求められるレビューの観点は異なる。それをチームそれぞれが知っている必要がある。 * 理解できない家電の説明書は、悪い翻訳と国内レビューの欠如から生まれる。国内レビューはメインの製品の完成後に行う必要があるので、ボトルネックになりやすい。 * 国内レビューがうまくいかないのは、インフラがないためである。翻訳をレビューしても報酬はなく、単なるボランティアになる。また、スケジュールにも含まれていない。 * 人間は罰よりも一貫性のあるポジティブさに強く動機づけされる。 * 望むこと、ゴール、ポジションの記述(役割？)などを明らかにする。**リーダーシップ、チームワーク、…これらは文化によって違う意味を持つため、明確に定義する必要がある。** * 定期的にチームミーティングを開催する。信頼と陽気な雰囲気を築くのに役立つ * 月次レポートを要求する。だれがどう貢献したのか把握し、賞賛に役立つ。 * ポジティブで建設的な態度を保つ。(困難な状況でも) * えこひいきしない…シナジーを壊す。 * 自己評価と上の評価の矛盾や不一致について話し合う。 * プロジェクトのレビュー。 * マイルストーンレビュー。問題が大きくなる前に対処できるようにする。 * マイルストーンミーティングではプロジェクトの方向性の修正が必要ではないか話しあう。 * 現在の状況、％で * 前のレポートからの達成 * 挑戦 * それぞれのタスクの予想時間 * スケジュール、コストを引き起こす可能性のある依存関係の特定 * 会議のアジェンダ * 会議で望むこと(例) * あなたが達成を望まれていることは何？ * ミーティングの間あなたは何をする？ * 不賛成、議論に大してどう対処しますか？ * ミーティングの時間について誰が責任を持ちますか？ * ミーティングの後方支援とは何ですか？ * プロジェクト後の評価。失敗の場合は原因を探り、成功のときでさえもベストプラクティスとして成文化する。 * 率直な意見のために匿名アンケートにしてもよいかもしれない。 * アジェンダ * 概要 * プロジェクト、ハイライト、挑戦の概観 * 調査の要約 * ディスカッション * フォーカスグループの結果のカテゴライズと優先順位決め * アクション * 結論(投票も必要かも) * 強力なファシリテーターのほかに、できれば外部のメモしてナレッジ化する人が必要。 ===== Chapter 8 ===== リスクと挑戦を管理する。 * 「いつでも自分がなりうるもののために、自分がなんであるかを犠牲にする」…留まらず進化せよということか。 * 企業活動の変化には、人とプロジェクトの2つがある。柔軟に変化させる。 * 人が働けなくなるリスクを予測しておく。転職、事故、家族…。 * 彼らに問題などを聞く。個人的失望をぶつけたり、失礼な質問をしてはいけない。また、助けを借りることがありうるからだ。 * チームが強固になることは当然よいことだが、反面、新しいメンバーが入りづらくなることもある。意図的にウェルカムな雰囲気を作ることが必要。ウェルカムワゴン(新人歓迎車)に代表されるムード。 * 新人に渡す荷物、バインダーを用意する。以下の情報: * 連絡先、経歴、役割。便りになる人たちを特定する。 * 会議の番号、コード。 * URLのリスト、ファイルの場所、プロジェクトに関連するすべての場所。 * プロジェクトの履歴、決定… * 主要イベントの録画。企業の文化を知れる。 * ミーティングのスケジュール、時間、場所 * チームのルール、ガイドライン * 略語のリスト * 最近のプロジェクトのガントチャート * 新人が責任を持つアクション * 役割の記述、責任 * 必要とするトレーニング、及びオンライントレーニングのURL。 * 最初の週のアジェンダ。 * チームのメンターの特定 * 新人のスキル、チームが求めること * チームミーティングのスケジュール * 第二言語話者などの場合は、リアルで来てもらったり派遣して正しく行われているか見る必要があるかもしれない。 * 質問しやすいようにする。バディをくませるとか、数週間はリアルで会う機会を作るとか。 * 効果的な変化のマネジメント: * 予防的 * 体系立てられた * チームの努力。変化は各々のメンバーにとって均等なわけではない。簡単な変更に見えても、ほかの工程の人が苦労するかもしれない。例: 製品名の変更。 * 開発サイクルとシンクロしている * リリースごとの変化の追跡を容易にする * コスト削減につながる * 修正があとになるほど、修正にかかるコストは大きくなる。 ===== Chapter 9 ===== プロジェクトの成功を評価する。 * メトリクス: 測定法 * 目的、目標、メトリクス。 * 時間、資源、プロセス、クオリティーを計測する。 * まず知りたいことを明確にする。優先順位をつける。 * サーベイツールや、自動計測を使用してデータを集める。 * 分析する。 * あとで活用する。 ===== Chapter 10 ===== ツールを比較する。 * タスクごとに使うツールを決める。優先順位を決める。 * ツールのマトリックス。 ===== Chapter 11 ===== インストール、カスタマイズ、セキュリティ。 ===== Chapter 12 ===== コラボレーションのためのソフトウェア・スイート。 * Cooperation と Collaborationは異なる。 * Cooperation: 独立したサブタスクがマージされて最終成果物になる。 * Collaboration: サブタスクごとにチームワークが必要。 ===== Chapter 13 ===== ミーティングとコミュニケーションツール。 * VoIP(ネット通話) * ミーティングプログラム ===== Chapter 14 ===== 情報公開ツール * ブログ * ポッドキャスト * ウェビナー ===== Chapter 15 ===== 情報共有ツール * カレンダー * ファイル共有 * 掲示板 ===== Chapter 16 ===== 情報を集めるツール * アンケート * プロジェクトマネジメント * タイムトラッキング ===== Chapter 17 ===== Wikiシステム。 * https://www.wikimatrix.org/ ===== Chapter 18 ===== RSSフィードとプッシュテクノロジー。 * ニュースレター * RSS