プログラマの要件定義への関わり方の再考

Keywords

  • 組織論

Contents

  • 1. 序文
  • 2. 2つのシステム開発
  • 3. 要件定義はビジネスサイドと一緒に考えるもの
  • 4. エンジニアからの提案
  • 5. コードの疎結合さ

序文

要件定義とどう関わっていますでしょうか?

要件定義といえば、営業やマーケターが実施するものであり、プログラマはそれを聞いてシステム化に専念すれば良いと思っていないでしょうか。

本稿では、正解のない仕様を元に開発をしていくプロジェクトにおいては、仕様は聞くものではなく、考えるものという意識を持つ重要性を提示します。

2つのシステム開発

なぜ、プログラマは要件定義は聞くものと思っているのでしょうか。

まず、システム開発には、既にマニュアルでの業務が成り立っているいて、それをシステム化するタイプのものと、完全新規でシステム開発するタイプの2通りがあります。

前者の例としては、銀行の窓口業務がインターネットバンキングに置き換わったことや店舗での在庫管理のシステム化などがイメージしやすいでしょう。

後者のシステム化はそもそもの業務が事前におこなわれていないタイプのものです。2000年当初のSNS、新ジャンルのゲーム、新規事業などが挙げられると思います。初めての概念であったり、会社にそのような運用ノウハウがない場合などです。

前者のシステム化は既にマニュアルで運用していた実績があり、その業務知識を元に実装すれば問題ありません。

業務知識を正確に理解している人がいるはずで、その人に率先して要件定義を実施してもらえれば問題なく、プログラマの出る幕はありません。要件定義を聞くものと捉えているプログラマが多いのは、この開発プロセスに慣れ親しんでしまったからでしょう。

ただ、一方で、後者のシステム開発は正解は誰もわかりません。一度要件定義をしてもその後、仕様変更が発生する可能性が十分にあります。

要件定義はビジネスサイドと一緒に考えるもの

正解のないシステムに開発においては、文字通り正解がないので、ただビジネスサイドの言うことを鵜呑みにして、システム開発をしても、意味がありません。

このタイプの開発で必要なことは、とりあえず機能をリリースしてみて、ユーザの出方を伺って、そこで初めて生まれる反応を元にさらに、作り込んでいくか、また別の機能を開発するかの判断を都度都度行うことです。この状況は、潜水艦がソナーを発して、そのレスポンスを情報に、深海を進んでいく状況と似ています。

エンジニアからの提案

エンジニアとしても、議論をしていく中で、ビジネスサイドの言う要件の根拠や論拠が欠けている場合は、「当初の想定の利益よりも開発コストのほうが上回りそうなので、一旦簡易的な機能を作ってみて、それでユーザの反応を調べよう」とビジネスサイドに提案することが重要になります。

その結果、反応が良くて利益貢献しそうであれば、開発コストを掛けてシステム開発を実施する、といったステップを踏むと良いです。

コードの疎結合さ

また、このタイプのシステム開発では、仕様が変更するのは当たり前となり、「いかに仕様変更の発生を防ぐか」といった意識から、「いかに仕様変更をしても、大きな影響がなく開発サイクルを回せるか」といったことに意識を向けることが重要となります。

この意識から導き出される方法としては、おそらく下記のものが挙げられます。

  • 自動テストの作成

自動テストがあれば、コードに修正を加えても、バグがあればすぐに発見できるので、安心して開発を続けれられます。

  • 疎結合なコード

あるコンポーネントは自分の責務だけを全うし、それ以外の責務は知らない状況、つまり、お互いが疎結合な状況であれば、コードの修正は局所的になり、少ない影響での開発となります。