1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI と PL のジレンマ ─ 実装が1ヶ月になった時代のソフトウェア資産計上

1
Posted at

はじめに

私はハノイでソフトウェア開発会社を経営している。

現在は、私以外にエンジニアは在籍していない。以前はいた。

そして、私の会社で製造しているソフトウェアのほとんどは、実装自体は AI が行っている。
設計とレビューは私が行い、その結果として「実装に耐えうる」品質のソフトウェアは問題なく作れている。

AI によって、ソフトウェアの実装コストは劇的に下がった。その結果、ソフトウェアのライフサイクルを「短くする」という選択肢が、現実的になりつつある。

ただし、その選択は、ある規模以上の既存企業においては、会計・PL・資産計上という文脈で、かなり居心地が悪い。

そのあたりの違和感を備忘的に整理した。

AI コーディングの現在地

現時点では、AI はまだ「パイロットを選ぶ」という印象がある。
セキュリティやメンテナンス性、将来の変更可能性などを意識した設計を、十分なコンテクストとして与えないと、実用に耐えないコードが出てくることも多い。メンテナンス案件とは相性が悪い。

ただし、それも時間の問題だと思っている。
AI がパイロットを選ばず、一定水準以上の実装を安定して出力する未来は、そう遠くない。

とはいえ、正直に言うと、私自身は、AI による実装そのものに、ビジネス上そこまで強い関心を持っていない。楽しいからやっている、という側面は大きいが、「やらなければならない」とは思っていないし、それによって競争力が保てないとも思っていない。

理由は単純で、プロジェクトの成否において、実装の占める割合は驚くほど低いからだ。

実際には、

  • 要件定義・要件分析
  • テスト戦略
  • 運用設計

といった部分をどう設計するかの方が、はるかにビジネスインパクトが大きい。

そのため、開発効率向上を目的としたコンサル案件では、「AI を使わない」という選択肢はないと提案する一方で、実装に AI を使うよう積極的に指導することは、していない。

プロジェクトの成功・失敗が、実装や技術力にほとんど起因せず、不完全な要件定義が支配的であることは、各種調査や研究を見ても明らかだ。残念ながら。

完全な要件定義というイリュージョン

とはいえ、完全な要件定義が可能かと言えば、それは絵に描いた餅だ。
そんなことはできない。

現実的なのは、

  • ハードランディングしない要件定義
  • 前提が壊れることを織り込んだ設計
  • アジャイル的な修正ループ

だと考えている。全てはそれを認識することから始まる。

この前提に立つと(立たなくても)、AI によるコーディングは「MVP を作る」という目的において、非常に相性が良い。すでに現時点でも、パイロットを選ばず、動くものを安価に作ることは可能だ。

AI がメンテナンス性や設計意図をより深く理解するようになれば、MVP を超えた領域でも、低コストな実装が当たり前になるだろう。

ただ、私はもう一つ、別の方向性があると思っている。

メンテナンス不能上等、という選択肢

現在、日本の税務・会計の文脈では、自社利用のソフトウェアは、原則として 5 年で償却される。それに引きずられる形で、ソフトウェアのライフサイクルも「5 年程度」と想定されることが多い。

正直に言えば、5 年は長すぎて競争力を維持できないと感じる一方で、実際には 5 年以上使われているソフトウェアが多いのも事実だ。

ソフトウェア資産計上では、

  • 開発中の人件費などが仮勘定として積み上げ
  • 完成後、5 年で償却する

という形になるため、PL 上はコストが平準化され、一見すると見栄えの良い PL を作ることができる。

しかし、これまで 1 年かかっていた実装が、メンテナンス性はさておき 1 ヶ月でできるようになった時代に、ソフトウェアのライフサイクルを一律で 5 年とするのは、妥当だろうか?

  • 1 年のメンテナンスに耐えられれば十分
  • 極端には、次のリリースまで動けば良い
  • 問題があれば、修正ではなく作り直す

こうした「使い切り・作り直し前提」の方が、トータルコストでは合理的なケースも出てくる。特にスタートアップなどでは、この戦略がスピード面で有利に働くだろう。

AI サポート実装の PR で憤慨している先輩エンジニアが、そのままであれば窓際に移動する日が来るのは、世界中で無双するゆとり世代のアスリートたちを見れば、現実味がある。基礎を軽視して良いという話しではない。前提のシフトに適応できていないのが問題だ。冬の窓際は寒い。が、いまは大いに吠えるべきだ。

会計的に起こる違和感

さて、ただし、この運用に舵を切ると、会計的には別の現象が起こる。

1ヶ月で捨てる前提のソフトウェアは、もはや「無形固定資産」として計上することができず、即費用になる。

すると、

  • キャッシュは増えている
  • しかし利益は落ちる

という、一見すると奇妙な状態が生まれる。

経営としては健全であるとも言えるが、株主や従業員への受けは、必ずしも良くない。
利益 ≒ 配当原資という経営を続けてきた会社であれば、株主配当やボーナスが減ると見えるためである。

妥当であっても、PL 上の見え方によって受け入れられにくくなる、というギャップがここにある。

AI はインフラ

AI でコーディングしたところでビジネスへのインパクトはほとんどない。選択によっては PL を傷つけ反発が起こる可能性すらある。というようなことを書いたが、AI によるコーディングを否定したいわけではない。

AI によって、これまで個人や小さなチームでは手が届かなかった領域に、気軽に踏み込めるようになったことは、明らかに価値がある。

私自身も日常的に AI を使って実装しているし、従業員不要で、キックオフ時に MVP を提示できるのは、明らかな価値だ。AI コーディングを主戦場にする人がいても、何もおかしくない。その Practice が AI コーディングをより高い次元へと押し上げる。速いサイクルが新しい価値を生み出す。素晴らしい。

ただ、私の関心は、

「その後、どう使い、どう捨てるか

という部分だ。

もはや人類はインターネットを捨てることはできない。AI を捨てることも大きな後退になる。私はスケールさせるために AI を使っているので、なくても止まらないが、AI を捨てるような世界は望んでいない。便利なインフラを捨てる理由はない。

「あんたバカァ?」と言いたいのは、時代に合わないビジネスモデルやコスト構造だ。

AI は「特別な存在」なのか?

会計や監査の文脈では、AI によって新しいルールや知識が必要になる、という語られ方をすることがある。しかし、AI を「実際の社員だったら」と置き換えて考えると、実はそんなこともないということがわかる。

  • どこまでの権限を与えるのか
  • 何をしてはいけないのか
  • 誰が責任を持つのか
  • どの行為をログとして残すのか

これらはすべて、人間の従業員に対して、すでに考えてきたことだ。

OLD but GOLD.

AI に対して必要なのは、全く新しい会計理論や監査知識というよりも、これまで人に適用してきたルールの適用範囲に AI も含めること、ではないかと思っている。

従業員規定、権限設計、教育・研修、運用ルール。

それらの対象が一人、あるいは一つ、増えるだけだ。

直近では、OpenClaw, Moltbook などで、AI のインシデント事例がホットな話題だが、それは新しい問題というよりも、人間がすでに通ってきた対策(クレデンシャルを git にあげてはいけません、2ch は匿名でも訴えられますよ的な)が、まだ適用されていないだけのものが多いようにも見える。

既存企業の生存戦略

スタートアップであれば、このような短命ライフサイクルへのシフトは、比較的容易に導入できる。

一方で、既存企業、とくに規模の大きな企業では、PL へのインパクトから、妥当であっても受け入れにくい。ここがかつてのクラウドアレルギーとは毛色が違う。

そして、それは無視できる問題ではない。

最終的には、社内カンパニー制や機能子会社への分離などのテクニックになるような気はしているが、これは実行にも意思決定にも時間がかかる。遅れれば遅れるだけダメージを受ける。

現時点で、既存企業が「今のうちに」検討しておくべき論点は、少なくとも次のようなものだと思われる。

  • ソフトウェアの寿命を、前提条件として言語化できているか

どのソフトウェアは長期利用前提なのか。
どのソフトウェアは短命でも構わないのか。

これを暗黙ではなく、前提条件として整理できているか。それに合う設計・実装になっているか・向かっているか。

  • 正しさと、導入可能性は別であると認識できているか

短命な運用は妥当でも、全社 PL に直撃させると受け入れられないことがある。

隔離や段階導入を前提に考えられているか。

  • 競争に晒される領域を、既存の時間軸に縛っていないか

スタートアップと競合する領域では、試行回数とスピードそのものが競争力になる。

その領域が、既存の評価・会計の枠組みに縛られていないか。

  • AI を「効率化ツール」だけで終わらせていないか

AI は実装を早くするだけでなく、ソフトウェアの作り方、捨て方、投資回収の考え方を揺さぶる存在でもある。

その摩擦を、問題として認識できているか。

おわりに

AI によって「できること」は確実に増えた。しかし、組織や制度がそれを消化できるかどうかは、別の問題だ。

既存企業にとって重要なのは、今すぐ正解を選ぶことではなく、どこで前提が壊れうるのかを、いまのうちに把握しておくこと だ。

エンジニアは、迷わず突き進めば良い。楽しいし。ただ、達成された際に、AI を操作するスキルが AI に吸収されてコモディティ化した時に、あなたの価値は何なのかは考えておいた方が良い。

私は、AI というインフラの上に、何をどう設計し、どう運用し、どう捨てるのかを考えている。片っ端から Automated Waste を量産するのは、楽しくない。

おまけ(PR)

このような問題は、非エンジニア系 CSuite から出てくることは稀で、CTO/CIO が提言すべき内容である。しかし、日本の情報系企業の CTO/CIO 設置率は 16%(大企業でも23%)程度と低く、技術的に重要な意思決定が現場任せになっていることを表しているが、現場からの提言で、これがディスカッションのテーブルに乗るとも思えない。もちろんカルチャー次第だ。

企業は CTO/CIO が必要ないと思っているわけではなく、必要性を感じている会社は 50% 程度に対して、適切な人を確保できていないのが現状だ。人が足らないという点では、PM もだ。

理由は割と明確で、

  • 必要とするスペックを有する人が、ほぼ存在しない
  • 必要とするスペックに対して、オファーの桁が足らない

ドラえもんが机からひょっこり出てくることを期待する経営は健全とは言えない。そんな中現場の生産性だけを上げて、全力で違う山を登る。これが現代の典型的な負けパターンだ。

弊社ではそのようなサポートを提供している。興味があれば。
ぼく、どらえm…笑

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?