「issue駆動」から「ユーザーストーリー駆動」へ：小さなチームの実践とつまずき集

PdM 歴 2 年目の kiki です。これは READYFOR Advent Calendar の 18 日目の記事です。

READYFOR で開発しているいくつかのチームのうち、私が所属しているのは PdM 1〜2 名・エンジニア 3〜4 名（BE/FE 混在）の小規模チームです。このチームで、タスクの単位を「issue」から「ユーザーストーリー」に切り替える取り組みを行いました。

スクラムで 2 週間スプリントを回しており、朝会・スプリントプランニング・スプリントレビュー・デモといったイベントは一通り実施しています。

本記事では、PdM だけでなくエンジニアやマネージャーの方にも向けて、

なぜユーザーストーリー単位に切り替えたのか
どのように運用しているのか（見積もり・QA・PR レビューなど）
実際に出てきた問題と、それに対してどのような改善策を取っているか

を具体的に紹介します。

「ユーザーストーリーで開発しよう」とはよく言われる一方で、実際にやってみると痛みも多く、運用で迷うことも多いと思います。
これからユーザーストーリー単位での開発を検討しているプロダクト開発チームの参考になれば幸いです。

これまでのタスク運用と課題

以前の私たちの進め方は、ざっくり次のような形でした。

実現したい機能ごとに「親 issue」を作成
そこから BE issue / FE issue の sub-issue を作る
BE / FE それぞれの担当エンジニアに割り振って実装
両方の issue が終わったら、どちらかがコードを統合し、テストして QA へ

この形で困っていたのは主に以下の点です。

統合の責任が曖昧
- 誰が最終的に統合・動作確認をして QA に回すのかが、その都度あいまいになりがちだった
- BE 側も FE 側も「自分は担当範囲だけ完了した」という感覚になりやすく、ユーザー価値単位では見えづらい
コミュニケーションコストの増大
- 「BE のここをこう変更したので FE では〜」といった擦り合わせが頻発
- 特にリモートワーク環境だと同期的なやり取りに乗せづらく、PR 上のやり取りが長くなりがち
エンジニアとしての成長機会が分離される
- BE / FE がきれいに分かれすぎていることで、「機能全体を設計しきる」経験がしづらい

issue 駆動からユーザーストーリー駆動への before / after

ここまでが「以前の進め方」と「そこから見えていた課題」でした。
実際には、次のような形で運用を切り替えています。

観点	before：issue 駆動	after：ユーザーストーリー駆動
タスク単位	機能ごとの親 issue > BE/FE sub-issue	ユーザーストーリー 1 枚を基本単位にする
担当の持ち方	BE / FE で別々のエンジニアが担当	原則として 1 ストーリー = 1 エンジニア（BE/FE 横断）
統合・QA への責任	BE / FE どちらかが都度担当（曖昧）	ユーザーストーリー担当者が統合〜QA 依頼まで一貫して担当
完成の定義	実装完了 + なんとなくの動作確認	受け入れ条件・非機能を満たし、PdM/QA チェックまで終える
進捗の見え方	BE / FE issue ごとに細かく見える	ユーザーストーリーを軸に、チェックボックス / sub-issue で補完

この after 側の運用について、次の章以降で順に掘り下げていきます。

ユーザーストーリー単位にした狙い

今回、次のような方針に切り替えました。

「ユーザーストーリーの中のタスクを複数人で分担する」のではなく
→ 「ユーザーストーリーごとに担当者を決めて開発する」 を基本形にする
原則として、1 つのユーザーストーリーを 1 人のエンジニア（BE/FE 兼任）に持ってもらう
どうしても進捗が芳しくない場合は、
- ペアプロを依頼する
- 必要に応じて、ユーザーストーリーから技術タスクを切り出して、得意な人に振る
  といった柔軟な運用を許容する（割り振りの判断はそのストーリーの担当者が担う）

この方針には、主に 2 つの目的があります。

統合とテストの責任を明確にする
- 「誰が統合して QA に回すのか」をユーザーストーリーの担当者に一本化する
- BE/FE のタスクが終わった後の 統合・動作確認・QA 依頼といった「最後の仕上げ」 が宙に浮かないようにする
プロダクトエンジニアとしての成長機会を作る
- BE も FE も、機能全体をユーザー視点で捉え、仕様・実装・テストまで通す経験を積む
- とはいえ無理はせず、ペアプロや技術タスク切り出しで段階的にサポートする

「完成」の定義と、誰がどう確認するか

ユーザーストーリー単位にするうえで、最初にチームで揃えたのが「何をもって完成とみなすか」です。

完成の定義

受け入れ条件を満たしている
- エンジニアが自分で動作確認を行い、ユーザーストーリーに記載された受け入れ条件をすべて満たしている
PdM（または委譲されたメンバー）による QA が完了している
非機能要件を満たしている
- 例えばパフォーマンス制約やログ出力、トラッキングなど、そのユーザーストーリーが満たすべきもの
受け入れ条件に書かれていないが見つかったものは別 issue にする
- 想定外の改善点などは新しい issue に切り出し、元のユーザーストーリーは「完成」とする

誰が確認するか

セルフチェック
- ユーザーストーリーの開発担当者が、受け入れ条件をもとに自分でチェックする
- 複数人で対応する場合は「主担当」を決め、主担当がセルフチェックを行う
PdM または PdM が委譲したメンバーによる確認
重要度の高いユーザーストーリーの場合
- 三段階で確認する
  1. 担当エンジニアのセルフチェック
  2. PdM
  3. QA エンジニア
軽微な修正の場合は、QA エンジニアに依頼せず PdM のみが確認することもあります。

ユーザーストーリー単位の見積もりプロセス

1. ユーザーストーリー管理の流れ

ユーザーストーリーの「Who（誰が）, What（何を）, Why（なぜ）」のうち、「Who, What」の「誰が何をできる」単位で分解
- 例：[ST_001] 学習アプリ利用者は個別の学習進捗を把握できる
ユーザーストーリーの「Why」は README.md に記述する
ユーザーストーリーは GitHub で管理
要件やデザインの変更があれば PdM が PR を作成 し、エンジニアや他のメンバーにレビューを依頼
要件が固まったタイミングで、主幹エンジニアがそのユーザーストーリーに仕様（スキーマや BE/FE 向け情報、関連リンクなど）を追記
仕様に対して、エンジニアが PR レビューを行う

ディレクトリ構成例

.
└── 機能名/
    ├── 共通系仕様/
    │   ├── 認可一覧.md
    │   └── DB設計.md
    ├── ADR/
    │   └── ADR_001.md...
    ├── ST/
    │   ├── ST_001.md
    │   └── ST_002.md...
    ├── main.md
    └── README.md

2. 見積もりの 2 段階

(1) 開発時期を決めるための概算見積もり

主幹エンジニアが、ある 1 つのユーザーストーリーに概算 pt をつける
そのストーリーを基準として、他のユーザーストーリーにも「相対見積もり」をつける
概算の相対見積もりを、チームのエンジニアがレビューし、相対関係としての pt を固める
相対見積もりを付けたストーリーのうち 1 つを選び、仕様策定・タスク分解をして、従来のやり方で「絶対値としての pt」をつける
その値を基準にして、他の相対見積もりをより現実的な pt に変換する

ここまでで、リリース計画や開発時期の目安を出します。

(2) 実開発前の詳細見積もり

実際に着手する直前に、改めて仕様策定を行い、
チームで Planning Poker を使って、ユーザーストーリー単位でストーリーポイントを再見積もりします。

3. スプリントを跨いだ場合の扱い

スプリント終了時点で受け入れテストをパスしていないユーザーストーリーは、そのスプリントには pt を計上しない
完了した時点のスプリントに pt を計上する
前提が変わったなどの場合は再見積もりする
スプリントゴールを検討する際は、
- 持ち越しユーザーストーリーの pt は「50%」として扱う（issue 上の pt は変えない）
- スプリントゴールに含めず先んじて取り組んだユーザーストーリーは 100% として扱う

ユーザーストーリー単位にして「良くなったこと」と「痛み」

良くなったこと

メンバーのユーザーストーリー理解度が上がった
- BE/FE をまたいで 1 人が持つため、「自分の担当範囲だけ理解する」では進められなくなりました。
- 理解が不足していると実装で詰まったり、他のユーザーストーリーと噛み合わなくなるため、自然と認識合わせの MTG が増え、理解度は上がらざるを得なかったという感覚があります。
QA しやすくなった
- 受け入れ条件がユーザーストーリーごとに整理され、PdM/QA から見ても「何を確認すれば良いか」が明確になりました。

痛み・課題

リードタイムが長くなり、ベロシティは下がった
- 「BE だけ終わっている」「FE だけ終わっている」という中途半端な完了が減る一方で、1 人が全体を持つ分、完了までの時間はどうしても伸びました。
エンジニアの理解コストが高い
- ユーザーストーリーに対する理解が必須で、そのための仕様策定や認識合わせの時間が増えます。
- 一方で、この投資が仕様抜けや QA 時の手戻りを減らしている面もあります。
技術的タスクとペアプロの扱い
- 各人が得意でない技術領域のタスクは、得意な人とペアプロで対応することが多いですが、
  - そこに至るまで PR 上でのやり取りが長くなりがち
  - リモートワーク環境もあり、「相談しに行くまでの一歩」のコミュニケーションが難しい

といった課題も見えました。

スプリントを回して見えた問題と、採用した改善策

ここからは、実際にスプリントを回すなかでチームとして直面した具体的な問題と、その都度入れていった運用改善をいくつか紹介します。
PdM だけでなく、エンジニアやマネージャーの方にも「自分たちならどう運用するか」をイメージして読んでいただければと思います。

1. PR からは「全体」が見えない問題 → main.md 自動更新

問題点

ユーザーストーリーや要件のレビューを PR ベースで行っていると、
- 「いまプロダクト全体のどの部分を見ているのか」が分かりづらい
- ユーザーストーリーが複数 PR に分かれると、どこが欠けていてどこが重複しているのか、俯瞰しにくい

採用した改善策

各ユーザーストーリーの PR がマージされるたびに、特定のマークダウン（今回は main.md）を自動更新する GitHub Actions の workflow を作成
main.md には、
- ユーザーストーリーの一覧
- 各ストーリーの要件
  だけを抜き出して記載し、「プロダクトバックログの要件ビュー」のように使えるようにしました。

これにより、PdM や新しく入ったメンバーでも「いま何が積み上がっているか」を一枚で把握しやすくなりました。

2. PR レビュー依頼が忘れられがち → Slack 連携でリマインド

問題点

PR のレビュー依頼が埋もれ、要件の確定が遅れることがある
- GitHub の通知だけだと、他の通知に紛れて見逃しやすい

採用した改善策

Slack bot と GitHub を連携し、
- PR 作成時に自動でレビュー依頼を通知
- レビューが一定期間進まなかった場合にリマインド
  するようにしました。

3. 8pt のユーザーストーリーが大きすぎて詰まる → pt と分割ルールの明確化

問題点

8pt をつけていたあるユーザーストーリーが大きすぎ、最終的に 3 つに分割することになりました。
ただし、「ユーザーストーリーとして意味を持つ単位」で分けた結果、技術的には互いに影響し合う構造になり、開発の進行が滞ってしまいました。

採用した改善策

分けた場合でも、同じエンジニアがそれらを担当し、別のユーザーストーリーと並行して進める 方がスムーズだと判断しました。
ルールとして、
- ユーザーストーリーの pt が 5 以上
- かつ 1 スプリント以内に終わらないボリューム と判断した場合は、
  ユーザーストーリーを FE / BE のタスクに再分割して、担当を分けることも検討する

これにより、「大きすぎるユーザーストーリーに固執して全員が詰まる」状態を避けるようにしています。

4. 進捗が見えづらくなった → チェックボックスと sub-issue で可視化

ユーザーストーリー単位の開発に切り替えてから、意外と困ったのが進捗の見えづらさでした。

タスク単位（BE issue / FE issue など）で管理していた頃は、

BE 側の実装がどこまで進んでいるか
FE 側の実装がどこまで進んでいるか

が issue レベルで細かく見えていました。一方、ユーザーストーリーを 1 枚の issue として扱うようになると、そこで起きている作業がすべて「1 枚のカードの中」に隠れてしまい、スプリント中盤で「どこまで進んでいるのか」が把握しづらくなるという問題が出てきました。

問題点

タスク単位で細かく分かれていたときよりも、進捗状況が粗くなった
スプリントの途中で、ボード上からは次のような状態が見えにくくなった
- 「実装はもう 8 割終わっているのか？」
- 「まだ設計や調査の段階なのか？」
- 「BE は終わっていて、FE だけ残っているのか？」

PdM としても、「このユーザーストーリーはスプリント内で終わりそうか？」を判断しづらい場面が増えました。

採用した改善策：ユーザーストーリー issue 内で進捗をブレイクダウンする

そこで、ユーザーストーリー issue の中に進捗をブレイクダウンして見せる仕組みを入れました。具体的には、次の 2 つを併用しています。

1. ユーザーストーリー issue にチェックボックスを作る

ユーザーストーリーを構成する主要な作業を、ざっくりと箇条書きにしてチェックボックス化します。

例：

- [ ] BE: API エンドポイントの設計・実装
- [ ] BE: テストコード追加
- [ ] FE: 画面コンポーネント実装
- [ ] FE: バリデーション・エラーハンドリング
- [ ] 動作確認（受け入れ条件チェックリストに基づく）
- [ ] PdM / QA の確認

これにより、1 つのユーザーストーリーの中でも、「いまどのあたりまで来ているか」を issue を開けば一目で共有できるようになりました。

2. 必要に応じて sub-issue を作り、Projects と同期する

もう少し細かい進捗管理が必要な場合や、複数人で並走する場合は、
- ユーザーストーリーを親 issue とし、
- 技術タスクや作業単位ごとに sub-issue を作成します。
GitHub Projects 上では、sub-issue のステータス（Todo / In Progress / Done）をそのまま進捗として扱い、ユーザーストーリーの進み具合をボード上でも可視化するようにしました。

効果

スプリントレビュー前に「どのストーリーがどこまで進んでいるか」を、PdM も含めて把握しやすくなりました。
「ユーザーストーリー単位」による責任の明確化を維持しつつ、「タスク単位」のときにあった進捗の見やすさも、ある程度は取り戻せたと感じています。

5. 動作確認の漏れ → 受け入れ条件のチェックリスト化

問題点

デモ前の動作確認の段階で、いくつかの対応漏れや、要件通りに実装できていない部分が発覚することがあった

採用した改善策

動作確認ステップのルール化
- GitHub 上で管理しているユーザーストーリーの「受け入れ条件」を、そのまま チェックリスト にしておく
- 動作確認時には、そのチェックリストを Issue にコピペし、1 つずつ実施・チェックしていく
実施タイミングの定義
- すべての PR がマージされた後、デモ・QA を行うまでの間に実施
- GitHub Projects に「開発者テスト」用のカラムを追加し、
  そこで開発者テストを完了させてから QA に回す
- 検証環境は、原則フルセット環境を使用
受け入れ条件記述の質を上げる
- 受け入れ条件部分のレビューに、先輩 PdM が入るようにしました。チェック観点は以下です。
  - MECE になっているか
  - 受け入れ条件として適切な書き方になっているか
  - 前提条件・操作・期待値が明確か
要注意パターンの蓄積
- 開発者テストでは通ったが、デモで確認漏れになったケースなどは、
  - 前提条件ごとの期待値を明記するようにする
  - ユーザーストーリー管理リポジトリの README.md に「要注意パターン（因子水準表）」として追記し、次の受け入れ条件定義に活かしていく

6. 自分が得意でない領域の開発に時間がかかる → 並走の仕組みづくり

問題点

BE を主に担当していたメンバーが、ユーザーストーリー単位になったことで FE も持つ必要が出てきた
普段触っていない側の技術領域の実装に時間がかかる

採用した改善策

PR を積極的に小さく分ける
- 早い段階からレビューをもらい、方向性のズレを小さくする
コミットを整理し、レビューしやすくする
ペアプロを積極的にリクエストする
アサイン時に「独走か並走か」を決める
- 実質的に 2 人をアサインし、メイン担当・サブ担当を決めておく
- 毎日 30 分、そのストーリーについて話す時間を設け、必要なくなれば頻度を下げる

これにより、「分からないまま 1 人で長い時間抱え込む」状態を減らすことを目指しました。

7. PR のリードタイムが長い → GitHub Actions + ラベルで可視化

問題点

PR のリードタイムが全体的に長くなっている
- PR 上のやりとりが多く、1 日 1 往復くらいしか進まない
- 軽微な指摘も多く、レビューの往復回数がかさむ

採用した改善策

Copilot による事前レビューを必須化
- 再レビュー前には必ず Copilot のレビューを挟み、軽微な指摘は極力そこで解消するようにしました。
長引く PR の同期的クローズ
- 初回レビュー依頼から 翌々日になっても終わっていない PR は、同期的に終わらせる ことをルール化
- GitHub Actions を設定し、
  - 一定期間オープンな PR に自動でラベルを付与
  - それをトリガーに、ミーティングでまとめて対応する

8. ユーザーストーリーにならない「技術的前準備」が大きい

問題点

ユーザーストーリー単位で開発しようとしたものの、
- 実際には、要件定義や仕様策定と並行して、
- 「ユーザーストーリーとはならない技術的な前準備の issue」
  が思ったよりも大きくなってしまうことがありました。

対応の方向性

技術的前準備は、あえて「技術ストーリー」としてユーザーストーリーと同列に扱うか、
もしくは「インフラ・基盤改善」系のエピックとしてまとめ、その配分をスプリントプランニングで明示的に行う

上記のような形を模索中です。

まとめ：チームとして握るべきは「粒度」と「前段の設計」と「学習サイクル」

ユーザーストーリー単位に切り替えてみて、チームとして大きかった学びを整理すると、次の 3 つでした。
特に PdM にとっては意思決定ポイントになりますが、エンジニアやマネージャーにとっても押さえておきたい観点だと感じています。

ユーザーストーリーは「正しさ」だけでなく「粒度」が 8 割
受け入れ条件の設計は「要件定義」ではなく「テスト設計」でもある
ベロシティ低下を「失敗」とせず、学習サイクルに組み込めるかが勝負

順に簡単に触れます。

1. ユーザーストーリーは「正しさ」より「粒度」のほうが運用に効く

導入前は、どちらかというと

「ユーザーストーリーの書き方はこれで正しいか」
「ユーザー価値はきちんと表現できているか」

に意識が向いていました。

実際に運用してみて痛感したのは、チームの健康状態に効くのは 「中身の正しさ」よりも「粒度の適切さ」 だということです。

8pt のストーリーが大きすぎてスプリントを圧迫したり
分割したもの同士が強く依存し合い、進行が滞ったり

といった問題は、ほとんどが「粒度」に起因していました。

PdM にとってはストーリーの切り方そのものが課題でしたし、エンジニアにとっては「どこまでを 1 枚のチケットとして持つのか」が日々の負荷感に直結していました。

そこで、いまのチームでは「粒度」について、次のような 実務寄りのルール を置いています。

粒度に関するチームルール（現時点の版）

「1 ユーザーストーリー = 1 スプリント以内に終わるサイズ」が基本
- 見積もり時点で「このストーリー単体で 1 スプリントを超えそう」と感じたら、必ず分割を検討する
- 「スプリントを跨ぐのが当たり前のストーリー」は極力なくす
pt のしきい値で「要注意ストーリー」を炙り出す
- ユーザーストーリーの pt が 5 以上 の場合は、「粒度を疑う」フラグとみなす
- そのうえで、次の観点で話すようにしています。
  - このストーリーは「1 人で FE/BE を通しきれるか？」
  - それとも「FE/BE に分けないと、完了まで長く抱えすぎてしまうか？」
- 「1 人で持つには重いが、ユーザー価値としては 1 枚で扱いたい」ケースでは、
  - ストーリーは 1 枚のまま
  - 中のタスクを FE/BE に軽く分割しつつ、同じエンジニアが束ねて担当する
    といった落としどころも許容しています。
「分割のタイミング」と「分割したあとの持ち方」を決めておく

粒度の失敗で詰まりやすいのは、「いつ分割するか」「分割したあとに誰がどう持つか」が場当たりになるときでした。そこで、次をルール化しています。
- 分割を検討するタイミング
  - 見積もり時点（Planning Poker）
  - スプリント前半で「明らかに終わらなさそう」と感じた振り返りタイミング
- 分割したあとの原則
  - まずは 同じエンジニアが複数ストーリー（または sub-issue）を束ねて持つ ことを優先
  - どうしても詰まる場合だけ、FE/BE で担当を分ける
  - 担当を分けた場合でも、「誰が最終的に統合して QA に出すか」は 1 人に決める
「粒度ルール」そのものも振り返る
- 各スプリントの振り返りで、
  - 「大きすぎて詰まったストーリー」
  - 「細かくしすぎてかえって進みにくかったストーリー」
    をピックアップし、
    「このケースは現行ルールで防げたか？ルールを変えるならどこか？」を軽く話すようにしています。
- ここで出た学びは、スプリントの Try として追記しておき、次のプランニングのときに参照します。

このくらいまで粒度を「言語化されたチームルール」にしておくと、

PdM 側は「どこで分けるべきか」を一人で悩みすぎずに済み、
エンジニア側も「大きすぎるストーリーを抱え込んでいるときに、どのタイミングで声を上げればいいか」が分かり、
新しく入ったメンバーにも、「このチームにおけるユーザーストーリーの大きさの感覚」を早めに共有できるようになりました。

2. 受け入れ条件の設計は「要件定義」であり「テスト設計」でもある

もうひとつ大きかったのは、受け入れ条件の設計が QA と開発者テストの品質をほぼ決める、という実感です。

PdM が書いた受け入れ条件を、
- 開発者テストのチェックリストとして使い、
- PdM / QA も同じリストで確認する
その前提として、
- MECE になっているか
- 前提条件・操作・期待値が具体的か
- 要注意パターンがカバーされているか
  を PdM 同士でレビューする

こうした運用を入れたことで、

「動作はしているが、PdM の意図したユーザー体験になっていない」
「開発者テストでは通ったが、デモで想定ケースの取りこぼしが出る」

といったズレが減っていきました。

PdM の仕事として、

エピック / ストーリーを書くこと
仕様をレビューすること

に加えて、

受け入れ条件をきちんと「テストシナリオ」として設計すること
そのナレッジ（要注意パターン）を README や因子水準表として蓄積すること

がかなり効く、というのが実感です。
エンジニア側から見れば、「何をどの前提で満たせばよいか」が明確になり、マネージャーにとっても品質リスクの見通しが立てやすくなります。

3. ベロシティ低下を「失敗」ではなく「設計されたコスト」として扱う

ユーザーストーリー単位に切り替えた結果として、

リードタイムは伸びました
ベロシティは下がりました

数字だけ見ると「悪化」に見えるのですが、振り返りの中で見えてきたのは、

メンバーのユーザーストーリー理解度は確実に上がった
PdM とエンジニアのあいだの認識合わせの MTG が増えた
要件・仕様・受け入れ条件の精度は徐々に上がっている

という「学習」と「品質」側のメリットでした。

大事だと感じたのは、

ベロシティの低下を「導入の失敗」と短絡的に捉えないこと
代わりに、
- どの痛みが「適切な学習コスト」か
- どの痛みが「運用のまずさによる無駄コスト」か
  を分解して、後者だけを潰していくこと

です。

今回で言えば、

適切な学習コスト
→ エンジニアが FE/BE を跨いでユーザーストーリーを理解する時間
→ 受け入れ条件を磨き込む PdM 同士のレビュー時間
潰すべき無駄コスト
→ 粒度の大きすぎるストーリーでの詰まり
→ 長引く PR の往復
→ 「誰が統合するのか」が曖昧なまま進む時間

を切り分けて、後者に対して

pt・分割のルール
チェックリスト化された受け入れ条件
GitHub Actions + ラベルによる長期 PR の可視化

といった具体策を当ててきた、という構図です。

明日からチームで試せる 3 つの一歩（特に PdM / エンジニア向け）

最後に、チームとして明日からでも真似しやすい一歩を 3 つだけ挙げます。

「pt が大きいストーリーをどう扱うか」のルールをチームで決める
- 例：pt ≥ 5 かつ 1 スプリントで終わらなさそうなら、FE/BE タスク分割も検討する
受け入れ条件をそのままチェックリストにして、開発者テストでも使う
- PdM が書いた受け入れ条件を、エンジニアがそのままテストに使えるようにする
長引く PR を可視化する仕組みを 1 つ入れる
- GitHub Actions + ラベルでも、Slack 通知でもよいので、「2 日以上動いていない PR」を一目で分かるようにする

ユーザーストーリー単位の開発は、単なる「チケットの書き方の話」ではなく、
プロダクトとチームの学習サイクルを、PdM・エンジニアが一緒にどう設計していくか、という話でもあると感じています。

この記事の内容が、一例として参考になれば幸いです。

▼ 明日12月19日はデザイナーのyosukeさんの担当です！お楽しみに！