はじめに

私は入社・配属されてから4ヶ月間、広告配信に関わるWebアプリケーションの開発を行っていました。そして2019年10月にグループが異動となり、現在はメディア「All About」を中心としたWebアプリケーションの開発に携わっています。このような新卒1年目を過ごした過程で、それぞれ異なる開発の進め方を経験しました。今回は所属したそれぞれのグループでのチーム開発を経験して学んだことを、振り返りも兼ねてお話ししたいと思います。

広告事業時代

オールアバウトでは All About プライムアドという広告プラットフォームを提供しています。私はこうした広告プラットフォームのシステムを構築・管理するグループに所属し、広告を運用するためのCMSの改修や機能追加などを行っていました。グループ内で抱えているタスクは細かいものから大きいものまでありました。細かいタスクについてはそれぞれ担当者が個人タスクとして作業を行った一方で、大きいタスクについては開発リーダー（いわゆる旗振り役）を中心としたチーム開発を行っていました。私はこのグループで、取引先向けに作られたWebアプリケーションのユーザーログイン基盤を構築するというプロジェクトに参加しました。複数のアプリをまたぐシステム構成だったため、もちろんチーム開発によるプロジェクトでした。

ここでのチーム開発の主なステップとしては、

要件定義
ガントチャート作成
実装作業
単体テスト
結合テスト、脆弱性チェック

といった具合で、ウォーターフォール開発を応用した手法をとっていました。

このチーム開発を通して学んだことは主に以下の2つです。

役割分担が明確なのは、一長一短
スケジュールがテストの結果に依存する

これらについて掘り下げていきたいと思います。

役割分担が明確なのは、一長一短

チームでは実装作業に取り掛かる前段階で、メンバーがそれぞれ開発・改修する機能ごとに担当を割り振られました。この役割分担で良かったことは、ガントチャートで計画した通り自分が担当する機能について集中して作業できたことです。これによって、一つのことについて深く学びを得ながら責任を持って作業を行うことができました（今回のケースでは、Cookie・セッションの仕組みなどについて学びました）。しかし、デメリットも存在しました。それはメンバーがプロジェクト全体としての現在地の把握を疎かにしてしまいがちになっていたことです。そうすると、プロジェクトの進行具合を把握するリーダーへ負担がかかります。このような仕組みでチーム開発を進めるときは、チーム全体の進行具合を各々のメンバーがチェックしたり、フォロー体制を整える枠組みが必要だと感じました。

スケジュールがテストの結果に依存する

この開発フローの最後に立ちはだかっていたのが、テストでした。いくらスケジュール通りに作業ができても、テストの結果次第でリリースが延期になってしまう可能性があり、結果としてスケジュールがテストの結果に依存する形になっていました。実装完了後にテストはやるにしても、その前に品質をより担保できるような開発手法（テスト駆動開発など）を取る仕組みが必要だと感じました。

メディア事業時代

2019年10月に異動となり、現在までメディア All About を代表としたメディアの運営に関わるWebアプリケーションの開発・保守を行うグループに所属しています。

このグループでも抱えているタスクは細かいものから大きいものまでありますが、基本的にほとんどのタスクがチーム開発によって行われています。

私の所属するチームでは、1週間を開発期間の1単位（スプリント）として、毎週水曜日に

スプリントレビュー
リファインメント
レトロスペクティブ
プランニング

といった形で、振り返り、要件確認、作業計画を行い、それに基づいて業務を遂行していく、という方法をとっています。いわゆるアジャイル開発の中のスクラムの枠組みです。

このチーム開発を通して学んだことは主に以下の3つです。

属人化を防げる
アウトプットへの意識が高まる
振り返りは大切、ただし改善をしなければ意味がない

これらについても掘り下げていきたいと思います。

属人化を防げる

私の所属するチームでは、大小問わず持っているタスクに全て優先順位をつけて作業計画を立て、ホワイトボードに付箋を貼る形でそれらを管理しています。（現在は、新型コロナウイルスの影響で原則在宅勤務となり、Trelloによる管理をしています）チーム内のタスクはメンバー共通のものであり、誰が担当、というものはありません。タスクを遂行するにあたり発生したドキュメントはメンバー全員に見える形で共有し、誰にバトンタッチしても良い状態を作ります。このようにして、チーム内タスクの「属人化」を防いでいるため、チームの作業の進捗状況は常に把握できていますし、誰かに負担が集中したり、誰かがいなくなって困るという状態が発生することもありません。個人的には途中までやっていたことを他のメンバーにバトンタッチをすることでもどかしい気持ちになることもありますが、円滑にチーム開発を進めるにはとても良い枠組みだと思いました。

アウトプットへの意識が高まる

先述の通り、チームでは1週間ごとに要件確認と作業計画を行っています。その際できるだけ多くのアウトプットを出すために、リリース納期やROIを確認しながらタスクに優先順位を付けます。そして、チームメンバーの稼働時間内に遂行できるタスクの作業計画を優先順位の高い順から立てていきます。こうして出来上がった作業計画に基づいて業務を遂行するので、自然とアウトプットへの意識が高まります。例えば、「この機能がリリースされればこれだけ収益性が高まる、コストを抑えられる」といった具合に、アウトプットをすることによって得られるメリットに注意が向きます。このようにアウトプットへの意識が高まることは、ただの作業者ではなく、会社の収益に貢献するビジネスマンとしての視点も養われると考えられるので、とても良いことだと感じました。

振り返りは大切、ただし改善をしなければ意味がない

チームでは必ず1週間ごとに振り返りを行っています。主に使用しているのは「KPT」ですが、1週間の中で何か大きな課題があった場合はそれについて時間をとって議論することもあります。 KPTでは、Keep（続けたいこと）、Problem（課題に感じていること）をブレスト形式で洗い出し、リストアップしたものについて議論を行い、最終的にTry（次の1週間で挑戦すること）を決定します。その次の振り返りでは前週に決めたTryがきちんと達成できているか確認をします。特に何か失敗してしまったとき、同じ失敗をしないためにも、振り返りは大切です。何ができて、何ができなかったか自分にとっての反省になりますし、他のメンバーの意見も聞ける貴重な機会になります。そして、振り返りから改善に繋げることも同様に大切です。私の所属するチームでは課題改善のためにTryを設定していますが、2週連続で同じTryを設定したことがあります。この状態を続けてしまうとチームは成長しない、ということが手にとるようにわかったので、改善することは重要だということを学びました。

終わりに

本記事では新卒1年目の私が2通りのチーム開発を経験して学んだことについてお話ししてきました。どちらが良いか、悪いかということではなく、何を学んだかということを意識して振り返ることができたのはとても良かったです。これからも一人のエンジニアとして、こうした振り返り（と、改善）を重ねながら経験を積んでいきたいと思います。