TwitterFacebookRSS Feed
アンチパターン社における非同期的なプロダクト開発のナレッジ(202107スナップショット)

アンチパターン社における非同期的なプロダクト開発のナレッジ(202107スナップショット)

こんにちは。

株式会社アンチパターンのCEO兼VPoEの小笹です。

株式会社アンチパターンでは、「日本のソフトウェアエンジニアを憧れの職業へ」を目指して、AWSエンジニア特化型のマッチングプラットフォーム「engineed」を開発しています。

engineedの開発は、フルタイムのメンバーだけではなく、社内のメンバーがサイドプロジェクトとして関わっていたり、外部の副業やフリーランスの方々が多数関わっていたりします。

前提として、優秀なソフトウェアエンジニアは生産性が非常に高いです。
なので、少ない時間でも優秀な人がプロダクト開発に関わってくださることは、大きな価値を生みます。
しかしながら、多くの企業がまだ副業者の活用に関して、ネガティブなイメージを持っていたり、うまく活用するイメージをもっていないように思います。
(私自身がengineedの営業を行う中で感じていることなのでやや定性的ですが)

そこで、非同期的なプロダクト開発を進めていくナレッジをシェアすることで、少しでも啓蒙活動になればいいなというのと、より多くの優秀なソフトウェアエンジニアに参画いただきたいと思い、筆を執りました。

本項では、非同期的なプロダクト開発に関して、

  1. 時間的な流れに着目した開発の流れ
  2. インクリメントに着目した開発の流れ

で整理しています。

概要

体制

  • プロダクトオーナー：1名
  • スクラムマスター(仮)：1名
  • 開発チーム(ソフトウェアエンジニア)：9名
  • 開発チーム(デザイナー)：1名

技術

  • 環境：Docker
  • フロント：TypeScript / Vue.js / Nuxt.js / Vuetify
  • API：Go
  • DB：PostgreSQL
  • ソース/課題管理：GitHub
  • インフラ：AWS

----------2022-04-06-10.27.12

1.時間的な流れに着目した開発の流れ

スクラムじゃない？

私自身認定スクラムマスターの資格を持っておきながらなんですが、engineedでは「スクラムを採用している」と言っていません。
というのも、スクラムというと設定されたイベントや確約をしっかり実行/設定している感じに受け取られますが、それは難しいと感じているからです。

やめたこと

スプリントゴールを設定すること

1週間を周期(スプリント)とおいて各人が開発に取り組んでいますが、その週どれくらいの時間をプロジェクトに投じれるかは本人も分かりません。
なので、スプリントゴールを定めて、それを果たすぞ！と息巻いたところで、正直何にもならないのです。
アンコントローラブルなものは、アンコントローラブルなものとして扱うべきです。
なので思い切ってスプリントゴールを設定することをプロジェクトの初期段階でやめました。
当然ベロシティは計測しプロダクトのロードマップは引きます。

スプリントプランニング/デイリースクラム

多くのメンバーがサイドプロジェクトとして参画していることもあり、同期で行うイベントを設定するのが難しいです。
なのでスプリントゴールを設定しないことと合わせて、スプリントプランニングとデイリースクラムをなくしました。
実施しているのはスプリントレビューとスプリントレトロスペクティブ、そしてウィークリースクラムです。

労働時間を管理すること

週ごとに何時間働くかを管理していません。実績を見ることはします。

実施していること

ウィークリースクラム

その週やったこと、次やろうと思っていること、困っていることを発表します。
もし、その週稼働できなかったら、ちょっと忙しくてできませんでした！と発表してもらいます。
それでは、問題の検知が1週間ごとにしかできないのでは？と思われる方もいるかもしれませんが、問題は発生した時、その場で共有し、その解決にフォーカスすべきだと考えています。

スプリントレビュー

最近は毎スプリントリリースしているので、プロダクトの最新版を共有しつつ、ビジネスのことも含めてシェアします。
この際、発表はプロダクトオーナーがしております。
基本的にはみんなでプロダクトの成長や発展を喜んでいるセレモニーとなっています。

スプリントレトロスペクティブ

そのスプリントの結果などをスクラムマスター(仮)の僕がシェアします。

発表の内容

  • 何がリリースできたのか？
  • そのスプリントで消化したISSUEの総計ポイントはいくつだったか？
  • 今後どのような変化が予測されるか？

発表を踏まえてチームでのふりかえりを実施します。

RetroSample.001

  • What was Good?
  • What was Bad?
  • Ideas
  • Action

という4象限を使っています。
Miroにあったクイックレトロスペクティブをそのまま採用しています。
ファシリテーションはスクラムマスター(仮)が行っています。

より非同期で開発しやすいようにWikiの更新がActionになることがあります。

時間的な流れ

月：スプリントレビュー/スプリントレトロスペクティブ/ウィークリースクラムを実施します。
火~金：割と夜に開発が進む傾向にあります。
土日：もりもりと開発が進みます。

スクラムじゃないとしても

イベントなどは全然違いますが、その三本柱たる「透明性」「検査」「適応」は実現できていると思っています。
また価値基準に関してもかなり高い水準で満たされています。

確約（Commitment）
プロダクトを通した理念実現に向けて互いをサポートすることを確約しています。

集中（Focus）
プロダクトを成長させるためにそのスプリントで可能な限り集中して作業します。

公開（Openness）
全ての作業はGitHubのカンバンを活用し全メンバーが見られる状態になっています。
作業途中でもプルリクエストを出し、他メンバーに作業を引き渡すなども行われています。

尊敬（Respect）
各メンバーは独立した一個人として尊重して扱われます。誰しも時間の制約はあれど、出来うる限りの確約をしてくれることを信頼しています。

勇気（Courage）
ただでさえソフトウェア開発は難しい中で、非同期に行うことは困難です。皆そのことに勇気を持って向き合ってくれています。

スクラムじゃないとしても学んできた内容は開発フローの中に詰まっています。(アジャイルではあると思ってます。)

これからも大事に育てていきたいと思います。

2.インクリメントに着目した開発の流れ

なるべく各人が非同期に活動できるようワークフローや技術面も工夫しています。

engineedDevFlow.001

青：プロダクトオーナー、デザイナー、スクラムマスター(仮)
緑：開発チーム

Selection_345

プロダクトバックログ(ISSUE)を作る

ここは主にプロダクトオーナーとスクラムマスターで議論をしていきます。
2人ともユーザーやクライアントと直接やりとりをし、何故その機能を作るべきなのかをしっかり設計します。
その部分が後ろの工程で行われる開発の品質に関わることを知っているからです。

デザイン

プロダクトバックログをもとにデザインに起こします。
engineedではAtomic Designを採用しており、AtomをなるべくVuetifyのコンポーネントで表現しようとしています。
なので、基本的にはVuetifyを見ながらFigma上にデザインを作っていきます。
大抵2~3案あげて、議論を深めます。
デザインが不要な機能に関してはこの工程をスキップします。

設計/API定義

画面が必要なものはFigmaとプロダクトバックログを、必要でないものはプロダクトバックログをもとに、データモデルを設計をします。そしてAPI定義を行います。
コンフリクト防止とフロント側への開発影響を極力少なくするために、OpenAPIを使ってスキーマファーストなフローにしています。

ISSUE分割

必要に応じてフロントとAPIにISSUEを分割します。その際もとのプロダクトバックログは親ISSUEとして設定します。
この時点でISSUEにはS/M/Lの規模見積もりを付与します。
これはベロシティの計算に活用しつつ、その機能の実装時期を見積もる際に活用します。
ISSUEにはラベルが設定されており、anyoneというラベルは誰でも取っていいなどルールが設定されています。

開発

フロントとAPIでそれぞれレーンを設けてあり上から順に開発していきます。
フロントもAPIもどちらもできる人はプロダクトオーナーと相談したりその時の状況を見てよしなに取っていってもらいます。
着手したらIn Progressレーンにチケットを移動させます。

システムテスト

Front：スナップショットテストは必須としており、ロジックの部分は徐々に増やしていっているところであります。
API：ユニットテストとインテグレーションテストを必須としています。
Front、APIともにプルリク作成時にGitHub Actionsでテストが走り、すべて通った上で、別のメンバーによるレビューを受けないとマージできない仕組みとなっています。

受け入れテスト

プロダクトバックログが要求を満たしているかを確認します。
確認ができた場合はチェック完了のラベルをISSUEにつけます。
不具合や追加の要望があれば、ISSUEを戻すのではなく、新たにISSUEを起票します。

デプロイ

そのデプロイのバージョン(メジャーなのかパッチなのか)とデプロイ先の環境(内部向けかユーザー向けかなど)によって作業内容や確認方法を変えています。
人の手をなるべく介さないようにCI/CD環境を整えることも必要です。
1スプリントに1回リリースできるといいなと思ってやっております。

提供したインクリメントが価値を発揮しているかは様々なデータをもとに分析し、より良いプロダクトになるように意識しています。こちらも大事に育てていきたいと思っています。

最後に

ソフトウェア開発って楽しいですよね！

プロダクト開発を進める上で重要だと思っていながら汎用的じゃないなと思っていること

engineedのプロダクトオーナーは優秀なソフトウェアエンジニアです。なので、LayerXさんが定義しているようなProduct Engineering Managerと言っていいと思います。彼自身が技術的なところもかなり踏み込んで開発チームと密なコミュニケーションをとって、技術的な側面も含めて戦略を策定していますし、直近の戦略では彼自身がビジネスのマネジメント権限を僕に一時的に委譲し、開発に入るということも実行しています。ソフトウェアエンジニアリングの知識があるプロダクトマネジメントってとってもいいなと思うので、これも啓蒙していきたいところです。