【PM向け】Googleドライブで起こるプロダクト開発時の課題と整理方法について
はじめに
Googleドライブは、複数の人が同時にアクセスしファイルやフォルダを編集できることで非常に便利な一方で、格納場所やファイル構造が複雑化したり、欲しい資料を探し出せなくなったりするケースがよくある。
弊社では、SaaSモデルの自社サービスを開発から営業まで行っており、主なファイルはGoogleドライブにて、管理と共有を行っている。開発も営業もスピード感持って刻々変わる新しい情報にアクセス・管理できることが重要なフェーズのため、情報管理をミスると後々取り返しがつかない。
そこで本記事では、PMである私自身が現場で感じた、Googleドライブでの課題や限界と、現在実際に使っている運用方針やツールを紹介する。
Googleドライブで一番避けるべき課題
プロダクト開発時に一番避けたいことは、同じファイルが別の場所に格納されてしまうことや、複数ファイルが存在することで最新版がわからなくなること、見つけ出すまでに非常に時間がかかったりすることだ。
通常、フォルダがMECEに分類できていれば、ファイルは重複しないように思える。しかし、SaaSモデルのプロダクトを作っていると、似たようなフォルダ名があちこちで散見される事態が起こるのだ。
例えば、営業時は、複数のクライアントに当たっていく中で個別具体の調整事項や提案資料が出てくる。その数が多いと、クライアントや案件名をフォルダ名に記載していくことが多い。（図1）
一方で、提供プロダクトは、クライアントに関わらず、基本的に1つに集約される。したがってクライアント個別の資料などは載せずに、開発工程で管理されることが多い。例えば、『要件定義』『設計』『開発』『テスト』『マニュアル』などだ。（図2）
そうすると、A社の会議資料内で、提案だけでなく要件定義や設計に関わる話が出た場合に、提案資料内に入れるか、開発物資料内に入れるかで迷いが生じる。（図3）
つまり、一階層目をMECEに分けていても、ルールなしに運用すると再帰的に類似フォルダが登場してしまうのである。
私たちの場合、原因は、クライアントに応じて個別具体的なファイルに分かれる要素と、クライアントに関係なくサービスとして共通化している要素の境目で格納場所に迷ってしまうことであった。
上記のようなフォルダの再帰性を放置すると、どんどんファイルが分散して格納され、後々探したり更新したりするのが大変になってくるので、気づいた時点でできる限り早期で対処することが、何よりもリソースの限られた自分たちを救う。
フォルダの設計思想から決める
フォルダ整理をするにあたり、最終的に目指したい状態としては、『メンバー自身が「何がどこにあるか」把握でき、ファイルを追加・移動するときに、対象フォルダを判断できる状態』である。
『把握できる』というのは、
ファイルに辿り着くまでルート距離が短いこと
ファイルまでの辿り着き方を推測できること
の2点を重視し、階層構造を設計した。
1については、階層を深くしないように修正し、フォルダ追加のルールを周知徹底することで解決する。一方で、2の推測しやすさには、フォルダの再帰性が起こらない設計と運用ルールが必要になる。
私たちのチームでの設計方針としては、フォルダの第一階層目において、下記のA,Bパターンが可能性としてあり、その論点を固めることから始めた。
パターンAは、クライアントや案件ごとにフォルダ化するもの。メンバー全員がどの案件に紐づく資料かを理解・推測している場合は、利用しやすい。
一方で、パターンBは、提案資料、要件資料、開発物、マニュアル資料、契約、などの行為や目的ごとにフォルダ化する。こちらは案件共通の内容や案件ごとの資料を比較のしやすい。また案件や会議名を知らない人にとっての検索性・推測性が高い。
パターンA, Bどちらも一長一短だが、私たちは今後、たくさん入ってくる新規メンバーが理解しやすいことと、SaaSとして各資料の共通化・比較できることを重視し、パターンBを選択した。
フォルダ構成を変更する際にやっかいなこと
上記の変更を進めるにあたっては、変更前後で「この資料がない」「わからない」などのトラブルになることが想定されたため、『変更前に、論点の承認を得る』『変更時の証拠を共有』『運用ルールを整備・周知』の３点を徹底しながら推進した。
具体的な流れとしてはこちら。
現状のフォルダ構成&資料URL一覧化
変更したい点をまとめる
相談ポイントや変更点を関係者に確認
移行作業 （金曜夜などに一気に）
運用ルールと最新フォルダ構成&資料URLの共有
フォルダやファイルの移動時は、一覧表に証拠を残す
ポイントとしては、1、5 の『フォルダ構成&資料URL一覧化』は、手作業では到底無理だったため、スクリプトを書いて自動化した。ツールの作り方・使い方については、次の記事で記載する。
また、フォルダ削除時は、必ず中身が空であることを確認し、タイトルに『xxxxx（空_日付）』を追記してから削除することで、自分の身を守ることをオススメする。
周知徹底
運用ルールとしては、階層が深くなることのデメリットを伝え、フォルダ追加時は、必要最小限の階層でまとめてもらうことを依頼した。
まとめ
本記事では、プロダクト開発時にGoogleドライブで起こる課題と解決策について紹介しました。まとめると
フォルダの第一階層目をMECEに分けても、類似フォルダが分散して出てきやすい
分散すると、資料の検索や格納に時間がかかることや、最新版の管理が担保できないため、早期に対処することが重要
階層構造の設計を決めるために、現状の課題点を理解し、論点を話し合う。
運用ルールとして、設計思想や方針を伝え、フォルダ階層を大きく乱さないように注意喚起する。
運用ルールの周知は一回限りではなく、都度質問を受けた時に対応していくことになるため、課題定義から運用実施までなかなか労力が求められたが、自動化できる部分には助けられたこと、後々大きな事故や探し出せないイライラが募るよりかは遥かに良いことという点で非常に意義のあった対応だったかなと自負しているのでぜひ参考にしていただきたい。
この記事が気に入ったらサポートをしてみませんか？