予算ブレの原因

オフショア開発には、受託開発、ラボ開発、そして折衷型の3つの契約形態が存在します。それぞれの契約形態には特徴と課題がありますが、最終的にここで「折衷型」と述べているものに集約していく傾向があります。

受託開発契約とその特徴

受託開発契約は、成果物の納品を約束する契約形態です。この形態では、事前に成果物の定義を明確にし、それに基づいて開発を進めます。受託開発契約はソフトウェア開発においてシンプルな形態と言えますが、成果物の定義を明確にすることは容易ではありません。実際の開発作業では、概念上の定義と現実の制約との間で調整が必要となる場合があります。

ラボ開発契約とその特徴

ラボ開発契約は、クライアントが直接開発者に対して指示を出す契約形態です。クライアントは開発者を拘束し、その時間を購入します。この形態は、日本のSES契約に近いものですが、ラボ開発では開発者は非常駐となります。時間単位で開発者の貢献を購入するため、時間の品質によって成果物の品質が保証されるわけではありません。開発者によって同じ時間内でも成果物の差が生じることがあります。

折衷型契約の意義とその特徴

折衷型契約は受託開発契約とラボ開発契約の折衷案として採用されます。この契約形態では、成果物の定義を柔軟にし、一定の作業時間も確保しながら、基本的にボトムアップ型で開発を進めていきます。オフショア開発においては、ビジネスモデルやクライアントの要求を理解し、中核的な開発人材（例えば、ブリッジエンジニア）を確保することが重要です。中核的な人材はクライアントのビジネスについて深い洞察を持ち、長期的な関係を築くことができます。このような中核人材をラボ契約で時間拘束的に確保し、プロジェクトが大型化したときはスポットで追加の受託契約を行い、人を追加で確保するというものです。

折衷案に収斂していく実際のプロジェクト

受託開発としてスタートしたプロジェクトでも、ラボ開発としてスタートしたプロジェクトでも、ベトナムでのオフショア開発が成功し長く続いている案件は、最終的に折衷案に収斂していく傾向があるようです。多くの場合は海外開発拠点は、日本の開発プロジェクトの外付け工場という位置づけになりますので、クライアントのビジネスをよく知った開発者を確保しつつスケーラビリティを確保するという両方が求められることとなり、このような形に落ち着くのでしょう。

もしこの形をゴールとするのならば、下記の2点に注目するのが良いでしょう。

(a) 長期契約が必要なこと：クライアントのビジネスモデルや独自の用語を理解し、本当に重要な要素を把握するためには時間が必要です。クライアントのビジネスに寄り添いながら開発を行うためには、最低でも1年以上の長期契約が必要です。

(b) ブリッジエンジニアを始めとする中核的人材の確保が大切であること：中核的な開発人材は、クライアントのビジネスをよく理解し、ビジネスの要件に応じて開発を進めることができる人材です。彼らは長期的なパートナーシップを築き、クライアントのビジネス成果に貢献します。そのため、オフショア開発においては、ブリッジエンジニアなどの中核的な人材の確保が極めて重要です。

オフショア開発においては、契約形態の選択とビジネス戦略の統合が成功の鍵となります。ビジネスの長期的な視点と中核的な人材の確保を重視することで、効果的なオフショア開発を実現することができるでしょう。

内製化が注目される背景

「アプリ開発は外注するもの」という考え方が変わりつつある。ローコードツールの普及により、プログラミング経験がなくても自社で業務アプリを開発できる時代になった。しかし、ツールを導入しただけで内製化が成功するわけではない。実際には「ツールは入れたが、誰もアプリを作れない」という状態に陥る企業も少なくないのが現実だ。

内製化が止まる原因

ローコード内製化がうまくいかない原因は、ツールの問題ではなく環境の問題にある。まず、操作方法を学ぶ機会が限られている。公式ドキュメントは英語中心で、実務に即した日本語の教材が少ないのが現状だ。次に、学んだ知識を実践に移す場がない。研修を受けても、日常業務に戻ると時間が取れず、スキルが定着しないまま終わってしまう。さらに、推進担当者が社内で孤立しがちだ。周囲に相談できる人がおらず、一人で試行錯誤を続けるうちに疲弊してしまうケースが多く見られる。

一気通貫が必要な理由

内製化を成功させるには、「セミナー・サポート・教材」の3つを一気通貫で揃えることが必要だ。セミナーで基礎知識を学び、教材で実践的なスキルを身につけ、サポートで困ったときにすぐ相談できる体制を整える。この3つが揃って初めて、現場の担当者が自信を持ってアプリを作れるようになる。どれか1つだけでは不十分だ。セミナーだけ受けても実践で使えず、教材だけあっても疑問が解消されず、サポートだけあっても基礎がなければ質問すらできない。内製化は「点」ではなく「線」で取り組む必要がある。個人の頑張りに頼るのではなく、組織として学びと実践の仕組みを整えることが成功の鍵になる。

成功企業の取り組み方

内製化に成功している企業は、最初から完璧を目指していない。まず1つの業務でアプリを作り、小さな成功体験を通じてノウハウを蓄積している。そして段階的に対象業務を広げ、社内に開発できる人を増やしていくアプローチを取っている。大切なのは、最初の一歩を正しい方向で踏み出すことだ。独学で遠回りするよりも、経験のある専門家に相談することで、最短ルートで成果にたどり着ける。「まず何から始めればいいか」を一緒に考えてくれるパートナーがいることが、内製化成功の最大のポイントだ。

まとめ

ローコード内製化の成功には、セミナー・教材・サポートの一気通貫が欠かせない。ツール導入だけで終わらせず、組織として学びと実践の仕組みを整えることが重要だ。まずは専門家に相談し、最初の一歩を正しい方向で踏み出そう。

効果検証から始める

多くの人は、試しにAIを導入してみて、効果を見てから予算取りを行っていきたいと考えている。とりあえずツールを導入したいといった理由では、なかなか費用を使っていいとはならないだろう。このような慎重なアプローチは非常に理にかなっており、実際の効果を数値で示すことができれば、その後の本格的な導入に向けた予算確保もスムーズに進むはずだ。まずは小さく始めて、確実な成果を積み重ねることが重要になってくる。

UI重視の効果測定

AIの効果を確認してから検討することを考えたときに最初にやることは、実はUI（ユーザーインターフェース）の部分である。例えば、グラフの表示などだ。結果として何ができれば、どういった業務がどれくらい短縮されるのかを第三者が見ても確認しやすいからだ。データの可視化により、AI導入前後の変化を明確に示すことができれば、関係者全員が効果を実感できる。特に経営陣への報告時には、視覚的に分かりやすい資料があることで、プロジェクトの価値を効果的に伝えることが可能になる。

開発とAIの分離問題

UIを作るとなると、結局はシステムの開発が必要になってしまうのではないかという懸念が生まれる。あるいは、システム開発を行うことで、そもそも期待したAIの活用がなされなくなってしまったりすることもあるだろう。これは、目的をシステム開発とAIとに分けているからだ。本来であればAI活用による業務改善が目標であったにも関わらず、システム開発が主目的となってしまい、AI機能が後回しになってしまうケースも少なくない。このような本末転倒を避けるためには、プロジェクトの優先順位を明確にすることが不可欠だ。

統合的アプローチの重要性

AIはAIの会社に発注する、UIはシステム開発会社に発注するといった、区分けをしてしまうことに誤りがある。まず、やるべきことを分解するのではなく、ITに対する知見のある人に区分けから入ってもらい、技術的な判断も行いつつKPIを作っていくことが重要になる。これは市民開発と呼ばれるものに近く、自社内でローコードを使って軽く開発することを意味する。技術的な専門知識を持つ人材が全体を俯瞰し、最適な技術選択とプロジェクト設計を行うことで、効率的かつ効果的なAI導入が実現できるのだ。

まとめ

部署やグループを横断した視点を持つことがとても大切であることがわかった。ツールや部分的な技術を目的としてしまう前に適した組織体であることの確認が大切だ。AI導入を成功させるためには、技術面だけでなく組織運営の観点からも準備を整える必要がある。