こんにちは、poipoiです。

「テクニカルディレクター目線のプロジェクトマネージメント手法」
を考えてみる記事。

今回は、「フロー情報」と「ストック情報」を意識して情報を管理しよう！というお話です。

「フロー情報」と「ストック情報」

皆さんはプロジェクトにおいてどのようなツールを使用していますか？

チャットツールやプロジェクト管理ツール、ストレージツールなど様々なツールを複数使用している方が多いかと思います。

これらのツールは、形態は異なりますが全て「情報」を扱うためのものですよね。
プロジェクトに関わるコミュニケーションやタスク、データなどのあらゆる「情報」を扱い、メンバー間で共有することで円滑にプロジェクトを進行するために使用していると思います。

つまり、「情報」をどのように扱うかがプロジェクト進行において非常に重要という事が言えそうです。

一口に「情報」と言っても先述のようにその種類は様々ですが、私はその中でも大きく「フロー情報」と「ストック情報」に分けて考えると良いのではと思っています。

フロー情報
「フロー情報」とは、その場で流れ去ってしまう情報です。
例えば対面での会話、電話、チャットツール上などで取り交わされるコミュニケーションで、基本的にその場にいる人のみで意思疎通される類の情報です。

ストック情報
「ストック情報」とは、アーカイブされ蓄積される情報です。
例えば、企画書やプロジェクト概要などのドキュメント類、ソースコード、デザインデータ、タスク管理データなど、書面やデータなど何かしらの形で保持され蓄積されていく情報です。

この「フロー情報」と「ストック情報」の特性を理解し、それぞれ適切な形で管理する事が必要です。

情報のオープン性

昨今は従来の中央集権的な手法よりも、メンバーごとがそれぞれの領域で独立して動きながら全体連携を図る、協調分散型なプロジェクト進行が主流になりつつあると感じています。

協調分散型のプロジェクト進行では、個々のメンバーそれぞれが全体の方向性を把握し、自身の行動を自ら決定していかなければなりません。

そのためには情報がいかにオープンになっているかが重要です。

例えば、ディレクタとデザイナーの間だけでデザイン変更の話がなされていたが、それがエンジニアに伝わっておらず実装に反映されていなかった、という類のミスコミュニケーションはよく聞く話かと思います。

これらは情報を適切に管理せず、オープンになっていないことで起こってしまう弊害です。

それぞれのメンバーが独立して動くからこそ、それぞれ個別に行われているコミュニケーション等の情報が、誰の目からでも見ることができるオープンな状態で管理される必要があります。

つまり、情報をオープンに保ちながら、先ほど説明した「フロー情報」と「ストック情報」それぞれを適切に管理していくためのツールを選定する必要があるのです。

フロー情報の管理方法とツール

フロー情報はいかに「キャッチアップ性」を高めるかを考えるのがいいでしょう。

毎日流れる膨大な量のフロー情報すべてに目を通すことは不可能です。
自分がコミュニケーションの当事者の場合にはすぐに気づくよう運用ひながら、その反面、関係ない話題はスルーし必要になった段階で「キャッチアップ」するような運用にするのが効率的です。

そのためには、極力口頭のみでのコミュニケーションを避けチャットツールを用いる。どうしても口頭でのコミュニケーションが避けられない場合でもその内容をチャットツールに転載ようにする。などし、オープンな場に履歴を残し後からさかのぼって話題を追えることが需要です。

また、チャットツールの選定には「通知機能」に注意すべきです。

先述のようにフロー情報は当事者ではない人が適切にスルーできる環境をつくることで効率化につながります。

そのため、すべての会話で参加者全員に通知が飛ぶようなチャットツールを使ってしまうと、自分に関係のない通知が頻繁に発生しメンバーの作業効率の低下を招きます。（Line や Facebook Messenger など。）

Slack などはデフォルトで自分宛てのメッセージ以外は通知されない設定になっており、また通知に関して詳細な設定をすることができ非常にオープンなフロー情報を取り扱いやすいツールになっています。

（具体的なSlackの活用方法についてはまたそのうち書こうかと思います）

ストック情報の管理方法とツール

ストック情報の管理において一番重要なことは「一元化」です。

様々な情報がそれぞれ別々の場所で管理されていると、どこになんの情報があるか把握するためにコストがかかってしまいます。

このコストは管理する情報の量が増えるごとに徐々に肥大化していくため、気づいた時には「え、そんなドキュメントあるの知らなかった」「新しくジョインした人が自分で情報をキャッチアップできない」などの面倒くさい事態を生んでしまいます。

とはいえ、それぞれ情報の種類によって扱いやすいサービスも異なります。
（コードは GitHub、データは Dropbox がそれぞれ適しているなど。）

そのため、Wikiツールなどをそれぞれのサービスに紐づけ一元的に管理することで、「ここを見れば全ての情報にたどり着ける」というような情報の集約地点を作ることが大事です。

また、情報の整理方法を「ルールベース」ではなく「ビジュアルベース」にすることも大事です。

よくストレージサービス上に、「01. 企画」「02. デザイン」… などの名称のディレクトリを作りその中に各データを格納していくような管理をしているプロジェクトを見ることがあります。

こういった方法ですと、そもそもどんな内容のドキュメントにどういった名前を付けてどこに保存すべきか、「ルール」を知っている人でなければ扱えません。

これも扱う情報の量が増えるごとに複雑性が増していき、結局適切に管理されず放置されるような事態を招きます。

またディレクトリ名やファイル名などの文字の一覧を見るよりも、視覚的に適切にビジュアライズされたものを見る方が思考の負担が少なく、直感的に情報へアクセスできます。

そのため、例えば Notion のような編集の自由度が高い Wiki ツールを用い、以下のようにパッと見てプロジェクトの概要がつかめるように「ビジュアルベース」で整理することが望ましいです。

・プロジェクトのキービジュアルやアイコン画像などを配置し、なんのプロジェクトなのかを視覚的に判断しやすいようにする

・全体スケジュールや直近対応が必要なタスクなどをトップビューに掲載し頻繁に把握が必要な項目がすぐに目に入る状態をつくる

・企画概要などの「そもそも何が目的だっけ？」がわかるものを見やすい位置に配置しておく

・技術情報やデザイン関係の情報など、制作にかかわる情報は構造的・網羅的に配置する

（これらを加味した、具体的な Notion 活用方法はまた別途書こうと思います）

このようにプロジェクトの情報管理ひとつとってもいろいろと工夫することで円滑な進行をすることが可能になります。

ということで「フロー情報」と「ストック情報」の話でした。
今回はこのへんで。