QCDの死角

失敗の正体

システムの失敗は見えないことがある。ブラックボックスであるがゆえに隠せてしまうからである。失敗かどうかの線引きができないところがシステム構築プロジェクトの難しいところである。

エンジニアの真実

もしかしたら、エンジニアが都合の悪いことは隠していることがあるかもしれない。しかし、決めつけてしまうとエンジニアはへそを曲げてしまう可能性がある。隠しているつもりはなくても隠れていることもある。

成功の境界

失敗の線引きは、納期が遅れることであろうか。バグが多いということであろうか。実は、状況によって一概に言えないのである。QCDという言葉があるが、品質と費用と納期のバランスを上手にとったとしても成功か失敗か、すぐにはわからないのがシステムという無形物である。

コスパの本質

コスパという言葉があるが、かけるコストに対して、どれだけのパフォーマンスが出せるかが問題となる。システム開発では、コストからやりたいことを計算するのではなく、やりたいことを明確にしたうえで、コスト内でリッチ度合いを調節することが重要である。

まとめ

システム開発においては、失敗が見えにくいため、失敗しないように見えるのかもしれない。失敗しないことは、成功であるということでもない。時間が経つにつれて失敗を感じることもあり得るのである。

関連記事

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

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


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

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

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

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

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

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

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

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

続きを見る >

開発の相場

相場の不在

フルスクラッチでのシステム開発に相場はない。相場とは商品が一般的に流通している商品など数が多い場合は、競争原理も働き、金額がある一定の範囲に収まってくるものである。

建築との差異

たとえば、一戸建て建築であれば、建物の規模と資材、それに加えて職人の人工で金額が決まる。フルスクラッチのシステム開発は、つまり極めて特殊な特注品を作るようなものであるため、システム開発に相場という概念が基本的にはないのである。

人件費の実態

システム(ソフトウェア)は一戸建てのように、基本的には材料費はかからない。システム開発の費用のほとんどは人件費である。大工職人の人工と同じように人月単価と呼ばれるSE1人が1ヶ月働く金額で相場を知ることができるのである。

工期の変動

建物を建てることと比べるとシステムやソフトウェアは無形の物となるため、1ヶ月の労働力を推し量ることは困難である。個人のプログラミングの早さによって、納期が早くなったり遅くなったりするのである。

まとめ

SEは過去のプロジェクト参画実績から、同じようなプロジェクトに何度も参画していれば手練れでスキルが高いと評価される。システムに関わる人材の評価が困難な点は、プロジェクトに参画する経験値と、本当の意味でのスキルが比例するわけではないことである。本当の意味でのスキルとはプロジェクトを成功させられるかどうかを指すのである。

続きを見る >

DXが頓挫する企業の共通点

最初だけ盛り上がるDX

「うちもDXを進めよう」——経営層の一声でプロジェクトが立ち上がり、社内には期待感が広がる。新しいツールの選定やキックオフミーティングで現場も盛り上がり、変革の予感に胸が躍る。ところが半年も経たないうちに、プロジェクトは静かに失速する。担当者は日常業務に追われ、誰も進捗を確認しなくなる。この「最初だけ盛り上がって止まる」パターンは、中小企業のDX推進で最もよく見られる失敗例である。

中途半端になる本当の原因

DXが中途半端で終わる会社には、共通する構造的な問題がある。まず、推進の旗振り役が明確でないこと。経営層は「やれ」と言うだけで、現場に丸投げしてしまうケースが非常に多い。次に、成果指標が曖昧なまま走り出していること。「業務を効率化する」という漠然とした目標では、何をもって成功とするのか誰にもわからない。さらに、既存業務との優先順位が整理されていないため、忙しくなると真っ先にDXの取り組みが後回しにされる。つまり、ツールや技術の問題ではなく、体制と仕組みの欠如が根本原因なのである。

継続できる会社の共通点

一方で、DXを継続的に推進できている会社には明確な共通点がある。第一に、専任または兼任の推進リーダーを置き、経営層が定期的に進捗を確認する場を設けていること。月次のレビュー会議があるだけで、プロジェクトの優先度は格段に上がる。第二に、最初から大きな変革を狙わず、小さな成功体験を積み重ねる設計になっていること。たとえば、紙の申請書を一つデジタル化するだけでも、現場は「変わった」という実感を得られる。第三に、社員への教育と巻き込みを初期段階から計画に組み込んでいること。DXは一部の担当者だけで進めるものではなく、現場全体が「自分ごと」として関われる状態をつくることが、継続の最大の鍵となる。

脱却への三つの鍵

DXが中途半端で終わる状態から脱却するには、まず「なぜやるのか」を経営層自身の言葉で社内に伝えることが出発点である。ビジョンなき変革に人はついてこない。次に、三ヶ月単位の短期目標を設定し、達成・未達を可視化する仕組みを導入すべきである。ゴールが遠すぎると人は走り続けられないが、短いスパンで成果を確認できれば、モチベーションは維持される。そして最も重要なのは、外部の専門家を適切に活用することである。社内リソースだけで推進しようとすると、知見不足や属人化で必ず壁にぶつかる。伴走してくれるパートナーの存在が、DXの継続と成功を大きく左右するのである。

まとめ

DXが中途半端で終わる最大の原因は、技術力の不足ではなく、推進体制と継続の仕組みが整っていないことにある。専任リーダーの設置、短期目標による進捗の可視化、そして現場全体の巻き込み——この三つを押さえるだけで、止まっていたDXプロジェクトは再び動き出す。「何から手をつければいいかわからない」という場合は、まず自社の現状を客観的に見つめ直すことから始めるべきである。

続きを見る >