はじめに
設計時の見落とし Advent Calendar 2018という面白そうなカレンダーがあったので、基本設計について考えてみました。
こんな基本設計はイヤだ！
基本設計ではどういったことまでドキュメントに起こすの？という話があると思います。結構会社やプロジェクトでまちまちですよね。
ここではざっくりと「プロジェクトの要件をインプットにして、システム開発が開始できるレベルまで構造を決める」とさせてもらいます。
正直当たり前のことしか書いてないけど、どれも実際に私が出会ったことのあるケースです。
設計全体
インプットとの紐づけがわからない
基本設計時のインプットならプロジェクトの要件になると思います。
この表現が要件定義書だったりただの機能要件・非機能要件の羅列だったりすると色々あると思いますが、いずれにせよ何かしらのインプットがあるはず。
そのインプットとその成果物である設計書の紐づけが分からないと、作成した設計書が正しいかどうかの評価が出来ません。
またここを意識していないと要件変更時に追従するのも難しくなるので、出来るだけインプットと設計書が紐づくような構成にするなり、対応表を作るなりしたいです。
やたら文章で書きたがる
図がほぼ皆無で文章しかない。文章だけだとどうしても複数の意味に取れる言い回しになることがあります。
例えば、モジュールAとモジュールBの管理するデータはモジュールCのデータと関連している。
⇒(モジュールA) && (モジュールBの管理するデータ) -> モジュールCのデータと関連
⇒(モジュールA && モジュールB) の管理するデータ -> モジュールCのデータと関連
みたいな
文章が多いと作る方は満足度が高いのですが、認識違いの元になるし、純粋に見にくいので図を利用しましょう。
後は文章を区切って簡単な文章にしましょう。
設計内容
ユースケース（機能・モジュールの用途）がよく分からない
ユースケース図がないとか、図はあるんだけどそのモジュールの説明が無くてシステム目線でどのように機能を実現しようとしているのかよくわからない状態。
「結局最初にHTTP requestを受けるのは誰なの！？」とかが結局よくわからないと、基本設計ドキュメントを見ただけでは意識合わせもしにくい。
最低限チーム毎の役割は基本設計時点で分かるようにしたいです。
外部インターフェースとなる部分がなにかよくわからない
ユースケースはわかったし登場人物も書いてある。でも登場人物同士の繋がりがよくわからない！
この状態だとチーム毎の役割は決まったんだけど、どのチームと関わっているかわからないので影響範囲が見えず遅延の元となります。
そんな状況あり得ないですか？意外とあります、「役割は決めたから後は現場で良しなに決めて！」ってプロジェクト。怖い怖い
シーケンスがど真ん中しか意識されていない
シーケンスは基本設計なのか？って話もありますが、インターフェースをある程度決める時点でざっくりシーケンスくらいは一緒に決めると思うので一緒に記載。
今まではどちらかというとタスクの抜け漏れという形で現れるようなものでしたが、この辺はシステム的な部分の設計漏れとして出てくる気がします。
エラー系
細かく洗い出すのは難しいかもしれませんが、エラー時の挙動については機能しようとして決めておく必要はありますよね。
例えばHTTPリクエストに対してだったらHTTP Statusで500 Internal Server Error辺りを返すのか、リクエストには200 OKを返すけど状態は変えないとか。
複数機能の並行処理
よくハマるのがこの辺りだと思います。
- 機能Aと機能Bを同時に実行することが出来ないようにするのか？出来るようにするのか？
- 実際にAとBの為のリクエストが同時に来た場合にどのような挙動にするのか？
- 後のリクエストはエラー？後で処理？後で処理する場合はブロッキングされるの？等
といった話。並行処理についてはシーケンス図を並べて「こっちのここにあっちの最初が重なったら？」みたいなことをやっていくとある程度潰せる気がします。セマフォやDBトランザクションのようなロックのある処理は特に。
性能周りの確認項目が洗い出せていない
この辺りはシステムがある程度出来てからでないと実際の確認は出来なかったりしますが、「検証出来るようになったらすぐ検証する」という状態にしてなっていないと痛い目見ることが多いので書いておきました。
起動時間
矛盾の無い完璧なシーケンスが出来ました！となっても、その結果起動時間が遅すぎるとなったら見直しが入るかも。
起動時間がシビアなシステムでは確認必須だったりしますよね。
通信性能
こちらは例えばHTTPリクエスト/レスポンスにどのくらいの時間まで許容するか？とか、動画配信するなら何fpsまで出すか？といった話。
スペックが出ないのでモジュール構成を見直すことになんてこともあり得るので、性能が決まっているなら早め早めに計測したいです。
物理スペックと合わない仕様
知っていれば当たり前だけど、知らないとハマるかもしれない話。
ハード屋さんがいればケアしてくれるかもしれませんが、ソフト屋さんだけだと結構見落としがちだったりしますよね。
私が出くわしたことがあるのは、動画配信用組込ソフトのPCシミュレーターを作った際に「PCだからきっと数十台でも性能劣化しないよね？」と言われ限界スペックを検証した際。期待値よりも全然下の段階で性能が出なくなったと思って計算したら、普通にギガビットイーサの性能限界だったなんてことがありました。
最後に
今回は基本設計というくくりで書かせていただきましたが、設計全体の話はどのフェーズの設計書でも共通していると思います。
設計漏れや認識違いを引き起こす設計書は、不具合を持っているようなものです。
設計書もコードと本質は同じで、意図が分かりやすく、シンプルな方がバグも少ないはず。
出来るだけ人にやさしい設計を行い、バグの少ないプロジェクトを作りましょう！