トピックス

新しい技術記事を追加しました

技術情報ページ「TECH」に新たな記事を追加しました。 今回は「社内向けiOSアプリをApp Storeで配信する手順」として
弊社WEBエンジニアが「iOSアプリを開発し、配信するまで」の
取り組みを記載いたしました。

技術の幅を広げる取り組みですが、「社内専用アプリ」を手軽に
運用・配信するには？という方の参考になれば幸いです。 ぜひご覧ください。 👉 技術記事はこちら

VB6の業務パッケージを生成AIでC#に移行する話

「VB6で作られた製品がまだ現役で動いている」
―――ソフトウェアベンダーの方とお話ししているとこの話題が出ることがあります。動いているからこそさわれない、でも対応できるエンジニアは減る一方。Windowsが新しくなるたびにヒヤヒヤする、VB.NETに移す話も出るけれど、それで本当に解決するのか…… 私たちキューボックもまさにそういうお客様の課題と向き合っています。
今回は病院向け業務パッケージを開発・販売されている医療系ソフトウェアベンダーの主力製品をVB6からC#へ、生成AIを活用しながら段階的に移行するプロジェクトについて、お話ししたいと思います。 600画面超のパッケージ この製品は業務・帳票・集計・データ連携といった機能を持つ、いわゆる基幹系の業務パッケージソフトです。総画面数は600を超えます。
「全部いっぺんに刷新しましょう」という提案をしたくなりますが、正直、現実的ではありません。既存のお客様（医療機関）が今日も普通に使っているシステムです。長い時間をかけて練り上げられた業務ロジックがコードの隅々に埋め込まれています。それをビッグバンで置き換えるのはテストの負荷、業務停止のリスク、要員確保の難易度すべてが跳ね上がります。
そこで私たちは機能モジュール単位で少しずつ移していく方針を採りました。今回、その一部モジュールの移行を完了し、次にどう展開していくかを検討している、というのが現時点の状況です。 VB.NETではなく、C#にした理由 VB6からのマイグレーションと聞くと、真っ先に思い浮かべるのはVB.NETへの移行だと思います。ツールは提供されており、ソースコードの互換性も高く、既存のVB技術者もそのまま使えるため、移行コストも比較的安く抑えられます。一般的にはこれが正しいのですが、私たちは今回、この選択肢を採りませんでした。理由は大きく３つあります。 Microsoft自身がVB言語の進化を止めていること 2020年3月、Microsoftは公式ブログで発表しています。「VBは.NET 5以降もサポートするが、言語として発展させる予定はない」。2023年2月にも「VBは安定した言語であり、新しいワークロードへのサポートは追加しない」と明示しています。
つまり、これから.NETに新機能やパラダイムが加わっても、VB.NETには反映されません。VB.NETに移行できても数年～十数年後に「もう一度モダナイゼーション」の議論が発生する可能性は十分にあります。パッケージ製品の視点で見れば、これは二度目の刷新コストを将来の自分たちに残すことを意味します。 技術者の確保 今、新しくVB.NETを習得しようとしている若手エンジニアはほぼ見当たりません。一方でC#は、Web/モバイル/Unityなど広く使われていて、若手人材の裾野が違います。製品を10年、20年と保守・拡張していくとき、「触れる人がいる」ことの価値は本当に大きいと考えています。 製品の拡張余地 C#で作り直せば、その先の機能追加で.NETエコシステムをフルに使えます。クラウド連携、API化、AI機能の組み込み ――― こうした選択肢が現実的なコストで検討できるようになります。これはパッケージ製品の競争力にも直結します。
もちろんVB.NETを選ぶことが間違いだとは考えておりません。既存資産の量、社内スキル、予算、優先順位・・・判断の軸はお客様ごとに違います。ただ「なんとなく互換性が高いから」VB.NETを選んで数年後に後悔してほしくない、それがC#を提案した理由です。 生成AIをどう使ったのか もうひとつ、このプロジェクトの特徴があります。私たちのエンジニアはほとんどコードを書いていません。
VB6コードの読み解き、業務ロジックの抽出、変換後のテスト仕様書の作成、そしてC#コードへの変換―――こうした工程で生成AIをフルに活用しました。人手による直接的なコード記述は原則として行わないアプローチです。
こう書くと「エンジニアは何をしていたのか」という話になりそうですが、実際は逆でやることは減っていません。むしろ密度が上がっています。 今回、私たちのエンジニアがやったのはこんな仕事です。
　－　元のVB6コードと実際の業務仕様を突き合わせて理解する
　－　生成AIに「何を、どういう文脈で、どう作らせるか」を設計する
　－　生成されたC#コードをレビューし、設計判断を下す
　－　テスト設計する（テスト仕様書は生成AIに作らせます）
　－　動作を検証する
　－　次にどのモジュールをどう進めるかを組み立てる
コーディングという「手を動かす作業」の時間がそのまま「設計と検証に頭を使う時間」に振り替わっている感覚です。 このアプローチによりこれまで人手コーディング前提では予算が組めなかった規模の案件にも現実的な選択肢を出せる可能性が出てきました。「600画面を全部を書き直すなんて無理」と諦められていたパッケージにも「AIを使いながら段階的に」という道筋を提示できる。まだ手応えの段階ではありますが、大きな変化だと感じています。 やってみて感じていること AIが生成したコードをそのまま採用できるかというと、そんなことはありません。レビューでの引っかかりもあればテストでの手戻りもあります。
プロンプト設計が不十分だと、機能的には動作しても冗長な記述や過剰なコメントが目立つ「リファクタリングの余地が大きい」コードが生成されてしまいます。
ただ、丁寧に進めていくと、どこにAIが強くて、どこに人間の判断が必要かの勘所が少しずつ見えてきます。今回、一部モジュールを移し終えたことで「このやり方は次の案件でも活用できる」という手応え、実感を得ています。
残るモジュールにどう展開していくか、他のお客様の類似案件にどう応用していくか、これからの課題です。 同じような悩みを持っていたら もしパッケージ製品の古い資産を抱えていて、こんなふうに感じているなら ―――

　－　動いているから触れない、でもこのままではまずい
　－　新しい環境に移す話は出るけど、それで本当にいいのか迷っている
　－　全面刷新は予算的にも工数的にも無理だと諦めている
　－　若手エンジニアが集まらず、保守要員の高齢化が気になっている

――― ぜひ一度、お話しさせてください。医療系に限らず、製造・物流・建設・士業向けなど、パッケージソフトを展開されているベンダーの方であれば業種を問わずご相談いただけます。
必ずしも「今すぐ全部やりましょう」という話ではありません。まずは製品を今後どう位置づけていくか、どこから手を付けるのが現実的か。そういった整理からご一緒できればと思っています。 お問い合わせ：こちらのフォームから

新しい技術記事を追加しました

技術情報ページ「TECH」に新たな記事を追加しました。 今回は「Tomcat が2週間でフリーズする問題を解決した話」として
実際の開発現場での知見をもとにまとめています。
スマホアプリ・WEBシステム開発に携わるエンジニアの方はもちろん
技術的な背景を知りたい方にもお読みいただける内容です。 ぜひご覧ください。 👉 技術記事はこちら

技術ブログを開設しました

普段の開発で気づいたことや、役立つ情報をわかりやすくお届けしていきたいと思います。
お気軽にご覧くださいませ！　記事はこちら https://q-boq.co.jp/tech

受託開発チームで新しい仲間を募集しています！

こんにちは、採用担当です。
キューボックでは現在、受託開発チームのメンバーを募集しています！
エントリー、お待ちしております！ 　🛠 受託開発って、どんな仕事？ キューボックの受託開発は「言われたものを作る」だけじゃありません。
お客様の課題を一緒に考えながら、仕様をすり合わせて、一緒に育てていく仕事です。 私たちの得意領域はスマートフォンアプリ＆Webアプリケーション。
動画配信やアプリ内課金、ストアリリースまで対応可能です。 社内には「技術の話が好きな人」「着実に進めるのが得意な人」などいろんなタイプがいますが、
共通しているのは「気持ちよく、誠実に仕事したい」というスタンス。 　🧑‍💻 こんな人をお待ちしています 大それたことは言いません。以下のような方、ぜひ話を聞かせてください。 　　　◯ チームで開発するのが好きな方
　　　◯ 受託開発に興味がある、または経験がある方
　　　◯ ユーザーやクライアントの「こうしたい」に寄り添える方
　　　◯ まあまあ真面目だけど、ちょっと笑いも大事にしたいタイプの方 　📩 ご応募・お問い合わせはこちら 少しでも気になった方は、以下のリンクまたは採用ページからご連絡ください。
カジュアル面談もOKです。お互いのことをよく知ったうえで進められたらと思っています。 👉 https://en-gage.net/q-boq/ 　おわりに 私たちの受託開発チームは「いいものを、いいやり方で」つくりたい人たちが集まる場所です。
ちょっと不器用でもOK、おもしろがって一緒に考えてくれる人、ぜひご一緒したいです。 そんな仲間に出会えることを、楽しみにしています！