nDiki : コラボレーション

情報発信 Blog 開発 Wiki 社内 Wiki 事後評価セッション 社内 Blog KPT アイデア メール ソフトウェア ノウハウ ソフトウェアかんばん 2005年 適応型ソフトウェア開発 Google ストーリーカード タスクカード メモ 納品 秋葉原 知識共有 ナレッジマネジメント グループウェア 会議 ミーティング コミットメント 3D WiKicker Google ドキュメント

■ すごいKPT事後評価セッション

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

@ 招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

• 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
• 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
  • スコープ、スケジュール、リソース、欠陥レベル
  • プロジェクト運営
  • コラボレーション (スタッフ間)
  • 個人・チームとして学習した点
  • その他 (開発手法など)
• 問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
• 良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
• 問題点は Problem です。(KPT法流)
• 問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
• 問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
• 注意点 (「適応型ソフトウェア開発流」)
  • 良かった点を必ず書いてください。(すごい会議にも通じる)
  • 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
  • 特定の個人を批評はいけません。
• 事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

@ セッション

メンバは4人。 ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。 次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出れば ホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。 「担当」と「期日」を明確に設定 (すごい会議流)。

@ 完了

合計90分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。 成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」2度目 (2005-06-03)
• いまいちパッとしなかった「ふりかえり」 (2007-02-28)
• すごい会議の正しい手順 (2005-07-04)

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

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

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

@ 長所

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

@ 短所

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

@ 効果的に行うには?

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

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

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

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

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

• すごいKPT事後評価セッション (2005-10-07)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• 「すごい会議」をしてみる (2005-05-27)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• すごい会議の正しい手順 (2005-07-04)

■ ソフトウェアかんばん

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

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

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

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

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

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

• B6 情報カードを使う。
  • この大きさだと書くにはちょうど良さそうだが広い壁が必要になりそうだ。
• エクストリーム・プログラミングのように、まずはストーリーカードを作成する。
  • 今回はベースとなる仕様書の機能を実装する形。ビジネスサイドがストーリーカードを作るという体制にはできないので、開発チームでストーリーカードをおこす。
• ストーリーカードからのタスクカードおこし。
  • 時間の関係から、まずは優先度の高いストーリーカードを選んでこれをタスク化する。
  • タスク化済みのストーリーカードは(tなどの)マークをつける。
• タスクカードのカテゴリは「TODO」「DOING」「CHECKING」「DONE」の4つとする。
• 開発者は TODO タスクカードから1枚カードを選んで署名して DOING へ移す。
• タスク作業完了後「DONE」あるいは「CHECKING」へ移す。
  • 「CHECKING」はチームはタスクを受け持った人が作業完了後、チームでチェックをして欲しい時に入れられるカテゴリ。
  • カテゴリ名はこれでいいかな?

まずはこれでスタート。

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

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

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

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

• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• 京大式カード (2005-10-26)
• Joel on Software - 必読書 (2008-08-14)
• WiKicker でソフトウェアかんばん (2007-03-01)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

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

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

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

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

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

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

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

p.s.

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

• すごいKPT事後評価セッション (2005-10-07)
• いまいちパッとしなかった「ふりかえり」 (2007-02-28)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• ソフトウェアかんばん (2005-10-28)
• 紙ベースのファイリング (2005-11-08)

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

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

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

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

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

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

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

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

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

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

• 作業風景 (スライドショー)

• 冷蔵庫が不調だとこんなにも不安になるものなのか (2005-06-24)
• CLIE マルチスタイラス購入 (2004-03-11)
• TC-1 復活! (2003-05-20)
• 秋葉原にベルギーワッフル専門店がオープン (2007-07-28)
• [ 秋葉原 ] マハーポーシャ (2004-02-28)

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

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

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

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

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

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

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

@ issue tracking

開発中に発生する

• モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
• ライセンス関連の問題など意思決定を要するもの

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 30分ルール

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

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

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

• ソフトウェアかんばん (2005-10-28)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• すごいKPT事後評価セッション (2005-10-07)
• すごい会議の正しい手順 (2005-07-04)
• WiKicker でソフトウェアかんばん (2007-03-01)

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

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

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

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

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

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

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

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

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

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

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

あたりか。

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

[ アウトプット主義 ] [ 書評 ]

• 私が情報発信を勧める理由 (2006-07-26)
• 社内 Blog 開設 (2006-05-16)
• Hyper Estraier で社内 Web コンテンツ検索 (2006-06-01)
• Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)

■ 社内 Blog 開設

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

@ DiKicker を使用

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

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

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

@ 運用

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

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

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

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

• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• mixiに登録 (2004-11-19)
• Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
• 最近の Twitter ステータスを nDiki 「最近のさえずり」ページ... (2007-11-23)

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

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

@ すき焼き

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

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

@ 話題

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

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

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

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

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

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

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

• 今日のさえずり - それ多分 Gmail spam フォルダの中 (2007-12-27)
• コラボレーションを促進するオフィスレイアウトへ (2006-03-11)
• 緊急出荷 (2005-02-28)
• ハンバーグお持ちしました (2006-01-02)
• CLIE マルチスタイラス購入 (2004-03-11)

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

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

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

• Google アカウント作成が行き渡ってきた。
• あるソフトウェアの BTS がうまくまわっていなかったので、不具合リストを Google ドキュメントのスプレッドシートで作ってリリース前に集中的に共有してバグ潰しをした。この一件で便利さが伝わった。

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

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

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

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

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

• 自分が個人で開発したフリーソフトウェアを自社製品に組み込むとき (2005-05-16)
• 影舞プロジェクトテンプレートを作っておく (2005-05-26)
• Joel on Software - 必読書 (2008-08-14)
• 今日のさえずり - 首なし犬 (2008-03-26)
• やっぱり3時間では終わらなかったすごい会議 (2006-07-21)