プログラミングの「ゴールドプレーティング」を避ける方法

みなさん、プログラミングで「もっと機能を追加したい」「もっと完璧にしたい」と思って、結果的にプロジェクトが遅れた経験はありませんか？

これは「ゴールドプレーティング」と呼ばれる現象で、多くのエンジニアが陥りがちな罠です。 必要以上に機能を追加したり、過度に完璧を求めたりすることで、かえって価値を損なってしまいます。

この記事では、ゴールドプレーティングの正体から具体的な回避方法まで詳しく解説します。 効率的で実用的な開発を実現したい方は、ぜひ参考にしてみてください。

ゴールドプレーティングとは？

基本的な概念

ゴールドプレーティング（Gold Plating）とは、プロジェクトマネジメントの用語で、要求されている以上の機能や品質を追加してしまう現象のことです。 プログラミングの文脈では、「必要以上に高機能・高品質なソフトウェアを作ってしまう」状況を指します。

語源と意味

「ゴールドプレーティング」は、本来の金属製品に金メッキを施すことから来ています。 見た目は豪華になりますが、実用性やコストパフォーマンスを考えると必ずしも良いとは限りません。

プログラミングでのゴールドプレーティング例

• 過剰な機能: 要求にない機能の追加
• 過度の最適化: 必要以上のパフォーマンス追求
• 完璧主義: 100%の完成度への固執
• 技術の誇示: 新しい技術の無意味な使用

よくある具体例

機能面でのゴールドプレーティング

例1：シンプルなToDoアプリ

## 要求仕様
- タスクの追加・削除・完了
- シンプルなリスト表示

## ゴールドプレーティング版
- タスクの優先度設定（5段階）
- カテゴリ分類機能
- 詳細な統計とグラフ表示
- SNS連携機能
- テーマカスタマイズ機能
- 音声入力機能
- AI による自動分類

この例では、シンプルなToDoアプリに不要な機能を大量に追加しています。

例2：社内向け管理システム

## 要求仕様
- 社員情報の登録・更新
- 基本的な検索機能

## ゴールドプレーティング版
- 高度な全文検索エンジン
- リアルタイム通知システム
- 複雑な権限管理（50段階）
- 詳細なアクセスログ分析
- 多言語対応（20言語）
- モバイルアプリ版

社内の限られたユーザー向けシステムに、過剰な機能を追加した例です。

技術面でのゴールドプレーティング

過度な設計パターンの使用

// シンプルな処理に複雑なデザインパターンを適用
public class CalculatorFactoryBuilder {
    private CalculatorAbstractFactory factory;
    
    public CalculatorFactoryBuilder setFactory(
        CalculatorAbstractFactory factory) {
        this.factory = factory;
        return this;
    }
    
    public Calculator build() {
        return factory.createCalculator();
    }
}

// 実際には単純な処理
public class SimpleCalculator {
    public int add(int a, int b) {
        return a + b;
    }
}

不必要な抽象化

# 過度に抽象化されたコード
class AbstractDataProcessor:
    def process(self, data):
        raise NotImplementedError

class ConcreteDataProcessor(AbstractDataProcessor):
    def process(self, data):
        return data.upper()

# シンプルで十分なコード
def process_data(data):
    return data.upper()

これらの例は、シンプルな処理に複雑な設計を適用した無駄な例です。

ゴールドプレーティングが起こる理由

完璧主義の心理

エンジニアの特性

• 技術的好奇心: 新しい技術を試したい欲求
• 品質へのこだわり: 高品質なものを作りたい願望
• 学習意欲: 技術向上への強い動機

心理的要因

• 承認欲求: 他者から認められたい気持ち
• 自己実現: 自分の技術力を証明したい
• 不安感: 「これで十分か？」という不安

これらの心理的要因が、必要以上の機能追加を駆り立てます。

プロジェクト環境の問題

不明確な要求

• 曖昧な仕様: 何が必要かが明確でない
• 変更頻発: 途中での要求変更
• ステークホルダーの不在: 意思決定者の不明確

時間的余裕

• スケジュールの余裕: 余った時間での追加開発
• 早期完成: 予定より早く完成した場合
• 待機時間: 他の作業待ちの時間

組織文化

• 技術重視: 技術的優秀さを重視する文化
• 完璧主義: 100%を求める組織風土
• 競争意識: 他チームとの競争心理

環境的要因が、ゴールドプレーティングを促進してしまいます。

ゴールドプレーティングの問題点

プロジェクトへの影響

スケジュールの遅延

開発時間の増加

• 機能追加: 追加機能の開発時間
• 複雑性増加: システム全体の複雑化による開発遅延
• テスト工数: 追加機能のテスト時間

具体的な遅延例

## 計画vs実績の比較

### 当初計画（4週間）
Week 1: 基本機能実装
Week 2: UI作成
Week 3: テスト
Week 4: リリース準備

### 実際の進行（8週間）
Week 1-2: 基本機能実装
Week 3-4: 「改善」機能の追加
Week 5-6: 「最適化」の実施
Week 7: 追加機能のテスト
Week 8: バグ修正とリリース

連鎖的な遅延

• 他チームへの影響: 依存するチームの作業遅延
• リリース計画: 全体的なリリーススケジュールの狂い
• 市場機会の逸失: 競合他社に先を越される

コストの増大

開発コストの増加

• 人件費: 追加開発時間による人件費増加
• インフラコスト: 高性能システムのためのインフラ費用
• ツール・ライセンス: 追加機能のための外部サービス費用

運用コストの増加

• 保守費用: 複雑なシステムの保守コスト
• トレーニング: 複雑な機能の利用者トレーニング
• サポート: 高機能システムのサポート負荷

機会コスト

• 他プロジェクトへの影響: リソースの他プロジェクトからの奪取
• 改善機会の逸失: 本当に必要な改善の先送り

品質への影響

複雑性の増加

コードの複雑化

# ゴールドプレーティングされたコード例
class OverEngineeredUserManager:
    def __init__(self):
        self.cache_strategy = CacheStrategyFactory.create_strategy()
        self.logger = LoggerBuilder().with_rotation().with_compression().build()
        self.validator = ChainedValidatorBuilder().add_all_validators().build()
        self.notification_service = NotificationServiceFactory.create_multi_channel()
        
    def create_user(self, user_data):
        # 過度な検証
        validation_result = self.validator.validate_with_full_report(user_data)
        if not validation_result.is_perfect():
            raise ValidationException(validation_result.get_detailed_report())
        
        # 過度なログ
        self.logger.info_with_context("User creation started", 
                                     context=self._build_full_context())
        
        # 実際の処理（ほんの数行）
        user = User(user_data)
        self.users.append(user)
        
        # 過度な通知
        self.notification_service.notify_all_channels(
            "User created", user, NotificationPriority.HIGH)
        
        return user

# シンプルで十分なコード
class SimpleUserManager:
    def __init__(self):
        self.users = []
    
    def create_user(self, name, email):
        if not name or not email:
            raise ValueError("Name and email are required")
        
        user = User(name, email)
        self.users.append(user)
        return user

システムアーキテクチャの複雑化

• 不要な分離: 過度なマイクロサービス分割
• 複雑な連携: 必要以上のシステム間連携
• 過剰な抽象化: 理解困難な抽象レイヤー

バグ発生率の増加

複雑性によるバグ

• 相互作用: 機能間の予期しない相互作用
• エッジケース: 複雑な条件分岐でのバグ
• パフォーマンス: 過度な最適化による性能劣化

保守性の悪化

• 理解困難: 新メンバーがコードを理解できない
• 変更困難: 小さな変更が大きな影響を与える
• テスト困難: 複雑すぎてテストが書けない

ユーザーへの影響

使いにくさの増加

UI/UXの複雑化

• 機能過多: 使わない機能による画面の複雑化
• 操作性悪化: 複雑な操作手順
• 学習コスト: 使い方を覚えるのに時間がかかる

パフォーマンスの悪化

• 処理速度: 不要な機能による処理速度低下
• メモリ使用量: 大量のメモリ消費
• 起動時間: アプリケーションの起動時間増加

本質的価値の希薄化

価値の分散

• 焦点のぼやけ: 本当に重要な機能が分からない
• 価値の相対化: 重要な機能の価値が下がる
• 使用率の低下: 全体的な機能使用率の低下

ユーザー離れ

• 複雑性への嫌悪: シンプルな競合への移行
• 期待値との乖離: 求めていたものと違う
• サポート問題: 使い方が分からない問い合わせの増加

ゴールドプレーティングを避ける方法

要求管理の徹底

明確な要求定義

SMART原則の適用

• Specific（具体的）: 何を作るかが明確
• Measurable（測定可能）: 成功基準が数値化されている
• Achievable（達成可能）: 現実的に実現可能
• Relevant（関連性）: ビジネス目標に関連している
• Time-bound（期限付き）: 明確な期限がある

要求仕様書の例

## 機能要求: ユーザー登録機能

### 概要
新規ユーザーがサービスに登録できる機能

### 具体的要求
1. ユーザーは氏名、メールアドレス、パスワードを入力できる
2. メールアドレスの形式チェックを行う
3. パスワードは8文字以上の制限を設ける
4. 登録完了後、確認メールを送信する

### 成功基準
- 正常な入力で登録が完了すること
- 不正な入力でエラーメッセージが表示されること
- 確認メールが1分以内に送信されること

### 除外項目（重要）
- SNS連携機能
- プロフィール画像アップロード
- 詳細な個人情報入力
- アカウント削除機能

スコープの厳格な管理

機能の優先順位付け

• Must Have: 絶対に必要な機能
• Should Have: あるべき機能
• Could Have: あると良い機能
• Won't Have: 今回は実装しない機能

MoSCoW法の適用例

## ToDoアプリの機能優先度

### Must Have
- タスクの追加・編集・削除
- タスクの完了状態切り替え
- タスクリストの表示

### Should Have
- タスクの並び替え
- 完了タスクの非表示

### Could Have
- タスクの期限設定
- カテゴリ分類

### Won't Have (今回)
- 他ユーザーとの共有
- 統計・分析機能
- モバイルアプリ版
- AI による自動分類

MVP（Minimum Viable Product）の考え方

最小機能での価値提供

MVPの原則

• 最小限の機能: 価値を提供する最小限の機能セット
• 早期リリース: できるだけ早くユーザーに届ける
• フィードバック重視: ユーザーの反応を重視
• 継続的改善: フィードバックに基づく継続的改善

MVP設計の例

## オンライン書店のMVP

### フェーズ1: MVP
- 書籍一覧表示
- 書籍詳細表示
- カートに追加
- 注文確定
- 基本的な決済

### 将来フェーズ（MVPでは実装しない）
- 高度な検索機能
- レコメンデーション
- レビューシステム
- ポイントシステム
- モバイルアプリ

段階的な機能追加

イテレーション計画

## 4週間イテレーション計画

### Week 1: コア機能
- ユーザー登録・ログイン
- 基本的なCRUD操作

### Week 2: 使いやすさ改善
- バリデーション強化
- エラーハンドリング改善

### Week 3: パフォーマンス
- 基本的な最適化
- 必要最小限のキャッシュ

### Week 4: リリース準備
- テスト
- ドキュメント
- デプロイ準備

### 次期以降の検討項目
- 高度な検索
- 詳細な分析
- 第三者連携

プロジェクト管理手法の活用

アジャイル開発の採用

スクラムの活用

• 短いスプリント: 1-4週間の短期開発サイクル
• デイリースタンドアップ: 日々の進捗確認
• スプリントレビュー: 成果物の確認と評価
• レトロスペクティブ: 改善点の抽出

ユーザーストーリーの作成

## ユーザーストーリーの例

### ストーリー1
As a 新規ユーザー
I want to アカウントを作成する
So that サービスを利用できる

### 受け入れ基準
- メールアドレスとパスワードで登録できる
- 入力エラーが適切に表示される
- 登録後にログインできる

### 除外項目
- SNS連携での登録
- 詳細プロフィール情報

タイムボックスの活用

時間制限の設定

• 機能実装: 各機能に明確な時間制限
• 完璧化の禁止: 時間内で実装できる範囲で完成
• 継続的改善: 後のイテレーションでの改善

タイムボックス例

## 機能別タイムボックス設定

### ユーザー登録機能: 3日
Day 1: 基本実装
Day 2: バリデーション追加
Day 3: テストとバグ修正
→ この時点で完成とする

### 検索機能: 2日
Day 1: 基本検索実装
Day 2: 結果表示改善
→ 高度な検索は次期フェーズ

実践的な対策

技術的なアプローチ

YAGNI原則の適用

YAGNI（You Aren't Gonna Need It）

• 意味: 「それは必要にならない」
• 原則: 今必要でない機能は実装しない
• 適用: 将来使うかもしれない機能の排除

YAGNI適用例

# ✗ YAGNI違反の例
class UserManager:
    def __init__(self):
        # 将来使うかもしれない機能を先に実装
        self.cache = Redis()  # まだキャッシュは不要
        self.analytics = Analytics()  # 分析機能は未定
        self.notification = NotificationService()  # 通知機能は要求にない
    
    def create_user(self, name, email):
        user = User(name, email)
        # 今は不要だが「将来のため」に実装
        self.cache.set(f"user:{user.id}", user)
        self.analytics.track_user_creation(user)
        self.notification.notify_admins(f"New user: {name}")
        return user

# ✓ YAGNI準拠の例
class UserManager:
    def __init__(self):
        self.users = []  # 今必要な機能のみ
    
    def create_user(self, name, email):
        user = User(name, email)
        self.users.append(user)
        return user
        # 他の機能は実際に必要になってから追加

DRY原則の適切な適用

DRY（Don't Repeat Yourself）の注意点

• 過度な抽象化の回避: 使われない抽象化は作らない
• 3回ルール: 同じコードが3回出現してから抽象化を検討
• コンテキストの考慮: 似ているが目的が違うコードは別々に保持

適切なDRY適用例

# ✗ 過度な抽象化
class GenericDataProcessor:
    def process(self, data, transformation_type, validation_rules, output_format):
        # 汎用的すぎて使いにくい
        pass

# ✓ 適切な抽象化（実際に重複があってから）
class UserProcessor:
    def process_registration(self, user_data):
        # 登録専用の処理
        pass
    
    def process_update(self, user_data):
        # 更新専用の処理
        pass

漸進的な開発

段階的機能追加

## 検索機能の段階的開発

### Phase 1: 基本検索
- キーワードでの部分一致検索
- 結果一覧表示

### Phase 2: 検索改善（必要性確認後）
- 検索結果のページング
- 並び替えオプション

### Phase 3: 高度検索（要求確認後）
- フィルタ機能
- ファセット検索

### Phase 4: AI検索（ROI確認後）
- 意味的検索
- おすすめ機能

プロセス的なアプローチ

コードレビューでの観点

レビューチェックリスト

## ゴールドプレーティング観点のレビュー項目

### 機能面
□ この機能は要求仕様に含まれているか？
□ 追加した機能は本当に必要か？
□ より簡単な実装方法はないか？

### 設計面
□ 使われない抽象化レイヤーはないか？
□ 将来の拡張を見越した過度な設計はないか？
□ パターンの適用は適切か？

### パフォーマンス面
□ 最適化は本当に必要か？
□ ベンチマークを取って効果を確認したか？
□ メモリやCPUの使用量は適切か？

定期的な振り返り

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

## ゴールドプレーティング観点の振り返り

### 今回のスプリントで
- 要求にない機能を追加していないか？
- 過度な完璧化をしていないか？
- 時間をかけすぎた部分はないか？

### 改善アクション
- 要求の再確認プロセス
- タイムボックスの厳格化
- レビュー観点の追加

ステークホルダーとの定期確認

週次レビューミーティング

## ステークホルダーレビューの進行

### 1. 進捗報告
- 完成した機能の動作デモ
- 予定との差異の説明

### 2. 追加機能の相談
- 「こんな機能を追加したいが必要か？」
- ステークホルダーからの明確な回答を取得

### 3. 優先順位の再確認
- 残り時間での優先順位
- リリースに必須の機能の確認

チーム・組織での対策

文化的な取り組み

価値提供重視の文化

価値観の共有

• ユーザー第一: 技術的完璧さよりもユーザー価値を重視
• 実用主義: 動くものを早く作ることを評価
• 継続改善: 一度で完璧を目指さず継続的改善を重視

価値評価の基準

## 機能評価の基準

### 技術的評価 < ビジネス価値評価
- コードの美しさ < ユーザーの満足度
- 最新技術の使用 < 問題解決の効果
- パフォーマンス最適化 < 機能の使いやすさ

### 評価指標の例
- ユーザーの使用頻度
- 問題解決に要する時間短縮
- エラー発生率の改善
- 顧客満足度スコア

Done is Better than Perfect

Facebookの格言の適用

• 完璧よりも完成: 80%の完成度で一度リリース
• 早期フィードバック: ユーザーの反応を見て改善
• 継続的デリバリー: 小さな改善を継続的に実施

実践例

## リリース基準の設定

### MVP リリース基準（70-80%）
- 基本機能が動作する
- 致命的なバグがない
- 最低限のユーザビリティが確保されている

### 改善版リリース基準（90%）
- ユーザーフィードバックを反映
- パフォーマンスが改善されている
- エラーハンドリングが充実している

### 完成版リリース基準（95%）
- 全ての要求機能が実装されている
- 十分なテストが実施されている
- ドキュメントが整備されている

教育・トレーニング

ゴールドプレーティング認識研修

研修内容

• 事例研究: 実際のゴールドプレーティング事例
• コスト計算: 追加機能の真のコスト
• 価値分析: 機能の価値評価方法

ワークショップ形式

## ゴールドプレーティング識別ワークショップ

### Step 1: 事例分析
グループで実際のプロジェクト事例を分析
- どの部分がゴールドプレーティングか？
- なぜそれが起こったか？
- どうすれば避けられたか？

### Step 2: 自分の経験共有
参加者が自分の経験を共有
- ゴールドプレーティングをした経験
- その時の心理状態
- 結果として何が起こったか

### Step 3: 予防策検討
チームで予防策を検討
- どのような仕組みが必要か？
- どのような観点でレビューするか？

技術的判断力の向上

判断基準の教育

• ROI計算: 機能追加の投資対効果
• リスク評価: 複雑化によるリスク
• メンテナンス性: 長期的な保守コスト

演習問題例

## 技術判断演習

### シナリオ
社内向けの勤怠管理システムを開発中。
基本機能は完成したが、以下の追加機能を検討している：

1. 顔認証による出退勤
2. AI による不正検知
3. 詳細な統計ダッシュボード
4. モバイルアプリ版
5. 他システムとのAPI連携

### 検討観点
- 各機能の必要性は？
- 開発コストと効果は？
- リスクは何か？
- 優先順位は？

### 期待する回答
現実的な判断基準に基づく優先順位付け

評価制度の見直し

技術的完璧さよりも価値創出を評価

従来の評価観点

• コードの品質: 技術的な美しさや効率性
• 技術力: 新しい技術の習得・活用
• 完成度: 隅々まで作り込まれた完璧さ

改善された評価観点

• 価値創出: ユーザーや事業への貢献
• 効率性: 最小の労力で最大の効果
• 適応性: 変化に対する柔軟な対応

評価項目の例

## エンジニア評価項目（改善版）

### 技術スキル（30%）
- 必要な技術の適切な選択と活用
- コードの可読性と保守性
- 技術的問題の解決能力

### 価値創出（40%）
- ユーザー価値の向上への貢献
- ビジネス目標達成への貢献
- 効率的な機能実装

### チームワーク（30%）
- 他メンバーとの協力
- 知識共有とメンタリング
- 建設的なフィードバック

早期リリースの奨励

リリース回数の評価

• 継続的デリバリー: 小さなリリースの継続
• フィードバック活用: ユーザー反応の分析と改善
• 学習速度: 失敗からの学習と改善

成功事例の共有

## 成功事例共有会

### 月次開催
各チームから以下を共有：
- 今月リリースした機能
- ユーザーからのフィードバック
- 改善した結果
- 学んだこと

### 表彰制度
- 最も価値ある小さなリリース賞
- 最も早い改善サイクル賞
- 最もユーザー満足度改善賞

成功事例と失敗事例

成功事例

スタートアップでのMVP開発

背景

• 企業: B2B向けプロジェクト管理ツール
• 期間: 開発開始から3ヶ月でリリース
• チーム: エンジニア3名

アプローチ

• 厳格なMVP定義: 本当に必要な機能のみ
• 週次ユーザーインタビュー: 毎週潜在顧客と対話
• 2週間スプリント: 短いサイクルでの開発

実装した機能（MVP）

## MVP機能リスト

### コア機能
- プロジェクト作成・編集
- タスク作成・割り当て
- 基本的な進捗表示

### 除外した機能
- 高度なレポート機能
- カスタムダッシュボード
- 第三者ツール連携
- モバイルアプリ
- AI による自動化

結果

• 早期顧客獲得: リリース1ヶ月で50社の利用開始
• 継続的改善: ユーザーフィードバックに基づく改善
• 資金調達成功: MVPの成功により投資家から評価

成功要因

• 明確な価値提案: シンプルで分かりやすい価値
• ユーザー中心: 技術的完璧さよりもユーザー価値重視
• 迅速な学習: 早期リリースによる学習サイクル

大企業での段階的リリース

背景

• 企業: 金融機関の内部システム刷新
• 期間: 2年間の大規模プロジェクト
• チーム: エンジニア20名

段階的リリース戦略

## リリース計画

### Phase 1（6ヶ月）: 基本機能
- 顧客情報管理
- 基本的な取引記録

### Phase 2（6ヶ月）: 業務効率化
- 自動計算機能
- 基本レポート

### Phase 3（6ヶ月）: 高度機能
- 詳細分析機能
- 外部システム連携

### Phase 4（6ヶ月）: 最適化
- パフォーマンス向上
- ユーザビリティ改善

ゴールドプレーティング回避策

• 厳格なスコープ管理: 各フェーズでの機能厳選
• ユーザー受け入れテスト: 各フェーズでのユーザー評価
• ROI計算: 機能追加の投資対効果測定

結果

• 計画通りのリリース: 各フェーズが予定通り完了
• 高いユーザー満足度: 段階的改善によるユーザー満足
• コスト効率: 予算内での完成

失敗事例

過度な技術志向による失敗

背景

• 企業: ECサイトのリニューアル
• 期間: 予定1年→実際2年
• 問題: 技術的完璧さへの固執

ゴールドプレーティングの内容

## 追加された不要な機能・技術

### 技術面
- マイクロサービス化（必要性が不明確）
- 複雑な分散システム
- 最新技術スタック（学習コスト大）
- 過度なパフォーマンス最適化

### 機能面
- AI による商品レコメンデーション
- 高度な在庫予測システム
- ソーシャル機能
- VR商品表示

問題と結果

• 開発遅延: 予定の2倍の期間
• 予算超過: 予算の1.5倍のコスト
• 複雑性: 運用・保守が困難
• 市場機会の逸失: 競合に先を越される

学習した教訓

• 技術選択の慎重さ: 新技術導入のリスク評価
• 機能の必要性: ビジネス価値の明確化
• 段階的アプローチ: 一度に全てを実現しない

完璧主義による機会損失

背景

• 企業: モバイルアプリの新規開発
• 期間: 予定6ヶ月→リリースなし
• 問題: 完璧を求めすぎてリリースできず

完璧主義の症状

## 完璧主義による問題

### 技術面
- 100%のテストカバレッジ要求
- 全ての端末での動作確認
- 完璧なパフォーマンス要求

### 機能面
- 全機能の完成を要求
- 細部の作り込みに固執
- ユーザーフィードバック前の完璧化

### プロセス面
- 無限のレビューサイクル
- 修正の修正の繰り返し
- リリース基準の引き上げ

結果

• リリース延期: 結局リリースできず
• 競合の先行: 市場を競合に取られる
• チームの疲弊: メンバーのモチベーション低下
• プロジェクト中止: 最終的にプロジェクト中断

改善すべきだった点

• リリース基準の明確化: 何をもって完成とするか
• MVP思考: 最小限での価値提供
• 時間制限: 完璧化の時間制限設定

まとめ

ゴールドプレーティングは、エンジニアの向上心や技術への情熱から生まれる現象ですが、プロジェクトの成功を阻害する大きな要因となります。

技術的完璧さを追求することは悪いことではありませんが、ユーザー価値とのバランスを考慮することが重要です。 MVP思考、YAGNI原則、段階的開発などの手法を活用することで、効率的で価値のあるソフトウェア開発が可能になります。

組織レベルでも、価値創出を重視する文化の醸成、適切な評価制度の設計、継続的な教育が必要です。 完璧よりも完成を、技術的美しさよりもユーザー価値を重視する姿勢が、成功するプロダクト開発の鍵となります。

エンジニアとしての技術的向上心を保ちながら、ビジネス価値とのバランスを取ることで、真に価値のあるソフトウェアを作ることができるでしょう。

「Done is better than perfect」の精神で、まずは動くものを作り、ユーザーのフィードバックを受けながら継続的に改善していく姿勢が重要です。 完璧を目指すのではなく、価値提供を目指すことで、より良いエンジニアになれるはずです。