第4回(最終回)担当者で情報を共有し、引き継ぐノウハウ開発環境の整理術

 結局、情報は人に依存する。組織内では異動、退職、新規参入などさまざまな種類の人の出入りが起こる。同時に情報は更新され、消滅したり、追加されたりする。刻々と変化する情報を整理することは、開発プロジェクトを円滑に運営する必須条件だといってもいい。今回はそのノウハウをお伝えする。(アットマーク・アイティ編集局)

» 2005年01月05日 12時00分 公開
[田中友子(SourceForge 技術担当),VA Linux Systems Japan(株)]

問題:負荷が特定の人に集中する/開発中に問題が発生するリスクが、スケジュールや分担に考慮されていない/担当者変更のダメージが大きい

  開発作業の進行に伴いさまざまな情報が蓄えられていきます。それは、(実装時に調べた)技術情報であったり、問題の解決方法であったりします。このような情報を開発者全員で上手に共有できればノウハウとして蓄積されます。しかし、問題を調べた人(あるいは解決した人)がチームに無断でその情報を隠匿(いんとく)していたりすると、進まない作業や解決できない問題の発生率が異常に高くなります。そして、そのような作業や問題から派生する新たな問題を担当することになるスタッフが、さらにその人だけの領域で問題を増殖させていくという悪循環を招く可能性があります。

 問題を解決する人は往々にして、(解決)作業の方法をチームに説明して情報を共有するという作業に自分の時間と工数を費やすよりも、1人でやってしまう方が簡単で効率がいいと考えがちです。意図的に(問題を)隠し持つつもりはなくても、進んで自分の得意な作業をし続けた結果、「その人」しか知らない作業や技術ができしてしまった、ということもあると思います。しかし、「その人」が長期の休暇を取ったり、出張に出かけていたりして連絡が取れないと、顧客や別チームの人たちなどに多大な迷惑をかけてしまいます。

 このようなことが積み重なると、新しいプロジェクトが始まったときに、柔軟な作業分担ができず、全体的な進ちょく状況に深刻な影響を及ぼします。特定の作業を特定の人にしか担当させることができないため、個人に対する作業の依存度が増し、作業負荷を考慮したスケジュールを立てることができません(作業負荷が集中するわけです)。こうなると、過去のプロジェクトの失敗や改善の経験を生かすことができず、いつまで経ってもリスクの精確な見積りもできません。日々発生する情報を効果的に共有し、再利用できるように工夫をすれば、このようなの問題を軽減することができるのです。

整理術的解決方法

(1) 情報を集める場所を決める

 個人個人がそれぞれの作業をローカルに抱えてしまっているようでは、結果としてプロジェクト全体の見通しが悪くなります。完全なものでなくてもいいので、ある程度のものができあがったら、それが文書であれ、ソースコードであれ、単なるテキストファイルであれ、開発メンバー全員が参照できるように管理するべきです。全員がこまめに情報を更新すればするほど、現在進行している作業の状況(進み具合や担当者)を逐次確認できます。

 このような環境を構築する第一歩として、「変更が発生したらとにかくここに登録すればいい」「情報を探したいときはとにかくここを探せばいい」という場所を決めます。当然ながらこの場所は、全員がアクセスしやすい場所です。また、できるだけ場所が分散しないようにするべきでしょう。

 情報の整理は関係者全員が共通のルールに従って行うようにします。どんなに素晴らしい管理方法でも、ほかの人が管理しているモノの意味や位置付けを理解できなかったり、情報を探し出せなかったりすると意味がありません。あらかじめ整理する対象や場所など共通のルールを決め、全員がそれに従って保存して初めてチーム全員にとって意味のある情報になります。

(2) 作業中心に情報を整理する

 文書やソースコードは思い付きで作るのではなく、何らかの作業の結果として作るのが普通です。プロジェクトに必要な作業をあらかじめ一覧表にまとめ、その一覧を索引的に活用しながら文書やソースコードを整理すると、情報の参照性が増します。

 ある新しい作業(A)を開始するとき、以前行った作業(B)で作成した文書を利用するとします。あなたはまず「以前行った作業(B)時に作成したあの文書はどこにあるかな」と考えます。おそらくこれは普通の発想だと思います。ゆえに、作業スケジュールとその作業のアウトプットを何らかの方法で管理していれば、それらの作業で生成した文書やソースコードの検索性も高まるわけです。

(3) 作業の経緯を記録する

 一般的に、作業一覧の管理は、作業担当者のスケジュール管理や最終成果物を作成するためのマイルストーンの明示化などを目的として行われますが、開発プロジェクトにかかわるさまざまな情報の整理が行えるという副次的な効果を発揮します。開発作業中に調査した技術情報や問題の解決策は、作業一覧インデックスから検索できるようにすることで、チーム全体の共有財産になるわけです。このような包括的なインデックスの作成と同時に、日記のような気軽さで、作業の経緯を記録するのも、情報共有という観点からすればチームに意外と役立つものです。「今日はこの作業で○○という技術が必要だと分かった。明日調べてみよう。△△でつまずいて、計画どおりに作業が進まなかった」などのメモを残すだけでも、チーム全体の作業効率を改善する一助になります。

(4) 作業の経緯を記録しやすい環境を作る

 「いずれ役に立つから作業中に作成した文書(やコード)を保存しましょう」といっても、開発チームの全員を動かす動機付けとしては弱いと思います。単なる呼びかけで終わらせるのではなく、作業の経緯を記録しやすい環境を構築し、チーム全員を自発的な行動に導くことが必要です。例えば、「情報の容器」(文書なら文書を管理するためのディレクトリやフォルダ、作業一覧ならそれを管理するためのデータベースあるいは表形式のファイル)を準備します。このような「情報の容器」を準備したうえで、開発チーム全員に情報の提供、入力を促します。

 開発プロジェクトにおける作業の一覧と作業の経緯をチーム全員に公開し、情報共有の効果を経験的に理解させるのも1つの手です。特定の作業の担当者とその担当者が行っている作業の細かい経緯がチーム全体に明らかになると、従来よく分からなかったほかのスタッフの作業内容とその進捗具合がガラス張りになります。たとえ隣に座っている人でも「昨日この人はいったい何をしていたんだろう」と疑問に思うことがありませんか? 「どこまで進んだか聞こう」と思ったら休みだったとか……。作業一覧表をみるだけで、ほかのスタッフがどういう作業に取り組んでいるか分かるようになります。その結果、ほかのスタッフの作業ノウハウを参考にしたり、自分の作業との整合性を保つよう心掛けたりといった工夫が各人の間で生じ、開発作業の効率があがっていきます。各人の作業が公開されますので、作業能力をアピールする場(評価される場)にもなります。

(5) 情報を検索しやすい環境を作る

 作業情報の集中管理体制を構築できたら、次に、情報の積極的な利用を促す仕組みを検討します。つまり、情報を検索しやすくする環境を考えるのです。わたしたちは蓄積した情報を再利用することで、開発作業の効率性を高めようとしているわけですから、必要な情報を見つけ出すのに時間がかかるような管理方法では問題があります。

 例えば、各情報に作業担当者の「名前」と文書作成者の「名前」を記載するスペースを設けるとしましょう。この場合、名前はフルネームで記載するのか、あるいは姓名でなく、社員番号だけにするのか、姓と名の間にスペースを入れるのかなど、記述方式の標準を確定しておかないと、「名前」をキーワードに情報を検索することが非常に困難となります。過去3回の記事の内容すべてに共通することですが、情報を入力する人が、情報を登録する場所・登録内容/項目・登録形式/書式に悩まなくて済むような環境になるように、工夫する必要があります。


 ……以上、ソフトウェア開発プロジェクトの宿痾(しゅくあ)である作業の個人依存性の高さから抜け出すためのアイデアを紹介しました。ソフトウェア工学の観点からいえば、プロジェクト管理に属するテーマですが、ここでは現場のエンジニアの視点から、すぐに取り掛かれるチーム全体の情報管理方法を提案してみました。

著者プロフィール

田中友子

 VA Linux Systems Japan (株)、SourceForge 技術担当。米国製構成管理ツールやコラボレーションウェアの日本語化作業およびテクニカルサポートに従事。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ