アズビルが、2027年4月に強制適用される新リース会計基準を1年前倒しして早期適用し、その基盤にプロシップの「ProPlus リース資産管理システム」を使った、という発表が出た。制度対応の案件は、通常のシステム開発とは要件の性質がまるで違う。この記事では、報じられた事実を整理したうえで、期日が動かない案件をどう設計するかという観点で読み解く。
なお、会計基準そのものの解釈・適用判断は監査法人と会計士の領分である。本記事は基準の解説ではなく、システム側の作り方の話として書く。
要点
- 発表はプロシップ (ProShip) によるもの (2026年8月18日)。導入先はアズビル。
- 使われたのは「ProPlus リース資産管理システム」。
- 新リース会計基準の強制適用は2027年4月。アズビルはこれを2026年4月に早期適用した。
- アズビルは当期からIFRSを任意適用しており、IFRS 16 (リース) への対応と地続きの案件になっている。
- 稼働の順序は、2025年度にIFRS版が稼働 (並行開示期間)、2026年度に新リース会計基準版が稼働 (適用初年度)。
- プロシップ側はIFRS 16の導入実績を100件以上としている。売上1,000億円以上の企業を対象とした累計導入は2026年7月時点で366社。同社は366万円の日本赤十字社への寄付を予定している。
制度対応案件は「要件を自社で決められない」開発である
私がこの手の案件で最初に説明するのは、制度対応が通常のシステム開発と要件の出どころが違うという点だ。
普通の業務システムは、何を作るかを自社で決められる。優先度を落とす、フェーズを分ける、そもそも作らない、という選択肢がある。制度対応にはそれが無い。要件を決めているのは社外 (会計基準) であり、期日は法令側の都合で決まっていて、交渉の余地が無い。
この性質の違いは、意思決定の順序をひっくり返す。動かせないのが期日と要件なら、動かせるのはスコープと作り方だけになる。だから制度対応でスクラッチ開発を選ぶ判断は、よほど固有の事情がない限り筋が悪い。基準解釈の更新に自社でずっと追随し続けるコストを、自前で背負い込むことになるからだ。パッケージを選ぶということが機能比較ではなく業務を標準に寄せる経営判断である、という話はCaratLaneがOracle Fusionで基幹を入れ替えた事例にも書いた。
制度対応で本当に難しいのは、どの製品を選ぶかではなく、自社の契約データが基準の要求する粒度で揃っているかである。ここは製品では解けない。
早期適用を選ぶと、本番稼働が2回になる
今回の順序を私が興味深いと思うのは、IFRS版を先に動かし、その1年後に新基準版を動かしている点だ。つまり本番稼働が2回ある。
外から見ると二度手間に見えるが、実務としてはむしろ合理的だと考えている。IFRS 16 と新リース会計基準はリースの捉え方に重なる部分が大きく、先にIFRS側で契約データの棚卸しと運用の型を作れているなら、2回目は同じ土台の上で差分に集中できる。逆に、強制適用の期日ぎりぎりで初めて着手すると、契約データの整備と制度対応と本番稼働が同じ数か月に重なる。一番危険なのは工程が重なることであって、稼働の回数ではない。
早期適用を「先進的だから」と読むのは表層的だ。私の読みでは、これはリスクを時間軸に分散させる判断である。同じ理屈で、基幹システムの刷新も忙しさが理由で先送りするほど選択肢が減る。刷新の進め方は基幹システム刷新の必要性・進め方・失敗しないためのポイントに整理した。
制度対応で工数が膨らむのは、システムではなくデータの側
リース会計の対応で工数が膨らむ場所は、経験上ほぼ決まっている。会計処理のロジックではなく、契約情報の棚卸しである。
- 契約書が部門ごと・拠点ごとに保管されていて、全社の一覧が存在しない
- 賃貸借契約・保守契約・複合機・車両など、リースに該当するかの判定が必要な契約が散在している
- 契約の開始日・期間・更新条項・解約オプションが、システムに入力可能な形になっていない
- 過去の契約変更が契約書の原本にしか残っておらず、履歴がデータ化されていない
システムを入れる前に、この4つがどれくらいの件数あるのかを実数で数えておく。数千件あるのか数万件あるのかで、プロジェクトの形が変わる。製品選定より先に、契約の件数と保管場所を数えるのが最初の仕事である。要件の粒度を揃える一般的な手順は要件定義の進め方と5ステップの手順を参照してほしい。
繰り返しになるが、どの契約がリースに該当するかの判定そのものは会計上の判断であり、監査法人と協議すべき領域である。システム側でできるのは、判定に必要な情報を漏れなく集められる形にしておくことまでだ。
開発会社・SIerにとって、この案件が意味すること
同業として読むと、制度対応案件には他の案件と違う経済性がある。
- 期日が動かないので、着手が遅い顧客ほど単価が上がる。 ただしこれは受ける側にとって旨味であると同時に、失敗確率も上がる取引でもある。強制適用まで残り期間が短い相談を受けたときは、フルスコープを請けるより、契約データの棚卸しだけを先に切り出すほうが双方にとって安全だ。
- 戦う場所は実装ではなく、データ整備と業務設計。 会計ロジックはパッケージが持っている。付加価値は、散在した契約情報を集めて構造化する泥臭い工程にある。ここは業務システム開発で培った力がそのまま効く。
- 制度は一度で終わらない。 会計基準も税制も改正が続く。制度対応を起点に入った顧客とは、改正のたびに継続的な関係が生まれる。単発の請負ではなく、運用と改正対応をセットにした契約に落とすほうが合理的だ。
- 専門領域を持つベンダーとは正面から競合しない。 プロシップのように特定領域で100件規模の実績を積んだベンダーがいる領域で、汎用の開発会社が同じ土俵に立つ意味は薄い。周辺の連携・データ移行・既存基幹との接続に回ったほうが取り分は残る。パッケージと個別開発の役割分担は基幹システムとERPの違いと選び方の判断基準にまとめている。
まとめ
この事例から取り出せる実務的な教訓は3つある。制度対応は要件と期日を自社で決められない開発であること。早期適用は先進性ではなくリスクの時間分散として読めること。そして工数が膨らむのは会計ロジックではなく契約データの整備であること。2027年4月の強制適用に向けて動く企業は、製品選定より先に自社の契約を数えるところから始めるのが早い。
