PJ活動お役立ちコラム
第21回　2021年04月20日
見落としがちなプロジェクト情報の残し方のコツ（前編）

データの時代に、プロジェクト情報を残すことの重要性はあらためて指摘する必要もないと思います。でも、いざ何か残そうと思ったときに自分のプロジェクトの「何を」残せばいいのか、悩まれたことはありませんか。また、逆に、前任者あるいは先行プロジェクトから情報を引き継ごうとして、欲しい情報が揃わず困った経験はありませんか。
情報の残し方にも様々なコツがあり、落とし穴があり、それを回避するための工夫と知恵があります。今回はそのなかで、近い将来のデータ活用を意識したプロジェクト情報の残し方について、2回に分けて考えてみたいと思います。

最低限のプロジェクト情報を残す

プロジェクトとして残すべき情報と言うと、

といったものがすぐに思いつきます。一番ベーシックな部分で悩むところは無さそうですが、実はこの中にも落とし穴がいくつかあります。

情報の残し方にルールが必要な理由

たとえば、「プロジェクト期間」。具体的にどのような情報を残すか突き詰めて考えると、意外に一筋縄ではいかないと気付きます。「期間」はスタートとエンドの日付を指すのか、終了日だけを指すのか。スタートの日付はプロジェクト発足日なのか実作業を始めた日なのか、あるいは受注（指示）を受けた日なのか。終了日は成果物をリリースした日なのか、それをエンドユーザーが使い始めた日なのか、あるいはプロジェクト報告会を行った日なのか。そもそも「日付」は「○○年○○月○○日」なのか「○○月」なのか「○○年度」なのか・・・企業やプロジェクトによっては「○○年度第1四半期」や「FY20/1Q」のように示す慣習もあったりして、意外なほど選択のバリエーションがあるのです。

そこで、各人が各人の判断に任せて情報を残すと、同じ「プロジェクト期間」という項目に、雑多な様式の雑多な情報が混在することになります。実は「プロジェクトリーダー」、「メンバー」等についても同じことが言えます。得てして「○○課長」「××社△△さん」といったように、会社名あるいは肩書きで個人を特定しようとしていまいますが、これも「雑多な様式が混在」する元凶と言えます。

その場では、報告する側にとっても報告を受ける側にとっても必要十分な情報なのですが、後になって振り返ると「この時点で課長だった○○さんと言えばあの〇〇さんか」「この8月というのはボクがこの部署に異動してきたころだから2017年の8月のことだよな」といったように、誰かの頭の中の知識を借りてきて「紐づけ」を行う必要が出て来ます。「たぶんAはBだろう」という「類推」が行われる余地があるわけです。これらの情報をもとに他プロジェクトと比較したり、傾向分析を行うといった「データ活用」の場面を考えると、データとしては使いにくい（データの信頼性の点でリスクがある）状態なのです。

さらに時代が下ってその紐づけを行える人すらいなくなると、もうデータとしては無意味になります。むしろ害悪をもたらしかねない「ノイズ」として除去する必要が出て来るケースもあります（紐づけ可能な同姓データと混同してしまう恐れがあるので中途半端な情報は無い方が良いと判断されてしまう）。せっかく残した情報が「ノイズ」扱いされ使ってもらえないのは残念ではありませんか。

これを避けるには、情報の残し方にルールを設けることです。
プロジェクト期間も、プロジェクトメンバーも、そのプロジェクトに携わっていた人から見るとごくベーシックな情報です。発足年月日と実作業開始年月日と各フェーズの終了日と報告日とを克明に残すことも、また自分やメンバーのフルネームや所属情報・職位情報・それにそれが何年何月時点の情報だったのかをきめ細かく残すことも、多少煩わしいことをいとわなければ、全く困難ではない作業です。時間で言えば数分ないし数十分でほぼ完璧な情報を残せるはずです。ルール化されていない情報を、後世の人や、当時のメンバーと面識もなく関わりも浅い第三者が、つなぎ合わせようとするから困難が生じるのです。決められた様式で決められた情報が残っていれば、誰も迷わないわけです。

今回は、情報の残し方にルールが必要である理由をお話ししました。
次回は、ルール化するために今すぐできることをお伝えします。

> 見落としがちなプロジェクト情報の残し方のコツ（後編）