要求定義がAIに飲み込まれる日

というか、もう飲み込まれはじめているのではないか。

要件が決まればコードは出てくる時代

もう、10年以上前だが、ある南米の会社が開発した開発ツールの話を聞いた。
そのツールは、その開発ツールが定義する方法で要件を書くと、Javaでも、Cでも、VBでもコードを吐き出すというものだった。

だが、出てくるコードは、、、

SIerのコンサル会社化

以前から、情報システムを開発する会社に対して、コンサルティング要素を求めるユーザー企業はいるなと思っている。

要求定義と要件定義、そして基本設計

当方、要求定義に関する研修を、IT関連企業向けに提供しています。

これは、やはり当方が書籍を書いたこともあり、これで知った方々が問い合せてくださるということがあります。

要件定義、要求定義を内製化する

先日、あるところで、「要求定義、要件定義の基本」的な話をさせていただいた。

その際、セミナー受講者から「内製化」について質問があった。

生成AIと要件定義

たぶん、これで今年最後の更新になりそうである。
そして、今年は生成AIがさらに進展してきた一年だったなぁなどとも思ったりする。

私が一応、専門としている要件定義において、生成AIはどんな役割を持つだろうか。

書籍改版の話が出てきた

拙著、「よくわかる要求定義の基本と仕組み」という本、2010年3月に第二版を発売して、もう12年経つ。

アジャイルプロセスの要求定義とウォーターフォールのそれ

アジャイルに対する私の認識

アジャイルプロセスでは、週、または2週単位程度で開発期間を区切り、その期間内でできる機能を高速に開発していくというのが一般的かと考えています。
その期間には、要求定義の期間も含まれると認識していますので、かなりの短期間になる認識です。
その期間内に、ユーザーが認識できる、またメリットを少しでも感じられる機能を開発する必要があるわけですから、かなり大変だろうと考えています。

たとえば、

システム開発会社をパートナーとみなさない発注者には気をつけよう

以前から、こうした事件は起こっているわけだが、野村證券とIBMの訴訟合戦は最高裁まで行くことになったらしい。

よくある現状踏襲

日経コンピュータの「フォーカス」というコーナーで読んだ、野村證券とIBMの訴訟合戦。
記事を拝見する限り、いわゆる「現状踏襲」に固執するあまり、要求追加と仕様変更が多発して制御不能になるパターン。
システム導入の際、現状踏襲するべき部分というのは確かにゼロではない。
ただ、それに固執するあまり、システム導入による業務改善がなされないというのは良くある話である。

要求定義工程で結ばれる「準委任契約」の変更点

要求定義工程では、通常、「準委任契約」が結ばれます。これまでの民法では「完成責任がない」履行割合型という形態でした。きちんと時間を使って働いたことが証明できれば、請求できるという契約です。

つまり、要求定義工程は「未完成のまま」終わることもできたということです。実際、要求定義という工程は「無」から「有」を作り出す部分がありますので、一体どのくらいの時間がかかるのか、完成とはなにかというのがわかりにくい工程でもあるため、準委任契約が適切とも言えます。

が、2020年4月に施行される民法改正でこの準委任契約に変更があります。