要件定義の問題点

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。

関連記事

小規模AI導入ガイド

効果検証から始める

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

UI重視の効果測定

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

開発とAIの分離問題

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

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

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

まとめ

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

続きを見る >

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

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


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

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

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

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

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

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

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

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

続きを見る >

DX失敗企業の共通点

DX推進の落とし穴

デジタルトランスフォーメーション(DX)に取り組む企業が増える一方で、期待した成果を得られずに頓挫するケースが後を絶たない。経済産業省の調査でも、DXに成功したと実感している企業はわずか数パーセントに留まっている。なぜ多くの企業がDXで失敗してしまうのか。本記事では、失敗する会社に共通する特徴を分析し、成功へ導くための視点を紹介する。

失敗企業の共通点

DXが失敗する会社には、いくつかの共通点がある。第一に「目的の不明確さ」である。ツール導入そのものが目的化し、何を解決したいのかが曖昧なまま進めてしまう。第二に「経営層の関与不足」が挙げられる。DXは全社的な変革であり、現場任せでは推進力が生まれない。第三に「現場との乖離」である。実際に業務を担う社員の声を聞かず、使われないシステムが構築されるケースが多発している。これらの問題は単独ではなく、複合的に絡み合って失敗を引き起こす。

成功企業の原則

では、成功している企業は何が違うのか。成功企業に共通するのは「ビジネス課題起点の発想」である。まず解決すべき経営課題を明確にし、その手段としてデジタル技術を選定する。また、経営者自身がDXの旗振り役となり、変革の必要性を全社に浸透させている。さらに重要なのが「スモールスタート」の姿勢である。最初から大規模なシステム刷新を狙うのではなく、小さな成功体験を積み重ねることで社内の理解と協力を得ていく。加えて、外部パートナーを活用して専門知識を補い、客観的な視点で推進状況を評価する仕組みを持っている。

成功は準備次第

DXの成否は、取り組む前の「準備」で大きく左右される。自社の現状を正しく把握し、何のためにDXを行うのかという目的を明文化することが第一歩である。その上で、経営層から現場まで一貫したビジョンを共有し、段階的に進める計画を立てるべきだ。失敗を恐れて動かないことが最大のリスクである。しかし、闇雲に進めても成果は出ない。重要なのは、正しい方向性を持って着実に歩みを進めることである。自社だけで判断が難しい場合は、DX推進の実績を持つ専門家の力を借りることも有効な選択肢となる。

まとめ

DXが失敗する会社には、目的の不明確さ、経営層の関与不足、現場との乖離という共通点がある。成功するためには、ビジネス課題を起点とした発想、経営者主導の推進体制、スモールスタートによる段階的な取り組みが不可欠である。正しい準備と専門家の支援を活用し、着実なDX推進を目指すべきだ。

続きを見る >