ビジネスアナリシスを考える

ビジネスアナリシスを考える
－あらゆる課題や問題解決を実現する効果的なアプローチ－
（第４８回）
8.
情報システムとビジネスアナリシス
8.14 仕様書はだれが作るべきか
・情報システムの構築における技術的視点と、利用者と開発者との関係や連携について議論をし
てきましたが、ここでは視点を変えて、システム開発における利用者と開発者との関係において
種々の課題発生の基になっている仕様書について考えてみたいと思います。
・情報システムの構築において、利用者と開発者をつなぐ約束として種々の仕様書があります。仕
様書にはいくつかの異なる目的や段階がありますが、一般的にはまず利用者が開発者に対して
出す提案要求仕様書や引き合い仕様書があります。 引き合いは複数の開発者に対して出され
る競争入札と、指定された開発者だけに出される特命発注があります。 引き合いには開発しよう
とするシステムの機能や性能に関する要求や実施上の諸条件が記載されています。 それに対し
て開発者は見積書を提出して入札に応じます。 見積書は見積条件を記載した技術仕様と見積
価格との二つの部分から構成されているのが一般的です。 提出された見積仕様はまず技術審
査によって内容の確認がされ、不十分が認められた場合には修正を要求されますがそれが終わ
るまで見積価格は評価されません。 見積書の中で要求仕様に対して実施不可能な事項に対し
ては対象外の意思表示は許されますが、評価の対象になります。 本来見積要求の仕様書は客
観性を保つため発注者が作成することが原則ですが、コンサルタントなど第三者の支援を受けて
作成されることはよくあります。 見積評価に関しても同様ですが、決定権は発注者にあります。
大規模な案件に関しては、見積要求のための概念的な全体計画作成のためのエンジニアリング
が先行して発注されることがありますが、その後の発注に関する公平性の維持のために、仕様書
作成に参画した開発者は、システム本体の受注に参加できないこともあります。 特に公的機関
での引き合いに関して厳しく管理されますので、システムの構想や概念レベルの設計のような上
流から、実際の構築までを手掛けるシステム開発者にはどの時点から参画するべきかの微妙な
問題があります。 このような流れとは別に、開発者が自主的に利用者に対してシステム提案を
行うことは良くあります。
・このような計画の初期における仕様書は基本概念を決める基礎になりますが、詳細見積や実際
のシステム開発における仕様書などの契約上の拘束条件の基本になりますので、その記述と解
釈が後刻の多くの契約上の理解と解釈の基本となります。 基本的には、発注者である利用者が
要求仕様書を作成し、受注者である開発者がそれに対応する見積仕様書を作成すればよいので
すが、現実問題として両者の間の意思の疎通と理解の相違により発生する種々の問題を回避す
るためには、誰がどのようにして仕様書を作ることがよいのかを考えたいと思います。
1
■利害関係者ではなくパートナーとしての立場が必要
・公共機関による情報システム構築の発注は多くの場合競争入札の形をとりますが、一般企業で
の発注では特命発注の場合も多く、技術の継続性や連携の緊密性などの利点がありますが、一
方、マンネリ化による非効率や技術の固定化などの欠点も指摘されています。 競争入札と特命
発注とでは発注者と受注者との関係のありかたには自ずと微妙な違いがあります。
・競争入札では、見積もり回答が同じであれば、より安価な提案へ発注されるのが一般ですが、
最も判定が困難なのは開発者の技術力や実行力などの能力と製品の品質や性能、そして信頼
性です。 特にシステムやソフトウェアの場合には組織能力としても、製品品質としても使ってみな
ければ判定できないことが多く、組織能力は開発中のコミュニケーションでわかってきますが、製
品の品質に関しては検収条件で検査しても測定しきれないものが多くあります。 さらには、運用
してみないとわからないもの、利用を始めて初めて分かる不具合もあります。発注者側に技術力
がある場合には重要なシステムの構造や手法に関して設計レビューを実施し、承認事項とするこ
ともありますが、そのような能力を持つ発注者は限られています。 不具合が発見されたところで
修正すればよいという考えもありますが、性能などは修正が困難な場合も多く、利用に耐えないシ
ステムになることさえ見受けられます。 問題の発生によっては対外的なシステムでは外部利用
者に与える影響は計り知れない問題を含みますので、品質に対する信頼性は限りなく重要です。
・競争入札での発注者の決定後と特命発注での利用者と開発者との関係形態は似ていると言え
ます。 システム開発の実行仕様は見積仕様書が基本になりますが、契約書で詳細を決めなけ
ればなりません。 利用者は開発者に対してどのように協調し、協力すればよいかが課題です。
発注者と受注者という立場で、利害意識を強く持つならば相互に信頼のあるシステムを開発する
ことは困難であると考えるべきでしょう。 あくまでも長期的にシステムを育て、運用していく善良な
パートナーであるという意識が必要です。 信頼あるシステムを構築すれば両者にとって利益が
生まれ、さらに次の段階への進展が期待されます。
■仕様書の共同開発と共同責任を考える
・歴史的経緯を遡ってみますと、大型計算機の時代には利用者とシステムの提供者はほとんど固
定していて、それに伴うソフトウェアもほとんどがハードウェアにリンクしていました。 この状態は
技術の継続性や長期的視点からの計画性からは大きな利点でしたが、考え方や技術の固定化
や互換性の障壁に保護された競争排除による効率低下などの欠点もみられました。 処理システ
ムの分散化が進むにしたがってこの形態は崩れてゆき、新たなシステム提供者が自由に参入す
ることができ、システム基盤に依存しない汎用プログラムが普及しますと利用者は好みに応じてそ
れらを選択することができるようになりました。 このような利用者と提供者との関係になりますと、
システムの開発や選択は利用者主導になり、利用者と提供者との間は要求と契約という関係が
顕著になりましたが、一方では、新しい企業によって新しい概念による汎用システムが多数出現し、
システムに多くの革新をもたらしました。 一方では、導入したが期待した効果が得られないまま
2
その後の保守もされずに短命に終わり、捨てられるという現象が新たな問題として浮上しました。
そのようなシステムは、もともと利用者と開発者との関係は希薄でしたから利用上の長期的支援
が得られる関係ではありませんでした。
・このような契約形態になりますと、強固な計画やエンジニアリング力を持った利用組織はよいの
ですが、計画力の弱い組織では要求の作成能力が十分ではなく、開発者が期待するものと異な
るものができあがってくるという現象が起こります。 これが利用者と開発者の間の不信の要因と
なって多くの問題を起こす原因になったと言えます。
・情報システム普及の初期においては、利用者と開発者とは近くにいて、互いに相談しながらシス
テム開発をしていましたので開発者は業務の本質を理解できました。 不具合はすぐに修正でき
ました。 ビジネスの現場の人間より業務プロセスに詳しいシステム担当者も多く、新しい技術を
すぐに業務に反映したり、試験的に利用したりすることも容易にできました。
・システムが高度化あるいは複雑化して利用者と開発者が分離された現在、利用者と開発者とが
一緒に働くという原点に戻ることはできないのでしょうか。 利用者がシステム技術の総てを理解
することも、開発者がビジネスの総てを理解することもそれぞれの高度化と複雑化のために非常
に困難になっています。
・システム計画の初期から、利用者と開発者が一緒になって議論し、研究して、長期総合的視点
から最適なシステムを構築することは一つの理想であり、その原点は昔も今も変わっていないは
ずです。 ビジネスシステムが複雑になり、情報技術の多様化と高度化が進み、すべてを一緒に
議論することは無理だという意見もあります。 両者が最適な回答を持ち寄り、合意の上で着手す
ることが一つの手段かもしれません。 少なくとも、両者の理解の相違に起因する誤りは避けられ
るはずです。
・開発内容を合意した最終ドキュメントだけは両者が共同で作成して、共同責任であることを約束
できないでしょうか。 それでも小さな問題は日常的に起こりますがそれらはやはり共同責任で解
決することです。共同の実行監視組織を作り、推進状況の監視と課題の調整にあたることは、問
題発生の回避や早期解決のためにも効果的です。 問題が大きくなってから争っても何も得ること
はありません。二つに分かれてしまった組織を実務の上でもう一度一つにすることはできないので
しょうか。 分かれていることで無駄な境界問題が起こります。 本来不要な摩擦が起こります。
それらは建設的ではなく無駄なエネルギーの消費です。
・契約の透明性やコスト削減のための競争見積もりの原則が強調されるあまり、本来のシステム
開発の姿、利用者と開発者の信頼という形が崩壊してしまったのではないかと危惧されます。 契
約上のコンプライアンスという視点からの監視も強くなっています。 それらの問題を克服した上で
両者の信頼の構築は可能なはずです。
・残された問題は、開発者はシステム開発によって適切な利益を得なければならないことです。適
切な開発コストの合意は見積価格の評価になりますが、対象の難しさ、適用技術、能力、納期、そ
の他条件など多様な要素の相互の評価による合意しかありませんが、少なくとも前提となるシス
テムの要求仕様の理解問題は解消されているはずです。 システムの価格必要コストの積み上
3
げではなく、開発システムの価値から評価することが望ましい、と言えますが、この問題の解決は
今後の課題と言えます。
■利用者にとって目標はシステムを作ることではなく経営目標を実現すること
・利用者にとってはシステムを構築することは効果的な業務処理をするための手段を得ることであ
ってシステムそのものは目的ではありません。 本来の目標は経営の目標を達成することにあり
ます。 もちろん、良いシステムができればその活用によって経営目標に容易に近づくことができ
るでしょう。 言い換えれば、それを目標としてシステム構築を計画してきたのです。 システム構
築を事業とする人たちにとってシステムを構築することは目的であり、利用者にとっていかに良い
システムを作り上げるかが目標であることは本質的な目的であるはずです。 そのシステムを通じ
て利用者が成果を得ることです。 良いシステムとは付加価値の高いシステムであり、事業貢献
度の高いシステムでしょう。 システム事業者が発注者のことを考えた時に、何を目標としてその
システムを構築するかという理解によって、発注者にとってのシステムの価値が作りこまれます。
利用者はどのように使うのだろうか、どんな人達が使うのだろうか、どうすれば使い易いのだろう
か、利用が進めばどんな問題が起こる可能性があるだろうか、次の技術の変化はどんな影響を
与えるだろうか、利用者にとって最も効果的で、信頼性があり、コストの低いシステム構築の方法
は何であろうか、また信頼性が高く運用の容易なシステムとはどんなものであろうか、という意識
をもって考えれば多くの課題が浮かんできます。 そこまで考えられる構築者ならば、利用者との
トラブルは生じないはずです。 両者の目的は同じなのです。
■利用者によるシステム要求の明確な表現
・ビジネス概念の高度化と複雑化、そしてそれらの変化は著しく、当事者においてさえも正しく現状
を捉えることが困難な場合さえあります。 このようなビジネスシステムの支援のための情報シス
テムを構築し維持するためには、利用者は情報技術者に対してその要求をいかに正しく伝達でき
るかが鍵になりますし、それは利用者の重要な責任です。 システム要求に対する情報技術者の
理解不足が多々指摘されますが、理解不足を生まないような要求の明確な説明表現能力を養う
ことが利用者にとって非常に重要な課題です。 利用者と作成者の相互の正しい理解は両者の努
力と信頼の中で解決される問題であることを深く認識しなければなりません。
■契約の本当の精神を理解する
・発注者と受注者との関係は契約関係ですから、契約を守ることは当然の義務です。 では、契約
を守れば十分かというと、契約の本当の精神を守ることと理解しなければなりません。 それは当
事者同士の信頼関係の構築になります。 システムはほとんどの場合完成後の保守が必要です。
システムのライフサイクルにおいては構築時の１０倍の努力とコストが必要であるとも言われてい
ます。 それらの期間における問題解決を少しでも軽減するためには、契約書に書かれている事
項の本質的内容への配慮が役立つでしょう。 構築システムに対する利用上の不具合の修正も
4
必要でしょう。 長期的な関係を維持しようとするならば本当の契約の精神を守るという発想でな
ければなりません。 それが利用者にとっても開発者にとっても将来にわたってプラスになるので
す。 それが本当のビジネスアナリシスではないでしょうか。
図 ８－１６ 契約仕様書の共同作成と実行監視
◇◆◇
5