要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

問題と課題の違い

下記の記事で、要件定義をするには課題定義力が重要であると述べた。

req-definer.com

問題定義力ではなく、課題定義力である。どのような業種においても、問題があって、その問題を解決していくことが仕事となる。問題を解決していくためには、この言葉を使い分けた方が、仕事をやりやすくなる。今回は、この2つの言葉を紹介する。

問題と課題の違い

f:id:req-definer:20220120200451j:plain

問題と課題の違い

上図は、問題と課題の違いを示した図である。ビジネスにおいて、問題と課題は用語的に区分けがなされている。

  • 問題:あるべき姿と現状に乖離がある状態
  • 課題:問題を解決するために、やらねばならないこと

これらの言葉は、明確に違うものだ。上図を見て欲しい。問題を定義する際にインプットとして使用される用語は、「あるべき姿」と「現状」だ。一方で、課題を定義する際にインプットとして使用される用語は「問題」だ。

問題というのは、「あるべき姿」という状態から「現状」という状態を引き算したものであり、引き算した結果としての状態である。

課題というのは、「問題」という状態を解消するためになすべき事(こと)である。

前者は状態、後者は事(こと)、ということで、まったく違うものなのである。

課題を定義すると、要件を定義できる

課題というのは、なすべき事である。なすべき事の中で、システムで実現可能なものはシステム要件化されるのである。したがって、課題定義の良し悪しが、要件定義書の良し悪しに直結するのである。

さて、この課題を定義するにはどうすればよいのだろうか?図を見ればわかることだが、問題を明確化しないといけない。では、問題を明確化するにはどうすればよいのか?あるべき姿と現状を把握しないといけない。

残念なことに、あるべき姿の確認と現状の把握は、顧客主体でないと突き詰められないことである。だからこそ、顧客が積極的に関与しないと、システム開発は進まないし、終盤になって変更が発生するのである。

くどいようだが、システムの要件は、課題を解消するための手段として定義される。そのため、課題定義が間違っていれば、システムの要件は変更されるのだ。問題の定義が間違っていれば、これまた要件は変更されるのだ。

  1. あるべき姿の確認
  2. 現状の把握
  3. 問題の明確化
  4. 課題の定義

上記のいずれかでも詰めが甘いと、システムの要件は変更される。エンジニアとしてITに関する技術を磨くことはもちろん大事だが、問題解決に関する技術も磨くことで、より良いシステムを作れるエンジニアになれるのではないかと思う。

結論:問題は「状態」であり、課題は「事(こと)」である