「クラウド費用が前年比で三割増えました」。情報システム部門の予算説明を聞きながら、止める理屈が出てこない。使っているのは事業部門で、契約しているのは情シスで、費用は全社の一般管理費に乗っている。誰も嘘をついていないし、誰も無駄だとは言っていない。ただ、増やす判断をした人の損益には、その費用が一円も乗っていない。IT費が止まらない会社で起きているのは、価格の問題ではなく、費用と決定権の住所が違うという問題である。
情シスという箱は、開示の世界には存在しない
企業会計基準第17号第6項は、事業セグメントの要件を三つ置いている。収益を稼得し費用が発生する事業活動に関わるものであること。最高経営意思決定機関が資源配分の意思決定と業績評価のためにその経営成績を定期的に検討するものであること。分離された財務情報を入手できるものであること。
なお同項にはただし書きがあり、新たな事業を立ち上げたときのように現時点では収益を稼得していない事業活動を事業セグメントとして識別する場合もあるとされる。だが情シスはこの例外ではなく、第7項で明示的に外される側だ。
ここから言えることは一つに絞られる。情シスの費用は、配賦しない限り、どの事業セグメントの損益にも現れない。 配賦していない会社では、予算査定は情シスの中で完結し、IT費が増えても事業利益は一円も減らない。事業側に止める動機がなく、増やす動機だけがある。
第23項の「合理的な基準」は開示の話であって管理会計の話ではない、と読む人がいる。逆である。同項の前段は、開示は最高経営意思決定機関に報告される金額に基づいて行わなければならないとしている。マネジメント・アプローチだから、社内で配賦をやめれば開示からも消える。社内で見ないと決めた瞬間に、外からも見えなくなる。 それでいいのかを、まずCFOが決める。
増え続ける理由は、クラウドが資産にならないことにある
止まらない構造の正体は、会計処理の非対称にある。
サーバとソフトウェアを買う判断は、三段の関門を通る。稟議、資産計上、そして償却である。研究開発費等に係る会計基準四3（自社利用のソフトウェアに係る会計処理）は、社内利用のソフトウェアについて「その利用により将来の収益獲得又は費用削減が確実であると認められる場合には、当該ソフトウェアの取得に要した費用を資産として計上しなければならない」とする。税務上の耐用年数は、減価償却資産の耐用年数等に関する省令の別表第三で定められ、複写して販売するための原本または研究開発用のものが3年、その他のものが5年である（国税庁No.5461 ソフトウエアの取得価額と耐用年数）。金額が大きいほど関門は厳しくなり、その全部が投資の意思決定として記録に残る。
クラウドはこの三段を通らない。稟議の単位は契約だが、費用は使用量で動く。契約時に承認した金額と、翌年に請求される金額が別物になる。承認したのは契約であって、金額ではない。 ここが統制の穴になっている。設備投資であれば承認後の膨張を止める仕掛けを置くのに（設備投資予算の執行管理｜承認後に膨らむ工事費をどこで止めるか）、クラウドには相当する関門が置かれていない。
なお、SaaSの導入時に発生する設定やカスタマイズの費用を資産として認識できるかは国際的にも論点で、IFRS解釈指針委員会は2021年にIAS第38号に関するアジェンダ決定（Configuration or Customisation Costs in a Cloud Computing Arrangement）を公表している。日本基準で運用している会社でも、向いている方向は同じだ。クラウドに移すほど、資産計上を伴う投資の判断は減り、月次費用の判断が増える。
単価は情シスが固定し、消費量は事業が動かす
単価の作り方は、サービスカタログを一枚作るところから始まる。1ユーザー1か月あたり、仮想サーバ1台1か月あたり、保管1テラバイト1か月あたり。粒度は五つか六つで足りる。そして単価は年度の初めに固定し、期中は動かさない。 標準原価と同じ考え方で、期中に動かすと事業側は自分の消費量を管理できなくなる。
消費量は、取れるところから取る。クラウド事業者が用意しているコスト配分タグ、SaaSのライセンス割当先、ID基盤に登録された所属部門。取れないものは配らない。推計で割った瞬間に、その配賦は毎年の交渉ごとになる。
単価と消費量の積を合計しても、実際にかかった費用とは一致しない。差額は情シスに残す。使われなかった容量、想定を外した単価、契約の最低利用料。この差額が情シスの成績になる。事業に押し付けた瞬間、情シスの調達の巧拙は誰にも見えなくなる。 製造原価計算で操業度差異を製造部門に残すのと同じ構造だ（原価管理の基本｜製造原価を「意思決定に使える」形にする）。
配賦の技術そのものは、ERPの標準機能で組める部分が大きい（SAPの配賦（アロケーション）設計｜共通費を「納得感のある基準」で割る）。詰まるのはいつも技術ではなく、何を配って何を配らないかの合意である。
配賦基準は、毎年いじれない
配賦の設計をやり直すたびに、事業別の損益は不連続に動く。社内の話で済むと思っているなら、第24項をもう一度読む。
第24項(5)は、事業セグメントの利益（又は損失）の測定方法を前年度に採用した方法から変更した場合に、その旨と変更の理由と影響の開示を求めている。配賦基準の変更は、社内の運用変更ではなく開示イベントである。 毎年いじる前提で設計してはいけない。
第24項(6)も効く。資産の配分基準と、関連する収益または費用の配分基準が異なる場合には、その内容を開示しなければならない。例示は、償却資産を事業セグメントに配分していないのに、その減価償却費だけを当該事業セグメントの費用に配分する場合である。自社サーバを全社資産として持ったまま、そこから出るIT費だけを事業に配ると、この形に近づく。
ここにクラウド移行の副次的な利点がある。クラウドは資産を持たないので、資産の配分基準と費用の配分基準がずれる論点そのものが消える。移行の投資判断でここを勘定に入れている会社は少ない（RISE with SAPとオンプレ・自社運用の選択｜クラウド移行をどう決めるか）。
配ってはいけないIT費が、必ず一定量ある
全部を配ると設計は必ず失敗する。IT費は三つに分かれる。
第一に、事業が消費量を決められるもの。業務システムのライセンス、事業が使うクラウド資源、事業固有の外部サービス。ここは配る。第二に、全社の意思で入れているもの。セキュリティ基盤、内部統制のための仕組み、監査対応、全社ネットワーク。ここは配らずCFOまたはCIOの直下に残す。第三に、過去の判断の残骸。使われていないのに解約されていない契約、移行が途中で止まったまま二重に走っている環境。ここも配らない。
理由は分けて考える必要がある。第二を配ると、事業長は自分で動かせない費用で評価される。評価に納得がいかないから、翌年の予算会議は配賦基準の議論になり、本題の投資判断に時間が回らなくなる。第三を配ると、費用が薄く広く散るので誰も廃止を言い出さない。残骸は、配らずに一箇所へ集めて金額を見せたときにだけ消える。
IT予算を、見積りから請求書に変える
情シスの予算説明が毎年つらいのは、あれが見積りだからだ。来年これくらいかかると思います、という話に、事業側は反論の材料を持たない。持たないから、金額の水準だけが議論になる。
配賦の設計を入れると、この会話が請求書に変わる。あなたの事業は先月これだけ使った、単価はこれ、だからこの金額。見積りは交渉の対象になるが、請求書は行動の対象になる。 事業側にできることは、値切ることではなく、使用量を変えることだけになる。
着手は契約の棚卸からになる。契約単位で一覧を作り、消費量を誰が決めているかを一列書く。単価表を五、六本作って年度で固定する。消費量が機械的に取れるものだけを配賦の対象にする。全社基盤と残骸は配らずに集める。そして配賦基準は、年度の切れ目にしか動かさないと決めておく。人件費を要員計画と結んで判断できる形にしたのと、やっていることは同じである（人件費の管理会計｜要員計画と人件費予算をつないで増員を数字で判断する）。
