非IT事業会社がDXするのがどれだけ大変かを、リアルな体験を記録として残していくシリーズ。前回の記事はコチラ。

今回は、不動産開発とアプリ開発の比較を通して、「リアルでフィジカルのモノづくり」と「デジタル・ソフトウェアのモノづくり」の違いを表現したいと思う。

どちらが良い悪いということではなく、両方の経験を通して感じた違いが、非IT事業会社がDXを目指す上で大事なエッセンスが含まれているように思えたからである。

なお、比較材料を「不動産」「アプリ」としたのは、私自身が経験あるというだけの理由だけであり、この２つをリアルとデジタルの代表格のように扱うべきではないはないことを注記しておきたい。

ちなみに経験年数は、不動産は8年（開発４年・運営３年半）、アプリは2年（リリース前1年・リリース後1年）であるので、あくまでそのレベルの経験で感じたことだということ注釈つけておきたい。

まず、２つの象徴的な違いを、以下のように表現してみたい。

不動産は90%完成させて10%改善
アプリは10%完成させて90%改善

見る人が見れば当たり前なこの違いが、この２つの商材を扱う組織、人などにとって多くの根本的な違いに繋がっていると感じている。

開発スタイル

まずとてもわかりやすい点から。

ソフトウェア開発には「ウォーターフォール型」と「アジャイル型」があると言われているが、不動産開発に原則的に「アジャイル」というスタイルはあり得ない。

柱や梁を支える鉄筋・鉄骨、壁紙や塗装、什器に至るまで程度の差こそあれ、基本的には一度作ったもの、納品されたものをすぐ変えてしまうということは出来ないし、できたとしても費用対効果が悪すぎる。

そしてもう一つ重要な点は、不動産の場合は、生身の人間が使うため、少しの不具合が人間の体に物理的なダメージを与えてしまうリスクがある。

だから、「とりあえず作って顧客に提供してから改善しましょう」なんて有り得ないし、そもそも沢山の法律によって、安全性を担保するための基準が設けられており、それをクリアしない形でのサービス提供は法律違反になってしまう。

一方で、アプリは、初期開発はウォータフォールという形を取ることもあるが、基本的にはアジャイル開発（厳密いうと「細かいウォータフォール」と言えなくもないが）でないと上手くいかない、と実感している。

もちろん最低限満たさなければいけない基準はいくつかあるが、不動産ほどに細かく明確に決められた法律や基準があるわけではない。

この開発スタイル、モノづくりのスタイルの違いは、あらゆる面（組織、事業計画、意思決定）での考え方に大きな影響を及ぼすことになる。

成長曲線/ピークが来るポイント

不動産開発の場合「竣工（開業）」がとても重要なポイントになる。竣工前に顧客がその不動産を使うことはあり得ないし、竣工後に工事が始まることも基本的にはあり得ない（厳密にいうと修繕やテナント入れ替えなどは日常的にあるが）。

不動産にとって竣工・開業は、いろんな意味でピークを意味する。

工事が竣工することで、物件価値を算定するための収支計算の分母（初期投資）決まるし、物件価値も基本的には開業時がピークとなり、減価償却という形で帳簿上も価値は減少していく。

世の中へのアピール（PR）も基本的には竣工・開業がピークだ。そのため世の注目も基本的には開業時から下がっていく。開業を超える注目を集めるというケースはほとんど聞いたことが無い。

一方、アプリにはピークがいつ来るかわからない、という表現が正しいと思う。

基本的にはユーザー数などの成長曲線を上げていく努力になるが、何がティッピングポイントになるかは、仮説は持つことはあれど、あくまでユーザー側の反応次第という面があるのでコントロールすることはとても難しい。

そのため世の中へのアピールのタイミングも、不動産とは大きく異なる。ウェブサービスでは「プロダクト・マーケット・フィット」「グロース」という言葉があるが、言葉は何であれ、要は、顧客に認められる状態まで必死に頑張り、そのポイントまで来たら一気に広告して集客する、ということなのだが、そのポイントもピークかというと、そういう事でもない。

はっきりしているのは、成長曲線が下がり始めたら危ない、ということだ。

つまり、アプリにとってのピークは、あくまでユーザーの反応次第ということになる。

このあたりから、不動産は供給者都合の商材、アプリは需要者都合の商材、ということが理解されやすいかもしれない。

チーム/組織

ピークポイントからも分かる通り、それはチーム／組織の在り方も大きく変わってくることになる。

不動産の場合、竣工・開業というピークを境に、「開発」と「運営」がかなりハッキリと分かれているため、それを担うメンバーも基本的には異なることが多い。

職種が異なると言っても過言ではない。求められるスキルも基本的に異なる。

多くの場合、竣工・開業をきっかけに開発チームは解散し、その後、運営チームに引き継ぐという形式をとる。

そして人員としては竣工・開業前後がピークになり、基本的には開業後、徐々に人は減っていく（人件費を下げて効率を上げていくため）。

アプリの場合、ピークがないので、成長している以上、基本的には人員はどんどん増えていく。

そして、「開発」と「運営」という分かりやすい切れ目がなく、ずっと「開発・運営」なので、体制が一気に変わることはなく、役割が細分化して人員が増えていく、という構図になる。

おそらくだがアプリの場合、成長しているうちは人員に上限はないんだろうな、と思う。

また、リーダーの呼ばれ方にも違いがあり、不動産は開発リーダーを「プロジェクトマネジャー」と呼び、アプリは「プロダクトマネジャー」と呼ぶ。

ごくごくシンプルに言うと、前者のミッションは納期内に完成させることで、後者のミッションはアプリの目指すKPI（例えばユーザー数など）を最大化させることだ。

顧客との関係

顧客との関係についても大きな違いがある。

アプリは、顧客が離れたら成立しない商材だ。

「リテンション（維持率）」「チャーンレート（解約率）」などの言葉を一般的に使っているが、それほど顧客が使い続けるのかどうかが事業の生命線になるからである。

そのため、顧客の声を聞く活動や、一度使ってくれた顧客に対しての対応は非常に手厚い。不動産と比較すると顧客の声を聞く頻度も高く、ユーザーインタビューはアプリ開発においては核となる活動である。

また、アプリ業界では「カスタマーサポート」ではなく「カスタマーサクセス」という言葉が使われている。顧客の「支援」ではなく「成功」のための取り組み、と言うことだが、このあたりからも顧客との関係の違いは感じられる。

不動産ももちろん顧客は大事だが、私が知る限り、この業界でリテンションやチャーンレートなどの言葉を聞いたことがない。

この違いについて私なりの見解だが、不動産の場合は、そもそも開発する時点である程度マーケットが有るか無いかが想定できると言う側面があるのだと思う。

これは不動産は当たり前だが、物理的かつ動かない商材だ。そのため、その場所を使う人がおおよそ想定できる。近くに同じような物件があれば、それが参考になるし、周辺に住んでいる人がどう言う人かもデータとして把握できる。

あくまでイメージだが、不動産は釣り堀で、アプリは大海で釣りをしているような感覚である。

不動産の場合、釣り堀といっても良い釣り堀かどうかによって釣果は変わってくるので、その見極める力が重要になるし、一度良い釣り堀を確保できたら、比較的安定的に魚がとれるが、大漁ということはないし、釣り堀の選択をミスったらずっと良い魚が取れない。

アプリは大海の中である程度、レーダーで群れが居る位置は把握できるが、まず1匹目が針に引っかかるかどうかが肝であり、如何に着実に一匹目をとらえ続けらえるかが勝負になる。常に魚群は動くため、一匹目を捉えられる確率は低い。そのため、何度もトライアンドエラーを繰り返す必要がある。

そして、どれだけ効率的に群れを捉えることができるかどうかを試行錯誤して、魚の特性をつかめると物凄い量の魚が釣り上げられる、といった感じだ。

２つの商材のリスク度合いやボラティリティの違いが感じていただけるのではないかと思う。

ーーー

と、ここまで書いてきたが、まだまだ表現しきれていない違いはたくさんあるのでが、既に3000字に超えてしまったので、一旦ここまでにする。

それでも、同じモノづくりでも大きな違いがあることが分かって頂けると思うし、実際こうした違いへの理解が、非IT事業会社がDXを目指す上での大きな障害になっていると感じる。

上記以外にも、安全性に対する深刻度合い、事業の成否の決め手、企業としての事業の意思決定、リーダーに求められるべきこと、チーム内の開発上の意思決定の違い、職能、、、などなど語りたいことは沢山あるのだが、それは別の機会にしようと思う。