JA
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
한국어Business Central ALアプリ開発をわかりやすく：オフィスビルのたとえ
By Mirko Peters ·
現代のビジネスを運営するうえで、基幹業務システム（ERP）は日々の業務の中心にあります。Dynamics 365 Business Centralのようなプラットフォームは、財務、顧客管理、在庫、受注、請求書まで、標準機能ですぐに対応できます。しかし、実際の業務プロセスが標準機能にぴったり合うことはまれです。標準アプリケーションにない承認ステップ、追加のデータ項目、独自の計算、業務ルールが必要になった場合はどうすればよいでしょうか。長い間、ERPをカスタマイズするということは、必要な機能を実現することと、将来のアップグレード失敗という悪夢に自らをロックインしてしまうことの間で、危うい綱渡りをするようなものでした。現在では、最新の開発アプローチによって状況は根本的に変わっています。このブログ記事では、Microsoftの最新の拡張モデルの背後にある考え方を解説し、ALによる開発の基本的な構成
Automatically translated with AI from the original post. Read the English original
現代の企業を運営するうえで、ERP(統合基幹業務)システムは日々の業務の中心にあります。Dynamics 365 Business Central のようなプラットフォームは、財務や顧客管理から在庫、販売注文、請求書まで、標準機能で幅広く対応します。しかし、実際の業務プロセスが標準機能にぴったり収まることは、ほとんどありません。たとえば、特別な承認ステップ、追加のデータ項目、独自の計算、標準アプリケーションにはない業務ルールが必要になった場合はどうすればよいのでしょうか。以前は、ERP システムをカスタマイズするということは、必要な機能を実現することと、将来のアップグレードで深刻な問題が起きることを避けることの間で、危うい綱渡りをするようなものでした。しかし現在は、最新の開発手法によって状況が根本的に変わっています。このブログ記事では、Microsoft の最新の拡張モデルの考え方を解説し、AL 開発の基本的な構成要素を見ていきます。そして、カスタムコードを標準アプリケーションから分離することが、安定し将来にも対応できる ERP を実現する最も重要な鍵である理由を説明します。
なぜ企業はERPをカスタマイズするのか
開発の仕組みを説明する前に、そもそもカスタマイズが必要な理由を理解しておくと役立ちます。Business Centralには、多くの伝統的な企業によく合う標準的な業務プロセスが幅広く用意されています。しかし、同じ運営方法の組織は二つとありません。たとえば、専門の食品卸売業者では、基本的な在庫管理を超える厳格なロット追跡や消費期限の管理が必要になる場合があります。地域のサービス会社では、請求書を確定する前に社内の承認プロセスを追加する必要があるかもしれません。専門小売業者では、きめ細かな顧客向けのリワードのランクやロイヤルティの追跡が求められることがあります。
こうした固有の要件があるからといって、業務プロセスを全面的に作り直したり、ERPを手放したりする必要があるわけではありません。多くの場合、必要なのは、Business Centralに追加のデータを一つ理解させることや、特定の社内チェックルールを一つ適用させることだけです。これまでの課題は、システムの根幹の整合性を損なうことなく、こうした変更を安全に実装する方法でした。
最新の拡張機能のためのオフィスビルのたとえ
技術的な専門用語に惑わされずに最新の開発の仕組みを理解するには、Business Centralを、専門的に設計された大きなオフィスビルとして想像すると役立ちます。従来のERP開発モデルでのカスタマイズは、耐力壁を無造作に取り壊し、コンクリートの床に新たな穴を開け、新しい部屋がほしくなるたびに独自の配管を建物の主要インフラに直接つなぎ込むようなものでした。すぐに欲しい部屋は手に入るかもしれませんが、建物の維持管理は非常に困難になります。元の施工会社が屋根の改修や基礎の近代化に来るたびに、独自の改造が更新作業と衝突し、高額で負担の大きい問題が発生していました。
Microsoftの拡張モデルは、この構造を根本から変えます。オフィスビルのたとえでは、Microsoftが主要な構造、つまり基本フレームワーク、安全基準、設備、標準のオフィスを維持します。組織に追加のスペースやカスタマイズした機能が必要になった場合、建物の内部フレームワークには手を加えません。代わりに、建物の外側にある承認された接続ポイントに安全に取り付けられるモジュール式のアドオンを構築します。独自の機能は、標準アプリケーションのすぐ隣に、独立した自己完結型のユニットとして配置されます。Microsoftはいつでも主要な建物をアップグレードでき、独自のアドオンは安全に無傷のまま残ります。
ALと拡張モデルの理解
ALは「Application Language」の略です。Dynamics 365 Business Central専用のカスタム機能を開発するためにMicrosoftが作成した、専用のプログラミング言語です。ALを使うと、開発者は業務プロセス、計算、検証、レコード、ページを追加、変更、拡張できます。
AL言語の構文そのものよりも大切なのは、拡張機能モデルというアーキテクチャの考え方を理解することです。古いバージョンの製品、特にDynamics NAVのレガシーなC/AL開発環境では、開発者が標準のアプリケーションオブジェクトを直接変更することがよくありました。これにより深いカスタマイズが可能になった一方で、基幹システムとカスタムコードが強く結合してしまいました。Microsoftが更新プログラムを公開するたびに、開発者は元のソースコードと変更箇所を手作業で比較し、整合させる必要がありました。最新のAL拡張機能モデルは、変更を標準のアプリケーションコードを上書きするのではなく、その横で独立して動作する拡張機能としてパッケージ化することで、こうした手間を解消します。
まずは標準機能、カスタマイズは後で
Business Centralはカスタマイズできるからといって、必ずカスタマイズすべきとは限りません。従来のソフトウェアと比べて既定のワークフローが少し違うというだけでシステムを変更すると、不要な長期的保守の負担が生じかねません。ERPの運用におけるベストプラクティスは、「まず標準機能、カスタマイズは後で」という考え方に基づくべきです。
AL のコードを1行でも書く前に、開発チームと経営層は3つの基本的な問いを立てるべきです。従業員が実際に直面している問題は何か。その代わりに何が起こるべきか。業務プロセスを調整すれば、標準のBusiness Centralで既に解決できないか。AL開発は、標準製品では重要なビジネス要件を本当に満たせない場合に限って行うべきです。
AL の主要な構成要素
拡張機能を開発する際、開発者はオブジェクトと呼ばれる特定のプログラミング要素を扱います。オブジェクトとは、特定の役割を担うようアプリケーションの中で独立して設計された部品です。ここではALソリューションを構成する主要な構成要素を見ていきましょう。
テーブル、フィールド、ページ
テーブルは、Business Centralのデジタルなファイルキャビネットとして、データを安全に保存する役割を担います。顧客テーブルには顧客情報、品目テーブルには在庫情報が格納され、トランザクションテーブルは販売伝票を扱います。これらのテーブルの中には、氏名、住所、電話番号、日付などの個々の属性であるフィールドがあります。
しかし、データベースのテーブルにデータがあっても、従業員がそれを操作できなければ役に立ちません。そこで登場するのがページです。ページは、Business Central内の画面表示やユーザーインターフェイス画面を定義します。顧客カードは1件のレコードの詳細を表示するページであり、一覧ページは複数のレコードを一目で確認できるように表示します。テーブルがデータを保存し、ページがそのデータをユーザーに提示する、という関係です。
テーブル拡張とページ拡張
標準のBusiness Centralがほぼ必要な機能をすべて備えているものの、たとえば顧客ごとのカスタムロイヤルティ特典レベルといった追加のデータ項目が1つだけ必要な場合はどうでしょうか。既存の基本データを複製した新しい顧客テーブルを一から作るのではなく、開発者はテーブル拡張を作成します。標準の顧客テーブルには手を加えず、拡張機能によって新しいフィールドを追加するだけです。
もちろん、テーブルにフィールドを追加しただけでは、従業員の画面に自動的に表示されるわけではありません。これを解決するために、開発者はページ拡張を使用します。ページ拡張は、新しいフィールドに加えて必要なグループ、アクション、ボタンを、標準のBusiness Centralのユーザーインターフェイス画面に直接組み込みます。従業員は使い慣れた標準のページで作業を続けられ、拡張機能が必要な専用データをその画面にスムーズに表示します。
コードユニット、トリガー、イベント
データの保存とユーザーインターフェイスは重要ですが、アプリケーションには値を計算し、ワークフローを処理するためのロジックも必要です。コードユニットは、この再利用可能なビジネスロジックを集約する場所を提供します。たとえば、顧客の特典レベルによって特定の割引率が決まる場合、その計算コードを複数のページやレポートに無理に重複させるのではなく、一元化されたコードユニットに置くことができます。
アプリケーションのライフサイクルには「トリガー」と呼ばれる特定のポイントがあり、コードはそのポイントで実行されます。トリガーは、ユーザーがページを開いたとき、フィールドの値を変更したとき、請求書の転記を実行しようとしたときなど、特定の操作が行われると自動的に起動します。同様に、イベントを使うと、拡張機能は標準アプリケーションが発行する通知を受け取ることができます。たとえば Business Central が伝票の転記直前であることを通知すると、拡張機能はそのイベントを即座に捕捉し、適切なタイミングで独自の検証ロジックを実行できます。
まとめ: ERP をアップグレード可能な状態に保つために
基幹業務システムのカスタマイズは、もはやアップグレードを壊すリスクの高い作業である必要はありません。Microsoft の最新の拡張機能モデルを採用し、AL 開発の力を活用することで、組織はコアアプリケーションを完全にクリーンで安定した状態に保ちながら、Business Central を自社固有の業務ニーズに合わせて調整できます。ERP を、カスタム機能が内部の構造を取り壊すことなく外部に安全に接続される、よく設計されたオフィスビルのように捉えることで、ビジネスは俊敏さと効率性を維持し、今後のすべてのソフトウェア更新に十分備えることができます。
このトピックをさらに深く掘り下げ、最新の開発手法に関する専門家の見解を聞くには、関連するポッドキャストのエピソード Dynamics 365 Business Central AL Development をぜひご覧ください。