はじめに
ユアスタンドでハードウェア・ファームウェア開発担当をしている吉田です。
今回は工数見積もりの可視化についてです。
工数見積もりの伝え方が難しい
前提とメンバー構成
私はハードウェア・ファームウェア(組込みLinux領域)を担当するエンジニアです。
私以外のCTO/PdMを含む開発メンバーのほとんどはアプリ・バックエンドエンジニアという構成で,私は若干技術領域が異なります。
課題
私に限らずほとんどのエンジニアは「このタスクが何日でできるか？」と見積を行うことがあると思います。
私の場合特に周りと技術領域が異なるので以下の問題があります。
- 難易度や規模の見えない見積もり
- タスクの複雑さや前提条件が伝わらず、メンバーは難易度を評価できない
- 仮に私が○○日かかると言っても、メンバー納得感が少ない。
- 高い環境依存リスク
- 製品Aでは実装不可・製品Bなら可能、というハード差も前提に含めないと判断材料が不足
- 実機必須のデバッグ要件
- デバッグに手元の実機が必要なケースでは、リソースやスケジュール調整が不透明になる
これまで過去の作業工数を元にざっくりと見積もっていましたが、セルフマネジメントの観点からも、より明確に言語化・共有する必要性を感じています。
Tシャツサイズを利用した工数見積
Tシャツサイズとはタスクの規模や複雑さをXS、S、M、L、XLといったサイズで表現することで相対的に工数を見積する手法です。
Tシャツサイズを定義しよう
生成AIを利用して定義しよう
以下ステップでTシャツサイズを定義する
- サイズの範囲を決める(XS~XXL)
- ざっくりでいいので自分なりに各サイズの複雑さを定義する
定義例
とりあえず自分でざっくり定義してみた例。
LとXLを基準にちょっと逆算的に書いています。
-
XS（数時間以内）
- 概要：実質的に依存・リスクなし。即時対応可能
- 例：パラメータ変更、文言・コメント修正
-
S（1～2日）
- 概要：既存機能の軽微な修正や設定更新。影響範囲が狭い
- 例：既存モジュールのバグ修正
-
M（2～3日）
- 概要：既存コードやプロセスの改良・最適化。
- 例：ロジック微調整、設定ファイル追加
-
L（1週間）
- 概要：既存アーキテクチャの拡張や小規模な新規機能の実装。
- 例：systemdユニット作成、簡易な動作確認
-
XL（2~3週間）
- 概要：複数コンポーネントをまたぐ新規機能の設計・実装。
- 例：通信プロトコル設計＋実装、新規合わせ込み。
-
XXL（4週間以上）
- 概要：大規模設計・検証・製造を伴うタスク。ハードウェアやインフラを含む領域横断的開発
- 例：ファームウェア全体設計、ハード検討～製造が必要な開発
- 生成AIに取り込んでも案を揉む
GPTからの返答例
あなたの定義はとてもわかりやすく、チーム向けに「粒度」と「技術難度」を両立させていて良いと思います。ただ、もう少し安定運用するために以下の点を検討してみてはいかがでしょうか。
* リスク要素の明示
* XS の定義見直し
→「パラメータ変更」はチーム内では SS になりやすい一方、テスト工数が意外に膨らむ場合があります。
*「不確実性」評価を併せ持つ
定義したTシャツサイズ
ストーリーポイントも合わせて出力しましたが、最終的に以下のように定義しました。
-
SS（1p）
- 作業内容例：パラメータ変更、文言・コメント修正
- 依存度：なし
- テスト範囲：単体テストのみ
- 不確実性：Low
-
S（2p）
- 作業内容例：既存コードの軽微修正（ログ追加／条件分岐追加程度）
- 依存度：内部モジュールのみ
- テスト範囲：ユニットテスト＋結合テスト一部
- 不確実性：Low–Mid
-
M（3p）
- 作業内容例：既存コードやプロセスの改良・最適化。
- 依存度：他モジュール呼び出しあり
- テスト範囲：結合テスト＋インテグレーション
- 不確実性：Mid
-
L（5p）
- 作業内容例：既存アーキテクチャの拡張や小規模な新規機能の実装。
- 依存度：ドライバ／センサ依存あり
- テスト範囲：結合テスト＋システムテスト
- 不確実性：Mid–High
-
XL（8p）
- 作業内容例：複数コンポーネントをまたぐ新規機能の設計・実装。
- 依存度：他チーム／HW依存あり
- テスト範囲：システムテスト＋性能試験
- 不確実性：High
-
XXL（13p）
- 作業内容例：大規模設計・検証・製造を伴うタスク。ハードウェアやインフラを含む領域横断的開発
- 依存度：複数部門調整・HW発注
- テスト範囲：結合テスト＋現地試験＋リグ試験
- 不確実性：Very High
タスクのサイズを評価してみた
定義が完成したので、過去のタスクを評価してもらった。
- **サイズ**：XL（8p）
- **主な要素**
- 並行処理／スレッドセーフ設計
- 他プロセスとのソケット通信・リアルタイム性あり
- 設定の動的更新・状態管理
- 状態の遷移ロジック
- タイムアウト処理
- **テスト範囲**
- システムテスト
- 性能試験
- **依存度**：High
- 他プロセス連携
- 設定ファイル
- 並行処理フレームワーク
- **不確実性**：High
- 並行処理＆デッドロック回避の複雑さ
- 状態遷移ロジックの分岐数
- 通信処理の信頼性確保
### 理由まとめ
1. **新規プロセス開発**（UDP 通信含む）
2. **高依存・高リスク** の要素多数
3. **システムテスト＋性能試験** が必須
4. **高度な並行／状態管理** による不確実性
→ XL（8p）相当と判断できます。
ネクストステップ
これまでの見積は経験や過去の作業を元にしたざっくりしたものでしたが、Tシャツサイズを定義することである程度明確に言語化できました。
ストーリーポイントを活用したタスク評価と改善
Tシャツサイズに加えて、ストーリーポイントを活用することで、各タスクの難易度・不確実性・依存関係をより明確に言語化できるようになりました。
今後は各タスクに対してストーリーポイントを付与し、実際の作業時間や成果と照らし合わせて、見積もりの精度を高めていく予定です。
これにより、個人の主観に依存しがちな工数見積もりを、チームで共通認識を持って扱える指標に変えていけると考えています。
AIを活用した工数見積もりの効果検証ができるようにしたい
今後は生成AIを活用して以下のような効果を検証し、定量的に評価していきたいと考えています。
- 生成AI利用前後のタスク完了時間の比較
- コードレビューやデバッグ作業の工数削減効果
- タスクサイズごとの作業効率向上度の可視化
Discussion