タスク消化よりもイシュー特定を重視できるエンジニアになるために

同僚と雑談していて、何気なく問いかけたら想像以上に議論が盛り上がったので記事にしたいと思います。

僕「〇〇さんってアサインされた チケット に対して、Howを求めます？Whyを求めます？」

今思うと、少し的がブレている質問だった気もしますがエンジニアである同僚は、「Whyだろ。」と答えてくれました。

ここでいう、チケット を僕らはイシューと認識して話しております。

ただ、人によっては 「チケット = タスク」と思い込んで話す人もいそうですよね。

本記事では、プロジェクトにおいてエンジニアがどのように振る舞うべきなのかについて書いてみました。

記事のまとめとして、私からみなさんにイシューを起票させていただきますので、一度課題を認識いただければ幸いです。

イシューとタスクの違い、言えますか？

さっそく本題ですが、「イシューとタスクを履き違えている」「イシューとタスクが曖昧になっている」現場、 よくあるんじゃないんでしょうか？

私はもともとIT業界じゃないので、新卒の研修ではイシューをビジネス用語として学びました。
それもあって、IT業界に入って「イシュー ≒ タスク」と捉えている現場が多くあり、若干の違和感を覚えました。

簡単にですが、イシューとタスクについての私の理解を記載させていただきます。

※ この辺りをちゃんと学びたい方は以下の書籍がおすすめです。
「イシューからはじめよ」がおすすめです。

イシュー

• 白黒つけるべき重要な問題・事象
• 解決すべき課題や問題、または議論すべきテーマを明確にしたもの

私は、「イシュー = 問題提起・課題・問題解決をするための種」だと理解しています。

タスク

• イシューを解決するために必要な具体的な作業の単位。

つまり、「イシューがないのにタスクが生まれている」って本来あり得ないことと思っています。

じゃあ、イシューとは、どういう単位で始まるの？ って所ですが、本記事でもすでにイシューになり得る文言が出て来ています。

先程使った文章、「つまり、「イシューがないのにタスクが生まれている」って本来あり得ないことと思っています。」ですが、これ、問題提起ですよね。

「本来あるべき姿」と「現状の姿」を比較しています。

本来あるべき姿: タスクがあるならイシューは存在するべきだ。
現在の姿: イシューがないのにタスクが生まれている

「このイシューチケットのステータス」としては「じゃあこうするべきだ！」という手段や解決策が出てない状態です。

イシューの責務。タスクの責務。

※ ビジネス用語としての意味ではなく少しIT業界(プロジェクト)の使われ方に寄せた、私の理解です。

イシューの責務

• 解決すべき「課題」「不具合」「要求」やを記録・議論する単位
• 解決すべき問題や課題の本質の追求
• 「なにが問題か／なにを達成したいか」を明確にし、関係者の合意形成を行う
• 5W1Hの中でも、特に Why を明確化する
  5-Why 分析 についての記事、以前書いています。

タスクの責務

• イシューを解決するための必要な作業の単位
• 作業ログがある
• 5W1Hの中でも、How を詰めまくる

---

簡単な例だとこんな感じでしょうか？

• イシュー:
  • 納品する Git リポジトリに不要ファイルが含まれないようにしたい
  • ログイン機能に不具合がある
• タスク:
  • .gitignore を整備する
  • セッションの有効期限チェックを修正する

もう少しわかりやすくエンジニアの業務を例に提示すると、こんな感じでしょうか。

• タスクドリブンの場合:
  言われた通り実装する。→ 後で「重すぎて落ちる」「欲しい項目がない」とクレーム → 手戻りコスト発生。
• イシュードリブンの場合:
  「なぜ？」と問う。→ 「DMを送るリストが欲しい」と判明 → 「じゃあSendGrid連携の方が早いし正確ですよね？」 → 実装ゼロ（No Code）で解決、あるいは別機能提案。

では、次のセクションにて、イシューとタスクを履き違えちゃった例、いくつか提示いたしますね。

イシューとタスクを履き違えちゃった...。

今回、記事にするにあたっていろいろ考えてみたんですけど結構深刻かもです。

あるある！を得られそうな順に記載させていただきます。

1. イシューがただの作業メモ化

本来、「問題・改善点・仕様変更の議論場所」であるはずのイシューが、単なるタスクの羅列になってしまいそう、といったシチュエーションです。

解決したい課題はなんだったのか。って事態が待ってそうですよね。

チームで「課題がなにか」認識せずに、方法の議論だけが盛り上がりそう。
↑ 多くの現場で発生してそうですね。

2. 「これは課題なのか、単なる作業なのか」が不明確になる

イシューがタスク化してる現場で多そうなんですけど、目的と手段が曖昧になってそうです。

本来なら、課題に対しての Why を詰める場面であっても、判断つかず How に走り出す人が出ちゃいそう。

エンドユーザーの気持ちはもちろん、レビュワーやQAの気持ちを一回考えて欲しい。

3. ステークホルダーとの信頼性の低下

これが結構怖いなって思ってます。

タスクの数はめちゃくちゃこなしてるけど、実際には「課題解決」ではなく「タスク消化」しかしていないため、進捗指標が信頼できない。(問題の本質を追わずタスクだけ処理すると、リリース後に重大な不具合や仕様齟齬が噴出しそうですね)

この現象、グッドハートの法則と呼ぶらしいです。

4. タスクの粒度崩壊

「.gitignoreを追加する」レベルの作業と、「管理画面全体の改善」とが同じ扱いになると、優先度やスコープの管理ができなくなりますよね。

「管理画面全体の改善」は、現状の問題点がなんなのか、を見つける所がスタートだと思います。

エンジニアとして多職種への関わり方 ~エンジニアはどう振る舞うべきなのか~

理想だけを求めていいのであれば、ビジネスサイドのメンバー(PMやクライアント)と会話をする際、エンジニア視点で求めてることって「How」ではなく「Why」ですよね。

ビジネスサイドサイドで「How」まで定められてしまった場合、制約がより多くなってしまい選択肢が限られてしまいます。
また、本来達成したいことが見えづらくなります。

ただ、ビジネスサイドの役割として手段を提示するのも仕事の1つです。

※ 私の希望としては「Why 8割」「How 2割」を所望しますが...。

---

 

そこで、「エンジニアの役割は？」「エンジニアはどう振る舞えばいいの？」という所を私なりにまとめてみました。

私は「鏡」であるべき、だと考えております。

ビジネスサイドやPMが「タスク（How）」で依頼してくるのは仕方がないです。
解決策を考えることが、彼らの仕事でもありますので。

ただ、「エンジニアはその解決策を鵜呑みにする」ことはNGです。
「本来はこういう課題を解決したいんですよね？」と問い返すような鏡になること、がエンジニアの使命です。

摩擦を恐れて「言われた通り作ります」と言うのは、優しさではなく職務放棄だと私は感じます。

まとめ

いかがでしょうか？ ハッと思い当たるシーン、多いんじゃないんでしょうか。

本記事内で、いくつか問題提起と私の見解を提示させていただきましたが、 私の中ではまだ、「イシューと どう向き合っていけばいいのかという 課題 」に対する答えは出ていません。

最後に皆さんに向けて「イシューとどう向き合っていけばいいのか」というイシューを残して、本記事を締めたいと思います。