受託開発会社
社内 6 名 / 顧客 30 名課題（Before）
顧客への進捗共有はメールと表計算。社内の議論用に別ツールを併用し、情報が二重管理になっていた。
DevLog で（After）
顧客は無料アカウントで進捗を直接確認。社内の検討は内部コメントで同じ課題に集約し、ツールを 1 つに統合した。
「顧客を何人招待しても料金が変わらないので、共有をためらわなくなりました。」
DevLog の理由
“課題管理ツール”の、その先へ。
DevLog は、よくあるプロジェクト管理ツールの模倣ではありません。開発案件と AI に振り切った設計思想で、別物の体験を目指しています。
3 つの設計思想
汎用ツールと、ここが違う
あれもこれもできる“万能”ではなく、開発の現場で本当に効く方向に絞り込みました。
AI で“動く”課題管理
課題を書けば AI が実装して PR を返す。記録するだけの管理から、手を動かす管理へ。
顧客と社内を 1 案件で両立
内部コメント・社内 Wiki を可視性で分離。情報を別ツールに退避させません。
開発案件に最適化
GitHub 双方向・リリース管理・鮮度管理 Wiki・LINE 通知。汎用の“なんでも”ではなく現場特化。
比較
従来型ツールとの違い
| 観点 | DevLog | 従来型の課題管理ツール |
|---|---|---|
| AI による実装・PR 作成 | 課題から自動（MCP × GitHub） | チャット補助どまり |
| 1 案件内の情報分離 | コメント / Wiki 単位で内部・公開 | プロジェクト単位が中心 |
| ナレッジの鮮度管理 | 種別 + 確認日で陳腐化を可視化 | 通常の Wiki |
| GitHub 連携 | 既存リポと Issue / PR 双方向 | 内蔵リポ / 限定的 |
| LINE 通知 | プロジェクト単位で標準対応 | 外部連携頼み |
| ねらい | 開発・受託案件に特化 | 全職種向けの汎用 |
※ 比較は一般的な汎用プロジェクト管理ツールの傾向を一般化したものです。
こんなチームに向いています
受託・開発会社
顧客と進捗を共有しつつ、社内の議論や工数は隠したいチーム。
AI を活用したい開発
Claude で実装を自動化し、課題管理から開発までをつなげたいチーム。
GitHub 中心の現場
既存リポを活かし、Issue / PR と課題を地続きで運用したいチーム。
導入事例
現場での、使われ方
業種ごとの代表的なユースケースをご紹介します。DevLog が“どこに効くか”をイメージしてください。
SaaS スタートアップ
開発 8 名課題（Before）
課題は溜まる一方で、細かなバグ修正に手が回らない。AI 活用も“チャットで相談”止まりだった。
DevLog で（After）
課題に @claude と書くだけで実装の下書き PR が上がる。レビューに集中でき、小さな改善が滞らなくなった。
「課題を書く文化が、そのまま実装の自動化につながる感覚です。」
社内 DX / 情シス
全社 40 名 + 部門横断課題（Before）
部門ごとに依頼ツールがバラバラ。誰が見た・対応中かが分からず、二重対応や放置が起きていた。
DevLog で（After）
既読表示で対応状況が一目で分かり、通知は Slack と LINE へ。鮮度管理 Wiki で手順書の陳腐化も防げている。
「「見た／まだ」が見えるだけで、催促のやり取りが激減しました。」
Web 制作会社
制作 4 名 / クライアント別案件課題（Before）
クライアントごとの要望と社内タスクが混在。GitHub の作業とも分断され、転記の手間が大きかった。
DevLog で（After）
公開ハンドブックでクライアント向け手順を共有し、GitHub の Issue / PR は課題に自動リンク。転記がなくなった。
「クライアント向けと社内向けを 1 案件で分けられるのが効きました。」
※ 上記はサービスの想定利用シーンを示す代表例です。特定の実在企業・実績を示すものではありません。