新メンバーの初タスクとして「ドキュメント更新」をやってもらうことのメリット

くまごろー
·

ちょっと主観多めではあります

チーム開発でありがちだよなあと感じている課題

  • 参画時は最初に環境構築だったりPJTのキャッチアップをするけど、ドキュメントの情報が古いままになっていて無駄に時間を消費してしまう

  • 「わからないことは何でも気軽に聞いてくださいね」と言われても、参画した側としてはどの段階で質問するかちょっと迷う

  • ドキュメントの情報が古かったり誤っていることに時たま気づいてチーム内で正しい情報を確認するけど、ドキュメント自体は更新されずそのままになっている

「ドキュメント更新」というタスクをやってもらうと良いこと

[前提]

  • 環境構築のついでにやってもらう

  • このタスクについてもっと平たく表現すると「環境構築とPJTキャッチアップのために共有した資料で、間違ってたり情報が古かったりする箇所が判明したら更新しておいてください」という程度のもの

[思ったこと]

個人PCの環境構築って、チームとして開発に携われるメンバーを増やすための大事なタスクだと思うんだけど、どうしても「PCの持ち主のためのタスク」として認識されがちだけど、環境構築に「チームが保有するドキュメントの更新」をくっつけることで、環境構築にかかる作業を「チームのタスク」に引き上げやすくなる

そうすることで、新メンバーはより質問しやすい気持ちになれるのでは?と勝手に思っている。自分の環境構築だけでなく、チームのドキュメントを更新するという役目も担っているので。そして、環境構築の間に何度も質問・相談してもらうことで、コミュニケーション取りながら開発を進めるスタイルの定着にプラスになっているように感じる

また、ドキュメント更新をタスク化することで「ドキュメントは古かったり、間違っている可能性がある(だから、気軽に質問してね)」という認識をチームで共有できる。これは地味に結構大事なのでは? 私自身も手順書通りに進めてもうまくいかなかった時、「もしかしたら資料は合っていて、自分の作業が間違っているのかもしれない」と思って質問するのを先延ばしにしてしまったことがあった(かなり時間を無駄にした)

あと、ドキュメントって、ものすごい慎重に扱われていて変更するのに誰かの承認が必要だったり、変更回数が少なかったりすると誤りがあっても訂正されにくいよね。参画したタイミングでドキュメントの変更に関与してもらうことで、それ以降も(いい意味で)気軽にドキュメントに触ってもらいやすくなる。コードと同じように、メンバー皆で管理するものだという意識を持ってもらえると、各々が気づいた時には更新してくれるようになるし、もし更新が追いついてなかったとしても振り返りなどで「ドキュメントが古いままなのを何とかしたい」といった声が自然にあがりやすい雰囲気になる。

@kumagoro95
その日考えたことをつらつら書いています。