導入した経緯
GameWithで攻略・広告関係のチームで仕事をしているtaguchiです。
普段は攻略記事に関係する技術的な仕事全般をしています。
自分たちはもともと少人数で動いているため、チーム内外での意思疎通という面では特に困ることはありませんでした。特定のタスクについての情報共有は、基本的には週１〜２回の会議やSlackでのやり取りで事足りていました。
ちょっとした機能改修やバグ修正であれば上記で良いのですが、問題は一つのプロジェクトの規模が数週間から１〜２ヶ月ほどになった時です。
意思疎通はできていると言えど、そのプロジェクトの区切りが曖昧になるという現象が起きがちになりました。
具体的に述べると、
- そもそも当初の目的が時間経過に伴ってズレてくる
- 何をもってプロジェクトの終わりとみなすのかが曖昧になる
- 目的に沿った機能と目的に沿ってない機能の区別が曖昧になる
といった問題が生じました。
プロジェクト開始当初は完全に意思疎通ができていたとしても、状況は刻一刻と変わっていきます。時間経過によって互いの理解や、プロジェクトの状態についての合意はズレていきます。
この問題に対して何かしら良い対策は無いかと探している内に、デザインドックに行き当たって導入したという次第です。
デザインドックの運用
導入したと言っても、弊チームは少人数で成り立っていることもあり、そこまで厳密な運用はしていません。ルール的に決めていることは
- デザインドックを作る基準
- デザインドックの項目
- 必ず1ページに収める
の３つのみです。
デザインドックを書く基準
全てのタスクに対してデザインドックをきちんと作成するのはコストに見合っていません。そこで、おおよそ２週間以上は時間がかかりそうなプロジェクトに対してのみ書くことにしています。
また、そんなに工数がかからなそうな場合でも、タスクの起案者から話を聞いてみて、開発側でいまいち目的や理由がピンと来なかった時には、デザインドックを書くことを通してそれらを明確にしています。
デザインドックの項目
一般的なデザインドックの項目を採用しています。特別な項目はありません。基本的には以下の通りです。
- 文脈と範囲
- そのプロジェクトが立ち上がるに至った背景
- 対象となる領域
- 具体的にどのような問題が生じているのか、など
- 目標と非目標
- どのような状態になっていることが望ましいか
- 工数などを鑑みて、何をやらないことにするか
- デザインと仕様
- ワイヤーフレーム
- 実装時の挙動など
- プログラム設計
- インフラ構成やテーブル・API設計などの実装に際しての詳細な情報
1ページに収める
ここが肝となるのですが、上記の内容を必ず１ページに収まるように書いています。
外部の人からそのプロジェクトに対して質問された時や、新たに作業者が加わった時に、その１ページを見るだけで概要が掴めてしまう、という状況を目指しています。
外部リンクがある場合にも、ここに導線を置くようにしています。
何が効果的だったのか
デザインドックを書くようになってから、わりとすぐに様々な利点が見えてきました。
不要なミーティングをしなくて済む
弊社はフルリモートで仕事をしています。そのため、定期的なミーティングから外れた話となると、気を抜けばすぐに情報共有漏れが生じます。
その際に「このプロジェクトってそもそも何の為にやっているんでしたっけ？」というような根本の質問が生じると、それに対しきちんと説明するのは結構難しいものです。
いちいちミーティングを開いたり、Slackで長文のやり取りをすると双方にとってコストが高くつきます。しかしながら、デザインドックがあればとりあえず１ページのURLを渡し、「なにか分からないことがあったら聞いて下さい」で済ますことができます。
状況に変化が生じ、当初の目的から外れたことをやりたい場合にはもちろんミーティングが必要となりますが、不要なミーティングややり取りを削減できたという点ではかなり恩恵を受けていると感じます。
目標に沿わない機能を削れる
同じプロジェクトを数週間もやっていると「あそこは○○した方が良いんじゃないか？」といったようなアイディアがどこからともなく出てくることがあります。
リリース期限が決まっているなら新規の仕様は却下されますが、我々のチームでは期限が決まってないことが多いので、以前は雰囲気で実装してしまうことが多かったです。
デザインドックを導入してからは、新たなアイディアが生まれた場合にも、当初の目的に沿っているか沿っていないかで判断することが容易になりました。
結果的に、無駄というか、効果が曖昧な機能を作る必要がなくなり、リリースサイクルが早くなったように感じます。
思考リソースの削減
デザインドックには「目標と非目標」という項目があります。この非目標、つまりやらないことをきちんと書いておくことが非常に重要です。
非目標にわざわざ書く項目は、おおむね目標と非常に近いドメインにある事柄となります。
例えば、目標が
「目標：Aにαの機能を実装する」
だったとしたら、Aに非常に近いA'ではどうしようかと少し話し合った上で
「非目標：今回はA'にαの機能は実装しない」
といった形できちんと書いておきます。
たったそれだけではあるんですが、これによって余計な可能性について考える必要がなくなり、思考リソースを節約できるようになりました。
もし書き残してなかったとしたら、実装開始１ヶ月後くらいのタイミングでAへαの機能を追加しているときに、「もしかしたらA'へも同機能が必要なのでは……？」と考えて、誰かと話し合う必要性が出てきます。
最初に書き残しておくことで、あとから余計なことを考えずに済むようになり、非常に楽になったという体感があります。
もしデザインドックを読んでも必要かどうかの判断がつかない場合には、誰かと話しあった末に書き足しておけば二度手間を防ぐこともできます。
情報へのアクセスが容易
かなり些末な情報や外部へのリンクは別として、ほぼ全ての情報を1ページ内に収めていることがかなり効いています。
プロジェクトを進めていくとそれに伴って情報が増えていきます。実装の詳細な仕様もあれば、そこに至った背景や「やるやら」の話まで、様々な情報で溢れてきます。
だいたいの情報はNotionで管理をしているのですが、Notion上でドキュメント間の導線をうまく作るのも面倒だったりして、どこに何があるのか分からなくなることは少なくありません。
そのため、とにかく1ページに載せておくと決めたことで、ドキュメントを見に行く心理的ハードルが低くなりました。「ここを見ればだいたい分かる」、逆に言えば「ここ以外の情報はだいたい無視してOK」という安心感は非常に大きいです。
まとめ
リモート環境下ではドキュメントをできるだけ書き残した方が良い、というのは概ね誰もが同意してくれると思います。問題はドキュメント書く手間と管理する手間です。
我々のチームでは少人数ということもあり、運用上のルールとしては書く項目と1ページに収めるということくらいしか決めていません。そうすることで、気楽に追記・更新・閲覧ができる状態になっていると思います。
緩い運用でも現状でかなり役に立っているので、ちょうど「面倒にならない」と「役に立つ」が両立できるような形で、今後も活用できていけたらなと思っています。
