• Home
• コーポレートブログ
• Redmine関連ビューアーを仕様駆動開発で作ってみた

こんにちは。開発グループの吉岡です。

なぜRedmineビューアーを作ったのか

Redmineに関連するビューアーを作りました。

一番の理由は、自分が使いやすいRedmine関連のビューアーが欲しかったからです。普段の作業では、情報を開いて確認する操作を何度も行います。だからこそ、Macで軽快に動き、見たい情報にすぐアクセスできるものが欲しいと思いました。また、表示のレイアウトや情報の出し方には好みがあります。既存のツールに合わせるのではなく、自分の作業スタイルに合った表示を実現したいという思いもありました。

もう一つの理由は、Redmineに関係するものを作りたかったことです。私たちの会社ではRedmineのホスティングサービスを提供しています。せっかく個人開発をするなら、会社の事業とも関係のあるものを作りたいと考えました。

以前からRedmineの見た目を変えるプロダクトを作ったりもしていたので、Redmineの使い勝手や見え方を変えることには関心がありました。今回のビューアーも、その延長として作ったものです。

なぜ仕様駆動開発を試したのか

今回の開発では、Claude Codeとcc-sddを組み合わせて、仕様駆動開発を試しました。Claude Codeでは、主にOpus 4.8を使用しました。

cc-sddは、AIコーディングで仕様駆動開発を進めるためのツールです。要件定義、設計、タスク分解、実装という流れを整理しながら開発できます。

仕様駆動開発を試した理由は、AIを使った開発が今後どう変わっていくのかを考えたかったからです。AIを使うと実装は速くなりますが、曖昧なまま進めると、期待と違うものができたり、途中で方向性がぶれたりします。そこで今回は、先に仕様を整理してから実装する流れを試しました。仕様駆動開発そのものを目的にしたというより、AIを使った個人開発やチーム開発の変化を考えるための実験として取り組みました。

作ったもの

作ったものは minedock です。minedock は、複数の Redmine サーバーに接続できる macOS 向けの閲覧専用ビューアーです。

https://github.com/yoshiokaCB/minedock

minedock は、Redmine の REST API を利用して、チケットや Wiki などの情報を取得します。Redmine のデータを直接変更するのではなく、API 経由で取得した情報を macOS アプリ上で見やすく表示する、という構成です。

主な機能は次のとおりです。

• 複数サーバーの管理: 名前・URL・API キーを登録し、サイドバーから切り替えて使えます。API キーは macOS の Keychain にセキュアに保存されます。
• プロジェクトツリー: VS Code に近い 2 ペイン構成で、左側にプロジェクト一覧をツリー表示します。展開するとチケット一覧と Wiki ページが並びます。
• チケット閲覧: チケットを開くとタブで並べられます。説明・コメントは Markdown または Textile 記法に応じてレンダリングされます。ステータス・担当者・優先度でのフィルタリングにも対応しています。
• Wiki 閲覧: Wiki ページのレンダリング表示とページ内リンクの遷移ができます。
• ローカルファイルツリー: Redmine のツリーと切り替えて、ローカルのファイルシステムも閲覧できます。

いずれも閲覧専用で、作成・編集・削除はスコープ外としました。今後追加予定です。

仕様駆動開発の流れ

cc-sdd では、次の順序で作業を進めました。

1. 要件定義 — 「何を作るか」を EARS 形式で書き出します。今回は、サーバー管理、プロジェクトツリー、チケット閲覧、Wiki 閲覧、レイアウト、パフォーマンスの 6 つの要件に整理されました。
2. 技術設計 — アーキテクチャ（MVVM + Service 層）、コンポーネント境界、データフロー、使用ライブラリを決めます。Keychain の保存スキーマや Redmine API との契約もここで明確化しました。
3. タスク分解 — 設計をもとに実装タスクをリスト化します。Foundation（モデル・永続化・API クライアント）→ Core（各機能の ViewModel/View）→ Integration（シェル統合・キャッシュ）→ テストという順序で、約 20 のタスクに分かれました。
4. 実装 — タスクリストに沿って、AI が実装を進めます。

技術的な選択

今回は、あえて自分がこれまで経験したことのない開発をしようと思い、MacのネイティブアプリをSwiftで開発しました。

主な技術的な選択は次のとおりです。

• SwiftUI + Swift Concurrency: UI は SwiftUI、非同期処理は async/await で統一しました。
• 2 ターゲット構成: MinedockKit（フレームワーク）と minedock（アプリシェル）を分離し、アプリを起動しなくてもテストが動く構成にしました。
• Markdown / Textile の両対応: Markdown は swift-markdown-ui、Textile は WKWebView + ローカル変換 + CSS で対応しました。外部依存を増やしすぎずに、両方を扱えるようにしています。

やってみた感想

仕様を先に書いてから実装に入ることで、AI に依頼するときに「何を伝える必要があるのか」が明確になりました。 今回の開発は、最初に次のようなアイデアを AI に伝えるところから始めました。

参考: 最初のアイデア

Macのネイティブアプリを作る。
swiftを使う。（GPUも使用して高速に動かしたい）
RedmineにRest API でRedmineにアクセスする。
AIと連携できるようにする。文章生成、チケットの要約、チケットの内容に応じて調査するなど。

Redmineのチケットとwikiを閲覧できる。
レイアウト
vscodeをベースに考える。
左側
プロジェクトツリー。その下にチケット、wikiのリスト。
タブで切り替えてローカルファイルも表示する。
中央エリア
チケットの詳細やwikiを表示
右エリア
AIのチャット欄。
下エリア
ターミナルを表示する。

Redmineのチケットとwikiを編集できる。
機能は可能な限りRedmineと同等にする。
編集用のInputフィールドはvimのキーバインドで操作できるように変更ができるようにする。
通常の編集とコメントができる。

この時点では、まだかなり曖昧なアイデアです。それでも AI は、ここから要件や設計を整理し、さらにコードの生成まで進めることができます。ただし、曖昧なアイデアのまま直接コードを書かせると、出来上がったものが意図とずれていても気づきにくくなります。今回のように、先に要件や設計を作っておくと、生成されたコードが自分の考えていたものに合っているかを確認しやすくなりました。

一方で、仕様を書いたからといって、すべてがその通りに進むわけではありません。今回も、UI イベントのルーティングや idle/loading 状態の扱いなど、設計段階では見えていなかった問題が実装後に出てきました。そのため、実装しながら仕様や設計を見直す場面もありました。この経験から、仕様駆動開発は「最初に全部決める」ためのものではなく、「実装前に考えるべきことを整理しておく」ためのものだと感じました。

また、エラーが発生しても、以前ほど焦ることはありませんでした。エラー内容や起きている状況を自然言語で AI に伝えるだけで、原因を調査し、修正まで進めてくれました。

今回は、仕様駆動開発をしたからといって、最初から完全に期待通りのプロダクトができたわけではありません。それでも、最初の曖昧なアイデアから考えると、かなり精度の高いものが作れたのではないかと思います。

一方で、現時点では「設計が正しいかどうか」をどう判断するかが重要だとも感じました。今回のように、開発経験の少ない言語やプラットフォームを使う場合、その判断は簡単ではありません。実際に、AI に確認しながら進める場面も多く、それなりに時間はかかりました。ただ、実装そのもののスピードは非常に速いです。設計の精度を高められれば、AIを使った開発ではかなりのスピードでプロダクトを作れるのではないか。今回の開発を通じて、その期待感を持つことができました。

まとめ

今回は、Macで動くRedmine関連のビューアー minedock を、仕様駆動開発で作ってみました。

一度で完全に期待通りのものができたわけではありませんが、最初のアイデアを仕様や設計に落とし込みながら進めることで、かなり形にすることができました。今回の経験を活かして、今後はより精度高く、より速く開発できるようにしていきたいです。

minedock はまだ閲覧専用ですが、今後は作成・編集・削除への対応や、AI連携などの機能追加も考えています。せっかく仕様駆動開発で作り始めたので、今後の機能追加も同じ流れで進めていきたいと思います。

引き続き、minedock を実際に使いながら改善しつつ、AIを使った開発の進め方についても試していきます。

---