書籍改版の話が出てきた
拙著、「よくわかる要求定義の基本と仕組み」という本、2010年3月に第二版を発売して、もう12年経つ。
拙著、「よくわかる要求定義の基本と仕組み」という本、2010年3月に第二版を発売して、もう12年経つ。
アジャイルプロセスでは、週、または2週単位程度で開発期間を区切り、その期間内でできる機能を高速に開発していくというのが一般的かと考えています。
その期間には、要求定義の期間も含まれると認識していますので、かなりの短期間になる認識です。
その期間内に、ユーザーが認識できる、またメリットを少しでも感じられる機能を開発する必要があるわけですから、かなり大変だろうと考えています。
たとえば、
以前から、こうした事件は起こっているわけだが、野村證券とIBMの訴訟合戦は最高裁まで行くことになったらしい。
日経コンピュータの「フォーカス」というコーナーで読んだ、野村證券とIBMの訴訟合戦。
記事を拝見する限り、いわゆる「現状踏襲」に固執するあまり、要求追加と仕様変更が多発して制御不能になるパターン。
システム導入の際、現状踏襲するべき部分というのは確かにゼロではない。
ただ、それに固執するあまり、システム導入による業務改善がなされないというのは良くある話である。
要求定義工程では、通常、「準委任契約」が結ばれます。これまでの民法では「完成責任がない」履行割合型という形態でした。きちんと時間を使って働いたことが証明できれば、請求できるという契約です。
つまり、要求定義工程は「未完成のまま」終わることもできたということです。実際、要求定義という工程は「無」から「有」を作り出す部分がありますので、一体どのくらいの時間がかかるのか、完成とはなにかというのがわかりにくい工程でもあるため、準委任契約が適切とも言えます。
が、2020年4月に施行される民法改正でこの準委任契約に変更があります。
ちょっと半年くらい前の記事なので、半年で大きく変わっている可能性もゼロではないが、それほどは変わっていないだろうと予想する。
日経コンピュータの記事によると、1980年代に17%だった「ユーザーが要件をまとめられない」というのが、2010年代には34%の2倍になっている。また、「ベンダーが要件を理解できない」というのも1990年代には12%だったが、22%に増えている。
深刻なのは、「ユーザーが要件をまとめられない」という方であろう。
ある企業の要求定義の事例を聞いてきた。その企業ではこれまでウォーターフォール型の開発をしてきたとのことだったが、はじめてアジャイル開発を取り入れて進めたらしい。
1ヶ月もしないうちに、モックアップができあがったそうで、ここまでは良かったらしい。レビューしたことで、現場からも意見がたくさん出てきたとのことだった。が、良かったのはここまでだったらしい。
システム開発の要求定義をしていると、予算を超えるような要求の数になってしまい、「これは優先順をつけないとできあがらないな」ということがよく起こります。
ユーザーがその優先順位をつけてくれるといいのですが、つけ方が分からないとか、とにかく全部やってくれと言い張るとかすることもあるので困りものです。後者の場合には、システム開発から手を引いたほうがエンジニア側としては安全な場合が多いのではないでしょうか。
もし、ユーザー側の人間なら、そこはちゃんと優先順位をつけてあげたほうがいいでしょう。これは「譲歩」することではなく、「協力」することです。なので、積極的に優先順位をつけてプロジェクトがうまくいくように進めたいところです。
要求定義研修でよく質問されるのが、
「どの程度の範囲で要求をヒアリングしたり、掘り起こしたりすべきか」
というものです。実際、この質問は「ヒアリングを適当なところで切り上げられないか」という効率面を考えたものです。しかし、要求のヒアリングを効率面だけで判断すると、
要求が漏れることで、追加要求が発生して開発工程の後戻りが起こる
ことになります。ですから、可能なら、要求はたくさんのレベルのところから引き出す必要があります。
慣れないシステムエンジニアが要求定義、要件定義をするときに陥りがちな、ちょっとした罠について、お話したいと思います。それは、「実現方法や実装方法を考えてしまうこと」です。
システムエンジニアはシステムを作ることを主要な業務としているので、顧客の要求を耳にするとどうしても「動やったらできるだろう」という方向に行きがちです。ですが、要求定義、要件定義ではそれよりも大切なことがあります。
新しい要求がどんどん出てきてしまうと、システム開発予算をオーバーしてしまうため、プロジェクトマネージャやSEの方々は要求を抑え込みがちです。それもひとつの妥当な選択であることは議論を待ちませんので、否定するつもりはまったくありません。
ただ、怖いのは開発が進んでいってから出される要求追加と変更です。最初からわかっていた要求を、開発が進んでから出されるのはとても困ります。できれば、そうしたことは避けたいというのも自明ではないかと思います。
最近のコメント