はじめに

こんにちは、 Gunosy Tech Lab 所属の hyamamoto です。昨日に引き続き Gunosy Advent Calendar 2022 の 16 日目の記事を書かせていただきます。昨日は社内で初めてビルドツール Bazel を導入した話というタイトルで Bazel の導入について紹介しました！モノレポに Bazel 導入を検討している方はぜひ読んでみてください！

さて、完全に私ごとで恐縮なのですが、今年はライフステージが変わるイベントが多くありました（大阪への移住、入籍、家の契約）。諸々を考慮した結果、注文住宅を建てることにしたのですが、その過程でソフトウェアエンジニアとしての知見が活かせると思うポイントがあったので、その話を書かせていただきます。今回はややソフトめな話になりますが、ぜひ読んでみてください！

家造りとソフトウェアエンジニアリング

家造りとソフトウェアエンジニアリングには以下のような類似点があると考えています。

類似点

ゼロから新しいプロダクトを作る
技術的に可能・不可能なことがある
QCD の観点を踏まえて仕様の策定が必要

一方で相違点としては次の内容が挙げられます。

相違点

エンドユーザーは自分たちのみ
出資者は 100% 自分
複数回のリリースによるトライアンドエラーが困難*1
技術や仕様に対する知見を自分たちは持っていない

以上を踏まえて考えると、注文住宅の依頼者は家造りに対する PjO, PdO であると考えられます。しかも、技術が分からない側として依頼を出す必要があります。いつもは技術が分かる側で、依頼に対してそんな仕様は厳しいと思うこともしばしばだと思いますが、今回は完全に逆の立場です。ワクワクしてきますね。

依頼者として行ったこと

以上の内容から、注文住宅の依頼者は QCD の観点を踏まえつつ必要なユーザーストーリーを洗い出し、それを開発者に適切に伝える必要があります。これに向けて今回私が行ったことをご紹介します。

コストの可視化

今回 Delivery の観点は考えなくていいので、まずは家を購入することによるローン支払いと長期的な資産を可視化しました。当たり前ですが家を建てた結果、生活が詰むという状況は避けるべきです。

最初は建築会社の方が紹介してくれた FP さんにライフプランの見積もりを出してもらいました。しかしながら、ライフプラン作成時に考慮するパラメータを自身でいじることができないため、改めて自分で見積もりを出してみることにしました。 FP さんの話を聞くまではどういうパラメータを考慮すべきかの検討がつかなかったため、まずは話を聞いてみてよかったと思っています。

今回考慮したパラメータは次のようなものが挙げられます。

年間の期待収入
毎月の住宅ローンの支払額
固定資産税
毎月固定で支払う必要があるものの額
- 食費、交通費、水道光熱費、保険料
年間で支払う必要があるものの額
- 旅行費
一定期間で発生する月々の固定費
- 子供が n 人いる場合を想定して、その子供が m 歳になるまでの期間の月々の固定費
  - 2040 年から 2045 年の期間は大学進学期間なので、月々の固定費が追加で 100,000 円必要になる
一定のサイクルで発生する年間の費用
- 車の買い替え
- 家の修繕費

上記のパラメーター設定を元に Python で以下のような可視化を行いました*2 *3。なお、資産運用による運用益や年金は考慮していない設定になっています。

この画像から以下の内容がわかります。

資産（左上）のグラフから、将来にわたって資産が黒字である*4
収支（左下）のグラフから、車の購入時や子どもの大学進学時など年単位で収支が赤字になる
- しかしこれは資産のグラフから許容できる
資産（左上）と支出（右上）のグラフから、老後は生活費によって資産が単調減少する

あくまでシミュレーションではあるものの、自分の過ごしたい生活水準とそれに対するコストを可視化することで、いくらまで家にお金を使っていいかの目安が見えてきます。厳し目の設定になってはいるものの、老後において 20 年間無収入で生活する難しさを感じました。将来的には、このシミュレーションを元にした予実管理機能を用意できたらいいなと考えています。

このブログのレビュー中に社内で教えて頂いたのですが、金融庁がライフプランシミュレーションのアプリを出しているみたいなので、こちらを試してみても良いかもしれません！

https://www.fsa.go.jp/policy/nisa2/lifeplan_sim/index.html

ユーザーストーリーの洗い出し

次にユーザーストーリーの洗い出しをパートナーと行いました。個人的にこの作業をやったことで、自身の脳内整理と担当者さんとのコミュニケーションの効率化に繋がりとてもよかったです。

当初は担当者さんに打ち合わせの中で五月雨に SNS などで見た間取りなどを伝えていました。しかしながら、そもそも自分たちの脳内でも達成したいユーザーストーリーが明確になっていないことに気づき、この結果コミュニケーションロスが発生していることを感じました。言い換えると間取りをこうしたいはあくまで要件であり、要求ではないということです。

togetter.com

コンセプトを考える

そこでまず、意思決定の基礎となるコンセプトを我々の間で洗い出しました。本当はインセプションデッキをやりたかったのですが、なかなか時間のかかる作業でもあるため、今回はパートナーとの間でのパッケージデザイン的な要素の洗い出しにつとめました。

話し合った結果、我が家では以下の内容がコンセプトとして決まりました。

非日常
- 日々の生活でも楽しさを感じられたい
老後まで住める
- コストをかけるからには長く住みたい
機能的
- 光熱費を抑えたい
- 修繕費を抑えたい
- 災害に強くあってほしい
犬と暮らす
- 飼っている犬がいるので共に生活しやすい環境にしたい

マインドマップを洗い出す

次に行ったこととしてマインドマップの洗い出しです。よくある話として How が What のように扱われてしまい、プロダクトにおける概念の階層構造が明確になっていないことがあります。今回の間取り整理でもこの現象が起きていたため、マインドマップを作成し自分たちの脳内における概念の階層化を行うことで、伝えたい要望を洗い出しました。以下が今回洗い出したマインドマップです。