フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月(人工)単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

関連記事

日本の技術人材不足とオフショア開発

セクション1: 日本のソフトウェア開発人材不足の背景

日本のソフトウェア開発業界は50年以上の歴史を持ち、多くの経験豊富なエンジニアが存在します。しかし、現在の日本では開発人材の不足が深刻な問題となっています。この人材不足は、企業が即戦力となるエンジニアを安価で求めるという要望に由来しています。そのため、日本の人材不足はしばしば「即戦力を安く求める欲求」として揶揄されることもありますが、この言い方には一面の真実も含まれています。企業が効率的な開発を行うためには、即戦力のエンジニアが必要なのは当然のことです。

また、この人材不足の問題は、単に日本だけに限ったものではありません。他の海外でも同様の人材不足が起きています。したがって、オフショア開発を検討する際には、都合の良い人材を海外で見つけることができるという考え方は一部正解であり、一部誤解とも言えます。

セクション2: 日本とベトナムのエンジニアの特徴

日本のエンジニアは、特にWeb関連のエンジニアにおいては、1990年代からのキャリアを持つベテランが多く存在します。そのため、文字コードやバイナリ、組み込み技術など、古いOSや低レベルの知識を必要とする開発においては、日本の技術者は強みを持っています。一方、新しいフレームワークや概念の習得には、国民性よりも年齢が影響を与える傾向があります。そのため、ベトナムのエンジニアは若さを活かして新しい技術を素早く学ぶことが得意と言えます。

また、コンピューター業界においては、上流と下流、低レベルと高レベルといった言葉が中立的に使われますが、この意味において日本は低レベル開発に向いており、ベトナムは高レベル開発に向いていると言えます。そのため、バランスの取れたオフショア開発を行うためには、日本のエンジニアのジェネラリスト的な能力とベトナムのエンジニアのスペシャリスト的な能力を組み合わせることが重要です。

セクション3: 日本とベトナムの開発手法の違い

日本のソフトウェア開発では、納期を守るためにウォーターフォール型の開発手法が主流です。アジャイル開発が概念的には取り入れられつつありますが、完全にアジャイルな開発プロセスを採用しているケースはまだまれです。一方、ベトナムのソフトウェア開発は、日本の開発手法と大きく異なるわけではありません。基本的には納期を守るためのウォーターフォール型の手法が一般的ですが、OSSの影響を受けて開発手法が変化しつつあります。

日本の開発現場と比較して、ベトナムの開発手法の利点は、新しいフレームワークや技術の習得において素早い反応性を持つことです。ベトナムのエンジニアは若く、学習意欲が高いため、最新の技術に対する理解が早く、柔軟に対応できるという特徴があります。ただし、ベトナムの開発現場においては、アジャイル開発の完全な導入はまだ一般的ではないことに注意が必要です。

セクション4: 言語の壁以外の考慮すべきポイント

ベトナムのエンジニアを活用する際に言語の壁を乗り越えるためには、円滑なコミュニケーションを図ることが重要です。英語がビジネスコミュニケーションの共通語となっているため、日本の企業がベトナムのエンジニアとのコミュニケーションを円滑に行うためには、英語教育の強化や翻訳ツールの活用などが有効です。また、文化やコミュニケーションスタイルの違いも考慮すべきポイントです。異なる文化背景を持つエンジニア同士が協力する場合、相手の文化に対する理解や尊重が求められます。

セクション5: 成功へのカギはバランスと柔軟性

ベトナムでのソフトウェア開発のオフショアを成功させるためには、日本とベトナムのエンジニアの特長を組み合わせることが重要です。日本のエンジニアはジェネラリストとして幅広い知識と経験を持っており、プロジェクト全体の管理や技術的な統括を担当することが得意です。一方、ベトナムのエンジニアはスペシャリストとして特定の技術に精通しており、新しい技術の習得にも素早く対応できます。

オフショア開発においては、開発現場のバランスと柔軟性が求められます。例えば、日本のエンジニアがジェネラリストとしてプロジェクトを牽引し、ベトナムのエンジニアがスペシャリストとして特定の技術領域を担当する役割分担が効果的です。また、現代的な開発手法を用いることも重要です。ウォーターフォール型の手法に加えてアジャイル開発の一部を取り入れるなど、柔軟に適切な手法を選択することが目的達成(コストダウン実現)へのカギとなります。

続きを見る >

DX予算が通らない真因

DX予算否決の壁

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

経営層が承認しない理由

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

予算を勝ち取る提案術

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

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

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

まとめ

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

続きを見る >

開発の相場

相場の不在

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

建築との差異

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

人件費の実態

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

工期の変動

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

まとめ

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

続きを見る >