予算ブレの原因

導入

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

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

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

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

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

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

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

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

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

結論

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

内製化の壁

システムの内製化が重要ということは、どこでも聞くと思う。しかし、具体的に内製化していくための段取りを整理して教えてもらうのは難しいのかもしれない。業種業態によって様々なケースが存在するからである。内製化を成功させるには、単に技術的な知識だけでなく、組織全体での戦略的な取り組みが不可欠となる。

経営コミット

システム開発の内製化を行っていくには、まず経営層からのコミットメントが必要不可欠である。これが必要であるから諸外国ではCRO（Chief-Revenue-Officer）という部門を横断した権限を持つ人を据えている。その上で、まず内製化の目的を明確にする。おおむねコスト削減、スピード向上、ナレッジ蓄積などであろう。目的がきまると、企画、開発、保守、インフラなどのどの範囲で内製化するのが見えてくる。組織全体での合意形成が内製化成功の基盤となるのである。

失敗回避策

よく聞く失敗例では、権限のないIT戦略室、デジタル推進部などを作ってしまうことである。あるいは、適切な人員の配置や育成がなされないパターンも同様である。大きな権限を持つことになることを前提に考えると、実施するプロジェクトについても小さなプロジェクトにおいて実績を積み上げたほうがいいだろう。たとえば、小規模低リスクである業務改善ツール（例：Power AppsやExcelマクロ）から市民開発を実施していくなどを計画することをお勧めする。段階的なアプローチが組織の信頼獲得につながる。

仕組み化

小さなプロジェクトで実績を積むと、こなれてきてしまうため、やはり属人化の危険性が伴う。ここで、いかに永続的に考えることができるか、内製化のための仕組みを構築できるかは、システム開発経験者などの知見のある人も交えて人材育成に取り組むべきである。定期的な振り返り（レトロスペクティブ）やナレッジ共有会、現場からの改善提案を吸い上げる文化を育て、仕組化していく。持続可能な内製化には組織文化の変革が欠かせない。

まとめ

開発基盤とガバナンス整備、ソース管理やドキュメント管理などの定性的な内製化は簡単に作ることができる。しかし、そのマインドや仕組み、自然とDevOpsをはじめとしたPDCAサイクルにもっていくには、システム知見だけでも難しくある。持続的な内製化にたどり着くためには最初の企画や構成段階で知見をもつメンバーを入れておくのがよいだろう。

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。