この記事は「こちら」に移動しました。
【連載:モデリング修行 入門編

第1回 モデリングなしで開発はできない


篠原光太郎
2002/12/21


なぜいま、モデリング?

 

 

 これまで構築した中で最も大規模なシステムは、どんなシステムだったでしょうか? あるいは、一番複雑だったシステムは、どんなシステムだったでしょうか? そのシステムが、どのようなシステムだったか全体像を紹介していただけないでしょうか?

 このような依頼をされたときに、皆さんならどのように説明をしますか? ホワイトボードにシステムのブロック図を描いて説明してくださる方もいらっしゃるでしょうし、業務の流れの中で、システムの利用側面を言葉で説明してくださる方もいらっしゃるでしょう。はたまた、システムそのものを利用してデモしてくださる方もいらっしゃると思います。

 では次に、そのシステムの中で皆さんが担当した部分のみを切り出して、別のシステムとして作り直すとします。そのとき、元のシステムとの間で、どのようなデータのやりとりが必要になり、新しいシステムの全体像がどのようになるか描き直すことができますか? これは、システムの規模と皆さんが担当された役割によって違うと思いますが、システム全体にわたっての影響範囲に関しては、担当範囲外までは分からない、という人が多いのではないでしょうか。

 近年、ビジネスを支える情報システムは、大規模化、複雑化の一途をたどっており、部門用の小規模なシステム以外では複数名の担当者でプロジェクトチームを構成してシステム構築を行う場合が多いと思います。担当者も数名の小規模のチームであれば問題はないのですが、数十名を超えるようなプロジェクト規模になると、システムの全体像を担当者全員で共有することは、非常に困難になってきます。

図1 1つのシステムの認識の仕方は、担当者によって違う

 担当者1人が認識できるシステムの規模には、限界があります。これは、「通常の人なら」という限定が付きますが、私の経験では、テーブル数で100、画面数で50を超えると、全体を把握できる規模を超えます。仮にこれを超えてしまうと、どうなるかといえば、(1)1カ所の修正を反映する範囲が特定できなくなる(2)1つのエラーが発生したとき、同種のエラーが発生する可能性がある個所を特定できなくなる、など目に見える弊害が起き始めます。

 開発の現場にいらっしゃる方の中には、「え? もっと多くの画面を一度に扱っているよ」という方もいらっしゃるでしょう。でもそれは、例えば、順次開発を行って、結果として100画面になった、といった場合ではないでしょうか。仮に1画面の開発に3日間かかるとして、100画面の開発には300人日かかるわけです。月20人日として、1人でこなすとすれば、約15カ月の仕事ですよね。本当に15カ月前に開発した画面の詳細を覚えていて、ある障害が発生したときに、同種の障害の発生する可能性のある画面を思い出すことができるでしょうか?

 大規模なシステムの開発においては、1人で一度に認識ができる規模を優に超えてしまう場合が、昨今のシステム開発では日常茶飯事ではないでしょうか。このような状況を打破するためには、システムの全体像を把握でき、各構成部分の整合性を保つための何らかの仕組みが必要になってきます。

大規模システム開発には必須のモデリング

 

 

 
 そこで登場するのが、抽象化して全体を把握することを可能にする「モデリング」という技法になります。モデリングにはさまざまな定義がありますが、ここでは、業務やシステムを抽象化するためのテクニック、と定義します。

 モデル化して抽象化することによって、1人の人間が理解できる範囲は非常に広がります。このよい例が、地図です。地図にはさまざまなバリエーションがあります。縮尺の違いや目的によってさまざまな実測地図がありますし、実際の地形とは違う絵地図なども地図の1つですよね。地図は、用途によってさまざまなものを選択することができます。

図2 目的別のさまざまな地図は、地球のモデルである

 共通していえることは、縮尺が大きい地図は、同じ用紙に描ける範囲が広いということです。例えば、「A3」の大きさの用紙に縮尺を変えることで世界地図と日本地図の両方を描くことができます。A3の大きさの用紙に描かれた世界地図は、世界全体を見渡すことができます。アメリカは日本の東にあり、オーストラリアは日本の南にあることが一目瞭然で分かるわけです。A3の世界地図であれば、首都がその国のどの辺にあるのかも、ある程度は見当がつくでしょう。一方、A3の大きさの用紙に描かれた日本地図では、日本全土の4島の大きさが分かるだけではなく、都道府県の区切りや主要幹線道路がどのように敷かれているかも大体分かります。A3の日本地図では、アメリカやオーストラリアがどちらの方角にあるかは分かりませんが、東京都よりも神奈川県の方が広いことは、一目で分かるでしょう。

 モデリングをすることにより、細かな情報をそぎ落とし、その骨格となる部分のみ抽出をします。全体を把握するために、細かな情報は必要ないからです。全体を把握するためには、この骨格が非常に重要です。例えば、世界地図では、大陸と海の境界線や、国同士の境界線は、非常に重要な情報の1つでしょう。これらの境界線が紙の上に描かれているだけで、全世界の人々は、地球全体のイメージを持つことができます。これをシステム開発に置き換えたときにも、全体のイメージをシステム開発にかかわる多くの人が持てるということは、非常に重要であることが分かるでしょう。ソフトウェアシステムは特に、目には見えない「データ」という情報を取り扱うため、このモデリングという作業が非常に重要になってきます。

モデリングは難しい?

 

 

 
 モデリング、という言葉を聞いて、拒否反応を起こす人も多いのではないでしょうか。正直に申し上げて、「きれいなモデル」を作成するのは、非常に難しい作業です。きれいなモデルを作成することは、私の経験上では、得意な人と不得意な人がいます。でも、「モデル」を作成することは、だれにでもできることです。ちょっと、びっくりされましたか?

 モデリングは、アートに近い領域を持っています。モデルを作るということは、絵を描くということに似ています。絵は誰にでも描けますが、多くの人が美しいと思う絵、共感することができる絵を描ける人は、ごくわずかの限られた人ですよね。モデルも同様で、きれいなモデルを作成するのは非常に難しく、できるのは限られた人になります。ただし、情報システムの構築におけるモデルで必要になってくるのは、美しさではなく、誰にでも理解できる分かりやすさです。分かりやすい「モデル」を作成することは、コツさえつかめば、多くの人ができるようになるはずです。

図3 モデルは分かりやすさが命。標識は良い例の1つ

システム構築における「モデル」って何?

 



 「モデル」という言葉を聞いて、皆さんが思い浮かべるものにもいろいろとあると思います。情報システムの構築に範囲を狭めれば、「データモデル」や「オブジェクトモデル」もしくは、「ビジネスモデル」といった言葉を思い浮かべる方が多いのではないでしょうか。これらのモデルは、「モデル」と名前が付いている非常に分かりやすいモデルの例だと思いますが、皆さんが通常使われているツールの中にも、さまざまなモデルが存在します。

 例えば、「フローチャート」は非常にメジャーなツールだと思いますが、これはプログラムを抽象化したモデルと考えることができます。また、「機能ブロック図」については、プログラム構成のモデルと考えることができます。同様に、「業務マニュアル」や「規定」といったたぐいのものがあると思いますが、それらは業務そのものをモデル化したものと考えることができます。また、先ほど説明した絵地図や地下鉄の路線図も、モデルの1つですよね。

図4 フローチャートはプログラムのモデルの1つ

 このように、私たちは知らず知らずのうちに、モデリングを実生活の中でも実施、もしくは利用しているのです。このように考えると、システム構築におけるモデリングも身近に感じられませんか?

 この連載では、システム構築におけるモデルの中でも非常に重要な位置付けとなる「データモデル」について、事例を用いながら解説をしていきたいと考えています。ゴールは、「データモデリングという身近な事例を理解することで、モデリングという概念自体の効用を勘として会得する」ことにあります。つまり、「Welcome to Modeling World」というわけです。

モデリングによってできること

 




 データモデリングの話を進める前に、もう少し、情報システム構築におけるモデリングについて話をしたいと思います。情報システム構築はモデリングをしなければできないか、というと、そんなことはありません。冒頭でも説明したとおり、特に小規模なシステム構築であれば、モデリングをしなくても事は足ります。では、モデリングを行うことで得られるメリットは何でしょうか。その主なメリットは、次の4つだと考えられます。

  1. 多くの人とのコミュニケーション

  2. 論理的整合性検証

  3. システム最適構成検証

  4. 規模見積もり

 では、以下でモデリングのメリットについて考察をしてみます。

(1)コミュニケーションツールとしてのモデル

 システムを構築するうえで考慮すべき関係者は、主に次のような人がいると思います。

  • システムを利用する人(エンドユーザー)
  • システムへの投資を決定する人(意思決定者)
  • システムの要件をまとめる人
  • システムを設計する人
  • システムを開発する人
  • システムを運用・管理する人

 小規模なシステムの開発においては、これらの役割を兼任することが多いでしょう。例えば、システムを利用する人=システムを設計する人であったり、システムを設計する人=システムを開発する人=システムを運用・管理する人であったりということは、よくあるパターンです。

 これが、大規模なシステムになると、これらの役割は別の人になることが多く、さらにそれらの役割の中でもさまざまな事情によって、関係者がいっきに増えます。まず、システムを利用する人とシステムに投資をする人は、面識もないことが多くなります。システムを利用する人は、外注のデータ処理会社からの派遣社員かもしれません。システムの投資に対しての意思決定者は、会社の役員や、場合によっては社長ということになるでしょう。システムを構築する際には、これらの非常に幅広い関係者の思惑を、1つのシステムとして実現しなくてはなりません。もしくは、実現しないポイントに対して共通認識を持つ必要があります。

 また同様に、システムを利用する人とシステムを開発する人は、プロジェクトを通しても一度も顔を合わせないことも多いでしょう。システムを開発する人同士も、全員の顔を知っているかというと、かなりあやしいですね。また、最近のシステム構築の現場を考えると、それぞれの役割の人が、世界中に散らばっているということも多くなってきているのではないでしょうか。

 このような状況の中で、1つのシステムに対して共通の認識を持って構築を進めていくということは、非常に困難な状況になってきています。特に、意思決定者やエンドユーザーのシステム構築に対する目的や、その背景にある「当たり前」と思われるような前提事項の認識を合わせることは、システム構築を成功させるためには非常に重要なポイントになってきます。

 大規模なシステムに対しての共通認識を持つためには、システムの全体像を関係者間で理解するためのツールが必要になります。このためのツールが、各種のモデルということになります。モデル化は、関係者間のコミュニケーションに役立つツールとして、活用することが可能です。

(2)論理的整合性検証ツールとしてのモデル

 システム構築の一般的な進め方は、最初のフェイズで要件を定義し、その後のフェイズで要件を具体化しながらシステムを設計し、そして設計に基づきながら開発していくという流れになると思います。この要件とは、システムで実現されるべき項目の固まりです。また、意思決定者やユーザーは、この要件定義された項目がシステムにおいて実現されるという期待値になります。つまり、システム開発における契約内容が、要件といってもよいでしょう。

 よって、要件と実際に構築されるシステム機能の整合を保っていくのは、非常に重要です。意思決定者もユーザーも、要件として定義されていること以上のシステムは望まないでしょうし、逆に、そこに書かれている項目は実現されることが必須と考えています。要件に書かれている内容を忠実にシステムに落としていくことが、求められていることになります。

 ところが、実際のシステム構築においては、要件が概要設計書になり、概要設計書が詳細設計書になり、それを基にプログラムコードが書かれ、テストが終了し、システムが完成した時点では、それぞれの機能がどの要件に基づいて構築されたものか、明確にトラックできなくなっているケースが非常に多いのです。要件の定義はシステム構築の最初のフェイズで取りまとめられるものの、その後のフェイズにおいて、随時アップデートされているということはまれではないでしょうか。これでは、最終的に作られたコードの中には、どの要件に基づいて作られたのか分からない機能が、たくさんできてしまいます。

 大規模なシステムになると、システムの膨大な機能1つ1つと膨大な要件のマッピングをトラックしていくことは、非常に困難です。1000個の機能と、1000の要件をマッピングしようとすれば、そのマッピング表がどの程度の大きさになるかを考えれば、その困難さは容易に見当がつくと思います。この困難さが、要件のトラッキングがされない現実を引き起こしていると思います。

 これを可能にするのが、モデリング手法ということになります。業務とシステムをそれぞれ抽象化してモデルを作成し、抽象化することで簡易になったモデル間での整合性を保つことが可能になります。1つ1つの小さな要件と膨大なプログラムとの整合性を保つより、モデル間での整合性を取ることの方が非常に簡単です。また、モデル間での論理的整合性を保つことで、システムの骨格になる部分での整合性を取ることは可能であり、骨格レベルでの整合性はシステムの健全性を保つために非常に重要な要素になります。モデル化をすることは、システムの骨を作り、頑丈でかつ柔軟な体作りをするために役立ちます。

(3)システムの最適な構成を検証するためのツール

 大規模なシステムの計画段階においては、システム全体をサブシステムなどの単位に細分化する作業が必須になります。ところが、このシステムの細分化の作業自体の出来・不出来が、システム全体の出来・不出来を決めてしまうことが少なくありません。細分化の単位を間違ったシステムは、エンドユーザーに「不便」を強いるか、もしくは、それをシステムでカバーするために必要以上に複雑なプログラムコードを書くことが必要になります。

 システムの細分化以外にも、システム構築の計画において決定すべき事項は、数多くあります。また、システムの細分化と同様に、計画時点での決定事項が、後々、大きな影響を及ぼすものが多くあります。

 これらの出来の悪いシステム構築を防ぐためには、計画時点で多くの検証を行う必要があります。例えば、システムの細分化に関しては、数多くのパターンを用意し、各パターンにおいて、設計や開発の時点で予想されるメリットとデメリットを検証することが必要になります。

 このようなパターンによる検証を行うために、システムのモデル化が有効です。

(4)システム開発の規模を予測するためのツール

 大規模なシステムにおいては、システムの開発規模を計画時点で予測することが、非常に重要になります。計画時点での開発規模予測の精度は、最終的なシステムのリリースが予定どおりに行われるか否かを決定付ける重要なポイントの1つになります。

 システムの開発規模の予測をするためには、システムの構成要素ごとに規模を見積もることが必要になります。機能開発の規模を予測するためには、機能のモデルが必要になります。また、データベースの開発規模の予測にはデータモデルが1つの重要なインプットになります。モデルの要素ごとに見積もりを行うことで、計画時点で必要になる精度の見積もりを実施することが可能になります。
 
 よって、モデリングは、「あった方がいい」ではなく、「ないとシステム構築において欠陥を呼ぶ」必須の技法といっても過言ではないでしょう。

 今回は、「モデリング」の必要性とその効果についての話をしました。次回は、データモデリングに話を移して、データモデルの位置付けとその作成ステップをご紹介する予定です。

IT Architect 連載記事一覧


この記事に対するご意見をお寄せください managemail@atmarkit.co.jp

「ITmedia マーケティング」新着記事

「女の一生」リサーチまとめ
女性の思い描く「なりたい自分」、結婚の新常識、子育てに関して妻と夫の思惑は同じなの...

970x250のサイズで常にメディアのトップに広告を表示、ヒトクセが「Smart Canvas Billboard」を提供開始
ヒトクセは、同社のリッチメディア広告配信プラットフォーム「Smart Canvas」において、D...

「GenieeSSP」がネイティブ広告向け配信APIの提供を開始
ジーニーは、同社のインターネットメディアの広告収益最大化プラットフォーム「GenieeSSP...