はじめに
こんにちは。anyでエンジニアをしている @koukibuu3 です。
この記事はanyプロダクトチームAdventCalendar2025、2日目です。
今年5月に入社してからの半年間で、僕が感じた課題と、その改善に向けて取り組んできたことを書きます。
新しいチームに入った直後は、“わからないこと”だらけでした。プロダクトの理解もそうですが、それ以上に気になったのは タスクの進め方や前提が、人に強く依存していること でした。
「これは何をもって完了なんだろう？」
「なぜこの順番で進めているんだろう？」
「ここって暗黙の決まりがあるのかな？」
こんな疑問を抱えながら開発を進める中で、同時に「ここを整えれば、もっとスムーズに働けるはずだ」とも感じました。そこで、ニュージョイナーとしての観点を活かし、“わかりづらさ”を一つずつ形式知に変えていく 取り組みを進めてきました。
その結果、タスク管理やプランニングの流れが整理され、説明が必要だった作業が “読めば動ける” チームの資産 として積み上がりつつあります。
この記事では、そのプロセスと学びをまとめます。
“わかりづらさ” の正体を分解してみた
まず前提として、any のメンバーはとても雰囲気が良く、エンジニア同士はもちろん、フレンズさん1やビジネスメンバーとも気軽にコミュニケーションが取れる環境です。「これ聞いて大丈夫かな……」と身構えるような場面はなく、疑問を投げれば誰かが丁寧に答えてくれる。そんな健全な空気があります。
また、任されるタスクも各メンバーのスキルに信頼が置かれていて、「この人なら問題なく進めてくれる」という安心感がチーム全体にありました。そのおかげで、各自が自律的に動ける文化が根付いていたように思います。
しかし、その良い空気とは裏腹に、ニュージョイナーの立場から見ると “何がどこで、誰によって、どんな前提で進んでいるのかが見えづらい” という状況がありました。
プロダクトの機能も、各メンバーの専門領域もまだ掴めていない。
そんな状態では、「誰が何を進めているのか」「どのタスクがどう繋がるのか」「自分がどこに入っていいのか」といった全体像がつかみづらく、手を動かす前の理解コストが高くなりがちです。
この “全体の構造が見えない” ことこそが、僕にとっての“わかりづらさ”の核心でした。
Jira移行をきっかけにタスクの“見える化“に取り組んだ
入社して1ヶ月ほど経った頃、タスク管理をNotionからJiraに切り替える話が出てきました。
anyではスクラム開発が進んでいて、高度にカスタマイズされたNotionでタスク管理をしていましたが、自由度が高いぶん「どこを見れば何が分かるのか」を理解するのが難しいと思うこともありました。
ちょうど僕は前の職場でJiraを使っていたこともあって、「だったら、この移行のタイミングでタスク周りを誰でも分かりやすいようにできないかな」とEMに話を持って行きました。
そこでまず、今のタスクの流れを整理しながら、
- 誰がどのタスクを進めているのか
- 今どの状態にあるのか
- そのタスクで行うことは何なのか
- どのくらい大変なタスクなのか
といった “見づらさ” のポイントを洗い出していきました。これらを整理することで、改善したいポイントが明らかになりました。
プランニングでタスクを “並べきる“ ことを目指した
Jiraの形がある程度整ってきたタイミングで、配属されたプロジェクトでも少し試してみることにしました。
プロジェクトの目指す目標に向けて毎スプリントでどのタスクを進めるかを決める必要があります。そこで、プランニングの段階で、スプリント中に着手するタスクをすべて並べきることを目指しました。
並べたタスクには可能な範囲で「何をするのか」も具体的に書いておきます。これにより、チーム全体の認識が揃いやすくなり、スプリント開始後に「次、何をやればいいんだっけ？」と迷う場面がほとんどなくなりました。
これまでは、やるべき作業自体は担当者の頭にはあるものの、タスクとして外に出ていないケースも少なくなかったように思います。そこで、頭の中の作業をタスクとして起票し、プランニングで全員と認識合わせをする流れを取り入れました。
タスクがすべて見える状態になると、スプリント中に余裕が出た人が、自然と別のタスクを手に取れるようになります。「この人の仕事」と縛らず、必要なところを柔軟に分け合えるようになったのは大きな収穫でした。
最初の頃はPdMと別途時間を取ってようやく並べきる状態でしたが、今ではメンバー全員が自然にタスクの起票・整理・分割を行い、追加のMTGなしでスプリントの準備が整うようになっています。
こうした変化は、目標に向けたタスクが整理され、誰から見ても明らかな状態になったことが大きいと感じています。
「見える化」されているだけで、チーム全体が動きやすくなることを実感しました。
ストーリーポイントの導入でメンバーの目線をあわせた
プランニングでタスクを並べきれるようになってきたタイミングで、次に取り組んだのがストーリーポイントの導入でした。
元々、僕自身はポイントを付ける作業が好きで、タスクの重さを事前に把握できる点に価値を感じていました。ただ、チームとしてはポイントを付ける習慣がなかったため、このタイミングで「共通のものさし」を作ることにチャレンジしてみることにしました。
まずはプランニングポーカーを取り入れ、メンバー全員で同じタスクの“重さ”をどう捉えるのかを話し合うところからスタートしました。徐々に、ポイントの付け方に共通の感覚が生まれ、プランニング時には各タスクにポイントが載るようになり、スプリント後には計測にも使える状態になりました。
とはいえ、全くポイント感がない状態からプランニングポーカーを実施するのは難しいと考えたため、事前に暫定のポイント感ガイドラインを作成して共有し、大きな乖離を防ぎました。
▲ any的ストーリーポイントガイドラインの一部抜粋
チームでポイントを付けることにはいくつか明確なメリットがあると感じています。
- タスク内容の理解が自然と深まる
ポイントを付けるには「何をする作業なのか」を全員が把握する必要があるため、スプリント前の解像度が上がる。 - 粒度の適正化が進む
大きすぎるタスク（弊チームでは5ポイント以上）は「分割できるか？」という議論のきっかけになり、結果として扱いやすいサイズへ分解される。 - チームの“キャパシティ”が見えるようになる
ポイントが共通指標になることで、「うちのチームが1スプリントでだいたいどれくらい進められるのか」が把握でき、中期の工数見積もりの根拠として使える。
導入前は「なんとなくこのくらいできそう」で進んでいた部分が、ポイントという共通言語を導入したことで認識が揃いやすくなり、先の見通しも立てやすくなりました。
まとめ
ニュージョイナー目線で感じた “わかりづらさ” の正体を探し、分解してみることで、個人的な “わかりづらさ” の解消に留まらず、よりスクラム開発を進めるためのanyとしての型ができたように感じます。
▲ ポイント付け初めた頃のバーンアップチャート
▲ 直近のスプリントのバーンアップチャート
ポイント導入初期と直近のスプリントを比較すると、見積もりの精度やタスク完遂率が上がってきたことがわかります。計画通り進めることが目標ではありませんが、こうして実際のデータで改善が見えるのは嬉しいです。
そして何より、ニュージョイナーからのこうした提案を「やってみよう！」と快く背中を押して協力してくれるanyメンバーには、感謝の念が絶えません。
この記事で書いたように、anyは新しく入った人の視点も大切にしながら、チームで改善を進めていける環境です。興味を持っていただけた方、ぜひ一緒にプロダクト開発しませんか？
-
anyでは業務委託など正社員以外の雇用形態で関わってくださる方々をanyフレンズさんと呼んでいます。 ↩