アジャイルもローコードも「上流」は必須

 次は、アカン・ローコード開発のほうだ。これはある金融機関のCIOが話してくれた。その金融機関でもローコード開発ツールを利用しているが、今のブームを次のように危惧しているという。「ローコードで何とかできるのは内部設計から単体テストまでの範囲。要件定義などの上流は従来通り、厳密に行わなければならない。それなのにローコード開発を導入すると、なぜか上流をいいかげんにするケースが多い」。

 なるほど、その通りだ。しかも、なんちゃってアジャイル開発と相通じるところがある。両者とも要件定義などの上流工程をないがしろにする。両者の違いといえば、なんちゃってアジャイル開発のほうは「要件がよう分からんからアジャイルでやる」「アジャイルだから要件定義は不要」といった訳の分からない理屈で上流をいいかげんにするのに対して、アカン・ローコード開発では要件定義などの重要性すら意識されていない可能性があることだ。

 読者の中には「いや違うだろ。そもそも『上流』というのはウオーターフォール型開発の発想でしかない」と思う人もいるかもしれないが、それは違うぞ。確かに、デジタルサービスのためのシステムなどを立ち上げる際には、完璧な要件定義は不可能だ。急いでシステムを開発する必要もあるだろうから、とりあえず7割程度の要件を詰めてシステムをつくり、その後で残りの要件を検討するといったやり方を取る場合もあってよい。

 しかしどんな手法を取ろうとも、要件定義などの「上流」の重要性は変わらない。だって、そうだろう。大企業の「PoC(概念実証)ごっこ」ならいざ知らず、ITベンチャー企業が自社の命運をかけたデジタルサービスのシステムを開発する際に、上流での検討をないがしろにすることがあり得るだろうか。いくらアジャイル開発でシステムを構築するといっても、提供するサービスや対象顧客、ビジネスモデルなどを議論し、システムの基本仕様の検討を重ねるはずだ。そうでなければ、投資家に対する背任行為である。

 ローコード開発のほうは、そもそも「要件がよう分からん」は基本的にあり得ない。もちろん、顧客向けのデジタルサービスのためのシステムに適用するなら、その可能性はゼロではないが、社内向けのシステムでそんなことを言っているようでは話にならない。ローコード開発は、プログラミングの工数を減らすことで素早く開発できるようにしたり、あるいはプログラミングスキルの乏しいビジネスサイドの人でも開発できるようにしたりするのが狙いのはず。要件定義などビジネスサイドの知的作業を簡略化するものではない。

 念のために言っておくと、何でもかんでもウオーターフォール型のように開発しないと駄目だと言っているわけじゃないぞ。事前に検討しなければいけないことは、脳みそを燃やし尽くすまで考えなければならないと言っているだけだ。これは澁谷氏が書いている通りであって、その骨の折れる知的作業で手を抜くために、「今はアジャイル開発だよね」「ローコード開発でやればよいではないか」などと騒ぐのは、けしからんと言っているだけだ。

 ただねぇ、なんちゃってアジャイル開発でも、アカン・ローコード開発であってもシステムは出来上がってしまうからな。だから「そんなかたいことを言わなくても」という風潮になりつつあるわけだ。何せ、今やどの企業の経営者もDX(デジタルトランスフォーメーション)の成果を株主や投資家らに示したいから、どんなにくだらないPoCでも、どんなに出来損ないのシステムであっても大歓迎だ。かくして、なんちゃってアジャイル開発やアカン・ローコード開発は日本企業にまん延していく。「あー怖い」と震えるほかない。

次ページ 「デジタルカイゼン」のための開発に堕落