効率化の誤解

目標設定の要諦

SESと呼ばれる派遣や準委任契約では、プロジェクトを完遂することが難しいとしている。これはゴールが未設定であったり、曖昧になってしまう場合が多くあるからである。ゴールの設定や未来像は非常に重要で、プロジェクトマネージャーなどリーダーが必ず持っておくべき指針である。

真のリーダー像

システム開発に参画するメンバーは一般的に経歴書やスキルシートによって決まる。プロジェクト経験数が多かったり、扱える言語が多かったりするだけでは、本当のスキルは推しはかれない。やはり、確認すべきは不測の事態が起きたときの対処方法を豊富に持つリーダーが必要となる。

アジャイルの本質

犬小屋を建てるときに設計書はいらないが、マンションを建てるには設計書がいる。アジャイル開発といっても、例えばマンションを設計図なしに建てるといったことを考えるとある程度は見通しや知見などを持つメンバーが方向性を決めていく必要がある。システム開発はその時その時の条件によっていい悪いの判断軸が変わる。さらに時間の経過でも判断軸が変化していくのである。

部分最適の罠

日本には「カイゼン」という高度経済成長期を支えた力強い言葉がある。しかし、時と状況によって判断軸が変わるソフトウェアという無形財産の前では、「善」に「改」めることができているのか、変化してしまう背景がある。職人気質である国民性も相まって、どうしても部分改善、部分最適を繰り返してしまうというプロジェクト現場が少なくない。

まとめ

システム運用や保守における部分最適は必ずしも全体最適になるわけではない。むしろ、この部分最適が全体を考えたときの労働生産性を下げていることすらある。小回りが利く人であればあるほど属人化してしまったりするため、誰が全体最適を見るのがベストなのか、改めて考える必要がある。

関連記事

ローコード開発とAI活用

AIとローコードの融合

ローコード開発プラットフォームの普及により、非エンジニアでもアプリケーション開発が可能になった現在、生成AIの活用が大きな注目を集めている。ChatGPTやCopilotなどのAIツールを組み合わせることで、開発スピードがさらに向上すると期待されているが、本当にすべてのローコード開発にAIが必要なのだろうか。コスト、品質、保守性など多角的な視点から、AI導入の真の価値を見極めることが、企業のDX戦略において極めて重要になっている。

コード生成の現実

生成AIによるコード生成は確かに魅力的だが、実際の品質には課題がある。AIが生成するコードは、単純な処理であれば高品質だが、複雑なビジネスロジックや例外処理が絡むと、不完全なコードが生成されることが少なくない。さらに深刻な問題は要件定義の壁である。AIは与えられたプロンプトに基づいてコードを生成するが、曖昧な要件や暗黙の前提条件を正確に理解することは困難である。結果として、開発者は生成されたコードを詳細に検証し、修正する必要があり、期待したほどの効率化が実現しないケースも多く見られる。

保守性のコスト

AIを活用したローコード開発において、最も見落とされがちなのが保守性の課題である。AI生成コードは、その時点では動作しても、後から読み解くことが困難な構造になっていることがある。変数名が不適切だったり、処理の意図が不明瞭だったりすると、半年後に修正が必要になった際、開発担当者が変わっていた場合、大きな手戻りが発生する。また、AIツールのバージョンアップや仕様変更により、過去に生成されたコードとの互換性が失われるリスクも存在する。初期開発のスピードを重視するあまり、長期的な運用コストが膨らんでしまっては本末転倒である。真のDX推進には、目先の効率化だけでなく、持続可能な開発体制の構築が不可欠なのである。

適切な見極め

ローコード開発におけるAI活用は、すべてのケースで必須というわけではない。定型的な画面開発や単純なCRUD操作など、パターン化された開発にはAIが有効だが、複雑なビジネスロジックや高度なセキュリティが要求される領域では、人間による丁寧な設計と実装が重要である。重要なのは、プロジェクトの性質、チームのスキルレベル、長期的な保守計画を考慮した上で、AIを活用すべき領域と従来手法を維持すべき領域を明確に区分することである。段階的にAIツールを導入し、効果を検証しながら適用範囲を拡大していく慎重なアプローチが、失敗リスクを最小限に抑え、真の生産性向上につながる。

まとめ

ローコード開発へのAI導入は、万能の解決策ではなく、適材適所で活用すべきツールである。コード生成の質、要件定義の難しさ、保守性の課題を十分に理解した上で、自社の開発体制に合った形でAIを取り入れることが成功の鍵となる。短期的な効率化だけでなく、長期的な運用まで見据えた戦略的な判断が求められている。

続きを見る >

なぜベトナムは比較的ライトウェイトなWeb開発に向いているか

導入

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

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

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

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

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

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

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

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

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

結論

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

続きを見る >

ローコード開発≠安い

誤解されるコスト削減

実はローコード・ノーコードツールを使えば、開発が必要なくなるので安くなるというのは正しくない。たしかに、ノーコードツールを社内メンバーでCMSを使ってソフトを作るという場面は開発費用はかからない。

CMSとはコンテンツ・マネジメント・システムの略で、たとえばWebサイトのコンテンツを構成するテキストや画像、デザインなどを非エンジニアがプログラミングをせずに作成や管理できる仕組みのことである。ローコードツールはそれに加えて少しのプログラミング知識でシステムやツールを作成できることである。

開発手法の選択基準

断じてローコード開発だからといって安いわけではない。開発手法の特性による得手不得手を上手に使い分けるからトータルとして価格が安くなるということである。非エンジニア営業の金額調整という意味での判断でローコード開発を選択する場合は失敗することがある。

システム導入の本質理解

ローコード開発でも、システム導入の目的や条件が本質的にわかっていなければ、仕様要件のブレによって結果としてトータルが安くなることはない。これはローコード開発ということが問題なのではなく、フルスクラッチ開発であっても、SaaSと利用する場合であっても同じことが言える。

負債の危険

本来ローコード開発が適さない場合にも関わらず無理やりに合わせることで、プログラム部分の複雑性が増し、技術的負債となって大きな問題になっていく。結果として安くはならず、ローコード開発のメリットであるメンテナンス性までも損なうため、トータルで考えると高くなる。

まとめ

お客様の予算内で考えないといけないので、といった口癖があれば注意が必要である。クライアントの言いなり状態であれば、無理な要求は開発における仕様だけではないだろう。金額を含めた総合的な判断ができる人が、結果としてローコード開発を選択するわけである。

続きを見る >