ローコード開発≠安い

誤解されるコスト削減

実はローコード・ノーコードツールを使えば、開発が必要なくなるので安くなるというのは正しくない。たしかに、ノーコードツールを社内メンバーでCMSを使ってソフトを作るという場面は開発費用はかからない。

CMSとはコンテンツ・マネジメント・システムの略で、たとえばWebサイトのコンテンツを構成するテキストや画像、デザインなどを非エンジニアがプログラミングをせずに作成や管理できる仕組みのことである。ローコードツールはそれに加えて少しのプログラミング知識でシステムやツールを作成できることである。

開発手法の選択基準

断じてローコード開発だからといって安いわけではない。開発手法の特性による得手不得手を上手に使い分けるからトータルとして価格が安くなるということである。非エンジニア営業の金額調整という意味での判断でローコード開発を選択する場合は失敗することがある。

システム導入の本質理解

ローコード開発でも、システム導入の目的や条件が本質的にわかっていなければ、仕様要件のブレによって結果としてトータルが安くなることはない。これはローコード開発ということが問題なのではなく、フルスクラッチ開発であっても、SaaSと利用する場合であっても同じことが言える。

負債の危険

本来ローコード開発が適さない場合にも関わらず無理やりに合わせることで、プログラム部分の複雑性が増し、技術的負債となって大きな問題になっていく。結果として安くはならず、ローコード開発のメリットであるメンテナンス性までも損なうため、トータルで考えると高くなる。

まとめ

お客様の予算内で考えないといけないので、といった口癖があれば注意が必要である。クライアントの言いなり状態であれば、無理な要求は開発における仕様だけではないだろう。金額を含めた総合的な判断ができる人が、結果としてローコード開発を選択するわけである。

関連記事

要件定義のアプローチ

要件定義の基本

すべてをシステムで解決してしまおうとする要件定義には注意が必要である。システムの成功の可否は要件定義にかかっていると言っても過言ではない。しかし、十分に要件定義の時間を使ったにも関わらず、ITプロジェクトが失敗することがある。

規模別の要件定義

システム構築の規模によって、要件定義の粒度が変わる。小さなITプロジェクトの場合は要件定義をせずにプロトタイプを作りながらシステム構築を進めるといった方法がある。これをアジャイル開発、プロトタイプ開発と呼ぶ。

要件定義の本質

要件定義の粒度は時間を掛ければ細かくなるわけではない。ユーザー側でも要件定義を進めるにつれて、想定している機能の矛盾点が出てくることがある。この矛盾点を解消していくこと自体を要件定義としてはならない。要件定義はあくまで本質的なコアとなる部分から膨らませることが重要である。

対話型要件定義

要件定義フェーズで失敗するパターンは、ユーザー側との対話ではなく、システム会社側がヒアリングに徹する場合である。ユーザー側はITを利用してどのようなことができるかを知らない可能性が高いため、システム専門家がそれを鵜呑みにした仕様で要件を固めてしまうと、製造工程で無駄な工数が発生し予算をオーバーしてしまうことがある。

まとめ

本質的な要件をコミュニケーションによって、はっきりさせていく作業こそが要件定義と言えるのである。さまざまな視点から何度も繰り返し要件をなぞることで粒度が落ちていき、適切な要件定義書となる。何でもかんでもシステム化せず、オペレーションとの関係性を見合わせながら進めることが望ましい。

続きを見る >

システム開発の混迷

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

続きを見る >

AIの教師モデル開発や画像のタグ付けを目的としたBPO的なプロジェクトにはベトナムオフショアが向いている理由

AI教師モデルにおけるBPOの重要性

AI技術の急速な進化により、教師モデルの構築が重要視されています。テキスト型のAIだけでなく、画像認識などの領域でも教師モデルの役割は増大しています。これらのモデルの開発には人手によるタグ付けや手作業が不可欠です。こうした教師モデルのプロジェクトをBPO(ビジネス・プロセス・アウトソーシング)としてオフショアに委託することで、労働力の確保とコスト効率の向上を図ることが可能です。

ベトナムのBPOにおけるアドバンテージ

ベトナムはBPOプロジェクトにおいて、他の国に比べてアドバンテージを持っています。BPOの重要な要素は末端のワーカーがコンピューターベースのルールに基づいた作業を行うことです。ベトナムは安価な人件費を提供し、労働力の習熟度が高いため、大量生産に適しています。また、日本との文化的類似性や日本語の理解により、コミュニケーションがスムーズに行われます。これらの要素により、ベトナムはBPOにおける優れた選択肢となっています。

ベトナムのBPOのマネジメントと技術力はこなれてきている

BPOプロジェクトにおいては、マネジメントと技術力の確保が重要です。ベトナムはこれらの点においても成熟しています。効率的なプロジェクトマネジメントを行うことで、タグ付けやデータ整理などの作業が円滑に進行します。また、BPOにおいて必要なコンピューター作業に対するリテラシーも高く、新しい技術分野にも積極的に対応しています。ベトナムの成長に伴い、BPOの品質と効率は更なる向上が期待されます。

BPOにおけるコミュニケーターの重要性

BPOのプロジェクトには、ルールやマニュアルを作成する段階でコミュニケーターが重要な役割を果たします。ルールの策定には様々な要素が考慮される必要があり、ベトナム側からのフィードバックも重要です。コミュニケーターは日本とベトナムの文化や言語の違いを理解し、円滑なコミュニケーションを図ることで、プロジェクトの成果物の品質向上に寄与します。

AIでのコスト優位性の確保のための戦略的投資

AI技術の製品化において、BPO部分のコストダウンが重要な課題となります。ベトナムに安定したAIのためのBPO作業をオフショアにすることで、コストセンターの効率化を図ることができます。将来的にAI技術はますます製品化が進み、BPOの需要も増加することが予想されます。そうした中で、ベトナムのアドバンテージを活かした戦略的な投資により、ソフトウェア開発企業のマネージャは競争力を強化し、成功につなげることができるでしょう。

続きを見る >