以下は去年の弊社のQiita アドベントカレンダーに投稿したものです。
qiita.com
これはなに？
はじめまして。リンクアンドモチベーションの伊藤です。
主にバックエンドの開発を担当しており、最近はタイトルにあるように新規機能開発や既存機能改善に関わる多くの設計に「レビュワー」として携ってきました。
この記事では私がレビュワーとして開発の「設計」に関わってきた中で、
- スムーズにステークホルダーの認識が揃ったな
- 議論がより深まった上で決定できたな
と感じた設計におけるポイントをまとめてみました。
「設計でなにをしたらいいか迷っている方」
「コーディングだけじゃなくもう少し上流工程に入りたいと思っている方」
の参考になれば幸いです。
そもそも設計って？
この記事では特に「基本設計」について触れていきたいと思います。
実装よりも上流の過程についてはこの記事などを参照ください。
唐突ですが設計フェーズでの難所は 「選択肢を網羅し、判断基準を揃えて、決断する」 ことであると思います。
もし選択肢が1択なのであれば粛々と設計書に落とし込んでいくこととなりますが、多くの開発ではいくつかの選択肢の中から最適と思われる一つを選択しなければなりません。
特にアーキテクチャやライブラリの選定、データベース設計などはほぼ必ず分岐が存在します。
それらの選択肢や分岐の中の1つをステークホルダー間で合意することが設計フェーズにおけるゴールになります。
この合意形成に向けてあらかじめ整理されていたらありがたかったポイントを5つにまとめていきたいと思います。
スムーズな合意形成に向けて意識したいこと
1. ✅ 選択肢を網羅できているか
アーキテクチャやライブラリの選定、データベース設計はもちろんのこと、クラス設計やフロー設計にも複数の選択肢が存在することが多いです。
🙅♂️NGケース: 十分な量の選択肢が存在しない
「え、本当にこれしか選択肢ってないの？」
「あの方法とかもあるんじゃないかな？」
で議論が止まってしまいがちです。
もちろん議論の中で新しく出てきた選択肢は十分な検討がなされていないため、「再度検討します」になってしまいます。
🙆♂️OKケース: 自分の中で「これはないだろう...w」と思っていた選択肢も棄却しない
「案外この方法もいいね」
「この選択肢ではないから、こっちがいいね」
のように納得感を持たせつつ、議論を広げていくことが可能になります。
選択肢は多ければ多いだけ良いので設計フェーズではどのタイミングでも追加していくと良さそうです。
まとめると
- 💡 パターンを網羅しできるだけ選択肢をあげる
- 💡 「ない」と思った選択肢も残す
- 💡 常に新たな選択肢がないか振り返る
2. ✅ 機能要件を深く理解して観点を出せているか
こんな機能がほしい、こういう風にしたいなど開発には必ず「要望・要求」が存在します。
要望・要求を元に機能要件に落ちたものが設計の前段階としてあるはずですが、これをどこまでイメージしきれているかが重要です。
🙅♂️NGケース: 要件を鵜呑みにし、理解が浅い
「このパターンの要件満たせなくない？」
「これだと使い勝手悪くないかな？」
となってしまいます。
🙆♂️OKケース: ユーザー視点で要求や要望まで立ち返り、要件を認識する
「確かにこれならユーザビリティが上がるね」
「こんなユーザーストーリーが増えても対応できるね」
と誰のための開発か認識を揃えながら議論することができます。
要件定義をじっくり見直すことで開発者視点で要件のブラッシュアップも可能です。
まとめると
- 💡 何度でも要件は見返す
- 💡 誰がどう使うかまでイメージする
- 💡 開発者視点で要件をブラッシュアップさせる
3. ✅ 非機能要件も考慮できているか
性能要件やセキュリティ要件といった非機能要件も立派な要件です。
ただ目に見えづらいために要件定義されていなかったり、意識の外から外れがちです。
🙅♂️NGケース: 非機能要件を認識しないまま進める
「これ、誰でもアクセスできちゃわない？」
「こんな使い方されると、レスポンス返るまで時間かからない？」
のように思わぬ指摘を頂いちゃいます。
🙆♂️OKケース: 求められる非機能要件の基準感を定めていく
「これなら今のアーキテクチャでも問題なさそうだね」
「この案に決まりだと思ったけど、システムダウン時のことを考えると他も考えなきゃだね」
と、より議論に幅が広がり、システムとしての信頼性も事前に考慮できます。
非機能要件に関してはシステムを通して共通のことも多いので過去に同様な議論がなされていないか、
またそこから変わった点がないかを確認することも重要です。
まとめると
- 💡 求められている非機能要件が何か明確にする1
- 💡 決まっていなければ決めにいく
- 💡 過去の議論も確認しアップデートがないか確認する
4. ✅ 開発工数や拡張性を考慮できているか
ビジネスサイドからは見えない開発サイドの条件も重要な判断軸となります。
特に開発にかかるコスト(工数) はリリースや費用にも影響するため重要な指標となります。
また技術的負債2とどう向き合うかも1つの観点です。
🙅♂️NGケース: 開発サイドの条件が見えていない
「一見良さそうけど、リリース間に合わなくない？」
「これできるエンジニアいるかな....」
と夢見がちな設計になってしまいます。
🙆♂️OKケース: 正確でなくて良いので工数感や今後の拡張性を見据える
「ちょっと重い開発だけど、今度この機能が出るからこっちにしよう」
「ここまでコスト払う必要があるか評価しよう」
と実現可能性を考慮した議論にしていくことができます。
未来を見据えた開発は賛否両論あるとは思いますがある程度確度の高い要件ならばそれを見据えた拡張性の高い開発も検討の価値があります。
また、エンジニアにとってのわかりやすさも天秤に乗せて判断したいです。
まとめると
- 💡 ざっくりとでも開発工数を見積もる
- 💡 エンジニアにとってわかりやすい構成にする
- 💡 (近い将来を考慮した拡張性をもつ)
5. ✅ 要件や工数のmust/wantと選択肢に対する評価が正しいか
最終的に、1.で挙げた選択肢に対して2~4の判断基準で評価し、どの選択肢を取るのが最適かを合意します。
そのためには2~4で挙げた基準を
- must (絶対に達成しないといけない)
- want (できれば達成したい、強弱やグラデーションがあっても良い)
の二つに分ける必要があります。
🙅♂️NGケース: must/wantで分けない
「この数の条件を全部満たす案なんてなくない？」
「一長一短でどれがいいかわからない」
と途方に暮れてしまいます。
🙆♂️OKケース: ステークホルダーにmust/wantの確認が取れている
「この条件はwantだしバックログに積もう」
「mustを全て満たすのはこの二つしかないからどっちがより最適かwant条件で考えよう」
と議論の方向性や意思決定が後押しされます。
また、各選択肢の判断基準ごとの評価は設計者の無自覚な贔屓が出るので
「ほんとに？w」を繰り返し、できるだけ定量的な評価となるようにしたいです。
まとめると
- 💡 2-4の条件 にmust/want (優先度) を付ける
- 💡 1で出した選択肢 × 2-4の条件 の評価が妥当か繰り返し見直す
- 💡 できるだけ定性ではなく定量的な評価をする
ちょっと簡単な具体例
例えば新機能Aの開発の設計を任された場合、この5つのポイントを抑えて整理すると以下のようになりました。
これを見ると、
- 「新規カラムを追加案」はmust条件を4つも満たせていない
- 「既存カラムを更新案」はmust条件を1つ満たせていない
- 「カラムの追加 + 移行 + 削除案」は出してみたものの、まだ時期尚早だな
ということがわかるので
- この「旧機能Aをこれまで通りユーザーが使うことができる」という要件は本当にmust要件なのか確認してみよう
- 「新機能Bを一括で登録する際のレスポンスは 1s以内に返る」を達成できるオプションはないかな？
- 直近の工数をどこかで確保できないか掛け合ってみよう
のように方針が決まり、ステークホルダーへのアクションも明確になリます。
終わりに
ここまでの5つのポイントを抑えてあれば、どの選択肢を選ぶか決断できたり、推しの案に決定させるために必要なアクションが見えてきます。
もし参考になれば幸いです。
