機能開発タスクの設計資料のテンプレートを作成してみたら、担当機能をもっと愛せるようになった

はじめに

この記事は「株式会社ビットキー Advent Calendar 2022」 9日目の記事です。
今回はWork & Experience Product所属の@usu_shinが担当します！

ビットキーでは日々多くの機能開発が行われています。その中で発生する"設計"という工程でどう考えていくのが良いのかを型化し、設計資料のテンプレートとして表現したので、この記事ではそのテンプレートを紹介させていただきます。またテンプレート作成の副次的効果によって、担当する機能に愛情を注げるようになったというところも少しだけ話をさせていただきます。

この記事でいう設計とは

この記事ではアサインされた機能開発タスクをどのように理解し、どのような手法で完了まで持っていくかを決定していく作業を設計と呼んでいます。
実装上の技術的決定を行う行為を指す設計よりも広義な意味で設計という言葉を使用しておりますのでご注意いただけますと幸いです。

そもそもなぜテンプレートを作成しようと思ったのか

大きく理由は以下の3つになります。

• 設計を行うにあたって、どう考えていくべきかを型化し、効率化したかった
• 機能をアップデートしていくにあたり、どの段階でどういった意思決定を行ったのか履歴を残したかった
• レビュワーに考えが伝わる資料にしたかった

設計を行うにあたって、どう考えていくべきかを型化し、効率化したかった

型を用意する以前の自分は機能開発を行うにあたって、必要そうだと思ったことを殴り書いていっていました。
思考プロセスに再現性がないため、次設計を行う時にも同じように思いつくものを殴り書きます。効率的じゃありませんね。
設計では様々なことを考え、そしてこれには多くの時間を必要とします。型を作ることで時間のかかる設計という行為を少しでも効率化したいと思いました。

機能をアップデートしていくにあたり、どの段階でどういった意思決定を行ったのか履歴を残したかった

ビットキーでは日々多くの機能をスピード感持って開発しております。目まぐるしい日々を送っているともう半年も前のことを思い出せなくなります。
「あれ、なんでこの機能作ったんだっけ？」、「なんでこんな実装にしてるんだっけ？」という状態に陥りがちでした。
その度にSlackの会話、コミット履歴やPull Requestを検索していく...そんなやり方で開発を行っていました。非常に無駄で非効率です。
そんな経験から、なぜ今この状態になっているのかという意思決定の履歴を残しておくことで、機能を適切な方向へ成長させていけるのではないかと思いました。
そして、資料を遡った時に当時の状況がすぐに理解できるフォーマットがあった方がいい、というのが一つのテンプレート作成のモチベーションになっていました。

レビュワーに考えが伝わる資料にしたかった

設計という工程は非常に重要だと捉えています。設計が丁寧でないと、「作ったけどあんまり意味がないものになってしまった...」、「よくわからない仕様すぎて機能改修つらい...」なんてことが発生してしまいます。設計に多角的な視点を加え、設計品質を向上させる取り組みの一つとして他者のレビューを受けることは一般的かと思います。ただ、設計の意図が伝わらなければ品質を向上させるための議論は生まれないと思っています。伝わる資料であることは設計品質を向上させるための一つの要素だと考え、伝わりやすい形式にしたいと思ったのもテンプレートを作成しようと思った動機の一つです。

最終的に作成したテンプレート(MarkDown)

## 1. 本資料で決定したこと

## 2. 決定に至る背景
### 期日
- 設計完了期日
- 実装完了期日
- リリース完了期日

### なぜこのタスクが発生したのか？

## 3. 比較・検討内容
### 理想描画

### 現状と理想のGap

### スコープ定義

### Gapをどう埋めるか

### 影響範囲

## 4. 実装TODO

## 5. 外部チーム連携TODO

## 6. 関連資料・参考資料

テンプレートの各項目の説明

実際に作ってみたテンプレートの各項目について説明していきます。

1. 本資料で決定したこと

この資料の中でどういった意思決定を行ったのかをここに記載していきます。
時間が経ってからこの資料を読んだ時に、一目で当時の記憶が蘇るように一番上に記載します。

2. 決定に至る背景

期日

ほとんどのタスクには期日が設けられています。設計を行うにあたっていつまでにこの機能を顧客に届ける必要があるのかという観点は非常に重要です。お客様に機能を届けなくてはいけない日から逆算し、リリース日、設計完了期日、実装完了期日をここに書いていきます。

なぜこの機能が必要なのか？

なぜこの機能を開発しなくてはいけないのか、どんな問題を解決したいのかを明確にしていきます。
この"なぜ"を明確にしていくことで機能の方向性が見えてきます。
"なぜ"を突き詰めていった結果、機能開発が必要ない問題だと気づく時もあるかもしれません。
その場合は開発を行わないという意思決定でも良いと思います。
納得のいく機能を開発するためにも機能の必要性を考えていきましょう。納得いかないものは好きになれませんからね。

3. 比較・検討内容

理想描画

機能の方向性をより明確にするために、今から作る機能がどのような状態になるべきなのかを記載していきます。
どうすればユーザーの抱える問題を最高の形で解決できるのか、技術的にどういった形になるとグロースさせやすいのか。
様々な視点から思いつく理想を書いていきます。一旦、現実的かどうかは置いておきます。
個人的にはここが一番重要であると思っています。なぜならこの工程を怠った場合、絶対にその機能を好きになれないからです。ここがこの記事の結論と言っても良い部分になりますね。
機能開発は単発のリリースで終わるものではなく、幾度とアップデートを繰り返し成長させていくものです。成長させるための愛情が注げるように好きになれる機能を考えていきましょう。
とはいえ理想は人それぞれ異なるもの。自己満足にならないように気をつけましょう。よく私は資料をここまで書いた段階でレビューをもらって他者の視点を入れてもらいます。

現状と理想のGap

理想が描けたところで現在の状態を把握し、理想に到達するためにどんな問題点があるのかを洗い出していきます。
問題点の全量や詳細から理想への道のりがどの程度長いのかを把握します。

スコープ定義

問題が洗い出せたところで2の"決定に至る背景"の内容と照らし合わせて現実的な落とし所を決めていきます。
どこまでのGapを埋めれば今ユーザーが抱えている問題を解決できるのか、期日に間に合うのかを考えていきます。

Gapをどう埋めるか

スコープが決まったところで解決すべき問題をどう解決していくかを一つずつ考えていきます。
技術的な話、仕様の話をここに記載していきます。

影響範囲

Gapを埋めることでどの領域のどういった機能に影響を与えるのかを記載していきます。
これにより設計レビューを依頼すべき相手を把握したり、テスト観点を確認することができます。
例えばWeb、iOSアプリ、Androidアプリが共通で使用するAPIを修正する必要があるのであれば、各領域のEngineering Managerにレビュー依頼が必要であり、既存機能に影響がでないかをテストする必要があると理解することができます。

4. 実装TODO

実装上のやるべきことを考え、スコープ達成までの具体的なTODOを列挙していきます。
スコープ達成に必要なことを整理するだけでなく、この内容は進捗を見える化する役割もあります。
例えば

- [ ] リクエストの型をxxxに変更する
- [ ] クラスAのBメソッドをxxxのように修正する

のようなTODOを列挙し、終わったらチェックしていくことでやらなくてはならないことの全量に対して実際に完了していることが自分および他者から見える状態になります。
あと何やれば終わるんだっけ？がすぐわかる状態にあるのは管理する側としてもありがたいかと思います。
また、設計段階で実装のTODOを決めておくとPull Requestのコード行数が肥大することも防げているように思えます。
私はTODO一つ達成するごとにPRを作成したりするので、レビュワーの負担も軽減できているのではないかと思います。

5. 外部チーム連携TODO

自分が所属しているチーム以外に対して働きかけるべきことを列挙します。
例えば

- [ ] Webの画面改修に伴い、新規デザイン作成依頼をUIデザインチームに依頼する
- [ ] iOSアプリチームに新規エンドポイントを使用してもらうように変更依頼を行う

などの依頼事項を列挙します。
案件に関わるような機能なのであればビジネスサイドの担当者に機能の説明を行ったり、実際に触ってみてもらったりもするので、その依頼を行うことも本TODOに該当します。
タスクは自分の担当するプロダクトのデフォルトブランチにコードがMergeされて終わりではなく、適切な人を巻き込みながらお客様へデリバリーして完了となります。そのためあえて実装TODOと項目を分け、

• 検討した影響範囲から必要なアクションを具体化する
• お客様へデリバリーするところまで具体的に考え抜く

を徹底させるようにしています。

6. 参考資料

この設計を行うにあたって前提とした設計資料や参考にしたドキュメントをここに記載します。

さいごに

結論、開発する機能は思いっきり理想を描いて、理想に向かって成長させていきましょう。そうすれば機能を愛することができます。
もちろんテンプレートを作成したことで抱えていた問題を解決できています。背景の理解不足による不具合、考慮漏れや意味のないものを作ってしまった…ということが削減されたと思っています。また、手探り感が消えたことで設計が今まで以上に楽しく行えています。

ここまで読んでいただきありがとうございました。

以前登壇させていただいた内容を以下に添付いたしますのでもしよければご参照ください。

• ロッカーを中心にユーザー体験をConnectしていくために限界まで汎用的に考えたお話
  • 資料
  • YouTube

明日の「株式会社ビットキー Advent Calendar 2022」は @arasan01 が担当します。
"SwiftUIにユーティリティファーストなCSSの知見を取り込む考察"と題した非常に面白い記事になっています！
iOSアプリ開発者は必見の内容になっているので是非読んでみてください！