"爆速開発"を実現するアイミツ開発チーム
アイミツ開発チームでエンジニアリングをしている deliku です!
以前ブログで、FindyTeam+ Award 2022を受賞したことを書きましたが、今回はアイミツ開発チームの発足からこれまでの取り組みを紹介したいと思います。
▶︎ そもそもユニラボはどんな会社か?
私たちは「受発注を変革するインフラを創る」というビジョンを掲げ、
「世の中から発注の失敗をなくし、多くの企業がよりよい受発注をできるようにする」ことを目指しています。そのために、アイミツ / アイミツCLOUD / アイミツSaaS というアイミツシリーズのサービスを展開しています。
▶︎ アイミツサイト開発チームのミッション
サイト開発チームは、アイミツサイト関連でSEO対策をメインにいかに多くの発注依頼をアイミツサイト経由でいただけるかを日々考え開発を行っていいます。
▶︎ アイミツサイト開発チームメンバー
エンジニア、企画、デザイナーはそれぞれ所属部門が異なりますが、サイト開発というワンチームで活動しています。基本リモートで働いていますが、週一で出社推奨日を設けるなどを試行錯誤しています。
▶︎ アイミツサイト開発チームの発足
アイミツは今年の春頃までリプレイスプロジェクトを行なっており、それが完了した 5月中旬から新しく発足したチームになります。
▶︎ インセプションデッキによる共通目標の醸成と相互理解
チーム発足当初に インセプションデッキ を用いて、チームで為すべきことの方向性を確認し合いました。これにより、"チームメンバーが常に同じ方向を向いている" という、大事なスタートがきれたと思っています。
▶︎ 月一のKPT実施
Keep・Problem・Try を用いて振り返りを行います。私たちのチームは開発手法にスクラムを採用しており、レトロスペクティブにてスプリントの振り返りを毎週していますが、月に一度全体の振り返りを兼ねて行なっています。振り返りの際は、美味しいご飯を食べながら少しラフな雰囲気で行っています(KPTを行う日は出社推奨としていますが、必須ではありません)
KPTには、miroを利用して付箋で個々にK / Pを書いて、2-3分で発表します。
最後に Problem を集約して、Problemに対する Try を話し合ってアクションを決定しています。
▶︎ スクラムイベントと関連会議
上述のイベントスケジュールに、スクラムイベントに本来ないMTGが設定されているので補足説明します。
企画会議
サイト開発の企画メンバーが、企画を持ち寄り "Why / What" の説明を行い、プロダクトオーナーから企画承認やフィードバックをもらう会議となります。最初のうちはエンジニアは任意参加でしたが、"Why / What" の説明を聞き、疑問があればその場で確認するほうが効率が良いことが分かったので、現在はエンジニアも参加しています。
設計会議
企画会議で承認された企画を、エンジニアと企画オーナー(企画を起票した人)で "How" の認識合わせや 企画の深掘りを行う会議となります。また、メインの担当エンジニアをつけ、細かい要件の調整は別途個別にやることとしています。企画内容によって話が間延びしたり議論が伸びてMTGの予定時間を超過することがあったためです。
▶︎ 1週間のサイクルは実際に開発していてどうなのか?
1週間は短いです。なので開発に充てる時間を他のことで消費しすぎないように意識しています。
例えば企画が大きい(開発する機能の量が多いなど)ものだと、仕様を調整したり認識合わせをするのにどうしても時間が取られてしまいます。このとき開発する時間がなくなってしまいスプリントの達成が難しくなることが何度かありました。とはいえ仕様をある程度つめないと、ストーリーポイントがブレることで、次以降のスプリントの達成の見通しが悪くなる可能性が上がります。最近は時間をかけすぎす、ストーリーポイントにブレがあることをある程度許容するかたち(不確実性が高いとして、ポイントを増やす)で運用することとしています。
作業で詰まったり、想定外のことがあるとすぐHELPをだし、下手に1人で抱え込んで時間を消費しないようにしています。
▶︎ タスク管理はどのようにしているか?
チーム全体のタスクはNotionで管理しています。エンジニアの場合、着手するタイミングで進行中レーンに移動させ、GithubIssueを起票する運用になっています。Notionを使っていて辛いと感じる点として、サブタスクが作成できない問題があったのですが、バージョンアップで対応いただけるようで嬉しいです。
▶︎ 1日1回以上のリリースサイクル
Notionで管理しているタスクにリリース日のプロパティを設定することで、タイムラインビューを使用することで、そのタスクがいつリリースしたか視覚的にわかりやすくなります。毎日なにかしたらのリリースを行なっていることが下記の図からわかるかと思います。リリースはエンジニアが誰でも簡単にできるよう仕組み化と手順のマニュアルを用意しています。
▶︎ 開発スピードを高い水準で維持するために
何度も読み直している LayerX の資料を掲載しておきます。
複雑な仕様は開発が大変 / 維持も大変(負債となりうるリスクがある)
複雑な仕様は何かが間違っているのではないかと疑問に思う
仕様はシンプルにして、同じ価値を提供できないかを考える
仮説検証段階で本当にそこまで開発するべきか?
「コッテリ」 ではなく 「ヘルシー」にできないか? エンジニアだけではなくプロダクトに関わる人が常に意識する
これらをチームで意識し、小さく仮説検証を繰り返していくことがアウトカムをつかむ最善の手なのではないかと私は思います。
また開発スピードをあげるために、CIの強化やデプロイを誰でもできるようにしていたり、コードレビューの負担を軽減する取り組みなど、開発者体験をよくしていく取り組みを行っています。