記事

なぜベトナムはERPシステム開発に向いているか

ベトナムは、ERPシステムの開発を行うのに適した場所と言えます。特に、日本企業が自社の生産拠点や流通拠点をベトナムに持っている場合や、ERPシステムが過去に作成したwebベースのものである場合は特に向いています。ここでは、その理由について解説します。


ベトナムの市場理解と製造業との親和性

ERPは業務に直結したシステムであるため、業務理解と市場の理解が欠かせません。ベトナムを生産拠点にしていたり、ベトナム市場に製品を販売している日本企業は多いため、そのような日本企業はベトナムの物流や製造現場に慣れているからです。ベトナムの市場理解と製造業との連携により、ERPシステムの在庫管理など、製造業に特化した機能を効果的に開発することができます。これにより、生産管理や物流効率の向上を実現し、ビジネスの競争力を強化することができるでしょう。

ベトナムにおける既存の知識と日本語通訳者の能力

トナム人の日本語通訳者の能力も向上しており、生産や流通に関わる日本語も習得しています。これにより、ERPシステム開発プロジェクトの効率性が向上し、品質の高い成果物を生み出すことができます。

ベトナム国内には、日本企業の製造や流通、決済に関する知識が蓄積されています。日本企業の進出が主に製造業から始まったため、ベトナムではこれまでに日本独自の慣習や用語についての理解が深まってきました。このような環境下でERPシステムを開発することで、ベトナムとの意思疎通がスムーズに行われ、開発段階での要件の理解に対しての円滑なコミュニケーションが可能です。ベ

ベトナムのオフショア開発の特質と既存システムの改善

ベトナムのソフトウェア業界は、オフショア開発からスタートし、成熟した実装能力を持っています。しかし、そのような経緯のために上流工程については苦手です。要件定義や仕様作成の段階からベトナムに丸投げしてしまうのはあまり良いこととは言えません。その部分は日本側で行い、実装段階をベトナムで行なうのが良いでしょう。

特に20年前からのWebベースのERPシステムのリプレースや改善をする場合は、ベトナムは適切な場所と言えます。過去に作成された既存のシステムは現在の技術やセキュリティ基準に合致していない場合があります。しかし、ベトナムの開発者が現代的な技術を使ってUIやUXの改善に取り組むことで、既存システムの現代化やセキュリティの強化が可能です。 具体的には、DBはそのままにして、古い技術で作られているフロントエンド部分をリプレースすると言ったプロジェクトが良いでしょう。

ベトナムオフショア開発に向く3つのプロジェクトと、向かない3つのプロジェクト 前の記事 なぜベトナムは比較的ライトウェイトなWeb開発に向いているか 次の記事

関連記事

記事

要件定義のアプローチ

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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

続きを見る >
記事

生成AIは使えない？

思い通りにならない理由

生成AIを導入したのに思ったような結果が得られない――そんな経験をしたことがある人も多いだろう。AIは進化を続けているが、それを使いこなす側にも試行錯誤が求められている。特に企業においては、社内情報を整理すればするほど目的の答えに辿り着けなくなる「RAGの沼」にハマることがある。多くの企業が生成AIを武器にしようとしているが、その真価を引き出すには、正しい導入と運用が欠かせない。

RAGとは何か

RAG（Retrieval-Augmented Generation）は、「検索」「拡張」「生成」の頭文字を取った技術であり、生成AIに独自情報を与えることで回答の精度を上げる手法である。インターネット上の情報だけでなく、社内マニュアルや業務データなどを取り込むことで、より業務に即した回答が可能になる。ただし、期待する結果が得られない場合、その原因は提供リソースの質や構造にある可能性が高い。

ChatGPT以外の選択肢

現在、生成AIとして多くの大規模言語モデル（LLM）が存在する。OpenAIのChatGPTをはじめ、AnthropicのClaude、GoogleのGemini、MetaのLLaMA、Mistral、Cohere、さらにAlibabaやBaiduといった中国系ベンダーもある。それぞれに強みがあり、RAGに適したモデルも存在する。たとえばCohereのCommand R+やMistralのMixtralなどが代表的だ。目的に応じてLLMを選び、最適な環境を整えることが重要である。

社内AIを成功させるには

セキュリティ上の理由から、社内情報をインターネットに出せない企業も少なくない。その場合、オンプレミス環境（社内ローカル）に生成AIを構築する選択肢がある。たとえばTinyLLaMAやPhi-2のような軽量モデルから、Nous HermesやMixtralなどの対話・RAG対応モデルまで選択肢は豊富だ。これらを活用すれば、外部にデータを出さずともAIの恩恵を享受できる。必要なのは、自社の目的と環境に適した判断力である。

まとめ

生成AIはあくまで「道具」にすぎない。導入しただけで目的が自動的に達成されるわけではない。課題を定義し、適切な情報を整備し、それを使いこなす力が必要だ。RAGがうまくいかないと感じたら、その原因はリソースや設計のミスマッチにあるかもしれない。

続きを見る >
記事

運用の昇華

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

続きを見る >