中堅・中小企業における IT 経営推進上の課題

(1)

中堅・中小企業における IT 経営推進上の課題（大島）

はじめに

企業が競争力を強化し，その生産性を向上していくためには，抜本的な構造改革・課題解決に向けて，IT を高度に活用する「IT 経営」の実践が重要となる（情報化白書2006）。目的なく，単に業務を IT 化するだけでは，不十分であり，

自社のビジネスモデルを再確認したうえで，経営の視点を得ながら，業務と IT との橋渡しを行っていくことが重要である。このような，経営・業務・IT の融合による企業価値の最大化を目指すことを「IT 経営」と定義している（経

論文

中堅・中小企業における IT 経営推進上の課題

IT の高度な利活用による経営戦略の遂行に向けて

大島博行

（京都学園大学経営学部論集第21巻第 1 号 2011年10月 31頁〜54頁）

要約企業が競争力を強化し，その生産性を向上していくためには，抜本的な構造改革・課題解決に向けて，IT を高度に活用する「IT 経営」の実践が重要となる。しかし多くの企業では，経営・業務・IT の融合による企業価値の最大化を目指す IT 経営が十分に実現できているとは言いがたい状況である。

その大きな要因は，IT 経営の核となる情報システムの開発工程における上流工程にある。本稿では，情報システム開発の上流工程の重要性とその実施方法における問題点を明らかにする。情報システム開発の各工程における方法論は数多く存在するが，上流工程に関する方法論はまだ確立しているとは言いがたい。その数少ない方法論も，どちらかと言えば経営資源が潤沢にある大企業を想定したものであり，経営資源に制約のある中堅・中小企業で使うのは難しい状況である。

キーワード：経営戦略，IT 戦略，IT 経営，情報システム，要求定義，中小企業

(2)

済産業省，2010a）。

しかし，経済産業省が2009年度に実施した「『IT 経営力指標』を用いた企業の IT 利活用に関する現状調査」（経済産業省，2010b）によると，企業における IT の利活用について 4 つの段階（ステージ）に分類^（図表1^）した場合，部門の壁を越えて企業全体での最適化が図られている「組織全体最適化企業群（ステージ 3 ）」や，単一企業組織を超えてバリューチェーンを構成する共同体全体の最適化を実現している「共同体最適化群（ステージ 4 ）」に位置する企業は，わが国では32.5％にとどまっている。アメリカでは，このステージ 3 および 4 に位置する企業の割合が63.8％となっており，韓国でも50％を超えている。

日本企業における IT の利活用状況の遅れは顕著であるといえる。特に中小企業だけを見ると，19.7％とさらに遅れている。

筆者はコンサルタントとして20年近く，主に中堅・中小企業の IT 経営推進 図表 1 企業の IT 化ステージ

出典：経済産業省（2003）

組織改革

トリガー

「システム」の時代

ERP 人事財務・・ SCM CRM SFA ・・

企業の IT 化ステージング

ステージ① IT 不良資産化企業群情報技術導入するも活用せず

情報技術の活用により部門内最適化を実現

経営と直結した情報技術活用により企業組織全体の最適化を実現

情報技術活用によりバリューチェーンを構成する共同体全体の最適化を実現

特定業務の改善

ビジネス／経営管理の高付加価値化

人材力／ブランド力の総合強化

「深化する組織」への脱皮ステージ②

部門内最適化企業群

ステージ③ 組織全体最適化企業群

ステージ④ 共同体最適化企業群

「経営」の時代

企業役割の変革

﹁企業

﹂の壁

﹁経営

﹂の壁

情報技術による企業プロセスの最適化バッ

クオフィスのI T 化

E D I 導入 E C 導電入

子計算機の導入

業務の I T 化

コミニュケーションの最適化社外との連携統合

・標準化

顧客視点の徹底

トリガー

(3)

の支援をしてきた。中堅・中小企業は大企業に比べて経営環境や経営資源の面で多くの制約がある。本稿では，中堅・中小企業の視点から，IT 経営推進上の課題を考察する。

Ⅰ IT 経営が進まない要因

経営は「視点」を，業務は「情報活用」を，IT は「メカニズム」を活かすことによって，経営・業務・IT が融合し，IT 経営が実現する^{（経済産業省，}

2010a）。

○視点：取り組むべき企業改革や業務改革の指針を，経営が提供

○ 情報：改革課題の達成に向け，必要な情報と，それを活かす業務の仕組みを，現場が提供

○メカニズム：改革実現に向け，情報の効率的活用手段をシステムが提供しかしながら，前述の調査結果にあるように，日本企業の多数においては，

こうした経営，業務，IT の融合は必ずしも十分進んでいるとは言えない。日経コンピュータ（2003）の調査によると，情報システム開発プロジェクトの成功率（品質，コスト，納期のすべてで当初計画通りの成果を収めたプロジェクト）はわずか26.7%という結果になっている。その理由をアンケートから分析すると，上流工程が不十分だったため，設計や開発工程で手戻りが発生し，その結果としてコスト増や納期遅延が発生した，あるいは上流工程での不備がそのまま修正されずシステム稼働後に品質への不満として現れた，といった問題が浮かび上がってくる。図表 2 に示すように，経営，業務，IT の融合は，事業要件定義，業務要件定義とも呼ばれる，情報システム開発の上流工程が重要な役割を担うが，その工程で経営の視点や業務の情報を十分に取り込めていな

1 ） 1 ）

1 ）上流工程は要求定義，要件定義等いろいろな名称で呼ばれている。その問題は後述するが，本章では，引用原文での用語をそのまま用いている。

(4)

いため，出来上がった情報システムがメカニズムとして機能しないのである。

これまで多くのベンダーは，システムを「どのように作るか」を重視し，

「何を作るか」を軽く見ていたため，開発方法論の中の要求定義に相当する部分は，システムを正しく作ることに力点を置いており，「どんな目的でシステ

図表 2 要件の定義と役割

出典：IPA（2006）

部署等／役割（ロール）要件の定義内容

経営層社長担当役員

業務部門部門長業務推進担当システム推進担当関連会社

情報システム部門

部門長

システム開発担当システム子会社

ベンダ

元請けベンダアウトソーササブベンダ

事業要件定義事業要件

定義業務要件

定義

システム要件定義システム要件定義

名称項目内容

事業要件定義

ビジネスモデルの検討等

新規事業／社外連係／組織改編／部門間業務分掌変更／現行業務踏襲，セキュリティなど

業務要件定義

業務モデルの検討等

業務内容（手順，責任・権限など），業務形態（ピークなど），業務品質，性能目標，運用，移行要件，セキュリティなど

システム要件定義

システムモデルの検討等

システム構成，業務アプリケーション（構造，DB・ファイル構造など），運用，移行要件，セキュリティ，機密情報保護対策など

(5)

ムを作るか」に関しては，ほとんど踏み込んでいない（日経コンピュータ，2004）。また，要求工学の教科書における要求仕様化プロセスは多様であり，著者ごとに異なるといってもいいくらいの状態である（山本，2006）。したがって，要求定義の重要さは分かっていても，いざ要求定義を行おうとしたとき，どうやっていいのか具体的な手順が分からない，というのが実情である。日経 IT プロフェッショナルが IT 技術者に対して行った調査でも，要求定義の方法論について，標準的な方法論が社内にない場合や，あってもそのままでは使えず自分なりに工夫して使っている場合が多いことがわかる（日経 IT プロフェッショナル，

2004）。

さらに，北島^（2006）が言うように，もともと要求定義という活動は，「正しい要求がすでに存在している」ということを前提に行われていた。ところが今日の要求定義は，顧客や市場の変化への対応や IT によるイノベーションなどを指向しているため，新たな業務のやり方やルールを定義したり，データ処理の方法を考えたりといった活動を前提にしている。つまり「正しい要求」は，

あらかじめ存在しているのではなく，新たに作りあげなければならないのである。安井（2006）も，「正しくないシステムを正しく作る」という愚をおかさないためにも，要求は論理的に正しく「開発」するべきものであるとして，

「要求開発」という言葉を提唱している。

前述した日経 IT プロフェッショナルの調査によると，要求定義に関して困っていることや問題を感じていることとして，「利用者の間で意見調整ができておらず，求めてくる要求が大きく異なる」「利用者自身が何をしたいのか分かっていない」「利用者の要求がめまぐるしく変わる」が上位 3 つとなっている（日経 IT プロフェッショナル，2004）。つまり，IT 開発者側から見ると，要求定義に関して本来利用者がすべきことが十分にできていないと感じている。

一方，JUAS（社団法人日本情報システム・ユーザー協会）の2004年度調査によ

(6)

れば，情報システムを発注する側としての反省点として一番多かったのが「システム仕様の定義が不十分のまま発注してしまった」，次が「委託先に要求仕様条件を明確に提示しなかった」となっている（JUAS，2005a）。つまり，利用者としても，本来要求仕様は利用者側できちんと決めるべきものであるが，それが十分にはできていないという認識である。

しかし，ここに両者の認識の違いがあると筆者は思っている。つまり，要求定義や要求仕様というような言葉を使っているが，利用者側と IT 開発者側では意味するものが異なっているのではないかということである。

例えば，企業の元 CIO である佐藤^（2006）は「我々ユーザー企業は，ビジネスにおける IT 投資の費用対効果を考え，どんなビジネスをして，IT をどう使ったらいいかを考え抜く。できあがったシステムを使いこなしてビジネスを遂行し，所定の効果を出すところに力を注ぐ。一方，IT や情報システムの開発については，IT ベンダーに責任をもって担当していただく。情報システムの開発局面に必要とされるスキルとして，要件定義，システム設計，ソフト開発，

全体のプロジェクトマネジメントなどがありますが，これらはすべて IT ベンダーが持っているべき専門スキルと考えます。」と述べている。また，建築家中村^（2006）は，依頼者との最初の打ち合わせで，希望する間取りや部屋の広さなど，家についての具体的な要望は，ほとんど尋ねないという。なぜなら依頼者が本当に求めている家は，依頼者自身には分からないと考えているからである。したがって中村は，打ち合わせの席で，生活についての雑談を重ねていく。その中から，依頼者にとってどんな家が心地よいのか，探っていくという。

情報システムにおいても同様で，利用者が本当に求めている情報システムは利用者自身にも明確には分かっていない場合が多いのではなかろうか。したがっ

2 ） 2 ）

2 ） CIO：Chief Information Officer（IT 担当役員）

(7)

て，利用者に聞くべきことは，具体的な情報システムの機能ではなく，どのような業務のやり方を目指しているのか，その中で情報システムをどう使いたいのか，ということである。

このような状況の中で，利用者としては，自分たちの望む情報システムについてきちんと開発者に伝える，開発者としては，利用者が真に望んでいることをしっかりと把握し，それを情報システムとして具現化する，ための有効な方法を模索している。

前述した JUAS の調査報告書の中でも，「利用部門が作成する RFP と IT 部門が補足して作成する部分の明確化と記述要領についてのガイドブックが必要である。」「パッケージ活用のための『業務仕様確定手法の高度化・効率化』が必要。」等を提言している（JUAS，2004a）。

Ⅱ 上流工程に関する動向

前章では，IT 経営が十分に実現できていない企業が多く，その大きな要因が情報システム開発の上流工程にあるということを述べてきた。本章では，いろいろな団体が公表している報告書や，ベンダーが用いている開発手法，工学分野における先行研究等から，ソフトウェア開発における上流工程の位置付けや，問題点，代表的な手法等を整理する。そして，中堅・中小企業でそれらを用いる場合の課題について考察する。

1 ．開発工程における上流工程の位置付け

情報システムの開発工程については，各機関やベンダーによって統一されていない。図表 3 に共通フレーム2007による開発工程分類，図表 4 に IPA（独立

3 ） 3 ）

3 ） RFP：Request For Proposal（提案依頼書）

(8)

図表 3 共通フレーム2007による開発工程分類

システム化の方向性・

システム化計画運用・評価

要件定義

事業業

務情報システム運用テスト

システム設計システムレベル

の設計

システムレベルのテストシステムテスト

システム方式設計システム結合

ソフトテストソフトウェアプログラミング

ソフトウェア設計

図表 4 IPA による開発工程分類

「超上流」の開発プロセス共有化

2005年度「エンタプライズ系プロジェクト」の俯瞰図

工程個別

全体支援

システムの方向性投資効果は上がっているか要求を満たしているか

仕様どおりか

要求工学

設計・開発技術経営評価

システム化計画業務評価

要求定義総合テスト

基本設計結合テスト

詳細設計ソフトウェアテストプログラミング

見積り

開発プロセス共有化，プロセス改善プロジェクト見える化

定量データ分析，見積モデル・手法

(9)

行政法人情報処理推進機構）による開発工程分類，図表 5 にベンダー各社の開発工程（テスト工程以降は省略）分類を示すが，各々微妙に異なっている。ベンダー各社の開発工程は，筆者が携わったプロジェクトにおいてベンダーが立てた作業計画から引用した。同じ会社でも，実施したプロジェクトによって異なっていることもある。

ただ，ベンダーが行う作業については，表現は異なっても，内容的には以下のような工程分けになっていることが多い。

（ 1 ）要件定義（または要求分析）

ヒアリングにより，利用者の要望を抽出する。現行システムがある場合は，

現行システムの問題点や改善要望も聞き出す。パッケージをベースにする場合 図表 5 各機関や IT ベンダー各社の開発工程定義

（注 1 ）SLCP-JCF98委員会（1998），（注 2 ）IPA（2007），（注 3 ）経済産業省（2007），（注 4 ）IPA（2005），

（注 5 ）経済産業省（2005）

各機関発行の資料や各ベンダーの提案書，作業計画書等を基に筆者作成

ベンダー名企画工程開発工程

共通フレーム 98（注1）

システム計画

システム

要求分析システム方式設計ソフトウェア要求分析

ソフトウェア方式設計

ソフトウェア詳細設計

ソフトウェアコード作成共通フレーム

2007（注2）

システム

化計画要件定義システム要件定義

システム方式設計

ソフトウェア方式設計

ソフトウェア詳細設計

ソフトウェアコード作成モデル契約

（注3）

システム

化計画要件定義システム設計

システム

方式設計ソフトウェア設計プログラミング

IPA（注4）システム

化計画要件定義基本設計詳細設計プログラミング

システム管理

基準（注5）要件定義システム設計プログラム設計プログラミング

Ａ社

要求分析概要設計詳細設計プログラム製造

仕様化

セッション概要設計詳細設計製造

Ｂ社

ユーザーインター

フェイス設計システム構造設計プログラム構造設計プログラミング要件定義アドオン・

カスタマイズ設計プログラム設計プログラミング

Ｃ社要件定義基本設計詳細設計実装

Ｄ社要件定義論理設計物理設計プログラム開発

Ｅ社要件定義外部設計内部設計プログラム開発

Ｆ社基本検討基本設計詳細設計プログラム開発

(10)

は，パッケージの機能説明をしながら，パッケージの機能がそのまま使えるもの，業務に合わせてパッケージを変更する必要があるもの，パッケージ機能に合わせて業務を変更するものに切り分けを行う。

詳細な RFP が発注者（利用者）から提示されている場合は，RFP の確認が中心となる。

成果物としては，新業務フロー図，システムに要求される主な機能の一覧とその概要，システムイメージ図等になる。

（ 2 ）基本設計（または概要設計，外部設計）

画面，帳票の設計を行う。要件定義の結果から，必要な画面，帳票を洗い出し，一つ一つのレイアウト設計を行う。また，データベース，マスター，コードの設計も行う。パッケージをベースにする場合は，アドオンやカスタマイズの設計を行う。

成果物としては，画面・帳票一覧，画面設計，帳票設計，データベース設計，

マスター設計，コード設計等になる。

基本設計が終了すれば，利用者の要望はほぼ確定できるので，この時点で開発以降の総費用の再見積もりを行うことが多い。

（ 3 ）詳細設計（または内部設計，プログラム設計）

プログラミングのための設計を行う。利用者との打ち合わせは基本設計まででほぼ終了し，以降はベンダー内部の作業が中心となる。

このように，ベンダーとしては，発注時点で利用者（発注者）の要求内容は明らかになっているという前提で，要求を聞き出しシステム要件にまとめる作業から始めるのが普通である。

4 ）

4 ） 5 ）5 ）

4 ）パッケージに機能を追加すること 5 ）パッケージ本体を変更すること

(11)

2 ．上流工程はなぜ難しいのか

IPA（2006）は，上流工程に関する問題発生の大きな原因として，次のように分析している。

「かつて情報システムは，企業内で自らの業務を合理化，効率化したい担当者が，自分が使うないし自分の部門が使うニーズを満たすために企画され，発注された。そのとき，要求はその範囲で明確であり，的確でぶれのないものであった。しかし，今日では状況は全く違ってきている。企業の中で業務企画をし，システム構築を依頼する担当者は多くの場合，自らがそのシステムを利用することはない。業務企画担当者は，いまやシステムの発注者でありながら開発を担う担当者とともに，利用者にシステムを供給する立場にいる。利用者の要求は多様化し，システム開発における要求定義，要件定義を複雑・不安定にする一方といえる。」

「従来のシステム開発は，業務マニュアルなどによって業務手順が詳細に定義され，システム化する範囲も明確に決まっているケースが多く，情報システム部門やベンダーが，業務部門から要望を聞いて作ることができた。しかし，

ビジネス環境の変化が早い昨今では，新規事業の立ち上げや関係会社などとの業務連携など，ビジネスのあり方そのものから検討するケースが増えている。」

大西・郷^（2002）は，要求定義はソフトウェアライフサイクルの最初に位置することによる重要性と難しさがあると言っている。つまり，設計工程は要求定義や要件定義の結果を基に行う，プログラミングは設計書を基に行う，というように，すべての工程は，前工程で作成されたものを基に作業を進めることができる。そして，どこまで意図したものに仕上がっているかは別として，前工程を行う人は，後工程を行う人が分かりやすいように成果物を作成する。後工程を行う人は，成果物に不明な点があれば前工程を行った人に聞くこともできる。しかし，要求定義だけは，何もないところから始めなければならない。

(12)

拠り所となる前工程がないのである。後工程のことを考えて成果物を作り，疑問点があればそれに答えてくれる人は存在しない。すべて自分で解決していかなければならないのである。

さらに，大西・郷（2002）は，要求定義の本質的な問題として，以下の 2 点を上げている。

一番目は，人間とコンピュータの処理の境界があいまいであるということである。企業における業務システムは，企業内の業務活動そのものであり，物流や人の活動を含む実体システムと，情報処理を行う情報システムに分けることができる。例えば，入出庫作業を行う倉庫現場という実体システムに対して，

出庫の指示を出したり実績を収集したりすることによって，情報システムは倉庫内の製品の流れを間接的に制御する。情報システムは，さらに人間が行う情報処理とその一部を担うコンピュータシステムから成る。人間が行う情報処理とは，例えば，コンピュータが出力する在庫数量の変動データを見て，発注量を判断するとか，倉庫現場で出庫すべき製品が不足しているような場合に代替品を指示するとかいった，コンピュータで完全に機械化できない判断や例外事象に対する処置である。

このように，業務システムは人間が行う業務活動の中に埋め込まれたシステムであり，コンピュータと人間の情報処理の境界が最初から決まっていないことに難しさがある。上記の例では，発注数量を判断する機能をコンピュータで行おうとすると，発注量計算のアルゴリズムを開発する必要があり，システム開発規模がまったく異なってくる。つまり，業務システムの要求定義では，コンピュータシステムをとりまく実体システムや人間との役割分担を含めた視点から検討を始める必要がある。そして，その検討が，コンピュータシステムの仕様以前の問題としてはるかに大きな比重を占める。

二番目は，仕様決定の根拠が脆弱であるということである。例えば，交通費

(13)

精算で「タクシーを利用した場合は領収書の添付が必要であるが，3,000円未満の場合は領収書が不要である。」というルールがあったとする。なぜ3,000円なのか，明確な理由はない。そのときの事情でたまたまそうなっているとしか言いようがない。生産管理や財務システムのように工学的あるいは法的なルールで仕様が決まる部分も確かにあるが，大部分は企業の独自の論理であり，その時点の組織の意思で決まる。制御系ソフトウェアや科学技術計算のように物理や数学をよりどころとするソフトウェアと根本的に異なる部分である。

これら 2 つの問題から言えることは，業務システムにおける要求定義は，コンピュータシステムに対する仕様以前の部分にむしろ注目しなければならないということである。その企業における実体システムの理解，人の情報処理とコンピュータシステムの最適な役割分担の検討，そして何よりも，企業独自の論理や意思で決まるルールをいかに明確化していくか，意思決定を効果的に促していくかが，非常に重要になる。

山岸ほか（2006）は，要求はもともとあるものではなく，上位の目的（ビジネス要求）を基に合理的かつ能動的に開発すべきものであると述べている。

実際の業務に関わる利用者にヒアリングをすると，それなりにシステムの要求らしきものが集まってくるが，それらを忠実にシステム化しても利用者の意図した目的が達せられるとは限らない。利用者から聞いた要求は，その利用者の個人的視野でのものであり，会社全体の業務を見渡した結果ではない。また，

業務からシステム要求に至ったロジックもブラックボックス的であり，常に同じ結論にたどり着く保証もない。つまり，その利用者の属人的，場当たり的，

直感的なものである。聞く人によって，また聞く時によって違った要求が出てくる可能性が高い。

利用者から得るべきは，結論的な要求ではなく，そのような要求に至った業務の背景である。複数の関係者からさまざまな方法で得た業務の姿を重ね合わ

(14)

せて初めて業務の全体像が明らかになる。

3 ．上流工程はだれが行うべきか

IPA（2006）では，上流工程の定義内容と役割について，次のように整理している。

「従来のシステム開発は，業務マニュアルなどによって業務手順が詳細に定義され，システム化する範囲も明確に決まっているケースが多く，情報システム部門やベンダーが，業務部門から要望を聞いて作ることができた。しかし，

ビジネス環境の変化が早い昨今では，新規事業の立ち上げや関係会社などとの業務連携など，ビジネスのあり方そのものから検討するケースが増えている。

このようなケースでは，システム開発の前に，まずビジネス環境を分析し，

業務範囲や業務分掌などを定めたうえで，必要な業務手順を決める必要がある。

そして，その役割は従来のように情報システム部門やベンダー主体ではなく，

業務部門や経営層主体であるべきだといえる。

図表 2 （前掲）に示すように，システム開発に必要な要件としては，事業要件，業務要件，システム要件などがあり，それぞれに対応した役割が考えられる。ビジネスのあり方そのものから見直すような場合には，事業要件からシステム要件までを明確にしなければならず，検討と意思決定に携わるべき関係者も多くなる。」

このモデルの特徴は，要件定義を事業要件定義，業務要件定義，システム要件定義の 3 つに分けたことであり，これによって，各々の要件定義の内容とそれを行うべき人を明確にしている。つまり，事業要件はビジネスモデルの検討等であり，経営層と業務部門が主体となって行う，業務要件は業務モデルの検討等であり，業務部門が主体となって行う，そしてシステム要件はシステムモデルの検討等であり，情報システム部門が主体となって行う。

(15)

山岸ほか（2006）は，経営層からのトップダウンにより情報システム部門主体で上流工程を行った場合，現場を置き去りにしたシステムありきのプロジェクトに陥ってしまう危険性がある，また現場主導では，全体最適にならない，

あるいは IT を活かしきれない，経営企画部門主導だとベンダーの提案を鵜呑みにしたものになってしまう，と指摘し，図表 6 のように，「要求開発推進チーム」「ビジネスモデリングチーム」「新システム開発チーム」の 3 つがバランスをとりながらプロジェクトを推進することが望ましいとしている。

要求開発推進チームは，要求開発のリズムを作り，全体を調整する機能を持つチーム，ビジネスモデリングチームは，業務サイドに立って，利用者の視点から要求を考えるチーム，新システム開発チームは IT サイドで，情報システム部やベンダーなどのシステム開発や保守に関わる立場のチームである。

IPA のモデルが事業要件，業務要件，システム要件と，いわばウォーター 図表 6 要求開発組織

山岸ほか（2006）

要求開発組織

要求開発推進チームファシリテート

（支援）する

ファシリテート

（支援）する新システム

開発チーム協働する

ビジネスモデリングチーム

ビジネスモデリングチーム（BMT）のミッション新しいシステムに対する要求を，迅速かつ適切に引き出し，開発チームに提供することに責任を持ちます。そのために必要な現状分析や将来のビジョンを捉え，ヌケモレダブりなく要望を取り上げます。

新システム開発チーム（NST）のミッション BMTが捕らえた要望を適切にシステム要求として受け取り，システムとして提供することに責任を持ちます。

開発時には複数回のイテレーションを繰り返し，要求の曖昧さ，見えない真の要求解明に，BMTと共に責任を持ちます。

要求開発推進チーム（RDT）のミッション要求開発全体を計画し，現状分析からシステム開発の完了まで，プロジェクト全体が成功裏に終わらせる責任を持ちます。

特にBMT,NSTのモチベーションとコミュニケーションを維持し，それぞれのチームとしての活動をファシリテート（支援）することに注力します。

(16)

フォール型で要件を固めていくのに対して，山岸らのモデルはプロジェクト内に役割の異なる 3 つのチームを置いて，それらが協働しながら要求定義を行っていく。いわば，スパイラル型のモデルである。IPA のモデルと比較すると，

事業要件はこのプロジェクトの前工程で決まっており，このプロジェクトでは，

ビジネスモデリングチームが業務要件を，新システム開発チームがシステム要件をそれぞれ専門に検討する役割である。

状況が許せば，山岸らのモデルの方が，より効果的ではあるが，しかし，新システム開発チームに参加する人材の問題がある。そもそも，中堅・中小企業ではそのような人材が乏しいことが問題となっている。といって，この段階でベンダーの力を借りるのは難しい。というのも，まだどのような情報システムを構築すべきかをこれから決定しようという段階なので，どのベンダーが最適か選定のしようがないからである。

4 ．上流工程での成果物

IPA（2006）は，上流工程を図表 7 のように定義し，各工程での成果物の例として以下をあげている。

①システム化の方向性およびシステム化計画での成果物 1 ）システム化方針の確認

事業戦略／事業計画，中長期システム化戦略，単年度システム開発計画，

事業システム全体図

2 ）プロジェクトの背景・目的の共有プロジェクト概要，プロジェクトの課題

3 ）システム化範囲の選択と集中

解決策へのアプローチ，システム化機能一覧 4 ）システムに求められる要素の確認

(17)

図表 7 上流工程の例

コンサル契約試算見積

承認

承認方針禀議

・発注検討

見積提案シス

テム化計画書作成部門間の検討

概要の確認

R F P

② レビュー

︵計画・見積

︶

コンサル契約仮試算見積

レビュー

︵システム化の方向性

︶

見積提案

資料作成・打合・発注検討

R F P

① 経営層

業務部門

情報システム部門ベンダサブベンダ見積レベル

契約

部門間の検討方向性の確認方針／

問題点

確認業務検討

承認

システム化の方向性システム化計画

必要に応じ実施

システム設計契約開発契約確定見積

概算見積

承認

承認システム投資効果確認設

計検討設計

︵内部

︶設計

︵外部

︶

画面帳票等の検討

レビュー

︵システム設計

︶

要件定義契約実行禀議

・発注検討

見積提案 R F P

③ レビュー

︵要件定義書

・予算

︶事

業要件

・業務要件定義

業務要件定義作成支援

システム要件定義作成支援

経営層

業務部門情報システム部門ベンダサブベンダ見積レベル契約

要件定義システム設計

必要に応じ実施

承認

(18)

業務概要図，現状業務フロー／新業務フロー（ラフ），システム全体図，

インフラ構成要素，サービスレベル想定，他システムへの影響，既存システム流用検討結果

5 ）プロジェクト実行計画の策定

プロジェクトの QCD 目標，マスタースケジュール，開発の特徴，検討内容の自己評価

6 ）投資効果による評価

開発工数見積もり，費用対効果（定量効果予測），費用対効果（定性効果予測），費用対効果（収支予測）

7 ）要件定義フェーズの計画と承認

要件定義フェーズの QCD 目標，詳細スケジュール，開発体制図・役割分担，マネジメント方法，プロジェクトリスクメモ，取り組みの工夫，

投資決裁書

②要件定義での成果物 1 ）機能要件（プロセス）

機能情報関連図，業務流れ図，業務処理定義書，システム機能階層図 2 ）機能要件（データ）

概念 E-R 図，データ項目定義書 3 ）機能要件（インターフェース）

システム間関連図，システム間インターフェース定義書，画面・帳票一覧，画面・帳票レイアウト

4 ）非機能要件

品質要件，技術要件，運用・操作要件，移行要件，付帯作業，その他の要件

図表 7 では，要件定義の中で事業要件，業務要件，システム要件を決めるこ

(19)

とになっているが，成果物を見る限りでは，システム化の方向性およびシステム化計画で事業要件と業務要件を決める必要がある。したがって，筆者としては，図表 7 の工程図で，要件定義工程の初めにある「事業要件・業務要件定義」をシステム化計画工程に持って行くべきではないかと考える。

また，JUAS（2004b，2005b）では，上流工程の成果物をベンダーへの見積仕様に使うという前提で，以下の項目をあげている。

①構築対象の業務システム企画上の前提条件の確定

ビジネス機能関連図，ビジネス連携図，ビジネスルール定義書，システム化目標定義書

②対象範囲のビジネスプロセスの定義

ビジネス機能構成表，ビジネスプロセス関連図 ③業務処理フローの定義

業務流れ図 ④業務ルールの定義

機能情報関連図，業務ルール定義書，個別業務処理定義書 ⑤ビジネスデータの表現

画面／帳票一覧，画面／帳票レイアウト，データ項目定義書 ⑥運用作業要件の定義

運用・操作要件書

IPA のモデルと表現の違いはあるが，必要とする成果物はほとんど同じである。JUAS の①②が IPA のシステム化の方向性およびシステム化計画工程での成果物に，JUAS の③④⑤⑥が IPA の要件定義工程での成果物にほぼ対応している。

いずれのモデルも，画面・帳票一覧やレイアウト，データ項目定義等，通常ベンダーが基本設計工程で作成する成果物を含んでいるのが，筆者にはやや違

(20)

和感がある。これについては，次章で述べる。

Ⅲ 中堅・中小企業における上流工程の課題

前章では上流工程に関する動向を整理したが，これを中堅・中小企業の視点で考えてみる。

中堅・中小企業が全社的な情報システムを開発する場合の特徴は以下のとおりである。

①企業規模が小さいため，社内に IT 技術者が不足している。

②そのため，システム開発はベンダーの力を借りざるを得ない。

③ QCD（品質，コスト，期間）面でのリスク許容量が小さいため，手作りではなく，実績のあるパッケージを活用することが多い。

④ 全社的な情報システム開発は，そう頻繁にあるものではなく， 5 年に一度くらいの全社を挙げての一大イベントになる。

このような中堅・中小企業の特徴を踏まえると，前章で述べた上流工程の成果物，要員，手法や技法を適用するには以下のような課題がある。

（ 1 ）成果物

IPA 案も JUAS 案も，これを作成するにはかなりのスキルとパワーが必要である。人材の乏しい中堅・中小企業ではかなり難しい。また，パッケージを利用することが前提となれば，あまり詳細に画面や帳票の設計をしても，後工程でパッケージとの Fit&Gap 分析をするので，二重作業になる恐れが多分にある。

したがって，ベンダーの力をうまく活用することで，自社内の IT 技術者の

6 ） 6 ）

6 ）パッケージの標準機能と業務形態を付き合わせながら，パッケージの標準機能が使えるもの，

パッケージに追加・変更を加える必要があるもの，パッケージに業務を合わせるものを洗い出していく作業

(21)

不足を補う工夫が必要である。

（ 2 ）上流工程を行う要員

中堅・中小企業にとって一大イベントになるため，経営者のトップダウンによるプロジェクト組成は比較的容易である。ただ，業務のキーマンは日常業務でも多忙なため，専任でのプロジェクト参加は難しく，業務との兼任になることが普通である。

情報システム部門の陣容は大きくはなく，数名〜十数名程度の企業が多い。

システム専門の要員はとくにいなく，兼任でシステムの面倒も見ているという企業もある。また，要員は日常業務に追われており，IT 技術を磨く時間がとれていないことが多い。したがって，情報システム部門が全社的なプロジェクトを引っ張っていくというのは難しい。

このため，ベンダーの力を借りる必要はあるが，うまく役割分担をしておかないと，山岸ほか（2006）も言っているように，個々の現場の声をそのまま反映したようなシステムや，ベンダーの都合を優先したシステムになってしまう危険性もある。

（ 3 ）手法や技法

前述のように，日常的に情報システム開発の上流工程が発生しているわけではなく， 5 年に一度くらいの頻度なので，上流工程の技法や手法を常時使うという環境にはない。要員の絶対数も少ない。したがって，情報システム部門が業務担当者にヒアリングしながら UML や BPMN といった技法を使って記述するというのは，あまり現実的ではない。また，情報システム部門が成果物をすべて作っては，業務担当者はどうしても受け身になりがちで，自分達が作りあげたシステムであるという自覚が乏しくなってしまう。業務担当者の参画意

7 ）

7 ） 8 ）8 ）

7 ） UML：Unified Modeling Language 8 ） BPMN：Business Process Modeling Notation

(22)

識を高めるためにも，業務担当者が自ら自分達の業務フローを作り，問題点を分析し，改善案を考えることが望ましい。

そのためには，IT の素人である業務担当者が使えるような手法である必要がある。

おわりに

本稿では，主に中堅・中小企業の視点から，IT 経営推進の難しさを考察してきた。IT 経営は経営，業務，IT の 3 つがうまく融合して初めて実現されるが，現場の業務プロセス改革と IT のメカニズム構築という 2 つの役割を同時に担う情報システム開発の上流工程が大きなネックになっている。メインフレームの時代は，自社の情報システム部門が現場の業務と情報技術に精通しており，また情報システム自体が経営戦略への貢献というよりは現場の業務効率化を目的としていたため，情報システム開発の上流工程はそれほど難しいものではなかった。今は，情報技術が日進月歩で進歩し，また現場の業務も多様化しているため，情報システム部門もキャッチアップができなくなっている。そこで，どうしても外部の専門家であるベンダーの力を借りる必要が生じている。

メインフレームの時代ももちろんベンダーが情報システム開発プロジェクトに参加することはあったが，それは主としてプログラミングという下流工程であった。上流工程は自社内で完結することが多かった。しかし，今は上流工程からベンダーが参加しているため，余計な困難が生じている。発注者と受注者という利害関係の相反するメンバーが共同で作業をしないといけないため，その線引きが困難なのである。筆者も中堅・中小企業の実情にあった線引きを提案

（大島，2007）し，試行してきたがまだまだ十分とは言えない。中堅・中小企

9 ） 9 ）

9 ） IT を直訳すれば情報技術であるが，IT はもう少し広い意味で使われることが多いので，ここではコンピュータに関する技術という意味を強調するために，あえて情報技術という言葉を使う。

(23)

業が IT をうまく使って生産性を上げることが日本経済にとっても重要であり，

今後もあるべき論だけでなく，中堅・中小企業の実情に合った現実的な方法論が多方面で検討されることを期待する。

参考文献

IPA（独立行政法人情報処理推進機構）；エンタプライズ系ソフトウェア開発力強化，

https://sec.ipa.go.jp/std/ep.php（2005），（2011年 9 月30日）

IPA（独立行政法人情報処理推進機構）ソフトウェア・エンジニアリング・センター；経営者が参画する要求品質の確保第 2 版，オーム社，（2006）

IPA（独立行政法人情報処理推進機構）ソフトウェア・エンジニアリング・センター；共通フレーム2007，オーム社（2007）

JUAS（社団法人日本情報システム・ユーザー協会）；ユーザ企業 IT 動向調査調査概要報告書平成15年12月，p.36（2004a）

JUAS（社団法人日本情報システム・ユーザー協会）；平成15年度ビジネスシステム定義研究プロジェクト「エンドユーザーによるビジネスシステム定義の進め方」，（2004b）

JUAS（社団法人日本情報システム・ユーザー協会）；企業 IT 動向調査2005 記者発表会，pp.41〜42（2005a）

JUAS（社団法人日本情報システム・ユーザー協会）；平成16年度ビジネスシステム定義研究プロジェクト「エンドユーザーによるビジネスシステム記述方法とリファレンスモデル」，（2005b）

JUAS（社団法人日本情報システム・ユーザー協会）；「要求仕様定義ガイドライン」，

（2007）

SLCP-JCF98委員会；共通フレーム98（1998年版），（1998）

大島博行；中堅企業の基幹業務システム構築における要求定義，システム監査学会誌

「システム監査」Vol.20 No.2，（2007）

大西淳・郷健太郎；要求工学，共立出版，（2002）

北島義弘；要求定義における品質確保の方法，http://www.atmarkit.co.jp/im/

cpm/serial/quality/02/01.html（2006），（2011年 9 月30日）

経済産業省；「情報技術と経営戦略会議」報告書，（2003）

経済産業省商務情報政策局監修；新版システム監査基準／システム管理基準解説書

（平成16年基準改訂版），財団法人日本情報処理開発協会（2005）

(24)

経済産業省；情報システム・モデル取引・契約書（平成19年 4 月），（2007）

経済産業省；IT 経営ロードマップ，（2010a）

経済産業省；『IT 経営力指標』を用いた企業の IT 利活用に関する現状調査報告書，

（2010b）

佐藤正史；経営者が IT を理解できない本当の理由，http://itpro.nikkeibp.co.jp/article /COLUMN/20070420/269074/?ST=management&P=1（2006），（2011年 9 月30 日）

中村好文；NHK プロフェッショナル仕事の流儀（2006年 4 月13日放送），http://

www.nhk.or.jp/professional/2006/0413/index.html（2006），（2011年 9 月30日）

日経 IT プロフェッショナル；「今こそ身に付ける要求定義の定石」，2004.1号，

pp.20〜54（2004）

日経コンピュータ；2003年情報化実態調査，2003.11.17号，pp.50〜71（2003）

日経コンピュータ；「システム開発，最後の難問見えてきた要求定義の最適解」，

2004.6.14号，pp.52〜71（2004）

日本情報処理開発協会編集；情報化白書2006，㈱ BCN（2006）

安井昌男；戦略的要求開発のススメ，翔泳社，（2006）

山岸耕二ほか；要求開発，日経 BP 社，（2006）

山本修一郎；要求定義・要求仕様書の作り方，ソフト・リサーチ・センター，p.21，

25（2006）

中堅・中小企業における IT 経営推進上の課題

中堅・中小企業における IT 経営推進上の課題

大 島 博 行

大島博行