仕様の個人的な使い方

この記事は、モノづくりの際に一般的な仕様の考え方を使えば、個人の作成作業にもメリットがあるという話しです。

「仕様って何なん？」

仕様とはそのアイテムが満たす項目のことです。
複数名や組織で開発にあたる際に齟齬なく目標を共有するためのものが仕様書なので、個人であれば普通は必要ありません。
では、なぜ仕様を個人でも使うとメリットがあるかというと、それはボンヤリと考えていたことを整理する為です。
個人でモノづくりをする際、個人の構想と、それに基づいて作られたモノが生まれます。
これは鶏と玉子の関係になりますが、「作ったモノを仕様にする」もしくは「仕様にしたモノを作る」と自分の中にあった誤解が明らかになります。
誤解とは、構想では上手くできると思っていたが失敗したこと、想定よりもコストがかかった等です。
誤解が見つかるのは良いことです。ソフトであればバグを出して品質が上がっている状態です。
もし想定と違う部分があれば、修正すれば良いだけです。
仕様を変えても良いし、モノの方を変えても構いません。大事なのは何を優先するかです。
組織の場合だと仕様変更の度に、変更を決定する手続きと周知する時間が必要ですが、個人ならリサーチしてから決めても良いですし、エイやでも決めてしまえます。
個人の創作や副業で問題となるのは、勢いだけで始めて、長い時間を消費してから誤解に気づくことです。個人であるからこそ、時間は有効に使うべきです。組織であればカバーしてくれる人もいるかもしれませんが、個人であれば簡単にカバー出来ません。

「仕様にするポイント」

私の場合はUSDMという仕様の書き方を勉強しました。
詳しい内容を説明すると長くなりますので、もしご興味がありましたら、ネットに専門の方があげた資料がありますので、そちらをご確認ください。
ここで私が伝えたい大事なポイントは「情報の階層化」と「理由の記述」です。
どのようなレベルで階層化するかについては、菊竹清訓先生の「か・かた・かたち」の考え方が参考になります。それぞれは以下のような概念となります。
か:原理や構想
かた:法則や技術
かたち:感覚や形態

アイデアから仕様化を始める場合は、アイデアや構想を、どの技術を用いて形にするかという順序で記述します。
実際に作ったモノから仕様化を始める場合は、形がどんな技術、アイデアや構想を根拠としているかを記述します。
仕様にする際は、階層が深いと読んでも分かりにくくなりますから、細かく書けば良いわけではありません。ですから、3階層くらいがちょうど良いです。
仕様を書く際に、何を書くか困ったときは、マンダラートを使うと網羅的に書し易くなります。

後から整理するパターン

本記事では、仕様を後から作る場合の例として、私が自作したタイラップスツールを仕様にしてみます。こんな感じです。

タイラップスツール｜Asahi｜note

階層化したタイラップスツールの要件

大きな要件は２つで、スツールの機能「座る」と、作り方に関する「簡単に組めてバラせる」となりました。そこから下の階層に向けて具体的な手段になっています。
今回はNOTE用にメモアプリを使いましたが、意外に簡単に出来そうだと感じました。