第2回　ソフトウェア業界のビジネスモデルと有名企業を知る

古川昌幸（野村総合研究所）
2009/8/27

一口にIT業界といってもさまざま。IT・ソフトウェア業界の構造と仕事内容、働く人について説明する。IT業界に就職したい学生は必見だ。

第1回｜1　2｜次のページ

■ ソフトウェア業界のビジネスモデル

　前回の記事「売り上げ11兆円、従事者38万人のIT業界を3分類」では、IT業界全体を概観したが、今回はその中でもソフトウェア業界について、もう少し詳しく見ていくことにしよう。

　ソフトウェア業界の顧客は、企業および個人である。個人の場合は、例えば皆さんがパソコンを購入した際、ワープロソフトやゲームソフトなども一緒に購入した経験があると思うのでイメージしやすいだろう。それ以外に、インターネットを通じて音楽をダウンロードしたり、オンラインショッピングを利用したり、ニュースサイトを見て情報を収集したりと、有料・無料にかかわらず企業が提供するサービスを利用した経験も多いだろう。このようなサービスは、ソフトウェア業界の企業がサービス提供企業から委託されて、情報システムを構築し提供している場合がほとんどである。

　それに対して、一般の企業が、自社業務の効率化を目的として情報システム化をする場合、個人の場合と同様、ソフトウェア業界にその構築を委託したり、最近では利用料支払形式の共同利用型サービス（ASP／SaaS）を使う場合などがある。

　これをソフトウェア業界の企業から見たビジネスモデルとしてとらえ直してみると、大きく2つのモデルに整理することができる。1つは、特定企業の事業目的のために委託されて情報システムの構築や維持・運用のための費用を対価としてもらうケース。もう1つは、自分たちのアイデアを製品やサービスという形で作り、不特定の企業や個人に提供し、対価として代金を受け取るケースである。

　前者のビジネスモデルは、一般にシステムインテグレータやアウトソーサのビジネスモデルであり、後者のビジネスモデルは、パッケージ製品を販売する企業のビジネスモデルである。いずれにしても、ソフトウェア業界の仕事は、情報システムを作る「モノ作り」とその周辺の仕事ということだ。

■ 情報システム構築の工程

　実際に情報システムを構築する場合、どのように行っているのだろうか。企業向けの業務システムを構築するノウハウとして古くから知られる「ウォーターフォール型開発」のプロセスに当てはめて説明することにしよう。

　ウォーターフォール型は水が高い所から低い所に流れていく姿をモチーフに、大きく上流工程、下流工程という2つの工程で構成されている。上流工程は主に設計工程である。下流工程は、上流工程で設計された機能を実現するプログラムを設計・開発し、動作確認のテストを行い、企業にシステムを導入して稼働させる工程である。

　これらの工程で行っている「設計」や「開発」とは具体的にどんな作業なのだろうか。システムエンジニア向けには本やWebサイトで解説しているので、ここでは簡単なエッセンスにとどめておくことにする。

◇

（0）システム化構想

　まず、情報システムの設計を行う前に、「なぜこの情報システムを作るのか」という目的と「どの範囲の業務を対象とするのか」というスコープ（範囲）の設定、「いつまでに作るのか」というスケジュール、「どのくらいの費用をかけるのか」というコストの概観を決め、構想書として作成する。ここでは、あくまでも目安として整理しておき、具体的な計画書はシステム要件定義終了後に作成する。

（1）システム要件定義

　情報システムを作るにも、まず「何をしたいのか」を明らかにしないと何を作っていいのかも分からない。そのためには、この情報システムが使われる業務がどのようなものかをきちんと理解しておく必要があり、「業務フロー」と呼ばれる業務の流れ、手順を整理したものをドキュメントとして作成する。その業務の流れや手順において、どこで情報システムを利用するのか、すなわち、コンピュータの画面に入力する手順やコンピュータから出力された画面や印刷物との照合作業や確認作業、あるいは印刷物を顧客に渡すフローなどをきちんと記しておくのである。このような業務と情報システムの関連付けを行う中で、どのようなデータベースが必要となるかについても明らかにしておく。

　これ以外にも、コンピュータに入力してから何秒以内に結果を返すといった性能に関する要求やセキュリティに関する要件なども明らかにしておき、「システム要件定義書」としてドキュメントを作成する。

（2）外部設計・基本設計

　システム要件定義書に従って、コンピュータへの入力を行う個所では、その入力画面を1画面にするのか、複数の入力画面にするのかといった体系から始まり、画面のデザイン、画面で入力する項目の定義、金額など数字を入力する項目の場合にはそのけた数を定めるといったことが設計作業である。コンピュータからの出力画面や印刷物についても同様な設計を行い、それを「外部設計書」としてドキュメントにまとめる。また、入力されたデータとデータベースの情報を使って、どのような処理を行うかを機能としてくくり出し明確にすることを機能設計と呼び、これをプロジェクト（サブシステム）ごとに「基本設計書」としてドキュメントを作成する。このとき注意しておくことは、コンピュータとしてエラーにすべき条件を明確に記しておくことである。

（3）内部設計（詳細設計）

　基本設計書で設計された機能を基に、主にプログラム単位で機能の構造設計を行う。分かりやすくいうと、画面から入力されたデータをビジネスルールに沿って処理して結果を返すメイン処理を行うプログラムと、複数の業務や機能で共通的に使われる機能、例えば、「今日は銀行営業日かどうか判定する」プログラムのようなサブルーチンのように、階層構造を持たせる「構造化プログラミング」の設計を行い、「内部設計書」（詳細設計書）としてドキュメント化する。

（4）プログラム開発（コーディング）

　プログラムごとに実現する機能を設計した内部設計書と対になるように、プログラムを開発する。業務アプリケーションはいまだに開発言語としてCOBOLを使うところも多いが、数年前からWeb系のシステムではJavaを使うことがかなり一般的になってきた。最近では、この工程を人月単価の安い中国やベトナムなどのオフショアに委託するオフショア開発が普及している。

第1回｜1　2｜次のページ