「ただ動く、使えるだけじゃダメなんだよ母ちゃん！」- システム開発時の設計にコストをかけるべき理由

こんにちは！PIVOTコラム編集部です。
今回は、システム開発とは切っても切り離せない「設計」の基本的な考え方と、陥りがちな問題について書いていこうと思います。

結論、以下の2点に留意してもらえば、クリティカルな設計の破綻を回避し、トータルコストを抑えることができると考えています。

1.  新規プロダクトの場合：

　リリース後の展望を早いタイミングで開発側に共有する
2. リニューアルの場合：

　見た目だけではなくシステムの再設計にもコストをかける 

この理由について解説していきます。

サービス設計、UI設計、UX設計….プロジェクトの中では「設計」というワードが山ほど出てきます。
その中でも今回は、コードを書く前に行う設計、実際にコードを書いてプロダクトを作る前準備としての設計、システムの設計にフォーカスしてみます。（便宜上システムという大きな括りで表記していますが、本来はこれがさらに細分化されて議論されます。）

僕らがプロダクトを実装する際、デザインや要件を元にいきなりコードを書き始めることは、ほとんどありません。
家を建てる際に完成イメージの模型だけを見て工事を始めようとする大工さんがいないのと同じですね。
大工さんは骨組みや部材、部材同士の接合方法などを明記した「設計図」を作成してから作業に取り掛かると思います。

WEBサイト開発やアプリ開発の場合も同様で、開発プラットフォームや言語、フレームワークやパーツの分割方針など、事前情報を元に「設計」をした上で実装に取り掛かります。

設計に関連する問題の多くは、リニューアル時に顕在化します。

なぜきちんと設計したはずものが問題を引き起こしてしまうのでしょうか？一言で言うと「初めに考慮していないことをやろうとしているから」です。

初めに考慮していること、それは初期開発の段階で要件、要望としてあげてもらったものに限られます。それ以上のことをやろうとすると、破綻する可能性があるのは明白です。

例えば…
「２階建ての家が欲しい（もちろんなるべくリーズナブルに）」
という要望に答えるべく、木造２階建ての家を制作したとします。
その後、しばらくすると次のようなリフォームの要望が出てきます。
「二世帯で住むことになったし、お金にも余裕が出てきたから、今の家を5階建てに増築したい」

「木造の骨組みでは5階建ての建物に必要な強度が確保できない…けれど広い居住スペースは確保したい…」
ここで、場当たり的な増築をおこなってしまうと事態はさらに悪化していきます。骨組みの補強など、本質的ではない部分への対応に追われてしまい、投下したコストに対して得られるリターンが少なくなっていく、という負の連鎖が始まります。

これらは、決して大袈裟な例えではありません。実際、”ハ○ルの動く城”状態になってしまったプロジェクトを多数みてきました。システムの設計はクライアントが現状を把握しにくく、対応が後手に回りがちです。

冒頭の2つのポイントに留意する必要が出てくるわけです。

1. 新規プロダクトの場合：

　リリース後の展望を早いタイミングで開発側に共有する
2.リニューアルの場合：

　見た目だけではなくシステムの再設計にもコストをかける

再び、先の例に則って説明していきます。
初期開発のタイミングで「２階建ての家が欲しい」という情報に加えて、「将来的に増築する可能性がある」という展望を共有いただければ、多少コストをかけてでも事前に骨組みを強化しておき、鉄骨2階建ての家が提案できます。
仮に先々のことは分からなかったとしても、リニューアルのタイミングで追加コストをかけて再設計を行うことで、トータルコストを最小限に止めることができます。

今回はシステムの設計にコストをかけるべき理由について書いてみました。然るべきタイミングで然るべきところにコストをかけて対応していく、これが息の長いプロダクトを作っていくための基本になると考えています。
新規開発、リニューアルの際には是非参考にしてみてください。