10.ここまでのまとめ

前回(連載番号：1-9)まで解ったことをまとめてみます。

１．設計書のパラメータは、スキーマを決めることにより明確に設計が可能になる。
２．スキーマも表で定義すると、網羅性のチェックや関連性が検査できる。
３．完全なオントロジーではないが、業務用語を定義しブレークダウンしていくと設計が完成する。
４．作業工程はスプレッドシートで設計できる。(規模が大きくなるとツールが必要)
５．設計書はツール等を作成すれば、検証が可能になる。
６．伝統的な構造化設計手法とも類似しているので、手法としては理解しやすい。
７．設計書をそのままテンプレート化しやすい。
８．Graphviz等のツールを使い、ダイヤグラムを自動で作成しやすい。
９．全て行列で定義しているので、公理的設計と相性が良い？
１０．作業はマトリックス指向なので、人により手法の好き嫌いがある。
１１．スキーマの定義でのカスタマイズが自由に行える。
１２．XMLとの違いは、ベースのインスタンスは用意しておく必要があることです。

最後に９については以前から気になっていた手法なので、少し掘り下げて検討してみます。
公理的設計の出典は、
Axiomatic Design 2001.Oxford University Press, Nam Pyo Suh
翻訳本：「公理的設計」森北出版
からです。
次の設計公理を満たすことが条件のようです。
公理１：独立公理(Independence Axiom)
公理２：情報公理(Information Axiom)

独立公理とは、要求機能は最小個の独立性を必要条件として定義すること。
情報公理とは、独立公理を前提条件に、設計の情報量を最適化すること。

Q.今回の方法では、機能を定義しているが最小個になっているか？
A.小さいシステムでしか検討していないので判断はできない。

Q.独立性は保たれているか？
A.オントロジー的に設計していけば、条件は満たせるのではないか。

Q.設計の情報量を最適化できているか？
A.説明を必要最小限な文で記述するので、最適化は比較的満たせる。

かなり荒い分析ですが、本来ならば大規模システムで検討しないとこのような評価 が意味をなさないので、これぐらいにしておきます。

---

ここまでの開発手法の名前を付けます。
「TakioQ　Method」日本語名「タキオク手法」と言います。「頑固で早く、品質まで確保」するイメージで命名しました。
私が勝手につけた名前です。
このブログを読んだ人しか知りません。
多分今回のこれを読んでくれている人は少ないので、このままで終わってしまう開発手法 なのかも知れません。ただし、旧バージョンですがローカルなシステムで実績はあります。
もし、興味を持たれましたらメールで連絡ください。