Confluenceで合意したのに、なぜJiraチケット化が一番しんどいのか考えてみました

最近、開発タスクの整理とチケット化について考える機会がありました。
今日はその中で感じた違和感と、そこから見えてきたプロセス改善の余地について書いてみます。

これはまだ自分の中で整理途中の考えですが、同じように悩んでいる人の参考になればと思い、書き残しておきます。

まず、開発側のタスクを Confluenceの表 にまとめ、チームで内容を確認・合意しました。
その後、Miro を使ってスケジュール感を整理し、レビューも受けています。

Miroを使った理由は単純で、サクッと描けるからです。
議論しながら配置を変えたり、粒度を揃えたりするには、とても相性が良いと感じています。

ここまでのプロセス自体には、一定の意味はあったと思います。
タスクの背景や優先度について、チームとして納得感のある合意が取れたと思います。

ただ、その次の Jiraへの正式なチケット起票 の工程で、強い負荷を感じました。

ConfluenceやMiroで合意しているにもかかわらず、
Jiraに起票する段階で、
すでに合意している内容をJiraのチケットとして書き直す作業が発生します。

Jiraへの起票で重かったのは、何をやるかを考えることではありません。
すでに合意している内容を、Jiraのチケットとして書き直す作業そのものが、
思っていた以上に負荷の高い作業だと感じました。

振り返ってみると、問題は「ConfluenceやMiroを使ったこと」ではありません。
問題は、
合意された内容を、そのまま自然にJiraチケットへ移せないプロセス
にあると感じました。

現状では、Confluenceの表もMiroのボードも、
最終的には「参考情報」として扱われ、
Jira起票時にもう一度、個人が作業を引き受ける構造になっています。

その結果、
合意 → 合意 → 最後に個人作業が集中
という流れになり、ここが一番しんどくなります。

この違和感から、
「正式な開発チケット化のプロセスそのものに改善余地があるのではないか」
と考えるようになりました。

例えば、

といった工夫が考えられます。

また、Confluenceの表が機械可読な形で整理されていれば、
Claude Codeなどを使って、
「Readyな行だけをJiraチケットとして起票する」
といった半自動化も現実的です。

こうなれば、Jira起票は考える場ではなく、
確認して生成する場 に近づいていくはずです。

追記：JiraをSoTにする、という別の考え方について

この記事では、Confluenceを起点に合意形成を行い、その後Jiraへチケット化する流れについて書いてきました。
一方で、そもそも JiraをSingle Source of Truth（SoT）と割り切る設計 も、十分に考える価値があると思っています。

JiraをSoTにすれば、タスクの二重管理はなくなり、
起票から実行、完了までが一本の線でつながります。
また、自動化やAPI連携、Claude Codeのような生成AIとの相性も良くなります。

ただし、Jiraは「実行の場」としては強い一方で、
検討途中のアイデアや、まだ確定していないタスクを扱うには、
心理的にも操作的にも少し重いと感じることがあります。

そのため、JiraをSoTにする場合は、

といった前提条件が必要になりそうです。

ConfluenceをSoTにするか、JiraをSoTにするかは、
どちらが正しいという話ではなく、
「どこで一番摩擦が生じているか」によって選ぶべきものだと感じています。

今回の違和感は、Confluence起点のプロセスから生まれたものですが、
同時に、JiraをSoTにした場合の設計についても、改めて考えるきっかけになりました。

まだ明確な正解は出ていません。
ただ、今回の経験を通して、

合意形成はできているのに、
最後のチケット化だけが重いのは、個人の問題ではなくプロセス設計の問題

だと、はっきり言語化できました。

次は、この仮説をチームの中で少しずつ試しながら、
本当に楽になる形を探っていきたいと思います。