PMのポイントは、時間・コスト・クオリティの3つのバランスをとること。この3つを包含するのが範囲。範囲が定まり、動かなければ、プロジェクト成功率は高まる。しかしリスクにより範囲は変動しうる。リスクをコントロールするのは人間であり、人材とコミュニケーションによりリスクを抑え込む。以上を全て包含するのが統合である。

時間とコストは別物として捉える。作業の遅延＝コストオーバーが常に成立するとは限らない。修正作業が増えても、要員の追加投入や、残業・休日出勤する事でスケジュールには影響を与えずリカバリできる可能性がある。修正作業が増えて、コストオーバーになる件についても、後工程の生産性を上げることや、もし進んでいるチームがあれば仕事の配分を見直す等、コストに影響を与えずにリカバリする事も不可能ではない。

遅延が発生した場合は、遅れの原因が製造者のスキル不足によるものなのか、無理な計画が原因か、それとも追加案件によるものなのかを把握し、対策を立てる。最も怖いのは問題があるのは分かるが、原因は分からないことである。

【プロジェクト品質の家Project House of Quality】顧客がどのような期待をしており、そして、その期待の優先度をプロジェクトの仕様に変換する手法で、ちょうど、家を組み立てるように、6要素を組み合わせていく。下記要素を下記順序で分析していくことにより、顧客の要望がプロジェクトの仕様に変換できる。

・顧客のプロジェクトへの期待／要望：顧客のプロジェクトへの期待やあるいは要望を分析し、きちんと認識する。顧客のプロジェクトへの期待とは、顧客のプロジェクトの目的であり、例えば、情報システムを調達する場合であれば、調達により何をしようかということ。

・プロジェクトの技術的特長や仕様：顧客の要望を踏まえて、プロジェクトにどのような技術的特長が発生するかを分析・理解する。どのような技術を使うのか、をきちんと認識する。

・顧客の要望とプロジェクトの仕様との関係：双方の間の関係を分析し、プロジェクトのフィージビリティを分析する。

・顧客にとっての重要性：顧客の要望を全て実現できればよいのだが、一般には投資金額の制限があるので全てはできない。そこで、顧客にとっての要望の重要性を分析する。

・他のプロジェクトとの比較：ベンチマーキングである。

・仕様の優先度：顧客の要望の優先順位をプロジェクト仕様の優先順位に落とし込む。

【プロジェクトマネージャー行動規範】

・目的の達成に責任を感じ、最後までやり遂げる

・戦略的な計画を作る

Ø スコープを定義する。スコープ定義が不明であれば不明なりに、請負側としては、スコープ前提を置いて見積りを提示し、リスクを低減させる。スコープが拡大してもスケジュールを守れるだけのリソースを確保したのであれば、スケジュール面でも費用面でもリスクはなくなる。

Ø WBSやOBS、資源マトリクスを作成する。

² 成果物を実際にブレークダウンする。戦略的計画であるので、従来のブレークダウンの方法にとらわれず、自分の見方で構造を決める。そのプロジェクトに求められる戦略性に応じて、ワークパッケージの大きさを決定し、あるいは、分解の深さを決めることができなくてはならない。

² 対象をシステムとして捉え、その構成ルールを発見し、成果物をMECEに展開する。

・専門技術を抽象的に考えることができる

・対象プロジェクトの特性から、システム基盤・内部設計・プログラミングに関して、リスクが高いか低いかを判断する。

・品質に対する高い意識を持ち、目標達成のための継続的な改善を行う

・常に顧客の真のニーズと利益を考え、実現するための行動をする

Ø 顧客やメンバーとのコミュニケーションを上手に行い、うまく情報を聞き出す。

Ø 成果物のビューを顧客のビューで捉え、その上で顧客が満足を得られるような分解をしていかなくてはならない。

・チームをまとめ、目標と情報の共有をするように行動する。PMの仕事の9割はコミュニケーションに当てられる。

・常に自分をコントロールされた状態に保つことができる

・マネジメント行動プロセスの詳細を正確に把握し、そのプロセスに従って実際に作業する

【サブPM】サブPMは単独でプロマネができるが、詳細設計や開発の実務は出来ない。プロジェクトの規模が大きく、更に上位のPMが必要な場合にサブPMを配置する。

【チームリーダ】PMが全てのメンバーをフラットに見るには手に余り、ワンクッション設けたい場合にチームリーダを配置する。システム開発プロジェクトは、通常、複数のチームから編成され、チームリーダの働きがプロジェクトの成否を左右する。チームリーダはSEとして詳細設計や開発もできるが単独でプロマネは出来ない。

しかし、技術、管理、人間的資質の全ての面で優れたチームリーダを確保することは一般には困難で、技術は強いが管理の経験が浅いメンバーをチームリーダに任命せざるを得ないことが少なくない。そうした場合には、PMは、日々のプロジェクト運営の中で、そのチームリーダを計画的、意図的に指導することが重要である。

そのためには、チームの役割やチームリーダの実績を見極め、重点的に伸ばすべき能力やその方法をチームリーダと共通に認識することが大切である。実際の業務を遂行していく中では、状況の把握方法、問題解決方法、報告の仕方等の具体的指導が必要である。

リーダの経験が浅い、コミュニケーションが充分でないチームにおいては、メンバーから上げられる報告の正確性や、数値の持つ意味・背景について詳細を確認し、雰囲気を読み取る必要があった。

【人材】プロジェクトの特性(対象業務・業界・技術)等から、スキルにマッチした要員が手配出来るか否かを判断し、リスクとして織り込む。

・業務担当者が参加している。

・要員に十分なスキルが備わっている。

・要員のスケジュールが確保されている(他プロジェクトの兼任)。

プロジェクトの遂行時に上記が確保されていないと、例えば要件定義が確定しなかったり、設計品質が低下したり、進捗が遅れたりする等のプロジェクト全体に波及する問題になることがある。

上記が満たされないままプロジェクトを立上げた場合、立上げ時に抱えていた問題から波及するおそれがあるプロジェクト全体の問題を事前に想定し、その兆候を早期に発見することが重要である。そのためには、立上げ時に抱えていた問題に応じ、以下の項目の傾向を分析する。

・要件に対する質問への回答の遅れ日数

・要件定義の変更回数

・設計レビューの指摘件数

・兼任している要員の作業負荷

【stakeholder】プロジェクトの成功、失敗を左右する人達を指す。プロジェクトスタッフの家族はステークホルダーである。PMBOK2.3では非常に広い範囲をstakeholderとして考えている。

【skill & competency】スキルは特定のタスク(ジョブ)に対する有能性概念である。従って、スキルがあるとは、特定のタスクができることを意味する。例えばDB設計のスキルというと、実際にDB設計というタスクができることを意味する。

これに対して、コンピテンシーはもっと抽象化された概念であるし、タスクベースでもない。つまり、コンピテンシーがあるというのは、何からの理由により、それができると推測されることを意味している。極論すると、スキルがあるという場合はあるタスクが確実にできるが、コンピテンシーがあるといってもできるかどうかわからない。

【要求される知識】

・情報収集の手法、手順、実践に関する知識

・関連法令(不正競争防止法、著作権法、特許法)

・企業の情報資産に関する知識

・情報システム及びネットワークの構成、技術、運用に関する知識

・システムおよびネットワークのアーキテクチャ、HW、SWに関する知識

・情報資産の評価および計量化の手法に関する知識

・情報資産が関係した事件や事故の事例に関する知識

・リスク評価に関する知識

・文書化に関する知識

【調査】

・調査に関する目標とスコープを設定する。

・調査情報が正確、かつ完全なものである。

・情報源・要求の把握は適切な方法論を用いて行う。

・継続的に情報収集を行う。

・インタビューの留意点として、インタビュー対象者の回答が、事実であるか推測であるかを区別する。

【Communication】プロジェクトの立上げから終結まで、全てのプロセスはコミュニケーションから始まる。厳しい案件では、チーム間のコミュニケーションの良し悪しが品質と納期に直結する。速く安く要求に沿ったシステムを構築できるか否かは、ユーザーとベンダを合わせた関係者のコミュニケーションにかかっている。誰が何時どのように情報を必要とし、その情報を誰が何時どのように提供するか、が問題である。

コミュニケーションの基本原則

・リレーションプロセスの原則…コミュニケーションは人間の関係性を構築することを基本としなければならない。コミュニケーションの基本は、人間関係を作ることである。人間関係は下記の4段階から作られる。

1. コミュニケーション計画

2. リレーション形成

3. 合意形成

4. 関係の維持管理

・周知の原則

・タイムリー性と適切性確保の原則…タイムリーかつ適切なプロジェクト情報の生成、収集、配信、蓄積、廃棄を行う。

・ニーズ明確化の原則…ステークホルダーのコミュニケーションニーズを明確化する

・事実遵守の原則

・正確性の原則…情報の提供者が正確な情報を発信するだけでなく、受信者が情報の内容を理解したことをフィードバックする。

・最適コミュニケーション技術活用の原則…時と場合に合わせて、最新の最適なコミュニケーション・ツールを使う。

【進捗管理】確定された計画は正しく運営されることで意味を持つ。一度遅延が発生すると以降計画通りとしても遅れを取り戻すことはできない。従って遅延の発生をリスクと捉え予防策を多く持っておくことが重要である。事前対策を行うことにより、要件追加が発生した場合も遅れの兆候をとらえることができればプロジェクト全体に波及する問題にはならない。

表計算ソフトを利用し、報告者がデータを入力することにより、進捗状況を可視化できるシートを作成する。それにより、本人に状況を認識させることが可能となり、管理者もそれのみを見れば状況が分かるようになる。

報告時には自分の作業計画／実施状況に対する自分のコメントも含めさせる。この施策により、メンバー自身の開発に対する考えが明らかになり、メンバーの業務に対する日々のモチベーションの高低も把握できる。

実績管理方式での留意点は、追加仕様が発生した時の工程により、プロジェクトに与える影響度は全く異なることである。

a. 基本設計で５人日の遅れ

b. 結合テストで５人日の遅れ

実績管理方式では同じ数値にしか見えませんが、前者の方がプロジェクトに与える影響が大きい。5人日の遅れの中で発生したと思われる追加仕様は、開発・単体テストを経て、システムテストを終えるまでの過程で膨らんでいくからである。

【Performance Management】計画を作ることと、実行することは別であり、パフォーマンスマネジメントは計画の実行上、最も重要なマネジメントである。プロジェクト計画を、パフォーマンス目標に落とし込んでいく必要がある。

チームのパフォーマンスを管理しようと思えば、個人のパフォーマンスの管理とチームのパフォーマンスの管理をする必要がある。

【Monitoring】現業部門の状況がその管理担当及びそれよりも上位の管理者によってタイムリーに把握され、それを予め設定した目標と比較し、差に対しての対応を機敏に行うことで環境変化に対応しようとするもの。

・整合性の原則…目標にそった活動を行う。

・成果測定性の原則…目標が数値化されていないと、モニタリング・コントロールができない。数値目標としてKGIやKPIを設定する。

・期間・範囲の適切性、費用対効果の原則…PMの主要要件である。

・実現性の原則

・再評価の原則…プロジェクト内容を定期的に再評価することは、正にモニタリングの意味そのものである。

・責任明確化の原則

・参画の原則

【追加仕様】仕様変更管理･･･前提が変わる場合には仕様変更管理を行い、プロジェクトへの影響を見極め、プロジェクト内で吸収可能か否かを判断し回答する。スコープ拡大のリスクを監視するため、以下の取り決めを顧客と行う。

・要件の追加／変更の窓口を決める。

・要件の追加／変更毎に見積もりを実施する。

・要件の追加／変更の工数を積み上げていき、しきい値を超えたら顧客と交渉する。

【アーンドバリューマネジメント】実際に完了した作業と実際にかかったコストを、計画していたコストとスケジュールに照らすこと。コスト・スケジュールのみならず、スコープ、調達、そして会計の知識へと、非常に広い広がりを感じる。

請負や受託でプロジェクトを実行しスコープを達成した結果、最も評価される点は利益。利益を生み出すにはコストを管理していなければならないし、そのためには計画段階で確度の高い予算を組んでいなければならない。

【営業マネジメント】プロジェクトマネジメントの中で、｢プロジェクトが始まっている前に結果が決まっている｣という話をよく聞く。例えば、受注の際に無理をして受注し、低価格で受注した案件は、いくら調達マネジメントをうまくやっても結果は見えている。どんな要求でも受けますといって受注してきた案件は、いくらスコープマネジメントを一生懸命にやってみても結果は見えている等、例は枚挙にいとまがない。

この問題を本質的に解決するには、営業マネジメントにプロジェクトマネジメントの考え方を導入し、開発マネジメントとの整合性を図っていくしかない。具体的な方法としてはスコープの拡張でもよいし、プログラムマネジメントのような考え方を導入し、アカウントベースでプロジェクトを管理していくのでもよい。他にも方法はあるかもしれない。いずれにしても、開発プロジェクトマネジメントとの連携が不可欠である。

営業プロジェクトマネジメントは営業プロセスを標準化し、その標準通りに営業活動をマネジメントしていくこと。

営業プロジェクトマネジメントのプロセスはベンダー側のマネジメントの進め方ではなく、顧客の購買行動に支配されることである。ベンダー側はそれを前提にイベントドリブンなプロセスを組み立てていく必要がある。営業プロジェクトマネジメントはここがきちんと認識できていないとうまくいかない。

重要なことはフェーズマネジメントを上手に行うことである。営業活動は受注までの活動ではない。受注後も営業プロセスは続く。開発段階(納品するまで)では顧客との調整、開発後はフォローがあり、ここまでできてはじめて営業活動は完結する。全てのフェーズで企画、計画、コントロール、終結といった枠組みで活動を整理する。

Risk Management

リスクは不確実な事象・状態で、発生するとプロジェクト目標にプラスあるいはマイナスの影響を及ぼすもの。リスクの兆候や警告をトリガーという。リスクが発生したか、発生しそうなことを示す。

リスクマネジメントとは、プロジェクトの目的を達成するためにどのようなリスクがあるかを明確に、できるだけ早い時期からその目標を達成に向けて、リスクへの対処をしていくことである。

常にリスクはついて回るし、納期遅れといった大きなレベルのリスク事象を完全に回避することはまずできない。なおかつ、同じリスク事象も、プロジェクトの実施期間、あるいは、次のプロジェクトでは変わることが多い。

一つのリスクを回避できると思ったら、その結果、どういうリスクが生まれるかを常に考えておく必要がある。これは、ブレークダウンしていけば洗いつくせるかというと実はそうではない。構造だけではなく、因果関係が含まれるので、ブレークダウンしてもすべては洗い出せない。システムとして捉え、システムとして対策をしなければならない。

リスク管理には許容・低減・移転・回避の4つの方法がある。

・許容は存在するリスクのうち、発生頻度や損害額から判断して、特に対策を行わず、発生時には自社が損害を受けることを認めること。リスク分析の結果、損害予想額より対策費用の方が多い場合は、許容するという判断がなされる。

・低減はリスクの発生頻度や損害額を、対策を行うことによって低くすること。どこまでリスクを低減するか費用対効果を考慮し、レベルを決める。

・移転は契約等で外部委託を行い、自社のリスクを他者に負わせること。移転においては外部契約だけでなく保険を利用することもある。自社で対応する費用と外部に移転した際の費用とでどちらが効果的かを判断し決める。

・回避は脅威発生の要因を停止、あるいは全く別の方法に変更することにより、該当するリスクの発生を取り去ること。

【step】

・リスクを特定する。

・発生確率、影響度を見積もる。

・リスクの軽減策を実施する。

・残存リスク(軽減した結果、残ったリスク)を監視する。

・顕在化したリスクに対処する。

【リスク識別】どのリスクがプロジェクトに影響するかを見定め、その特性を文書化する。プロジェクト・チーム、リスク・マネジメント・チーム、組織の他部門からの専門家、顧客、最終ユーザー、他のプロジェクトマネージャー、ステークホルダー、外部専門家等によって、繰り返しさまざまな観点から分析し、リスクとトリガーを洗い出す。

プロジェクトに良いもしくは悪い影響を及ぼすリスクを識別し、仕分ける。

・技術、品質、性能リスク：実証前や複雑な技術への依存、非現実的な性能目標、工業規格の変更

・プロジェクト・マネジメント・リスク：時間や資源の割り当て失敗、低レベルのプロジェクト計画、プロジェクトマネジメント能力の不備

・組織上のリスク：コスト、時間、スコープ目標の内部的な不整合、資金不足、組織内の他のプロジェクトとの競合

・外部リスク：法的／制度的環境の変化、労働争議、カントリー・リスク、オーナーの意思変更

【risk control】企業活動に伴うリスクを分析し損失を最小化するための方法。具体的には、リスクを回避・分離・移転・集中させたり、損失を予防・軽減させたりする。リスクを処理する方法としてはリスクファイナンスrisk financeもある。これはリスクコントロールを行っても発生してしまう損失や、どうしても取り除くことができないリスクに対する損失に備えて、資金対策をすることである。識別されたリスクが発生したときの予備費としてコンティンジェンシー予備費がある。

【不確定要素】不確定要素が多い時は、不確定要素を早急に確定させる必要がある。メンバーがどれだけ高いスキルを持っていても、不確定要素が多数残っていたのでは、リスクは高いままである。いくら進捗管理を実施したところで、ゴールが決まっていなければ、その進捗管理の意味は乏しい。

不確定要素を抱えることにより、下記のリスクが発生する。

・大幅な追加要件が発生する可能性がある。

・不確定要素が確定分に大幅修正という影響を与える可能性がある。

・確定分が無くなる可能性がある。

【見積もり】見積もりに際しては以下のリスクを勘案する。

・仕様変更の発生頻度・規模

・見積り時点での、仕様の煮詰まり具合

要求分析時に未確定な機能が存在する場合は、安全係数を盛り込んだ契約にする。一般的には安全係数に発生確率を加味して算出するが、｢いかなる理由であれ契約時の費用を超えることは許されない｣という場合は、発生確率を1.0とすることもありうる。

顧客に対しては顧客自身が予算獲得時に、バッファを持つことを強く推奨する。今日、ビジネスフローが急に変わる事は珍しくなく、詳細に検討を進めるとこれまでの検討に漏れが見つかり、変更することも珍しくないため。

ボトムアップ見積もりはトップダウン見積もりよりも信憑性が高い。

【委託】システム開発を他社に委託する場合、様々なリスクが考えられるが、そのリスクを回避するには、契約内容のチェックをしっかり行うことや過去の開発経験のチェックが必要となる。開発期間や開発コストはもちろん、開発後の運用・保守のことまで考えて契約を行う必要がある。

パッケージソフトウェアを用いた開発を行うにあたって販売元と契約を結ぶのは非常に危険が伴う。パッケージソフトウェアをシステムにそのまま適用できることは珍しいケースで、多くの場合は接続インタフェースの改良等の開発が伴う。となると、パッケージソフトウェアの開発までは販売店では対応しきれないことがよくある。特に海外ベンダーの場合は要注意である。

調達計画

製品やサービスをプロジェクト組織の外部から調達することで、どのプロジェクト・ニーズが最もよく満たされるかを判断する。調達すべきかどうか、いつ、何を、どのように、どの程度、調達すべきかを検討する。

調達するかどうかの判断や調達方法の決定について、調達分野の専門家や母体組織の調達専門分野の意見を参考に、調達マネジメント計画書を作成する。計画書ではどのように調達プロセス(引き合い計画～契約完了)をマネジメントするかについて記述する。母体組織に調達(契約)担当を持たない場合、プロジェクト・チームは、資源と調達に関する専門知識の両方を提供もしくは調達する。

外部からの調達の必要性なしと判断された場合は、以降のプロセス(引き合い計画、引き合い、発注先選定、契約管理、契約完了)は行われないが、一般的なプロジェクトでは、その一部、場合によっては全部を調達で賄う。

【make-or-buy analysis】母体組織がある製品を外部調達することも含めてコスト効率よく製造できるかを判断する。直接費と間接費を対象にする。例えば、レンタルやリースと購入(固定資産とする)の場合のコスト比較がある。

【契約形態の選択】

・定額請負契約・一括請負契約Fixed-Price / lump-sum contractsは、明確に定義された調達品に対する一括固定価格を設定する。納入者のリスク大→コスト増や未完成のリスクを上乗せした契約価格で、納入者のリスクが最大になる。契約先が作業に関しての一切の責任を持って開発を行う。日本での多くの契約が、この契約方法による。

・定額インセンティブ・フィー契約は、仕様での同意レベル以上の結果を出した場合、インセンティブやボーナスを支払う契約。納入者、購入者双方にリスクが生じる。

・実費償還契約cost reimbursable contractsは、実コスト＋納入者の利益を支払う。かかった費用を後から払う償還による契約。実コストには直接費だけでなく間接費も含まれる。プロジェクトの不確実性やリスクが高い場合の契約。購入者のリスクが大きい事が特徴。日本では実費償還契約は少ないと考えられていますが、建設コンサルの世界では実質的に実費償還契約が行われている。

・ T&M: Time and Material contractsは資源投入に緊急を要する場合等に用いられる。時間当たりで作業を実施させる。契約成立時点では契約額が確定していないため、購入者リスクが最大。契約者は毎日の監視・管理が必要となる。

【作業範囲記述書SOW: Statements Of Work】納入候補が調達品を供給する能力があるかどうか判断できるように、調達品について記述する。納入者が記述し、購入者がレビューする場合もある。調達プロセスの進行とともに改訂、改良する。

・プロジェクトの目標：WBSのコピーが添付される場合もある

・プロジェクトの作業と製品の仕様：納入者に求められる作業

・必要なサービス、付帯サービス

・プロジェクト・スケジュール

米国連邦政府の調達では、SOWと目標記述書SOO: Statements Of Objectivesを使い分けている。SOOは、ソリューションやサービスの調達に用いられている。

【引き合い計画】引き合いを行うのに必要な文書を作成する。購買者は調達文書において自分たちの要望や制限を正確に納入者に伝えることで、調達物自体と、それを受け取るまでの作業プロセスのリスクを少なくすることができる。

・入札Bid、見積･･･価格重視で選定を行う場合の呼び方。

・プロポーザル･･･技術的スキルや方法など、価格以外を重視する場合の呼び方。

・標準書式･･･組織や調達するモノやサービス向けの規格、様式(e.g.標準契約書、調達品に関する標準的な記述、入札に必要な全部／一部の標準化された入札文書)。

・調達文書･･･納入候補からプロポーザルを得るための説明および要請文書を作成する。作業範囲記述書、回答記入要領(納入者から正確で完全な回答を得やすくする。提案の柔軟性も確保する)、必要な契約条項(著作権条項、機密保持条項)が内容。

Ø 入札招請書IFB: Invitation For Bid

Ø 提案依頼書RFP: Request for Proposal

Ø 交渉招請書Invitation for Negotiation

Ø 第一次コントラクター提案依頼書Contractor Initial Response

【評価基準】

・価格：品目のコストと発送費などの付帯する経費も含む。但し価格だけを基準とした契約はリスクが高い。

・ニーズの理解度：納入者のプロポーザルで示される

・全体コスト／ライフサイクル・コスト：選定した納入者よりも低コスト(購入・運用)を実現できるか

・技術能力：納入者は必要な技術やスキル、知識を有する、もしくは獲得できるか

・マネジメントの仕組み：納入者はマネジメント・プロセスや手順を持っている、もしくは開発可能か。

・資金能力：納入者は必要な資金を持っている、もしくは調達可能か。

Process Model

【waterfall model】ウォータフォールモデルでのシステム開発では、基本計画から始まり、要求分析、外部設計、内部設計、製造、テスト、運用・保守と順に工程をこなしていく。システム開発を明確な工程に分けて、各工程での生産物を明確にして、その生産物を次の工程に受け渡していく開発モデル。滝waterfallの流れのように、上流から下流へと一気に進んでいくところから命名された。欠点は上流工程で紛れ込んだ誤りが、時として最後の段階にならないと検出されない点にあり、それを防止するために各工程でレビューを実施する。

全工程を同じ要員で行う必要は無く、必要に応じて要員追加するのが一般的。通常、プログラム設計・プログラミング・テスト工程で要員数はピークとなる。

ケースバイケースだが、基本計画や外部設計はシステム利用側の意思決定に左右されるため、過剰に人員投入しても効果は出にくい。内部設計やプログラミング設計、プログラミング、テストといった工程はシステム開発側の主導となるため、並列作業によって開発期間を短縮できる。

但し並行可能な作業は限られているので，1人で 3ヶ月かけるシステム開発が、3人で 1ヶ月で完了できるとは限らない。外部設計でしっかりと設計・確認を行い、並列作業を増やせるよう上手に内部・プログラミング設計するのがポイントとなる。

【spiral model】開発プロセスを繰り返しながら改良していく成長型モデル。各繰返しで、開発コストや品質などからリスクを評価し、リスクが最小となるプロセスをとる。ウォータフォールとプロトタイピングの両方の手法を取り入れ、開発初期の段階で独立性の高い部分で分け、その部分ごとに設計からテストまでの工程を繰り返して開発していく方法。

【prototyping model】開発初期段階での試作を通して、試作品（プロトタイプ）を作成し、ユーザーに評価してもらう(試用してもらう)ことにより、開発者との認識のズレを早期に解消するための手法。プロトタイプを修正しつつ、仕様を確定していく。

初期段階での誤りを発見し、後続段階での仕様変更による手戻りのリスクを防ぐ。但しユーザーの意見が必ずしも適切とは言えないため、拡張や変更時に問題が発生したり、ユーザーとのやりとりで逆に開発期間が延長したりする危険性がある。

【milestone】直訳すると一里塚。システム開発では意思決定をする(計画の見直しをする)ポイントを指す。一般的なシステム開発では、プロジェクトを円滑に進めるために最初に開発計画を立てる。開発工程には、設計の完了やコーディングの完了等のポイントとなる局面がいくつかあり、その局面毎に次の工程へ進むかどうかの判断が必要となる。その局面をマイルストーンと呼ぶ。

マイルストーンは意思決定をするポイントなので、各工程が終了する段階に設定される。例えばモジュールの仕様書が承認される時点をマイルストーンに設定することで計画が妥当かどうかを確認し、場合によっては修正をしていく。

【工数】システム開発は，各分担者の作業が他作業者の作業と完全に独立して行えるケースは稀なので、どうしても余分な工数がかかりがちになる。各作業の独立性を高めるにしても、事前にそれ相応の念密な設計が必要になる。

ソフトウェア開発規模と開発工数は比例関係にならないのが一般である。大きなシステムになるほど、指数関数的な関係となりがちである。その理由として以下が挙げられる。

・全ての要員へ知識を伝達させるのが難しくなる

・要員を管理する作業が複雑になる

・モジュールが増えることにより、設計するI/Fが増加する

・システムそのものの複雑性が増加する

【コンピュータ支援ソフトウェア工学CASE: Computer Aided Software Engineering】システム開発を支援するためのソフトウェア。システム開発支援ツールと開発方法論の統合、システム開発作業の効率化を目的とする。システム開発を便利にするもの。

・上流CASEツール：ソフトウェア開発(計画・設計)の初期段階を支援する

Ø DFD や E-R 図によるプロセスやデータのモデリング、リポジトリによる一貫した情報の管理

・下流CASEツール：プログラム作成・テスト・保守を支援する

Ø データベース定義の自動生成、プログラムの自動生成のシステム開発支援機能

・統合CASEツール：プロセス全てに一括して支援する

Ø プロジェクトの計画・見積もりやプロジェクトメンバのスケジュール管理等のプロジェクト管理支援機能

Ø ドキュメントの更新ルールの設定、バージョンの管理、部署単位・プロジェクト単位の管理帳票出力などのドキュメント管理支援機能。

戦略策定(情報化計画・企画)

【統合コンサルテーション】顧客状況に応じた最適なシステムの構築提案。経営課題、ビジネス戦略に対応した情報システム構想と、その構築計画を提供する。情報化資源の構想、適正な品質/コスト/日程計画を把握し、スムーズにシステム構築活動を開始することが出来るようになる。

・ヒアリング及び調査により、以下の情報を明確化する。

Ø 対象とする客先業務の目的、目標、重要成功要因

Ø 利害関係者stakeholder。

Ø 直接利用者の利益、直接利用者に対するサービス効果、達成優先度、制約

Ø システム化要求(機能、処理形態)

Ø 客先の業務フロー

Ø 現在と将来の社会経済的影響

【経営戦略】経営戦略策定フェーズでは、システム投資の目的を検討する。経営戦略という企業が実現すべき目的があって、それを実現するための手段の１つがシステム投資である。上流の肝となる部分である。

経営戦略がなければ、どんなシステムをいつ、いくらで導入するのかを判断する基準がない。他の会社もやっているから、役員がいうから、という理由だけで、システム開発を始めると、とんでもないことになる。開発の途中で、どんなシステムを作るべきなのか、誰もわからなくなってしまい、結果、開発プロジェクトは迷走する。

・顧客価値創造の原則は対象企業と顧客の関係を述べた原則。プロダクトアウトではなく、マーケットインがポイント。

・コアコンピタンスの原則は対象企業と競合他社との関係を述べた原則。環境の変化に合わせて自ら変わることができる能力が必要。

・選択と集中の原則は、対象企業のコアコンピタンスと顧客ニーズとの関係の原則。全顧客の全ニーズを満たすことはできない。

・最適資源配分の原則は、対象企業内部と仕入先や販売先等の外部のパートナーとの関係を述べた原則。

・戦略と業務プロセスの整合性の原則は、対象企業の戦略と業務プロセスの関係を表す。一貫性がなければならない。

・ベストプラクティスの原則は業務プロセスについての原則。最善のものを導入する。

・継続的改善の原則も業務プロセスについての原則。モニタリングしていく。

・知識共有と学習の原則は人材についての原則。環境の変化に対応するために、全社員が知識共有を進め、能力を高める必要がある。

・収益性の原則で、経営戦略は収益に結びつくことを示す。そのために収益計画を立案する。顧客、業務プロセス、人材に対する経営戦略が、収益を生んでいく。

【ビジネスモデル作成】

・ビジネスモデル検討の範囲･･･検討の対象となる組織の範囲を確認する。全社なのか、特定の事業部なのか、関連会社を含むグループ企業全体なのか。

・事業ドメイン･･･顧客、ニーズ、コンピタンス

・現状の業界特性分析･･･自社の業績に対して、マイナス要因になるかもしれない脅威から自社の業界特性を分析する。

Ø 顧客・市場

Ø 新規参入者

Ø 代替品

Ø 競合企業

Ø サプライヤー(供給者)

Ø チャネル

・ SWOT分析･･･自社の強みStrengthと弱みWeakness、将来の変化をもたらす外部環境の機会Opportunityと脅威Threatを分析する。ここから、自社の強みを事業機会によりもっと強くするとか、業界にとっての脅威を自社の強みで機会に変えるといった主要成功要因CSF: Critical Success Factorを抽出する。

Ø CSFに基づき、新しい事業ドメインを定め、自社の事業価値を再定義する。

Ø CSFに優先順位をつけて、事業改善テーマをいくつかに絞る。

・主要マネジメント要件の明確化･･･各事業改善テーマをビジネスエクセレンスモデルの6つの観点で整理し、マネジメント要件を明確化する。

Ø 顧客・市場

Ø 内部プロセス

Ø チャネル(販売チャネル)

Ø サプライヤー(供給者)

Ø 人的資源

Ø 支援サービス

・新ビジネスモデルの図式化･･･新ビジネスモデルによる投資が収益につながる過程をインフルエンス・ダイアグラムにより図式化する。インフルエンス・ダイアグラムは、原因から結果を矢印で結んだ図。

・収益構造モデルの明確化･･･新ビジネスモデルにより得られる収益を計数面で検証する。

【APQCの上位ビジネスモデル】APQCは米国生産性本部American Productivity and Quality Centerの略。上位ビジネスモデルには、基幹業務プロセスと支援業務プロセスがある。下記の観点でビジネスモデルを作る。

・基幹業務プロセス

Ø 市場と顧客の理解

Ø ビジョン策定と戦略の立案

Ø 製品とサービスの設計

Ø マーケティングと販売

Ø 製造組織での生産と納品、サービス組織での生産と納品

Ø 顧客への請求とアフターサービス

・支援業務プロセス

Ø 人的資源と育成のマネジメント

Ø 情報のマネジメント

Ø 財務および物理的資源のマネジメント

Ø 環境管理プログラムのマネジメント

Ø 外部関係のマネジメント

Ø 改善および革新のマネジメント

【業務プロセス改善】業務プロセスの変更要因は必ずしも内部の業革から発生するとは限らない。外部要因である事もしばしばある。

部門全体を対象とした業務プロセスの改善では、個々のプロセスの順序や改善効果のプロセス間の影響度合いを全体的な視点で検討する必要がある。部門全体としての体制作りやITを活用した情報共有の仕組み作りも欠かせない

業務プロセスを変更すると、ある部署には有利に、ある部署には不利に働く。個々のプロセス間で、互いに利害が一致しないようなケースでは、プロセス相互の調整という改善ステップを踏みながら、部門全体としての改善効果を実現させる。

これまで部門における業務プロセスの改善は、部門全体の業務プロセスを構成する個々のプロセス単位に着手することが多かった。その結果、個々のプロセスは最適化しても、部門全体として最適化することができないケースがあった。

例えば、物流管理部門において、部門全体のコスト削減を目指して業務プロセスの改善に着手する場合、仕入処理では、発注や検品作業の効率を優先して発注サイクルを長くするような検討をすることがある。この結果、需要との整合性がとれにくくなり、仕入量の過不足が発生する。一方、在庫管理では、商品が適量に発注されることを前提に、商品の保管レイアウトや棚番管理を改善する。しかし実際には、適正な在庫量とはならず、一時的に余分なスペースの確保や棚番管理の見直しが必要になる。場合によっては、過剰在庫や品切れ対応でコストも増加する。

業務プロセス改善では各部門の不満を解消し、合意形成を図る必要がある。合意形成のテクニックには色々ある。

・物流部門のコスト削減を目的に、物流単位を大きくしたいが、在庫管理側の不利益となる。双方とも正しい主張を行っているので、ではどこまでの線であったら譲れるのか、物流単位を変更する場合の手続に、在庫管理部門の承認を得るようにすれば良いのか、等の案で交渉を行う。

・物流単位を大きくする事により、検品が問題になるのであれば、検品作業そのものを無くす事はできないか、ITサポートにより、検品作業を効率化する事は出来ないか、という違った視点で交渉を行う。

・物流コストが、在庫ロス・チャンスロスよりも圧倒的に問題であることを証明する。

【情報システムの全体計画】全社的な視点からみた情報システムのあるべき姿、方向性をまとめたもの。経営戦略・課題から情報化課題を抽出し、現行の情報システム関連資源を調査分析した上で、中長期にわたる計画が立案される。全体計画の立案はトップダウンであるため、経営幹部層の参画が必要。

CIO: Chief Information Officerは、経営戦略に基づいて情報システム戦略を立案し、構築する責任者で、最高情報統括役員・情報システム担当役員と訳される。CxO(CEO, COO, CIO等の総称)と呼ばれる経営幹部の一員であり、企業活動における情報技術がより重要な位置を占める中で、CIOの役割も拡大しつつある。

CIOの役割としては以下がある。

・経営戦略に基づいて情報システム戦略を立案し、構築する

・情報技術を基に事業戦略を立案する

・情報システムおよび人的資産を統括し、最適化する

従って情報システムの全体計画立案にあたってはCIO はそのプロセスに強く関与しなければならない。

【戦略情報化企画】経営戦略をIT化により実現するためには、人と情報システムの両方の改革が必要。情報システムだけでは経営戦略の実現はない。

・戦略情報化企画を行うタイミングは下記の通り。

Ø 経営戦略が根本的に変わった時

Ø 現行計画に含まれるプロジェクトの大部分が完了した時

Ø 現行計画の経営上及びIT上の前提条件が大幅に変わり、計画を存続させることができなくなった時

・整合性の原則：戦略情報化企画は、経営方針と整合性を保つ必要がある。

・範囲の適切性の原則：企画の範囲は広すぎても、狭すぎてもいけない。最も効果が上がるように範囲を設定する。

・期間の適切性の原則：開発期間が長すぎると、経営環境も情報技術も変わってしまう。できたときにはすでに役に立たないシステムでは意味をなさない。

・費用対効果の原則：昔のOA化時代では人件費いくら削減を投資効果としたが、それだけでなく戦略的効果は全て挙げる。

・実現性の原則：本当にできるのか。

・成果測定の測定：進捗状況を評価する基準とモニタリングするプロセスが必要。

・再評価の原則、周知の原則、説明責任の原則、参画の原則

【戦略情報化企画のステップ】

・方針確定

Ø 範囲の設定：戦略情報化企画の範囲と期間を確定する。

Ø 方法論／技法の確定と資源の準備：方法論と技法、予定表を確定する。これで情報化の大枠が決まる。

Ø 企画プロジェクトチームを結成。

Ø プロジェクトチームの指揮／命令系統を正式に決定。

・評価：現状の情報システムの利用状況や利用可能なITの動向、この組織の将来のニーズを調査して、経営戦略で定めた経営方針を達成するためのベースライン(基準)を設定する。

Ø 経営方針および関連要因の確認：経営戦略で決めた経営方針とそれが及ぼす影響を確認。

Ø IT動向の検討：IT動向について、ITベンダー等から情報収集する。

Ø 将来ニーズの概観：経営方針とIT動向に基づいて、対象組織の将来ニーズを明確化する。

Ø 現在と将来のサービスレベル要件を確定する。サービスレベル要件とは、稼働率や応答時間といった情報システムの性能に対する要求水準のこと。これを戦略情報化企画フェーズの段階で確定する。

Ø 現行情報システム利用実態の文書化：現状を誰が見てもわかるように文書にする。

Ø 評価資料の作成：ここまでのステップを踏まえて、評価資料を作成する。

・戦略計画：戦略情報化のための戦略を策定する。経営戦略をシステム化するための戦略(考え方)と大まかなスケジュールを決める。

Ø インプット：経営戦略企画書、BSC、KPI、ITの現状。

Ø リファレンス：下位ビジネスモデル、ジェネリック情報モデル(上位)、成熟度モデル。

Ø ビジョンの確立：最初に望ましい将来像を決める。

Ø 代替案の分析：ビジョンを実現するための代替案、そのリスク、費用対効果を比較分析する。

Ø 戦略計画の策定：代替案の中から戦略的に最も有効な代替案を選定。その概要スケジュールを立案。

Ø アウトプット：経営改革企画書、当該企業のビジネスプロセスモデル、当該企業の情報モデル(上位)、当該企業のITの評価

Ø 経営改革企画書：組織や仕事のやり方といった人の面の改革について述べたもの。

・戦術計画：戦略情報化企画書を作成する。

Ø リファレンス：ジェネリック情報モデル(詳細)

Ø プロジェクトの特定と具体化：戦略を具体的なプロジェクトに細分化する。

Ø プロジェクトの優先順位設定：各プロジェクトの優先順位を決める。

Ø 戦術計画の策定：各プロジェクトの実施スケジュールを作る。

Ø モニタリング／コントロールプロセスの提案：スケジュール実施のモニタリング・コントロールを行うための仕組みを確立する。役員レベルの委員会(ステアリング・コミッティー)へのプロジェクトの定期的な報告、承認、変更などの手続きをルール化する。

Ø 戦略情報化企画書：情報システム面の改革について述べたもの。経営改革企画書とセットで改革は実現する。

【現行システム評価】競争力を保つためには、ビジネスの変化に合わせてシステムを柔軟に適合させることが要求される。現状のシステムとプロセスはどのような状況にあるのか、情報システム部門が抱えている問題点、悩みを把握・分析し、改善への方向性を示す。

・経営層、情報戦略担当役員、情報セキュリティ関係担当役員、現業部門上位管理者、情報システム部門上位管理者、企画関係者へヒアリングする。客先から許可された場合は、現行システムを試用又は見学する。

・企業の情報資産(情報システム、データ、人材、ドキュメント)を識別し、使用状況を把握し、合理的に整理する。

Ø 現行情報部門の組織(体制)

Ø 現行ユーザー部門の組織(体制)

Ø 企業内における情報資産のワークフローを分析する

・現行システムを評価する

Ø 現行システムにおける技術的環境(使用技術、保存データ)

Ø 現行システムにおける人的環境(配置、負荷、生産性、コスト)

Ø 現行システムの性能

Ø 機密性、完全性、可用性の側面から経営における重要度、致命度を評価し、整理する

・現行システムに対する課題を洗い出す。

・整理・評価した情報資産につき、経営層、情報セキュリティ関係担当役員、企画関係者に説明し、承認を得る。

【移行計画策定】移行後のシステム環境はどのような形になるのかを正確に把握した上で移行計画を策定する。

・新業務のワークフローの概観を作る。

・新業務における役割、組織、環境を定義する。

・新業務への移行の影響を明確にする。

・開発体制の決定

・利用する資源(資金／人員／物品)の決定

・大工程スケジュールの決定

・開発手法／成果物とその承認方法の決定

【開発優先度】情報システム開発の優先度は経営的判断に基づく。重要な経営課題に直結したシステム開発の優先順位は高くする。

要件定義

システム開発を行う上で、現状の問題点や業務を調査、分析して対象となるシステムの要件を定義する。ユーザーに直接インタビューを行ったり、既存システムを調査したりして仕様を決定する。

【要求仕様(定義)書】ユーザーが開発して欲しいと望むシステムに組み込んで欲しい機能等の要求を満たすために、どのようにすれば実現できるかという内容(仕様)を開発側が文書にまとめたもの。ここで作られた仕様を元にシステムを設計する。

この段階でしっかり文書化し、ユーザー側と開発側の意識の差を埋めた上で開発に入る。ユーザー側は、この文書をしっかり検討した上でその後の契約を行い、開発側はユーザーの意見をしっかりとヒアリングし、後戻りの少ない開発を行うのが望ましい。インタビューした内容から要求項目の洗い出しを行い、要求仕様を確定していく。ヒアリング能力が不足している場合、下流工程では吸収しきれない追加案件が発生する可能性がある。

【システム化要件定義】

・システム化対象範囲を定義する。システム化対象範囲(領域)を明確にする。開発対象外領域を明確にする。

・対象システムと関わり合いのある直接利用者及び外部システムとの最上位I/Fを定義する。

・開発方法を定義する。

・要件定義で使用する用語を定義した用語集glossaryを作成し、管理する。

・ユーザー部門に対し、とことん質問を繰り返すことで要求分析能力は磨かれる(｢ITエンジニアの意識・実態｣日経システム構築(2004.1)139)。

【システム要件定義】システムの要件定義（機能要件、性能要件、運用要件、品質要件）を行う。

・性能・品質要件を定義する(応答時間、処理量、信頼性・可用性、保守性・機能拡張性、安全性・セキュリティ、完全性、性能維持の限界条件)。

・システムで共有化したい情報と資源の要件を定義し、システム運用上の評価をする。

・システムの資源管理に関する要件を定義する(構成管理、機器管理、統計・報告、物理的接続性)。

・システムの運用管理に関する要件を定義する(データの外部保存、バックアップ、システム監視、障害対応、ファイルの配布)。

・システムに対する基本的な受け入れ基準を定める。

【サブシステム定義】システム化対象範囲内を機能分解し、サブシステムを定義する。

・システム化対象範囲を業務機能に分解する。

・システム的な観点で業務機能を幾つかまとめたサブシステムを定義する。

・サブシステムの機能を定義する。

・サブシステム間の最上位I/Fを定義する。

・サブシステム毎に必要となる処理形態(e.g.バッチ、リアルタイム)、分散形態の要件を明確にする。

【システム間I/F定義】

・新システムと関連する他システムを明確にし、新システムと他システムとのI/Fを分析する。

・システム間I/Fとして必要な機能を定義する。

【技術アーキテクチャ要件定義】新システムに必要な技術についての方向性を検討・定義する。アーキテクチャとはシステムを構成する基盤を指す。

・技術アーキテクチャ構成要素(H/W, S/W)をリストアップする。

・技術アーキテクチャ構成要素の将来動向を考慮する。

・技術アーキテクチャ候補を選択する。実績ある複数の技術の中から、ベストプラクティスを選定する。常に最新の技術を選択する必要はない。多くの要素(既存システム環境とのI/F、経済効果、技術の将来性)を判断し、必要がなければ従来技術による開発で十分なことも多い。

・技術アーキテクチャ候補及び競合アーキテクチャの費用・効果を比較評価する。豊富な構築経験に基づき、システム構築に要するコストを試算する。

・移行後のお客様システム環境(H/W, S/W環境等)を想定し、関連するプロダクト間の事前評価やお客様アプリケーションとの整合性確認を実施する。

【既存機能の再利用性評価】

・既存システムの再利用可能部品を評価する。

・既存システムの再構築部分を整理する。

・既存システムのリバースエンジニアリング必要性を整理する。

【移行要件定義】

・移行方式(Big Bang, Shadow, Fade out)を決定する。

・試行本番の必要性を検討し、必要な場合は候補サイトを決める。

・本番開始順番に関する条件を決める。

【Data Flow Diagram】DFDはデータの流れ(データがどこから入り、どこでどのように処理され、どこに出て行くのか) に着目して図式化する方法。データの流れを見やすく図や式で書く方法。DFDでは4種類の記号を使用する。

・データフロー(矢印)はデータの入力源から出力先までの流れを表す。1個のプロセスから複数のプロセスへ流れる場合もある。異なるプロセスから流れるデータフロー同士が合流して1つのプロセスになることもある。データフローには、流れている情報が分かるような名前を付ける。

・プロセス/処理(丸型四角で囲む)はデータの加工、変換を表す。

・データストア(2つの平行線で挟む)はデータやファイルの保管を表す。一時的な記憶の場合もある。ファイル間のデータのやりとりでは、間にプロセスが挟まれる。

・データ源泉data source, sink(四角形)はデータの入力源や出力先を表す。外部とも呼ばれる。

設計

【外部設計(論理設計)】要件定義で明らかとなったシステム要件を設計する。ユーザーの目に映る部分、コンピュータから見ると外側部分の設計を行うフェーズ。ユーザーの立場から見た設計が中心となる。

システム構成の共通基盤を設計し、システムの機能を決め、アーキテクチャ・I/F等を設計する。信頼性・安全性を向上させるには運用前の設計が必要。

・システムがどんな機能を持てばよいか決める

・システムのI/Fを決める(外部入出力(画面)設計)

・システムの大まかな概要を決定する

・ハードウェアの構成(マシン性能、OS)

・帳票設計、論理データ設計、コード設計

・開発にいくらかかるか(値段・期間)

・開発に使用するプログラミング言語の決定

【内部設計(物理設計、詳細設計)】外部設計での機能を分割して、機能を実現するためのプログラムの構造設計や、外部設計で行ったものをより詳細に設計する。開発者の立場から見た設計が中心となる。

・システムを分割（サブシステム化）

・各サブシステムの働きを決定（機能の明確化）

・各サブシステム・機能間の処理の流れを明確化

・サブシステムとして分割された機能単位を、幾つかのプログラム単位に分割する。評価基準(モジュールの独立性)に従って分割する。独立性が高いほどモジュールの不具合があったときに、影響が少なくてすむ。モジュールの独立性が高いとは、そのモジュールがある機能だけを実現していて、他のモジュールへの影響が少ないということ。モジュールの独立性の尺度にはモジュール強度とモジュール結合度がある。モジュール強度を高く、結合度を低くすることで、信頼性、保守性を向上できる。

・プログラムを作成できるレベルまでシステム内部を詳細に設計

【モジュール強度】各モジュール内部の関連性の強さを表す。機能的にまとまっているほど強度が強く、良いモジュールである。モジュールの強度が低いと他のモジュールを修正した場合に影響を受けやすく、再利用がしにくくなる。逆に、強度が高いと他の影響を受けにくく、再利用がしやすく拡張性の高いモジュールと言える。

モジュール強度は以下のような７つのレベルで表し、後の方が強い。

・暗号的強度は既存のモジュールを単純に分割したり、関連性のない複数の機能を１つにまとめたりしたモジュール。複数の関連性のない機能が集まっているモジュール。

・論理的強度は論理的に関連のある複数の機能を１つのモジュールにまとめ、引数の値によってそのうちの１つを呼び出して、実行するようにしたモジュール。指定された機能を実行するモジュール。どの機能を実行するかどうかはパラメタとして与えられる。

・時間的強度は特定の時点で逐次的に行う複数の機能をまとめて、実行するようにしたモジュール。

・手順的強度は逐次的に行う複数の機能をまとめて、実行するようにしたモジュール。処理する順序が決められている機能を持つモジュール。

・連絡的強度は手順的強度のモジュールに、モジュールの要素間で同じデータの受け渡しや参照が行われるモジュール。処理する順序が決められていて、かつ同じデータを利用する機能を集めたモジュール。

・情報的強度は特定の同じデータ構造を扱う複数の機能をまとめたモジュール。特定のデータを利用する機能を集めたモジュール。

・機能的強度はモジュール内のすべての機能が、単一の機能を実行するために関連しあっているモジュール。特定の機能を実行するモジュール。

【モジュール結合度】モジュール結合度とは各モジュール同士の結合の度合いを表したもので、結合度が弱いほど独立性が高くなる。モジュール結合度が低ければ保守性が良くなり、逆に高ければ保守性が悪くなる。モジュール結合度を弱い順に並べると次のようになる。

・データ結合ではモジュール間のデータは、全て引数として受け渡す。使うデータの受け渡しのみを行う。お互いに内部には関わりがない。

・スタンプ結合ではデータ構造（構造体、レコード）を含んだ引数として受け渡す。共通領域にない同じ構造のデータを受け渡す。但しその中の一部のデータは使わない。

・制御結合では呼び出されるモジュールの制御要素を引数として渡す。あるモジュールが他のモジュールを呼び出す時、制御のためフラグやパラメタを渡す。

・外部結合ではグローバルな(外部変数宣言している)データ項目を参照する。モジュール側でどのデータを使うかを宣言してあるデータを他モジュールが使う。

・共通結合ではグローバルな(外部変数宣言している)構造体を参照する。いくつかのモジュールが共通のデータ領域を参照している。

・内部結合では外部変数宣言していないデータを他のモジュールが直接参照する。１つのモジュールが、他のモジュールの一部となっている。

【実行計画策定】プロジェクト計画を再検討し、システム化計画を最終化する。開発全体コスト試算する。

【Function Point】ソフトウェアのコストモデルの１つ。機能毎に求めた複雑さの評価値と、システムの特性項目から求めた評価値の2つの値を基に、FP(function point)を計算し、 FP から必要工数を見積もる。

長所としては、プロジェクトの比較的初期から適用できることやユーザーから見える画面や帳票等を単位として見積もるので、ユーザーとのコンセンサスをとりやすいことがあげられる。短所としては妥当な基準値の設定のために実績データの収集・評価が必要である。

システム分析・設計技法

【構造化設計】大きな処理を段階的に小さな処理単位へ分割していく設計手法。構造化設計によって開発されたモジュールは独立性が高くなり、汎用性・保守性・拡張性に優れたよいプログラムとなる。トップダウンアプローチtop down approachは大きな単位から小さな単位へ設計を進めていく手法で、構造化設計には適している。

逆にボトムアップアプローチbottom up approachは、詳細となるモジュールから作成して、徐々に全体像を作っていく方法。

【Process Oriented Approach】POAは旧来のシステム分析・設計技法。機能を中心に考える。業務内容に着目し、その流れに沿って設計する。しかし業務の形態や流れは企業環境や戦略に大きな影響を受けやすいため、業務の流れが変化する度にシステムの仕様変更が余儀なくされ、大きなコスト負担を強いられる傾向にある。

【Data Oriented Approach】データ中心アプローチDOAはデータ中心の分析・設計技法。データ資源に着目して企業活動を分析し、設計する。データ資源は業務に比べて安定しており、正しいデータ分析・将来性のあるデータ設計を行なえば、企業環境・戦略に変化があっても、高い保守性を維持できる。

DOA によるシステム開発では、まず企業活動のデータ分析が行なわれる。多くの場合、E-R図で現データモデルが作成される。その上で、将来を見据えた新データモデルを構築し、システム基盤となるDBを設計していく。対象業務領域のモデル化に際しては、最も安定した情報資源に着目する。

【Entity- Relationship Model】実体entityと関連relationを2つの概念で表したデータモデル。関係DBを設計するためのモデルとして普及している。エンティティは特性を表すための属性attributeをもつ。

オブジェクト指向

【Object Oriented Approach】オブジェクト指向アプローチOOAは要求仕様を理解した上でオブジェクト(データとプロセスを一体化したもの)を定義し、それらのメッセージ通信や状態等を設計し、システム全体像を構築する。SWを独立した小さなプログラムの集合体として扱うことができるのでは、という考え方が根幹にある。可視性、拡張性、再利用性のメリットがある。オブジェクトを用いて、似たような構造のSWをたくさん作る場合に有効。但し大規模な開発でないとメリットは現れにくい。

オブジェクト指向言語では状態(メンバ変数)と振る舞い(method)をもつオブジェクトを定義する。オブジェクトが他のオブジェクトに対してメッセージを送信することによって、オブジェクト同士を協調動作させることで処理を実行していく。オブジェクト指向言語にはJavaやC++以外にもSmallTalk, Ruby, C#がある。

【object】概ね｢もの｣｢対象｣｢目的｣の3つ。オブジェクト指向でいうオブジェクトは単に存在するだけの｢もの｣ではない。オブジェクトが存在する前に認識する主体がまず存在する。この主体がある目的を持ってある視点から認識した対象がオブジェクト。目的や視点が異なればオブジェクトも異なる。

【Class】似たような性質のオブジェクトをあつめたグループ。逆にオブジェクトはクラスをインスタンスinstance化したものとなる。インスタンスとは、クラスの個々のオブジェクトを具体的にあらわしたもの。

クラス間に共通する性質を抽出し、共通情報クラスを作った時に、上位クラスをスーパークラス、下位クラスをサブクラスと呼ぶ。サブクラスからスーパークラスを生成することを汎化、スーパークラスをサブクラスに分解することを特化specializationと言う。クラスを変更しても、他のクラスへの依存性はないため、変更する必要はない。

【継承inheritance】既存のクラスの特性をもとに、新しいクラスを定義すること。親クラスの性質や動作を子クラスが引き継ぐ。サブクラスは、スーパークラスのデータやメソッドを継承する。モデルの拡張や変更の際に変更部分を局所化できる。

【Generalization】汎化はオブジェクト指向で抽象化を行うこと。複数のオブジェクトに共通する性質に注目して抽象化することで、is-a関係とも言われる。例えば、バスやトラックを汎化すると自動車になる。｢バス/トラック is a 自動車｣の関係である。スーパークラスとサブクラスをis-a関係で見れば｢サブクラス is a スーパークラス｣になる。

オブジェクト指向モデルでは抽象化の対象となるオブジェクトの操作は指定しなくてもよい。

【encapsulation】カプセル化は、オブジェクト同士の独立性を高めるための方法。カプセル化でデータとメソッドをひとまとめにして、オブジェクトとして定義し、外部に対しては必要な情報messageの交換だけとすることで独立性を高める。カプセル化はデータを外部と切り離した状態にすることなので、相互依存性は低くなる。再利用がし易くなる。

【分散オブジェクト】オブジェクト同士の動作を 1台のコンピュータ上だけで行うのではなく、NWを介して離れたコンピュータ上のオブジェクトの呼び出しを可能にする技術。分散オブジェクトを実現する技術としてはCORBA: Common Object Request Broker Architecture, Java RMI, HORBがある。

CORBA はオブジェクト同士がメッセージを交換するための共通仕様である。オブジェクト間通信の基本インタフェース、相互運用規定からなる。ネットワーク上に分散しているオブジェクトを呼び出すために、CORBA がインフラの役割を果たす。

言語に依存しないのが特徴で、あらゆる言語のプログラムをCORBAで接続することが可能。異なった言語で開発したオブジェクト同士でも、クライアントからサーバ上のメソッドを呼び出すことを可能にする標準仕様。

構築

【開発標準化】開発および運用のために必要な標準化を実施する。開発標準、命名規則、コーディング規約を作成。ドキュメントのフォーマットを評価し、品質を均一化する。

標準化により以下の点が実現される。

・品質の向上

・生産性の向上

・保守性の確保

【プロトタイピング】プロトタイプにより技術的に難易度の高い各種連携機能・パフォーマンスを検証する。

・プロトタイプの対象範囲を決める。

・暫定版データ構造を設計する。

・プロトタイプを設計する。

・必要に応じ、設計情報を補正する。

・プロトタイプから、プログラムの雛型を作成する。

【開発・実装】プログラムをいくつかのモジュールに分割し、プログラミングの手順を決定し、コーディング、コンパイルまでを行う

・テンプレートと雛型により、開発生産性の向上と標準化を徹底する。

・不良が発生した場合は障害データベースに不良内容を登録する。

・仕様変更を行う場合は仕様変更連絡書を作成して変更内容を他のサブプロジェクトに連絡する。

・プログラムを変更するときは変更理由をリポジトリに登録し、プログラムの変更履歴が追跡できるようにする。

【構造化プログラミング】コンピュータ科学者ダイクストラによって提唱されたプログラミング手法。プログラムへの入口が1つ、出口が1つであれば、順次・選択・繰返しの3構造で全てのプログラムは記述可能であるとする。

・順次はプログラムで記述された順に処理を行なっていく構造

・選択は条件によって処理を分岐させる構造

・繰返しは条件が満たされている間は、一定の処理を繰り返す構造

構造化プログラム以前はgoto文goto statementと呼ばれる命令によりプログラムの流れを制御する方式が主流であった。goto文は制御構造と無関係にプログラム上の任意の命令へ処理を飛ばすことができる。しかし大きなプログラムになると、goto文が大量に埋め込まれることにより、あちこちに処理が飛んでしまう状態になりがちである。こうなると作成した本人ですらプログラム構造の理解しにくく、保守性の悪いプログラムとなる。

このようなプログラムは制御ロジックが絡み合っている様子からspaghetti programと呼ばれる。構造化プログラミングはspaghetti programを生み出さないためのプログラミング手法として着目された。誕生以来30年以上が経過しているが、その考え方は現在においても標準的なプログラミング手法とされている。

【review】開発を行ったシステムについての意見を出し合い、批評を行うこと。複数のメンバーが集まり、再検討や改良を行って後工程に影響を与えないようにすること。かみ砕いて言えば、皆でチェックする会議のこと。

・ round robinは参加者全員がそれぞれの分担について、レビュー責任者を務めながらレビューを行うので、参加者全員の参画意欲が高まる。｢いくつかの処理を決った順番で繰り返して行う｣という意味から来た。

・ walk throughはエラーの早期発見を目的として少人数で短時間に行うレビュー方法。主催者(開発者自身)が同じシステム開発に携わった人の中からメンバーを集める。主催者は、事前に資料を配布しておき、各メンバーは配布資料を検討した上でレビューに臨む。そして、なるべく短時間で効率の良いレビューを行う。入力を仮定してコードを追跡するように、手続をステップ毎にシミュレーションすることによってレビューを行う。

・ inspectionはエラーの発見を目的として、事前にレビュー資料を準備し、責任者modulatorの下で行うレビュー。予め参加者の役割を決め、幾つかの選ばれた局面に注意を払い、迅速にレビュー対象を評価する。

テスト

テストは計画、仕様設計、実施、評価報告で構成されるライフサイクル・プロセスである。

・単体テストは出来上がった個々のモジュールをテストする。

・結合テストは他のモジュールと結合して行う

・統合テストは結合テストのうち、特にハイレベルのものを指す。

【テスト計画】対象システムについてヒアリングし、テストツールの動作確認、工数見積、詳細スケジューリング等を行い、最適なテスト計画を作成する。テスト体制・テストスケジュール・テスト項目・テスト方法等を策定し、実行計画書を作成する。

・テスト実施体制について。客観性を持たせるため、プログラミングの担当者とテスト担当者は別々とすることが望ましい。

・開発・改造部分及び周辺の既存機能を含め、どの範囲でテストを実施するか。

・開発・改造部分及び周辺機能について、各々どのような方法で、テストの結果が確認できるか。

・用意するテスト環境と、本番環境の性能差をどのように評価するか。

・テストケースのような詳細内容は不要で、あくまで方針レベルで良い。

【テスト環境】テスト環境をどのように用意するか。本番環境・開発環境とは独立させた、テスト環境が必要であるか。シビアな性能が求められる場合、本番環境を使用したテストは避けられない。

テスト環境は、システムの本番運用中でも、プログラムにバグがあってプログラムの修正をした時には再度テストを行う可能性があるため、テスト終了後も撤去すべきではない。但しテスト環境があまりにも大きければ別であるが、そのような場合は別に試験環境を用意するのが一般的である。

【仕様書作成】テスト対象処理の一連のオペレーションを記録し、テストシナリオを設定する。仕様書・テストスクリプトを作成する。テストシナリオ・項目・実施基準を評価し、品質を保証する。

【white box test】プログラムの内部構造や制御の流れに着目し、ロジックを調べて、全ての経路algorismが実行されるようにテストデータを作成する方法。全ての命令を少なくとも１回実行するようにテストデータを作成する命令網羅法や、if文等の分岐命令の組み合わせを考えた条件網羅法がある。分岐命令やモジュールの数が増えるに従って、テストデータが大きく増える。

テストデータの作成基準として、テストケースの網羅率coverageを使用する。coverageとは、ソースプログラムのパスのうち、どれくらいテストを達成したかを表す網羅率のこと。プログラムの動的なテストを行うためのテスト支援ツールとしてカバレージモニタがある。

【black box test】プログラムの内部構造やロジック(論理構造)については一切考えずにプログラムの外部仕様(入出力データ)からテストデータを作成するテスト方法。プログラムが設計者の意図した機能を実現しているかどうかのテストで、主にプログラム開発者以外の第三者が実施する。このテストでは、プログラムに冗長なコードがあっても検出することはできない。同値分割や限界値分析、実験計画法もこのテストに含まれる。

【結合テスト】モジュールの結合テストは、各モジュールの単体テストが終わった後に関連するモジュールをくっつけて行う。

・ bottom up testは、下位のモジュールから上位のモジュールへと、順次結合してテストする。上位のモジュールが完成していない場合はテスト用の代役モジュールとしてドライバdriver を用いる。ドライバは、テスト対象のモジュールを呼出し命令で呼び出す役割をする。テストの最終段階で全体の制御flowをテストすることになるので、最上位のモジュールで問題が発見された場合、トップダウンテストに比べ、他のモジュールに与える影響も大きくなる。

・ top down testは、上位のモジュールから下位のモジュールへと、順次結合してテストする。下位のモジュールが完成していない場合は、テスト用の代役モジュールとして、スタブstubを用いる。スタブは、テスト対象のモジュールからの呼出し命令の条件に合わせて値を返す役割をする。実際の開発ではあまり使われていない。

・ big bang testは、一度に全モジュールを結合してテストを行う。

【バグ埋込み法】SW内に残存するバグを推定するために意図的にバグを埋込み、埋め込んだバグが全て見つかった段階でSW内に残存するバグが見つかったことにするテスト方法。

【システム(総合)テスト】システムテストは、システム全体の機能テスト、性能テスト、障害回復テスト等を行うことによって、システム全体の品質を総合的に確認する作業である。システムテストでは、システム全体の十分な品質を確保するために、必要なテスト期間を設定し、本番と同じ環境を用いたテストを実施することが望ましい。

しかし実際には、テスト期間が限られていたり、本番環境と同等のテスト環境を用意できなかったりすることが多い。そこで、システムテストの計画立案に当たっては、このような制約を踏まえたテスト項目やテスト方法の策定が重要である。

【負荷(ラッシュ、ストレス)テスト】負荷テストは短時間に重い負荷(ストレス)をかけるテストである。大きな負荷がかかった場合にシステムの機能や性能にどのような変化が現れるかをテストする(NEC Eラーニング事業部編・アルゴリズムとシステム開発(日経新聞社2002)217)。

システムが本番運用に耐えられるものであるか検証し、合わせてそのボトルネックを明らかにする。高負荷I/Fの処理効率検証を実施する。

アプリケーションの処理時間や各サーバのCPU使用率/Memory使用量等、システムを構成する様々なノードのデータを採取する。採取データを元に、処理時間や各サーバのリソース使用状況をグラフ化し、テスト結果として分析する。

【Recovery Test】リカバリテストでは、障害とデータ消失に対してシステムを保証するあらゆる手段をテストする。性能要件として障害回復時間が規定されている場合は、切り替えに要した時間を測定する。

リカバリはシステム機能の1つであり、広義の機能テストの一部である。しかし、それはビジネスオペレーションを成功させるために非常に重要な機能である。仮にリカバリ機能が不完全ならば、システム障害から素早く復旧できず、ビジネスは短期の収入と長期の顧客信用を失うことになる。

リカバリテストは復旧の訓練にもなるため、ユーザーを巻き込むことが望ましい。障害回復手順書が完備していたとしても、実際の作業経験がないと初めての作業ではうまく行かない。しかも障害発生時は限定された時間内で、更に精神的な余裕もない状態でリカバリ作業を行わなければならない。

【受け入れテスト支援】受け入れテストは内容的にはシステムテストと変わらないことが多いが、実施主体はお客様である。

【業務(運用)テスト立会い】お客様業務(運用)テストへの立会い技術サポートを行う。

Quality

【プロジェクト品質】品質指標は下記の通り。

・プロダクトの品質：コンベンショナルな品質保証と品質管理の手法が適用されることが多い。

・プロセスの品質：最近注目されだしたプロジェクトマネジメントの組織成熟度のような手法を使う。

・メンバー個人のパフォーマンス：パフォーマンスマネジメントが有力な手段である。

・顧客満足度：知覚品質的な部分が大きく、体系的なアプローチの考案が難しい。

Ø 如何にすばらしいシステムを設計し、如何に完璧なインプリメントをしようと、そのシステムが顧客の目的に適っていなければ、顧客が満足することはない。

Ø 顧客の中でしっかりとした目的の設定ができていない限り、如何にベンダーががんばっても顧客自身が満足できることはない。

【品質特性】SWの品質特性は、ISO/IEC9126 で6つの特性と21の副特性から規定されている。

・機能性：ソフトウェアの機能と目的との一致の度合い

・信頼性：ソフトウェアに定められた機能を果たす度合いや、障害からの回復のしやすさの度合い

・使用性：使用目的や機能のわかりやすさ、運用しやすさの度合い

・効率性：資源の有効活用度の割合や時間的効率の度合い

・保守性：変更、修正の容易度

・移植性：他のシステムや他言語への移植のしやすさ

【テスト】開発したシステムが十分な品質を確保しているかどうかを判断するために、確認すべき項目とそれらの判断基準を定め、品質の測定を行う。品質確保の判断材料として、テスト実施件数と不良発生件数がある。下記に該当する場合は、品質が確保されていないと判断される。

・不良が多い、誤り摘出予定曲線(類型)より誤りが上回っている。

・不良の累積グラフが収束傾向を示さない。

・テスト項目消化予定曲線より実績が下回っている。

品質が確保されていない場合は、その原因を分析し、分析結果に基づく対策を実施して、稼動開始日までに品質を確保する必要がある。

原因分析では、不良が作り込まれた処理や工程を究明するために、パレート分析や特性要因図などの手法が有効である。そして、期間・コスト・資源などが限られたテスト段階では、作り込まれた不良を効率的に除去する必要がある。

・原因分析の結果から、特定の処理に不良が多いという傾向が判明すれば、同じような処理を行っているプログラムを机上で点検する。

・誤り多発箇所の重点対策として集中的なテストを実施する。

・テスト方法を変更する。

・体制を見直す。

・前工程の品質状況を見直し、前工程をやり直す。

さらに、原因を掘り下げ、再発防止策を検討することが求められる。特定の処理に不良が作り込まれた原因や、テスト段階前に摘出できなかった理由等を分析し、今後のシステム開発に生す。

本番

【導入】S/Wのインストール、作動確認を実施。インストール手順書、環境設定手順書、作動確認手順書を作成。

【チューニング】各種テストやヘルスチェックに基づき、チューニングを実施する。サブシステム単位の利用頻度・必要なシステムリソースの差異から、ディスクの使用率にバラつきがある場合は、データベースの配置替えを行う。

【教育(トレーニング)】新システムの要員教育を実施する。

【移行(切り替え)】移行準備、本番への立会い技術サポートを実施する。本番開始後に発生する問合せ・障害対応。

運用

【システム運用手順策定】現行のシステム運用を見直し、システムまわりの運用手順を策定する。運用手順書、BACKUP手順書、RESTORE手順書、リカバリオペレーションマニュアル、運行監視マニュアル、一時切り分け手順書、障害対応手順書を作成。

S/Wに障害を自動的に回復する機能があるとしても、自動回復機能がきちんと機能するように、障害回復手順を事前に検討する必要がある。

【障害発生未然防止策】重要なシステムでは、障害発生を未然に防止する仕組みが求められる。

・装置の二重化等のハードウェア、ソフトウェア両面での対障害設計。その目的は、障害は勿論ハードウェアの定期保守や、アプリケーション機能変更時の稼動保証にある。

Ø ハードウェアの定期保守や、アプリケーションの機能変更時には、片側ずつ作業を実施する。その作業中に、ミスが発生すると、システムは全体がダウンすることになるため。

・システムを、アプリケーション・基盤ソフトウェア・ハードウェアの３層に分割し、各々の層にて稼動状況を定期的にモニタリングする機能を組み込んでいる。アプリケーションの異常終了時や、CPU・ディスクの使用率が予め設定した閾値を超えると、警告を管理者にメールで通知する機能を有している。

・不注意によるミスや操作誤りを防止する確認手順や運用体制の構築

Ø 作業記録表や、作業者へのヒヤリングより、手順書の不明な点を明確化する。

Ø 極力作業を自動化する。多くのオペレータ操作を残したまま作業を継続する場合には、些細なミスでシステムダウンを引き起こす可能性がある。

・定期保守や予防保守の適切な実施

【復旧計画】システム導入時に、障害発生時の復旧計画を策定する。導入するシステムが使用する業務を確認し、発生しうる最悪の障害を想定し、それに対する復旧計画を立て、復旧までの時間を把握する。長期に渡って運用することが多いシステムでは、様々な障害が起こる可能性がある。その場合の被害を、最小に抑える準備が必要である。

・どこまでデータの保証を行うか。

・障害発生時から復旧までの時間はどこまで許されるのか。

【障害対策】情報システムには障害発生対策が常に重要である。システムの運用時に障害が発生した場合、業務の遅滞や多額な復旧費用などの著しい損失を招くことともなりかねない。

障害前のログ・操作内容・ハードウェアの情報等、取得できるものは取得し、解析する。データ保持部分(ディスク)の障害であると情報が取れない場合もある。ハードウェア障害・破損の場合は部品交換等になる。

・コンソールログはシステムの自動通報で通報されたメッセージを格納したログ。　　　　主に保守員が保守拠点で利用する。

・ジャーナルはジャーナルファイルやログファイルとも呼ばれる。この記録はシステムに障害が発生したときや、データが事故などで消失した時に、原因究明や復旧のために使用される。システム性能上の問題点分析や、改善のデータとしても使用される。

【Help Desk】ヘルプデスクは、エンドユーザがシステム・サービスを利用する中で発生するトラブルや疑問を受付ける窓口。コンピュータシステムの規模が巨大化し、複雑になってきている今日では、円滑なシステム運用を行うために不可欠な存在となっている。

解決までの全作業をヘルプデスクだけで行うとは限らないが、エンドユーザからの一次受付窓口として適切な処置を講じ、円滑なシステム運用を提供するための問題解決力が求められる。エンドユーザからの問合せは、電話・FAX・電子メールで受けるのが一般的。簡単な内容の問合せであれば即答することもあるが、解決までに時間を要すると判断される場合は、適切な手順で対応する必要がある。

【廃棄】記録媒体を廃棄する場合には、電子化情報の漏洩を完全に防ぐ措置を講じる。媒体が不要となった場合は、安全・確実に処分する。処分のための正式な手順を確立し、監査証跡(監査対象システムの入力から出力に至る過程を追跡できる一連の仕組みと記録)を維持するために、可能な方法で記録する。

・管理台帳上の保管期間が経過したデータであっても所定の手続に従い処理する。

・データを廃棄したとしてもその管理台帳の記録を抹消する必要はない。

保守

ソフトウェア保守はソフトウェア納品後に顕在化したエラーや、ソフトウェアに対する変更要求に対処する工程である。下記の要因により発生する。

・ソフトウェアの品質や性能が仕様書通りに作成されていない

・実行速度・操作性等に性能改善の必要性がある

・外部環境の変化(e.g.法改正)による仕様変更の必要性

・ハードウェアやOSの改定による変更の必要性

有償の作業なのか、無料で行わざるを得ない作業になるのかの判断基準を予め規則として、用意しておく必要がある。

ソフトウェア保守の JIS 規格では，ソフトウェアの修正活動に際して開発プロセスを参照する。保守作業の実行準備から始まり、修正・移行・廃棄までの各アクティビティは、開発プロセスと同様の活動を、それぞれの保守要求案件毎に実施することになる。

【退行テストregression test】ソフトウェア保守のために修正や変更が他の正常な部分に影響を及ぼしていないかを確認する。今まで問題なく稼動していた箇所が、他の部分の修正により、影響を受ける可能性があるため(リップル効果)、修正を加えた部分以外も再テストする必要がある。システム導入後の保守時(システム変更時)に行う。

Security

【情報セキュリティマネジメントシステムISMS】企業活動を適切に運営するために必要なマネジメントシステムの一つ。個別のセキュリティ問題毎の技術対策に加え、事業戦略やリスク評価によって必要なセキュリティレベルを定め、それを継続的に維持するための組織的な仕組みをいう。セキュリティ目標を達成する上で、効率的かつ効果的なセキュリティ対策を実現するためにも必要な仕組みである。

経営者は組織の情報セキュリティマネジメントシステムを構築するとともに、それによって組織のセキュリティ目標が実際に達成されているかどうかについても検証していくことが必要である。システム監査は経営者に代わって、情報セキュリティマネジメントシステムの実効性について監査を実施するという重要な役割を担う。

【基本方針】事業の特徴、組織、その所在地、及び技術の観点から基本方針を定義する。この基本方針は、次の事項を満たさなければならない。基本方針を定める際にこれらの項目を考慮した上で、問題のない、不整合などの起こらない基本方針にする｡

・目的。

Ø 組織として情報セキュリティに取り組むという決意の表明。

Ø 情報セキュリティが重要な取り組みであるという意識統一。

Ø 組織としての決意を周知することによる意識向上。

・情報セキュリティを実施していく上での方向性を指し示す。

Ø 情報セキュリティの対策がなぜ必要だと考えるのかという背景。

Ø 情報セキュリティ対策をすることでどのようなことを達成したいと考えるのか。

・目標を確立するための枠組みを含み、情報セキュリティについての活動の方向性及び原則を全体的な意味において確立する。

・事業上及び法令または規制上の要求事項、並びに契約に基づくセキュリティ義務を考慮する。法規制や契約を遵守することの宣言。

・基本方針を確立し維持する、戦略的に見た組織の情況、及びリスクマネジメントの情況を確立する。会社として特に実施すべきセキュリティ対策は何か。

・リスクを評価する基準、及び定義されるリスクアセスメントの構造を確立する。

・経営者によって承認されている。基本方針は組織としての方針であるため、組織の経営者が承認して、関係者へ開示する必要がある。方針を承認することで、経営層の関わりが希薄になってしまいがちな情報セキュリティ対策への参加意識を強くするという効果もある。

基本方針を策定する際は次の手順で進める。

・まず適用範囲を見直す｡

・適用範囲内で、会社にとって特に重要な情報、サービスは何かを検討する。

・適用範囲内で、会社にとって特に脅威となるリスクは何かを検討する｡会社として優先的に対応すべきリスクはどのようなものか。

・会社の経営方針、さらには会社として特に守らなければならない法規類を確認する。

・情報セキュリティ対策を従業員に求める上で訴えかけたいことは何かを考える｡

基本方針を定めたら実際に文書化する。形式としては書面でも、データでも構わないが、なるべく見やすい形式で作成する。見辛いと周知もし辛くなり、形骸化の原因となってしまう。周知のポイントは下記の通り。

・適当な手段で、全従業員に公表し、通知する。

・ ISMS適用範囲を全員が理解でき、確認できる。

・策定するだけでなく、関係者へ適切な内容の説明を行い、理解させる。

・見たい時にいつでも見られる。

・策定した基本方針を外部に公開する企業もある。情報セキュリティ対策を実施していると宣言し、体外的にアピールすることで、信頼の獲得を目指す。

【体制】情報セキュリティ委員会を頂点とし、全社レベル・部門レベル等のセキュリティ責任者・担当者を任命する。

・情報セキュリティ委員会はトップマネジメント若しくは取締役が委員長を務め、各部門から最低１名ずつの部長若しくは同等クラスの人員を選出し構成する。セキュリティポリシーの策定から運用に至るまで、その牽引役を努める。

・全体情報セキュリティ責任者は経営陣が情報セキュリティ委員の中から任命する。全社レベルのセキュリティ運用を正しく遂行するための責任を負う。

・部門情報セキュリティ責任者は、各部に１名置き、セキュリティ対策が守られ、違反が起こらないような体制を整える。部門セキュリティ担当者を通じて、セキュリティレベルの維持に努める。

・部門情報セキュリティ担当者は各部の部門セキュリティ責任者の下に1名設置する。部門スタッフがセキュリティ規定等を遵守し、違反しないよう指導する。

・情報セキュリティ教育担当は社員に対し情報セキュリティ教育を計画・実施し、周知徹底、教育、啓蒙を行う。

・情報セキュリティ監査担当はシステム監査技術者の有資格者を責任者として配置する。情報セキュリティ監査の基本計画及び個別計画を策定する。

Ø 個別計画に基づき情報セキュリティの監査を実施する。

Ø 被監査部門へ是正のための助言、及び勧告を行う。

Ø 監査報告書を作成し組織体の長への報告を行う。

【セキュリティ管理】

・個々の資産の責任者を明確にする。

・保護対象資産台帳を作成し、維持する。

・セキュリティを職責に含める。

・就業規則に機密保持に関する規定がある。

・機密情報を取り扱う委託先と機密保持契約を締結する。外部委託に関する契約書に、機密保持に関する条項がある。

【セキュリティ教育】セキュリティ教育は3ヶ月-半年に1回程度定期的に実施することが理想。集合教育により、セキュリティに関する最低限の知識レベルを保証する。教育後に確認テストや理解度を確認するヒアリングを実施すると教育の有効性が高まる。あまり難しいテストをするのではなく組織として守るべき重要事項について全員が同じ意識を持っているということを確認するレベルで良い。

セキュリティ教育の検証ポイントは下記の通り。

・入社時期、職制、組織(支社・地方営業所を含む)に関わらず、セキュリティに関する最低レベルの知識を有していることを確認する。

・実際のテスト問題を入手し、テスト内容がセキュリティの知識レベルを問うに相応しい問題になっているか確認する。

・教育実施記録より、個人別にテストの点数が管理され、不合格者に再教育を実施する。

・知識を有していない者については、機密情報へのアクセス制限が行う。

・知識レベルを上げる活動を実施する。

【セキュリティ設計】

・セキュリティ基準からセキュリティに関するシステム要件を導出する。

・リスク分析で行った情報資産の評価に従って、適切なセキュリティを適用する。特に物理環境的対策には大きな経済的負担を強いられる施策も考えられるため、リスク分析を適切に行い、重要度、費用対効果を含めた検討が必要になる。

・ネットワーク設計を理解し、セキュリティの観点で、問題点と対応策を検討する。

・信号漏洩防御に適した物理媒体を選択する。

・ネットワーク切断事故に対して被害を最小限に押さえられるような、ネットワークトポロジを選択する。

・企業の関連する組織に出向き、セキュリティを実現するために議論し、説得する。

【物理環境的対策】物理環境的セキュリティは、眼で見ることができるセキュリティである。建物及び関連設備は、想定されるリスクを回避できる環境に設置する。

・物理的に重要な情報資産が隔離できるようにシステムを統合化する。

・施設の敷地および建物のセキュリティ境界から、しっかりとセキュリティを維持する。

・耐震性(免震構造、完全2系統の電源設備と自家発電装置)、耐火性(水を用いない消火設備)

・外壁の外側に更に侵入を防ぐ外皮状の構造物を張り巡らせる。

・物理装置の配置、人的アクセス及び使用環境の安全装置(監視カメラ、搬入時の侵入を防ぐための高速シャッタ、完全に個室化されたトイレ)

・正面エントランスをあえてガラス張りにすることで、見通しを良くし、犯罪者の侵入の抑止効果、早期発見に役立てる。

・人的脅威には、故意によるものと過失によるものと分けることができる。過失による脅威の発生率を低下させる工夫をする。

Ø リラックスできる雰囲気を作り上げることでヒューマンエラーの発生を防ぐ。

Ø サーバルーム空調の静音化により、作業中の聞き間違いの発生を防ぐ。

Ø ラックを搬入した後で適切な場所に照明を取り付ける仕組みにすることで、作業する手元が常に照らされるようにする。

【セキュリティ区画】通常、セキュリティ区画とそれ以外の区画と2つだけということはなく、セキュリティレベルが異なる区画が複数存在することになる。

・セキュリティ区画の境界を明確に設定する。その境界が曖昧になると情報資産の重要度に応じた管理ができなくなる。

・セキュリティ区画は従業員不在時には施錠する。

・セキュリティ区画への入場は、管理責任者の許可を受けて登録した特定のメンバーに制限する。

・セキュリティ区画に入場する者には身分証明となるカード・バッジ等を常に明示させる。従業員は身分証明の明示がない入場者の相互確認を行う。

・従業員が異動や退職によって入室権限がなくなった場合、即座にメンバリストから削除し、登録メンバリストの改定作業を行う。身分証明となるカードあるいはバッジ等の返却を指示する。返却の確認を第三者が監視する。

・セキュリティ区画に入場可能な登録メンバーを定期的に見直す。

・セキュリティ区画への未登録者の入場については必ず入退場を記録し、登録メンバーが同伴する。

・セキュリティ区画に入場する外部からの来訪者には区画内での注意事項を事前に説明する。

【認証と権限】

・認証と権限の関係の整合性を保ち、認証・権限に関するシステム要件を論理的に組み立てる。

・認証されたユーザーが適切な情報資産にアクセスできるように、アクセス制御等のネットワークヘの要求条件を明確化する。

・認証、暗号技術、デジタル署名技術等のセキュリティ技術を統一のとれた観点で一つのシステムにまとめ上げる。バイオメトリックスやデジタル署名技術の利用について判断する。

・認証では、必要以上に冗長な確認を行わず、アクセス権限の付与は使いやすいように設計する。

・不正利用者に1つ認証が破られても、そのままでは他の部分ヘアクセスできないように、権限のコントロールを実施する。

・許可されたユーザーの動作を記録し、システム及びデータの不正アクセスに対して、発見しやすいように設計する。

【暗号化】

・リスク分析により、不正利用されたとき最もリスクが大きいデータが暗号化されるように設計されている。

・復号は参照するときのみ実行されるように設計されている。

・暗号鍵の管理は十分に行われるよう設計されている。

【管理】システム管理者は、システムにおけるセキュリティを確保する。

・管理は少人数の管理者グループにより、一元管理する。管理者が一人の場合、相互牽制が働かない、管理者不在時に対応できないという問題がある。

・管理情報は一般ユーザーに公開しない。

・管理用アカウントも個々の管理者専用のものを使用し、管理責任を明確にする。管理用アカウントを共有すると問題が発生した時に、追跡が困難になる。加えて牽制機能も弱まる。

【アクセス制御】利用者としての権限を与えられた利用者が適切にシステム資源を利用できるようにする。アクセス権は利用者がコンピュータシステムで操作できる情報と操作内容を限定するためのものである。UNIX であれば読込み、書込み、実行の権限をビットで表し、このアクセス権を所有者、グループ、その他といった単位で設定する。

パスワードアタックにも様々な方法があり、近年のPCの性能向上に伴い解析能力も上がってきているので、不用意なパスワード設定の危険性は増している。ブルートフォースアタックや辞書攻撃を行うツールでパスワードを解析されるという脅威も考えられる。

・ユーザーIDは、複数のシステムユーザで利用しない。

・ユーザーIDにはパスワードを必ず設定する。パスワードは随時変更する。パスワードは、紙媒体等に記述しない。

・パスワードには簡単に類推されない文字列を選択する。

Ø 数字、アルファベット、記号を組み合わせる。英数字以外の文字が許可されている場合はできるだけ利用することで強化できる。

Ø 下記をパスワードに使わない。ユーザーにとって、これらは覚えやすいのでパスワードに設定してしまう可能性が高い。

² 自分の名前、自分の名前の一部、イニシャル、誕生日

² よくあるニックネーム(人名＋｢ちゃん｣｢さん｣｢くん｣)

² 辞書にあるような単語・略語(UNESCO)

² 非常に規則的なもの(12345678, qwertyui･･･キーボードの2列目の文字)

² ユーザーIDと同じ。これはJoe Accountと呼ばれ、パスワード解析では一番簡単に解析できてしまう。

Ø 大文字と小文字を混在させる。

Ø できるだけ長くする。一般的には8文字以上とされる。

Ø サービス毎に異なる。

・複数のユーザーIDを持っている場合は、それぞれ異なるパスワードを設定する。

・パスワードを入力する場合は、他人に見られないようにする。

・他人のパスワードを知った場合は、速やかにシステム管理者に通知する。

・ユーザーIDを利用しなくなった場合は、速やかにシステム管理者に届け出る。

・ユーザーに任せるだけでなく、AP側でも制御を行う。

Ø パスワードの桁数チェック

Ø 有効期限の設定

Ø 文字数・使用文字種の制限

Ø 仮パスワードの強制変更

Ø 一定期間使用していないユーザの使用を停止する。

Ø 誤ったパスワードを一定回数連続入力した場合、ユーザの使用を停止する。

【運用】

・セキュリティ方針とセキュリティ基準Security Policyに従って運用を実施する。

・記録したデータを保管する

・セキュリティ違反を発見した場合、決められた手続きに従った対応を実施する

・侵入検査により、実際に攻撃を行う。侵入検査の内容は、セキュリティに関する最新情報を反映する

・セキュリティホールを見つけた場合、速やかに対策を実施し、あわせて今後の継続的な対策を検討する

・セキュリティホール情報やセキュリティ勧告及びパッチ情報の最新情報を定期的に確認する

・ベンダ提供の最新パッチを評価し、必要に応じて導入する。

【監視】

・セキュリティシステム設計で監視対象及び方法を明確にし、対象トラフィックを監視し、記録する。

・例外事項、その他のセキュリティに関連した事象を記録した監査記録を作成する。監査記録は将来の調査及びアクセス制御の監視を補うために、合意された期間、分析可能な状態で保存する。

・情報処理設備の使用状況を監視する手順を確立する。

・監視結果を定期的に見直す。

・システムが直面する脅威とそれらの起こり方を理解するために、記録を検証する。

・コンピュータの時計を正しく設定する。

・監視ソフトウエアを利用し、効率的かつ適正な監視を行うと共に、ソフトウエアで監視できない項目については個別に監視項目を設定。

【ウイルス感染】ウイルス感染の兆候を見逃さない。メールの添付ファイルは、開く前にウイルス検査を行う。DLしたファイルは、使用する前にウイルス検査を行う。アプリケーションのセキュリティ機能を活用する。ウイルス感染被害からの復旧のためデータのバックアップを行う。

コンピュータウイルスに感染したと思しきマシンを発見した場合は、被害拡大を食い止めるために、先ずは応急措置を指示する(N/Wから隔離する、そのコンピュータと利用している記憶媒体の使用を一時禁止する)。その後、ウイルスの特定、被害状況の確認、感染経路の調査、ウイルススキャン・駆除を行う。最後に再発防止策を講じる。

Audit

【システム監査】監査対象から独立かつ客観的立場のシステム監査人が情報システムを総合的に点検及び評価し、組織体の長に助言及び勧告するとともにフォローアップする一連の活動。

システム監査の３要素は下記の通り。

・信頼性…情報システムの品質並びに障害の発生、影響範囲及び回復の度合

・安全性…情報システムの自然災害、不正アクセス及び破壊行為からの保護の度合

・効率性…情報システムの資源の活用及び費用対効果の度合

社外リーダ採用について

1.プロジェクト概要と社外リーダ採用事由(設問ア)

1.1プロジェクト概要

1.1.1情報システム概要

私が参画したプロジェクトは証券業A社のEAIシステム構築プロジェクトである。本システムは海外証券市場での注文・約定を行うために、A社内の証券取引システムを海外子会社の証券システムと連携する。両システムは業界標準のFIXプロトコルを用いた専用回線で接続する。FIXプロトコルではメッセージ形式が定められているため、EAIシステムで変換を行う。

1.1.2プロジェクト概要

システムインテグレータである弊社はA社EAIシステム構築を受注し、私はマネージャとしてアサインされた。私の下にそれぞれ4人で構成される基盤チームとEAIチームを編成した。

EAIシステムには工数削減のためパッケージを利用し、FIX連携の実績があるB社製品が採用された。但し繁忙期であり、B社製品開発経験のあるリーダクラスの人材が不足していた。

1.2.社外リーダ採用事由

1.2.1チームの役割及びメンバ構成

EAIチームはB社製品を用いて、FIXメッセージ形式への変換部分の開発を担当する。メンバの半数は元々証券取引システムの開発メンバで証券取引システムには精通しているが、B社製品については使用法のトレーニングを受けた程度である。残りの半数はB社製品の開発経験はあるが、皆若手であった。

1.2.2社外からの採用の検討理由

このプロジェクトでは海外子会社との間の相互接続性の確保が重要な課題になるが、Bを利用することで、接続については問題が少なかった。また、B社製品は操作性の高い開発環境を備えており、トレーニング受講レベルの者が開発を担当することは問題なかった。加えてB社製品は独特の開発環境を備えているために、とりわけ他チームとの調整事項が少なくなる開発工程においては、リーダに作業計画立案から管理までを任せることにより、B社製品の特徴を活かした生産性の向上を期待できた。

しかしEAIチームのメンバは開発者としては優秀な部類に属するとしても、設計や管理については未経験で、リーダを任せるには力不足であった。そのため、B社製品を使用した開発において設計能力及び開発スケジュール管理能力のあるリーダを社外から求めることにした。

2.リーダに求められる条件と確認方法(設問イ)

2.1具体的条件

私はチームリーダ選定条件を文書でリストアップし、上司の承認を得た。基準は下記の通りで、優先順位の高いものから並べている。

(1)リーダーシップ・コミュニケーション能力

(2) B社製品を利用した設計・開発経験、知識

(3)チームリーダ経験

(4)弊社システム開発手法・標準への理解

(5)証券取引業務知識

選定条件の根拠は、(1) のリーダーシップ・コミュニケーション能力については、一般にリーダに求められるスキルとして思いつくものである。いかなるプロジェクトであっても、メンバ間の公式・非公式なコミュニケーションなしに成功はありえない。ここにはメンバを指導・育成する能力も含めている。但しこの基準は曖昧で評価が困難なため、単なる好き嫌いになりかねない。

そのため、この基準をメンバと目標・方針を共有し、仕事を進められる能力というように具体的なイメージを持たせた。現在の若手メンバも将来はリーダを務めることができるように経験を積ませたいと考えているため、リーダーシップといっても自己の方針を強要したり、何でも自分でやってしまったりするタイプは避けることにした。リーダーシップとコミュニケーション能力をまとめて1つにしたのもこのためである。

(2)のB社製品を利用した設計・開発経験、知識についてはB社製品での設計能力に欠けるチームにおいては優先的に求められる条件である。単にツールを使って開発できるというだけでなく、設計できる点が重要である。

(3)のチームリーダ経験は、能力が経験に裏打ちされるとの考えから入れた。リーダに必要な管理能力はここで判断する。但し、欲しいのはあくまで能力であるので、プライオリティを下げた。リーダという名前でなくても、それに近い仕事をしたことがあれば可とする。

(4)の弊社システム開発手法・標準への理解については引き継ぎや保守を考慮すると外せない基準である。製品ベンダの推薦者の場合、製品知識は深くても、この点を満たせないことが多い。

(5)システムの性格から導かれるが、B社製品かつ証券業務に通じているとなると範囲が非常に狭まるので、あったらいいという程度に位置付けた。証券業務についてはメンバが精通しているので、それで補えると判断した。

2.2確認方法

2.2.1選考手続

選考手続は書類選考、面接の順に実施した。先ず弊社と取引実績のある協力会社からB社製品での開発実績のある企業を選定し、リーダ候補の提案を依頼した。取引実績のある会社から選定したのは、弊社では協力会社データベースを構築しており、それによりこれまでの協力会社利用結果を確認できるためである。データベースからは、当時の担当部署・担当者を辿ることもできるので、ヒアリングを行うことも可能である。

書類選考ではB社製品の設計経験やリーダ経験の有無を確認した。加えて弊社での実績がある場合は、弊社開発標準を理解していると一応評価した。書類選考では3人に絞り、私、私の上司、候補者、候補者の上司の4人で面接を実施した。面接で選定条件の一つのリーダーシップ・コミュニケーション能力という主観的な評価を行うため、弊社からも複数人で対応することにした。

面接ではリーダーシップ・コミュニケーション能力について、面識のないメンバもいる中でのリーダーシップの発揮方法について尋ねた。メンバとコミュニケーションをとり、目標・方針を共有することでチームをまとめるという回答を期待しており、精神論や豪腕を排除するものである。

それ以外にB社製品の設計能力に関して、B社製品での開発経験の詳細をヒアリングすることで設計経験まであるか、リーダ経験に関してリーダとしての職務内容を聞くことで箔を付けるための名目上のリーダ経験ではなかったか、弊社開発標準への理解に関して弊社での実績がある場合の成果物など、書類のみでは判断できない点を確認した。

一方で過去の担当者ともヒアリングし、候補者の話と整合性が取れていることを念のために確認した。

2.2.2 選考結果

選考の結果、C氏を適任と判断した。C氏はリーダーシップ・コミュニケーション能力についての質問で期待に沿った回答をしたのみならず、ドキュメント表現力が、以前の担当者から高く評価されており、チームメンバに開発方針の明示と周知徹底をもたらすことが期待できた点があげられる。

また、チーム内の特殊事情として、親しい人には饒舌であるが、そうでない人の前では借りてきた猫のように大人しくなってしまうメンバがいるが、C氏は弊社での実績が長く、弊社に溶け込んでおり、一緒に仕事したメンバもいる点で問題ないと判断した。

加えてC氏は弊社が受託した小売業D社のEAIシステム開発案件にサブリーダとして参画した経験がある。チームリーダ経験はないものの、上記D社案件では他チームとの兼任リーダの下、事実上リーダの職務の少なからぬ部分を担当しており、リーダを任せられると判断した。

3.評価と改善(設問ウ)

3.1評価

本プロジェクトは納期内に所定工数で完了した。C氏がD社案件での経験をもとに、弊社開発手法・標準に基づいたB社製品の開発テンプレートを早期に作成し、メンバに説明したため、メンバもそれを利用して容易に開発を進めることができた。

手続的にも今回の採用は、複数人で評価している上、候補者の過去の担当者とヒアリングするなど、社内の情報共有システムを十分に活用できた点で、模範的事例と言っても良いと自負している。

今回のリーダ採用は成功を収めたと評価している。

3.2改善

今回の採用ではリーダ経験・B社製品の設計経験については、なるべく書類選考で判断するつもりであった。しかし協力会社への提案依頼時に書式を指定しなかったため、一般的な職歴を記述しただけのものが多かった。そのため、書類選考において十分な判断ができず、面接において改めて確認することもあった。

書類選考と比べると、面接はスケジュール調整もあり、時間もとられるため、書類選考で確認できるものはそうすることが効率的である。今後は書類を求める際に記述してほしいポイントを明確化して伝えることで、書類選考を充実したものにしていきたい。

Other

A社取引システムは最近、ホスト系からオープン(GUI)系の分散システムに移行されたばかりである。ホスト系資産はメーカに依存した技術基盤であったが、分散系システムはTCP/IPを通信基盤としたオープン系プロトコルを採用している。証券取引システムはIPSECに基づいたVPN回線により、各支店の端末と接続する。

しかし今回のプロジェクトは急遽持ち上がったプロジェクトである。繁忙期でもあり、ベテランSEをアサインすることができなかった。特にB社製品開発経験のあるリーダクラスの人材が不足していた。そのため、私は上司にプロジェクトを辞退することを勧めたが、上司は顧客との関係を重視して、私に依頼した。そこで、若手を中心としたチーム編成にせざるを得なかった。私の下にそれぞれ数人で構成される基盤チームとEAIチームを編成した。基盤チームは運用管理担当者およびネットワーク担当者からなる。

古典的な品質管理においてはテストやレビューが想起される傾向にある。開発担当者の中には全メンバでレビューを行ったことにより、全メンバの成果物になり、開発担当個人の責任は解消されるという、｢みんなで決めれば怖くない｣的な身勝手な発想を持つ開発担当者までいる。しかしテストやレビューはあくまで検証活動に過ぎない。品質は上流工程から作りこむべきものであり、設計書の段階から品質は始まる。従って設計能力は不可欠であり、社外からB社製品経験者をリーダに採用することにした。

しかも開発中は裏の日報を持っていて、問い詰めて初めて遅延が発覚したというケースもあった。そのためインフォーマルなコミュニケーションも結構重要になる

2.1.1弊社の協力会社選定基準

弊社は定常的に協力会社と取引を行っているが、ここ数年間の間で、プロジェクトの小規模化・技術の多様化が進んだ事から、協力会社の数は100を超えている。この中から、最適な協力会社と候補を見つけ出す事は難しい。一方で、プロジェクトに必要なスキルとのアンマッチが発生した場合、プロジェクトに与える影響は大きい。

そのため、弊社では昨年より協力会社管理基準を明文化し、かつ、協力会社データベースを構築し、過去5年間の取引を登録している。

協力会社管理基準については、マネージャ層には本基準を解説する研修受講が義務付けられ、内容の周知徹底が図られている。まず協力会社は弊社との間に取引口座を有している企業から選択する。これにより、弊社での実績があり、財務状況も問題ない企業であることが担保される。条件を満たす複数の協力会社に提案書と見積書の提出を依頼し、それをもとに候補者を絞りこみ、面接を行う。面接の評価は文書化して上司に提出し、上司の承認の下、決定する。

協力会社データベースには、協力会社利用結果の登録が義務付けられており、選考に際しては他部署での実績も参考にできる。加えてデータベースからは、当時の担当部署・担当者を辿ることもできるので、ヒアリングを行うことも可能である。

本プロジェクトにおいても採用手続きは本基準に則って行った。

社内の協力会社管理基準は社内実績に重きを置いたものである。そのため、実績ある候補の中に望まれる候補が存在する場合はうまくいくが、そうでない場合、例えば新しい分野に取り組む場合などは該当者がいないということもありうる。本件でも、弊社の開発実績がそれほど多くはないB社製品経験者を条件としたため、最初から候補者が限定された面がある。

競争激化の中で調達候補を既存の取引関係以外に拡張し、柔軟に新規の優良取引先を発掘していくことが求められると一般に言われている。また、技術の進歩は著しく、従来の実績では図り難いスキルが求められる案件も益々増加するものと予想される。今後は弊社との取引が少ない、又は取引がない企業についても信頼性のある評価ができるシステムが求められると考える。