Zenn
📝

Content-Converterプロジェクトの仕様書ドラフト作成（開発日記 No.060）

に公開
Python
仕様書
開発日記
idea

関連リンク

はじめに

昨日は、これまで個別に開発してきたDiary-ConverterとNote-Converterを統合する構想について検討しました。今日はその構想を具体的な形にするため、新しい統合プロジェクト「Content-Converter」の仕様書ドラフトを作成することにしました。

背景と目的

Diary-Converterは開発日記をZenn記事に、Note-Converterは一般的なメモをnote記事に変換するツールとしてそれぞれ開発してきました。しかし、機能的に重複する部分も多く、メンテナンス性や拡張性を考えると、これらを統合した方が効率的だと判断しました。

新しい「Content-Converter」プロジェクトの目的は以下の通りです。

  • Diary-ConverterとNote-Converterの機能を統合し、単一のツールで複数のコンテンツ形式とプラットフォーム（Zenn, note.com）に対応する。
  • 複数のLLM API（Gemini, OpenRouterなど）を柔軟に切り替えられるようにする。
  • プラグインアーキテクチャを採用し、将来的な機能拡張を容易にする。
  • テンプレート管理機能を強化し、出力形式のカスタマイズ性を高める。
  • コマンドラインインターフェース（CLI）と設定ファイルによる操作を可能にする。

検討内容

仕様書の作成は、LLMとの対話形式で進めました。まず、Docs/specification-draftディレクトリにContent-Converter.mdというファイルを作成してもらい、仕様書に必要な項目立てとドラフト作成を依頼しました。

LLMが提案した構成案は以下の通りです。

  1. 概要
  2. 背景と目的
  3. 機能要件
  4. 非機能要件
  5. アーキテクチャ設計
  6. インターフェース設計
  7. テスト計画
  8. 開発ロードマップ
  9. リスクと考慮事項
  10. 依存関係
  11. ライセンス
  12. 参考資料

この構成案をベースに、以下の点を追加・修正するよう指示しました。

  • 開発プロセス: 既存のdevelopment_process_guide.mdに従うことを明記し、重複する記述は避ける。
  • CI/CD連携: このツールはDocsリポジトリのCI/CDパイプラインに組み込んで利用するため、その点を考慮した設計にする。
  • OASIS連携: note.comへの投稿機能を実現するために、サードパーティ製のPythonアプリケーション「OASIS」を内部的に利用する方針を盛り込む。

これらの指示に基づき、LLMは仕様書ドラフトを更新してくれました。特に、OASIS連携については、背景、機能要件、アーキテクチャ、インターフェース設計、コマンドラインオプション、設定ファイル、リスクなど、多岐にわたる項目に反映されました。また、「テスト計画」セクションは「CI/CD統合」セクションに置き換えられ、より具体的なパイプライン連携の内容が記述されました。

実装内容

本日の主な実装内容は、仕様書ドラフトの作成と、LLMとの対話による内容の具体化です。

  • 仕様書ドラフト作成: Docs/specification-draft/Content-Converter.md を作成。
  • 仕様書構成: 上記「検討内容」で挙げた12項目を基本構成とする。
  • 仕様書更新: LLMとの対話を通じて、以下の点を反映。
    • 開発プロセスガイド (development_process_guide.md) への準拠を明記。
    • DocsリポジトリのCI/CDパイプラインへの統合に関する詳細を追加。
    • OASISツール連携に関する詳細を追加。
      • 背景と目的への追記
      • note.com対応機能としてのOASIS連携
      • 専用連携モジュールの設計
      • --use-oasis コマンドラインオプションの追加
      • 設定ファイルへのOASIS関連設定の追加
      • 連携インターフェースのサンプルコード案
      • OASIS連携に関するリスクと対策

技術的なポイント

今回の仕様書検討における技術的なポイントは以下の通りです。

  • プラグインアーキテクチャ: LLMの種類や対応プラットフォームを柔軟に追加・変更できるように、プラグイン形式の設計を採用します。これにより、コア機能と拡張機能を分離し、メンテナンス性と拡張性を高めます。
  • CI/CD統合: 開発したCLIツールをGitHub ActionsなどのCI/CDパイプラインから容易に利用できるように、標準入出力や設定ファイルの扱い、終了コードなどを考慮した設計が必要です。
  • OASIS連携: サードパーティ製ツールであるOASISを内部的に呼び出すためのインターフェース設計が重要になります。コマンドライン引数や設定ファイルを通じてOASISの動作を制御し、実行結果を適切にハンドリングする仕組みを検討しました。具体的には、--use-oasisオプションや設定ファイルでの有効化、専用の連携モジュールなどが仕様に盛り込まれました。

所感

LLMとの対話を通じて仕様書を作成するのは、非常に効率的だと感じました。項目立てや基本的な内容のドラフト作成を任せられるため、自分はより本質的な要件の検討や、既存の仕組み（開発プロセスガイド、CI/CD、OASIS）との連携部分に集中できました。

特に、OASIS連携のように、外部ツールとの連携を初期段階で仕様に組み込めたのは良かったです。後から追加するよりも、設計段階で考慮しておくことで、手戻りを減らせると期待しています。

仕様書の項目が多岐にわたることに改めて気づかされ、プロジェクトの全体像を具体化する上で非常に重要なプロセスだと再認識しました。LLMが提案してくれた構成案は網羅的で、抜け漏れを防ぐ助けにもなりました。これから始まるContent-Converterプロジェクトへの期待感が高まりました。

今後の課題

  • 作成した仕様書ドラフトの内容を詳細にレビューする。
  • 機能要件やインターフェース設計など、各項目をさらに具体化する。
  • 開発ロードマップに基づき、実装計画を立てる。
  • OASISツールの詳細な仕様やAPIを確認し、連携部分の設計を詰める。

まとめ

本日は、Diary-ConverterとNote-Converterを統合する新プロジェクト「Content-Converter」の仕様書ドラフトを作成しました。LLMとの対話を通じて、プロジェクトの目的、機能要件、アーキテクチャ、CI/CD連携、OASISツール連携などを盛り込んだ仕様書の骨子を固めることができました。今後は、このドラフトを基に詳細設計を進め、開発に着手していく予定です。

GitHubで編集を提案

Discussion