４月１３日　要件定義のジレンマに悩む

４月１３日ですね。

福島から米沢へ。

午後からずっと四時間半ほど要件定義の打ち合わせでした。

今回は弊社にとってもIoTが絡む初めての試みです。そのため、ソフトウエア開発で培ったやり方では間違いがあるかもしれません。

今回は、要件定義そのものは私が担わず、今回一緒にやってくださっているパートナーさんにお任せしました。

私のいつものやり方よりも、少しペースはゆっくりです。が、その分じっくりと地固めをしながらの要件定義ができたのではないかと思っています。

今までは、kintoneの良さを生かし、その場でレイアウトの変更を行い、JavaScriptを即座に変更できる利点を使って対応していました。

ですが、ご存知の通り、今の弊社はもうそれどころではない案件の数になってきています。

しかも私一人ではなく、多くのメンバーが実装を行う体制になっています。つまり、要件定義の後に仕様変更が生じてもすぐに対応するということができにくくなっています。

それもあって、要件定義のやり方そのものも見直さないとならないとは思っていました。

ただ、本当に要件定義を有効なフェーズとするには、要件定義に納品物を設け、契約で縛るしか抜本的な解決はないだろうなと思っています。

そこまでやってはじめて、納品物としての要件定義が実装までの品質を担保すると思っています。

要件定義の範囲から外れたものは全て機能変更の対象とし、追加案件とする。そうすればお互いが要件定義に本腰を入れるからです。

結局、システム構築の品質が悪化し、納期が遅れる原因は、要件定義で漏れた要件が後から後から出てくることで生じます。

ただ、仕様変更を防ぐために要件定義フェーズを設けるしかないとすれば、それはそもそも開発手法そのものがウォーターフォールになっていることが考えられます。

ウォーターフォールに対するアジャイルとは、個別に機能ごとに実装し、それぞれのサイクルを素早く回すことにあります。

要件定義をきっちりやるには、フェーズを分けて納品物を設ける。

が、それはウォーターフォール型のやり方に回帰すること。

そのことに、私の中でもジレンマを感じています。

人工知能を使った手法も含め、これが正解と言うやり方を探していますが、なかなか正解は見つかりません。

私としては、対応力や小回りの利く会社にしたいと思っているので、何か仕様変更が起きてもすぐその場で変えることのできるプラグイン、内部サンプル、そもそもの技術力を増強していく事が理想です。

まずは今回の案件を通して、私の中でもう一度要件定義のやり方を考え直そうと思っています。