アーキテクトな猫の図書館

設計の失敗：データベースの関連を纏めずに開発した時に起きる不幸

こんにちは！　@nekoasukaです。

設計で失敗した時の事も纏めておこうと思い、今回のエントリへ落とします。

今回は、

データベースの関連を纏めずに開発したら何が起きるのか

についてです。

まとめに入る前に、背景について補足します。

業務系ソフトウェアが開発対象である
複数名で外部設計を担当している（担当は機能ごとに分割されている）
３層環境で動作するアプリケーションである
リレーショナル・データベースを利用している
マスタデータ（※１）とトランザクションデータ（※２）とが別管理されている

ウォーターフォール型の開発手順に則り、
要件定義→外部設計（基本設計）→内部設計（詳細設計）→開発
と進む中、【外部設計】の段階でデータベースに保存するデータの構造を決定します。

この時、「機能に紐付けて、特定のテーブルの構造のみを設計書へ記述」を進めていた頃から、不幸は始まります。

機能に紐付けて作成された設計書のそれぞれは、「その設計書の中では」整合性が取れた状態で済んでいました。

しかし、時が経つにつれて徐々に設計のほつれが明らかになりました。

期待したデータが対象の項目に保存されない
特定条件を満たすデータの件数が、想定していた件数と異なる
検索を想定していたテーブルとは別のテーブルに情報が保存されている

といった具合に。

上記のような現象が発生した理由を考えてみました。

複数の外部設計担当者が読み書きするテーブルが多数あった
データベースの関連を表す資料が存在しなかった
各機能やデータ構造について、充分考察できる時間が用意されていなかった

業務の流れに沿って、業務の担当者が切り替わるタイミングなどに合わせてテーブルが切られています。
その都合上、機能を横断するテーブルが多数存在します。
機能ごとに区切って外部設計の担当者が割り当てられているため、複数名が同じテーブルの構造について考察する環境が頻発しました。

また、各外部設計書を横断するような、テーブルの構造を示す資料がありませんでした。
そのため、担当者間の設計思想が共有されづらい状況にありました。
※もちろん、担当者間で相談をしながら進めましたが、限度がありました。

更に、よくある話ですが、「納期」が重たい錨として降ろされており、人も少ない状況での設計でした。
自身の設計力のなさを嘆きつつ、「個人の担当範囲においてはおおよそ整合性が取れている」という状況にするので手一杯でした。
他の設計者の方も、精度の個人差はあれ、似た状況で開発フェーズを迎えました。

開発の途中、データベースの関連図をいよいよ作ろうという話が上がり、作成に踏み切りました。
すると、ぽろぽろと音を立てて、積み上げたデータベースの穴が、乱雑に配置されたテーブルの中から見えて来ました。
「一枚の絵を囲んで設計者間で議論」をし、穴がなくなるように改造をしていきました。

「一枚の絵」（※３）を書き始めたことで、データの整合については、鎮火の兆しが見えました。

以上が、データベースの関連を纏めずに開発した時に起きる不幸と、その回避の一策です。
僅かながらの備忘録として。

※１　マスタデータ
ソフトウェア全体に対して、動作を制御したり、情報を整理したりする場合に用いるデータの総称。
変更の少ない情報を取りまとめる事が多い。
例）　ログインユーザの情報、企業の情報、取り扱う商品の情報など

※２　トランザクションデータ
ソフトウェアの機能が動作する上で、機能の動作途中や、ユーザの操作によって発生するデータの総称。
変更や新規発生の多い情報を取りまとめる事が多い。
例）　商品の発送状況、商品購入履歴、ユーザー投稿コメントなど

※３　一枚の絵
通称ER図。
テーブル間で、データがどのように結びつくかを表現する図。
各テーブルの主キーとその他、テーブル間のデータが１：１なのか、１：ｎなのかなどの関連を示す図。
今回のプロジェクトでは、特殊な外部結合の条件なども色で結びつけて、表現してみました。

読書録：峡谷に橋を架けるために

暑さが一段落した中、久々な更新です。@nekoasukaです。

『システム設計の謎を解く強いSEになるための、機能設計/入出力設計の極意』を読んだので、その内容について纏めます。

本書の内容を一言に圧縮すると、
「要件と開発を橋渡しするための基礎力養成ドリル」
です。

中でも肝要と感じたトピックは、以下の３つです。

可不可よりも過不足を捕らえること
設計は品質と背中合わせだということ
絵を書くこと

これらについて、順に思考を巡らせます。

1. 可不可よりも過不足を捕らえること
ここでいう設計は、「顧客から要件を聞き出しまとめた後～「プログラムの具体的な実装方法を考える直前」までを対象としています。

その上で、先ず抑えた方がよい事として、可不可よりも過不足を捕らえることがあります。
要件定義をしている中で私自身もよくやりがちなのが、
「Aは標準の機能で対応可能です。Bは今のシステムのままでは対応できないため、新規開発が必要です。」
といった応対で終えてしまうことです。

顕在化した要件に対する応答としてなら、「可」とは思いますが、必要十分な対応かという視点であれば「否」と思います。
上記のような応対はもちろん、システムで対応出来る事と出来ない事との線引きに有効です。
次のステップとして、「過不足」を捕らえ、評価できるようになれと本書は語ります。
「過不足」とは『こんな事は無いのかな？』『こういう要件があるのなら、他にこんな要件があるはずでは・・・？』といった確認事項を指します。

例えば、
「国内の企業からある原料を購入するには、Xという機能を使えば対応可能です。ただ、海外の企業からですと、Xでは対応できませんので、カスタマイズが必要です。」
という「可不可」が存在したなら、次のような「過不足」へと考えを巡らせます。
『国内の複数企業から同じ原料を購入することは無いのだろうか？』
『海外の企業から購入する要件があるのなら、輸出に関する要件もあるはずでは・・・？』
といったように。

こういった「過不足」を確認事項として顧客とシェア出来るようにすると、ワンランク上の技術者となれるだろうと、本書は謳っています。

2. 設計は品質と背中合わせだということ
本書の中で多く出てくるキーワードに、「品質」があります。
設計をする際のビューポイント（視点）として「品質」の指標を用いたり、品質を担保するために設計の「型」を使ったりと言った例が挙げられています。
私が過ごしてきたプロジェクトでは、「開発の後からどんなテストをするか、品質を担保するか考える」環境が多く、設計の際に品質の事について考えを巡らせる機会は少ない印象がありました。
※私が単にそう感じただけである可能性もありますが。

「品質」の指標という点で言うなら、ISO9126やISO/IEC25000シリーズなどがあります。
しかしこれらはフルコース過ぎて、すべてをこなすには体力や時間が足りなさ過ぎます。
以前のプロジェクトで実際にISO9126を適用して、テストをどう作るか考えた事がありますが、６つある大分類のうち２つしか使うに至りませんでした。
※４つはリソースが足りない、必要がない、やる時期でないなどの理由から対象外としました。

これはあくまでも「テストをするとなった直後の話」ですので、設計時であれば、６つすべてを考慮に入れてもよいのでは、と考えます。
考慮に入れるとはいえ、そこで「過不足」の検討をすることは必至であると思いますが。

3. 絵を書くこと
最後に、私が大切と感じた事に、「絵」があります。
本書では始終に渡って多くの「絵」が出てきます。

「絵」で表現するメリットの最たるものは、「共有のしやすさ」にあると私は思っています。
文章では、「自身で考えていること」がすべからく表現出来ない時が多いとも思っています。
いずれにせよ「共通認識」がある程度必要ですが、文章よりは「絵」の方がその量を抑えられます。

文章では背景情報の共有や、用語の意味の共有に細心の注意を払う必要があります。
「絵」であれば、書き方やオブジェクト、色の意味だけを共有すれば「本論」に入ることができます。
「本論」も、「絵」であれば俯瞰して話を進めることができるため、考慮に漏れがないかが気付きやすくなります。

本書にはそんな共有のための「絵」が具体例として多く収録されています。
先輩や自分自身が書いていた絵はもちろん、その他の絵の意義や有用性を再認識する契機になりました。

以上が、私が本書を読んで考えを巡らせたことです。
この本には、設計について学ぶ道もいくつか参考文献などの形で示されていました。
それらでこの先の道標を確認しつつ、まだまだ思考を巡らせます。

備忘録：Twin Peaks Model(要求と設計)

服が破けるくらい膝を擦ってしまい、涙目な@nekoasukaです。

前回は『Twin Peaks Model』違いだったので、こちらの『Twin Peaks Model』について調べた事を書き出します。

『Twin Peaks Model』の『Twin Peaks』は、要求と設計を指しています。
要求と設計を山に見立て、それぞれの山を往来しながら、考えを巡らせる仕組みです。

手順はあっさりとしています。
次の３ステップだけです。

１．既存のシステムを修正しているような箇所から、仕様を辿って設計へ。
２．無視されがちな活動をとりあげ、他の事例と照らし合わせながら汎化や評価をする。
３．曖昧な要求について、他の設計を選択していたらどうなったかと思いを馳せる。

上記をこなす途中で気をつける事が２つ。

A．最初は一般的なところから、だんだん細かな業務特化されたところへ。
B．独立した機能を最初にこなし、だんだん関連機能が多いところへ。

ステップ１～３について私なりに、実際にウォークスルー（具体的に思考を巡らせて手順を追いかけること）をしてみます。
もちろん内容はフィクションです。

私はエンタープライズ系ソフトウェア（業務系と称されるソフトウェア）を取り扱っていますので、在庫管理のシステムを思い浮かべます。
今までExcelで表管理をしていたのですが、データ件数が増えたり、販売拠点が増えたりしたことによってデータを一元化したい、といった要求に応えていたとしましょう。

１．既存のシステムを修正しているような箇所から、仕様を辿って設計へ。
Excelをデータベースへと置き換えるのですから、テーブルに保持する項目やその構造を決定しているはずです。早速設計書を見に行きましょう。

２．無視されがちな活動をとりあげ、他の事例と照らし合わせながら汎化や評価をする。
データベースの設計で無視されがちな活動といって思いついたのは「データ件数の大幅な増加を想定して、適切なインデックスを作成すること」でした。
今回も案の定、外部参照をするキー項目にインデックスの漏れを発見しました。
よくない設計です。
外部参照をするキー項目に対しては、インデックスを貼らなければ「全数走査」が実行され、データ件数が増えるほど処理が遅くなります。
販売管理のシステムを触った時も、同様にインデックスが漏れていてお客様からクレームがあったことを思い出すなどしました。

３．曖昧な要求について、他の設計を選択していたらどうなったかと思いを馳せる。
設計書の別のところに、「在庫数と品目コードをテーブルAに、品目コードと品名をテーブルBに保持する」という記述を見つけました。
要求には、「在庫数と品名を管理する」としか記述がなく、「ある時突然品名が変わり、内容物（品目コード）は同じ」という品目はどう管理するかが曖昧でした。
もし、「在庫数と品目コードと品名をテーブルAに持っていれば」、上記のパターンは回避できます。しかし、在庫管理の情報が複雑になってしまいます。さらに、品名を間違えて登録しようものなら、修正が効きません。
※一般的には、突然品名が変わった！　などといった場合は品目コードから分けるのが自然と思います。

このように要求と設計とを行き来しながら、徐々に深く、細かく考えを巡らせていくことで、脳内の設計に関する情報が整理されていきます。
また、現時点の知見からアンチパターンやベストプラクティスが導き出されます。
※今回であればインデックスやテーブル設計の話。
エンタープライズ系のような、対象となるシステム範囲が大きく、他システムとの関連なども多いソフトウェアの設計を考察する時にはうってつけかも知れません。

備忘録：ツインピークスモデル

まずは出力を、@nekoasukaです。

Facebookで『設計を考えなおすもとになる』と教えていただいたので、早速調べてみました。
が、このツインピークスモデルでは無いことが判明。
本命はこちらでした。
こちらの記事を読んだ後、改めて纏めます。

本エントリは、折角なので残しておきます。

ツインピークスモデル（Twin Peaks Model)
金融監督体制の一種。
目的別に監視する枠組み。
リスクの状況を分析・評価する機関と、金融取引などの業務行為を監督する機関とに区切る。

ソフトウェアの設計に近しい話へ置き換えます。

ツインピークスモデル（Twin Peaks Model)
目的別に考察するための枠組み。
ソフトウェア開発を実施する際のリスクを分析・評価する視点と、成果物を観察する視点とに区切る。

設計の範囲で更に書き換えるなら、「設計を実施する際のリスクを分析・評価する視点と、設計時の成果物（外部設計書・基本設計書、テーブル定義など）を観察する視点とに区切る」と言えると思います。

さらに一歩踏み込んで実務に置き換えてみます。

①設計を実施する際のリスクを分析・評価する視点
　現在のプロジェクトは、慢性的なリソース不足です。
　また、全体スケジュールの不透明さが蔓延っています。
　更に、頻繁に顧客への説明会があり、そのための資料として設計書を作成する必要がありました。
　そのため、設計にかける事ができる時間が少ないことにより、「機能間の矛盾や、要件の漏れに気付きづらい」リスクがありました。

②成果物を観察する視点
　成果物は、Excelにまとめられており、可読性が低い状況にありました。
　また、既存の成果物に加筆修正を実施する形式での運用であったため、「既存のドキュメントを大幅に変更できない」という制約がありました。
　これによって、①で記載したリスクが顕在化する確率が増幅された気がしています。

上記を経て作成された設計書から、テスト時に多くの「外部設計書の誤り、矛盾」による手戻りが発生しました。
「よくない事例」として、一つのサンプルを取得出来たと思います。

ここまでの思考実験から、私はツインピークスモデルによる考察は、事実を冷静に辿る事が出来るフレームワークであると認知しました。

以上が、ツインピークスモデルについて調べた結果と、その考察です。

指折り数えられるアーキテクトを目指す錨をここに

はじめまして、あすか(@nekoasuka)です。

コンサルタントとエンジニアとを往来している、いわゆるソフトウェア産業の一労働者です。

このブログを作った一番の目的は、

「システム設計ならこのブログを読めばいいよ」というブログを書きたい。
そして、「一流アーキテクト」として一旗立てたい。
設計なら私に聞けといえる人に、32歳までになるという気構えで。
このブログを書き連ねるにあたって、主に次のトピックを考えています

　１．実際に設計をやってみた時のこと
　２．「基本設計はこうしたほうがいい」と思うこと
　３．設計について、読んだ書籍からの考察
　４．設計について、見た・聴いたことのまとめ
　５．基本設計と詳細設計（開発）との線引き

トピックは時とともに変わるとは思いますが、基本はこの方針で。

まずは29歳になるまでに、このブログを成長させる所から。

よろしくお願いします。