プロダクトのミニマム版を作って検証に役立てることはできないか?

1 min読了の目安(約1500字IDEAアイデア記事

じつのところ、ただの思いつきです。皆様のご意見をお聞かせ願えればと思います。

たとえば、React + Redux + react-router + Webpack + etc... みたいな構成のプロダクトがあったとします。もちろん、Scala + Akka + etc... でもいいでしょう。

その構成を最小限にしたもの(削るとしたら画面とかでしょう)を用意し、これを「ひな形」とでも呼ぶとしましょう。ひな形に、画面とか色々なモノを付け加えたものが、プロダクトです。

ひな形が基底クラスで、プロダクトはひな形を継承した完全版のクラスのような関係だと考えればいいかもしれません。

基本的にプロダクトで使ってる要素技術の全てをひな形にも導入します。おそらく利用パッケージを完全に同一にしたモノが望ましいでしょう。

atomic design を採用してるなら、atoms/molecules までをプロダクトコードと同期してもいいかもしれません。

ひな形の用途

たとえば、Webpack4 -> Webpack5 みたいな大型アップグレードがあったときに、ひな形を使って雑に検証ができるはずです。

あるいは、特定ライブラリを別のライブラリに置き換えるような実験もしやすいかもしれません。

全くの新規機能の開発用環境に使ってもいいかもしれませんし、内部構造を変更するための検証にも使えるかもしれません。

つまり、さまざまな検証用のテストベッド[1]といえるものです。

問題点

  • 「ひな形」をどうやってプロダクト本体と同期を取るのか?(管理コスト)
  • 「ひな形」で行った実験はどれくらい確実にプロダクト本体に役立つのか?
  • 「ひな形」で実験を行う工数を捻出できるのか?

ぱっと思いつく問題点はこのようなところでしょうか?

「ひな形」をどうやってプロダクト本体と同期を取るのか?(管理コスト)

  1. ルーティング情報を元に、ページを最小限にまで削る。VSCode で注意深く依存関係を見て、依存がなくなったものを削除を繰り返す
  2. 「ひな形」とプロダクトは別々に管理し、プロダクトのパッケージ情報(Node.js なら package.json とズレが生じたら、自動で「ひな形」の修正を促す bot でも作っておく

「ひな形」で行った実験はどれくらい確実にプロダクト本体に役立つのか?

やってみないとわからない気がする。

そもそも、プロダクトコードにブランチを切って実験するのでもいいのかもしれない。あえていうと、余計な要素を切った状態で実験できるという利点はありそう。

「ひな形」で実験を行う工数を捻出できるのか?

一番の問題点はこれかもしれないが、まぁ最初は持ち出しでプロダクション検証をやってみつつ、利点を説明できるようにして、ねじ込むという流れか。

まぁ、問題はやはり 2 番の

「ひな形」で行った実験はどれくらい確実にプロダクト本体に役立つのか?

次第にはなりそうです。

まとめ

プロダクションコードから、余計な要素を省いて、技術検証を行うためだけの「ひな形」を作れば何か役立たないか?

ということを思いついたところです。

もし、何かアイデアや、見落とした問題点や、解決方法などを思いついた方がいたら、コメントなりいただけると幸いです。

脚注
  1. ナイツ&マジックを好きな方なら「トイボックス」といえば身近でしょうか。 ↩︎