事業支援本部GM／VPoEの鈴木です。前回の記事では、クラスの開発組織がどんなチームでできているかをお伝えしました（※1）。

今回はその続きで、チームの中で1週間がどう流れていくかをお話します。

カジュアル面談では「スクラムで開発しています」とお話しすることが多いのですが、この一言で伝わることは、実はほとんどありません。スクラムの運用は、会社ごとにまるで違うからです。

ですので、月曜の朝から、リリースまで。実際の回り方をそのまま書きます。

月曜の朝、前の週に起票されたチケットをすべて確認

クラスの開発は、Jiraのチケットから始まります。起票するのは事業部のメンバーが中心ですが、エンジニア側から起票することもあります。

そのチケットを、毎週月曜の朝に棚卸しするためのMTGを行います。前の週に起票されたものを、1件ずつ順番に確認していきます。

参加するのは、CTOを含む社員のエンジニア全員です。開発と関わりの深い他部署のメンバーも入りますし、要件が複雑で説明が必要なときは、起票した本人にもスポットで参加してもらいます。

ここで確認するのは、実装方法ではありません。この開発で何が解決されるのか、誰がどう困っているのか。目的のほうです。

そのため、この場でチケットが差し戻されることも、そもそもやらないと判断されることもあります。「つくらない」も、棚卸しの結論のひとつです。

「やらない」で終わるチケットは、だいたい3つのパターンです

• すでにできる。「この情報が見えるようにしてほしい」という依頼が、実は別の画面を開けばもう見えている。使い方をお伝えして終わりです。いちばん多いパターンです。
• そもそも起きない。「こうなったときに通知してほしい」という依頼が、仕組みのうえで起こり得ないことだった。実際に起きたこともないので、つくる必要がありません。
• 運用が決まっていない。「この業務を管理できるようにしてほしい」という依頼で、その業務の進め方自体がまだ固まっていない。先に運用を決めてから考え直すことにして、差し戻します。

どれもそのまま実装していたら、使われない画面や機能が増えて、次に触る人の負担も増えていたはずです。

依頼した方に問題があるわけではありません。システム全体を毎日見ているのはエンジニアですので、「それ、いまの機能でできます」と言えるのは、こちら側だけなのです。

エンジニア全員が同席するのは、影響範囲の話が必ず出てくるからです。ECサイト側の改修が倉庫の運用に響くことも、その逆もあります。1件のチケットを全員で見ておくと、その手の見落としが減ります。

1週間で1スプリント。デイリースクラムはチームごとに変えています

棚卸しを通ったチケットは、各チームに割り振られます。そこから先は、1週間を1スプリントとして回します。

短いと感じられるかもしれません。実際、大きな機能は1週間には収まりません。それでもこの単位にしているのは、事業側の状況が変わる速さに、開発の区切りを合わせたいからです。

週の頭にプランニングの場を設けて、誰がどのチケットを持ち、どのくらいの見積もりで、どの順に進めるかを決めます。

一方で、ふりかえりは定例化できていません。ここは正直なところ、これから整えたい部分です。

デイリースクラムは、チームごとにやり方が違います。1日1回のチームもあれば、朝会と夕会の2回実施しているチームもあります。

全チームを同じ形に揃えることは、あえてしていません。扱う領域もメンバーの構成も違えば、詰まりやすいところも違うからです。形式よりも、困っている人がその日のうちに見つかることを優先しています。

1週間で終わらないタスクを抱えてしまうことも、当然あります。次のスプリントに繰り越すこともあれば、タスクの単位を細かく分け直すこともあります。

仕様に悩んだり、技術的に行き詰まったりしたときは、まずチームの中でサポートします。それでも解けなければ、開発組織全体で解決に動きます。

コードレビューは、チーム内と全員参加の2段階

書いたコードは、まずチームの中でレビューします。ここはプルリクエスト上で、非同期にやり取りするのが中心です。

それとは別に、週に1回、エンジニア全員が集まる全体コードレビュー会があります。

コードレビューと言っても、指摘だけをする場ではありません。設計の方針を議論したり、詰まっている課題を持ち込んで相談したり、新しい技術を導入するときに説明したりする場でもあります。

ナレッジ共有の中心も、この会です。ほかのチームがどんなコードを書いているかが見えるので、自分が担当していない領域の勘所も少しずつ溜まっていきます。

正直に申し上げると、レビューは甘くはありません。

動けばよいだけの場当たり的なコードや、保守性の低いコードは通りませんし、開発の目的や要件が曖昧なままであれば、漏れなく指摘されます。

AIは、私たちも開発に積極的に取り入れています。ただ、AIに書かせて、自分が理解できていないコードをレビューに出すのは、NGです。

これらは厳しく聞こえるかもしれませんが、入社して日が浅いエンジニアほど、ここで得られるものは大きいと思います。

あくまで未来の自分や、自分以外にこのコードを保守する人のためにレビューを重要視していると理解していただけたらと思います。

テストは自動と手動の両方。リリースは、基本的に毎日

自動テストはCIで回しています。ただ、それだけでは確認しきれない部分があります。

クラスのシステムは、在庫や配送、返却といった業務とつながっています。画面の上では正しく動いていても、現場のオペレーションとは噛み合わない、ということが起こり得るのです。

ですので、検証環境を用意して、依頼した本人に実際にシステムを操作して確認してもらいます。

自分が起票したチケットの成果物を、自分の手で触る。ここで「思っていたものと違う」が出れば、リリース前に直せます。

専任のQAエンジニアは置いていません。
自動テストと、依頼者による確認と、レビュー。この3つで品質を担保する形をとっています。

リリースは、基本的に休前日を除く毎日です。必要に応じて、1日に数回出すこともあります。

まとめて出さない理由は単純で、変更をためるほど、何が原因で壊れたのかが分かりにくくなるからです。小さく出しておけば、戻すのも簡単です。

そのうえで、業務に影響が出るようなものは、休前日に回したり、影響の少ない時間帯を選んだりします。

クラスのエンジニアの働き方に興味を持っていただけた方は、まず30分だけ話しませんか

この1週間の流れの中で、いちばんクラスらしいのは、月曜の棚卸しと全体コードレビュー会だと思っています。

決まった仕様が降ってくるのを待つ進め方ではありません。何をつくるかを決めるところに、エンジニアが最初から入ります。そのぶん、事業や現場のことを知らないと、判断ができません。

面白そうだと感じていただけたなら、たぶん合うと思います。逆に「決まったものを、集中してつくりたい」という方には、少し騒がしく映るかもしれません。

どちらの感想でも構いません。カジュアル面談は選考の場ではなく、あなたの知りたいことにお答えする場です。

少しでも気になった方は、「話を聞きに行きたい」からご連絡ください。直接お話しできるのを楽しみにしています。

※1 前回の記事「「担当、ずっとこれですか？」——そうはならない開発組織の話をします」

※2 エンジニアカジュアル面談の中身を一部公開！CLASの開発フローをご紹介します！（2023年公開。基本の流れは当時から変わっていません）