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

Naoki Machida

Keywords

Contents

序文

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

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

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

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

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

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

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

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

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

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

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

ビジネスサイドに対して、頻繁に「〜の方法で良いですか？」や「こういう方法で実装しようと思いますが良いですか？」というような質問をしてたら、まだ受託開発の意識が抜けていません。

方法に着目するのではなく、「目的を考慮すると〜の方法の方が良いですがどうでしょうか。」とより良い方法を提案するくらいの意識が必要です。

このタイプの開発で必要なことは、とりあえず機能をリリースしてみて、ユーザの出方を伺って、そこで初めて生まれる反応を元にさらに、作り込んでいくか、また別の機能を開発するかの判断を都度都度行うことです。

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

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

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

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

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

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

正解のないシステムに開発においては時間が経つにつれて、目指しているゴールが変わることがあります。そのため、技術選択する際に、一時点のゴールに特化した技術を採用して、最適化することはリスクが高まるだけです。

「現時点での仕様では、この技術が適している」というような発言をしたことがある人は多いと思いますが、今後保守していくエンジニアにとってはただの迷惑です。

できるだけ、色々なユースケースに対応している技術を選択すべきです。