SaaSは別のシステムと連携できる

SaaSを導入すると、別のシステムと連携したくなることも多いかと思います。多くのSaaSではWeb APIによるシステム間連携のインターフェイスが用意されています。これを使うとSaaSもシステム間の接続が行えます。このWeb APIを利用した比較的小さなプログラムを作成することで、相当な自由度で連携が可能です。連携相手は、既存の業務システム、別のSaaS、ExcelマクロやAccessで作った自社ツールなどになるかと思います。少し応用して、メールの受信から自動的にデータを登録したり、特定のイベント（例えば登録されたデータが一定の閾値を超えたときや、特定の状態になったとき）にメールやSMS（ショートメッセージサービス）を送信したりすることもできます。

Web APIとは何か

前述のとおり、SaaSには多くの場合システム間連携用のWeb APIが提供されています。Web APIとは、別のシステムからそのサービスのソフトウェア機能を呼び出すための窓口（プログラムインターフェイス）のことです。これにより、外部のシステムから、データ登録や取得、システム機能の実行など、SaaSが提供する機能を呼び出すことができます。

通常のWebのインターフェイスもWeb APIも、そのサーバーの実装からすれば外部から呼び出されるという点では同じです。通常のWebとWeb APIの技術的な違いは、Webは提供相手が「ブラウザ（を操作する人）」であるのに対して、Web APIは「別のシステム」である点になります。Web APIは、ブラウザに表示する画面そのものであるHTMLではなく、処理結果のデータだけを返却します。

Web APIの方式

現代のWeb APIはRESTと呼ばれる方式が最も一般的です。RESTは、多くの場合JSONと呼ばれるごく単純なリクエストとレスポンスを前提に機能呼び出しを行う仕組みです。
対してSOAPと呼ばれるXMLベースの仕組みも存在します。SOAPはXML技術とともに20年ほど前に流行した方式です。
SOAPは業務利用を強く意識された設計で、サービスの機能を言語化する技術も用意されました。高機能であり、自動的な接続を志向する節もあり当時は近未来的だったのですが、システム間連携を行うだけの用途なら高機能すぎて使いにいとされ、よりシンプルで現実的なRESTにほぼ置き換わってしまいました。これは残念なことなのですが、ソフトウェアエンジニアリングの業界全体で、自動的なシステム間接続はあきらめた（方向が違った）ということだと思います。
RESTを採用するWeb APIは、パラメータの形式、レスポンスの具体的な形式に厳格な規範はありません。システム毎にエンジニア向けのドキュメントが作成され、それを利用者（エンジニア）が読んで呼び出しプログラムを作成することになります。

Web APIの認証

サーバーが正しいユーザーであることを適切に判定する方法「認証」は、Web APIを提供するサービスにより個別に設計されています。とは言っても多くの場合、SaaSが専用のAPIや別の方法でIDとシークレットキーを発行し、呼び出し側が全てのAPIの呼び出し毎にこの2つをサーバーに送信する方式が一般的です。シークレットキーはパスワードに相当する概念ですが、長いランダムな文字列が採用されます。このシークレットキーはもちろんSSLで暗号化された通信で受け渡しが行われます。

システム連携の他の方法

SaaSのシステム間連携では、Web APIではなくファイル転送により連携する方法が採用されていることもあります。ファイルを渡すことで、そのファイルを処理するのです。システム間でファイルを渡す方式は次の4パターンが一般的なのですが、SaaSでは多くの場合(1)か(2)が採用されています。

• (1)POSTによるアップロード
  ブラウザベースのWeb画面でファイルをアップロードするときと同じテクノロジによる手法です。SaaSのサーバープログラムはアップロードされたファイルを受け取り、ファイルを処理します。
• (2)SFTPによるファイル転送
  SFTPと呼ばれるセキュアなファイル転送プロトコルを使ってファイルを渡す方式です。サーバーはファイルを受信したら、その受信自体や別のWeb API呼び出しを契機にファイルを処理します。
• (3)AWSのS3を使う方法
  Amazon Web Services(AWS)のストレージサービスを使う方法です。バケット(保存先)、アクセスキー、シークレットキーの3点の情報を元にファイルを送信できます。サーバーはファイルの到着を監視するか、別のWeb API呼び出しを契機に処理を開始します。
• (4)その他のツール
  上記以外にもいくつかのベンダーからシステム間連携に使えるファイル転送ツールが提供されています。これらのツールは過去に上記(1)～(3)が存在していなかったりまだ一般的ではなかったころの名残りなのですが、安定動作や障害対策の仕組みが加わっておりSaaS以外のシステム間連携では根強く使われています。

SaaSのフォーム入力データの連携で注意すべきこと

SaaSでフォーム画面等で入力・更新を行ったデータを外部システムに連携する場合、更新日時を利用して連携の要否を自動判定するケースが多くなります。このときデータの削除の連携には注意が必要です。SaaSからデータを削除すると単に削除されるだけのケースが多く、その場合はこの「削除」した事実を他のシステムに連携する方法がないのです。データの削除を他のシステムに連携する際は、データを物理削除せずに論理削除することで、データ削除を更新として連携する等の工夫が必要になります。

障害時を想定した設計が必要

SaaSは連続稼働が前提となっていない場合が多いです。SaaSではよく稼働率が明示されていますが、例えば稼働率は99.9%以上と明示されている場合、1ヶ月間では43分ほど停止しても基準内ということになります。夜間にメンテナンスのために計画停止するケースがあるのはもちろんのこと、障害により日中に停止するケースもあり得ます。
システム間のデータ連携を自動化する場合は、SaaSが停止することも考慮して設計する必要があります。データを漏れなく取得するのであれば、どこまで取得したかを別の仕組みに記録し、そこから開始する方法が有効です。データを漏れなく登録するのであれば、エラーが発生することを前提に自動的なリトライを行うなどの仕組みを検討することになります。また、エラー時に自動復旧が難しい場合は、システム管理者に自動で障害を伝えるメールやSMSを自動送信する等の方法も必要になります。

システム間連携の運用方法

システム間の連携はクラウドで実行する方法が最も一般的です。もちろんクラウドで自動実行する場合は、そのサーバー自体もハードウェア障害等で停止する可能性があるので、万全を期す場合はクラウドのサーバーも二重化し単一障害点を作らない方法を採用します。この場合、2台のサーバーが協調して動作するように設計します。処理時間が長くない場合、DBを使うとこれを実現できます。処理の開始時に特定のレコードをロックし、ロックできたら処理を実行し、完了したらロックを解除する方式をとるのです。これにより2つのサーバーで同時実行を避けつつ、片方のサーバーが障害で停止しても、システム間連携を安全に稼働させることができます。
連携の実行が手動で良ければ、Windows PC用に連携プログラムを作成する方法もあります。手作業にはなりますが、連携プログラムが実行結果を表示するようにすれば、成功・失敗を実行時に確認できるので運用も簡単です。

業務システムの開発において、データベース設計はシステム全体の優劣やコスト、さらにはシステムの寿命をも左右する重要な作業です。このコラムでは、データベース設計で重視すべきことを解説し、設計の手順と作成すべきドキュメントについて説明します。

【データベース設計で重要なこと】

業務システムにおいて、データベース設計で重視すべきポイントは次の3点です。

1. 1.将来性に影響：自然な構造で適切に正規化されており、現実のデータ構造と乖離がないこと
2. 2.生産性に影響：理解しやすい構造であり、ドキュメントが整備されていること
3. 3.安定稼働に影響：性能確保や排他制御、大きすぎないサイズ等、システムの実行面で無理がないこと

以下、１つずつ解説します。

1.将来性に影響：自然な構造で適切に正規化されており、現実のデータ構造と乖離がないこと

業務システムは運用を開始した後も業務の見直しなどにより変更の要求が発生することが普通です。変更の要件がデータベースのデータ構造に及んだ時、元の構造が適切に正規化されていて、かつ現実のデータ構造と乖離がないようにすると、無駄な変更を抑えることができます。以下に簡単な例を挙げて説明します。

★実業務の概念とデータベース設計に乖離がある悪い例

※商品と部品が１つのテーブル「在庫」で管理されています。
システムが小さいうちは問題になりにくいのですが、次のようなときに設計の見直しが必要になってきます。
・商品の場合に必要な項目を追加（例：売価）
・部品の場合に関係を持つ別テーブルの追加（例：調達先）

★正規化ができていない悪い例

※この例ではオプションのIDと料金が2組になっています。
将来オプションの管理項目（例えば、オプション半額キャンペーン適用）が増えたり、オプションの設定可能数が3点以上に増えたりすると、システムの変更規模が大きくなります。

2.生産性に影響：理解しやすい構造であり、ドキュメントが整備されていること

データベースにアクセスするプログラムを設計・実装するには、そのシステムのデータベース構造を理解する必要があります。勘違いがあると致命的なバグを作りこむ可能性が高くなるからです。データベースが自然で理解しやすい構造で、またドキュメントがしっかり整備されていると、プログラム開発時の生産性を確保しやすくなります。

3.安定稼働に影響：性能確保や排他制御、大きすぎないサイズ等、システムの実行面で無理がないこと

データベースは、どんなに理論的に正しくても無理な箇所がないように設計しなくてはいけません。例えば次のような事象を避ける必要があります。

• （たとえ現実にフィットした構造でも）関係が複雑すぎてデータ取得のクエリー（SQL）が複雑になってしまう
• テーブルのデータ件数が多すぎてクエリーの実行速度が確保できない
• （テーブルの項目数が多い場合に）検索対象が多すぎてインデックスのサイズが大きくなりすぎる

【データベース設計の進め方】

1.データベースの知識を得る

大前提としてデータベースの仕組みをよく理解する必要があります。一般ユーザー向けに作られているツールとは違い、データベースシステムは簡単を目標にしたものではありません。使う側のエンジニアがデータベースシステムをよく理解したうえで適切に利用することが前提となっています。
このコラムで扱っているデータベースとはリレーショナルデータベース（関係モデルのデータベース）を指しているのですが、そもそもリレーショナルデータベースは「性能が出にくい」かつ「癖が強いもの」なのです。
データベースの設計の良しあしはシステム全体の良しあしに波及するため、業務システムの構築にあたっては知識が不足した状態でデータベースの設計に手を出すべきではありません。もし十分な知識や経験がないのにデータベース設計を行うのなら、必ずデータベースをよく理解し、経験を積んだ上級エンジニアの指導やレビューを受けてください。

2.業務とシステム仕様を理解する

「データベース設計で重要なこと」でデータベースは自然な構造になっていることが大事だと述べました。自然な構造に設計するには、業務とシステム仕様を十分理解していることが必要です。例えばシステム仕様は理解したが、その背景の業務が分からない状態でデータベース設計を行うと、初期実装は無事に完了するかもしれませんが、データ構造が現実と乖離する可能性が高く、少々の変更で変更コストが跳ね上がるシステムができるかもしれません。よいシステムを作るために大事なのは「動けばいい」と考えないことです。「あるべき姿」を常に模索する必要があるのです。

3.テーブルを見いだす

データの管理単位であるテーブルを見いだす作業を行います。テーブルは商品、売上、売上明細、等のデータの管理単位に合わせます。データの用途が説明しやすい１つの単位であり、データの単位が明確であることが条件になります。データの単位とは、「売上」の発生毎に1件、売れた商品毎に１件などのデータの発生・管理単位のことです。

4.テーブルの主キーを設定し、テーブル間の関係を明らかにする

この作業がDB設計のヤマ場です。次の4-1～4-5を行います。

4-1.見いだしたテーブルに主キーを設定する

主キーとはテーブル内の１データを一意に決定する項目のことです。
主キーは業務で使うデータ項目をそのまま指定するナチュラルキーと呼ばれる手法と
主キーのために項目を追加するサロゲートキーと呼ばれる手法があります。
ナチュラルキーは業務データそのものであるため分かりやすい反面、いくつかのデメリットがあるので採用するときは気を付けて下さい。
・主キー項目の更新がしにくい（例：メールアドレスは会員をユニークに識別できますが、変更の可能性があります。主キーは他のテーブルからのそのデータを参照するためによく使われます。つまり値を変更する用途に向いていません。）
・主キーが複数の項目からなる複合キーになりがちでクエリーがその分長くなる
・ユニークに見えても実は違う可能性がある（例：書籍のISBNコードは使い回されていることが知られています）
・将来の運用が不明な場合がある（例：部門コードは部門に対してユニークに設定されるでしょうが、未来永劫までユニークに運用されるとは考えない方が無難です）
明確にナチュラルキーが良いと確信できるとき以外はサロゲートキーを使うことをお勧めします。

4-2.テーブル間の関係を明らかにする

テーブル間の関係を明らかにします。1:1、1:Nの関係が基本となります。N:Mの関係は中間テーブルを使い、1:Nの関係に整理します。
テーブルの関係はER図に整理・記述します。ER図はテーブル内の項目を記述することが一般的なのですが、全体が表現しにくい場合は、項目の記述を省略してテーブル名のみを書く方法で良いと思います。項目の表記より全体を見渡せることの方がデータベース構造の理解のために重要だからです。

4-3.正規化の観点でテーブル構造を見直す

テーブルの関係性を設計する際、データの重複をなくし矛盾が発生しにくい整理された構造とするために、正規化の概念が役に立ちます。正規化では、繰り返し項目を別テーブルにし、従属する内容（たとえば、売上明細における商品名）を別テーブルに切り出す等の作業を行います。
正規化は杓子定規に行うのではなく、現実を踏まえて判断します。たとえば、自社の採用活動をシステム化するなら、転職歴が少ない人のみを採用する会社であっても応募者データと職歴データは別テーブルにすべきだと思いますが、連絡先電話番号を最大2項目登録可能とする場合は、将来3項目以上に増やす可能性は低いので、繰り返しの項目ではあるのですが別テーブルには切り出さずに、応募者テーブルに2項目用意する方が単純で望ましいでしょう。

4-4.物理的に無理がないか検討し、現実的な構造に調整する

データ件数が多すぎたり、項目数が多すぎたりする箇所を調整します。また、テーブルに格納するデータに偏りがある場合もテーブルの分割を検討します。
いくつか例を挙げます。

・スマホを使った会員システムで、様々な条件で会員を選んで記事を配信する場合、どの会員にどの記事を配信するかをテーブルに格納することになりますが、このテーブルは（記事×配信対象）の件数になります。例えば、このテーブルを会員IDと記事IDの2項目にすることで（つまり他の項目を配置しないことで）テーブルのサイズを小さくできます。また、記事のタイプ毎にテーブルを分ける方法で、１テーブルの件数を抑える設計も考えられます。

・例えば多数の個人情報の項目を持つ会員テーブルを考えるとき、多くの会員は個人情報を記録せず、一部の会員だけが個人情報を記録するなら、個人情報を個人情報テーブルに切り出すと会員テーブルが扱いやすくなります。

4-5.参照整合性制約を設計する

テーブル間で参照整合性制約を設定するかを決定します。参照整合性制約とは、参照されているデータは存在が必須であり、また削除できないようにする制約です。たとえば、商品カテゴリAを参照している商品データBBBがあるとき、Aは存在している必要があり、参照されている限り削除できません。

5.テーブルの項目を整理し、検索に使う項目にインデックスを設定する

テーブルに全ての項目を配置し、項目に適切なデータ型、ユニーク制約、NotNull属性を決定します。さらに外部キー（主キーを参照する項目）と検索で使う項目にインデックスを設定します。
尚、ユニーク制約は本当にユニークになるのかを確認してください。例えば会員テーブルで退会者のデータを消さずに残す場合、同じメールアドレスで新規登録を受け付ける必要があるかもしれません。
項目値が入らないケースが多い項目にインデックスを設定するときは、NULLを許可することでインデックスのサイズを抑えることができます。（NULLはインデックスに記録されないからです。この仕様はDBによって異なります。お使いのDBの仕様を確認してください）

6.排他制御を設計する

デッドロックが発生しないようにデータ更新時の具体的な排他制御の方法を設計します。どのようなときにトランザクションを使い、どのレコードをどのようにロックするか、どのようなときに楽観的な排他制御を行うのかを設計します。

【データベース設計のドキュメント】

データベース設計は開発者全員が理解することが非常に重要です。そのためデータベース設計書のドキュメントは開発に参加する全員（少なくともデータベースにアクセスするコードを書く全員）が読み込むので、コストをかけてでも良好なものにする価値があります。

1.ER図

テーブル間の関連を書いた図です。私は下から上に参照するように（1:Nなら1が上、Nが下）書きます。書き方にはいくつか流儀があるのですが、大事なのは全体が見渡せることと、構造が理解しやすいことの2点です。
例を示します。

※悪い例（参照の方向がばらばら）

見ただけでは構造が把握しにくいのではないでしょうか。直したのが次の例です。

※良好な例（参照の方向が同じ）

どうでしょうか、関係が理解しやすいと思います。ある程度テーブル数が増えて、関係も増えてくるとテーブルとテーブルを結ぶ線が引きにくく、配置も難しくなります。なかなか骨の折れる作業なのですが、ハコの位置を調整したり書き方を工夫して理解しやすくすべきです。かけた以上のメリットが得られると思います。プロジェクトに参加するエンジニアが多いならなおさらです。
また、一般にER図の要件ではないのですが、テーブルの分類にあわせて色分けしたり、注意が必要な箇所にコメントを書くと、より理解しやすいER図になります。

2.テーブル設計書

テーブルと項目の設計書です。テーブル設計書は1テーブル毎に書くのではなく、全テーブルを1つのExcelシートに記述すると全体を見渡しやすくて便利です。また、コード設計は別資料に書くことが一般的なのですが、テーブル設計書に記述したほうが実装時の効率が良くなります。

3.排他制御ルール

複数のテーブルをまたがって整合性を保つ必要があるときはトランザクションとレコードロック等を使った排他制御を行うのですが、この排他制御はシステム全体で統一がとれていないとデッドロックが発生します。そのため、プログラマが守るべき排他制御のルールのドキュメントを作成します。※ロックについては別のコラムで解説します。

4.CRUD表

CRUD表はテーブル毎のレコードのCreate,Read,Update,Deleteがいつ行われるかを記述したマトリクス表です。これはデータの作成や更新のタイミングが分かりにくいときに作成します。CRUD表は単に作るだけの資料になりがちなので、作成前に本当に必要かどうかを考えると良いでしょう。

上記以外にも、事象に応じて保存データの状態が変わる場合や特徴的な要素があるときは、補足の説明資料を作成します。

【まとめ】

業務システムはデータベース設計の良しあしで決まると言っても過言ではありません。また、設計を理解しやすくするためのドキュメント類も重要です。業務システムの開発ではいろいろなドキュメントを作成しますが、最も重要なドキュメントは何かと聞かれれば、私は真っ先にER図とテーブル設計書を挙げます。この2つは完璧さが常に要求されます。

Webシステムのクライアント側（PC側）をExcelマクロ（VBA）で実装すると、表形式のデータをExcelシートで扱えるため、利便性の高いシステムを実現できます。

どのような方式か

Webシステムとはインターネットで利用できるシステムのことを指します。最も一般的なWebシステムはクライアント側にブラウザを利用しますが、Webシステムはブラウザが必須なわけではなく、このコラムでご紹介するようにExcelを使って実現することもできます。
（注：ブラウザで動作しているシステムがそのままExcelで動作するわけでありません）

Webシステムでブラウザを使う場合、ブラウザはサーバーが用意したHTMLを表示しJava Scriptで画面制御を行うことでユーザーインターフェイスを実現します。Excelを使う場合は、Excelマクロでサーバーから取得したデータをExcelシートに配置したり、ダイアログと呼ばれる画面を用いてユーザーインターフェイスを実現します。

Excelでファイルを開くときに「参照」ボタンのクリックでポップアップ表示される画面がダイアログの一例です。Excelマクロで独自デザインのダイアログを作成できます。

ブラウザを利用する場合のサーバーは、クライアントの要求に応じてHTMLを組み立ててレスポンスを返しますが、Excelを使う場合はクライアントの要求に応じて、HTMLではなく処理結果やデータだけを返す方法となります。Excelマクロはサーバーから取得したデータをExcelシートに貼り付けたり、表示を変更するわけです。

何が優れているのか

ユーザーの操作対象がExcelなので表形式のデータ操作に優れています。例えば指定した条件に合致する顧客データや売上データなどをExcelシートに取得できれば、Excelの機能を使うことでグラフを表示したり別のシートに転記したりすることが簡単です。

サーバー呼び出しはマクロで動作するので、一度システムができてしまえば、データ取得後に定型の業務処理、例えば月次の売上集計表をグラフ付きで別のExcelブックに出力し、関係者へのメール送信や印刷まで自動化するなど、業務に合わせた後からの拡張も難しくありません。

サーバー側の実現方法

サーバー側の開発はブラウザを使うシステムに比べ、画面（HTML）の作成を行わない分シンプルです。具体的にはExcelマクロから呼び出されるAPIを開発・配置することになります。APIの呼び出しはブラウザ用のシステムと同様に暗号化を伴うHTTPS通信が使えます。返却するデータはHTMLではなくJSONと呼ばれるシンプルな形式です。APIは(1)要求を受け付けて(2)サーバー処理を行い(3)結果を返すものなので、要件が合うならExcelに限らず他の用途、例えばシステム間の連携と共用できます。

ログイン画面と認証

ログイン画面はExcelマクロで表示する方法がよいでしょう。利用者によりユーザーIDとパスワードが入力されログインボタンがクリックされたら、ExcelマクロからサーバーのログインAPIを呼び出します。サーバーのログインAPIは、Excelマクロから受け取ったユーザーID・パスワードをあらかじめデータベースに格納してあるものと照合することでユーザーを認証します。

認証が成功したら、サーバーAPIではトークンと呼ばれる長いランダムキーを生成し、データベースにユーザー情報と紐づけて保存してからレスポンスとして返却します。

トークンはExcelでもログアウトするまで管理し、ログイン以外の全てのAPI呼び出し時にパラメータとしてサーバーに送信します。サーバー側ではこのトークンを確認することで認証したユーザーであることを識別するのです。

自動アップデート

ブラウザベースのシステムはプログラムの実装は全てサーバー側にあるため、システムの更新はサーバープログラムの更新で行えますが、Excelを使った場合はExcelマクロの更新時はそのExcelブックを配布する必要があります。

Excelブックは手動で配布する方法もありますが、PCの台数が増えてくると運用コストが増加するため自動化が理想的です。アップデートの自動化は次をExcelマクロで実装し、ファイルをダウンロードするAPIと最新版のExcelブックをサーバーに配置することで行えます。

• (1)Excelマクロ起動時にサーバーにファイルの最新バージョンを問い合わせる
• (2)APIで必要なファイルをダウンロード
• (3)ダウンロードしたファイルを差し替え

(3)はExcelマクロ実行中のファイル差し替えはできないので、ローカルに配置したVBScriptで行います。このVBScriptはExcelの終了を待ってファイルをコピーし、Excelブックを起動しなおす簡単な内容です。

(1)はバージョンを問い合わせるAPIを実装しても良いのですが、最新のバージョン情報を記録したテキストファイルをサーバーに配置し(2)のAPIでダウンロードする方法をとるとシンプルです。

開発コスト

Excelマクロ（VBA）はプログラミング言語としては、他の最近のプログラミング言語（C#, Swift, Kotlin等）に比べると機能面で劣りますが、複雑なプログラムを書くのでなければ生産性やメンテナンス性に大差はありません。逆に開発後にエンドユーザーが（希望するなら）自力でメンテナンスできる点で優れています。

システム全体の開発コストは仕様次第ではあるのですが、Webシステムと比べて大きくは変わらないと考えてよいかと思います。また、Excelの機能を活用する部分に限っていえば大きくコストダウンできます。

エンドユーザー企業が、システム開発を発注するとき、最も注意すべきトラブルは、意図したシステムができないことだと思います。
有効な回避策はたった１つだけです。
「発注前に仕様が明記された資料をベンダーとユーザーで共有すること」
これにつきます。

【どうして意図したシステムができないトラブルが発生するのか】

意図したシステムができないトラブルは、ユーザーの期待とベンダーの予定がかみ合わないときに発生します。この状況に陥ったプロジェクトのほとんどは、見積もりが大きく不足しています。

「見積もりが大きく不足したシステム開発」ほど最悪なプロジェクトはありません。予算も期間も不足するため、様々な問題が発生します。

ベンダーの企業体質やプロマネの資質が良好ではない場合、実際に予算と期間が不足すると、ベンダーはコストを下げるために躍起になります。開発途中で気が付いた課題があっても、わずかでもコスト増になりそうな提案は行われず、安価かつ安易な解決方法が選択され続ける場合すらあります。

プロジェクトの途中で抜本的な対策が行われれるか、小手先の手法でまっとうな品質のシステムが完成するなら、まだ運が良いほうです。ただただ無理を押し通して、品質の悪いシステムが完成するケースを実際に見かけます。

「ベンダーが悪い」といえばその通りです。しかし、システム開発は事業目標の達成手段であることが普通で、計画どおり進まないのは何としても避ける必要があります。

【要件定義と提案書】

まっとうなベンダーであれば、システム開発を受注する際、システム規模が大きければ「要件定義」と呼ばれるシステム要件を明確化する作業フェーズを提案してきますし、逆に規模が小さければ「提案書」と呼ばれる資料を作成します。一般に前者は有償で、後者は無償で提供されるサービスです。

この要件定義書、または提案書で、ある程度荒い「仕様」を整理することになります。要件定義も提案書も決まったフォーマットはなく、作成者が個別に形式を吟味して作成するものです。

要件定義書、提案書は、「(1)どのような仕様のシステムを作るのかを明らかにすること」と、「(2)システムの開発規模を固定すること」の2つの目的を達成するために作成します。これに価格や納期の情報などが加わることで、以降の開発契約が可能になるのです。

ユーザーは、要件定義あるいは提案書の仕様案を確認することで、安心して発注することができます。

仮に上記を端折った場合、発注側からみれば要望通りのシステムが完成するかが曖昧であり、受注側からみれば、開発規模が不明であることになります。

【仕様不明確のまま見積もりを入手した場合】

たとえベンダーが仕様未確定で見積書を出してきても鵜呑みにせず、仕様案を要求すべきかと思います。要求すべきは、見積もり根拠等ではなく仕様案です。もし、無償で提案書を作成するベンダーが見つからなければ、有償でも作成すべきです。

システム開発フェーズの上流工程である要件定義あるいは提案書作成は、単に構想をシステム化するための初期作業というだけではなく、契約のために必要不可欠なフェーズなのです。

【要件定義/提案書の内容】

ここで一つ絶対に避けるべきパターンがあります。要件定義書あるいは提案書に、要求事項が書かれていて、どう具体化するかが書かれていないケースです。

ベンダーに提案を依頼するときの文書（いわゆる提案依頼書）であればそれでいいのですが、要件定義や提案書に要求事項だけが書かれている場合、「どのような仕様のシステムが完成するのか」も「開発規模」も明らかではないことになります。

例えば「在庫を的確に把握できること」は単に要求事項であり仕様案ではありません。

• 単に在庫の一覧が表示できれば良いだけかもしれません。
• 適切な分類ごとに数量と、平均の滞留期間をグラフ化する必要があるかもしれません。
• そもそも在庫を正確に把握するために入出庫を把握する仕組みから見直す必要があるかもしれません。

適切な要件定義書や提案書では、「在庫を的確に把握するための具体的な方法」が明らかにされます。詳細な設計書である必要はありません。少々荒くても画面の簡易スケッチと機能の説明が書かれていれば、大トラブルは避けられます。

一般に提案書は要件定義書より精度が劣りますが、この点については、提案書を受け取ったときに、打ち合わせで提案書をめくりながら細かく質問して埋める方法が良いでしょう。質問の大部分は「後から決定しても大丈夫」等の答えが返ってくるはずです。もちろん、質問の内容次第では、要件定義書や提案書の手直しが必要になるケースもありますが、それは必要な作業です。焦らず資料の更新を待ってください。

最近の業務用のWebシステムではグラフ表示を取り入れる機会が増えてきました。

　ほんの数年前はグラフ表示のライブラリは、高価だったり使いにくかったりと良いものが見当たらなかったのですが、現在は見た目も機能性も素晴らしいオープンソースのライブラリが多数登場してきています。

　私が最もWebの業務システムに適していると思うのはchart.jsと言うライブラリ。上のサンプルのとおり、デザイン性に優れています。グラフ表示の際のアニメーションも良好です。ライブラリ自体をサイトに配置するので、ライブラリのアップデートやサービス終了を気にすること無く運用できます。

　分析のためのグラフ描画は、どうしても大量のデータアクセスがついて回るので、設計には考慮が必要です。例えば、１年間の売上で商品種類毎の比率を見るには、１年間の全ての売上データにアクセスする必要があります。

　データ量が多い場合や同時利用数が多い場合等、どうしても負荷が高い場合は、業務用のデータベースサーバーと分析用のデータベースサーバーを分離する方法が有効です。現状でデータ量が少なく、ビジネスの成長と合わせてデータ量が増えていくことが見込まれる場合は、論理的に別サーバーで動作するようにデータベースを設計しておき、当初は１台のサーバーに配置する方式をとります。

WASAPIとASIOの概要

ビット深度の取り扱い

ビット深度についての詳しい解説

DSDの再生方式

WASAPIの共有モードと排他モード

結局どちらが優れているのか