服が破けるくらい膝を擦ってしまい、涙目な@nekoasukaです。
前回は『Twin Peaks Model』違いだったので、こちらの『Twin Peaks Model』について調べた事を書き出します。
『Twin Peaks Model』の『Twin Peaks』は、要求と設計を指しています。
要求と設計を山に見立て、それぞれの山を往来しながら、考えを巡らせる仕組みです。
手順はあっさりとしています。
次の3ステップだけです。
もちろん内容はフィクションです。
私はエンタープライズ系ソフトウェア(業務系と称されるソフトウェア)を取り扱っていますので、在庫管理のシステムを思い浮かべます。
今までExcelで表管理をしていたのですが、データ件数が増えたり、販売拠点が増えたりしたことによってデータを一元化したい、といった要求に応えていたとしましょう。
1.既存のシステムを修正しているような箇所から、仕様を辿って設計へ。
Excelをデータベースへと置き換えるのですから、テーブルに保持する項目やその構造を決定しているはずです。早速設計書を見に行きましょう。
2.無視されがちな活動をとりあげ、他の事例と照らし合わせながら汎化や評価をする。
データベースの設計で無視されがちな活動といって思いついたのは「データ件数の大幅な増加を想定して、適切なインデックスを作成すること」でした。
今回も案の定、外部参照をするキー項目にインデックスの漏れを発見しました。
よくない設計です。
外部参照をするキー項目に対しては、インデックスを貼らなければ「全数走査」が実行され、データ件数が増えるほど処理が遅くなります。
販売管理のシステムを触った時も、同様にインデックスが漏れていてお客様からクレームがあったことを思い出すなどしました。
3.曖昧な要求について、他の設計を選択していたらどうなったかと思いを馳せる。
設計書の別のところに、「在庫数と品目コードをテーブルAに、品目コードと品名をテーブルBに保持する」という記述を見つけました。
要求には、「在庫数と品名を管理する」としか記述がなく、「ある時突然品名が変わり、内容物(品目コード)は同じ」という品目はどう管理するかが曖昧でした。
もし、「在庫数と品目コードと品名をテーブルAに持っていれば」、上記のパターンは回避できます。しかし、在庫管理の情報が複雑になってしまいます。さらに、品名を間違えて登録しようものなら、修正が効きません。
※一般的には、突然品名が変わった! などといった場合は品目コードから分けるのが自然と思います。
このように要求と設計とを行き来しながら、徐々に深く、細かく考えを巡らせていくことで、脳内の設計に関する情報が整理されていきます。
また、現時点の知見からアンチパターンやベストプラクティスが導き出されます。
※今回であればインデックスやテーブル設計の話。
エンタープライズ系のような、対象となるシステム範囲が大きく、他システムとの関連なども多いソフトウェアの設計を考察する時にはうってつけかも知れません。
前回は『Twin Peaks Model』違いだったので、こちらの『Twin Peaks Model』について調べた事を書き出します。
『Twin Peaks Model』の『Twin Peaks』は、要求と設計を指しています。
要求と設計を山に見立て、それぞれの山を往来しながら、考えを巡らせる仕組みです。
手順はあっさりとしています。
次の3ステップだけです。
上記をこなす途中で気をつける事が2つ。
1.既存のシステムを修正しているような箇所から、仕様を辿って設計へ。
2.無視されがちな活動をとりあげ、他の事例と照らし合わせながら汎化や評価をする。
3.曖昧な要求について、他の設計を選択していたらどうなったかと思いを馳せる。
ステップ1~3について私なりに、実際にウォークスルー(具体的に思考を巡らせて手順を追いかけること)をしてみます。A.最初は一般的なところから、だんだん細かな業務特化されたところへ。B.独立した機能を最初にこなし、だんだん関連機能が多いところへ。
もちろん内容はフィクションです。
私はエンタープライズ系ソフトウェア(業務系と称されるソフトウェア)を取り扱っていますので、在庫管理のシステムを思い浮かべます。
今までExcelで表管理をしていたのですが、データ件数が増えたり、販売拠点が増えたりしたことによってデータを一元化したい、といった要求に応えていたとしましょう。
1.既存のシステムを修正しているような箇所から、仕様を辿って設計へ。
Excelをデータベースへと置き換えるのですから、テーブルに保持する項目やその構造を決定しているはずです。早速設計書を見に行きましょう。
2.無視されがちな活動をとりあげ、他の事例と照らし合わせながら汎化や評価をする。
データベースの設計で無視されがちな活動といって思いついたのは「データ件数の大幅な増加を想定して、適切なインデックスを作成すること」でした。
今回も案の定、外部参照をするキー項目にインデックスの漏れを発見しました。
よくない設計です。
外部参照をするキー項目に対しては、インデックスを貼らなければ「全数走査」が実行され、データ件数が増えるほど処理が遅くなります。
販売管理のシステムを触った時も、同様にインデックスが漏れていてお客様からクレームがあったことを思い出すなどしました。
3.曖昧な要求について、他の設計を選択していたらどうなったかと思いを馳せる。
設計書の別のところに、「在庫数と品目コードをテーブルAに、品目コードと品名をテーブルBに保持する」という記述を見つけました。
要求には、「在庫数と品名を管理する」としか記述がなく、「ある時突然品名が変わり、内容物(品目コード)は同じ」という品目はどう管理するかが曖昧でした。
もし、「在庫数と品目コードと品名をテーブルAに持っていれば」、上記のパターンは回避できます。しかし、在庫管理の情報が複雑になってしまいます。さらに、品名を間違えて登録しようものなら、修正が効きません。
※一般的には、突然品名が変わった! などといった場合は品目コードから分けるのが自然と思います。
このように要求と設計とを行き来しながら、徐々に深く、細かく考えを巡らせていくことで、脳内の設計に関する情報が整理されていきます。
また、現時点の知見からアンチパターンやベストプラクティスが導き出されます。
※今回であればインデックスやテーブル設計の話。
エンタープライズ系のような、対象となるシステム範囲が大きく、他システムとの関連なども多いソフトウェアの設計を考察する時にはうってつけかも知れません。
PR