SIerはアジャイルやローコードが嫌い？導入が進まない背景とは？

一部の組織や人々の間では、アジャイル開発に対する抵抗感や不信感があるようです。SIer（システムインテグレーター）の中にも、ローコードプラットフォームに対する誤解やアレルギーを持っている人がいるとも見聞きします。今回は、SIerが積極的にローコードを活用しない理由を紐解いてみましょう。

まだまだ根強い、アジャイルに対する誤解

一部のSIerが抱いているローコードツールへの抵抗感は、未だにあるアジャイルに対するさまざまな誤解と無関係ではないでしょう。構造化されておらず混沌としているとか、適切な文書がないといったありがちなミスリードは、以前の記事でもまとめたので、ぜひ合わせてお読みください。

[nlink url=/2023/07/04/8misunderstandings-of-agile/]

アジャイル開発に対して誤解を抱いていれば、エンジニアがより速く、より少ないハンドコーディングで価値を提供できるローコードのメリットを見誤ります。柔軟性があり、ドラッグ&ドロップのビジュアルUIを備えているローコードツールも、SIerのコントロールが制限されていると認識されることがあります。エンタープライズ向けの非常に大規模で複雑なプロジェクトでは、パフォーマンスやスケーラビリティーの面で懸念を持つ人もいます。特定のベンダーに依存してしまうベンダーロックインや、非エンジニアを含む人材のスキルと教育、役割の棲み分けなど、懸念点には事欠きません。

卵と鶏のどちらが先か？ですが、アジャイルに対するSIerの誤解や不信感も、ローコード開発プラットフォームが進化し続け、導入が拡がるに連れて、着実に理解が進んでいくことでしょう。

[nlink url=/2023/07/14/low-code-no-code-dev-market-status-and-forecast/]

実は、アジャイルよりウォーターフォール型開発の方がメリットがある！？

ウォーターフォール型は、シンプルで分かりやすく、今も多くのプロジェクトで採用されています。プロジェクトで一番長い期間である設計から実装までの間は、ユーザーとマネージメントの作業負荷が低いのもメリットです。

しかし、その期間が楽だからといって、開発のリスク自体は一切減ることはありません。むしろ、納期が近づくに連れて大きな問題が露見し、エンジニアの作業負荷が一気に増大します。

一方、アジャイル型は、短いサイクルで要件定義と受入テストを細かく繰り返すため、仕様で上下のブレ幅は少ないものの、プロジェクト期間中は常に、ユーザーやマネージメントに一定量の負荷が発生し続けます。ユーザー参加型と言われる理由は、このためです。

しかし、プロジェクトのリスクや問題点を早期発見して、早い段階で解消できるという大きなメリットがあります。

[nlink url=/2023/04/07/manifesto-for-agile-software-dev/]

ソフトウェア開発の管理は「不確実性」への対応が鍵

ソフトウェア開発のリスクの一つが、コストの誤差です。エンジニアリングとマネージメントの観点から、ソフトウェアの開発コストについて、見積り方法や課題を調査した本があります。この中に、以下のような図があります。

「不確実性のコーン」とも言われる横向きの三角錐は、システムの企画段階から要件定義を経て、基本設計、詳細設計、そして実装・テストと、プロジェクトが進むに連れて、コスト見積りのブレが少なくなっていくことを示しています。つまり、不確実な要素をできるだけ早い段階で減らしておくことは、開発スピードだけでなく、コスト面からも大きなアドバンテージとなります。

なぜSIerは積極的にローコードを活用しないのか？

では、なぜSIerはローコード開発プラットフォームを積極的には採用しないのでしょうか？大きく3つの理由で考えてみましょう。

1.システムを作ること自体がビジネスモデルであるから

システム開発の自動化を軸とした、ビジネスモデルの変革が必要

手段と目的が入れ替わってしまっていることは、決して珍しくありません。システムの開発そのものが目的になっているビジネスでは、そこが簡略化されてしまうことは、自社の存在価値の否定につながってしまうため、簡単に認めるわけにはいきません。人月・人日などの工数カウントが重要なビジネスでは、業務が効率化されてしまうことが売上の減少に直結します。

一方、ユーザー企業にとって本当に重要なのは、システムではなく、それを利用して自社の強みをさらに強化したり、新たなマーケットニーズに対応できる柔軟性のはず。B2Bであれ、B2Cであれ、CX（顧客満足度）の向上が、さらに重要になっていくことを認識した企業は、信頼できる外部の組織とのパートナーシップは維持しつつ、自社でシステムを開発できる内製化の比率も徐々に上げていくようにシフトしています。

2.独自の手法と開発ツールに膨大な投資をしてきたから

自社のローコード製品を作るか、他社の製品を使うのか決断が必要

1970年代にイギリスとフランスとが共同開発した、超音速旅客機コンコルドの失敗は、サンクコスト（沈んだコスト）の例として上げられます。限られた乗客数という収益性の低さや、騒音による環境負荷、高額な航空運賃など、複数の要因で中止に追い込まれました。しかし、それまでに費やした巨額なコストもあり、中止が決定されるまでにはさらに時間とコストが費やされました。

自社開発したオリジナルのシステムやツールがビジネスモデルを支えてきた組織にとって、それを捨ててローコード開発プラットフォームへ移行することは、組織の存続を左右する死活問題です。仮に、自社でオリジナルのローコードツールを開発するとしても、複雑化・多様化する一方のシステム状況や、それを実現するための人材と人件費、さらに進化する先行のプラットフォーマーとの競合など、問題は山積しています。

ローコード開発プラットフォームへの移行は、SIerやエンジニアレベルの話ではなく、経営トップが判断すべき重要課題です（多くの場合、自社ツールを開発した人物と、それからの脱却を決断する人物との社内政治という、別の問題も孕みます）。

3.自動化ツールに対する懐疑的な意見が多いから

自動化ツールを認めた場合の、技術者集団の価値向上が必要

効率的で強力なローコードツールの価値を評価してしまうことは、組織だけでなく、既存のエンジニアの存在価値も問われることを意味します。例えば、ウォーターフォール開発しか経験したことがない中堅のエンジニアを再教育するコストと、最初からアジャイル開発でローコードツールの教育を受けた新人エンジニアとが、同じアウトプットで評価されることは十分あり得ます。

新しいテクノロジーに対して、クリティカルシンキングで慎重に判断することと、技術面のアドバンテージを正しく評価することは共存可能です。

ローコードツールは、確かに、開発経験が浅いエンジニアの底上げや裾野を広げることにつながります。その一方で、スキルがあるエンジニアが使えばより開発効率をアップでき、従来はできなかった新しい技術的チャレンジを可能にしたり、その人でなければならない部分を強化できます。これは、エンジニアとしてのキャリアパスにとっても大きなメリットとなります。

本当に欲しいモノは、見たり触れるまで理解できない

20世紀に活躍した、クルーズ船の設計者であるジョン・マクニースの言葉に、次の文章があります（注意：フォードモーター社創立者のヘンリー・フォード自身の言葉だとする記録はなし）。

人々が何を求めているのかを、聞き込み調査によって突き止めようとすることには問題がある。つまり、もしヘンリー・フォードが自動車を作るべきか否かを人々に尋ねたら、彼らは『本当欲しいのはもっと速い馬だ』と言っただろう。

My Customers Would Have Asked For a Faster Horse – Quote Investigator®
https://quoteinvestigator.com/2011/07/28/ford-faster-horse/#note-2539-2

この記事のタイトルを「SIerは…」と大きな主語にしてしまいましたが、好き嫌いという個人の肌感覚や直感も確かに重要です。そもそも、アジャイル開発やローコード開発が常に最適解ではなく、プロジェクトや組織によって、合う・合わないはあります。アジャイルは、ウォーターフォールの発展でもありません。

革新的な開発スタイルや、ローコード開発プラットフォームのメリット、そしてそれらが自社のチームにフィットするかどうかは、組織やプロジェクト次第です。場合によっては、一度、そのアドバンテージを知ってしまうと、元の非効率なやり方へは戻れないかもしれません。 ただ、未知の世界への畏れを好き嫌いで片付けてしまうのは、とてももったいないことです。自分が信頼するメンターや注目する組織、コミュニティーを通じて、常に情報を収集したり、トライアルやサンプル、セミナーなどで実際に体感し、正しく理解しておくことは不可欠です。これは、自分自身とチームの可能性を広げることにつながるでしょう。

リプリパ編集部

編集部員

XFacebookInstagram

リープリーパー（略称：リプリパ）編集部です。新しいミライへと飛躍する人たちのためのメディアを作るために、活動しています。ご意見・ご感想など、お気軽にお寄せください。
リプリパ編集部の記事一覧