最近、「ProjectMateとは何か」を説明する機会が増えてきました。
ProjectMateは私が単独で開発・利用しているWebサービスのため、これまで説明を省略してきましたが、説明なしでは文脈が伝わりにくい状況も増えてきたため、必要なときに提示できる記事を執筆します。

ProjectMateとは

ProjectMateは、私のRedmineチケット管理を支援するWebサービスです。Python/Djangoで開発しており、個人のマネジメントダッシュボードとして日常的に使っているほか、AI関連機能を実装する際の実験場としても活用しています。

作った背景

ProjectMateを作る前にも私は自分用のチケット管理ツールや業務支援ツール自体を作り、自分で使っていました。

ProjectMate開発の転機になったのはChatGPTの登場でした。ChatGPTが登場して、新機能の開発ハードル、速度が一気に変わり、現実的に確保できる時間の中で作れるシステムの大きさが変わりました。そうなると作りたいシステムのイメージや適切な機能設計も変わっていき、作り直しました。

きっかけは、夜に1人で酒を飲んでいたときのことです。私は普段、一人で酒を飲まないのですが、数ヶ月に一回特別な節目にお酒を飲みます。その時、お酒を飲みながら、考え事をしていると普段、課題管理にもたつきイライラしていることが気になってきました。

カッとなってChatGPTに作りたいシステムのイメージを相談し、酔い覚ましに散歩しながらスマホでChatGPTと要件定義と設計をして、コードも自動生成していきました。当時、まだ精度も低かったので、ChatGPTが書いたコードをPCで私がリポジトリに取り込んでから自分でデバッグしながら動作する状態に仕上げました。

当時、解決したかった課題は、外部のホスティングのRedmineの重さや、チケット一覧のフィルタリングのしづらさ、定期タスクの手動登録の面倒さ、全体状況を俯瞰する手段の不足、といった課題でした。

主な機能

現在、ProjectMateで使っている機能を紹介します。

例えば、チケットの定期発行機能は毎日使っています。HeritageArrowの事務処理では、月次の振り込みや経費処理といった財務系の定期業務から、案件ごとの振り返りや全体計画見直しといった思考タスクまで、やるべきことは自動的にチケットとして発行されるようになっています。

また、チケット登録時のデフォルト設定や一括登録機能、自動関連付け、自動カテゴリ設定などの機能があり、チケットの整理整頓の手間も減らしています。例えば、トラッカーを選択すると事前に設定した優先度や期日が自動設定されるようになっていたり、新しいチケットが発行されるとタイトルと説明をLLMで見て適切なカテゴリが割り当てられたしします。

KPIダッシュボードもつけています。値としては、対応待ちチケット数、チケット消化速度、定期タスクの消化速度などを確認できます。全体として、運用の健全性を確認したいと考えていて、チケットが溜まりすぎていないか、ちゃんと回っているかを把握するために使っています。

全体として、Redmineを利用した課題管理の手間を減らし、運用しやすくするツールの側面が強くあります。

私のProjectMateの使い方

私は仕事を始めるときにまずProjectMateを開くようになっています。チケット処理の起点となるダッシュボードを用意しているからです。内部ではRedmine APIをコールしてチケット一覧を取得して、フロントエンド上でフィルタリングしたり優先度を確認しやすくなっています。実際のデータはRedmineを見にいきます。

ProjectMateがあることによって、Redmineは単なる日々のタスクではなく、自己観察と改善のサイクルを回すための基盤として機能します。自分で決めた運用ルールをProjectMateを通してRedmineに課題として発行し、それがどれくらい守れているか、守れていない場合は何が原因か、といった分析の素材をProjectMateで集めて見える化します。そうしてKPIをチェックして振り返り、改善課題を検討する流れも、定期発行されるチケットを起点に回しています。継続的で無理がない活動を作っていくために、ProejctMateが動いています。

実験場を持つということ

一方で、ProjectMateは、Webサービス開発の実験場という側面もあります。ProjectMateには、様々な実験的なAI関連機能が入っています。AI機能だけでなく、Slack連携、Discord連携、各種サービスからWebhookを受け取って処理する機能など、色々な外部サービス連携の実験機能が入っています。これまでに300本ほどのPRがマージされています。

私は、開発者は誰もが自分の実験場を持つべきだと思っています。自分の権限で自由に編集できるプロダクトがあることで、気軽に実験ができるようになります。このような考え方はアプレンティスシップパターンや達人プログラマーでも紹介されていた記憶があります。（記憶なので曖昧ですが）

それによって、自分が管理する場所で新しい取り組みにチャレンジして、うまくいったものを他のプロジェクトに展開するという流れを作れるようになります。

AI活動の実験

先ほど、軽く触れたようにProjectMateは、AI関連機能を試す実験場としても活用しています。

具体的な話を紹介してみると、チケットに対して様々な角度からAIを当ててきました。自動レビュー、自動トラッカー設定、自動要約といった分析系の機能から、自動タスクバラシ、自動日報生成、自然言語でのタスク登録といった生成系の機能まで試しています。実際にそれを作りつつ、自分で使いつつ、どういう効果があるかを考えつつ調整しました。

また、コーディングエージェントが登場してからは、そちらの実験場にもなりました。自動バグ修正、機能開発、リファクタリング、ドキュメント生成、セキュリティチェックなど、思いつくことを気軽に試しています。自分で作っているサービスなのでコードベースや技術構成を把握しており、何ができるか検証しやすい環境になっています。

やってみることの価値

さらにいうと、私としては、やってみることが大切だと思っています。やってみたから話せること、生み出せる価値があります。それを体現する場所になっています。

ProjectMateにはゴミ機能が山のように入っています。試してみたけど使わなくなったもの、思ったより便利じゃなかったものです。時に削除していくこともあります。それでいいと思っています。たくさん作って、そこから本当に使えるものだけをピックアップして使い続けるのが大切です。

やってみて分かったことはたくさんあります。例えば、AIに開発を任せるとレビューが甘くなりやすく、ドキュメントがないと私のレビュー負担や設計の負荷も高い。そこで、モノレポにしてドキュメントも同居させて、その負荷を下げています。

実際にドキュメントはSphinxで書いています。というか、ドキュメントもClaudeCodeに書かせてみて、開発プロセスやコーディング規約、アーキテクチャドキュメントも入っています。AIに仕様を書かせて設計させる流れも作りましたし、GitHub ActionsでClaude Codeのレビューも走らせています。ドキュメントとコードの不一致をAIでスキャンして矛盾が見つかれば、個別調整します。

また、ヒヤッとしたこともあります。その一つは、気づいたら一部の画面で認証がなかったことです。その画面自体は機能一覧くらいしかなくて、チケットの中身は見れない画面なのですが、「AIに明示的に仕様として認証が必要なことを伝えないとそんなことになるのか」と驚いたことを覚えてます。普通、認証はかけるでしょ、と思ってました。そのタイミングで、認証なしの画面はホワイトリストとして設定して明示しない限りは認証がかかるようにユニットテストを追加しました。

こうした経験は、他のプロジェクトでAIを活用するときにも活きています。HeritageArrowのバリューに「実践を重ね信頼を築く」があります。ProjectMateは、その姿勢を自分自身で体現している場所でもあるでしょう。