トップページ / プロフィール / 無料メールマガジン / ノウハウ集・書籍 / お役立ちリンク集 / おすすめの本 / 投稿・コラム / 道具箱 / 【裏口】
----------- ------------ ------------------- ---------------- ----------------- -------------- ------------- -------- --------

間違いだらけのシステム構築

〜企業システムの強化書〜

HOME

◆本文書に対するご意見、ご感想などは下記へご連絡下さい。◆
E-MAIL:hiroyuki_aoshima@kigyo-systems.com

システム構築プロジェクトの成功率は僅か30%!実に70%がコスト・納期を超過し
失敗しているそうです。つまり、普通にやっていれば、ほぼ失敗するということです。
企業システム戦略家の青島弘幸が、確実に成功率をアップし、最小の投資で最大の
成果を得、会社を強くする企業システム構築のノウハウを解説します。

無料レポート(PDFファイル)をこちらからダウンロードできます。
(なお、パスワードはメルマガ(無料)をご購読いただいた方にだけお知らせします。)

※出版関係者のみなさま、ぜひ、出版企画書(こちら)をご検討下さい。

以下の項目名(青文字部)をクリックすると各本文へジャンプします。

『目次』
はじめに
第1章 システム戦略
 1 最小の投資で最大の効果を生むシステム戦略
  ◆ITの本質
  ◆ソリューションの実態
  ◆「自働化」の落とし穴
  ◆「ペーパーレス化」の落とし穴
  ◆「統合データベース」の落とし穴
  ◆「パッケージソフトと自社開発」買うべきか、造るべきか、それが問題だ!
  ◆海外製パッケージソフトに負けるな!
  ◆「レガシ・システム」は負の遺産か?
  ◆ナレッジマネジマント、それ以前の問題
  ◆情報共有と日本文化
  ◆SCMと日本文化
  ◆業務への組込み、使ってこそナンボ
  ◆利益が全てか
  ◆ITバランススコアカードで多面的に評価せよ
  ◆最小の投資で、最大の効果を生む、開発の優先順位付け
  ◆マルチタスクより、シングルタスクで投資を早く、確実に順次回収せよ
  ◆システムは、「守・破・離」で育てよ
 2 短期戦を戦うシステム開発体制
  ◆ビジョン
  ◆プロジェクトの命名
  ◆ビジョンへと導く方法論
  ◆コンサルタントの功罪
  ◆キーマンを探せ
第2章 システム要件定義
 1 自社に必要十分な要件定義
  ◆情報処理の基本は5W2H
  ◆5回のなぜで、シナリオを検証
  ◆それで、いくら儲かるか
  ◆シンプル・イズ・ザ・ベスト
  ◆8:2、腹八分目の法則
 2 急がば回れ、質の良い仕様書の作り方
  ◆質の高い仕様書
  ◆分かりやすい表現
  ◆無くてはならない機能、あったらいいな機能
  ◆応答時間という麻薬
  ◆新技術の光と影
  ◆物事には表と裏がある
  ◆フロントローディング
第3章 システム開発
 1 リスクを緩和する上手な予算の使い方
  ◆2:4:2:3の法則
  ◆仕様変更対策
  ◆反復型開発の落とし穴
  ◆部品化・構造化の落とし穴
 2 もっと安くなる見積りの取り方、商談のしかた
  ◆見積りの取り方
  ◆委託と請負
  ◆選定方法
  ◆人月の矛盾
  ◆オーバースペックなハードウェア
 3 後悔しない契約書のチェック・ポイント
  ◆納品(誰が、いつ、どこに、何を、どのように)
  ◆著作権、所有権
  ◆仕様変更
  ◆検収条件
  ◆瑕疵期間
 4 早め々が肝心、進捗状況をこまめに確認
  ◆悪い知らせを聞く
  ◆レビューは、羅針盤
 5 いよいよ納品、検収のチェック・ポイント
  ◆機能
  ◆性能
  ◆保守性
  ◆ドキュメント
  ◆瑕疵
 6 紛争勃発!
  ◆仕様変更か欠陥か
  ◆常識と非常識の狭間
  ◆過失相殺
  ◆「欠陥」は業者だけの問題?
  ◆第三者による監理、助言
第4章 システム運用試験と実用展開
 1 実業務に使えるか?運用試験のチェック・ポイント
  ◆キーマン
  ◆テストデータ
  ◆追加発注
  ◆業務マニュアル
  ◆システム活用は十分な教育から
 2 これからが本番、儲けてなんぼの実用展開
  ◆実用展開戦略
  ◆ビッグバンか、順次拡大か
  ◆測定できなければ評価しようがない
  ◆売上げや利益だけが評価ではない
  ◆適用拡大は慎重かつ大胆に
第5章 プロジェクト管理
 1 ウォークスルーでイメージ合わせ
  ◆台本は、業務フロー
  ◆小道具は、画面と帳票のスケッチ
  ◆参加者は、役者・監督・スポンサ
 2 ドキュメント・レビュー
  ◆仕様書
  ◆見積書
  ◆設計書
 3 リスク
  ◆認識的リスク
  ◆人的リスク
  ◆技術的リスク
  ◆組織的リスク
おわりに

ーーー<本文>ーーーーーーーーーーーーーーーーーーーーーーー

はじめに
  書店に行くと、IT関連の書籍が山積みされているが、それらは、いずれも専門性が高く、IT業界関係者か、情報処理技術者向けに書かれたものが大半である。一方で、「動かないコンピュータ」(日経コンピュータ)や、関連の雑誌などでは、情報システムにまつわる、IT業者やコンサルタント会社の問題やユーザ企業側の問題などが指摘されている。しかし、その問題に対して、どう対処していったらいいのかを、ユーザ企業の立場で書かれたものは少ない。プロジェクト管理やリーダシップに関するものも、IT業者がプロジェクトを、うまく運営していくという視点で書かれている。はたして、このような状況で、健全な情報社会が醸成されていくのだろうか。これだけ、IT関連の情報が溢れながら、コンピュータやシステムは分からないので、業者に全てお任せというユーザ企業も少なくないように思う。その結果、失敗事例だけが取りざたされ、景気低迷の折、いっそうIT投資から、足が遠のいていくような気がする。いや、むしろバブルの頃に、そうやってIT投資はしてみたものの、思ったほど成果が出ていない、業者ともめた、プロジェクトが頓挫した、それこそ「動かないコンピュータ」が会社の墨で、ほこりをかぶっている。そんな失敗を経験して、もうITはこりごりだと、負け癖がついてしまった企業もあるのではないかと心配する。何もIT投資を勧めているわけではない。自社の主体的な経営判断で、IT投資を抑えるというならそれは、それで良い。そうではなく、ITは、「良くわからないので」、これまでと同じような予算枠の中で考える、あるいは、逆に極端に縮減してしまう。ということでは、さらに元気が無くなっていくばかりではないか。やはり、IT業者に任せるにしても、ユーザ企業から見たITの本質を知り、自社で抑えるべきところは押さえ、業者の見積りを理解し、対等に渡り合えるようになるべきである。そうして、最小の投資で最大の効果を生む、自社に合ったシステムを「早く、安く」構築すれば、必ず会社に新しい風を送り込んで元気になれると確信する。そこで、製造業のシステム部門で、20年に渡り、多数のシステム構築を手がけ、利用部門との調整や業者との商談から得た「早く、安く、儲かる」システム構築を成功させる秘訣を、名古屋人の堅実な視点から書きまとめてみることにした。本書は、まさにユーザ企業の、ユーザ企業による、ユーザ企業のためのシステム構築の本である。業者や雑誌などの言うことを、鵜呑みにせず、自社の業務システムをしっかりと見据え、主体性を持ってシステム構築をしたいと考える経営者、システム部門の方々の一助になれば幸いである。

1 最小の投資で最大の効果を生むシステム戦略

  できるだけ少ない投資で、最大の効果を生むようなシステムとは、どのように考えれば良いのか。システムを考えるときに、どんなことに留意すべきか。IT導入ということで、業者の提案を鵜呑みにしたり、必要でもない機能を詰め込みすぎたりして、結局、使い難い、使われないシステムに多額の投資をしてしまうことを防ぐために、ITの本質とは何か、さまざまな落とし穴や基本的なポイントはどこか、投資効果や優先順位付けは、どう考えれば良いのか。


◆ITの本質
  近年、IT(情報技術)という言葉が、さかんに使われるようになった。そして、いろいろな場面でITを活用することで、さも、さまざまな経営課題が解決できるかのように言われている。むしろ、ITを使わなければ、時代からとりのこされるかのようなことまで言われてきた。
 
  かつて、コンピュータが企業に入り込み、いろいろな場面で活用されるにつれて、コンピュータは、なんでも問題を解決できる魔法の道具のように言われたことがあった。これは、現代のITに対する捕らえ方と同じである。一体何が変わったのだろうか。実は、本質的なところは何も変わっていないのである。

  何故なら、人間の情報処理という営み自体が何も変わっていないからである。情報処理の本質は、入力・処理・出力である。なんのことはない、大昔から人間の知的活動の基本とされている、いわゆる「読み(入力)・書き(出力)・そろばん(処理)」である。そもそも、コンピュータが、この人間の知的活動を模擬して作られた機械であるから、あたりまえといえば、あたりまえである。が、最近の業者やマスコミが繰り出す、複雑怪奇な専門用語に目がくらみ、ITの本質を見失って、迷走していることが多いように思う。本質を知ってみれば、なにも難しいことなどない。コンピュータ側の専門用語や、実現方法(How)は、業者に任せておけばよい。あくまで、ユーザが考えるべきは、どんな「読み・書き・そろばん」(WHAT)を、コンピュータという機械にさせるかに尽きる。

  さて、この「読み・書き・そろばん」中で、特に「書き」(出力)が重要である。出力は、製品であり、行動である。どんな製品を造るのか、その製品で、どんな経営をしていくのか、どんな行動を起こして、どんな社会貢献をしていくのか、ここに最も時間をかけて考えなければならない。そして、製品が決まったら、それを造るために、どんな加工(処理)をすれば良いのか、その処理には、どんな入力(材料)を必要とするのかを、遡って考える。

  最終的な製品(出力)を得るのに必要のない処理や入力は、ムダである。現実の業務を忠実にIT化しても、そこにはムダが沢山ある。ムダな入力は、人件費のムダにつながる。
 処理のムダは、設備投資のムダにつながるのである。
 
  コンピュータあるいは、ITは、この情報処理(入力・処理・出力)を代行、あるいは補助する技術であり、安価かつ容易に、量・時・距離といった制約を超えて処理することが出来る。ITとは、たったこれだけのことである。この特性を利用して、情報(出力)をいかに仕事に役立てるのか、それは使う人間が考えることであり、ITに、それを求めてもしかたがない。

  では、最近のITは何が変わったのか。それは、経営環境の変化にともない、必要とする出力(情報)の質・量・タイミングが変わってきたのである。例えば、かつては、社内の伝票処理の効率化において、必要な出力は、計算された伝票であった。しかし、会社間での伝票処理を効率化し、スピードアップを図るためには、伝票ではなく、電子データが必要とされるようになった。さらに、その電子データは、少量多品種生産により、より大量かつ、頻繁にリアルタイムで必要とされるようになった。

  しかし、この伝票にある情報自体は、変わっていないこともある。したがって、この情報の質・量・タイミングを変えることで、経営のやり方を変えようという発想が無ければ、あるいは、逆に、経営からの要求が無いのであれば、最新のITを導入する必要はないと言える。

  このITの本質を良く理解し、あなたが考える経営戦略にとって、どのような情報(出力)が、どれくらい、いつ、どこで、どんな形で、必要なのかを見極めることが重要であり、それには、特別なIT知識は必要なく、また、流行の3文字略語や、ITツールを追い駆けることではない。


◆「自働化」の落とし穴
  IT活用では、経営効率化のために業務プロセスを改革し、自動化することが多い。し  かし、自動化すれば必ず、効率化するとは限らない。実は、自動化には大きな落とし穴が  ある。それは、業務プロセスを自動化することで、柔軟な対応ができなくなったり、内部  統制が甘くなったりするということだ。

  例えば、発注業務を手作業で、人が介在して業務を遂行していたころは、注文金額の書  き間違いに気が付いたり、単価の急な変更にも対応できた。ところが、これをEDI(電  子商取引)を導入し、自動発注システムを構築したのは良いが、間違った金額のまま、取  引先にデータが繋がったり、急な単価変更などにも、簡単に対応できなくなったりという  ことがある。つまり、業務プロセスが自動化により、ブラックボックス化・固定化するた  めに、人間のカンや融通が働くなってしまうのである。

  業務プロセスを人を介して繋ぐということは、ちょうどハンドルの遊びのようなもので  もある。煩雑なハンドル操作を吸収して車をなめらかに運転することができる。自動化・  リアルタイム化された業務プロセスは、この遊びが全く無いハンドルのようなもので非常  に危険である。一箇所で入力したデータがリアルタイムで、各方面に自動伝達されるのは  一見格好良いが、ひとたび誤ったデータが流れれば、そのために関係者が右往左往させら  れるというのは、ハンドルの遊びが無いために車が蛇行するのに似ている。これでは、か  えって非効率かつ、危険きわまりない。皆さんの中にも、間違いメールを多人数に同時発  信してしまい、取消し&謝罪メールを出された経験をお持ちの方がおられると思うが、そ  れも自動化による弊害の1つである。間違いメールならまだ良いが、受発注業務など社外  との取引業務では信用問題など、致命傷になりかねない。

  製造業の世界では、トヨタは、これを自動化ではなく「自働化」(にんべんのある自動  化)と呼び、何か不具合や異常を感じたら、いつでも停止できるように工作機械を改良し  て(人間の知恵を付けて)いるのだ。また、市場環境の変化が激しい現代、かつての大量  生産時代には効率的であった自動化生産ラインや自動化ロボット工場を取り壊し、多能工  によるセル生産に切り替えている会社もある。いずれも、人間のカンや融通性をとりもど  し、環境変化に柔軟に対応するための動きである。

  そこで、業務プロセスをIT活用して効率化する場合でも、何から何まで自動化・リア  ルタイム化するのではなく、非効率を承知で人手を介在させ、不具合や危険を感じたり、  急な変更があった場合には、いつでもデータを止められ・修正できる「自働化」(にんべ  んのある自動化)を図るようにすべきである。そうすることによって、これまで有効に働  いていた内部統制(コントロール)を失わず、システムが暴走し、人間が迷走させられる  ことを防止できる。


◆「パッケージソフトと自社開発」買うべきか、造るべきか、それが問題だ!
  自社の業務システム構築には、「早くて、安い」パッケージソフトを買うべきか、業者  に依頼して「じっくり、お金をかけて」自社開発するべきか、大いに悩むところだ。

  ところで、あなたは、建売住宅を買うか、注文住宅を建てるか?  「買うか、建てるか」それが問題だ!私達には、ゼロから建築士とひざを突き合わせて間  取り・建材を詳細に詰めていく、時間・費用・根気・知識は無かった。かといって、建売  住宅に生活スタイルを合わせられるほどの割り切りもできなかったのだ。さらに、当時の  建売住宅は、欠陥住宅の温床のように言われていた。内部構造や建材がブラックボックス  であり、心理的にも、実質的にも手抜き工事が発生しやすいのである。一方で、建売住宅  には、実際に家の間取りや家具の配置などを、実物を前に確認できるというメリットもあ  る。注文住宅では、設計図を頼りにイメージしていくしかないが、これが素人には難しい。

  そこで、私と家内は、建売住宅と注文住宅の、良いとこ取り作戦をとった。それは、数  十種類の基本の間取りが決まっている規格住宅から、もっとも希望に近い間取りのものを  選び、それに設計変更料(建築士に設計を依頼する場合の1/10程度)を払って希望の  間取りとしたのである。また、その業者が建てた似た間取りの家に住む顧客を紹介しても  らい、見学し、実際に家具を配置した感触、生活観などを事前確認した。同様に、3D間  取りソフトのウォークイン機能(実際に家の中を歩いているような映像を映し出し、内部  の様子や移動線をシミュレーションする)でも事前確認した。結果として、「早く、安く、  一定の品質が保証された」希望どおりの家を手にすることができた。

  実は、システム構築は、建築と似たところがあり、これと同じ方法がとれる。ポイント  は、システム化対象業務が特異でなく、一般的な業務と共通点が多いこと(家の例では、  あまりにも変形土地や狭小土地では、規格住宅がそもそも入らない)。その基本のシステ  ム機能に対し、家の間取りにあたる、データベースのキー項目や画面などの追加・削除、  構成変更ができるような規格品を見つけることだ。(例: シンプルな生産管理システム)さらに、ソースコードを入手できれば理想的である。

  これに近いのが、マイクロソフト社のAccessである。付属のテンプレートには、その  まま使える顧客管理システムや在庫管理システムなどがあり、ソースコードも提供されて  いる。また、あなたが、他社の購買管理システムと、それを構築した業者を知っているな  ら、その業者に依頼してみてもいい。おそらく、他社のシステムで作ったプログラムを一  部流用するなどしてコストダウン・品質を確保することができるかもしれない。

  一方で、著名な海外製ERPパッケージでは、在庫データベースのキー(識別子)が、  部品マスタと1対1の部品番号のため、複数地点での倉庫毎、あるいは、輸入品(ドル建)  /国産品(円建)毎、で在庫を管理することができなかった。これを管理可能なように、  データベースのキーを変更すると膨大な改修費用が必要となる上、今後のバージョンアッ  プにも対応できなくなるため、採用を見送ったこともある。ERPは、システム的には、  一元化データベース中心の設計であるため、データベースのキー項目が何かを調べれば、  情報を管理できるメッシュ(粗さ)が分かる。この情報の管理の粗さこそが重要であり、  ここをパッケージに合わせられるか否かが採用の決め手となる。表面的な画面の機能など  は、一見マッチするように見えても、データベースのキーが合わないと、既存のデータが  移行できないとか、従前のきめ細かい管理ができなくなるなどの不具合が発生する。ちな  みに海外では、円建で材料を購入することは無いので、同一材料で円建とドル建の管理は  不可能である。同様に、在庫単位もフィートとセンチメートルを同時に管理できない。

  くれぐれも、「自由設計」を謡いながら壁のクロスや装備品程度を選択できるくらいで、  ちょっとした間取り変更でも、多額の設計料や改造料を要求するような業者には、ご注意  いただきたい。例えば、高生産性・高柔軟性をうたい文句に、パッケージソフトやソフト  ウェア部品を利用してシステム構築を請負う大手業者なども存在するが、そのパッケージ  や部品は、あなたにとってはブラックBOXだ。業務変更に合わせて、システムを改良し  たくても手も足もでない。結局、その業者に依頼せざるおえなくなってしまう。

  そして、高生産性・高柔軟性は、得てして業者の利益率向上には寄与するが、契約金額  ・納期・仕様変更容易性などには反映されないことも多々ある。あなたが、生涯生活(業  務)スタイルを大きく変えないという割り切りで、「早く、安い」建売住宅を、主体性を  持って選んだとしても、それはそれで良い。むしろ、経営環境に合わせて、業務スタイル  を変えていかなければならないような核の部分に、目先のお手軽さにまどわされて、ブラ  ックボックスを抱え込み、それが経営の足かせになることが恐ろしいのだ。

  なお、自動車を注文生産する人は、ほとんどいない。自動車は、壊れたり、古くなった  りしたら、新しく買い換えるのが一般的だからだ。どんなに、高価な自動車でも一生同じ  自動車に乗る人は少ない。新型車に買い換えることで、新しい装備やスタイルを楽しむこ  とが出来る。また、自動車によって生活スタイルを拘束されることもない。

  このように、その基本機能が決まっており、新しく買い換えることで、追加の機能や使  いやすさを手に入れることができ、使い方の自由度が大きいものは、買ったほうが良い。  例えば、ワープロソフトやCADソフトなど、いわゆるツール系のパッケージソフトであ  る。

◆最小の投資で、最大の効果を生む、開発の優先順位付け

  さて、ここでは最小の投資で、最大の効果を生むシステムを具体的な戦略・計画に落とし込むための優先順位付けについて、少し実務的な話をしよう。まず、最大の効果を得るためには、その効果を測定する。この効果は、前述したように「財務面での利益」だけでなく、それに関連つけられた「顧客、社内プロセス、学習と成長」の視点を加え多面的に評価しなければならない。次に、投資を測定する。投資は、後述するように、利用者にとって意味のあるシステム構成要素(画面・帳票・ファイル)を元に、ファンクションポイント法で算出する。

  そして、最小の投資で、最大の効果を生む案件順に並べて、その上位から優先的に開発していく。最小の投資で、最大の効果というのは、いわゆるROI(投資利益率:利益÷投資×100%)として数値化する。最後に、シナリオの妥当性や実行推進力を加味して最終的な優先順位を決定する。これらは、定性的なものであるが、評価基準にしたがって
 採点し、それを合計して数値化する。いくら、ROIが最大になるような案件であっても、その効果獲得までのシナリオに妥当性が無かったり、実行推進力に不安があれば、計画どうりの成果を獲得することができない。いくら、最小の投資とはいえ、システムは使ってナンボ。使われなければ、投資自体が無駄になってしまう。
 以下に、これら評価項目の例を示す。
 
 <評価項目と説明>
 ・シナリオ
  「問題、原因、対策から効果、目的達成」にいたる計画の妥当性、
議論の深さ、仮説立証性等を評価する。
   a.経営貢献度
     顧客満足、損益改善等の経営課題に対し有効か。
   b.費用対効果
     投資に対する、効果や成果は十分か。
   c.適用範囲
     システムを適用できる組織、機種は広範か。
   d.首尾一貫性
     目的達成までのシナリオは一貫し矛盾は無いか。
   e.明確性
     目的、効果、新旧業務の違い(できていること/やりたいこと)、
適用時期や範囲等は明確か。
   f.現状認識度 既存のシステムや業務はもちろん、
     現場の実態や客先の現状は十分把握しているか。
     「なぜを5回繰り返し」て真因を探っているか。
   g.実現性
     システムの機能はもちろん、運用において、人、業務、組織、
社外まで考慮して検討しているか。
   h.リスク評価
     計画実行上のリスク分析・評価が十分か。
     4大リスク:「要件、技術、人、組織文化」
   i.代替案検討度
     リスク等を考慮し、代替案を検討しているか。
     システム化以外に改善案を検討評価しているか。

 ・推進力
  計画を推進する、人や組織を動かすための仕組み(仕様作成、運用試験、
実用化展開
  ・利用促進を推進し、成果を獲得するための施策等)を評価する。
   a.組織体制
仕様決定から利用促進までの組織体制は十分か
   b.キーマン
現場のキーマンを十分参画させているか
   c.職制の理解度
システムの目的や効果、担当者の作業負荷などに ついて、職制は理解・認知し
     ているか
   d.組織文化
業務変革に対する抵抗、パソコン嫌い等はないか
   e.実用化状況
改修対象システム又は他の既存システムは、十分 活用されおり、所定の成果が
     出ているか


◆マルチタスクより、シングルタスクで投資を早く、確実に順次回収せよ
  さて、優先順位をつけた各案件を、どのように開発していくのが効率的であるか。ここに、開発規模が5人で6ヶ月かかる案件が2つあったとしよう。プロジェクトリーダが二人、開発要員が10人いた場合、あなたなら、どうするか。それぞれの案件を、プロジェクトリーダに割り当て、開発要員を5人ずつにして、2案件を並行してマルチタスクとして開発するか。

  その場合、各システムが効果を生み、投資回収を開始できるのは、半年後である。これは予定通り5人・6ヶ月で、開発が完了した場合である。しかも、この2案件に関連性がある場合、さらにプロジェクトの遂行は困難になる。プロジェクト間での関連情報をやり取りする場合、そのコミュニケーションコストなどのオーバヘッドが大きくなり、一般的には、予定よりも長期化する傾向にある。

  そこで、著者は、1案件にプロジェクトリーダ1人、開発要員10人を割り当て、それぞれの案件を3ヶ月で順に、シングルタスクとして開発することを推奨する。この場合、最初の1案件は、3ヶ月で完了し、投資回収を開始することができる。そして、次の案件を3ヶ月で完了し、半年後から投資回収を開始できる。

  開発チームの開発力を集中することができ、プロジェクト間のコミュニケーションコストが発生しない。例えば、これが3案件であっても同じである。最後に回った案件は、投資回収までに9ヶ月かかることになるが、それでも先に2案件を短期に完了することで、投資回収を早めることが出来る。複数案件を、複数チームでマルチタスクで開発するより、
 シングルタスクとして短期開発した方が、同じ投資をするにしても、効果を早く順次獲得でき効率が良いのである。


◆キーマンを探せ
  システムを、最小の投資で構築し、素早く投資回収するためには、プロジェクトチームのメンバとして、対象業務及び組織のキーマンを参画させることは必須である。キーマンとは、単に実務に詳しいだけでなく、その組織の中での発言力が強く、リーダシップを発揮できる人物である。彼らを当初から巻き込み、ビジョンなどを共有しておくことは、あらゆる断面において有効である。
 
  逆にキーマンを、当初から巻き込むことに失敗し、要件定義で重要な機能が抜け落ちたり、ムダな機能を搭載してしまったりし、いざ実用展開段階でキーマンが、システム利用に対して、反対行動を起こしたために、頓挫してしまったプロジェクトも少なくない。こういったキーマンは、かならずどんな組織にも存在するはずであるが、見つけるのが難しい。日ごろから、現場に足を運んで、いろんな人からヒアリングしておかなければならない。もし、あなたが、そういったキーマンを、あそこは誰それ、ここは誰それと、すぐにピックアップできるようなら、それだけでもプロジェクトは、すでに成功に向かっている可能性が高い。それほど、システム構築の成否に、開発体制における「人」の要素は大きいのである。そして、リスクも同じように大きい。
  
  システム構築プロジェクトに実務経験者の参加をシステム部門が要請した場合、多くは、その部門にとって、戦力として影響の無い人物がアサインされることがある。目先の部門利益を考えれば当然の結果でもある。およそ、キーマンとなる人物は、その部門において中心的な役割を担っており、常に忙しく、彼がいなくなれば、その部門の戦力はガタ落ちになることは目に見えている。

  もし、プロジェクトが、社運を賭けるような戦略案件であり、失敗が許されないなら、当面の戦力ダウンを承知で、プロジェクトに選任させることを、経営者であるあなたが決断しなければならない。システム部門長と業務部門長では、部門最適の観点から平行線をたどり、埒があかないことが多い。会社の将来を見据え、当面の損失リスクを承知で、人材をプロジェクトに投資するかどうかは、部門を越えて経営者が判断し決断しなければならない。

  さらに、システム部門長と業務部門長の双方の利益を考慮した折衷案として、プロジェクト兼任として、業務部門に在籍させたままにしておくできではない。先に述べたように、キーマンは、もともと超多忙である。そんな彼が、業務部門に席を置けば、プロジェクトよりも、通常業務を優先することは火を見るより明らかである。しかも、業務部門に在籍すると言うことは、当然、その業務部門に対しての業績で評価がされるので、プロジェクトに身が入らないのは当然である。

  キーマンは、業務部門から引き抜き、プロジェクトに専任とし、籍もプロジェクトマネージャの配下としなければ、キーマンとしての本来の働きを期待することはできない。実際に、優秀な業務部門のキーマンが参画しながら、現業と兼務であったために、要件定義が遅れ、要件に不備があり、実用開始までに、予定の半年以上も遅れ、予算も超過したプロジェクトがある。最小の投資で、素早くシステム構築をし、早期に実用化し投資回収を確実に行い、最大の効果を生むには、キーマンを専任化してプロジェクトに参加させることが重要である。そのほうが結果的にプロジェクトが長期化することも少なく、業務部門への影響も最小・最短に抑えることが出来る。


◆第三者による監理、助言

  システム構築において、やはり専門知識においてユーザ企業は弱者である。例えば、ハードウェア能力にしても、業者から、レスポンスを確保するためには必要ですと言われれば、高価であるとは思いながらも購入するしかない。例え、後でもっと小さい能力のハードウェアでも良かったとしてもしかたがない。

  ソフトウェアにしても、「できません。」と言われれば、納得できなくても、あきらめるしかない。後で、別の業者に、こうすれば、できますよと言われて悔しい思いをしたとしてもだ。また、要件定義や要求仕様に漏れやミスがあってもそれを親切に指摘してくれる業者もいれば、「仕様書どおり」に作りましたと知らん顔の業者もいる。後で仕様書の漏れが見つかれば、やはり、追加費用を用意して改修しなければならない。

  もちろん、業者と対等に渡り合える技術力を持つのが理想であるが、ITの高度化により、餅は餅屋ということにも利がある、また、本業でないIT技術者を、業者と同等のスキルまでに育成するために教育投資をするのは、現実的ではない。これでは、建築業者と同じ知識を、施主が身につけてから家を建てよというのと同じである。そこで、欠陥住宅防止においては、第三者の建築士による工事監理、建築検査を実施することが推奨されており、役所の検査も義務つけられている。

  こうしたことを考えると、社内に、システム構築に長けたシステム部門なり、システム要員を確保できない場合は、やはり、第三者による監理や助言が必要になる。これは、コンサルタントのように調査、分析だけで後は宜しくということではなく、システム構築の企画から運用までの全工程に渡り工事を監理し、助言をあたえることができる専門家のことである。経済産業省のITコーディネータ制度も、こういった目的で制定されたものである。

 その他、地域振興センターなどでも、IT化支援を目的とした専門家派遣事業を展開している。こういった支援制度を利用して、業者任せのシステム構築ではなく、主体性を持ったシステム構築を実施するべきである。また、このような制度を実効性のあるものにするために、建築士法や建築基準法と同等の法制度が、システム構築に対しても整備されることを望む。欠陥住宅のように即、人命には関わらないが、これだけ欠陥システムが社会問題化しているのであるから、もっと厳しくてもおかしくはない。

  監理のポイントとしては、要件定義書や要求仕様書のチェック、システムの内容と規模に応じた業者探し。余談になるが、この業者探しは、お見合いに似ているかもしれない。結婚相手は、自分で探すのが一番という考え方もあるが、結構、自分にあった相手を探すのは大変な事である。自分のことも良く分からないが、相手の事も良く分からない。そこで、仲人が間に入って「摺り合わせ」を行う。

  システム構築の場合も、多分に人的要素の影響が大きいので、最適な業者を探すのは重要である。しかし、これから構築するシステムの技術的、業務的、経済的、距離的、運用保守等の特徴を抑えて、それに会う業者を探すのは、骨が折れる。そこで、とりあえず身近に付き合いのある業者に声を掛けるということになっていないだろうか。最小の投資で最大の効果を得るシステムを構築するなら、この業者探しは慎重に行うべきで、専門家による仲人をお願いしては、いかがだろう。

  さて、話を戻すと、次に見積書のチェック及び業者とのネゴ支援、各レビューへの参加によるチェックと助言、プロジェクトの進捗状況把握と改善勧告、納品検査における品質の専門的チェック等を、必要に応じて依頼するとよい。この時、ユーザ企業の立場で考えつつも、業者から独立した第三者として公平な立場でのチェックと助言を与えることができ、ユーザ企業と業者との良好な関係を築けるような人材が理想である。

  一方的にユーザ企業の肩を持ってしまうと、業者との信頼関係が築けず、結局、ユーザ企業にとっても不利益を被ることになるし、反対に、業者に依存していると、どうしても評価が甘くなりがちである。建築士の場合でも、建築会社などに、設計下請け業務で依存している建築士では、第三者としての公平な評価をし難い傾向にある。このようにバランス感覚に優れた専門家を探す事は、決して容易ではないが、探せば必ず見つかるので信頼できる人物に巡り合うまで地道に情報収集して欲しい。ITコーディネータ協会や日本システムアナリスト協会、中小企業診断協会など、専門家どうしの団体もあるので相談してみてもよい。


6 紛争勃発!

   受入検査において、明らかに「欠陥」であると判定できる場合は問題ないが、システム構築においては、発注側としては、欠陥であると思われる不具合であっても、業者からは、それは欠陥ではなく、仕様書に書いてなかったので仕様変更であると反論されることが少なくない。これは、業務という抽象的なものを対象としている上に、要求事項が言葉によって表現されることが原因であるケースが多い。ハードウェアのように形状を設計図として表現できないところに本質的な難しさがある。

   さらに、日本語特有のあいまいな表現が、コンピュータに指示をするプログラミング言語と相性が悪い。要求仕様書では、YesともNoとも、とれる表現に対して設計者なりプログラマなりが、コンピュータに指示をするために、プログラミング言語に変換する過程で「おぼつかない」業務知識を頼りに、Yesか、Noかの、どちらかに決定を下す。ところが、この決定が発注側が意図した結果と異なるというわけだ。
   
   欠陥であれば、業者が無償で是正することとなり、仕様変更であれば、発注側が追加費用を支払うことになるので、両者に利害関係が生じ紛争勃発となる。そうなった場合に、できるだけ禍根を残さずに両者が納得できるような形で解決するには、どうすれば良いのか以下に基本的な考え方を述べる。

 
◆仕様変更か欠陥か
  まずは、かならず争点となるのがこれだ。発注側が「欠陥」であると主張するのに対し、業者は、それは仕様に書いていなかったので「仕様変更」であると反論される。主張が通らなければ、是正の費用を負担することになるので、どちらも簡単には譲らない。ここで、問題となるのが要求仕様の明確さである。要求仕様書に記述されている条件が明確であれば、それが欠陥であるかどうかは、即座に判明する。

例えば、ある計算を行う条件が、1000以上の場合に、900で計算が実行されれば、明らかに欠陥である。ところが、問題になる場合は、このように要求仕様が明確に記述されていない場合が多い。条件を数値ではなく、業務用語で記述してあったりする。発注側からすれば、その業務用語で表現しておけば、細かい条件を数値で一々記述しなくても分かるはずという「思い込み」がある。

  また、要求事項には正常なケースに対する処理を記述すれば、当然、例外処理や異常処理は、業者が考えて作りこんでくれるものと思っている。業者側も、自らの業務知識や経験を売りにして、顧客に「そこまで書かなくても分かります」といった感じで、要求分析が進められることが少なくない。日本独特の、一から十まで言わせない、聞かないというところである。かくしてシステム構築は、「麗しき誤解」の上に作業が進められ、最後の最後になって紛争が勃発するのである。

  そして、この紛争を解決する慣習が、先に述べた2:4:2:3である。つまり、当初、2の要求に対し、最後に4であったことが判明する。しかし、予算は2の見積もりで確保されているので、折衷案として、発注側は要求事項を1取り下げ、業者は、1無償で追加開発することで、3に落ち着くというものだ。結局、双方が痛み分けとなり手打ちとなる。まさしく、IT業界の悪しき商慣行である。

  著者の立場は、仕様書に書いていないことや、書いてあっても不明確であり、いかようにも解釈できることは、欠陥ではないとする。誰が読んでも、一意に解釈できないということは、業者の業務知識なり経験を信頼して「お任せ」したのであるから、それを一概に「欠陥」と決めつけるのはどうかと思う。一方で、仕様書に記載されているにもかかわらず、読解不足で意図しない結果となるのであれば、それは「欠陥」である。

  読みやすいか、読みにくいかは、問題ではない。専門家としての注意義務がある。よく読めば、確かに記述されているにもかかわらず、読みにくいので気が付きませんでした、というのでは通らないと思う。さらに、専門家として注意を払い、要求事項に不明確なヶ所がある場合、適切な質問なりして要求分析段階で、明確にしておく努力を怠り、勝手に解釈してプログラムを作っておきながら、後で「仕様書が不明確」であることを理由に、過失責任を逃れようとすることは、法律でも認められていない。

  仕様変更か、欠陥か、双方が利己的な主張をする前に、自らの「甘え」を自省すべきであると思う。発注側は要求仕様書が明確に書かれているか、業者はあいまいな要求仕様を明確化する努力を怠っていないか、勝手に作り手側だけの理論で解釈しなかったか。まずは、それぞれが各自の非を認めるところから始めなければ泥沼の水掛け論にはまり込むだけで、なんの利得もない。例え法的に争って勝ったとしても、金銭的に解決が図られるだけで、システムは完成しない。争議によって失った時間を取り戻すことはできないのである。


◆常識と非常識の狭間
仕様書に書いていなくても、当然、機能として盛り込まれていなければならないと主張する根拠として、それが、常識的なものであるかどうかが争点となる場合もある。ところが、この常識というのが非常にあいまいであり、どこまでを常識というのかがはっきりしない。確かに業界標準となっている業務プロセスや業務用語などは、その業界に精通しているものにとっては、常識である。

  業者は、はたして、どれくらい業界に精通しているであろうか。おそらく、それほど精通しているとは思えない。例え、精通していても業界の標準的な業務についての知識であって、あなたの会社の業務である可能性は低い。すなわち、私の常識は、あなたの非常識ということもあり、暗黙の了解が、麗しき誤解を生む元凶である。

  仕様書に書いてなくても、常識であると主張できるほど、業界標準に則った業務プロセスになっていると言えるかどうか、甚だ疑問である。自社内だけで通用する常識を振りかざして、「そんな機能は当然。盛り込んでいないのは欠陥だ」と声を張り上げるのは、かなり乱暴だと思う。ただし、業者との付き合いが長く、何度か自社のシステム構築を発注している場合には、自社内だけの常識であっても、ある程度は主張できるだろう。

  これまでのシステム構築の経験から明らかに常識と言える業務知識についても、仕様書に書いていなかったことを理由に、欠陥ではないと主張するような業者なら、今後も継続的にシステム構築を発注する意味はあまりない。それならば、最初から経験の無い業者に発注したほうが、甘えや馴れ合いが無くなり、要件定義や要求仕様をしっかりと固められる可能性もある。業者に「それは、知りませんでした。」と開き直られても諦めもつくというものだ。業者は、自社業界の専門家ではなく、コンピュータ業界の専門化であるということを前提に仕様書をまとめれば、暗黙の了解や大前提の省略による誤解も少なくなる。

  一方で、コンピュータ業界の常識は、特に記述する必要は無い。例えば、システムが障害を起こした場合に、データベースなどを障害前に回復し、安全にシステムを再起動できるような機能を備えることは、仕様書に明記していないとしても、システム構築の専門家として常識的に盛り込んでいなければならない。このようなことまで、仕様書に明記していないことを理由に欠陥ではないと主張するような非常識な業者には、お引取り願ったほうが良い。おそらく、障害対策や回復機能以外にも、仕様書に明記していないことを理由に手抜きをしている可能性が高い。


◆過失相殺
  欠陥と仕様変更は必ず発生する。欠陥の場合は、業者側に修繕義務や損害賠償責任が発生する。仕様変更の場合は、発注側に追加発注という費用負担が発生する。そこで、両者の過失を相殺するというのは、いかがだろう。つまり、欠陥に対する損害賠償費用と、仕様変更に対する追加費用を、差し引きゼロにするのである。

 できれば、問題が発生してからではなく、最初の契約時点で取り決めをしておけば、欠陥や仕様変更を抑制する効果も期待できる。業者にとっては、欠陥を多発すれば、本来は仕様変更で追加費用をとれるものも、とれなくなってしまう。また、発注側にとっては、欠陥に対する損害賠償を請求できるところも、仕様変更によって請求できなくなってしまう。欠陥が少なく、仕様変更が多ければ、発注側に余分に費用が発生するし、欠陥が多く、仕様変更が少なければ、業者側に余分に無償作業が発生する。そのようなことが、最初から分かっていれば、損しないように気をつけようというのが心理だ。

  それでも、やはり仕様変更か欠陥か、調整がつかないようなことがある。この場合には、 双方が意固地になり、もう理屈ではなくなってくる。平行線をたどってムダな時間を浪費するより、どうしても必要な機能ならば、改修に必要な費用を折半するなどして紛争を解決する道を探ったほうが得策だ。とにかく、システム構築を前に進めて、使えるようにすることが、本来の目的である。


4 早め々が肝心、進捗状況をこまめに確認
  さて、業者にシステム構築を請負契約で発注した場合、基本的には納期までにシステムを納品してもらえばそれで良い。ところが、システム構築プロジェクトの場合、スケジュール遅れとなることが少なくない。かといって、納期遅れの場合にペナルティを課すことも慣行的に行われていない。例え、契約で取り決めペナルティを取ったとしても、システムの実用開始が遅れて損失を被るのは自分たちである。請負契約だからと、業者に任せきりにせず、適宜進捗を把握して問題があれば早め々に対処するようにすべきである。

 
◆悪い知らせを聞く
  人間誰しも悪い知らせは聞きたくないものだ。また、悪い知らせを持ってきた人間にあたったりする。しかし、それでは問題が発生しているのに、真の状況が隠され、「問題ありません。なんとかします。」という報告ばかりを受けることになる。これでは、リスクを早期に発見し、対策を講じることなどできない。「良い知らせ」と「悪い知らせ」があった場合は、まず、良い知らせを先に聞くようにするとよい。悪い知らせを聞いて落ち込んだ後に、良い知らせを聞いても嬉しくない。報告するほうも良い知らせを先にしたほうが、悪い知らせを報告しやすいだろう。「ほめてから、しかる」と、苦言も受け入れられ安いのと同じだ。

  とかく悪い知らせというのは、届きにくいものだ。担当者も、ギリギリまでなんとかしようともがき、最後の差後になって、実は...と切り出してくることが多い。まじめで努力家ほど、この傾向にあるので余計にやっかいだ。悪い知らせを早めに出して助けを請えば、結構、助け舟が出たりするものであるがまじめ・きまじめさが邪魔をするのか、なかなか切り出してこない。また、業者としては、早くから遅れそうだと手をあげて、余計な詮索やチャチャを入れられたくないという思いもあろう。

  このような状況を打開し、風通しを良くするには、発注者である側が「気を使わなければならない!」なんで、発注者(顧客)が気を使わなければならないと思われる方も多かろうが、先に述べたように、システム構築というのは、すべからく「人」「人」「人」である。したがって、人はメンタルな面に左右されやすい。プロジェクトをスムーズに進めたいのであれば、業者側のプロジェクトリーダにその気になってもらわなければならない。「俺は客だ!」とふんぞり返ったところで、仕事は進まない。業者も含めた、チームビルディングを考えなければならない。

  業者側のリーダクラスが、打ち解けて何でも相談して来るようになれば、悪い知らせを先(早め)に聞くこともできる。業者側にマネージャには言えないような事でも、どうしましょうと相談を持ちかけられればしめたものだ。業者側で、プロジェクトが頓挫している場合も、話を聞いて見ると要求事項を満足するために、技術的に困難な課題が出てきたりしてしるケースもある。そのような場合、利用者と調整し、要求事項を緩やかなものに変えることで、課題が解決できることもある。

  業者側の技術者は、契約している以上、要求仕様書を忠実に実現しようとして、ムダな時間を浪費していることも多い。また、要員不足となっているにもかかわらず、業者側のリーダが上司に言い出せずに一人で抱え込んでいる場合もある。そういった場合も、状況を早めにつかめば、顧客として業者の上司に要員の増強を要請することもできる。

  いずれにしても、納期間際に「遅れます!」と突然言われて、あたふたしても始まらない。悪い知らせに耳を澄まし、早め々に対策を業者と共に考えることで、納期遅れによるムダな時間・コストを防止するようにしたい。業者に対しても相応な配慮をし、なんでも状況をオープンにさせるように仕向けることが肝要だ。


◆レビューは、羅針盤
  システムの出来具合と進捗状況は、適宜、業者から報告を受けるのは、リスク管理の面から当然である。また、悪い知らせを早め々に聞き出して、先回りして対策を打つことも重要である。しかし、これは、いずれも間接的な情報である。やはり、重要なポイントでは、自らの目で確かめることが必要だ。 織田信長は、間接的な情報だけに頼った情勢判断では、「今、そこにある危機」に対する勘が働かず、手遅れになることを恐れたため、3現主義(現場、現物、現実)を徹底していたといわれている。また、トヨタの強さの一端にも、徹底した3現主義があると言われている。

  システム構築は、成功率が30%程度といわれるほどリスクの高い仕事である。これを、他人任せ、業者任せにして、間接的にしか関与しないようでは、成功はおぼつかない。建築においても、欠陥住宅を防止するために、竣工までに3回は、現地において第三者の専門家と共に、自分の目で、建築検査を行うように推奨されている。システム構築における検査にあたるのが、レビューである。レビュー無しで、システム構築を行うのは、羅針盤無しで、荒海に乗り出すようなものであり、難破するのは必至である。

  レビューをマイルストーンにおいて実施することで、品質と進捗状況の両方をチェックすることができる。例えば、品質上の問題が発見された場合、その重大度、影響度によって、今後の進捗が、どの程度遅れる可能性があるかを事前に予知することができる。一般に、進捗状況は、計画に対して、実績がどれくらい進んだか、どれくらい遅れたかの過去形の報告しかされず、「この先、どれくらい遅れそうか」ということは報告されない傾向にある。そして、実際に品質上の問題などの解決に手間取り、遅れが表面化してから報告される。このような場合でも、レビューによって品質上の問題を事前に把握することができれば、遅れる前に、適切な技術者を手当てするなどの対策を打つことがでる。

  確かに、専門の技術用語が飛び交うレビューに、素人が口をはさんでも、どれだけ意味があるかという疑問があるかもしれないが、レビューに数多く参加することで、リスクを嗅ぎ分ける勘が鍛えられ、内容に関わらず「ヤバイ」状態にあるか、ないかを知ることができるようになる。専門的に、どうしても心配があれば、建築における第三者としての建築士や、医療におけるセカンド・オピニオンとしての医師と同様に、第三者の専門家として、システムアナリストやITコーディネータ、別の業者のサポートを受ける手もある。

  以下に、できるだけ専門的な内容に入り込まずに品質と進捗状況を、顧客の立場からチェックするためのレビュー・ポイントを述べるので、臆せず、ぜひ、レビューを実施し、参加してほしい。まずは、いつ行うかであるが、建築検査では、基礎工事、棟上げ、竣工の格完了時に3回実施することが推奨されているが、システム構築では、基本設計又は外部設計で2回、詳細設計又は内部設計で1回、統合試験で2回行うことを推奨する。

  基本設計は、作業進捗が30%と70%の時点で実施し、詳細設計は進捗70%の時点、統合試験は、試験計画作成時点と試験70%完了時点で実施する。いずれにしても、作業完了時点では、問題が発見された場合、即、スケジュール遅れとなってしまうので、その前に実施する。問題発生による手戻りは、「必ずある」という前提で考えておけば、残りの作業の中で、対策を事前に打って、遅れを防止できるか、遅れても被害を最小に抑えられる。基本設計では、大きな方向性が固まるのが30%程度の進捗時点。ここで、一度レビューを実施し、方向性に大きな違いが無いかを確認しておくことで、後から、大きな手戻りが発生するリスクを抑えることができる。

  ただし、これは30%程度の作業で、全体の方向性が決まるように設計作業をすすめることが前提となる。全体設計をせずにできるところから順次、プログラムを作成するようなやり方の場合は、完成の都度レビューをすることになる。その場合、作業の完成間際に全体の方向性を覆すような設計変更が発生した場合は、かなりの手戻りを覚悟しなければならない。これは、ちょうど基礎を全部作らずに、間取りが決まった部屋から家を建てるようなものである。

  最近は、小さな部分に分割して、早くユーザに使えるシステムを提供し、フィードバックを得ながら、要求仕様を盛り込んでシステムを順次構築するようなやり方を提案する業者もいるが、基幹業務システムのように、基礎に巨大なデータベースを必要とするような場合は、せめてマスタ・データベースの基本構造とキー項目(データ識別子)や基本の画面・帳票構成くらいは、後で変更することのないように全体設計をすることをお勧めする。

  統合試験では、試験を実施する前に、試験計画を作成した時点でレビューを実施することで、試験の妥当性をチェックする。試験の内容が必要十分であるか、人手を必要以上に掛けていないかをチェックする。万一、スケジュールが遅れているようであれば、比較的業務に影響が少ない機能については、試験内容を簡略化することで、さらなるスケジュール遅れを防止することもできる。とかく業者は、責任感から全ての機能に対して、綿密な試験を計画するが、それゆえに漏れや手抜きも発生する。発注者側が、イニシアチブをとって、機能ごとに重要度やリスクを考慮してメリハリを付け、重要な機能は徹底的に集中して試験し、そうでなければ、良い意味での手抜きをすることも必要である。
  
  次にレビューでのチェックポイントであるが、できるだけ専門的な内容に入り込まずに危機的状態にあるか、今後、危機的状況に陥る可能性がどれくらいあるかを感じ取るには、要件定義書と要求仕様書に基づいて確認する。つまり、コンピュータ上の専門的な内容ではなく、あくまで、顧客からの観点に立って質問すればよい。一つは、基本設計や詳細設計、試験計画の内容が、要件定義や要求仕様のどの項目に対するものか、その追跡性を確認する。

  専門用語ではトレースアビリティというが、全ての設計内容とプログラム、及び試験内容は、必ず要件定義と要求仕様から文書上で追跡できなければならない。その追跡が文書上ではっきりしない、質問しても明確に答えられないようなら、危険度大である。また、明確になっていれば、さらに、漏れや抜けが無いかをチェックできる。漏れや抜けを事前に発見できれば、手戻りを防止できる。漏れや抜けの他にも、過度の設計や試験にも目を光らせたい。要件定義や仕様書で要求されてもいないのに、技術者が、余計な気を使って、過度に機能を盛り込んだり、信頼性を上げたり、必要以上に執拗な試験をしたりと、これらは、追加費用は発生しないかもしれないが、スケジュール遅れや余計な問題を誘発するリスクを抱えている。トレースアビリティを確認することで、「過不足なく」仕事が進んでいるか否かをチェックできる。

  トレースアビリティを確保する単純かつ確実な方法は、要件定義や要求仕様の各記載項目に項目番号を付けておき、設計書の記載項目番号やプログラム番号あるいはサブルーチン名、クラス名等と対応つけた対応表を作成することである。

  もう一つ質問すべき点は、トレースアビリティ確認表を元に、設計なりプログラムの内 容について、要件定義なり要求仕様を満足するために、なぜ、そのような設計にしたのか、あるいはプログラムにしたのか、あるいは、その試験内容で良いと判断できるのかである。技術者は、設計した結果について、専門用語を使って詳細に説明することはできるのであるが、この「なぜ」という基本的な質問に、しっかりと答えられないことがある。慣例的に、あるいはマニュアルに書いてあったからとか、という答えでは、はなはだ心配である。「なぜ、そうしたのか。なぜ、それで要件なり要求を満足できると考えたのか。」これを、顧客に分かるように、要件定義書及び要求仕様書に関連つけて、しっかり説明できる技術者であれば、ほぼ安心していて良い。

  専門的な内容はさておき、要件や要求仕様に対して、しっかりした技術的根拠を持って、設計なりプログラムなりを作成し、試験を実施したことが、レビューで確認できれば、ほぼ、レビューは成功である。もし、問題点が発見されても、それ以降に適切な対策がとられ解決されると見てよいだろう。反対に、要件や仕様に対するトレースアビリティも不明確で、明確な技術的根拠も無く作業が進められており、専門用語ばかりを並べて、しどろもどろ。顧客が分かるように説明できないようであれば、危険度はかなり大である。

  これが、基本設計の30%の段階で判明し、改善が見られないようであれば、技術者の交代を要請することで、早い段階にリスクを緩和できる可能性が高い。さらに、技術者を交代しないとか、説明責任を果たせる技術者が出てこないようであれば、早めに業者を乗り換えることもできる。これが、詳細設計以降に発覚しても、もう手遅れである。高い出費を覚悟で、いわゆる「火消し」を雇うか、システム構築を放棄するしかなくなってしまう。
        
  このようにレビューは、必ずしも専門知識を必要とせずとも、仕事が順調に進んでいるか、この先、問題が発生する可能性が、どの程度あるかを知ることができる。レビューを重ねることで、内容以前に、技術者の説明の仕方や態度で、「ヤバイかヤバクないか」を感じ取ることができるようになる。また、質問も表面的なことだけでなく、深く突っ込んだ質問もできるようになる。例え、専門的内容に対して判断を下すことが出来なくても、その技術的根拠がはっきりしていれば、他の技術者に意見を聞いて比較することもできる。万一、後で問題が発生しても、他の技術者の援助を受けるなどして解決策を見出すことも可能である。少なくとも、システム構築プロジェクト全体が、泥沼に陥ることだけは、かなりの確立で防止できるのである。


3 リスク

   何をするにもリスクは付き物だ。システム構築は、成功率が30%と言われるほどリスクの高い投資である。そのリスクに無頓着で、業者に任せっきりにするのは、保険に入らずに車を運転するのと同じくらい危険だ。システム構築における主なリスクは、認識的リスク、人的リスク、技術的リスク、組織的リスクである。

それぞれのリスクは、単独ではなく複合的に襲ってくることが多いので、常にリスクに対してアンテナを高くして、コスト、時間に与える影響によって優先順位を付け、それぞれのリスクに応じて早めに対策を打つ必要がある。リスクに対するアンテナを敏感にするには、間接的な情報だけに頼らず、3現(現場、現物、現実)主義を尊重する事だ。例え、技術面に疎くても、リスクに対する嗅覚やカンは鍛えられる。

なぜなら、システム構築におけるリスクは、いずれのリスクであっても、必ず人が絡んでいるからだ。ソフトウェアとは、全てが人の論理思考によって創出されるものであり、自然科学のように自然現象を取り扱わないので、材料が環境や天候、熱や力により劣化や破壊するなどの不確定要素の高いリスクは無い。技術的なリスクであっても、よくよく聞いて見ると、人の思考過程に起因することが多い。


◆認識的リスク
  もっとも多いのが、この認識的リスクだ。システム構築は、認識に始まり認識に終わる。いろんな段階で、認識を誤る、勘違いするというリスクがある。目的を誤認する。要件を誤認する。要求事項を誤認する。伝える相手を誤認する。聞く相手を誤認する。進捗状況を誤認する。問題の本質を誤認する。これは、システム構築が人の認識の上に成り立つものであり、形を成さないという本質的な宿命を負っていることによるものである。

  そもそもの目的を誤認しているのでは、それ以降の認識が正しいか否かを議論しても意味が無い。まさかと思われるような目的の誤認が、このシステム構築では起こりえる。それは、ハードウェアのように目的物の最終的なイメージを形で表現することができないためである。例えば、顧客管理システムといっても、その思い描く目的は10人10色。誰もが認識できるような形として表現することはできない。

  例え、オブジェクト指向であっても解決できない領域のリスクが存在する。そこで、早期に誤認を発見し、見当違いのシステムが構築されるのを防ぐには、誰もがわかる地図を用意する事と、適切なチェックポイントで、それまでに通過した道と進行方向が正しい事を確認しながら進むしかない。地図とは、バランススコアカードや経営戦略、業務モデルや業務フローなど、人の思考を表現するものならなんでも良いが、関係者全員が5W2Hに沿って、情報の流れを認識できること、シンプルな表記法であることがミソである。

  また、誤認を起こさないためには『聞き間違いは、言う側の恥』という諺を、関係者全員が肝に銘じておくことも重要だ。特に、システム構築を依頼した業者の知識をあてにして、「暗黙の了解」や「1を聞いて10を知る」のようなスタイルでは、誤認のリスクが高くなる。結局、思ってもいないようなシステムが構築されてしまい、痛い目に合うのは誰か。

  もし、誤認を発見したら、徹底的に議論する。何故?を5回繰り返して、問題の本質を抉り出す。そうすることが一見回り道で時間がかかるようだが、関係者全員のベクトルが一致すれば、チームは自然と良い方向へ向かう。逆に、目先のコスト・時間を惜しんで、誤認を放置すれば、後になればなるほど、その悪影響は計り知れないものとなって襲いかかってくる。世のシステム構築の70%が、所期目的や要件の誤認によってコスト2倍、期間2倍の失敗に終わり、中には中途挫折して水泡と帰してしまう例も少なくない。システム構築において、認識的リスクは、危険度最大級のリスクなのだ。


◆技術的リスク
  近年は、ITの高度化・複雑化によりシステム構築における技術的リスクが高くなっている。かつての汎用機だけの世界に比べると、パソコンやUNIXが混在し、それらがネットワークでつながれている。また、搭載されるソフトウェアも、さまざまなベンダのものが混在している。さらに、これらを接続するためのミドルウェアと呼ばれるソフトウェアが複雑さに拍車をかけ、ブラックBOX化を増長している。

  いきおい、新しい技術や製品を採用した場合、マニュアルでは可能なはずが、実際は繋がらない、動かないという事態が発生する。複数ベンダの製品を組合わせて採用した場合は、解決が困難になる傾向にもある。こういったリスクを避けて、実績のある枯れた技術だけを採用してシステムを構築できれば、信頼性、安定性などの技術面だけでなく、コスト・期間でも有利であることは間違いない。しかし、それだけでは満足できないほどビジネス側からの要求も高度化している。

  例えば、既存の汎用機上のシステムを、インターネット経由で社外から利用したいなど、既存の技術だけでは実現できない要求に対して、新しい技術を採用しなければならないこともある。また、新ビジネスを短期間で立ち上げ同業他社より競争優位に立ちたいと思えば、技術的なリスクを覚悟で、新技術を採用し短期構築に挑まなければならない。システム構築コストを削減するためには、オープンソースソフトウェアの採用も必要だ。

  このような場合には、できるだけ早めに技術的な検証を目的とした実験を行うことだ。例え、開発初期に追加の費用を払ってでも技術検証を依頼したほうが、システム構築が本格化してから「できない」という事態になるよりはましだ。最悪「できない」という事態になってしまったら、その理由が費用的なものなのか、時間的なものなのか、それとも純粋に技術的に不可能なのかを良く見極める必要がある。

  費用的・時間的にできないという場合は、その影響を分析し、投資対効果を見極めた上で実施の可否を判断する。また、技術的に不可能な場合は、より高い技術者を採用すれば可能なのか、一般的に不可能な要求なのかを見極め、あきらめるか否かを決断する。時間と費用をかければ大抵の技術的課題は解決すると思われるが、ビジネス上の目的や目標に照らして、その技術を採用することの有用性を経営的観点から判断しなければ、単に技術的興味でコスト・納期に影響を与える事となる。技術自体に価値を見出すのは研究者やシステム業者に任せておけばよい。

  この他にも、IT業界は浮き沈みが激しく欧米では企業再編なども盛んだ。こういったことに対して、採用した製品が巻き込まれると、突然のサポート停止や質低下となることもある。できるだけ、将来性のある製品を採用することと、もう一つは、その製品に依存しないようにシステムを構築しておく。ポイントは、実行時には業務プログラムだけで動き、製品の存在を必要としないこと。一部の開発ツールには、実行時にも製品が無いと業務プログラムが動かないものがある。もし、その製品がサポート停止になれば、業務プログラムも塩付けになる。

  そして、保守可能な形でソースコードを確保すること。これも一部のソースコードを生成する類の開発ツールは、製品が無いとプログラムを全く変更することができない。製品が無くても、ソースコードさえ完全な形で存在すれば、なんとかなるものだ。さらには、特定の基盤ソフトやデータベースソフトに依存しない言語や環境を採用しておくこと。近年、Javaを採用する企業が増えてきたのも、技術動向の流れが速いIT製品に対し依存度が低く、一度作成した業務プログラムは、どの製品の上でも動かすことが出来るという利点が評価されているからだ。

  自社でゼロからシステム構築する力の乏しい企業が、業務パッケージを採用して手っ取り早く、業務改革とシステム構築を済ませるというケースも増えてくると思うが、ソースコードも無く、中身もブラックBOXでは、業者に首根っこを押さえられたも同然。せめて、自社の業務が、パッケージソフトに塩付けにされないように、業者の経営状況や製品のサポート状況をこまめにウォッチしてほしい。そして危ないと感じたら、早めに他の製品に乗り換えることを考えたほうが良い。その為にも、追加開発は必要最低限に抑えておくべきである。大型の業務パッケージでは、技術的リスクが経営的なリスクに直結しやすいので、その製品の10年、15年先を見極める力量が必要になる。


2 これからが本番、儲けてなんぼの実用展開
  いよいよ、運用試験も完了し実用段階である。システムは、実用化して成果を出してこそ意味がある。とにかく動けば、それでシステム構築が成功したなどというのは間違いである。そこを勘違いして、完璧なシステムを構築することが目的に摩り替わってしまい、ここまでたどり着くのに青息吐息になってしまい、いざ実用開始する段階になって安心(
 放心)してしまうケースが少なくない。特に、大きな規模になればなるほど関係者は、カットオーバがゴールだという認識であるようで、テープカットや打ち上げなどセレモニをして大騒ぎしているのは、滑稽でもある。別に、それが悪いわけではないが、システム構築の完了はあくまで通過点であり、これからがスタートと考えるべきである。いうなれば、システム構築の完了は、飛行機が完成したのと同じであり、実際にエアラインに配備され、旅客を乗せて運行しなければ、どんなにスバラシイ機体も、ただの鉄の塊に過ぎないのと同じである。業者などシステムを構築することを生業としている者としてはそれで良いが、システムを利用して確実に成果を獲得し、所期の目的を達成できて一段落である。


◆実用展開戦略
  システムを実用化し起動に乗せ確実に成果を獲得するのは、それなりに綿密な戦略が必要である。利用者の自主努力に任せておけば、自然に定着するなどというのは幻想である。著者の知るところでも、鳴り物入りで構築した電子伝票システムが、いざ実用化開始してみると、まったく使われず、あいかわらず現場は紙の伝票を使用し続けて、いっこうにシステムの利用率があがらないということがあった。

  その状況に対して何もせず手をこまねいていたわけではなく、利用部門のシステム構築担当者は懸命に現場を走り回り、トップダウンでも、システム構築の目的を再確認し、早期の実用定着化を訴えた。それでも、なかなか利用率が上がらない。現場の実態を調査してみると、電子伝票システムの実用化と並行して、これまでどおり紙の伝票を使用していたため、不慣れなシステムを利用していなかったのである。

  これは、システムの実用開始と同時に、紙を全面的に廃止してしまうと混乱が生じるかもしれないという安全策が裏目に出た結果である。後から考えれば、運用試験で十分に利用者を教育しておけば心配はなかったものを、その時間と労力を惜しんだために、いらぬ心配をしなければならず、紙とシステムの並行運用という実用展開戦略をとらざるをえなかったのである。結局、紙の伝票を一切認めないということを現場に周知することで、システムの利用率を向上する事ができた。

  その他にも、高度な機能を一度に実用定着させようとしたために、結局、手作業のほうが効率的という誤解が生じて、ほとんど使われないシステムも存在した。このケースでは、まずはじめに単純な機能に限定して実用定着化を図り、普及した段階を見計らって高度な機能を利用するように展開することで解決を図った。あるいは、正確なデータをタイムリに入力しないために、システムからの出力が信頼されず、業務に使われないというケースでは、地道なデータ整備を実施しなければならなかった。このように、利用者の情報リテラシを見極め、実用化に合わせてレベルアップを図ると共に、システム化された業務については、システムを利用することを義務付け、抜け道を遮断することが必要である。

  システムでは対応できない例外ケースを手作業で柔軟に対応するのはよい事であるが、システム化した業務まで、柔軟(勝手)に抜け道を作って通してしまっては、システムは一向に定着しない。誰しも、頭では経営上のシステム化目的を理解しても、自分が慣れていないやり方には抵抗感があるものだ。厳しく、かつ、優しく現場を引っ張っていくには、運用試験に続いて、ここでもキーマンの働きが重要となる。

  システムの使い始めは、誰もが不慣れなために単純なところでつまずいたりするものである。その時に、身近にいて、すぐに助けの手を差し伸べてくれるキーマンがいなければ、たちどころにシステムは使われなくなってしまう。システムを使わなければ、そもそも仕事が成り立たないように、うまく業務プロセスに組込んでしまえれば、申し分ないのであるが、必ずしもそういかないケースもある。そのような場合、システムというものは、とても脆弱である。

  ITの冒頭で述べたように、その本質が「読み・書き・そろばん」である以上、システムに何も入力しなければ、何も出てこないのである。そのような状況において、システムを定着化させ、確実に成果を挙げるまでに地道な定着活動が欠かせない。それを、現業と並行して先頭に立って行わなければならないキーマンは、ボランティアであるよりは、なんらかのインセンティブを与えられたほうが、はるかにやる気が出るというものだ。


◆測定できなければ評価しようがない
  システムを実用開始したら、その成果を測定する必要がある。半年なり、1年なり経過した後に最終的な評価をしなければならないので、そのために成果を確実に測定する。システムが実用開始され軌道に乗ると、それで大成功と思いたくなるが、それだけでは当初のシステム構築の目的を達成したことにはならない。計画当初に目論んだ目標を達成できたかどうかを継続して測定するためには、どんな指標で測定するかを明確化しなければならない。

  そして、その指標は、目標に対して関連付けられている必要がある。これは、バランススコアカードなどを利用して、財務面だけでなく、顧客の視点、社内プロセス、教育と学習など多面的に評価できるように、各視点での重要指標をあらかじめ定め、それにそって成果を継続的に測定しなければならない。

  当初の目的が人減らしであり、削減人数を何人としているなら、それはそれで単純に成果を測定することができる。しかし、その削減した人数の移動先が、社内である場合は、簡単ではない。なぜなら、社内から人が居なくならない限り固定費を削減することにならず、会社の損益には反映されないからである。良くあるのが、業務効率化によって浮いた人を、別の付加価値の高い仕事に移動するというものだ。

  この場合、単純にシステム化した業務の担当者が何人減ったかを測定しても意味が無い。最終的には、付加価値の高い仕事をして、実際に売上げ増につながるとか、製品コストが下がるとかして、利益貢献したかどうかを測定しなければならない。しかし、移動した人が、実際に高付加価値の仕事をするかどかは、はなはだ俗人的であり、さらにそれで利益貢献したかどうかを測定するのは極めて困難である。

  それでも、1人分以上の業務を削減できる場合は、まだ良い。効率化による成果が、0.5人分とか、0.2人分とかである場合にはさらにやっかいだ。1日8時間の仕事をシステム化して効率化できても、それが4時間とか6時間であるなら、その浮いた時間をどう使うのか?人件費の削減までにはならないし、浮いた時間にちょうど、当てはまるような仕事がなければ、結局、休むか仕事のペースを落とすだけのことである。

  また、顧客情報システムを導入して営業支援などを目的とした場合も、システムにより売上げがどれくらい向上したのかを正確に把握するのは困難である。あるいは、知識共有システムを構築して、新しいアイデアを創出し、新製品開発に活かそうという場合、新製品が生まれたがどうかだけでは成果測定が難しく、例え、新製品が生まれても、それがシステムによる知識共有の成果なのかどうかは疑わしい。さらには、昨今の外注化政策が進んだ企業では、効率化によって外注要員を減らせたとしても、それが外注費に反映されなければ、自社で投資をしながら、外注会社の業務効率化をしているようなことにもなりかねない。
  
  このように、成果測定の指標を財務面だけに求めてしまうと、合理的な成果を測定できず、結局、数字遊びのような成果測定になってしまう。これでは、システム構築による成果を正しく評価することができなくなる。そこで、バランススコアカードを利用することで、財務面だけに偏らずに多面的、かつ、総合的な成果を測定することが可能となる。


◆質の高い仕様書


  要件を満足するための、必要にして十分な「質の高い仕様書」とは、どんなものか。それは、要件を満足するように、コンピュータにやらせるべき「読み・書き・そろばん」が明確になったものである。特に、コンピュータに何を「書かせる(出力させる)」のかを第一に考えなければならない。決して、ITの技術的・専門的に高度な内容を「質が良い」と言っているわけではない。
    
  具体的には、画面や帳票に、誰に、いつ、どこで、何を、なんの為に出力させるのかを、各業務プロセスで扱う情報項目の全てについて決定する。そんなに細かいところまでと思われるかもしれないが、たった一つの重要項目が抜けていることが、運用直前で発覚して、予算超過や実用開始遅れ、混乱を招くことも珍しくない。逆に、大して重要でもない情報を大量に出力するのは、全てにおいてムダである。
    
  コンピュータは、あっというまに無駄なゴミ情報を大量に吐き出し、伝達してしまう。その出力情報に埋もれて、人が整理に時間を要したり、混乱したり、あるいは、そのまま捨てられた中に重要な情報があったりしたのでは、ITによる競争力強化どころか、効率化さえもままならない。
    
  要件の実現に必要にして十分な出力項目が決まったら、次に、その出力を得るための計算式(そろばん)を、同じく5W2Hにそって決定し、さらに、その計算式に必要な入力(読み)を決定し、画面・帳票としてマッピングする。
    
  画面・帳票の他に、ファイルというものがあり、これは、コンピュータ内部のことなので、ユーザには分かり難いと思われているが、そんなこともない。「読み・書き・そろばん」において、必要な情報を、どのように整理して保管しておくかを考えれば良いだけである。事務ファイリングと同じである。仕事をするのに、取り出し易いようにキングファイルを整理分類しているように生活の知恵を働かせることだ。
    
  出力から遡って、必要なときに、必要な情報が取り出せるようにしておくには、どうやって情報を整理し、何を記録・保管しておけば良いのかを決定する。なお、一時的に必要な出力情報や、他の情報から計算によって得られる情報は、ファイルとして記録・保管する必要はない。そのために、ITの専門知識も用語も必要ない。そうやって、考えられたファイルを、コンピュータ上で、どのように実現するのかは業者に任せておけばよい。
    
  実際は任せ切りにしていると、とてつもなく高価な最新のデータベース・システムを意味もなく買わされたり、逆に、遅くて使い物にならないプログラムを作られることも少なくない。そういったことを避ける意味でも、要件を満足する出力を得るために必要十分な速度、対象となるデータ量、利用者数(同時、最大)などを、あらかじめ想定して仕様書に明記しておくべきである。


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

  とかく、雑誌やIT業界は、新技術を売り込みたがるものだ。また、実際のシステムに  適用し「実績」を作りたいのだ。それが、顧客のシステム開発案件の中で適用できるなら、  それは、お金をもらって実証実験ができるのであるから、こんなおいしいことはない。  そこで、顧客の要求仕様を実現する為に、さまざまな理由をつけて、新技術を採用すれば  「こんな、いいことがありますよ。」といって売り込みをかける。それが、必ずしも顧客  の利益にならない場合がある。

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

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

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

  既存の技術を使った安価なシステムを提案する業者と、新技術をふんだんに取り入れた、  革新的な高価なシステムを提案する業者と、どちらを選ぶべきかは、あなた次第である。  しかし、「最小の投資で、最大の効果を生む、儲かるシステム」を構築したいなら、おの  ずと答えは明快である。ご親切に、お金を出して業者の実証実験に協力し、儲けさせるこ  ともなかろう。もっとも、新技術の最初の適用事例となって、広告塔になるかわりに、開  発費を値切るという荒業もないではない。この場合、自社の知名度や業界への影響力がも  のを言う。


◆部品化・構造化の落とし穴
  システム構築にあたり、部品化・構造化は、生産性を向上させるための古くて、新しい考え方である。あらかじめ用意された部品を組合せて、システムを構築できれば、確かに早く、安くシステムを構築できるだろう。確かに、自動車などでは、こういった部品化により、安く、早く、良い物を作ることが実現されている。しかし、業務システムの場合は、いかがなものか。
 
  特に、製造業における生産管理などは、会社毎に全て違うと言っても過言ではない。超多品種少量生産なのである。自動車会社でも、顧客にあらゆる部品の組合せを自由に選択させる方式を導入したところがあるが、やはり納入リードタイムが長くなっているそうだ。システムに要求される仕様にあった部品を探しているくらいなら、作ったほうが早いと言うこともありえる。
    
  コンピュータの世界における部品とは、あくまで、人が、要求事項に沿うように、コンピュータの振舞いを図式化し、設計し、プログラミング言語で定義したものである。つまり、その部品は、作る人によって振舞いが微妙に異なるのである。例えば、実世界では、同じ「本」であっても、システムにおける「本」という部品は、書店の業務システムと、図書館の業務システムと、出版社の業務システムでは、それぞれに振舞いが異なる。
    
  従って、要求仕様にピッタリ合う部品を探すことは、かなり困難である。そこで、現実問題として、どうするかというと、似たような部品を複製し、一部改修して目的の部品に仕上げるのである。また、全体の構造は、ある時点での要求事項を満足するために考案した、一時的な部品どうしの関係を定義したものである。古くは、階層型で関係を定義し、最近では、部品どうしの応答をネットワーク型で定義しているが、いずれも、静的な状態を定義したものである。
    
  ところが、現実の世界は混沌としており、時間と共に変化する。開発中、あるいは運用中に、その変化に合わせて、部品なり構造なりを変化させていかなければならない。部品化しておけば、他の部品に影響を及ぼすことなく、これを実現できるというのが理想であるが、現実は、そう単純ではない。この場合に、部品の中味が明らかになっていれば問題ないが、ブラックBOXになっているとやっかいである。あくまで、外から見た振舞いだけで、影響のあるなしを判断しなければならない。
  
  開発当初は、部品の再利用により生産性が良くなったとしても、このような状況に陥ってしまうと、かえってコストアップにつながる。また、少しずつ振舞いの異なる、似たような部品が増えてしまい、管理が手薄になると混乱の極みである。中味がブラックBOXである部品と、部品同士の複雑な関連、構造化により、業務変化のスピードにシステムの変更が追いつかなくなってしまっては本末転倒である。本来、部品化・構造化は、こういった問題を解決するために考え出させた手法である。その手法が、逆に自ら問題を引き起こすことになる。
    
  最近では、多数の部品を提供しており、その組合せでシステムを構築するという業者も出てきているが、そのメリットは、顧客に還元されているのか疑問である。また、使われた部品は、あくまで提供した業者のものであり、中味はブラックBOXである。ソースコードの提供もしている業者もあるが、その場合は、決して「お安く」はない。それに、その部品を使って、新しい部品を作ったり、組合せてシステムを構築するのは簡単ではない。そこで、また、コンサルティングが必要になったりする。
    
  部品化して、中味が分からなくて良いのは、システムの中で、コンピュータとやりとりする内部の処理で、ほとんど変更が無いような箇所だけである。業務プロセスのように、環境変化に合わせて、処理内容(振舞い)を変更していかなければならないような場合は、中味が分からなければならない。システム構築において、部品を利用して、コストダウンを測る場合は、運用後の保守も考慮して、最小の投資になるか否かを判断しなければならない。


2 もっと安くなる見積りの取り方、商談のしかた
   皆さんは、システム構築費用が、どのように決まるか御存知だろうか。あるいは、業  者の提示する見積もりが妥当だと判断して契約をしているだろうか。一式いくらで、こん  なもんだと言われて十分納得できなまま契約していないだろうか。もちろん、仕様書が数  ページで、画面数も分からない仕様書では、業者も、それなりの見積書しか作りようがな  く妥当かどうかは、分からないとしてもしかたがない。

  しかし、これまで述べたように、しっかりとした仕様書を作成したなら、それに値する  だけの見積書の提示を求めることができ、その妥当性について業者と納得行くまで交渉し  商談が可能である。単に、「もっと安く」という水掛け論や、不当な値引き要求は、結局、  見えないところで手抜きされ品質が悪化する。最小限の投資で、最大の効果を生むシステ  ムを、早く安く構築するには、業者と納得行くまで話し合った上で、妥当な金額を算定し  なければならない。「安かろう、悪かろう」ではかえって高い買い物になってしまう。


◆見積りの取り方
  システムは、ハードウェアとソフトウェアから構成されおり、それぞれに見積もりのベ  ースとなる要素がある。それらの要素は、決して専門家だけが理解できるものであっては  ならず、あくまで顧客である、利用者からのシステムに対する要素をベースに見積り・商  談がなされるべきである。もし、業者の見積りが理解できないのであれば、理解できるよ  うに作成してもらうべきだろう。

  ハードウェアにおいて利用者にとって意味のある要素とは、要求応答時間、同時利用人  数、利用回数、データ量、故障時の復旧時間などである。CPU処理能力がどうとか、D  ISKの性能がどうだとかそういった専門的な説明を聞いても分からないし、それらが直  接、利用者にどのような影響を及ぼすのか分からない。業者が、そういった、個々の性能  数値を説明したがる場合は、おそらく業者にも分からないかもしれない。したがって、ハ  ードウェアの見積りにおいては、ここにあげた利用者にとって意味のある要素に関連つけ  て見積もりを作成してもらうのが良い。

  例えば、要求応答時間がxx秒、同時利用人数がxx人だから、CPUは1GHzのも  の2個とメモリ2GBが必要という具合である。このように見積りを作成してもらうと、  合い見積もりをとる場合も、比較がしやすく、また、同時利用人数が増えた場合、どれく  らい追加の費用が必要になるか、あるいは逆に、費用を削減した場合、どれくらいの応答  時間、同時利用人数になるかを、ある程度想定することができる。もし、見積りに予算が  合わない場合、仕事のやり方を工夫し、同時利用人数を半分にすることができれば、投資  額を削減できる可能性がある。

  つぎに、ソフトウェアにおいて利用者にとって意味のある要素とは、画面・帳票・ファ  イルである。個々の要素に難易度で重み付けをして機能数(FP:ファンクションポイン  ト)を決定し、これに、単位FP当たりの単価を乗じて金額を算定する。難易度は、デー  タ項目数と機能の複雑度で決定される。

  例えば、複雑な画面は、100万円/画面などとなる。これに、改修の場合は、改修率  を乗じる。また、類似の機能であれば、流用率を乗じる。同じような機能で表題の1部が  異なるだけの帳票や画面が多数あるような場合、業者が単純に積み上げてくると膨大な費  用になるので注意が必要である。これで、システム全体の画面・帳票・ファイルを数えれ  ば、全体の金額が決まる。ここで、作業範囲や開発言語・ツールの生産性などを加味して  単位FP当たりの金額を調整すれば最終的な開発費用が決定する。作業範囲には、要件定  義、要求仕様、外部設計、内部設計、プログラム作成、単体試験、統合試験、運用試験な  どがあり、生産性は、COBOLを1とした場合に対する、他の言語の生産性を倍数もし  くは、比率で示す。

  次に、作業範囲を、内部設計〜統合試験とすれば、全体作業の60%、開発ツールをV  Bとすれば、生産性を1.6倍(60%)とし、各々を割り掛ける。ここで、作業工程の  定義と、各工程の作業内容および成果物について、理解を合わせておく必要がある。その  上で、作業内容や成果物のボリュームによって、単位FP当たりの単価を調整することも  できる。全体金額が、100万円ならば、100x0.6x0.6=36万円となる。こ  の見積り方法を、ファンクションポイント法と呼ぶ。ソフトウェアの見積りには、ぜひ、  このファンクションポイント法を用いてもらいたい。

  ファンクションポイント法の利点は、画一的に金額を算出できるということではない。  難易度などは、かなり主観的な判断が入る余地がある。むしろ、その主観的な部分につい  て、利用者からの視点で、ベンダと交渉ができるということにある。利用者から見て、大  した価値を生まない画面に多額の金額を支払う必要はない。逆に、価値のある画面であれ  ば、業者の内部作業工数にかかわりなく妥当な対価を支払っても良いだろう。さらに、仕  様書から画面・帳票・ファイルを数え上げるので、成果物の漏れや忘れを発注者・受注者  の双方でチェックでき、合意の上で発注できるので、納品時に「画面が足りない!」とい  うようなトラブルも未然に防止できる。
 以下に見積り計算式の例を示すので参考にされたい。

 開発費(円)=FP数 x 改修率(流用率) x 言語生産性 x FP係数 x 単価(円/FP数)
 ・FP数:
  単純入力/出力ファイル(3)、普通入力/出力ファイル(5)、
  複雑入力/出力ファイル(8)
  単純入出力ファイル(3)、普通入出力ファイル(6)、複雑入出力ファイル(13)
  単純入力画面(3)、普通入力画面(6)、複雑入力画面(13)
  単純出力画面(3)、普通出力画面(5)、複雑出力画面(8)
  単純入出力画面(6)、普通入出力画面(11)、複雑入出力画面(19)
  単純メニュー画面(2)、普通メニュー画面(2)、複雑メニュー画面(9)
  単純帳票(3)、普通帳票(6)、複雑帳票(10)
 ・改修率:新規(1)、改修(0.1、0.2、0.3、0.5、0.7)
 ・言語生産性:COBOL(1)、VB(0.6)、MS-Access(0.25)、アセンブラ(1.5)
以下より、最新の言語別生産性一覧表を購入することができる。
  http://www.spr.com/products/programming.htm
 ・FP係数:作業対象範囲 / 全工程
    要求分析(2)+設計(3)+製作(3)+試験(2)=全体(10)
  例 製作(3)+試験(2)/全体(10)=FP係数=0.5
 ・単価 10万円/FP

 計算例:普通入出力画面、新規、言語VB、設計〜試験工程作業
 開発費(円)=FP数(11) x 改修率(1) x 言語生産性(0.6) x FP係数(0.8)
        x 単価(10万円/FP数)
       =52.8万円

  ソフトウェアの見積もりは、古くはプログラムの行数による見積もりや、人月による見  積もりが慣例的に行われている。しかし、これらは、いずれも開発する業者側の作業規模  をベースとした考え方であるため、利用者からは、その妥当性が良く理解できない。利用  者にとっての「価値」にそぐわないなどの問題が指摘されている。その矛盾については、  後述する。


◆人月の矛盾
  ソフトウェアの開発費用は、『作業時間=人月(5人で2ヶ月なら10人月)』に単位  金額を乗じて決める。つまり、製造コストのほとんどが人件費という特異な産業である。  その生産性は、使用する開発ツールやプログラミング言語、開発手法、人の能力(なんと  最大で生産性10倍以上違う!人件費が10倍違う!製造コストが10倍違う!)などで決  まる。

  従って、例え同じ画面数のシステムであっても、人の生産性によってシステム構築費用  は、大きく異なる。業者から一式1000万円の見積り(そもそも一式いくらの見積りし  か出せない業者は信用できない。妥当性のある見積りを作る能力が無いということは、そ  れまでの実績管理がされておらず、組織的な原単位や見積り基準も無く、いきあったりば  ったりで、その都度、担当者がエンピツを舐めて見積もっている可能性さえある。そんな  業者に、まともな設計・開発技術力があろうはずがない。)であっても、生産性によって  1/2〜1/3にもなる。

  場合によっては、一桁違ってくることもある。例えば、MS―Accessの生産性は、  一般的に他の言語の4倍の生産性である。仕様を見直して、MS―Accessで、開発  してもらえば1000万円が、250万円になる可能性もあるということだ。さらに、標  準のテンプレートをベースに手直しする程度であれば、さらにゼロが一つ減る。

  ところで、ソフトウェア費用は、作業時間で決まると書いたが、実は、ここに大きな矛  盾がある。それは、ソフトウェアの生産性は個人の能力に最も左右されるという点だ。例  えば、同じ画面・機能のプログラムであっても、優秀な人なら1ヶ月、ところが新人や不  慣れな人では2ヶ月かかるとします。その場合、単価が、1人月で100万円とすると、  出来の悪い人がやったほうが200万円と高額になってしう。

  発注側の我々からすれば、同じ画面・機能であるので、誰がやろうと同じ価値であるの  に、その価格が違うというのは、価値工学的に考えれば、明らかに矛盾がある。中には、  作業時間の原単位として作成物数を、いまだにプログラムの行数(命令数)で提示してい  る業者もあるかもしれない。しかし、行数であっても同じ。優秀な人が書けば、1000  行で実現できる機能を、できの悪い人が書けば、2000行になるかもしれない。また、  最近の生産性の高い開発ツールを使用すれば、さらにプログラムの行数は少なくなる。  これでは、ベンダの人材育成費や開発生産性向上の研究費まで肩代わりしているようなも  のだ。

  この傾向は、大手だから優秀で、生産性が良いかというと、そんなことは決してない。  ソフトウェアの生産性は、あくまで、プログラムを作る個人の能力に依存している。そし  て、大手は、自分達ではプログラムは作成せずに、2次、3次の下請けにやらせている。  大手では、1人月100万円程度が相場だそうだが、それには、この中間マージンや一般  間接費用、宣伝広告費用、管理職の給料などが、たっぷりと上乗せされている。だからと  いって、担当の技術者が、特別に「早く、安く、良い」システムを提供してくれるわけで  はない。確かに大手には優秀な人が集まるかもしれない。しかし、彼らは、官公庁や金融  機関などの数十億円規模のプロジェクトに投入されており、我々のように1件、数百〜千  万円規模のプロジェクトには、「手配屋さん」しか投入されない。このように作業時間に  よる金額というのは、非常に大きな矛盾を抱えている。

  そこで、先に述べたファンクション・ポイント法が考案された。これは、あくまで、利  用者側からみたシステムの構成要素である、画面や帳票(入出力)等を基本単位としてシ  ステム規模と開発費を決定する。

  これまでの欧米などでの研究調査の実績や私の経験から、平均的な画面機能、開発言語、  生産性での要件定義〜完成までの単価は、70〜100万円/画面、程度である。つまり、  ソフトウェアの平均的な生産性は、世界的にもあまり差が無いということである。ただし、  個別には言語や個人の能力で、最大10倍の差が出るのは前述したとおりである。


◆仕様書
  次に仕様書の基本的なチェック項目を紹介するので参考にされたい。さらに、記載内容  については前述の「質の高い仕様書の基準」や「分かりやすい表現」も合わせてチェック  していただきたい。ソフトウェア開発というのは、意図するところを人間の言葉からコン  ピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水は、  なかなか途中で注ぎ足すことが難しい。

(1)題名は、「..システム仕様書」のように、システム名を明記しているか。
    ”名は体を表す”というので、一考を要する。
(2)システム概要(業務フロー)は、システムの全体、業務との関連、他システム
    及び業務との連携が理解できる内容か。5W1Hに照らし合わせてチェック。
(3)帳票は、名称、入出力の区分、データ項目、レイアウト、入出力方法、入力チェック
    及び条件が明確か。
    各帳票に対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(4)画面は、名称、入出力の区分、データ項目、レイアウト、入出力方法、入力チェック
    及び条件が明確か。また、各画面の操作方法、メニュー構成及び遷移が明確か。
    各画面に対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(5)ファイルは、名称、入出力の区分、論理構造、各データ項目の名称、属性、長さ、
    キー項目等が明確か。
    *既存の帳票、画面、ファイルは、識別可能な名称があれば、自明な詳細事項の
     記述は不要。
    各ファイルに対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(6)各画面・帳票等の要求機能、処理方法は理解できる内容か。
    処理条件、処理サイクル、タイミング、処理件数の平均値と限界値、必要性能
    (処理時間、レスポンス)、エラー処理、データのバックアップと廃棄処理、
    セキュリティ対策等は明確か。
(7)入力〜処理〜出力の流れ及び関連が、業務プロセスに対して矛盾無く理解できるか。
(8)各帳票、画面と関連ファイルのデータ項目は対応付けされているか。
(9)各帳票、画面、ファイルの各要素に対し、新規、改修、既存が判別できるか。
(10)要求仕様は、業務上の期待効果の実現に対し、過不足や矛盾はないか。
    上位文書である、要件定義書の各業務要件と各要求仕様の追跡性を確保しているか。
(11)要求仕様は、技術的、費用対効果的に実現可能かつ必要十分な内容か。
(12)要求仕様は、見積書のデータ型(帳票、画面、ファイル)の種類及び数と整合性が
    とれているか。
(13)略語、専門用語、コード表、エラーメッセージ表等の説明があり、明確か。
(14)購入ハードウェア/ソフトウェアとの関連は明確かつ整合性がとれているか。
(15)データの移行作業等が検討されているか。必要な場合は、移行条件等が明確か。
(16)運用上の制約条件や障害発生時の回復時間などを規定しているか。
(17)システム化対象業務に関連する職制の承認サインを得ているか確認する。



◆見積書
  ソフトウェアの原価は、ほとんどが人工費であるので、生産量と生産性の合意が基本と  なる。ここでは、ファンクションポイント法による見積もりを前提に、チェックポイント  を紹介する。従って、仕様書上で要求されている画面・帳票・ファイルに対して過不足が  無いこと、各構成要素の難易度や改修率に応じたFP数、単位FP数当たりの生産性や原  単位などが妥当かどうかがチェックのポイントとなる。複数の業者から合い見積もりを取  る場合も、このような見積もりであれば比較検討しやすい。もっとも、1式いくらでは、  比較検討のしようがない。単に安いか高いかだけでは、もしかすると大きな見積もり漏れ  や、作業範囲などに相違があるかもしれない。見積書は、提案書でもあるので、その内容  を見れば実力や誠意を伺い知ることができる。仕様書どおりの言われた事だけやるという  見積書と顧客の立場に立って、必要十分な内容での分かりやすい見積書と、どちらの業者  を選ぶかは自明だ。

(1)数量(工数)、単価、金額は、明示されており、計算間違いはないか。
(2)見積り有効期限は、明示されているか。
(3)システム仕様書に対し、データ型(機能)は過不足無く定義されているか。
    整合性をチェック。
(4)処理方式ではなく、外部機能(帳票、画面、ファイル)に着目してデータ型を定義
    しているか。
(5)内部処理の作業用一時ファイルをデータ型として定義していないか。
(6)階層型データベースや表データベースでは、全体ではなく、関連するセグメント
    や表のみを対象ファイルとして項目数、難易度を算出しているか。
(7)各データ型(入力、出力、入出力)の区分は、システム仕様書に対し妥当か。
(8)難易度別、データ型(画面、帳票、ファイル)の数は、システム仕様書に対し妥当か。
(9)難易度の選定(難易度表:データ項目数、処理の複雑さ)は、システム仕様書に
    対し妥当か。
(10)修正率の選定は妥当か。
    ・類似ソフトの流用、プログラム部品の使用を考慮しているか。
    ・全体に対する、改修部分の規模から見て、妥当な修正率か。
    ・改修でも、外付け可能な機能追加は、その部分を新規開発とした場合と比較検討する。
(11)開発言語の生産性は妥当か。
    ・生産性の良い、適切な開発言語、ツールを選択しているか。
    ・汎用ソフト、ユーティリティ、開発ツールの使用を考慮しているか。
(12)FP係数(単価/FP又は作業工数/FP)は妥当か。
    開発標準により、作業工程と各工程での実施作業及び成果物が明確化されている
    ことを確認し、その上で、委託する作業範囲及び成果物及び仕様書の完成度に応
    じて妥当かを確認する。
(13)マクロ的に見て、合計金額、合計工数は、システム規模に対し妥当か。
    過去に実績のある、同等内容・規模のシステムと比較して見る。
    このためにも、システム構築の実績を画面・帳票数、FP数、作業範囲、成果物、
    発注金額などで記録しておくと良い。
(14)データ型、難易度、ファンクションポイント数(FP)、金額は、矛盾や計算間違いがないか。
    基本的なことであるが、あとで揉めないようにキッチリとチェックし、納得でき
    ないところはしっかりと説明を求めるべきである。
(15)別途、導入・移行作業等が必要な場合に、見積りがしてあるか。
    見積もりから漏れていることが少なくない。
    いざ実用開始直前に追加費用が発生して慌てないようにしたい。
(16)ハードウェア、ソフトウェア、ライセンス等、必要十分な購入品を別途、見積り
    してあるか。システム仕様書及び実際の業務要件、運用環境に対して、必要十分
    な性能・容量・数量等がサイジングされているか要確認のこと。



◆設計書
  設計書の内容は技術的になるので、あるていどITに対する知識がないと難しいが、で  きれば設計レビューにも参加することを勧めする。早い段階で、以下を確認しておくこと  で設計者の漏れや勘違いを早期に是正できる。運用試験などの後工程で発見し、後戻りや  繰り返しを重ねるよりはコストや期間を抑制できる。

 (1)仕様書の要求事項が、確実に設計に反映されていることを追跡しやすいように
    記述されていること。
    例えば、仕様書の記載項目のページ番号や章・節と、設計事項との対応リストなど。
 (2)使用している設計手法やテンプレート及び、その選択理由が明確であること。
 (3)アーキテクチャについて、何故、それが最善の方式であるのか明確かつ、
    論理的に説明できること。
 (4)代替案を、2つ以上比較検討していること。
 (5)設計上持ち込んだ、制約事項等の確認。例えば、最大処理件数やデータ容量など。
 (6)データ項目の桁数、属性、識別キーなどの確認。
 (7)障害対策やバックアップ機能の確認。
 (8)ユーザビリティやアクセシビリティ、ユニバーサルデザインを考慮していること。


Counter