ソフトウェアは組織である〜「所有か利用か」の次に来る、Software as an Organization

先日、ソフトウェアとは経営にとって何なのか、という話になりました。長く一緒に経営とソフトウェアに取り組んできたクラシコムの青木さんとの対話です。事業を動かす基幹システムを自分たちで作り、育て続けている会社で、私はそこでCTOを務めています。お互いに分かっているつもりでいたのに、いざ一言で言おうとすると、言葉が出てきませんでした。

道具、と言えばそうなのでしょう。ただ、道具と呼んだ瞬間に、使う人と使われるものに分かれてしまいます。買ってきて、置いておいて、必要なときに手に取る。ソフトウェアは、そうはいきません。動かし続け、直し続け、事業が変わればかたちを変えています。

サービスと呼ぶこともできます。Software as a Service という言い方は、すっかり定着しました。ただ、これは受け取る側から見た言葉です。作って、抱えて、変え続ける側から見た言葉が、まだありません。

その日は答えが出ませんでした。あとになって思ったのは、当てはめる言葉を探すより先に、比べる相手を間違えていたのではないか、ということです。ソフトウェアは、組織によく似ています。

ソフトウェアは、なぜ「完成」したことになるのか

理由の一つは、会計の扱いにあるように思います。ソフトウェアは、固定資産に計上されます。帳簿の上では、工場や建物と同じ列に並ぶ。何年かけて償却するかを決めて、時間とともに価値が目減りしていくものとして管理されます。

そうやってモノの側に置かれると、完成があるように見えてきます。工場なら、建ててしまえば、あとは動かすだけです。同じ感覚で、ソフトウェアも作り終えたら、あとは使うだけだと思ってしまう。

以前、システムは負債にも資産にもなると書きました。あれは帳簿の話ではなく、育て方の話です。会計上どう計上されようと、ソフトウェアが動き続けるものであることは変わりません。

作る側も、同じように考えています。緻密なスケジュールは引くのに、ロードマップを更新するという発想がない。完成させて引き渡すところまでが仕事だと考えていれば、そうなります。ソフトウェアを作る仕事は、長いあいだ製造業のかたちで語られてきました。

組織なら、こうはなりません。組織を固定資産に計上する会社はないし、「うちの組織は完成した」と言う経営者もいない。採用して、育てて、配置を変えて、制度を変えて、ずっとやり続ける。放っておけば緩んでいくことも、みんな知っています。

ソフトウェアについて言われてきたことは、そのまま組織について言えることでした。

技術的負債と組織的負債は、同じものだ

ソフトウェアには、保守性という言葉があります。あとから変えやすい状態を保っておくこと、と言い換えてもいい。機能が増えても、直したい箇所にすぐ手が届く。誰が読んでも、何をしているか分かる。目に見える成果とは別のところで、その状態を保つために手をかけ続けます。

放っておくと、その場しのぎの対応が積み重なって、あとから変えられなくなっていきます。技術的負債と呼ばれるものです。負債という言い方のとおり、溜まるほど身動きが取れなくなる。

組織でも、同じことが起きます。そのときは仕方のなかった特例が残り、例外に対応するためのルールが積み上がり、気づけば何かを変えようとするたびに、あちこちに断りを入れなければ動かなくなっている。以前、これを組織的負債と呼びました。

属人化も、どちらでも起きます。あの人がいないと回らない仕事が増えるのと、一人しか触れないプログラムが増えるのは、起きていることが変わりません。どちらも、書き残されていないこと、渡されていないことが原因です。

ソフトウェアには、内的品質と外的品質という分け方もあります。外的品質は、使う人から見える動きのこと。内的品質は、外からは見えない、変えやすさのことです。経営から見えるのは、たいてい外側だけになります。

組織も同じです。売上や成果は見えるけれど、人が育っているか、風通しがいいかは、数字に出てきません。内側への投資を後回しにしても、そのときは何も起きない。効いてくるのは、変えようとしたときです。新しい機能を足そうとして、あちこち直さないと入らないと分かる。新しい事業を始めようとして、任せられる人がいないと分かる。そこではじめて、後回しにしてきた年数が、まとめて表に出てきます。

ソフトウェアの品質特性は経営にも当てはまるのではないか、と以前に書いたことがあります。いま思えば、当てはまるのではなく、同じものを別の言葉で呼んでいただけでした。

構造が絡み合っているほど、伝えることと確かめることが増えていきます。『人が増えても速くならない』と一冊かけて書いたのはソフトウェア開発の話でしたが、組織でも変わりません。

経営がソフトウェアを設計するのは、必然になる

会社には、就業規則があり、稟議の仕組みがあり、決裁の順序があります。どれも、仕事のやり方を書き記したものです。誰が何をして、次に誰へ渡り、どこで承認されるのか。毎回ばらばらにならないように、決めて、書いておく。

ソフトウェアを作るというのは、これとほとんど同じことをしています。注文を受けてから届けるまでに何が起きるのか、どの数字をどこで確定させるのか、例外が出たら誰が判断するのか。決めて、書き記して、そのとおりに動かす。

違うのは、書いたものが自動で執行されるところです。就業規則なら、破ろうと思えば破れます。ソフトウェアに書かれていないことは、起きません。画面にないボタンは押せないし、通っていない経路は通らない。

そして、順序が逆になってきました。

DXという言葉で語られてきたのは、紙や人手でやっていた業務を、システムに移していくことでした。業務のかたちが先にあって、それを写し取るのが開発だった。いまは、ソフトウェアファーストという言い方があるように、ソフトウェアが先にあって、人がそこに乗って仕事をします。ネットの事業に限った話ではありません。店舗でも、工場でも、物流でも、ソフトウェアのないところに業務がなくなりつつあります。

そうなると、ソフトウェアをどう設計するかは、業務をどう設計するかと同じことになります。事業の組み立てを決めているのは、ソフトウェアの構造のほうだからです。

経営がソフトウェアの設計に関わるのは、だから必然です。人事制度を人任せにする経営者はいません。同じように、事業のかたちを決めているものを、外に預けたままにはできません。

経営とソフトウェアは、互いに決め合う

経営がソフトウェアの設計に関わると、決めるという行為が一方通行ではなくなります。

経営がソフトウェアを決めるのは、当たり前のことです。どういう事業にするか、どこで利益を取るか、何を捨てるか。決めたことが、そのままソフトウェアのかたちになります。

ソフトウェアの構造のほうが、経営の意思決定を縛ることもあります。

たとえば、購入の手続きを一段短くする機能を作るとします。作るかどうかを決めるには、その機能の良し悪しだけを見ていては済みません。手続きが短くなれば、買われる数はどれだけ増えるのか。支払いの確定するタイミングが変われば、売上をいつ立てるのかも変わる。在庫の引き当ても、問い合わせの受け方も、返品の扱いも動きます。

一つの機能を作るかどうかを考えることは、事業をどう組み立てるかを考えることと、同じでした。逆に、いまの作りでは入らないと分かれば、計画のほうを変えることになります。ソフトウェアが、事業計画の制約になる。

そして、動かした結果が返ってきます。ソフトウェアが動けば、数字が出る。何がどれだけ使われて、どこで止まっているのかが見える。それを見て、次を決める。

決めて、作って、動かして、また決める。この行き来が回っているとき、経営とソフトウェアは別々のものではありません。一体になっています。

そうなると、CTOの仕事は、作ることではないはずです。

技術を選び、設計を決め、動くものを作る。どれも要りますが、そこで閉じてしまうと、事業のほうから切り離せる役割になります。作って渡すところまでが担当だと決めた時点で、そこに納品が生まれる。

ソフトウェアの構造が事業の制約になるのなら、CTOは、その制約を経営の場に持ち込む人になります。この機能は入りますが、代わりに何を諦めますか。この作りのままだと、来期の計画はここで止まります。決める場で、それを言えるかどうか。

CTOの仕事は、動くシステムではなく作り続ける体制をつくることだと、以前に書きました。いま思えば、あれでもまだ半分です。体制をつくるだけでなく、ソフトウェアの側から経営の判断に関わるところまでが、その役割になってきています。

人の集まりだけが、組織なのか

ソフトウェアは組織に似ている、と書いてきました。逆にしても成り立ちます。組織も、ソフトウェアに似ています。ただの喩えなら、こうはなりません。

組織とは、人の集まりのことだ。長いあいだ、そう考えられてきました。その前提は、AIエージェントに仕事を任せはじめると、揺らぎます。

これまで人がやってきた仕事を、少しずつ代わってもらう。誰に何を任せるか、どこまで任せるか、うまくいかなければ渡し方をどう変えるか。AIエージェントを束ねる仕事は、組織のマネジメントによく似ています。人と組織のマネジメントが得意な人は、AIエージェントを使うのもうまい。

私たちも全社の標準として使っていますが、標準にするのは入り口を揃えるところまでです。使い方そのものは、現場ごとに変わっていきます。担当している事業が違えば、任せ方も、渡す情報も違ってくる。うまい使い方が見つかれば、それが広がっていく。

うまくいかないのは、導入して終わりにしたときです。ツールを配って、使い方を決めて、これで完了、としてしまう。使いながら使い方を変えていけるところがAIエージェントの面白さなのに、一過性の導入では、それごと捨ててしまうことになります。

こうなると、組織を人の集まりだと言い切るのが難しくなります。働き手のうち何割が人なのかは、これから会社ごとに変わっていくはずです。それでも、それを組織と呼ばなくなるわけではないでしょう。

Software as a Service から、Software as an Organization へ

組織という言葉の意味を、広げて考えてみます。人の集まりではなく、目的のために働くものたちの構造。そう置けば、人の集まりも、ソフトウェアも、同じ組織として扱えます。

ソフトウェアの持ち方は、これまで何度か変わってきました。かつては、各社が自前で作っていた。やがてパッケージ製品が出てきて、買ってきて入れるようになった。それがクラウドに乗って、Software as a Service、つまりSaaSになりました。所有から利用へ、という流れです。

では、その次に何が来るのか。

AIによって、内製できる範囲が広がりました。会計や人事のように、法や制度の変更に追いつく必要があるものは、これからも買ったほうが早い。ただ、自社のデータを収めて、自社のやり方で動かすものなら、自分たちで作って足りる場面が増えています。利用から、また所有のほうへ戻りはじめている。

問題は、その戻り先です。所有すると決めたときに、工場や建物と同じ持ち方をすれば、作って終わり、あとは償却するだけ、という扱いに逆戻りします。

だから、ソフトウェアを組織のように扱う考え方がいります。それが Software as an Organization です。

Service は、受け取る側から見た言葉でした。買って、使って、合わなければ乗り換える。Organization は、作り、変え、維持する側から見た言葉になります。

SaaSがなくなるとは思いません。買って使うほうが早いものは、これからも残ります。ただ、すべてをSaaSで揃える時代ではなくなってきました。自分たちで抱えるソフトウェアには、それにふさわしい言葉がいります。

組織もソフトウェアも、マネジメントに完了はない

マネジメントという言葉は、もともと進行形です。組織をマネジメントするというとき、いつか終わるとは誰も思っていません。人が入れ替われば手を入れ、事業が変われば形を変え、うまくいかなければ直す。それを続けることを、マネジメントと呼んでいます。

ソフトウェアも同じです。バージョンを上げることも、動かし続けることも、少しずつ良くしていくことも、どこかで終わる作業ではありません。

だとすれば、組織のマネジメントができている経営者なら、ソフトウェアのマネジメントもできるはずです。新しい何かを学び直す必要はない。すでに手の内にあるものを、対象を変えて使えばいい。

その逆も、すでに起きています。今年の6月、メルカリが、CTOだった方を最高人事責任者（CHRO）と最高AI責任者（CAIO）に就任させると発表しました。AIで開発が速くなっても、意思決定や組織のかたちが変わらなければ、その速さを活かせない、というのが会社の説明です。畑違いに見えるかもしれませんが、ソフトウェアと組織が同じものだとすれば、無理のない移り方でした。

会計が分からないまま経営するのは難しい、というのは、たぶん誰も否定しません。ソフトウェアも、それに近い位置まで来ていると感じています。事業がソフトウェアの上で動いているなら、そこが分からないままでは判断ができない。

ただし、プログラミングができるようになりましょう、という話ではありません。自分で書けたから分かるわけでもないし、AIに作らせられることとも違います。組織を見るときと同じ目で、ソフトウェアを見られるかどうかです。

かといって、技術は知らなくていい、ということでもありません。組織をマネジメントする人が、人のことを分からなくていいとは誰も思わないはずです。ソフトウェアも、中身への関心を手放したら、マネジメントにはなりません。

組織とは、ピープルソフトウェアである

私の持論ですが、ハードウェアでないものは、すべてソフトウェアだと考えています。形があって、触れて、置き場所がいるもの。それがハードウェアで、それ以外がソフトウェアです。

では、組織はどちらでしょうか。

組織に実体はありません。人が集まっているところを見ても、それだけでは組織とは言えない。机も建物も、組織そのものではない。役割があり、決めごとがあり、動き方があって、はじめて組織と呼ばれます。触れるものは、何もありません。組織には、ハードウェアがないのです。

だとすれば、組織もソフトウェアです。

ここまで書いてきた「ソフトウェア」は、正確に言えばコンピュータソフトウェアのことでした。それに対して、組織のほうはピープルソフトウェアと呼んでもいい。コンピュータの上で動くのか、人の上で動くのかが違うだけで、どちらもソフトウェアです。

最初の問いに戻ります。ソフトウェアとは、経営にとって何なのか。

答えは、組織です。そして組織もまた、ソフトウェアでした。別々の名前で呼んできた二つは、同じものだったのだと思います。

働き手が人でなくなっていくこれからは、その境目はもっと薄くなります。役割を切り分けずに全部を持つことも、渡して終わりにしないことも、組織について考えてきたことの延長にありました。ソフトウェアを持つというのは、もう一つの組織を持つということです。