タスク管理が激変！dev3チームのワークフロー改善

【㈱フクロウラボ】エンジニアブログ

こんにちは。dev3 チームに所属しているフロントエンドエンジニアの今泉です。
フクロウラボエンジニアブログの読者は開発に携わっている方が多いのかなーと勝手に思っています。
ですが、今回ご紹介するワークフローは開発に携わる職種だけでなく、様々な職種の方にとって良いヒントをもたらせればと思い、出来るだけ専門的な用語を避けて抽象的に書いてみました。

こんな方向け

  • もっと良いワークフローないかな、となんとなく思っている

  • 明確に課題意識はないけど今のやり方が最適なのか分からない

  • 他社どうなのよ

本記事で触れない事

  • おすすめのタスク管理ツール

  • 限定的なルールのすすめ

前置きが長くなりましたが、フクロウラボのdev3 チームがこの約半年間でタスク管理を大きく改善した際の取り組みについて、一部ですがご紹介していこうと思います。
よかったら最後までお付き合いください。

タスク管理ってどーしたらいいのさ

タスク管理ツールを導入し、チケットを作成してガントチャート引いて・・
「以前からその方法を採用していたから」、「それとなく調べて良い感じに管理している」といった開発現場をいくつか経験してきました。
もちろん、会社の方針もあれば、チームの環境によってベストプラクティスは異なってくると思います。
フクロウラボのdev3 チームでは Jira によるタスク管理を行なっており、大まかなルールはあれど基本的には "やりやすいように" 管理しようという、"雰囲気"のもと、個人の裁量でチケットを扱っていました。

この仕様って・・？

タスクを作成する人とそのタスクを対応する人は必ずしもイコールではありません。
書き手によってフォーマットも違えば、伝わらない文章だとやりたいことの背景が分からないといった事も。
書き手と読み手で実現したいことのピントが合わない事態が発生し、仕様について後からヒアリングをしたりと、フローを何度か往復してやっと制作に取り掛かる、というような事もしばしば。

と、書いておいてなんですが、仕様のヒアリングを繰り返し行う事自体はさほど問題とは思っていません。
問題提起したいのは、このやりとりが作業者と依頼者の個人間または限られた狭いスコープで行われていたことで、
チーム内で知見や知識の循環が滞っていた事、作業の分解や引き継ぎが困難になっていた事、時には認識齟齬での手戻りが発生していた事です。

そこで、dev3 チームでは決まった時間にタスクを開発メンバー全員で書き下ろす時間を設けることにしました。
このイベントをバックログリファインメントと呼び、以下のフォーマットを厳守して作成しています。

ユーザーストーリー
◯◯ がしたい。それは、◯◯ だからだ
デモ手順
1. ◯◯ に遷移
2. ◯◯ を押下
3. ◯◯ が表示される

特に、ユーザーストーリーがとても重要で、そのチケットの目的、実現することで誰がどうなるか、といった内容を必ず記載します。
そして、デモ手順は目的実現の定義を記載する項目になり、デモ手順通りにデモをすることでユーザーストーリーが達成される、といった構図になっています。

決められたフォーマットに沿ってタスクを全員で書き下ろすのは分かったけど、仕様決めの話はどこにいったの！
と思われた方、すみません。あえて脱線しましたが、次項で説明します。

（補足）
ここまで読まれてご存知の方もいらっしゃると思いますが、バックログリファインメントというイベントはスクラム開発手法におけるイベントの一つです。
dev3 チームではスクラム開発手法を採用しており、スプリントと呼ばれる開発サイクルの中で、決めた時間通りに各種イベントを設けています。
本記事ではスクラム開発手法がなんなのか、どのように実践するのかの詳細は割愛しますので、ご興味のある方は最後に紹介する著書を読んでみてください。

誰が決めるの？

ソフトウェア開発に限定せずとも、多くのプロダクトの先にはユーザーがいます。
ユーザーの目的を果たすためのツールとしてプロダクトが存在する、という概念をdev3 チームでは大事にしています。
そこで、ユーザーストーリーマッピングという手法をもとに、実際にプロダクトを使用するステークホルダーと開発メンバー全員の参加型で用件定義を行なっています。
詳しくはこちらの記事でまとめていますので、この手法を実際に採用して何が良かったかを簡潔に述べます。

  • ユーザーの目的が明確にわかる

  • ユーザーの要望 ⇄ 開発目線で提案 といったコミュニケーションがとれる

  • 共通認識が生まれ、齟齬が発生しにくい

  • 合意が取れるため手戻りが発生しにくい

順番が前後しましたが、ユーザーストーリーマッピングで洗い出した上記の要件に対して、前項で説明した通りチケットを書き下ろしていきます。

ユーザーに直接関係しないような要件定義は？
実は、バックログリファインメントとは、ユーザーストーリーマッピングでの要件を書き下ろすためだけの時間ではありません。
バックログリファインメントでは大きく以下の３つを行っています。

  1. タスクの目的と実現方法を明記したチケットを作成する（厳密にはその限りでない）

  2. タスクを着手可能な状態にする

  3. どの程度工数がかかるかの予測を立てる

「タスクを着手可能な状態にする」とは、調査や設計などの作業も当然必要になる可能性があるため、バックログリファインメントの時間で「◯◯ の方法を検討する」などのチケットを作成する事もあります。

それっていつ終わるの？

前項で「タスクに対していつ終わるのか予測を立てる」と述べました。
タスクを着手可能な状態に分解した後、一つ一つに相対的な数字（ポイント）を振る作業を全員で行います。
この作業の中でおさえておきたい大事な点が二つあります。

  1. 各々で考えた数を提示する

  2. 出揃った数字が大きく乖離している場合はディスカッションをする

この二点は、メンバー間で作業感や認識齟齬を出来るだけ無くす大事なコミュニケーションとなっています。

ポイントを振ったところでいつ終わるか分かる？
予測はあくまで予測に過ぎません。大事なのは予測をして実際にどうなったかの結果の積み重ねと考えています。
例えば、期間を決めた１サイクルの内に見積もりの n ポイントを消化したとします。
次のサイクルで n ポイントを消化しました。
、、といったように計測を繰り返します。

1 サイクルの合計稼働時間 ÷ 1 サイクルの合計消化ポイント
この方法でポイントあたりの時間が算出できます。
見積もりと計測を繰り返すにつれて精度も上がっていくため、
ゴールまでの合計ポイント数 ÷ 1 ポイント当たりの時間
を計算すると、いつ頃ゴールするのか、根拠に基づいた現実的な見通しがつくようになります。

計測するまで分からないの？と思われるかもしれませんが、なんの根拠もない予測よりも計測に基づいた予測の方が価値がある、という考え方になります。

なぜ区切るのか

前項で「サイクル」という単語が頻出しましたが、そもそもなぜ区切りをつけるのかという点と、どの粒度で区切るか、においてあまりピンとこない方も多いと思います。
dev3 チームでは、ゴールは出来るだけ小さくを意識しています。
例え話を踏まえて解説します。

自社で Twitter のように様々な機能を持つ SNS を制作することになりました。
ゴールの定義はステークホルダーが希望する機能を網羅し、リリースすると仮定します。

長い期間をかけて制作し、ようやく社内レビューでお披露目した際にステークホルダーから、
「なんかイメージと違う」「もっとこうして欲しい」などのフィードバックがあった場合、制作に費やした期間のうちどれ程が無駄になるでしょうか？

更には製作中に仕様追加や変更があった場合、先の見えないゴールに向かって永遠と走っている感覚に陥ります。

ここで注意したいのが、必ずしもゴール = 成果物のリリースと定義しなくてもよいという事です。
※ 実情により様々あるでしょうが、あくまで一つの考え方として捉えて頂けると。

先の例で言うと、まずはユーザー登録ができるところまでをゴールにしよう、といった具合に制作のゴールを細かく分割します。
その中で 1 サイクルの期間を決めて毎回ゴールを目指すのですが、サイクルごとに制作物のレビューの時間を設けます。
このとき、 1 サイクルの期間についてもゴールは出来るだけ小さくという考え方が機能します。
そうすることで、以下のようなメリットがあります。

  • 認識齟齬を早い段階で解消でき、手戻りがあった場合に素早く修正できる

  • 追加要件など差し込みタスクに柔軟に対応できる

実際にdev3 チームでは 1 週間のサイクルで開発を回しています。
その分レビューなどのイベントにかなりの時間を費やしますが、得られる恩恵と比べた場合にどちらが生産的かと言う点を鑑みての判断です。

最後に

今回はフクロウラボのdev3 チームが行っているタスク管理と手法の一部について、概念的な部分も多くありましたが紹介させていただきました。
概念の浸透やスクラムというフレームワークを採用するにあたって、とあるメンバー指導のもと以下の著書の輪読会を１ヶ月かけて行いました。
SCRUM BOOT CAMP
読まれた方は、本記事のほとんどが受け売りという事に気づくでしょう（笑）

本記事では触れていない、チーム内でのロールやスクラムイベントの説明などかなり分かり易く書かれています。
もっと深掘りしたい、全体的にどんなフレームワークか知りたいといった方にお勧めの一冊です。

この記事が気に入ったらサポートをしてみませんか？