nDiki : コラボレーション

2005年10月24日 (月)

効果的な複数人電話会議は?

年初あたりから社内で Skype が利用されはじめて、複数人による電話会議もよく行われるようになっているようである。 離れている拠点のスタッフ間での連絡が密になるなど、効果はあるようだ。

しかし自分は特に複数人における効果的な電話会議手法を見い出せていないので、積極的に利用していない。

長所

  • 物理的に離れているスタッフを含めた会議が可能
  • 既存のインターネット接続上で Skype を使う分には通信コストが余計にかからない

短所

  • 顔が見えない
    • 聞いているのか、理解できているのわからない
  • 通常の会議より時間がかかる / 同じ時間で決まることがすくない
  • 回線断などがあると、しらける

効果的に行うには?

アジェンダにしても参加者の下準備にしても、集合して行う時以上に周到に準備しておく必要があるであろう。 Skype だと気軽に召集できる感があるが、ミーティング中に伝達できる情報量は少ないのだからそれぞれ事前に資料を用意してメールなり、Wiki なりで情報を共有しておく必要がある。

たとえば、共同創造に必要な情報は顔を突き合わせてやり取りしたほうが効果的なのに対して、情報伝達に必要な情報は紙や電子ファイルの形態でも直接やり取りするのと同じぐらい効果的である。-- 適応型ソフトウェア開発 p.119

普通の会議と同様、情報伝達と共同創造の区別が重要である。

いわゆるミーティング、特にコラボレーションが、否定的に捉えられがちなのは、共同創造と情報伝達という2種類の基本的な相互作用が区別できていないためである。--- 適応型ソフトウェア開発 p.118

ほとんどの組織では情報伝達を濫用している。--- 適応型ソフトウェア開発 p.119

スポンサード リンク
[ 10月24日全て ]

2005年10月28日 (金)

ソフトウェアかんばん

naney:57031780

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

  • イテレーションの設定
  • タスクの見積もり
  • ストーリーの見積もり
  • 全体の見積もり
  • 定期的チェックタイムの設定
  • 貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]

[ 10月28日全て ]

2005年12月6日 (火)

乱入OK! コラボレーションタイム

11月末にモノを発送できたプロジェクトの事後評価セッション。 手法は前回と同じKPT法をとりいれた方法で。

セッションでは「質問したい時に、忙しそうにしていると話かけづらい時がある」という課題があがった。 あ、自分のことね。 忙しいと集中して(あるいは集中しているフリをして)そういう雰囲気を醸し出しているな。

こちらは案外好きな時間に声をかけているのだが、立場というダイオードが入っているのかもしれない。

集中とコラボレーション、どちらも大切。

ということでアイデアとして、時間を決めてその間はアポがはいっていたり極限状況にあったりない限り、チームメンバで御互いに話しかけたら誠実に対応するというルールを作ってみた。 15:00 - 16:00 をその時間に。その日にある程度作業をした後問題が発生した頃で、かつコラボレーション後実行してみる時間を残っている時間はこの時間帯かなと。

トリンプ・インターナショナル・ジャパンの「がんばるタイム」のように、各個人業務の集中時間を設けるという事例は聞いたころがあるが、こういうコラブレーション推奨時間を設けている話はまだ見かけたことがない。 多分いろんなところでやられていると思うのだけれども。

p.s.

基本的にそれ以外の時間には話かけるなということではないので、お間違いなく。

[ 12月6日全て ]

2006年3月11日 (土)

コラボレーションを促進するオフィスレイアウトへ

naney:112139721

今日は土曜日であるが、平日なみ(よりちょっと遅く)に起床。 電車にゆられて秋葉原で下車。オフィスで向かう。 昨年から昼休みに同僚がメジャーを持って歩きまわって 3D 化してシミュレーションするなど、少しづつ計画をあたためてきたレイアウト変更のためである。

夜通し飲んで顔の赤い腰を痛めている若手スタッフと、年寄りがかかると思われている病気のスタッフと、バイクでこけて怪我をしているスタッフと、還暦を過ぎているスタッフと、日本語が堪能ではないスタッフと、体調のよろしくない FF 好きなスタッフと自分で総勢7名。

2月末の納品作業のバタバタ後で細かい配線計画等はできていなかったが、まぁそこは何とかなるでしょうということで。

予想通りパーティションの分離・合体と移動がうまくいかずに、一部破壊しつつ無理矢理に新レイアウトへ。 前半戦でパーティション・デスクなど什器の移動を終え、後半戦からは電源・電話・LAN の再配線。

電話に関しては現状の配線図がないため、こんがらがっている配線をほぐしつつ接続図を作成。

ネットワーク系は、サーバ PC の移設と UPS の差し替えも含めてなので思ったより時間がかかる。

あちらことちらで「ガシャン」と物を落とした音が聞こえたり、「アッ」という声とともに足にひっかかって無理矢理な状態のコードが目に入ったりと(それぞれ自分もやらかしているわけだが)、やばそうな部分もあったが奇跡的に故障している機器はなかったようである。

なんとか夜の 9:00 を過ぎて目処がたち、記念撮影をして解散。

真中にオブジェのそびえ立つ、以前より開放感のオフィスになった。 さて来週以降、効果のほどは。

naney:112140169

[ 3月11日全て ]

2006年4月10日 (月)

ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

issue tracking

開発中に発生する

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェース仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

  1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
  2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

  • 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

[ 4月10日全て ]

2006年5月15日 (月)

すべての情報を共有する。情報閲覧者が判断する。

帰りの東北新幹線で、ウェブ進化論の続きを読む。 興味を持ったのはこれ。

シルバースタインは「こうした情報共有の仕組みをテクノロジーが支える」と語ったが、グーグルの社内情報システムはごく普通のシステムの組み合わせだ。ごく普通のブログや掲示板、社員全員が同じ文章を自由に編集できるウィキ (Wiki) と呼ばれる共同作業用環境、検索エンジンといったものの組み合わせである。-- ウェブ進化論 p.86

社内に Wiki を立てて、周囲を巻き込みつつ情報共有のため基盤と文化を育てようとしている自分にとって「ごく普通のシステムの組み合わせだ。」というのは心強い話である。

本書ではさらに、下記のように続く。

道具自身に新性があるのではなく、すべての情報を共有することを原則に「情報自身の淘汰に委ねるという思想のほうに新性があるのだ。 -- ウェブ進化論 p.86

はてなの近藤氏も2005年7月27日の記事で同様のことを述べている。

ここで大事なのは、「その情報を出すべきかどうか」を情報発信者が判断するのではなく、全ての情報を出しておいて、情報閲覧者が「その情報を読むべきかどうか」を判断すればよい、と考えることです。-- CNET Japan Blog - 近藤淳也の新ネットコミュニティ論:情報の私物化を禁止する

効果的にコラボレーションをして成果を上げていくにはメンバが、積極的に情報をアウトプットし共有していくことが重要である。

しかしながら情報のアウトプットというのはなかなか実行されないものである。 理由はなんだろう。

  1. 情報共有/活用基盤がない。
  2. 情報を共有するという文化がない。
  3. 情報をアウトプットするコストが高い / 高いと感じる。
  4. 情報をアウトプットするメリットを理解できない / 感じられない。
  5. 情報を制限することで権限を維持したいから。

あたりか。

Wiki の次の一手として社内 Blog を立ち上げることにしよう。


[ アウトプット主義 ] [ 読書ノート ] [ opinion ]

[ 5月15日全て ]

2006年5月16日 (火)

社内 Blog 開設

ウェブ進化論の中の Google の話に触発されて、そのうちやろうと思っていた社内 Blog の開設を行ってみた。

DiKicker を使用

ソフトウェアnDiki で使用している DiKicker を。 コメント機能・トラックバック機能が無いためコラボレーション的な要素はあまり望めないかもしれないが、RSS フィードもあるし社内情報発信のとっかかりとしては十分かと。

そのかわりにキーワードで串刺し表示する機能を使ってプロダクト名やプロジェクト名など決まったテーマをまとめて読み進めることができるため、社内利用には向いているのではと考えている。

検索機能が無いのは痛いので、早めに手当てする必要あり。

運用

特に全社的に強制導入とかではなくて、まずは自分が試行錯誤しながら運用してみるといった感じで進めるつもり。 自分がガンガン情報を書いて、メールに permalink を貼りつける。

メンバに定期的に見てもらうには、随時小ネタをしこむ必要があるかなぁ。 他にも書く人が現れて、社内での RSS 活用が進めばしめたものである。

ちなみに各人が使うのは DiKicker にこだわるつもりは全然無くて、適当に設置してくれればと考えている。 DiKicker 社内で使っている Wiki (WiKicker) と同じ文法とはいえ細かいところは便利じゃないので、むしろ違うものが流行ったほうがいいかなとも(数人は一緒に DiKicker を使ってくれると嬉しいけど)。

ある程度 alpha な人が開設し揃って波がおきたら、普通の人でも簡単に書けるような環境を整備してより広めていきたい。

[ 5月16日全て ]

2006年11月16日 (木)

すき焼きを食べつつリーダーシップ議論

会社の人に誘われて 万世秋葉原本店 7F 七福神ですき焼き

すき焼き

うちのが作るすき焼きは特殊で、「焼」というより「煮」に近い。 小さい時からそれがすき焼きだと思っていたため、普通じゃないと知ったのは大人になってさらに随分たってからだ。

そんなせいで「普通」のすき焼きの作法はよくわからず、気がつけばいろいろ奉行していただいてしまった。

話題

話題としては、会社の話や仕事の進め方の話とか。

私としては、メンバがうまく自律的に活動し、チーム内でのコラボレーションを最大限引き出し、全体として効果的な成果を上げるよう導くのがリーダーの役目と考えている。

強権的に高負荷をかけることで成果があがりまた部下の成長が生まれるという階層型でプレッシャーをかけるやり方の訴えには賛同しかねた。

瞬発的に長時間労働するのはアリだと思う。 ただしそれを中長期的に行うのは結果的に逆効果だ。 たった1日遅くまでやっただけで、次の日の効率がガタ落ちしているのを見ることもよくある。

また 100% あるいは時には 120% というが、ゆとりがない状態ではプロセスも組織も硬直し崩壊を招く。

しかも残業代も出さずにそんなことを指示するのは言語道断。

より知的に生産性をアップしなければならないのだ (さて、どうやって?)

[ 11月16日全て ]

2008年7月25日 (金)

社内で Google ドキュメントがブレイクし始めた

今年の春ごろから開発資料やミーティング資料などを Google ドキュメント上で作成して、適宜関係者に共有するようにしてみた。

当初はほとんど自分がオーナーのものばかりだったんだけれど

あたりで利用するようになったのではと推測。

特にリスト系はスプレッドシートでコラボレーション(共同編集)できるのがやはり魅力的なんだと思う。 同時にアクセスしている人が表示され変更もリアルタイムに見えるためライブ感があり、「一緒にやっている」という感覚が味わえるのがポイントだ。

ちなみに Excel も共有ブック設定することで同時に編集できる(Joel on Software でもこの機能を「Excel についてあなたが知っておくべきこと」の1番目として紹介している)。

BTS/ITS は専用のシステムを使った方が tracking その他の点で機能的にはよいのだが、億劫で設置自体がなかなかされなかったり、使い方を覚える(思い出す)のが面倒で敬遠されるということも多い。

小規模なら共同編集可能なスプレッドシートでシンプルに運用するのもアリだと思う。 っていうか、シンプルでいいから最低限のことはやっておかないと。

[ 7月25日全て ]

2009年11月13日 (金)

今日のさえずり - 年間 36500 tweets 相当か

2009年11月13日

[ 11月13日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.054348s / load averages: 0.53, 0.49, 0.50
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker