調べられるものをいちいち覚える必要のない“しくみ”を作らないといけない

プロジェクトの中で、プロジェクトチームの情報共有のためにプロジェクトを介してやり取りされる情報を補完するリポジトリを利用しているプロジェクト数はどれだけあるのだろう。例え、プロジェクト情報を溜め込むリポジトリがあるとしてもどれだけ積極的にプロジェクトメンバが能動的に利用しているのだろうね。

「メールとファイルサーバがあれば十分でしょ？」と言われても
ワタシの感覚は、未だ多くのプロジェクトがメールベースで情報をやり取りしていて、プロジェクトに関する情報もメールに蓄積していると感じているんです。特に、インフラ構築のプロジェクトでは顕著ではないか、と思うんですが。

だから、プロジェクトの工程が進んで試験工程になってアプリケーション側から「仮想OSのリソースが要求と違う！」なんてクレームがつくとパラメータ仕様書を見ればまだいい方で、リソースを確定するに至ったメールを探そうとする輩が出てくる。プロジェクトでファイルサーバがあるにしても、詳細設計書やパラメータ仕様書などやプロジェクトで要求されるレビュー記録があったとしても。仕様検討の経緯やそれを詰めるための打ち合わせ議事録が残っているかどうかまではわからないでしょう。特にね、途中から参画したメンバにとっては。

「いやいや、メールとファイルサーバがあればそれを探せばいいじゃない。」と言うかもしれない。でも、それ本当にそのしくみだけで十分なのだろうか。本当は、ソレしか知らないからソレを過去に使った経験からだけで言っているのではないだろうか、なんて思ってしまうのは歳をとったからだけなのかな。

プロジェクトの途中、システムの構築が始まるとそのためのメンバが計画どおり増員されることになるけれど、そのときに参照するファイルサーバがいつも最新のドキュメントを閲覧でき、パラメータを決定するための仕様を決めた経緯が閲覧できるのであればそれほど拘らなくてもいいのかもしれないけれど。現実問題としてはファイルサーバへのアクセス権限が読み書き可で設定されている現状からみれば、どれが最新の設計書でどれが1つ前のバージョンかを新規参入組のメンバが誤謬なく閲覧できるかどうかは怪しさ満載なのだと思うんです。

それにさぁ、excelとかwordとかいちいち開かないとその中に見たい情報があるかどうかなんてわからないじゃない？

調べられるものをいちいち覚える必要の無い環境を作る
人の記憶は曖昧だらけだ、ともうすぐ50歳を迎えるワタシは日々思う。ホント、厳しいねー。フィジカルな面で。いや、割とね、どうでもいいことは覚えているんです。だから、あのとき「こういった経緯で仕様を決めたよね。」なんて言えるんですけど。

とはいえやはり、忘れてしまうものは忘れてしまう。それは関心を持ち続けられる対象であれば覚えているけれど、関心を持てない対象は覚えていられないのです。多分、それはワタシだけではなくて、程度はあるにつけプロジェクトメンバも同じなのだ、と思うし思いたい。

そんな曖昧な記憶を当てにするのではなく、プロジェクトに必要なのは“覚えている必要のない環境づくりだ”と思うんです。そのしくみづくり自体も“プロジェクトマネージャの仕事なのである”と。だって、プロジェクトの構成管理の方針を決めるのはプロジェクトマネージャだもの。

であるなら、メールは用途を限定しないといけない。なんでもメールに押し込んでいてはいけない。だって、

メールクライアントが飛んでしまったらどこから復旧する？
メンバが抜けてしまったら過去の経緯を知る人がいなくなるよ。
メールの宛先に入っていなければ知る由もないよ。
後から参画したメンバは過去の経緯が人伝でしかわからないよ。

メールは連絡手段であると割り切って使用した方がいいと思う。それより、プロジェクトマネージャはいつでもそれまでの経緯をメンバが調べられるしくみを用意した方が良いと思う。それは、構成管理のしくみ、情報共有のしくみ。しくみの具体的なツールは何でもいいけれど、リポジトリのバージョン管理ができるしくみは必要です。アウトプットがなぜその形になったかその経緯の情報を残しておくためにテキストデータを残せるしくみが必要です。なぜか。

そのしくみを用意しなければ、キーパーソンはプロジェクトから抜けられなくなるから。

それを無理して抜けてしまうと後に残されたメンバは迷子になるんですよ。それはそれでまた抜けた人がいちいち召喚されてしまうんです。

バージョン管理のしくみに入れておくといいもの
設計書やパラメータ仕様書を登録しておく他にこれは入れておいた方がいいものかあります。1つは、設計の仕様決めの検討資料は当然残すとして、やり取りしたメールがあるならそのメールを“○○仕様検討会yyyymmdd”とかディレクトリを作って入れておく。全部じゃなくていい。仕様を手打ちしたメールとか。製品ベンダの見解とか。手間だけど、後になって理解の相違があったとき、そこに戻れるんです。で、メールだと送信日時が残っているのでそれで関連するメールのあたりを付けることができるので。

テキストデータとして取っておいた方がいいもの
テキストデータはWebサービスのしくみに残しておくのがいいです。Officeアプリでは開かないと何が入っているかわからないですからね！wikiでもいいし、ポータルでもいい。案件ごとに手軽に作成できるチケットをお勧めしますけど。

で、テキストデータとして取っておいた方がいいもの。1つ目は、パッケージを使用しているなら製品ベンダーへの問い合わせ。いまどきの製品ベンダとの問い合わせはベンダのWebサイトでやり取りすることもあるけれど、べろっとコピペしてチームで共有できるところに置いておいた方がいい。それは、ベンダへの問い合わせは問い合わせた本人しか閲覧できないことが多いから。そうするとチームの中で共有できないので。

もう一つ、検証用の仮想サーバなどのシステム環境の特権ユーザやパスワードやスペック、パッケージのバージョンなどの情報。意外とノーコントロールであることが多いんです。検証環境を作った人しか知らないので都度聞いてたり。

メンバに能動的にしくみを使ってもらうために
一貫してそれを使ってもらうためにメンバを躾けること。何事も中途半端はいけないですよ。情報が分散してしまうから。それでは必要な時に都度目的のものを探す手間がバカにならないですもん。そして見つけられない。そんなことにならないために、1つの場所に溜め込み続けるんです。プロジェクトが終わるまで。