要件定義のアプローチ

負債の本質

技術的負債には、設計負債やコード負債がある。金銭的な負債であれば借入金やマイナスの表記で数字化できるのだが、技術的負債においては数字化できないことがとても難しい点である。経営に関するほとんどのことは定量化や定性化が可能だが、たとえば企業創業者の発想する「野生の勘」を直接的に数字化できないように技術的負債も一筋縄では見える化しない。

設計時の対策

技術的負債の中でもコード負債については、システム開発の現場からよく発想されるリファクタリングや再構築などを行うことで比較的わかりやすい返済方法となる。知らない人が作ったプログラムや古くなったプログラムのバージョンなど、リスクを表現し対応することができる。何よりも最初の企画設計段階で負債が積みあがりにくい仕組みを考えることが大切である。

高負担な設計

技術的負債の中でも利息の高い負債が設計負債である。単体機能における設計であれば、モジュールごとの再設計によって返済が可能である。しかし、プログラムは複数のモジュールが絡まり合っていることがほとんどなので、複雑なオペになってしまう。また、稼働中のシステムにわざわざ再設計したプログラムを導入するリスクに対して、得れるメリットも少ないので見過ごされがちである。設計能力は例えば、紙というオブジェクトのメソッド（振る舞い）とプロパティ（保持する情報）を聞いて正しい答えが帰ってくれば多少安心であろう。紙の振る舞いは燃えるであり保持する情報は面積などがある。

根本的解決

しかし、技術的負債はこのように目に見えやすい設計負債やコード負債が致命的になることは少なく、やはりその上層でどのような指針に基づいてシステム運用がなされてきたか、また長期視点で一貫したメンテナンスを行うことが必要である。システムの維持には保守費用や運用費用を払っていることが多いと思うが、これだけでは将来の負債を減らしていくことはできない。やはり、鳥の目を持つITコンサルタントやITアナリストなどの役割を持つメンバーが必要である。

まとめ

ITコンサルタントやアナリストは、すぐに利益も生まない、経費を削減するわけでもないといったコストセンターとしてのポジションなので、あまり起用していない中小企業も多いようである。投資に対する効果が見えにくいのは、料理でいう香辛料と同じなのかもしれない。その少しの投資が未来を大きく変えることになる。IT技術は日進月歩で発展するからである。

導入

Web開発は様々な分野が存在しますが、ベトナムは比較的ライトウェイトなWeb開発に適していると言えます。本記事では、Web開発のいくつかのカテゴリについて検討し、ベトナムでのオフショア開発の適性について評価します。

カテゴリ1: 古典的なホームページ開発

古典的なホームページ開発について考えます。現在でも、完全なスクラッチでのホームページ開発が行われることもありますが、一般的にはWordPressなどのフレームワークが使用されることが多いです。このカテゴリについては、利点と欠点がありますが、ベトナムがオフショアに向いているかどうかは、まずは中立的な評価となります。

まず欠点から述べると、デザイン要素が大きいために海外での開発には向いていないと言えます。企業のウェブサイトや商品紹介ページ、ランディングページなどは、マーケティングの観点からデザイン要素が重要です。これらはウェブ開発やHTMLの問題ではなく、デザインの問題であり、プロジェクトの規模的に技術的な開発とデザインの分野が結合していることも多いです。このようなプロジェクトを海外にアウトソースすることは適切ではありません。ベトナムであろうと他の国であろうと、同様の理由が当てはまります。また、ベトナムの開発会社が日本語に堪能であっても、最も難しい分野を外国人に依頼していることを考えるべきです。

一方で、利点について考えましょう。デザインとウェブ開発の分業体制が進んでおり、古典的なホームページ開発の事例は少なくなってきています。従って、ある程度の分業体制が整っている場合は、一部をベトナムにアウトソースすることは合理的です。具体的には、デザイン部分を日本国内で行い、コーディングのみをベトナムで行う方法が考えられます。また、WordPressの記事やショッピングのCMSにおける商品加工など、既にデザインがテンプレート化されている場合もあります。Webは様々な使い方ができるため、適切な開発方法を選ぶためには、日本国内でキャリアのある人材を選択することが重要です。しかし、開発のシステム化を進める企業にとっては、一部の工程をアウトソースすることは有益です。

カテゴリ2: アプリケーションのウェブインターフェース

次に、アプリケーションのウェブインターフェースについて考えます。システムの本質的な価値はデータベースにありますが、検索や編集、書き込みなどにウェブ技術が使用されることは一般的です。また、これはスマートフォンアプリの開発にも大きく関連しています。特にビジネス用途のスマートフォンアプリは、実際にはサーバーやデータベースへのウェブインターフェースに過ぎないことが多いです。

このような開発においては、ベトナムが向いています。デザイン要素や言葉の使い方についてあまり心配する必要がなく、英語で開発しても大きな影響はありません。正確な判断基準を明確に整理できることが、現実的には最も簡単です。過去には、ウェブをシステムのインターフェースとして使用する方法には多くのノウハウが必要でした。例えば、JavaScriptを使ってカレンダーをポップアップさせたり、メールの文字化けに対処するための独自のルールが存在しました。しかし、Bootstrapなどのライブラリ化により、これらの問題は解決されました。そのため、ベトナムのエンジニアの若さや素早さを活かして、新しい技術を学びながら開発を進めることが可能です。

ただし、このような開発には継続性がないという問題もあります。長期間にわたって使用されるシステムではありますが、このような仕事には継続性が求められません。したがって、最適な解決策が存在しない場合でも、状況に合わせて適切な方法を見つける必要があります。

結論

ベトナムは比較的ライトウェイトなWeb開発に向いていると言えます。古典的なホームページ開発においてはデザイン要素が重要であり、海外にアウトソースすることは適切ではありません。しかしその開発工程において分業化や標準化がすでになされている場合は、オフショア開発を検討することは有益でしょう。また、ビジネス用途のアプリケーションのウェブインターフェースにおいては、ベトナムのエンジニアが若さと素早さを活かして開発を進めることができます。
これらの開発においては、WordPressやBootstrapなどのツールやフレームワークを活用することで効率的な開発が可能です。企業のシステム開発においては、オフショア開発の一部を活用することで生産性を向上させることができるでしょう。

DX推進の落とし穴

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

失敗企業の共通点

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

成功企業の原則

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

成功は準備次第

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

まとめ

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