システム開発の関係者

② 4工程の流れを読み解く

「何を」→「どう」→「作る」→「確かめる」——この4拍子が、システム開発の基本形です。

③ プロジェクト組織

システムの開発は、ユーザ（システムの利用者）、ベンダ（システムの提供者）などが参画するプロジェクト組織で行われることが一般的です。

プロジェクト組織は、システム開発の発注元であるユーザ企業のシステム部門、発注先となるシステム会社（ベンダ）で構成されます。

加えて、業務システムの場合にはその利用者となり、エンドユーザに向けたシステムの場合には利用者となるエンドユーザに情報発信を行うユーザ企業の各事業部門から数名が選抜され、プロジェクト組織に参画することが多くなっています。

④ 関係者を図で整理する

⑤ 各事業部門が参画する理由

業務を実際に行っているのは事業部門です。システム部門だけで要件を決めると、

使う人が設計に参加する——これがプロジェクト組織に事業部門が入る理由です。

⑥ 中小企業での現実

大企業と違い、中小企業にはシステム部門がないことが多いという事情があります。

この差が、中小企業のシステム導入を難しくしています。

⑦ 診断士の役割

システム部門の役割を、外部の専門家が補う——ここに診断士が関わる余地があります。

技術そのものより、進め方と判断の助言——これが診断士に求められる関わり方です。

⑧ この章の位置づけ

技術を知っているだけでは、システムは作れません。誰と、どういう順番で、どう進めるか——それがこの章のテーマです。

関心事が食い違う

この食い違いを放置すると

プロジェクト組織を作る意味

関係者を最初から巻き込んでおけば、途中での食い違いが減ります。

3つ目がとくに大きい

次節で学ぶウォータフォールモデルのデメリットに、「上流工程で欠陥があってもプロジェクトの終盤まで発見できず、大きな手戻りが発生する可能性がある」とあります。

現場の人が最初から参加していれば、上流工程で気づけます。

診断士としての助言

「システムを作る」のではなく「業務を変える」——この認識を関係者で共有できるかが、成否を分けます。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　システム開発の手順は、大まかに分析・設計・プログラミング・テストに分けられる。

> b　分析工程では、ユーザの要求を明確にして開発するシステムを定義する。

> c　プロジェクト組織は、ユーザ企業のシステム部門のみで構成される。

解答　a：○　b：○　c：×

• c：×……プロジェクト組織は、ユーザ企業のシステム部門と、発注先となるシステム会社（ベンダ）で構成され、加えてユーザ企業の各事業部門から数名が選抜されて参画することが多くなっています。

多重下請けの構造になることがあり、ベンダの下にさらに複数の階層が連なる場合もあります。

③ オフショア開発

近年では、海外（中国やインド、フィリピンなど）のサブベンダに開発業務を委託するオフショア開発が進んでいます。

④ ニアショア開発

比較的距離の近い遠隔地（国内の北海道や九州、沖縄など）のサブベンダに開発業務を委託するニアショア開発も進んでいます。

⑤ 2つの違い

off（離れた）とnear（近い）——英語の意味がそのまま距離を表しています。

⑥ それぞれの長所と課題

オフショア開発

ニアショア開発

⑦ なぜニアショアが生まれたのか

オフショア開発が広がった結果、言語や文化の違いによる問題が表面化しました。

「安さ」だけを見て委託すると、かえって高くつく——この反省から、言語と時差の問題がないニアショアが選ばれるようになりました。

⑧ 費用と意思疎通のトレードオフ

安くなるほど、意思疎通が難しくなる——この関係を理解したうえで選ぶ必要があります。

⑨ 中小企業にとっての意味

中小企業が直接オフショア開発を行うことは多くありませんが、発注したベンダがオフショアを使っていることはあります。

最後の点が重要

自社の顧客情報や設計情報が、知らないうちに海外の会社に渡る——という事態は、情報セキュリティの観点から看過できません。

第6章で学んだ情報セキュリティの管理は、委託先まで含めて考える必要があります。契約書で再委託の可否と条件を定めておくことが、実務上の備えになります。

② システム構想フェーズ

システム利用側であるユーザ企業においてシステム化のニーズが顕在化すると、システム化計画の検討が始まります。この段階を、システム構想フェーズとよびます。

システム化の構想はユーザ企業内で行われることが一般的であり、システム部門が各事業部門などと調整し、システム化計画書を作成します。

③ システム化計画書の内容

システム化計画書には、主に以下の内容が記載されます。

④ 5つの項目が答える問い

「なぜ・何を・いくら・いつまで・誰が」——企画書の基本要素がそろっています。

⑤ 「ユーザ企業内で行われる」という点

システム化の構想はユーザ企業内で行われることが一般的です。

なぜベンダに任せないのか

最後の点が重要

ベンダは自社の製品やサービスを売る立場です。悪意がなくても、自社の得意な方法に寄った提案になります。

「何が必要か」を自社で固めてから、「どう実現するか」をベンダに問う——この順番が大切です。

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

外部委託先となるベンダを選定する際、発注先候補のベンダに具体的な提案を依頼する文書を作成することがあります。これを、RFPとよびます。

RFPには、システムの概要や主要な機能、調達条件などが記述されます。

⑦ RFI（Request For Information：情報提供依頼書）

一方、発注元となるユーザ企業はベンダに比べて最新技術に精通しておらず、RFPに記載する内容を明確に示せないことがあります。

その場合には、発注先候補のベンダに情報提供を依頼する文書であるRFIを作成し、調達条件などを決定するために必要な情報をベンダから収集します。

RFIにて得られた情報を元にRFPを作成し、具体的な提案と発注先の選定に移ることが多くなっています。

⑧ RFIとRFPの順番

情報を集めてから、提案を求める——この順番です。

⑨ 名前から意味を引く

Iが情報、Pが提案——頭文字で判別できます。

⑩ なぜRFIが必要なのか

発注元となるユーザ企業はベンダに比べて最新技術に精通していない——この非対称性があるためです。

まずベンダから情報を得て、RFPを書けるようにする——これがRFIの役割です。

⑪ RFPを作ることの意味

「比較できること」が、RFPのもっとも大きな価値です。相見積もりを取っても、前提が違えば比べられません。

⑫ 中小企業でのRFP

「RFPを作る」というと大がかりに聞こえますが、A4数枚でも十分です。

これだけでも、提案の質と比較のしやすさが大きく変わります。

診断士が中小企業を支援する場面で、RFPの作成を手伝うことは、具体的で効果の高い関わり方です。