読者です 読者をやめる 読者になる 読者になる

冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

プロジェクト見取り図がすごく便利

チームビルディング その他

公開されている良い方法をパクるのに遠慮はしません(少しは遠慮しろ。

先日よりこれを取り入れてみました。

背景

  • 細かいプロジェクトが多い
  • プロジェクトは並行する
  • 多くの人に手伝ってほしい局面があったりする

上記の様なチーム状況で、各プロジェクト間でサポートの調整したりするために、以下の観点で状況を把握したいと思いました。

  • 今、各メンバーが何を担当しているか?
  • 今、注力すべきことに注力しているか?

モノは?

プロジェクト名とかメンバー名とか出せない情報もあるので、ごめんなさい。やってることは上記スライドと一緒で、デザインが違うだけです。

何で作ってるの?

Keynoteです。アイコン画像やパーツなどをそろえておけば、特に自動化とか考えなくても良い手間だと思いますよ。というか、更新するという行為の中で状況が把握できるということもあるので、このくらいだったら私が手で更新すべき、と思ってます。

更新するタイミング

まだ始めたばかりでペースがよくわからないので、今はだいたい以下のどっちかにしています。

  • リリース完了したら
  • 週次のチケットの棚卸しで状況が変わってたら

完了したものには、1週間くらい完了がわかるマークを貼っといて次の更新時にプロジェクトの枠ごと消します。

一手間のビジュアルが持つ情報量

作るときには、注釈とか文字情報とかをなるべく載せずに、ビジュアルで表現できる情報を念頭に置いてます。こうすることで、手間(だいたい一回の更新で15分とかそこら)の割に得られる情報量が非常に多くなって重宝しました。ぱっと見で、だいたい状況が把握できるんですよ。この「だいたい」というのが重要で、判断をするために見なくても良い情報を削ぎ落としてくれている感じがします。

とりあえず、運用進めていく上で工夫したことは以下2点。

  • プロジェクトの色にルール決める
  • Chatworkのアイコンを設定してもらう

前者は、色と数で状況を把握できるような工夫ですね。

運用を開始してからしばらくは、Chatworkのアイコンがデフォルトのメンバーが何人かいたこともあって、名前で書いていたのですが、やはり文字だと把握するのに時間がかかりました。

まとめ

こういう手作業のドキュメント業というのは、どうしても手間として見てしまいがちなんですが、価値のあるものは確かにあります。それから、ビジュアルの情報量の多さというのは圧倒的です。

図示するという一手間はもう少し大事にしても良いかな、と思いました。