要件定義の問題点

はじめに

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

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

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

要件定義の丸投げ

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

無理な受注

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

人材紹介会社の利益構造

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

エンジニアの責任範囲

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

発注側の保身

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

関連記事

Figma AIが変えるUI/UX開発

開発現場の変革

2025年、デザインツールFigmaに搭載されたAI機能が業界に衝撃を与えている。Figma Makeは、AIチャットを通してプロンプトを入力すると、UIデザインを自動生成する。従来、画面設計には専門的なスキルと多大な工数が必要だったが、テキスト入力だけでデザインが生成される時代が到来した。この変化は単なる効率化ではなく、開発プロセスそのものの再定義を意味している。

主要機能

Figma AIは、機械学習を活用したデザインアシスタント機能である。画像生成、背景削除、解像度向上に加え、モックアップへのリアルなテキスト追加やトーン調整が可能だ。さらに注目すべきは「Figma Make」の登場である。Figma Makeは、Figma社が提供するAIデザイン生成ツールだ。テキストで指示を入力すると、UIデザインや画面構成、コンポーネントなどを自動生成する。デザインシステムの公開ライブラリをデザインに反映でき、生成したデザインデータをFigmaのフレームに還元できる点が大きな強みとなっている。

具体的メリット

Figma AI導入による最大のメリットは、開発スピードの劇的な向上である。UIを作るのに通常半日かかる作業も、0フェーズのプロジェクトであれば1時間程度である程度整ったプロトタイプが生成できるため、スピード面で大きく工数を削減できる。また、Figma Makeはチームメンバーやプロダクトオーナー、カスタマーサクセスの方々とやり取りする際に言語化しづらい領域をデザインで表現できる点が強みだ。アイディアレベルのものも即座に形にしてフィードバックを受けられることで、意思決定の迅速化と手戻りの削減が実現する。非デザイナーでもアイデアを視覚化できるため、部門間コミュニケーションが円滑になる。

留意点と活用法

Figma AIの導入にあたっては、適切な活用領域の見極めが重要である。現時点では既存プロダクトの運用フェーズでフル活用するのはまだ難しいものの、新規プロジェクトやモックアップ作成には十分効果的と評価されている。生成されるコードはReactベースの構成になっているため、既存技術スタックとの整合性確認も必要だ。Figma Makeは他職種のメンバーとのコミュニケーションをスムーズにし、アイディア出しを活発にするための共通の思考ツールとしても活用できる点を踏まえ、段階的な導入計画を立てることが成功の鍵となる。まずはパイロットプロジェクトでの検証から始めることを推奨する。

まとめ

Figma AIとFigma Makeは、UI/UX開発の在り方を根本から変革するポテンシャルを秘めている。チャットによるデザイン生成は、開発工数の削減だけでなく、チーム全体の創造性向上とコミュニケーション活性化をもたらす。ただし、既存ワークフローとの統合や適切な活用領域の選定には専門的な知見が求められる。

続きを見る >

ベトナムオフショア開発に向く3つのプロジェクトと、向かない3つのプロジェクト

ベトナムに向くプロジェクトの特徴

ベトナムへのソフトウェアのオフショア開発については昔から肯定的な意見と否定的な意見があります。昨今のベトナムの人件費の向上と日本の人件費の低下、そして円安もあり、コストダウン効果が見込めなくなってきています。しかし、単に海外オフショア開発が良いか悪いかという単純な問題ではなく、ベトナムの特徴を踏まえて、どのようなプロジェクトが向いているのか見極めることが重要です。本記事では、ベトナムにおけるオフショア開発に向く3つのプロジェクトと、向かない3つのプロジェクトを紹介します。

ベトナムに向くプロジェクト

1. 生産拠点や流通拠点を持つERPシステム開発

日本企業がベトナムに自社の生産拠点や流通拠点を持ちそのためのERPシステムを開発する場合、ベトナムは適した場所と言えます。ベトナム企業はベトナムの市場に精通しており、日本企業もベトナムの物流や製造現場に慣れています。また、ERPシステムの構築経験も蓄積されており、ベトナムのソフトウェア業界は成熟しています。さらに、ベトナム人の日本語通訳者の能力も向上しており、生産や流通に関わる日本語も習得しています。このような環境下でのERPシステム開発は、効率的かつ円滑に進めることができます。

2. ライトなWeb開発など経験を必要としない開発分野

技術の進化が激しいWeb開発など、比較的ライトで長年の経験を必要としない開発分野においても、ベトナムは適した場所と言えます。これらの分野では、若くて習得の早い技術者が求められます。ベトナムの技術者は熱意を持ち、新しい技術の習得に積極的です。また、技術自体も日本やベトナムといった特定の地域に依存せず、汎用性の高いものが多いため、ベトナムの技術者との協力により効果的な開発が行えます。

3. BPO的なプロジェクトでの教師モデル開発や画像タギングなど

ベトナムはAIにおける教師モデルの開発や画像のタギングなどのBPO的なプロジェクトにも適しています。ベトナムの基礎教育レベルは高く、労働者の字の読み書きやPCの使用能力に問題はありません。また、ベトナムはピラミッド型組織を構築しやすい文化的環境が整っているので大量生産に向いています。これらの要素を活かして、BPO的なプロジェクトをベトナムで展開することは効果的です。

ベトナムに向かないプロジェクト

1. コストダウンが目的のインクルーシブなプロジェクト

単純なコストダウンが目的のインクルーシブなプロジェクトは、ベトナムにとって戦略的な選択肢とは言えません。最初は若くて安いエンジニアを投入することで一時的なコストダウン効果を得るかもしれませんが、時間が経つにつれて人件費が上昇し、コストが増加してしまいます。また、ベトナムのエンジニアも自身のキャリアパスを考えるため、離職率が高く、人材の取り替えが困難になる場合もあります。

2. AIなど最先端技術のラボラトリーとしてのプロジェクト

ベトナムはAIなどの最先端技術のラボラトリーには向いていません。ベトナムは積極的な技術開発を行っていますが、他の国々も同様に積極的であり、特にアドバンテージがあるわけではありません。また、最先端技術になるほど人件費が高くなり、ベトナム価格でも他の国と競争することが難しい場合があります。このような背景から、ベトナムにおける最先端技術の開発には慎重な判断が求められます。

3. 最終消費者向けのセールスやマーケティングシステム

最終消費者向けのセールスやマーケティングシステムは、ベトナムとの文化や商習慣、法律、税制などの違いにより、開発が困難となる場合があります。ベトナム側で日本のマーケットに適したシステムを開発することは難しく、逆に日本側でもベトナム市場に合わせたシステムを構築することは容易ではありません。ただし、バックエンドのシステムに関しては国による違いは少ないため、ERPのようなバックエンドのシステム開発はベトナムでも適しています。

以上がベトナムにおけるオフショア開発に向くプロジェクトと向かないプロジェクトの一例です。プロジェクト選定においては、ベトナムの特徴や環境を的確に把握し、ベターな組み合わせを選ぶことが成功への重要な戦略となります。

続きを見る >

DX予算が通らない真因

DX予算否決の壁

「DX推進の予算を申請したのに、経営層から却下されてしまった」——そんな苦い経験を持つDX担当者は少なくない。市場環境の変化や競合のデジタルシフトに対応するため、DXが急務であることは多くの方が理解している。しかし、その必要性が経営層に正しく伝わらなければ、どれほど優れた施策であっても予算は承認されない。実は、予算が通らない本当の原因は、提案内容そのものではなく「伝え方」にあることがほとんどである。

経営層が承認しない理由

多くのDX担当者は、最新技術のトレンドや業務効率化の可能性を中心にプレゼンを組み立てがちである。しかし、経営層が重視するのは「技術の新しさ」ではなく「投資に対するリターン」だ。具体的なROIの試算や競合他社の導入事例、導入しなかった場合のリスクといった経営判断に直結する要素が欠けていると、提案は「面白いが今ではない」と先送りにされてしまう。さらに、現場の業務課題と経営課題を結びつける視点が弱いことも、予算が通らない大きな要因のひとつである。経営層の関心事を正しく理解し、その言語で語ることが予算承認への第一歩となる。

予算を勝ち取る提案術

では、どうすれば経営層を動かす提案ができるのか。まず重要なのは、DXの目的を「業務改善」ではなく「経営課題の解決」として再定義することである。たとえば「受発注業務をデジタル化する」ではなく、「受発注のリードタイムを30%短縮し、年間○○万円のコスト削減と顧客満足度の向上を実現する」というように、具体的な数値で効果を示す。次に有効なのが、スモールスタートの提案だ。いきなり大規模な投資を求めるのではなく、まず小さな成功事例を作り、その実績をもとに次の予算を獲得していくアプローチは、経営層の心理的ハードルを大幅に下げてくれる。加えて、同業他社の成功事例や政府の補助金制度を活用した費用対効果の説明も、説得力を高める強力な武器になる。

DX予算獲得は伝え方が9割

DX予算が通らない根本的な原因は、多くの場合、技術や施策の問題ではなく経営層との「コミュニケーションギャップ」にある。担当者が見ている世界と経営層が見ている世界は異なり、現場の課題感をそのまま伝えるだけでは、経営判断に必要な情報が不足してしまうのだ。大切なのは、経営層が意思決定しやすい形に提案を翻訳することである。ROI、リスク、競合動向、段階的な投資計画——これらの要素を盛り込むことで、提案の説得力は格段に上がる。DXは一度の提案で完結するものではない。小さな成功を積み重ね、信頼と実績を築きながら組織全体の変革を推進していく姿勢こそが、最終的に大きな予算獲得へとつながっていくのである。

まとめ

DX予算が通らない原因は、提案内容よりも経営層への伝え方にある。技術視点ではなく経営視点で語り、具体的なROIやリスクを数値で示すこと。そしてスモールスタートで実績を作り、段階的に投資を拡大するアプローチが有効である。

続きを見る >