営業職の俺がエンジニアになる〜群馬Web化計画編〜

2017年に未経験からエンジニアに転職をした私が群馬でイノベーションを起こすまでの備忘録です。

何でも良いから日報だそうというルールが生んだ副作用

「チーム開発を楽しく学ぶプロジェクト」(そろそろ覚えやすい名前を考えたい)にて、日報を提出してもらっているのですが、その日報提出を行うことで素晴らしい副作用が生まれたので備忘録として共有したいと思います。

これまでの日報提出のルール

本題に入る前にこのプロジェクトでのこれまでの日報提出のルールについて紹介します。といってもかなりシンプルなのですが

1. フォーマットは下記のものを使用

# 今日やったこと
# 明日やること
# 困り

2. 何もなくても空の日報を提出すること

というルールで運用をしていました。ちなみに、この日報提出はスクラム開発で言うところのデイリースクラムを簡易化したものです。本業があるメンバーもいるので、流石に毎日ビデオチャットで会議をするわけにも行かないので、このスタイルを取ることになりました。

気づいたら変わっていたこと

上記のルールで運用していたのですが、気づけば「とある暗黙のルール」が追加されていました。それが「プロジェクトに関わらないことでも日報に書いてOK」というルールでした。

個人的には「まぁ何も書かれてないよりはマシかな」という程度に思っていたのですが、これがすごい副作用を発揮しました。

副作用とは?

さて、本題に入るとしましょう。上記のルールで運用をして生まれた素晴らしい副作用というのが、「継続的な日常の振り返り」ができる様になったということです。

当初私が日報制度を取り入れた目的は下記のとおりでした。

  • 開発進捗を追うこと
  • 困りがあれば手を差し伸べられる状況を作ること
  • メンバーとの接点を最低限持てるようにすること

要は管理がしたかったのです。仮に日報がなければ、誰が何をやっているかがわからないことは愚か、接点を持つこともままならなくなるので、おそらくかなり初期段階でこのプロジェクトは頓挫していたことだと思います。できる限り少しでもプロジェクトを前に進めたいという思いからこの日報制度を取り入れたのでした。

でも、「プロジェクトに関わらないことでも日報に書いてOK」という暗黙のルールが追加されたことにより、「日常の振り返り」を「継続的に」行う機構が生まれたわけです。

ただし、この機構はまだ発展途上で、全メンバーが日常の振り返りをしているわけではありません。ごく一部のメンバーがたまたま日常の内容を書いてくれていただけです。それ以外のメンバーは空の日報を提出してくれています。

そのため、今の段階では「暗黙のルール」として運用されてはいますが、次回の定例にてこれを正式な「第3のルール」として定義し、次回以降のスプリントでどういった化学変化が起こるのか?を観察したいと思います。