中華大好き！ぼくらのチーム開発 〜日々のタスク篇〜

岡田です。しがないフリーランスエンジニアです。
2020年2月末までとある現場にいたのですが、そこでのチーム開発がとても良かったので、ここに記録します。

チームというのは、人と人の話なので、再現性は低いかもしれません。しかし、すぐに転用できるような小さなテクニックもあるはずです。読んだ方々の現場に活かせれば幸いです。

/* これらは私個人の力で作り上げた物ではなく、当時のチームメンバーAさん、Iさん、Sさん（あいうえお順）の協力があってこそ、実現したものだと思います。とくにSさんは、このやり方の基盤を築いてくださいました。大変感謝です。 */

今回は「日々のタスク篇」です。私たちが日々のタスクを進めていくなかで、大事にしていた事を紹介します。サマリーすると下記の通り。

・タスクはアナログで管理。チーム全員で、自分たちに合ったタスク管理方法をみつける。
・集中すべきことを決める。放置されているタスクはどんどん掃除する。
・チームとしての優先度を決める。レビューがきたら、個人作業は止めて、それを優先する。
・頻繁にデモをしてフィードバックをもらう。デモ後にレビューに出す。
・必ず全員がレビューする。

結論から述べると、実際こんな効果・変化がありました。

・特定機能がバグだらけだったが、バグがほとんど無くなった。
・チーム内の透明性（他の人が何しているかがわかる）が上がった。
・非常に早いサイクルで、どんどん機能をリリースできた。
・目立ったスケジュールの遅延も出なかった。
・コミュニケーションの機会も増えたので、ワイワイとした雰囲気になった。

それでは具体的にみていきます。

＊　＊　＊

タスクはアナログで管理。チーム全員で、自分たちに合ったタスク管理方法をみつける。

タスク管理に使ったツールは下記です。

・ホワイトボード
・付箋
・点シール

（JIRAも使っていましたが、あくまで補助的でした）

実際のボードはこんなカンジです。

デイリー・スクラムでは、このボードの前に全員集合し、タスクの更新・進捗確認をしました。
私たちは、デイリーを朝と夕方の2回していました。朝は今日の目標設定、夕方はそれの進捗確認（進捗が芳しくなければ相談）という内容でした。

デジタルに比べて、アナログで行うメリットは下記です。

「自分たちに合った使い方にアレンジできる」
タスク管理を行うデジタルツールはいくつかあります。しかし、それがチームに合うかはわかりません。一方アナログであれば、自分たちで使い方を柔軟に変える事ができます。後述しますが、「点シール」の使い方はその代表的な例です。

「メンバーが物理的に集まる」
デイリーの際、物理的に人がホワイトボードに集まるようになります。チーム全員がホワイトボード（つまり、全体のタスク）を見ながら話し合うので、着手漏れを減らしたり、気になったことの相談・議論ができます。メンバー同士の単純接触効果も得られます。

集中すべきタスクを決める。放置されているタスクはどんどん掃除する。

なるべくスプリント期間中に集中すべきタスクだけ、ホワイトボードに残すようにしました。
アナログ管理だと、散らかり具合もひと目でわかるというのも利点です。
私たちのチームでは、大抵デイリーのときに「散らかってるのでそろそろ掃除しませんか？」と声が挙がりました。

具体的な掃除方法を紹介します。単純にタスクを消化する以外にも、掃除方法はあります。
ローンチ済のプロダクトでは、エンジニアとして改善したいことは山のように出てきます。もちろん付箋に書いてホワイトボードに貼っていきますが、私たちのチームでは、1〜2週間ほど放置されて残っている付箋は、どんどんゴミ箱に捨てていくようにしました。

これは、「私たちが集中すべきことリスト」の鮮度を保つためです。集中しなくても良い事（または、体力的にいま集中できない事）を残しておいてもノイズになるだけです。また、本当に重要な事であれば、掃除しても自然とまたTODOに挙がってくるだろうという考えもあります。

チームとしての優先度を決める。レビューがきたら、個人作業は止めて、それを優先する。

道具の一覧で「点シール」を挙げました。私たちはチームとして優先する事項（付箋）に、このシールを貼って明確化しました。
ここで強調したい事は、このシールは個人としての優先事項ではない、という事です。私たちが決めたのは、"チームとしての優先事項"です。

シールを貼ったタスクは、"チームとして"絶対優先になります。そのため、そのタスクのコードレビューが来たら、他の作業をしていても、チーム全員が優先してレビューします。

夕方のデイリーでも、シールを貼った付箋がReviewレーンより先に進捗しているかを必ず確認しました。
こうした仕組みを作ることで、個々人が自分のタスクに集中してしまいレビューがほったらかしになるという事が無くなります。

頻繁にデモをしてフィードバックをもらう。デモ後にレビューに出す。

「今週の目標」のシナリオを満たせているかどうかを、必ずチーム内でデモしました。

デモの機会は、週に1回... などというように固定されていません。
メンバーが「デモをしたいです！」と手を挙げたら、その瞬間デモは始まります。もちろん「今週の目標」も"チームとして"の目標なので、他の作業をしていようが、最優先で集まって全員でデモを見ます。

デモのタイミングは、試行錯誤していくうちに変わっていきました。最終的には「コードレビューに出す前」が慣習になっていきました。

・デモに対し、メンバー全員でフィードバックをする
・担当者はそのフィードバックを反映して、コードレビューに出す

上記のフローが定着し、手戻りは圧倒的に少なくなりました。
デモフィードバックにはエンジニアだけでなく、PdMも参加しました。コードだけではない観点（UIなど）のフィードバックも、その場で吸収できます。

また、エンジニア観点では、コードレビューも効率的になったように思います。デモを見て動作のイメージができているので「そのコードで何が起きているのか」を追うのが早くなりました。

必ず全員がレビューする。

チームのエンジニア全員が、コードレビューをしました。フロントエンドのタスクでも、バックエンドエンジニアがレビューに参加しました。逆も然りです。理由はいくつかあります。

「変更が起きたことを知っている人の数が、多ければ多いほど良い」
たとえ文言変更程度の小さなタスクでも、必ずレビューをしました。私はよく「『ここが変更になったのね〜』程度で、さらっと見てください！」とレビューを出しました。本当に見てもらうだけです。しかし変更箇所を知っている人が多ければ、属人リスクを減らす事ができます。

「観点が多いほうが良い」
フロントはフロント、バックエンドはバックエンドと壁をつくれば、レビュー観点が抜け落ちてしまいます。
とくに私は、「命名に関しての観点」が強かったです。これはフロント、バック関係なく適用できる観点です。
私はフロントエンドエンジニアでしたが、バックエンドのコードに対しても、そうした観点で多くのレビューコメントをしました。

「メンバーが他分野も学習し、できる事が増える」
レビューを重ねていくうちに、私はバックエンドのコードも書けるようになっていきました。
技術領域に壁を作らず、少しずつでも個々人のできる事が増えることで目標の実現スピード、システムへの理解度が上がっていきました。（もちろんこの考えは、組織によって合う・合わないがあると思います）

＊　＊　＊

以上、日々のタスクを進めていくなかで大事にしている事でした。
（断片的に網羅していく構成になってしまいました。プラクティスの紹介をうまくまとめるのは難しいですね...）
この記事で、開発をうまく回すヒントを皆さんに与えられれば幸いです。気が向いたら、コミュニケーション・ナレッジ篇、ふりかえり篇なども書くかもしれません。

ちなみにタイトルに中華が着いているのは、チームの中でなぜか『中華一番！』が流行り、よく中華料理店にランチに行っていたからです。※

それではまた！
岡田

/* ※なぜか「〇〇一番！」というワーディングも流行っていました。誰かのファインプレーを褒め称える時には「{lastname}一番！」。今週目標・今日目標も、実際の呼び名は「今週一番」「今日やる一番」でした。あれはいったいなんだったんでしょう。（すっとぼけ） */