どんな開発プロジェクトであっても,開発の過程では様々な課題*1が生じる。チームはそれらを一つひとつ乗り越える,あるいは回避して前に進まなければならない。本連載でも,第18回第19回において「ふりかえり」という方法でチーム内に発生する課題を表出化*2させ,どのように解決するかを紹介した。ふりかえりは一定の期間ごとに実施するワークショップだが,どちらかというと個々人が感じている隠された課題を表出化させて共有することが目的だ。

 開発現場では,その時々で仕様や設計についての疑問や問題,欠陥(バグ)などが発生する。TRICHORDチームでは,これらをイテレーション終了時のふりかえりまで持ち越す形にはしていない。これらの問題は,即座,あるいは最低でも1日以内にチーム内で共有して何らかの対応をとらなければならないからだ。

 こうした問題は,一般的には問題管理表のようなExcelシートや,課題管理システムに登録して共有したうえで,対応することが多いだろう。TRICHORDチームでもTracという統合プロジェクト管理システムを使って課題を管理している。ここでは,こうしたシステムに登録する前の問題共有に着目したプラクティスをご紹介しよう。

 TRICHORDチームでは,A2サイズのスチレン・ボード(掲示物を印刷して張っておくボード)を一枚置いておき,メンバーが問題と思ったこと,あるいはチーム全員に伝えたいことがあれば,付せんに書いて張っておくことにしている(写真1[拡大表示])。毎日朝会(スタンドアップ・ミーティング)の後に,一つひとつ付せんの内容を確認しながら切り分けていく。課題や欠陥であれば課題管理システムに登録してバグレゴ*3に積む。メンバーに周知するだけで済む内容であれば,付せんを破棄して終わりにする(図1)。筆者はメンバーに伝えたいことを付せんに書いてボードに張っておき,翌朝にそのことを伝えるだけ,という使い方もしている。その一方で,即座にタスク化して実施する場合もある。


写真1 付せんとスチレン・ボードで課題を共有する様子
[画像のクリックで拡大表示]


図1 付せんに書かれた情報の遷移
課題管理システムに登録してバグレゴに積むこともあれば,メンバーに通知した後,すぐ破棄することもある。

[画像のクリックで拡大表示]

 課題管理システムに登録する前にわざわざ付せんに書いて張っておくのは,メンバーがそれぞれ問題だと思うことをチームで共有しておきたいからだ。共有も「メーリング・リストに投稿」や「システムに登録」という段階に入る前に,直接本人の口から説明し,必要があれば質疑応答した後で共有したいと考えている。 切り分けはその後でよいのだ。少なくともメンバーの間では直接共有することで,課題に対する誤解や不明点が生じるのを防ぐことができる。

 この意味では,とりあえず直接課題管理システムに登録し,翌朝チェックするという方式でもかまわない。ただ,スチレン・ボード+付せんの方がより軽快だ。

 TRICHORDチームでは,意識して実施していることが2つある。1つは,課題を全員で共有することである。課題への対応やその決定はリーダーやマネージャが行うこともあるかもしれないが,まずはチームでどんな課題があるかを共有しておくことが大切だ。チームのメンバーはチーム内で発生している課題を知る権利がある。

 2つ目は,「○○に登録してあるから見ておいて」ではなく,「否が応でも見なければいけない場面」を作りだす必要があることだ。これはメールによるやりとりでもそうだが,席が近くにあるにもかかわらず「メールを送ったから見ておいて」だけではあまりにも効率が悪すぎる。確かに,メールは距離感をなくすことができる。だが,対話が生み出すリアルタイム性やワイドバンド・コミュニケーションまでは再現できない。

懸田 剛

チェンジビジョンでプロジェクトの見える化ツール「TRICHORD(トライコード)」の開発を担当。最近,ハックという言葉よりも“工夫”という素晴らしい日本語があることを再認識した。工夫の積み重ねが“功夫”になる。個人サイトはhttp://giantech.jp/blog