開発プロセス
開発手法
設計書
ソフトウェア開発

はじめに

若手SEならきっとみんなぶつかる疑問、設計書について持論をまとめます。

  • 開発手法
  • 要件定義
  • 外部設計
  • 内部設計
  • テスト仕様書

開発手法

設計書そのものの話の前に、まずはソフトウェア開発の手法について。

  • ウォーターフォールモデル
  • プロトタイプモデル
  • 反復型(アジャイルとか)モデル

メジャーな分類としてはこのあたりでしょうか?
ソフトウェア開発でこのどれにも当てはまらないってあんまりなさそうですね。

ソフトウェア、システムの性格や顧客要望に応じて上記の手法のうち、どの子をチョイスするか・・・
PMやPLクラスの経験豊富な方々が決めることがほとんどかな?
(中には謎のこだわりで独断するような人もいますよね。ウォーターフォールしか認めへん!的な(笑))

さて、なぜ開発手法の話から入ったかと言いますと、
開発手法は違っても、最後に残る設計書は同じという観点から攻めたかったから。

中には、「アジャイルやから設計書はない!」などのファンキーな発言をする人もいますからねー。騙されないように気を付けましょう。
もちろん、システムの作り方が違うんやから、その過程で出来上がるものは異なる。
けど、最終的にはどの手法だろうと同水準の内容を含んだ設計書が出来上がってないとおかしいでしょう。

ということで、ソフトウェア開発手法の違いは道のりの違い!到達点は同じ!です。

要件定義

要件定義って何をする工程でしょうか?この問いに具体的に、かつ端的に答えるのは簡単ではないでしょう。

要件定義とは、情報システムやソフトウェアについて顧客が望んでいる機能や仕様などの概略をまとめたもののことである。通常、要件定義をまとめたものは要件定義書と呼ばれる。また、要件定義に先立って、発注する側の顧客の方から、おもな要望や必要条件などをまとめたRFPが先に提出されることもある。(IT用語辞典より)

この説明をもとにどれだけの人が要件定義書を作れんねんって感じですよねぇ…
以下に僕が要件定義書を作成するときに意識することをまとめます。

  1. 要件定義の段階では、システムの観点で記述しない
  2. システムを用いて実現させる業務のビジョンを明確にする

この2点だけです。要件定義の段階って、まだシステムのレベルにまで話が下りてないんですよね。だからシステム屋じゃなくても要件定義って理解できるんですよ。だからユーザの上長クラスまでレビューするんですよ。
ここで問われるシステム屋の技術力は、顧客業務を理解して文書化できること、そして実現可能性や実装効率を加味した要件定義ができることとなります。

ところが、たったこれだけのことを理解できない、守れない人が多数いるのが現実です。
なぜか?簡単です。プログラマあがりがSEになるからです。
もちろんプログラマからSEになること自体は何の問題もないでしょう。私だってそうです。ただ、どうしてもプログラマ観点に引っ張られるんでしょうね。
要件定義の段階で、どんなテーブルを作るイメージだのどんなフラグを用意する感じだのと書き出すんですよ。
こういう人に突っ込むと大体「いや、要件定義はシステムの概要レベルやからこれでいい!概要レベルやから大丈夫!」とか答えるんですよね。

この悲劇を引き起こすのは、完成物から逆引きする発想です。
設計書のリバースエンジニアリングなんてものがありますが、あれも本当危険ですよね。ソースコードの要約みたいなものを書いて「〇〇の設計書をリバースした!」ってベテランに言われるとびっくりして小便ちびりそう。おっと話が逸れました。

顧客の要望がなんとなくつかめてくる
     ↓
大体こんな感じで作ることになるだろうな~と想像
     ↓
頭に思い描いたものをそのまま記述

この流れを踏むと、メンテナンスできない設計書が晴れて完成おめでとう☆彡
だって工程先取りしてるんだから、こいつがボトルネックになってバージョン1.0の完成段階で多数の修正が入った要件定義書が出来上がるでしょう。

ちゃんと工程に見合った記述レベルを意識しないとだめです。
外部設計を進めないとわからないこと、内部設計を進めないとわからないこと、いっぱいあるんですから。もちろん追加であれやりたい、やっぱりこうしたいとか、開発途中に要件定義書を修正することはあります。けど、つじつま合わせの修正が発生するのは、システム屋としての技術力の問題です。