Zenn
🪴

ClineでサーバーレスWebアプリを開発してSIer業務に適用できるか検証してみた

2025/03/25に公開
3
AWS
SIer
Serverless
生成 AI
Cline
tech

1. はじめに

ClineをSIerで使えるか？

SIerといっても、様々な仕事のスタイルがあるでしょう。

私も受託開発や自社サービス開発含めた数多くのプロジェクトにかかわってきました。

今回は、その中でも受託開発のウォーターフォール型プロジェクトに焦点を絞り、設計書やテスト仕様書などのドキュメントの納品が求められるプロジェクトを対象として考えてみます。

まずClineを導入するまでのハードルが高く、実際の受託開発プロジェクトですぐには使えない、と多くの方が思われていることでしょう。
そのハードルについては後述するとします。
ひとまず、模擬的なプロジェクトでClineを導入し、生産性を向上させられるか試してみることからスタートします。

今回、盆栽管理アプリ「Bonsai App」新規開発プロジェクトを立ち上げ、
受託開発のウォーターフォール型プロジェクトにおけるClineの活用可能性を検証してみました。

2. 検証プロジェクト概要および検証ポイント

盆栽管理アプリ「Bonsai App」

今回開発したのは、盆栽の管理を支援するWebアプリケーション「Bonsai App」です。

  • 主な機能は以下の通り
    • ユーザー認証: ID/パスワードによるログイン機能
    • 盆栽管理: 盆栽の登録、編集、一覧表示、詳細表示
    • 作業記録: 剪定、植替え、水やりなどの作業記録の管理
    • 作業予定: 今後の作業予定の管理
    • 画像管理: 盆栽や作業の画像アップロード、表示機能
    • 月次レポート: 月ごとの作業サマリーと次月の推奨作業

技術スタック

フロントエンド:

  • Angular v13.x
  • TypeScript
  • SCSS

バックエンド:

  • AWS Lambda（Node.js 20.x）
  • Amazon DynamoDB
  • Amazon S3
  • Amazon CloudFront
  • Amazon Cognito
  • AWS CloudFormation

技術的な特徴

フロントエンド（Angular）

  • コンポーネントベースのアーキテクチャ
  • レスポンシブデザイン（モバイル対応）
  • 状態管理とサービス層の分離
  • 画像の遅延読み込みと最適化

バックエンド（AWS Lambda + DynamoDB）

  • RESTful APIの実装
  • DynamoDBの単一テーブル設計
  • 効率的なクエリパターン
  • 画像処理と最適化（S3とCloudFrontの活用）

インフラストラクチャ（AWS CloudFormation）

  • 完全サーバーレス
  • インフラのコード化（IaC）
  • 環境ごとの分離（開発環境と本番環境）
  • CI/CDパイプラインの設定
  • セキュリティ設定（IAMポリシー、CORS設定など）

ウォーターフォールプロセスの適用

本プロジェクトでは、以下のウォーターフォール型の開発プロセスを適用しました：

  1. 要件定義: ユーザーの要求を分析し、システム要件を定義
  2. 設計: システム設計、API設計、データモデル設計、UI設計
  3. 実装: 設計に基づくコード実装
  4. テスト: 単体テスト、結合テスト、システムテスト

なお、全てのドキュメントをMarkdown形式とします。

検証ポイント

全ての工程にClineを使い、人間が作業した場合と同等の品質の成果物が作れるかを確認しながら、どの程度生産性の向上に寄与できるかを検証します。
ClineのAPI ProviderはAnthropic、Modelはclaude 3.7 sonnetを使用します。

3. .clinerulesによる開発プロセスの標準化

.clinerulesファイルの役割と重要性

開発に入る前に、.clinerulesについて説明しておきます。
Clineでは、.clinerulesファイルを使用して、プロジェクト固有の開発ルールや注意点を定義できます。このファイルは、Clineがプロジェクトの文脈を理解し、適切な動作をするための重要なガイドラインとなります。

今回のプロジェクトでは、以下のような情報を.clinerulesファイルに定義しました：

  • アプリケーション概要と主な機能
  • データモデル概要
  • 環境設定
  • コマンド実行時の注意点（Windows環境での注意点など）
  • プロジェクト構造
  • 各工程の定義
  • 開発フロー
  • AWS無料枠の制限
  • デプロイ手順
  • トラブルシューティング

Cline上での各工程の明確な定義

.clinerulesファイルで、Clineを使った各工程のプロセスを明確に定義しました：

## cline上での各工程の定義
1. **要件定義＆設計工程**
   - Planモードでユーザーの要求をインタビューして分析しシステム要件を洗い出す
   - 要件をユーザーが承認したらActモードに切り替え、featureブランチを作成し、システム要件をもとに設計関連ドキュメントを追記修正する
   - 設計関連ドキュメントが完成したら、コミットする
   - 設計関連ドキュメントをもとに、結合テストケースを作成する
   - 結合テストは `docs/test/` ディレクトリに記載する
   - 結合テストは設計をもとに、因子と水準を洗い出しペアワイズ法で２因子間を網羅する組み合わせテストケースを作成する

2. **製造工程**:
   - featureブランチにコミットされた設計関連ドキュメントをもとにTDDでコードを実装する
   - 製造とユニットテストを実行する
   - 完了したら、featureブランチをdevelopブランチにマージする

3. **結合テスト工程**:
   - テスト環境情報
      - /docs/test/.env
   - ログイン後、テストケースに従ってテストを実行する
   - 想定結果と実際の結果を比較し、テスト結果のレポートを作成する
   - 結合テストレポートの承認が得られたら開発完了

この定義により、Clineは各工程で何をすべきかを理解し、開発を進めてくれます。

.clinerulesファイルは、開発プロジェクトで策定する「開発標準」のような役割です。

開発を進めながら、最適な.clinerulesを模索し、継続的に改善していくことが重要です。
今回の検証過程で、工程とタスクをどのように紐づけるかなどを試行錯誤した結果、現時点でこのような定義になりました。

4. 開発の始め方

開発環境の初期構築

前提条件：

  • Cline導入済みのCursor（もしくはVSCode）
  • AnthropicのAPIキー
  • GitHubアカウントとリポジトリ
  • AWSアカウントとアクセスキー
  • AWS CLI
  • node.js

今回、ゼロベースで開発をスタートしました。
まず、プロジェクトの開始時に開発環境の初期構築を行いました。以下は、実際に使用した最初のプロンプトです：

Webアプリを開発します。まずは以下の要件に応じたプロジェクトのディレクトリ構造を作成し、環境を準備してください。

# 技術要素
## インフラ
  - 全てAWS
　- APIはlambdaとAPI Gateway
　- フロントはS3
　- DBはDyanamo
　- 静的コンテンツはS3
　- 認証はCognito
　- すべてcloudformationでコード管理

## サーバー
  - node.jsでAPI構築

## クライアント
  - Typescript（Angular）でSPA構築

# ドキュメント
## markdownでの設計
  - プログラムがわからないユーザーが理解しやすい設計ドキュメントをmarkdownで作成し同一リポジトリで管理
  - 画面イベントの定義、APIのインターフェース定義、処理フロー、インフラ構成などを設計ドキュメントとして作成します。

たったこれだけで、ゼロからプロジェクトの骨組みを構築してくれます。

もちろん不足部分や想定とは異なる部分はあります。都度、Clineに指摘して修正してもらいます。

この指示だとリッチすぎるAWS構成を出してきたので、無料枠に抑えたいと再指示して作り直してもらったり、など。

しかし、成果物を直接修正することはなく、Clineへの指示だけで、骨組みとしては十分すぎるものができました。

ここから、具体的な業務要件をもとに、開発を進めていきます。

5. Clineを活用した設計工程

要件定義から設計書作成までのプロセス

まずClineのPlanモードを活用し、ユーザーの要求をインタビュー形式で分析し、システム要件を洗い出します。

以下は、個別機能の要件定義と設計に使ったプロンプトの例です：

ダッシュボード画面に一括水やりボタンを追加します。.clinerulesの要件定義＆設計工程の進め方の通りに進め、設計を完了させてください。

この指示から、Clineは要件を分析し、QAをユーザーに投げ返してきます。
QAに回答する形で指示を出していくことにより、システムでどのように実現するかを提案してくれます。
提案をユーザー承認し、PlanモードからActモードに切り替えて、設計ドキュメントを生成してもらいます。

以下は、生成された設計ドキュメントの一部です：

このように、UI設計、コンポーネント設計、サービス設計、インタラクション設計を含む詳細な設計ドキュメントが生成されます。

Clineは、プロジェクトの文脈を理解し、適切な設計を提案してくれます。

  • API設計書
  • プロセスフロー設計書
  • データモデル設計
  • UI設計
  • インフラストラクチャ設計

要件定義と設計書の品質

実際のところ業務で使える品質なのかどうか、
感触としては間違いなく使えるレベルにあります。

Clineは、Planモードを活用し要件を分析、整理し、高い品質で設計書を作成できます。
しかし、適切な単位で要求、要件を分割して指示を出す必要があります。
1つのタスクで複雑すぎることをやらせると、迷走しはじめたり、途中でタスクを打ち切られたりします。
また、高度な業務知識が必要な領域においては、適切に知識を与えてあげないと良い提案が返ってこないことがあります。

総じて、使う側のスキルが必要です。

より複雑で大規模な業務アプリでさらなる検証は必要ですが、使いこなせれば高速で高品質の成果物を作り出せると思います。

6. Clineを活用した実装工程

設計書に基づくコード実装プロセス

Clineに設計ドキュメントを理解させ、コードを生成してもらいます。

以下は、実際に使用したプロンプトの一例です：

ダッシュボード画面への一括水やりボタン追加の設計が完了し、コミットしました。.clinerulesの製造工程の進め方の通りに進め、製造を完了させてください。

この指示だけで、サーバーサイド、クライアントサイド両方の実装を、設計通りに進めることが可能です。

テスト駆動開発（TDD）の実践

.clinerulesで定義されたTDDプロセスに従い、以下のRed-Green-Refactorサイクルを実践しました：

  1. Red: 失敗するテストを先に書く
  2. Green: テストが通るように最小限のコードを実装する
  3. Refactor: コードをリファクタリングする

Clineは、このTDDプロセスを理解し、各ステップに合わせた支援を提供しました。例えば、まず失敗するテストコードを生成し、次にそのテストが通るような実装コードを生成し、最後にコードのリファクタリングを行うという流れです。

以下は、実際のTDDプロセスの例です：

1. 失敗するテストの作成（Red）:

// server/tests/unit/services/workRecordService.test.ts
describe('createWorkRecord', () => {
  it('should create a work record', async () => {
    // モックの設定
    const mockBonsai = { id: 'bonsai123', userId: 'user123', name: '五葉松' };
    getBonsaiByIdMock.mockResolvedValue(mockBonsai);
    putItemMock.mockResolvedValue({});
    
    const workRecord = {
      bonsaiId: 'bonsai123',
      workTypes: ['pruning'],
      date: '2025-03-01T00:00:00Z',
      description: 'テスト作業記録',
      imageUrls: []
    };
    
    const result = await workRecordService.createWorkRecord('user123', workRecord);
    
    expect(result).toBeDefined();
    expect(result.id).toBeDefined();
    expect(result.bonsaiId).toBe('bonsai123');
    expect(result.workTypes).toEqual(['pruning']);
    expect(result.date).toBe('2025-03-01T00:00:00Z');
    expect(result.description).toBe('テスト作業記録');
    expect(getBonsaiByIdMock).toHaveBeenCalledWith('bonsai123', 'user123');
    expect(putItemMock).toHaveBeenCalled();
  });
});

2. テストが通るコードの実装（Green）:

// server/src/services/workRecordService.ts
export async function createWorkRecord(userId: string, workRecord: CreateWorkRecordRequest): Promise<WorkRecord> {
  // 盆栽の存在確認
  const bonsai = await getBonsaiById(workRecord.bonsaiId, userId);
  if (!bonsai) {
    throw new NotFoundError('指定された盆栽が見つかりません');
  }
  
  // 作業記録の作成
  const now = new Date().toISOString();
  const newWorkRecord: WorkRecord = {
    id: uuidv4(),
    bonsaiId: workRecord.bonsaiId,
    workTypes: workRecord.workTypes,
    date: workRecord.date,
    description: workRecord.description,
    imageUrls: workRecord.imageUrls || [],
    createdAt: now,
    updatedAt: now
  };
  
  // DynamoDBに保存
  await dataStore.putItem({
    PK: `USER#${userId}`,
    SK: `WORKRECORD#${newWorkRecord.id}`,
    GSI1PK: `BONSAI#${workRecord.bonsaiId}`,
    GSI1SK: `WORKRECORD#${newWorkRecord.date}#${newWorkRecord.id}`,
    ...newWorkRecord
  });
  
  return newWorkRecord;
}

3. コードのリファクタリング（Refactor）:

// server/src/services/workRecordService.ts
export async function createWorkRecord(userId: string, workRecord: CreateWorkRecordRequest): Promise<WorkRecord> {
  // 盆栽の存在確認
  const bonsai = await getBonsaiById(workRecord.bonsaiId, userId);
  if (!bonsai) {
    throw new NotFoundError('指定された盆栽が見つかりません');
  }
  
  // 作業記録の作成
  const now = new Date().toISOString();
  const newWorkRecord: WorkRecord = {
    id: uuidv4(),
    bonsaiId: workRecord.bonsaiId,
    workTypes: workRecord.workTypes || [],
    date: workRecord.date,
    description: workRecord.description,
    imageUrls: workRecord.imageUrls || [],
    createdAt: now,
    updatedAt: now
  };
  
  // DynamoDBに保存
  await saveWorkRecord(userId, newWorkRecord);
  
  return newWorkRecord;
}

// 保存処理を分離して再利用性を高める
async function saveWorkRecord(userId: string, workRecord: WorkRecord): Promise<void> {
  await dataStore.putItem({
    PK: `USER#${userId}`,
    SK: `WORKRECORD#${workRecord.id}`,
    GSI1PK: `BONSAI#${workRecord.bonsaiId}`,
    GSI1SK: `WORKRECORD#${workRecord.date}#${workRecord.id}`,
    ...workRecord
  });
}

このように、Clineは.clinerulesで定義されたTDDプロセスを理解し、各ステップに合わせ実装を進めてくれます。

サーバーレスアーキテクチャの実装

サーバーレスアーキテクチャの実装では、AWS CloudFormationテンプレートの生成、Lambda関数の実装、DynamoDBの単一テーブル設計などを行いました。

特に、DynamoDBの単一テーブル設計では、以下のような設計を採用しました：

# infrastructure/cloudformation/storage.yml
BonsaiTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: !Sub BonsaiTable-${Environment}-${AWS::AccountId}
    BillingMode: PROVISIONED  # Provisioned mode for free tier
    ProvisionedThroughput:
      ReadCapacityUnits: 5    # Minimum setting
      WriteCapacityUnits: 5   # Minimum setting
    AttributeDefinitions:
      - AttributeName: PK
        AttributeType: S
      - AttributeName: SK
        AttributeType: S
      - AttributeName: GSI1PK
        AttributeType: S
      - AttributeName: GSI1SK
        AttributeType: S
    KeySchema:
      - AttributeName: PK
        KeyType: HASH
      - AttributeName: SK
        KeyType: RANGE
    GlobalSecondaryIndexes:
      - IndexName: GSI1
        KeySchema:
          - AttributeName: GSI1PK
            KeyType: HASH
          - AttributeName: GSI1SK
            KeyType: RANGE
        Projection:
          ProjectionType: ALL
        ProvisionedThroughput:
          ReadCapacityUnits: 5
          WriteCapacityUnits: 5

この設計により、複数のエンティティ（盆栽、作業記録、作業予定、月次レポートなど）を単一のテーブルで管理し、効率的なクエリを実現しました。

実装の品質

言うまでもなく、高い品質を実現してくれます。

しかし、この工程でもClineへの指示の出し方は重要です。
適切に分割されたサイズのタスクを実行することが、品質の高さにつながります。
複雑な指示を与えると、迷走した挙句コントローラー層にビジネスロジックを実装し始めたりなど、収拾がつかなくなることもありました。
その場合はそのタスクは諦め、タスクの与え方を再検討すべきでしょう。

また、エラーの修正を指示した場合などに、「事なかれ主義」に走る傾向があります。
根本原因を解決せずに、エラーを握りつぶすような実装を追加して、画面表示上のエラーをなくすだけのような対応を取ってきます。
無駄にif文を追加して「回避策」を埋め込んでくることもあります。

適切に監視し、方針を与え、導いてあげる必要があります。

7. Clineを活用したテスト工程

テスト仕様書の作成プロセス

Clineに、設計書をインプットとし、テストケースの作成を指示します。

以下は、カレンダー機能の結合テストケースの一部です：

# ダッシュボードカレンダー結合テスト

このドキュメントでは、Bonsai Appのダッシュボードカレンダー機能に関する結合テストケースを定義します。

## 目次

1. [テスト概要](#テスト概要)
2. [因子と水準](#因子と水準)
3. [テストケース](#テストケース)
4. [テスト実行手順](#テスト実行手順)

## テスト概要

ダッシュボードカレンダー機能は、作業予定と作業記録をカレンダー上にマッピングして表示する機能です。このテストでは、カレンダーの表示、イベントの表示、ユーザー操作に関する機能が正しく動作することを確認します。

## 因子と水準

ダッシュボードカレンダー機能のテストに関連する因子と水準は以下の通りです：

### 因子A: 表示モード
- A1: 月表示
- A2: 週表示

### 因子B: イベントタイプ
- B1: 作業予定のみ
- B2: 作業記録のみ
- B3: 作業予定と作業記録の両方

### 因子C: イベント数
- C1: 少数（1〜5件）
- C2: 多数（10件以上）

### 因子D: 期間
- D1: 現在の月/週
- D2: 過去の月/週
- D3: 未来の月/週

### 因子E: ユーザー操作
- E1: 表示切り替え（月表示⇔週表示）
- E2: 期間移動（前月/次月、前週/次週）
- E3: イベントクリック

## テストケース

ペアワイズ法を用いて、2因子間の組み合わせを網羅するテストケースを設計しました。

| テストID | 表示モード | イベントタイプ | イベント数 | 期間 | ユーザー操作 | 説明 |
|----------|------------|----------------|------------|------|--------------|------|
| TC-CAL-001 | 月表示 | 作業予定のみ | 少数 | 現在 | 表示切り替え | 月表示で少数の作業予定を表示し、週表示に切り替える |
| TC-CAL-002 | 月表示 | 作業記録のみ | 多数 | 過去 | 期間移動 | 月表示で過去の多数の作業記録を表示し、期間を移動する |
| TC-CAL-003 | 月表示 | 両方 | 少数 | 未来 | イベントクリック | 月表示で未来の少数の作業予定と作業記録を表示し、イベントをクリックする |
| TC-CAL-004 | 週表示 | 作業予定のみ | 多数 | 未来 | 期間移動 | 週表示で未来の多数の作業予定を表示し、期間を移動する |
| TC-CAL-005 | 週表示 | 作業記録のみ | 少数 | 現在 | イベントクリック | 週表示で現在の少数の作業記録を表示し、イベントをクリックする |
| TC-CAL-006 | 週表示 | 両方 | 多数 | 過去 | 表示切り替え | 週表示で過去の多数の作業予定と作業記録を表示し、月表示に切り替える |
| TC-CAL-007 | 月表示 | 作業予定のみ | 多数 | 現在 | イベントクリック | 月表示で現在の多数の作業予定を表示し、イベントをクリックする |
| TC-CAL-008 | 月表示 | 作業記録のみ | 少数 | 未来 | 表示切り替え | 月表示で未来の少数の作業記録を表示し、週表示に切り替える |
| TC-CAL-009 | 週表示 | 作業予定のみ | 少数 | 過去 | イベントクリック | 週表示で過去の少数の作業予定を表示し、イベントをクリックする |

### TC-CAL-001: 月表示での作業予定表示と表示切り替え

**目的**: 月表示で少数の作業予定を表示し、週表示に切り替える機能を確認する

**前提条件**:
- ログイン済みのテストユーザーセッション
- テスト用の盆栽（1つ以上）
- テスト用の作業予定（1〜5件、現在の月内）

**テストステップ**:
1. ダッシュボード画面にアクセスする
2. カレンダーが月表示で表示されることを確認する
3. 現在の月のカレンダーに作業予定が表示されることを確認する
4. 表示切り替えボタン（週表示）をクリックする

**期待結果**:
- カレンダーが月表示から週表示に切り替わる
- 週表示でも同じ作業予定が表示される
- 作業予定が青系統の色で表示される

.clinerulesで定義されたペアワイズ法による組み合わせテストケースの作成が実現できています。

.clinerulesに基づくテスト実行

テスト実行では、.clinerulesで定義したテスト環境情報（/docs/test/.env）をClineに参照してもらい、Browser use機能を使って自動で実行します。
WebアプリだとBrowser use使えるので楽ですね。

テスト実行後、テスト結果の分析と報告書を作成してもらいます。

テスト結果の分析と報告

テスト結果は、docs/test/results/ディレクトリに保存しました。
Clineは、テスト結果を分析し、問題点の特定と修正案の提案まで行ってくれます。

以下は、ダッシュボードカレンダーテストの結果サマリーの一部です：

## テスト結果サマリー

| 結果 | テスト数 | 割合 |
|------|----------|------|
| 合格（○） | 2 | 22.2% |
| 一部合格（△） | 7 | 77.8% |
| 不合格（×） | 0 | 0% |
| **合計** | **9** | **100%** |

## 主な問題点

1. **テストデータの不足**
   - 過去の期間にデータが表示されていない
   - 未来の期間に作業記録が表示されていない
   - 多数のイベントが重なるデータがない

2. **機能面での問題**
   - 特になし（基本機能は正常に動作）

このように、Clineはテスト結果を分析し、問題点を特定するだけでなく、次のステップとして何をすべきかも提案してくれました。
（この例ではテストデータ不足で、十分な結果になりませんでした。テストデータの作成は今回手動ですが、今後Clineにやってもらうようにしたい。）

テスト工程の品質

今回検証の範囲では、テスト仕様書作成からテストの実行、結果の報告まで、まったく問題ない品質でした。

より複雑な業務アプリでは精度が下がるとは思いますが、どこまで可能なのか引き続き検証してみたいと思います。

8. 検証結果と考察

生産性

設計書とテスト仕様書、テスト結果レポートが揃い、開発環境と本番環境それぞれでアプリが動き、GitHub ActionsによるCI/CDを構築するまで、私1人で約30時間かかりました。
ClineやAIなしで開発していたら、100時間どころか200時間必要だったかもしれません。

結果として70%～85%程度の工数削減となりました。

生産性向上の観点では絶大な効果があることを実感できました。
特に、コーディングだけでなく、要件定義、設計、テストの全工程で有効性を感じられたことは大きな収穫でした。

なお、Clineにかかった総コストは120ドル程度でした。
生産性の向上度合いと比較して非常に小さいと言えます。

各工程における品質と課題

設計工程

.clinerulesやドキュメントテンプレートを整備することにより、高品質な設計ドキュメントの生成が可能です。

繰り返しになりますが、適切な単位で要件を分割し、1つ1つタスクを進めることが重要です。
難解な要件を一度に指示するとうまくいかないことが多いです。
使っていくうちに、この記載レベルなら大丈夫だろう、これはダメかもしれない、というのがわかってきます。
AIの性能向上、コンテキストウィンドウの拡大で、将来的には改善されるでしょう。

実装工程

実装工程では、TDDプロセスに従った高品質なコード生成が可能でしたが、課題もあります。

  • 複雑なタスクの品質課題: 複雑なタスクの場合、アーキテクチャの一貫性が損なわれるなど充分な品質のコードが出力されない
  • 事なかれ主義: エラー修正時に根本原因から目をそらし、表面上エラーを消すような実装をすることがある

行き詰ったらそのタスクはすっぱり諦め、消費したコストは必要経費と思って、タスクの粒度を見直しましょう。

テスト工程

テスト工程では、テスト仕様書の作成からテスト実行、結果分析まで高品質な成果物が得られました。
複雑度が上がると精度が下がると予想されるため、実際の業務アプリレベルの複雑度での検証は引き続き必要です。

所感

ウォーターフォールの想定でスタートしたのに、Clineを最大限活用するために適切な要件・タスクの分割と工程の分割を試行錯誤するうちに、アジャイル開発のように小規模に各工程を繰り返すスタイルになりました。
工程を分割しさらに要件も分割してタスクを実行していくため、ウォーターフォールのやり方でも大丈夫ですが、実行順は、大枠から作り始め細部を整えていく進め方で考えるのがよさそうです。

重要なのは、要件・機能の分割、タスクの分割、シンプルな仕様、疎結合なシステム、関心の分離。

やってはいけないのは、複雑怪奇な仕様、密結合なシステム、スパゲッティコード、神クラス。

従来のシステム開発と同じですね。
AI活用時代になり、これまで以上に差がつくようになると感じました。

システムエンジニアの役割も変化していくことでしょう。

  • コード記述者からプロンプト設計者・レビュアーへの役割シフト
  • 業務知識とAIの能力を組み合わせる「AIオーケストレーション」スキルの重要性
  • 全体設計と品質管理に注力

もう一つ、Bonsai App自体について。
テストが足りていなかったり、業務レベルで運用するには考慮できていないことが多かったりはしますが、趣味で個人的に盆栽を管理するには十分なアプリです。
Clineを使ってみるのが主目的で、Bonsai Appは副産物に過ぎないはずだったのに、思った以上に完成度が高く、今後使いながら継続的に改善していきたいです。

9. SIer業務への適用に向けた課題と対策

セキュリティとコンプライアンスへの対応

最初に棚上げしたCline導入のハードルについて、ここで触れます。

SIer業務では、セキュリティとコンプライアンスが重要な課題です。

その点Clineは厄介な存在です。
Clineはファイルの読み書き、コマンド実行を凄い勢いで繰り返します。
Auto-approve設定で自動実行の可否は設定できるとはいえ、
極端な話、git push --forceやrm -rf /*をやってもおかしくないです。
（私はRead files and directoriesのみAuto-approveし、他は必ず一つ一つ許可するようにしています。）

このようなシロモノを開発者に自由に使わせるのは、組織としてリスクがあります。
そのリスクと、Clineがもたらすリターンを天秤にかけ、組織としての判断をする必要がありますが、
顧客の環境にアクセスしたり顧客のリソースがあったりするSIerの場合は、特に難しくなってくると思います。
AI利用に関する理解は高まっている時代とはいえ、厳しいところでは歯牙にもかからないかもしれません。

私はClineを業務に適用するにあたって最大の課題が、このハードルだと思っています。
本記事のような検証や、より実務に近づけた実証実験で成果を明らかにし、
また、リスクアセスメントを実施して、天秤を傾けるように動いていくことが大切でしょう。

10. まとめと今後の展望

Clineの可能性と限界

今回の検証を通じて、Clineの可能性を実感しました。

可能性:

  • 小規模のプロジェクトでは驚異的な生産性向上
  • コーディングだけではなく設計書やテスト仕様書などのドキュメント作成にも効果的
  • TDDの実践により高品質なコード生成
  • 設計とコードの一貫性維持

しかし万能ではなく、うまく使うスキルが必要であり、うまく使える場面を考える必要があります。

課題:

  • 複雑な要件や大規模システムへの適用には課題あり
  • セキュリティとコンプライアンス上の懸念
  • 人間の監視と指導が必要

現実的な導入ステップ

SIer企業でClineを導入するなら、以下のようなステップが現実的でしょう：

  1. 個人レベルでの試験導入:

    • 社内の技術検証プロジェクトで活用
    • 成果物の品質と生産性を測定

  2. 小規模チームでの限定的な活用:

    • 非機密情報のみを扱うプロジェクトで試験的に導入
    • .clinerulesの整備と標準化

  3. セキュリティ対策の確立:

    • 機密情報フィルタリングの仕組み構築
    • 権限管理と監査の仕組み整備

  4. 段階的な適用範囲の拡大:

    • 成功事例の蓄積と共有
    • 組織全体への展開

AIとの共存

Clineのような強力なAIツールは、私たちSIerの仕事を奪うのではなく、変化させるものだと考えています。

  • 人間の役割の変化:

    • コーディングからAIの監督・指導へ
    • 業務知識とAIの橋渡し役へ
    • 創造的な問題解決と品質保証へ

  • 必要なスキルセット:

    • 要件の分析および整理
    • AIの出力を評価・修正する能力
    • システム設計の原則への深い理解

今後の展望

今回の検証は小規模なアプリケーションでしたが、今後は以下のような取り組みを進めていきたいと考えています：

  1. 実務プロジェクトでの検証:

    • 実際の業務アプリケーションレベルの複雑さでの検証
    • 複数人チームでの活用方法の確立

  2. .clinerulesのテンプレート化:

    • プロジェクト種別ごとのテンプレート作成
    • ベストプラクティスの蓄積

  3. 教育プログラムの開発:

    • AIとの効果的な協業方法の教育
    • Cline利用スキルの育成

AIとの共存は避けられない未来です。抵抗するのではなく、いち早く取り入れ、その力を最大限に活用する方法を模索していくことが、SIerとしての競争力を維持する鍵になるでしょう。

Clineは完璧ではありませんが、その可能性は計り知れません。今回の検証が、皆さんのAI活用の一助となれば幸いです。

3

Discussion

ログインするとコメントできます