【極限の設計論】VB.NETにおける「複数戻り値」の正解。ValueTupleでコードのノイズを削ぎ落とし、堅牢性を手に入れろ。
業務自動化ツールの開発現場において、我々エンジニアは常に「スピード」と「品質」のジレンマに直面する。
ファイル操作、データベースへのクエリ、複雑な計算ロジック。これらのメソッドを設計する際、多くの開発者が陥る「設計の罠」がある。それは、「複数の結果を返したいが、わざわざ専用のクラスや構造体を作るほどでもない」という場面での妥協だ。
`ByRef` を多用して引数で値を書き戻すのか？ それとも、その場限りの使い捨てクラスを定義して名前空間を汚染するのか？
断言しよう。どちらも正解ではない。
本記事では、モダンなVB.NETにおける最強の武器、`ValueTuple` を活用した、美しく、かつ堅牢な複数戻り値の設計手法を伝授する。コードの可読性を劇的に向上させ、バグの温床となる「不明瞭なデータ受け渡し」を根絶するための極意を、今ここで叩き込む。
1. なぜ、あなたの設計は「重い」のか
まず、現場でよく見かける「避けるべき設計」をレビューしよう。
避けるべきパターンA：`ByRef` による副作用の連鎖
' ❌ アンチパターン：ByRefによる設計
Public Sub ReadConfiguration(ByVal filePath As String, ByRef isSuccess As Boolean, ByRef content As String)
' ロジック...
End Sub`ByRef` は、メソッドの外にある変数を直接操作する。これは一見便利だが、大規模なアプリケーションでは「いつ、どこで値が書き換わったのか」の追跡を不可能にする。副作用の塊であり、ユニットテストの最大の敵だ。
避けるべきパターンB：使い捨てクラスの乱造
' ❌ アンチパターン：過剰な設計（Over-engineering）
Public Class FileReadResult
Public Property Success As Boolean
Public Property Content As String
End Class
Public Function ReadFile(ByVal path As String) As FileReadResult
' ロジック...
End Function「たった一つのメソッド内でしか使わない」データのためにクラスを定義するのは、プロジェクトの資産（名前空間）を汚染する行為だ。クラス定義が増えれば増えるほど、コードの全体像を把握するコストは増大する。
2. 救世主 `ValueTuple`：スタック上の軽量な情報伝達
ここで登場するのが `ValueTuple` だ。
`System.Tuple`（参照型）と混同してはいけない。我々が使うべきは、値型（Value Type）である `ValueTuple` だ。
ValueTuple が優れている3つの理由
1. 名前付き要素（Named Elements）: `Item1`, `Item2` といった無意味な名前ではなく、`IsSuccess`, `ErrorMessage` といった意味のある名前で値を扱える。
2. 圧倒的なパフォーマンス: 参照型（Class）と違い、スタック領域に割り当てられる。ヒープへの割り当て（GCの負荷）を回避できるため、ループ内での大量生成でもパフォーマンスが低下しない。
3. ボイラープレートの排除: クラス定義を書く必要がなく、メソッドのシグネチャだけでデータの構造を定義できる。
3. 実践：プロダクション品質の設計例
では、実務で即戦力となるコードを示そう。
シナリオは「設定ファイルを読み込み、成功成否・内容・エラーコードを返す」という、業務ツールでは頻出するパターンだ。
【推奨】ValueTupleを用いたスマートな設計
Imports System
Module FileProcessor
''' <summary>
''' 設定ファイルを読み込む。
''' </summary>
''' <param name="filePath">対象ファイルパス</param>
''' <returns>
''' (IsSuccess: 成功成否, Content: 内容, ErrorCode: エラーコード) のタプル
''' </returns>
Public Function TryReadFile(ByVal filePath As String) As (IsSuccess As Boolean, Content As String, ErrorCode As Integer)
Try
' ファイルの存在チェック
If Not System.IO.File.Exists(filePath) Then
' 失敗時も、構造を維持したまま意味のある値を返す
Return (False, String.Empty, 404)
End If
' ファイル内容の読み込み
Dim content As String = System.IO.File.ReadAllText(filePath)
' 成功時：名前付きで値を返す
Return (True, content, 0)
Catch ex As Exception
' 例外発生時：エラーコードを定義して安全に返す
' 業務アプリでは、例外をそのまま投げ飛ばすより、
' 状態として返却する方が呼び出し側の制御が容易になる場合が多い
Return (False, String.Empty, 500)
End Try
End Function
Sub Main()
' --- 呼び出し側の実装 ---
Dim path As String = "config.txt"
' 1. 分解代入（Deconstruction）によるスマートな受け取り
' VB.NETでは、タプルを直接変数に展開できる
Dim (success, data, err) = TryReadFile(path)
If success Then
Console.WriteLine($"[SUCCESS] 内容: {data}")
Else
Console.WriteLine($"[ERROR] コード: {err}")
' エラーコードに基づいたロジカルな分岐
Select Case err
Case 404 : Console.WriteLine("原因: ファイルが見つかりません。")
Case 500 : Console.WriteLine("原因: システムエラーが発生しました。")
End Select
End If
Console.ReadLine()
End Sub
End Moduleアーキテクトの視点：ここが「堅牢」のポイント
1. 戻り値の「意味」をシグネチャに込める:
`As (IsSuccess As Boolean, …)` と記述することで、メソッドのドキュメントを読まずとも、何が返ってくるかが一目でわかる。これは「自己文書化」されたコードだ。
2. 例外の制御:
`Try…Catch` で例外を捕捉し、`ErrorCode` という「状態」に変換して返している。これにより、呼び出し側は `Try…Catch` を乱用することなく、`If success Then` という極めて読みやすいロジックでフローを制御できる。
3. 分解代入（Deconstruction）の活用:
`Dim (success, data, err) = …` の一行。これこそがモダンな書き方だ。一時的な変数 `result` を作って `result.Item1` とアクセスするような、泥臭いコードとは決別せよ。
4. 運用上の注意点：落とし穴を回避せよ
どれほど優れた武器も、使い所を間違えれば凶器となる。
① 複雑すぎるタプルは「クラス」へ昇格させよ
戻り値が5つ、6つと増えていくようなら、それはもはや `ValueTuple` の限界を超えている。
要素が増えすぎたタプルは、呼び出し側の引数リストを混乱させ、可読性を著しく損なう。「3〜4要素を超えたら、専用の構造体（Structure）またはクラスを検討せよ」。これが設計の境界線だ。
② .NET Framework のバージョンに注意
`ValueTuple` は、.NET Framework 4.7以降、または .NET Core / .NET 5+ で標準サポートされている。古いレガシー環境（.NET 4.0/4.5など）を保守する場合は、NuGetパッケージ（`System.ValueTuple`）の導入が必要になることを忘れるな。
③ 不変性（Immutability）の意識
タプルを受け取った後、その中身を書き換えるような設計は避けるべきだ。タプルは「データの塊」として、「一度作ったらその状態を保持する」という使い方が最も安全である。
結論
`ValueTuple` を使いこなすことは、単なる「書き方のテクニック」ではない。
それは、「メモリ効率を意識し、副作用を排除し、コードの意図を明確にする」という、プロフェッショナルなエンジニアリングの実践そのものだ。
無意味なクラス定義でプロジェクトを肥大化させるな。
`ByRef` で予測不能なバグを招くな。
これからは、スマートなタプル設計によって、美しく、堅牢な自動化ツールを構築せよ。
幸運を。
