関数命名におけるデータ方向性の設計

～A_To_BとB_From_A形式の考察～

Copyright © 2025 LWP 山中 一弘 本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

要約

関数名において「入力データから出力データへの変換・転記」を表す際、A_To_B（入力起点）とB_From_A（出力起点）のどちらを採用するかは、処理の責任がどちらにあるかによって判断するべきである。
出力データの仕様に責任がある場合はB_From_Aとし、入力データの流通や発信に重きがある場合はA_To_Bとするのが一般的である。
命名の一貫性を保つためには、ドメインごとに命名規約を設けることが望ましい。

第1章　はじめに

1.1 命名の重要性と目的

関数の命名は、単なるラベル付けではない。関数が担う処理の意味や責任、データの流れを明示する設計行為である。特に業務アプリケーションにおいては、関数名がそのままドキュメントの代替となり、他者による理解やメンテナンスのしやすさに直結する。

適切な命名は、プログラムの可読性を高めるだけでなく、誤った使用や副作用を未然に防ぐ手段にもなる。逆に、命名が曖昧であると、処理の意図が見えにくくなり、関数の重複や不整合を引き起こす原因となる。これは開発規模が大きくなるほど深刻な問題となる。

本稿では、関数命名における「データの方向性」という視点を中心に、命名の一貫性と設計責任との整合性を追求する。特に「A_To_B」形式と「B_From_A」形式の使い分けに焦点を当て、その意味的背景と実装指針を明らかにする。

1.2 データ指向の命名とは何か

データ指向の命名とは、関数の処理対象や変換対象となるデータ構造に焦点を当て、その変化の方向性を名前に反映させる手法である。従来の動詞主導の命名（例：Convert, Update, Set）に対し、名詞の変換関係（例：A_To_B、B_From_A）を明示することで、関数が「何をどうするのか」をより構造的に表現する。

この命名手法の背景には、関数が果たす責任の所在を明示し、同時にデータの発信元と受信先を可視化する意図がある。特に処理の複雑度が高まる業務系アプリケーションでは、データの流れを関数名から即座に把握できることが、設計・レビュー・保守の各局面で大きな利点となる。

データ指向命名の導入によって、処理構造と名前空間の整合性が高まり、設計上の曖昧さや重複を避けることができる。これにより、関数設計そのものが、より論理的かつ再利用性の高いものへと進化する。

第2章　二名法による関数名の構造

プログラミングにおける二名法とは、関数や変数の命名において「大きなもの_詳細_動作」の順序で構造を表す手法であり、設計意図と処理責任を明示するための命名規則である。たとえば Invoice_Total_Calculate は「請求書の合計を計算する処理」を表し、User_Profile_Update は「ユーザーのプロフィールを更新する処理」を意味する。

このように、先頭に「ドメイン対象（大きなもの）」を置くことで、命名の起点が明確となり、ドキュメントや補足なしでも設計構造が自然に読み取れるようになる。

二名法において、詳細部が省略される場合もある。たとえば User_Update のように書かれる関数は、オブジェクト全体への処理を意図しており、この場合はオブジェクト指向におけるメソッドと同様の意味構造になる。

また、動作部を省略した Report_DateRange のような命名は、データ構造や条件値を示す変数・プロパティとして使われることが多く、用途に応じて柔軟に命名粒度を調整できる点も特徴である。

この命名手法は、単なる識別子のルールではなく、関数が何に対して・どこまでの粒度で・どのような責任を持つのかを名前に埋め込む設計表現である。

この手法はドメイン駆動設計やレイヤードアーキテクチャとの親和性が高く、命名によって設計全体の可視性・保守性・再利用性を飛躍的に高めることができる。

2.1 A_To_B形式とB_From_A形式

代表的な形式として「A_To_B」「B_From_A」がある。「A_To_B」は、Aという入力をBという出力に変換・転記・適用する処理を示す。起点を入力に置いた表現であり、処理の焦点が「どのように変換されるか」にある。一方、「B_From_A」は出力を起点とした表現であり、「この出力はどの入力に基づいて構築されるか」に重きを置く。

これらの使い分けは、機械的な規則ではなく、関数が果たす設計上の責任に基づく。すなわち、出力の仕様や整合性に責任を持つ関数であれば「B_From_A」、入力データの加工や発信が主目的であれば「A_To_B」と命名すべきである。

どちらの形式を用いるかは、プロジェクトやドメインによって異なるが、いずれにせよ、責任の所在に即した命名こそが、設計の意図を最も端的に伝える方法となる。

2.2 名詞の粒度と一貫性の注意点

二名法における「A」および「B」に当たる名詞には、粒度（granularity）の統一が求められる。たとえば、「Customer」から「Invoice」への変換を表す場合、どちらもドメインオブジェクトの単位で統一されていれば問題ないが、一方が属性（例：CustomerName）で他方が構造体（例：Invoice）であると、読者に誤解を与える可能性がある。

さらに、同一プロジェクト内での命名の一貫性も極めて重要である。たとえば、「Order_To_JSON」と「SerializeOrder」のように表現が混在すると、同種の処理なのか異なる責任なのかが曖昧になり、開発・保守の障害となる。

命名規約を定める際は、「何を一単位として扱うか」「どのレベルで粒度を揃えるか」を明文化し、共通理解として浸透させる必要がある。これにより、関数群全体の構造的可読性が向上し、設計全体の品質が底上げされる。

第3章　入力起点 vs 出力起点の比較

3.1 処理責任による分類基準

関数命名における「A_To_B」と「B_From_A」の使い分けは、単なる表現の好みではなく、関数が担う処理責任に基づく設計判断である。どのような出力を生成すべきかという仕様責任を負う場合、その出力に焦点を当てる「B_From_A」形式が適切である。これは出力側の形式や整合性が業務要件に密接に関係する場面において特に有効である。

一方、入力の取得や発信が主目的であり、処理自体が入力起点で構成される場合は「A_To_B」形式が自然である。たとえば、ユーザーデータをレポート形式に変換する関数で、変換後のレポート構造に厳格な仕様が課されているなら「Report_From_UserData」が適切となる。逆に、ユーザーデータを他形式に順次出力するような流れにおいては「UserData_To_Report」が妥当となる。

命名形式の選択は、関数の内部実装ではなく、外部とのインターフェース、すなわち関数が契約している責任範囲に従って決定されるべきである。これにより、関数設計が仕様志向となり、全体設計の整合性が向上する。

3.2 転送／通知／変換における視点の違い

「転送」「通知」「変換」といった処理は、一見すると似ているが、命名においては視点の置き方が異なる。転送（Transfer）は、データをある形式から別の媒体へ移す処理であり、起点と終点の両方が明確な場合は「A_To_B」形式がふさわしい。通知（Notify）は、受信側が主語となるため、「Notification_From_Event」など出力起点の表現が自然である。

変換（Convert）は処理の種類によってどちらの視点も取りうるが、変換結果の仕様に重きが置かれるなら「B_From_A」、変換前の入力系列の流れに焦点があるなら「A_To_B」を選ぶべきである。

重要なのは、関数名により「誰が何に責任を持ち」「どの方向にデータが流れるか」を明確にすることである。これにより、単なる処理名ではなく、設計上の意図と責任構造を読み取ることが可能になる。関数は単独で完結するものではなく、設計構造の中で意味を持つ。その意味を適切に表現するためには、これらの視点の違いを認識した上で命名する必要がある。

第4章　設計指針としての判断基準

4.1 出力仕様に責任を持つ関数の命名

関数の主な責任が「どのような出力を生成するか」にある場合、その関数は出力の構造や整合性を保証する役割を担う。このような場面では、出力側を主語とした「B_From_A」形式が適している。たとえば「Invoice_From_Order」は、Invoiceという出力が正しく生成されることに責任があることを示している。

この形式は、出力の仕様が業務要件に密接に関係し、テストやレビューでも出力の正しさが主な評価対象となる関数で特に有効である。また、命名において出力側の仕様が先に明示されるため、読み手が処理の目的と結果を即座に理解しやすいという利点がある。

命名においては「この出力がどの入力に基づいて構築されるか」という観点を重視し、責任の所在を明確にすることが、堅牢な設計指針として機能する。

4.2 入力フロー主導の処理の命名

処理の主眼が「どのような入力を処理するか」に置かれている場合、命名は入力起点の「A_To_B」形式が適切である。たとえば「SensorData_To_LogEntry」は、センサーデータという入力がどのように処理されて記録されるかに注目した命名であり、処理フローの起点を明示している。

この形式は、複数の入力が次々と処理されるストリーム処理や、外部からのイベントドリブンな処理において効果的である。また、入力データの収集や発信のタイミングを明確に設計する場面では、起点の明示が処理全体の理解を助ける。

重要なのは、出力の仕様があくまで従属的なものであり、処理の設計責任が入力の収集・解釈・転送にある場合に、この形式を選ぶことである。関数の使用意図が「この入力を処理したい」にあるかぎり、A_To_Bの形式は明確な設計表現となる。

4.3 中立的な場合の簡潔表現（A_To_Bの許容）

処理の性質が明確に出力責任とも入力責任とも言い切れない中立的な場合、命名は読みやすさと簡潔性を優先して「A_To_B」形式に統一することも現実的な選択である。特に実装上の責任が分散している場合や、関数が単なる形式変換・ラッピングである場合などは、この形式で十分に意図が伝わる。

たとえば「XML_To_JSON」のような単純な形式変換では、特定の出力仕様や入力フローに強い責任があるとは言いにくく、処理の方向性を表すだけで十分なケースが多い。このような場合にまで厳密な責任論を適用すると、かえって命名が過剰に冗長になり、可読性を損なう恐れがある。

中立的な場面では、処理の実装意図と設計の複雑さを勘案した上で、命名方針に一貫性がある限り、A_To_B形式を包括的に使用しても問題はない。ただし、その際にも「この命名は中立性に基づく簡略表現である」という認識を持ち、他の関数との整合性に配慮する必要がある。

第5章　命名規則としての実装例

5.1 業務アプリにおける具体例

業務アプリケーションでは、関数の命名が処理フローやデータ構造に直結するため、設計段階で命名のルールを定義することが重要となる。たとえば、受注データから請求書データを生成する処理に対して「Invoice_From_Order」という命名を行えば、出力となる請求書の正確性と構造仕様に責任があることが明示される。

同様に、ユーザー入力を検証しログ形式に変換する関数には「UserInput_To_LogRecord」のようなA_To_B形式が適しており、入力データの流通と変換過程に注目した設計が反映される。このような命名は、保守時に関数の目的を即座に把握する助けとなり、ドキュメントレスな実装を実現する。

実際の業務現場では、こうした命名がそのまま業務フローや帳票仕様とリンクしているため、関数名が設計書と等価な役割を果たすことも少なくない。

5.2 プロジェクト単位でのルール化手法

関数命名に関するルールは、個人の裁量に委ねるのではなく、プロジェクト単位で明文化された規約として整備すべきである。これにより、開発メンバー間での表記揺れや命名判断のバラつきを防止し、関数群全体の整合性が保たれる。

具体的には、プロジェクトの初期設計段階で「命名規則ドキュメント」を作成し、使用する命名形式（A_To_B形式、B_From_A形式）、名詞の粒度、動詞の使用範囲、命名に含める業務用語の制限などを明示する。また、既存関数をリストアップし、典型的な命名パターンをサンプルとして共有することも効果的である。

さらに、命名規則の適用をコードレビュー項目に組み込むことで、実運用の中でも一貫性を維持できる。こうしたルール化の運用は、関数名を通じた設計思想の伝達を可能にし、属人化の回避にもつながる。

5.3 VBA／GAS／TypeScriptでの記述スタイル

関数命名のスタイルは使用言語に応じて若干異なるが、二名法を導入する基本原則は共通している。VBAではCamelCaseが主流であり、「CreateReport_FromSheetData」のように構文要素を明示する構造が望ましい。また、VBAでは関数単体の意図がより重視されるため、命名によって責任範囲を明確に示すことが特に重要である。

Google Apps Script（GAS）では、JavaScriptベースの命名規則が採用されており、lowerCamelCaseが一般的である。たとえば「sheetToJson」や「jsonFromSheet」のように簡潔かつ一貫性のある命名が求められる。

TypeScriptでは型情報と併用することで、命名の構造性がより高まる。型定義と連携させて「UserDataToReportData(input: UserData): ReportData」のように、関数名と型が相補的に意味を伝える設計が可能となる。

いずれの言語でも、命名における「方向性」と「責任の所在」を明示するという原則を守ることで、関数が果たす役割を設計上の要素として一貫して扱うことができる。言語固有のスタイルに従いつつも、設計意図を反映した命名を行うことが、実装全体の質を左右する重要なポイントとなる。

第6章　補論：副作用・双方向処理・冪等性との関係

6.1 関数の副作用と命名との整合

関数の副作用（side effect）とは、関数の実行によって引数の変更や外部状態への影響が発生することであり、命名と設計上の責任を一致させる上で重要な判断要素となる。副作用を伴う関数は、単なる変換ではなく「処理の実行」としての性格を持つため、命名にもそれを反映させる必要がある。

たとえば「Export_To_File」のような命名は、出力の目的と副作用（ファイルの作成）を明示しており、処理の実行によって環境が変化することを利用者に伝えている。一方で、「Json_From_Data」のような命名は純粋関数的（pure function）であり、データの変換結果を返すだけで外部には影響を与えないことが想定される。

副作用の有無は、関数の使用可否やテスト方針に影響するため、命名レベルでその性質を明示しておくことが望ましい。特に業務アプリケーションでは、誤って副作用を伴う関数を繰り返し呼び出すことが重大な不具合を引き起こす可能性があるため、命名を通じた責任の可視化が不可欠となる。

6.2 双方向変換（A ⇄ B）の表記戦略

データ形式や構造の相互変換を行う関数では、双方向性（bidirectional conversion）をどう表現するかが課題となる。特に「A_To_B」と「B_To_A」の両方が定義されている場合、それらをセットとして認識できる命名の一貫性が求められる。

たとえば「Xml_To_Json」「Json_To_Xml」のように対となる命名を用いることで、読み手はこの2つの関数が双方向の関係にあることを直感的に理解できる。また、関数が双方向に対応している場合でも、1つの関数に両方の機能を持たせるのではなく、方向ごとに関数を分離し、それぞれの責任を明確にする方が保守性・安全性の観点で優れている。

加えて、変換の可逆性が保証されない場合は、あえて双方向を匂わせる命名を避け、処理の主方向のみを示す命名に留めるべきである。双方向性を前提とした命名が誤解を招くと、意図しない誤用が発生する可能性があるためである。

6.3 冪等性と更新処理における命名の違い

冪等性（idempotence）は、同じ処理を何度繰り返しても結果が変わらない性質を指す。関数が冪等であるかどうかは、命名と設計の整合性を判断するうえで極めて重要である。たとえば「Ensure_Exists」や「Initialize_IfNeeded」といった命名は、処理が冪等であることを暗に示しており、再実行しても副作用が繰り返されないことが期待される。

一方、「Update_DB_Record」や「Insert_New_Entry」のような命名は、実行のたびに状態が変化する非冪等処理であることが明確に伝わる。命名により処理の性質が事前に把握できることで、使用者は安全な呼び出し方を選択しやすくなる。

冪等性のある関数は、再試行やリトライ処理との相性がよく、安定したアプリケーション設計に貢献する。そのため、命名によってその性質を明示しておくことは、関数設計における信頼性向上に直結する。

命名は処理内容の単なる記号化ではなく、処理の本質的な性質──副作用、方向性、冪等性──を正しく伝えるための設計言語であるべきである。

第7章　まとめと推奨規約の雛形

本稿では、関数命名におけるデータ方向性の設計という視点から、「A_To_B」と「B_From_A」という二名法形式を中心に、命名の意味論と設計責任の関係を明らかにしてきた。単なる命名規則ではなく、関数が担う役割や処理責任に即した設計上の判断基準として命名を捉えることで、関数名が設計意図を直接表現する構造へと昇華される。

第一に、関数が出力データの仕様に責任を持つ場合は「B_From_A」、入力フローや処理の発信に焦点がある場合は「A_To_B」を採用するという原則を明示した。この原則は、設計ドキュメントやコードレビューにおいて、一貫した判断基準として機能する。

第二に、命名における名詞の粒度や一貫性、双方向処理や副作用、冪等性との関係について補論的に整理し、命名が単なる形式ではなく、設計上の信頼性・可読性・安全性を担保する鍵となることを示した。

これらを踏まえた推奨命名規約の雛形は以下のとおりである。

推奨命名規約（雛形）

形式

• データ変換関数は基本的に「A_To_B」または「B_From_A」の形式を使用する。

• 双方向処理はそれぞれを明示的に分離する（例：Xml_To_Json / Json_To_Xml）。

責任基準

• 出力データの構造や整合性に責任を持つ関数は「B_From_A」形式とする。

• 入力データの発信や処理の起点に責任を持つ関数は「A_To_B」形式とする。

粒度と一貫性

• 「A」「B」に用いる名詞は同一レベルの粒度（Entity / DTO / JSONなど）に統一する。

• ドメインごとに許可される名詞のリストを設け、命名の揺れを防ぐ。

副作用と冪等性

• 副作用を伴う関数は、処理の影響範囲が明示される命名とする（例：Export_To_File）。

• 冪等性が保証される関数は、繰り返し実行に耐える名称を用いる（例：Ensure_Initialized）。

規約運用

• プロジェクト開始時に命名規約ドキュメントを整備し、命名パターンの例と禁止例を明記する。

• 命名規則をコードレビュー項目に含め、継続的な整合性を保つ。

本規約はあくまで雛形であり、プロジェクトの特性やドメイン要件に応じて調整・拡張されるべきである。ただし、命名の目的が「コードに設計意図を宿すこと」であるという基本姿勢を見失わないかぎり、どのような現場にも応用可能な設計原則として機能する。関数命名は、設計の可視化とチームの共通言語を実現する、もっとも重要な技術的表現である。