1. はじめに。
同僚に何気なく質問したら想像以上に議論が盛り上がったので記事にしたいと思います。
僕「〇〇さんってアサインされた チケット に対して、Whatを求めます？Goalを求めます？」
今思うと、少し的がブレている質問だった気もしますがエンジニアである同僚は、「Goalだろ。」と答えてくれました。
ここでいう、チケット を僕らはイシューと認識して話していました。
ただ、人によっては 「チケット = タスク」と思い込んで話す人もいそう。
本記事では、イシューとタスクについて考えたことを綴ってみます。
記事の最後に私からイシューを起票させていただきますので、一度課題を認識いただければ幸いです。
※ 本記事は、「方法を提示するような記事」ではありません。「感じた課題を綴った文章」です。
※ 尚、エンジニア目線かつ、主観が強いかもです。
2. イシューとタスクの関係って？
さっそく本題ですが、「イシューとタスクを履き違えている」「イシューとタスクが曖昧になっている」現場、よくあるんじゃないんでしょうか？
私はもともとIT業界じゃないので、研修ではイシューをビジネス用語として学んだんですが、
IT業界に入って「イシュー ≒ タスク」と捉えている現場が多くあり、若干の違和感を覚えました。
簡単にですが、イシューとタスクについての私の理解を記載させていただきます。
※ この辺りは、「イシューからはじめよ」がおすすめです。
イシュー
- 白黒つけるべき重要な問題・事象
- 解決すべき課題や問題、または議論すべきテーマを明確にしたもの
私は、「問題提起・課題・問題解決をするための種」と理解しています。
タスク
- イシューを解決するために必要な具体的な作業の単位。
つまり、「イシューがないのにタスクが生まれている」って本来あり得ないことと思っています。
じゃあ、イシューとは、どういう単位で始まるの？
って所ですが、本記事でもすでにイシューになり得る文言が出て来ています。
つまり、「イシューがないのにタスクが生まれている」って本来あり得ないことと思っています。
これ、問題提起ですよね。
「本来あるべき姿」と「現状の姿」を比較しています。
「このイシューチケットのステータス」は「じゃあこうするべきだ！」という解決策が出てない状態です。
このあたりの記事が参考になりました。
3. イシューの責務。 タスクの責務。
※ ビジネス用語、ではなく少しIT業界(プロジェクト)の使われ方に寄せた、私の理解です。
イシューの責務
- 解決すべき「課題」「不具合」「要求」やを記録・議論する単位
- 解決すべき問題や課題の本質の追求
- 「なにが問題か／なにを達成したいか」を明確にし、関係者の合意形成を行う
- 5W1Hの中でも、特に Why を明確化する
5-Why 分析 についての記事、以前書いています
タスクの責務
- イシューを解決するための必要な作業の単位
- 作業ログがある
- 5W1Hの中でも、How を詰めまくる
簡単な例だとこんな感じでしょうか？
-
イシュー:
- 納品する Git リポジトリに不要ファイルが含まれないようにしたい
- ログイン機能に不具合がある
-
タスク:
- .gitignore を整備する
- セッションの有効期限チェックを修正する
ここまで堅苦しい説明ばかりでしたので、
最後に「イシュー」と「タスク」を履き違えたらどうなるリスクがあるのか、を妄想してみました。
お付き合いお願いします。
4. イシューとタスクを履き違えちゃった...。
今回、記事にするにあたっていろいろ考えてみたんですけど結構深刻かもです。
あるある！を得られそうな順に記載させていただきます。
4-1. イシューがただの作業メモ化
本来、「問題・改善点・仕様変更の議論場所」であるはずのイシューが、単なるタスクの羅列になってしまいそう。
解決したい課題はなんだったのか。って事態が待ってそうですよね。
チームで「課題」を認識せずに、方法の議論だけが盛り上がりそう。
↑ めちゃくちゃ多そうだな笑。
4-2. 「これは課題なのか、単なる作業なのか」が不明確になる
イシューがタスク化してる現場で多そうなんですけど、目的と手段が曖昧になってそうです。
本来なら、課題に対しての Why を詰める場面であっても、判断つかず How に走り出す人が出ちゃいそう。
エンドユーザーにもですが、レビュワーやQAの気持ちを一回考えて欲しい。
4-3. ステークホルダーとの信頼性の低下
これが結構怖いなって思ってます。
タスクの数はめちゃくちゃこなしてるけど、
実際には「課題解決」ではなく「タスク消化」しかしていないため、進捗指標が信頼できない。
(問題の本質を追わずタスクだけ処理すると、リリース後に重大な不具合や仕様齟齬が噴出しそうですね)
4-4. タスクの粒度崩壊
「gitignoreを追加する」レベルの作業と、「管理画面全体の改善」とが同じ扱いになると、優先度やスコープの管理ができなくなりますよね。
「管理画面全体の改善」は、現状の問題点がなんなのか、を見つける所がスタートだと思います。
5. まとめ
どうでしょうか。ハッと思い当たるシーン、多いんじゃないんでしょうか。
本記事内で、いくつか問題提起をさせていただきましたが、
私の中でイシューと どう向き合っていけばいいのかという 課題 に対する答えは出ていません。
ですので、今回は、「問題提起」のみ (イシューの起票のみ) でとどめておこうと思います。