僕が思う要件定義や設計書作成時に決めるべき内容

前置き

• 自分のこれまでの知識や経験から、要件定義や設計書作成時に決めるべき内容を整理する。
• 一般的なものではないが、自分のこれからの開発に生かしたい。
• 自分の知識や経験は以下である。
  • 大学生のときに学んだベンチャー時代のソニーのプロジェクト管理手法
  • Web系ベンチャー企業での開発経験
  • 大企業での分析システムの開発経験
• 以下では「要件定義」「基本設計」「外部設計」「内部設計」の4フェーズに分けているが、どのように分けるか、どのような言葉を使うかは組織や状況によって異なる(詳細設計とか)。ちなみに、「外部設計」「内部設計」という言葉を使用するメリットは、「外設(ガイセツ)）」「内設(ナイセツ)」と略せること、外部と内部が対になることだろう。

要件定義

• 要件定義の目的

  • 要件定義の目的は、開発する対象物および、それが外部に与える影響を明確化することであると僕は考える。
  • 例えばソニーがカラーテレビを開発したとき、開発する対象は「カラーテレビ」であり、そのカラーテレビが外部に与える影響は、「テレビを見ながら夕飯を食べる暖かな家庭を実現すること」であった。当時のテレビは暗く、部屋を暗くしないと見られないものであったため「明るい」テレビを作ることで、ソニーは「夕飯時の家族団らんの風景」を日本にもたらそうとしたのである。

• 要件定義で決めるべき内容

  • 目標
    • 「簡潔かつ明瞭な目標」を定めることが必要であると僕は考える。
    • その目標は「我々は果たして何を作ろうとしているのか？」「それによって何を実現しようとしているか？」を示す。例えばソニーがカラーテレビを開発したときの目標は「夕飯時に家族みんなで見られる明るいテレビ」であった。この目標により「何を作るのか」「それによって何を実現しようとするのか」が明確になる。
    • 大事なことは、この時点でスペックを定義しないことだ。もしもこの時点で「明るさ何ワットのテレビ」と決めてしまうと、本来の目的からずれてしまう。本来の目的は「家族が夕飯時に一緒に見られる明るいテレビ」であり、それによって「暖かな家庭の姿」を実現することである。そのためにはワット数のみならず、画面サイズや値段も重要なスペックだ。いくら明るくたって、画面が小さければ家族みんなでは見られないし、明るさや大きさが十分であったとしても、値段が高すぎては家庭では購入できない。
    • よい目標は、こういった数々のスペックを決める際の指針となる。
  • As-isとTo-be
    • As-is(現状)とTo-be(あるべき姿)を明確化することが重要だろう。
    • 例えば業務システムを構築するなら、現状の業務フローはこのようになっていて、そこでは大量の手作業があり、大量の紙媒体の文書が生まれ、管理が大変、といったものだ。
    • To-be(あるべき姿)としては、構築するシステムを導入した際の将来像を示す。構築するシステムの導入後は、無駄な手作業は一切なく、情報はデジタル管理され、必要な情報を必要なときにいつでも見ることができ、より的確な経営判断が可能になる、といったものである。
  • 新規性、強み、参入障壁
    • 例えばECサイトを構築するなら、既に存在するECサイトはこのようになっているが、我々が新たに開発するものはこういった点で新しく、こういった点が強みである、といったことを整理することだ。
    • 参入障壁も重要だ。他社が同じようなものを作ろうとした場合に、我々にはこういった経験や強みがあるから他社が真似したとしても容易には追いつけない、といったことを確認する必要がある。
  • 開発物の概要
    • どのような資料を作成するかは、開発対象や状況(自社製品か、受託開発か)でかなり異なる。
    • 例えばソニーがカラーテレビを開発したときは、すでに白黒テレビを開発しているから、次はカラーヴァージョンのテレビを作る！ ぐらいで済んだのではなかろうか。
    • 業務システムを構築する場合は、図や説明を駆使して何を作ろうとしているのかを示す必要があり、かなりの量の文書になる。
  • スケジュール、マイルストーン
    • いついつまでに作らないと他社に負ける、というのは当然ある。いついつまでにシステムを導入しないと間に合わない、といったこともある。そういった制約から、スケジュールやマイルストーンが決まる。これを確認することが重要だ。
  • 設備、人員、予算
    • 要件定義の内容を設計に落とし込まねば、必要な設備や人員、予算について読むのは難しい。それでもこの段階で予算などを作成する必要が出るのが世の常。

基本設計

• 基本設計の目的

  • 基本設計では、要件定義で明らかになった内容を設計に落とし込む。またそれを開発するための方式や体制、具体的なスケジュールを作成する。
  • 基本設計のゴールとしての理想は、設計が決まり、開発体制や方式も定まり、予算が明らかになり「これで作れるぜ！」と確信を持てる状態になることだろう。しかしながら、ソニーのカラーテレビ開発のような研究しながら行う開発では、この段階では設計の決めようがない。新規性の高い開発であるほど、その傾向は強いだろう。こういった際は、「こういうふうに作るぜ！」という開発方式を明確にすることがこの時点でのゴールではなかろうか。
  • ちなみに当時のソニーは、フレキシブルＰＥＲＴチャート、という手法を使っている。

• 基本設計で決めるべき内容

  • 設計
    • 機能要件
      • 要件定義で明らかになった内容を実現するために必要な機能の要件を明確にする。
      • 開発するものは、以下の機能を持つ。1.〇〇、2.〇〇 ・・・ といったイメージ。
    • 非機能要件
      • WEBサイトなら、常時接続ユーザー○○人を想定、その際のレスポンスは○秒以内といったもの。
    • 機能一覧
    • システム構成図
  • 開発ツールや環境
    • 各種プログラミング言語やフレームワーク、ライブラリなど
    • OS
    • WEBサーバ、データベースなどのミドルウェア
  • 開発方式
    • 各種プロジェクト管理ツールや開発手法
    • レビューのルール、体制など
  • 開発体制
    • PM、エンジニア○○人など
  • 運用設計
    • 運用時の保守体制、運用予算など
  • セキュリティ設計
    • 脆弱性対策
    • 脆弱性が明らかになった際の対応について
    • 使用する言語やフレームワークのアップデートについて
  • テスト方式設計
    • 単体テスト方式(各言語のユニットテスト使うとか)
    • 結合テスト方式
  • スケジュール詳細
    • 人員確保のスケジュール、資金管理など
  • 開発標準(文書のフォーマットなど)

外部設計

• 外部設計の目的

  • 外部設計では、基本設計で明らかになった機能を開発の単位(開発グループや個人の単位)に分割し、それらの機能間のインターフェースを定義する。また、各機能から共通に使用する機能の設計を行う。
  • 外部設計のゴールは、開発グループや個人の単位にタスクを割り振ることができる状態にすることだろう。あなたたちはこういうものを作ってね。入出力の仕様はこうで、必要とされる性能はこうだよ、といえるようにすることだ。これで、個人やグループごとに担当する機能を開発することが可能になる。

• 外部設計で決めるべき内容

  • 機能間連携
    • 機能間のインターフェース
    • 外部モジュールとの連携仕様
    • 画面遷移図や画面レイアウトなど
  • 全体で使用する部分の設計
    • DB設計。ER図やテーブル定義書
    • プログラム設計(フレームワーク導入など)
  • 各機能のスペック定義
    • 性能や制約

内部設計

• 目的

  • 個人あるいはグループが、担当する機能を開発するために必要なことを定義する。詳細設計ともいう。
  • 内部設計(あるいは詳細設計)においては、実態と設計書の乖離が少なくなるのが理想ではなかろうか？ 例えば、メソッドの引数や戻り値は、入出力の設計そのものであるから、コードの書き方を工夫し、設計とコードを同一にしたい。そうなれば設計書のメンテナンスといった作業は不要になる。

• 内部設計で決めるべき内容

  • 入力仕様詳細
    • 外部設計で決めない細かなこと(デフォルト入力値の定義など)
  • 出力仕様詳細
    • 外部設計で決めない細かなこと(エラー時の振る舞いの定義など)
  • 処理の流れ
    • コードから処理の流れが読めない場合。

終わりに

• 以上、自分の考えを整理するために書いたが、何らかの形で誰かの役に立てば嬉しい。