ゆとり世代の中野です。

さっそくチャレンジについて書いていきます。

最近は実家の愛犬が約18年の大往生を遂げ、会うたびに老いてる親を見ると、健康に天寿を全うしてほしいなと思うようになりました。

また最近はフルリモートのため健康にも意識が向き始めました。

20代は不健康の極みとも言えるような生活をしていたので今後は自分のため家族のために健康寿命を延ばすようにしていきたいと思っています。

さて、今日は寿命について今の考えをつらつらと書いていきたいと思います。

とはいえ、人間の寿命ではなくProductの寿命。

Productの寿命とは？売れなくなった時？サ終？オワコン？

どれも正しいですね。しかし、今回フォーカスするのはアプリケーションの寿命の話です。

実はユーザの皆さんは知らないと思いますが、使っているそのアプリケーションはもう寿命かもしれません。

それではアプリケーションの寿命とはなにか？寿命がきたらどうなるのか？について書いていきたいと思います。

みなさんは日々様々なProductを触っています。

それはスマホのゲームやチャットツールかもしれませんしECサイトかもしれません。

日々みなさんが触っているProductはプログラミングされて実現されています。

ここでは便宜上アプリケーションと明記するようにします。

アプリケーションを構成しているのはざっくりいうとはデータとロジックです。

このデータをストックしているのがデータベースです。

そして、そのデータを活用するために様々なロジックを組み合わせてアプリケーションは皆さんの実現したいことを実現してくれています。

しかし、このデータベースとアプリケーションはライフサイクルの違いがあります。

一般的にデータベースはアプリケーションよりも長寿であると言われています。

何故データベースは長寿なのかというと、データベースに貯めたデータはアプリケーション以外のところでも使うことができます。例えば条件に一致するユーザにだけDMを飛ばしたいやよく使っているユーザの属性を抽出しそういうユーザがいるチャネルに広告を出稿するなどデータは色々な使い方ができます。

一方アプリケーションはデータを活用し特定のバリューを提供することが目的になっています。

誤解を恐れずに言えばアプリケーションはデータベースの窓口になっているとも言えます。

つまりアプリケーションがいなくてもデータベースは活用する方法が多岐に渡りますが、アプリケーションはデータがなければできることは限定的になってしまいます。

そのためデータベースのほうがアプリケーションよりも長寿と言われています。

では、何故アプリケーションはデータベースよりも寿命が短いのかについて考えていきたいと思います。

アプリケーションを車、ドライバーをビジネスマンとしましょう。

日々紫外線を浴び雨風に晒されいくと車は痛みます。

これらは外的要因です。

例えば、使っている技術のサポート切れや使ってるSaaS都合の障害などです(あげだしたらきりないので)

また、荒い運転や急発進急ブレーキばかりを繰り返してると車は痛みます。

こちらは内的要因です。

例えば、急なビジネスのピボットやスピード優先でやってほしい作業などよく組織内で上がってくる依頼などです(こちらもあげだすときりないので)

さて、これらの過酷な環境を日々走る車はメンテナンスが必要な状態です。

しかし、車は止まるのを許されていません。

今度はドライバーからこれらをつけてほしいとカスタムの依頼が来ます。

例えば、明日までに○○できるようにしてほしいや外部のサービスと連携してこういうことを実現してほしいなどです(こちらもあげだすときりがないので)

しかし、レースは白熱しています。まだまだピットには戻れそうにないです。

なんとかレースに勝つために形だけでもと思い取り付けます。

そうした過酷なレース中にドライバーが気づきます。

ドライバー「あれ？カスタム速度が落ちてないか？」

整備士「すみません。まだまだ時間がかかりそうです。」

悪いことは重なります。

ドライバー「おい、エンジンが止まったぞ！」

整備士「エンジンが壊れました」

アプリケーションは外的要因と内的要因の変化に加えビジネスロジックの複雑性も持っています。

さらに、ここには暗黙知や歴史的背景に様々なトレードオフの負債があり、合わせて返済ができないほどの技術的負債があることが容易に想像できます。

それらが複雑に絡み合い互いに依存関係を持ち紐付けない状態になりにっちもさっちもいかなくなった時、それがアプリケーションの寿命ではないでしょうか。

当たり前ですが、銀の弾丸はありません。

多くの場合これらの問題と対峙しているのはおそらくエンジニアだけでしょう。

あれをやればこれをやれば小手先のテクニックはたくさんありますが

もっと大きなスキームで課題の本質を捉え改善していく必要があります。

それはビジネスサイドを巻き込むことです。

まずは技術のトレードオフの理解を理解してもらう必要があります。

「早くしてほしい。」「急ぎなんだ。」「すぐにいる。」「なるはや。」

これらの言葉を使う人達に特に理解してもらう必要があります。

まず、速さは寿命とのトレードオフであること

これを早くだすことでどれぐらいビジネスで跳ねるのか聞きましょう。

言いなりになるのではなく対等な関係をお互いに作っていきましょう。

時にはエンジニアがドライバー席に座ってみる必要もあると思います。

何故その要望があがってきたのか何故急にそんなことを言われるのか。

座ってみてはじめてわかることもきっとあると思います。

彼らはモンスターではなくチームメイトです。

相互理解を深める必要があります。(お互いにリスペクトを忘れずに)

さて、前回はエンジンが壊れ複雑に絡み合っており修理が出来ませんでした。

今回は壊れない車を作って欲しいと言われています。

しかし、次のレースも過酷であり前回より困難な戦いになることを告げられます。

安心して下さい。優秀な先人たちがそんなレースでも戦える車を作る方法を残してくています。

市場は日々姿かたちを変え、求められているものも変わります。

それらに素早く適用し対応できる必要があります。

それは強いチームを作ることです。

チームは誰かの指示を待つのではなく自分たちで考え自分たちで勝てる車を作ります。

時には失敗もしながら、それすらも糧として必ず実現してくれるはずです。

彼らはチームでビジネスを理解しコードで表現します。

そうして最低限の機能を持った車にドライバー飛び乗り過酷なレースに参戦します。

レースの過程でより多くのフィードバックを整備士に伝えるでしょう。

彼らはもう対等な関係です。何が必要か何をするべきかお互いがやるべきことを理解しています。

日々アップデートされていく車で着実に順位をあげていきます。

古い車も新しい車も同じアプリケーションです。何が変わったのでしょうか。

それは新しいアプリケーションは無闇矢鱈に作ることをやめています。

アプリケーションで解決したい課題にフォーカスしており対等な関係性を構築しています。

そして、あらゆることを想定して設計を考え直し、現在のレースのスピード感に耐えうる設計にしたようです。

以前は10年先も耐えれるアーキテクチャを採用していたようですが、今回は簡単に捨てれるアーキテクチャにしたようです。

過酷なレースは取り巻く環境がすぐに変わるため懸命な判断だと思います。

それに合わせてドメインごとにそれぞれチームを作り担当するようにしたようです。

以前はデータベースに依存する形でアプリケーションを作っていましたが、現在は自分たちで落とし込んだドメインロジック群がアプリケーションになっています。

関心事と責務の分離に成功しているため多くの外的要因で力技で対応していた変更がなくなり、内的要因の多くを未然に防ぐことに成功しています。

しかし、突然別れはやってくるものです。

エンジンを担当していたチームが事故に巻き込まれてチームを去ることになりました。

おそらく抜けた人数分だけあなたは人員を補給するでしょう。

彼らは非常に優秀でした。エンジンだけを差し替えれば動くように作っていたのでした。

そう、彼らは知っていたのです。ドメインロジックのモデリングがチームよって変わることを。

再編成したチームでエンジンを切り盛りしますがなかなか思ったようにいきません。

彼らには彼らなりに見えている世界があり既存のロジックと噛み合っていませんでした。

そこで、彼らなりにモデリングし直し古いエンジンから新しいエンジンに差し替えます。

それまでドライブしていなかったチームが急にドライブしはじめました。

新エンジンチームは既存のコードを捨て新しくモデリングしなおしエンジンを差し替えました。

これは旧エンジンチームがこうなる未来を想定していたからですね。

何はともあれレースは続行できそうです。

さて、本題に戻ります。

生物のように脳死や心肺停止など明確な線引があるわけではないのでアプリケーションの寿命を明確に定義するの実はとてもむずかしいことです。正しく見極めることは非常に困難だと思っています。

そこで、ドメイン知識を持ったチームをアプリケーションの健康寿命と定義するようにしました。

チームが解散したり変わっても以前と同じようにおそらくアプリケーションは動き続けるでしょう。

しかし、以前と同様に市場の変化に追随していけるとは限りません。

健康寿命を迎えたタイミングでチームが担っていたアプリケーションを作り直す必要も出てくると思います。

またそうなった時を見越して旧エンジンチームが作ったように差し替えれるように作る必要があります。

色々な可能性と選択肢は健康寿命がある時に行い正しい取捨選択で不確実性の波を超えていきたいですね。