伊藤さんの近況報告
1ヶ月ぐらいブログの更新が空いてしまいました。
子どもの卒業式・入学式や町内会の役員仕事やら、あれこれ用事が重なってゆっくりブログを書く時間がない今日この頃です。
ブログを書く時間がない理由のひとつに、家のリフォームがあります。
ふと思い立って、伊藤さんちでは現在、自宅の風呂、洗面所、トイレ、キッチンと、水回りを一通りリフォームしてしまおう！という計画が進んでいます。
今住んでいる自宅は築13年ですが、現状、特にどこか具合が悪くなった部分があるわけではありません。
じゃあなんでリフォームするのか？というと、理由は大きく分けて3つあって、
- 新築当時は予算がなくて、水回りは平凡な風呂やトイレしか選べなかった
- 家の設計をしていた当時は妻が長女を妊娠していた時期に重なっていて、つわりのせいで打ち合わせにあまり参加できず、妻のこだわりを十分反映できなかった
- 長男が高校生になり、あと3年ぐらいしたら大学進学で家を出て行く可能性があるので、子どもたちが家にいる間にリフォームをしておきたい
・・・といった理由で、「家族全員が楽しめる間に、こだわりのリフォームを！」という運びになりました。
というわけで、2月ぐらいから急ピッチでキッチンメーカーのショールームを訪れたり、ハウスメーカーさんに図面を書いてもらったりしています。
で、僕の方はできあがった図面や見積もりを細かくチェックしたり、カタログを穴が空くぐらい眺めて、今回のリフォームに取り入れるべきオプションがないか、等々の確認をしています。
何か気になる点が見つかると担当者さんにメールを送ったりする必要もあり、なんだかんだであっという間に時間が溶けていきます・・・。
現時点では図面や見積もりが9割方固まった段階で、これから5月から6月にかけて順次工事を進めていく予定です。
家のリフォームはウォーターフォール開発
で、当たり前といえば当たり前なんですが、家のリフォームは「THE☆ウォーターフォール開発」で進むんですよねー。
つまり、最初に全部仕様をかっちり決めて、見積もりと納期を出してもらって、互いに合意が取れたら契約して着工、というスタイルなわけです。
しかし、システム開発も家のリフォームも、ウォーターフォール開発はあまり嬉しくないです。
いかんともしがたいのはわかっているものの、どうリフォームするかを考えていると「実際に使ってみないとわからない」というポイントがたくさん出てきます。
カタログを見たり、ショールームに行ったりすることである程度想像しやすくなる部分はありますが、それでも限界があります。
たとえば「次回の打ち合わせまでにトイレや洗面所のクロスの色や柄を選んでください」とお願いされても、クロスのサンプルを眺めるだけじゃどういう組み合わせでどういうふうに見えるのか、正直よくわからないんですよねえ。
最近水回りのリフォームを検討中なんだけど、トイレの床やクロスの色・柄を決めるのが難しい……。ハウスメーカーから実物サンプルをもらったものの、組み合わせのイメージしづらい。「AとBの完成イメージ、好みはどっち？」みたいな選択肢を選んでいくと理想の組み合わせが見つかるサービスがほしい！ pic.twitter.com/inkvMtBz4j
— Junichi Ito (伊藤淳一) (@jnchito) 2021年3月28日
しかも、ウン百万もする大きな買い物なので、絶対失敗したくない。
でも、やってみないとわからない部分がたくさんあるので失敗しそう。
というジレンマ。
失敗はしたくないけど、かといって「試しにやってみて、ダメだったら作り直す」というオプションの選択はまず不可能なので、仕方なく図面やカタログとにらめっこしながら、脳内イマジネーションをフル稼働させる作業をずっと続けております。
システム開発もウォーターフォール開発はつらい
で、ここからシステム開発の話に移ります。
システム開発もウォーターフォール開発になるとこれとほぼ同じ問題が出てきますよね。
ウォーターフォール開発は仕様書を書いて、見積もりと納期を出して、合意を取れたら開発開始、というスタイルなので。
でも、システムだって使ってみなきゃわからない部分がたくさんあるわけです。
というか、システムには形がないので、家のリフォーム以上に「実際に使ったらどうなるか」を想像しにくいと思います。
僕はシステムを作る側の人間ですが、今回のリフォームでお客さんの立場に立つことで、あらためて「やっぱりウォーターフォール開発はあかんなー。絶対お客さんもつらいと思うわ」と強く思いました。
ハードの開発スタイルにソフトの開発スタイルを合わせる必要はない
ただ、システムは「形がないので想像しにくい」という弱点がある一方で、「建築物に比べるとはるかに作り直しやすい」という強みがあります。
「画面の色はどうしよう」とか「文字の大きさはどれくらいがいいかな」みたいな話であれば、その場でぱっぱっと変更することができます。
それだけでなく、もっと大きなレベルで「あとからCSVエクスポート機能を付ける」なんてことも、ソフトウェアであれば比較的簡単に実現可能です。
であれば、ウォーターフォール開発をやめたらいいんですよね。
ある程度大まかな要件を決めたら、実際に開発してみる。
そして、「実際に使ってみて、しっくりこない部分があれば作り直す」というスタイルにしちゃえばいいんです。
建築物はハードですが、システムはソフトなので、そもそものモノが違います。
なのでハードの開発スタイルに合わせてソフトを開発する必要はないわけです。
（何十年も前のソフトウェア開発だとコンピュータ資源の制約があってハードウェアと同じぐらい作り直しにくかったと思いますが、それは昔の話です）
システム開発をサブスクとして提供する「納品のない受託開発」
しかし、「何度でも作り直せばいいやん！」と思ってもその次に問題になるのが、「そのスタイルでどうやって商売するか」というビジネスモデルの問題です。
「事前に見積もりや納期を出す方式」で商売をすると、「何度でも作り直す方式」と相性の悪い部分がたくさん出てきます。
この問題を解決するために、僕が勤めている株式会社ソニックガーデンでは「納品のない受託開発」というビジネスモデルを採用しています。
これは文字通り、納品をなくして継続的に開発を続けるというビジネスモデルです。
今どきの言葉で雑にまとめると「システム開発のサブスク」ですね。
毎月定額料金で開発をし続ける、定額料金を払っている間はいくらでも作り直し可能、というスタイルで開発を進めます。（めちゃくちゃ雑なまとめですが）
「納品のない受託開発」は楽しい
僕はかれこれ10年近くこの「納品のない受託開発」でシステム開発を続けていますが、とても良い開発スタイル＆ビジネスモデルだと思っています。
特にお客さんが新規事業を始める場合は「システムがどう出来上がるか想像しづらい」という問題以上に「お客さん自身のビジネスがどう転ぶかわからない」という問題の方が大きいです。
「納品のない受託開発」であれば、お客さんのビジネスの進化に合わせて継続的かつ柔軟にシステムを変更していく、ということが可能です。
なので、システムを作る側も、開発をお願いする側も、ウォーターフォール開発に比べると圧倒的にストレスが少ない開発スタイルだと思います。
まさに「win-winの関係」ってやつですね。
それにウォーターフォール開発だと、使うかどうかわからない機能も事前に作るかどうか決定しなければなりませんが、「納品のない受託開発」であれば「最初はその機能無しでリリースする。本当に必要になったらそのタイミングで機能追加する」という選択肢が採れるので、開発コストの節約にもなります。
今回、自宅のリフォームで「THE☆ウォーターフォール開発」に巻き込まれながら、「あ〜、家のリフォームも『納品のない受託開発』スタイルでできたらいいのにな〜」と何度も思った次第です。
まとめ（と、We're hiring!）
前述の通り、「納品のない受託開発」は発注者側だけでなく、開発者にとってもメリットがあります。
お客さんと直接やりとりをしながら、二人三脚でシステムを開発していくのはとても楽しい作業です。
バリバリコードを書きたいけど、ウォーターフォール開発だとなんかすごくストレスが溜まる……と考えている開発者のみなさんは、「納品のない受託開発」プログラマになると幸せな開発者体験が待っているかもしれません。
興味がある方はぜひソニックガーデンのホームページを覗いてみてください😘
www.sonicgarden.jp
あわせて読みたい
「納品のない受託開発」について詳しく知りたい方は社長の倉貫さんが書いたこちらの書籍もどうぞ。
現在では変わった点もいろいろありますが、基本的な考えは大きく変わっていません。
- 作者:倉貫義人
- 発売日: 2014/07/18
- メディア: Kindle版
