急がば回れ──質の良い仕様書の作り方：企業システム戦略の基礎知識（4）（2/2 ページ）

[青島 弘幸，＠IT]

応答時間という麻薬

　仕様書の主な要素には、「機能」のほかに「性能」がある。いわゆる、応答時間のことだ。利用者にとって応答時間は速ければ速いに越したことはない。ただしそれが、開発費用・期間に何の影響もなければという条件付きの話だ。

　実際には、応答時間による作業効率向上が、どれだけ利益に結び付くのかを、それに支払う対価と相関的に評価しなければならない。利用者からすれば、応答時間は麻薬のようなもので、どんどん要求はエスカレートしていく。最初は、10秒くらいで十分のつもりが、5秒、3秒、1秒以下と要求は止まるところを知らない。一度、応答時間1秒の世界に慣れてしまうと、3秒は非常に遅く感じるものだ。

　しかし、冷静に考えると、応答時間2秒の差が、どれだけ作業効率に影響を与えるのだろうか。確かに遅いとイライラするが大して差はない。よく高速道路で120km/hで飛ばしている人がいるが、100km/hと比べても、到着時間は大して違わない。それと同じで応答時間の速いシステムは疲れるうえに、作業効率に大きな差は出ないのである。

　ところが、仕様書に応答時間10秒以内と書くのと、3秒以内と書くのでは、ハードウェア／ソフトウェアの投資額が1けたも違ってしまうことが少なくない。扱うデータ量、同時利用者数、最大利用者数、平均利用量、最大利用量を、ビジネスの面から投資採算性が妥当であるかを確認することを怠ってはならない。

新技術の光と影

　最近のIT革新は目覚ましく、次から次へと新技術が出てくる。果たして、それは本当に役立つのか。その答えはYesでもあり、Noでもあるというのが正直なところだ。例えば、インターネットを介して　自宅から公立図書館の蔵書を検索できるようになったことは、本当に便利だと思う。一方で、オフィススイート・ソフトなど、新機能の半分も使っていない。5年前のワープロソフトでも十分な機能を持ち、仕事に支障はない。

　必要もないのに、新技術を採用してプロジェクトが遅延したり、余分な開発費用がかかったりしないように、それらの新技術が本当に役立つかをビジネスの視点から考えなければならない。そのときに大切なのは、表面的な技術論ではなく「ITの本質」の項で述べたように「読み・書き・そろばん」に対して、どこが、どのように、優位になるのか。その優位性は、自社のビジョンを実現するために、どのように役立つのかを考える。

【関連記事】
【ITの本質】IT投資を失敗させる“3つの落とし穴”（＠IT情報マネジメント > 情報化戦略・投資）

　例えば、情報をリアルタイムに共有できる新技術では、時間的・空間的な制約を超えて情報共有が実現できるが、それがビジョンの実現にとって、どんな優位性をもたらすのか。営業担当者が入手した情報を、社外からリアルタイムでシステムに入力し、社内外で共有できることが競争優位をもたらすのか。そうでないなら、翌日出社して、机のパソコンから入力すればよく、新技術を採用する理由はない。

　単に新技術を採用した画期的なシステムを構築したいという「思い」だけで、仕様書に「携帯端末を利用し、社外からのデータ入力ができること」などと書くより「24時間以内に、営業情報を社内外で共有できること」と書く方がよい。あくまで、ビジネス上の目的だけを示し、それを実現するために、どんな技術を採用するかは専門家に提案してもらえばよい。

「要求」どおりの「仕様」にならない理由

　ソフトウェアに対する要求仕様は、とかくあいまいになりがちである。いざ、蓋を開けてみると、思っていたものと違う動作をするソフトウェアができてきたりする。

　特に想定していなかった事態が発生したときにこういったことが起こりやすい。通常「要求」というのは、ある条件の場合に、このように処理してほしいというようなことを考える。例えば「計算の結果の上限値は、100を超えないようにする。」という要求は、明確に記述されている。

　ところがコンピュータは困ったもので「100を超えたときには、どうするのか」を決めてやらないと、そこで考え込んでしまうか、仕事を放り出してしまう。そういった場合、画面が応答しなくなったり、突然、真っ黒な画面になったりする。

　要求事項には、必ず表と裏があるものだが、コンピュータは、それを厳密に必要とする。人は例外事項に対し臨機応変に対応してくれるが、コンピュータはしょせん機械でしかない。例えば「条件A、条件B、条件Cを満足する場合に、ある処理をせよ」という仕様では、A、B、Cすべての条件に対する真偽の組み合わせは、2×2×2の8通りだ。

	A：真　B：真　C：真	A：偽　B：真　C：偽
	A：真　B：真　C：偽	A：偽　B：真　C：真
	A：真　B：偽　C：偽	A：偽　B：偽　C：真
	A：真　B：偽　C：真	A：偽　B：偽　C：偽

　しかし、この記述では最初の組み合わせに対する処理だけを定義したにすぎず、残りの組み合わせに対する処理は、設計者やプログラマの判断に委ねてしまうことになる。そして、彼らは、親切に確認の質問をしてくれることもあるが、納期と予算のプレッシャーの中では、彼らの持つ「業務知識」で推測して処理を決定してしまう。なぜなら、すべての条件を決定しないとコンピュータはいうことを聞かないので、彼らの仕事が終わらないからだ。

　開発者に思ったとおりのシステムを構築してほしければ、めんどくさがらず、1つ1つ仕様を確認する必要がある。

　次回は、上手な予算の使い方について解説しよう。

著者紹介

▼著者名　青島 弘幸（あおしま ひろゆき）

「企業システム戦略家」（企業システム戦略研究会代表）

日本システムアナリスト協会正会員、経済産業省認定　高度情報処理技術者（システムアナリスト、プロジェクトマネージャ、システム監査技術者）

大手製造業のシステム部門にて、20年以上、生産管理システムを中心に多数のシステム開発・保守を手掛けるとともに、システム開発標準策定、ファンクションポイント法による見積もり基準の策定、汎用ソフトウェア部品の開発など「最小の投資で最大の効果を得、会社を強くする」システム戦略の研究・実践に一貫して取り組んでいる。趣味は、乗馬、空手道、速読。

「システム構築駆け込み寺」を運営している。

メールアドレス：[e-mail]