はじめに
こんにちは、GxP の岡田です。
この記事はグロースエクスパートナーズ Advent Calendar 2025の22日目の記事です。
要約
- 案件復帰で「なぜこうなっているのか分からない」モヤモヤが増えた
- 勉強会で知った観点をきっかけに「判断の背景」を残す価値に気づいた
背景
今年、数年間離れていた案件に復帰しました。
復帰してからというもの、自分がいなかった期間に作られた機能や仕様に触れるたび、モヤモヤが少しずつ溜まっていく感覚がありました。
当初は、そのモヤモヤの正体が自分でもよく分からず、
「何となく腑に落ちない」という感覚のまま過ごしていた気がします。
そんな中、社内の勉強会で学んだロジカルシンキングの観点をきっかけに、
自分が何にモヤモヤしていたのかを言葉にできるようになりました。
その結果、
「これは未来の自分を困らせないための話だ」
と捉え直せるようになりました。
この記事では、その気づきに至るまでの経緯と、これから試していきたいことをまとめます。
案件に復帰して徐々に増してきた違和感
今年の1月に、数年間離れていた案件に復帰しました。
離任前は設計や実装がメインの作業者でしたが、復帰後はチーム全体や成果物を見たり、お客さんと調整をしたりするリーダーとしての役割がメインになりました。
お客さんからの問い合わせ対応や改修・新規要望を進める中で、離任期間に開発・改修が行われた機能や仕様に触れる機会が増えていきました。
その中で、
なぜこの作り・仕様になっているのだろう？
と疑問に思う場面が増えていきました。
チケットや設計書として使用しているWikiを見ても、
最終的な仕様は分かりますが、なぜその形に落ち着いたのか までは読み取れません。
当時のやり取りが残っていそうなチャットもありますが、量が多すぎて現実的に追い切れませんでした。
この時点では、「何が分からないのか」さえ整理できておらず、
ただ漠然とした違和感だけが残り、モヤモヤを募らせていきました。
社内勉強会で得たヒント
そんな中、社内勉強会の GxDojo （詳しくはこちら）に参加する機会がありました。
自分が参加したのは、アジャイルコーチの 高江洲 睦 さん が講師を務める、リーダーシップ育成基礎コースの中で、ロジカルシンキングをテーマにした回です。
この回では、ロジカルシンキングやクリティカルシンキングについて、
すぐに実践できる技法がいくつか紹介されていました。
その中で特に印象に残ったのが、
「行動の背景を深掘りする観点」 です。
この観点に対する答えが書かれていれば、
自分のモヤモヤは解消されるのではないか
そう感じました。
※ 以下は、GxDojo（講師：高江洲 睦 さん）で投影されていたスライドより引用しています
数ある対応方針の中から、
なぜその選択をしたのかという「判断の背景」が見えないこと に、
自分はモヤモヤしていたのだと腑に落ちました。
なぜ判断の背景は残らないのか
モヤモヤの正体が分かってきて、冷静に振り返ってみると、
そもそも自分が知りたかった 「判断の背景」 は、残るようになっていませんでした。
現在利用している Jira のチケットテンプレートは、数ヶ月先にリリースする成果物について、
関係者間の認識の齟齬を減らすこと を主目的にしています。
そのため、
- なぜ作るのか
- 何を作るのか
- どう動くのか
といった内容は書かれますが、
どんな背景や制約のもとで、その判断に至ったのか までは残りません。
なぜ「判断の背景」を残したいと思ったのか
改めて考えると、自分が「判断の背景」を気にする理由はいくつかあります。
改善し続ける仕事だから
自分たちの仕事は、一度作って終わりではありません。
顧客の変化する要望に合わせて、システムを改善し続けることが求められます。
過去に作った機能を改修する際、
当時の目的や制約が分かれば、「今に合った形に変える」という判断がしやすくなります。
システムの複雑化と透明性の低下
離任前と比べて、システムは基盤寄りになり、結合先も増えました。
自システムだけでなく、他システムの制約や前提も考慮しないと、
意図を正しく理解できない場面が増えている印象です。
自分の役割の変化
リーダーとして、問い合わせや改修・新規要望に対して判断する立場になりました。
その際、過去の「判断の背景」が分からないと、同じところでまた悩むことになります。
こうした経験を通して、
「これは未来の自分がまた同じモヤモヤを抱えるやつだ」
と強く感じるようになりました。
具体的にやろうとしている改善
ここまで書いた通り、今の運用だと「判断の背景」が残りにくく、未来の自分（や他のメンバー）が困りやすい状態になっています。
なお、「判断の背景を残す」という話には ADR（Architecture Decision Record）のように、アーキテクチャ上の意思決定を記録する考え方もあります。
一方で今回残したい「判断の背景」はアーキテクチャに限りません。仕様の落とし所、運用都合、顧客・社内調整の結果など、業務的な判断も含めた「対応方針の判断の背景」 です。
だからこそ、まずは チケット運用に“判断の背景を残す仕組み”を組み込む ところから始めようと考えています。
1. 「行動の背景を深掘りする観点」から、最低限の質問を採用する
すべての観点を毎回埋めるのは負担が大きいので、まずは自分たちの現場で効果のありそうなものを採用します。
具体的には、以下の質問をテンプレートに入れる予定です。
- 何が足りなかったのか？（制約）
- どうあるべきだと考えたか？（価値観）
- 得をすることは？（メリット）
- 何を避けようとした？（リスク）
- 他の選択肢を選ばなかった理由は？（思考の癖）
「すべてを網羅する」ではなく、未来に読み返したときに判断の筋道が再現できることを目指します。
2. Jiraのチケットテンプレートに「判断の背景」欄を追加し、エピックをDONEにする際に未入力を防ぐ（Jiraの自動化）
上で決めた質問に答えられるように、チケットテンプレートに 「対応方針の判断の背景」 を記入する欄を追加します。
自由記述だけだと書きづらくなりそうなので、質問形式で入力しやすい形に寄せます。
運用で一番難しいのは「最初は書くけど、そのうち書かれなくなる」ことだと思っています。
そこで、エピックチケットをDONEにする際に、
- 判断の背景欄が未入力
- あるいはテンプレート文のまま
の場合はDONEにできないようにするつもりです。
これは Jira の自動化 を使って仕組みとして担保する想定です。
（「書いてください」と注意喚起するだけではなく、プロセスに組み込みたい）
さいごに
今回学んだ 「行動の背景を深掘りする観点」 を用いて、
判断の背景や意図をアウトプットする取り組みを試していきたいと考えています。
それを積み重ねることで、
未来の自分や、これからこの案件に関わる誰かが、
同じモヤモヤで立ち止まらなくて済むようにしたいと思っています。
判断の背景を残すことが当たり前になっていく文化につながれば嬉しいです。
同じように
「なぜこうなったのか分からずモヤモヤする」
という経験をしたことがある方の参考になれば幸いです。