取得プロセスとは何か？

2019年10月27日2022年10月26日

取得とは

ITプロジェクトにおける取得とは、JIS X 0160:2012の定義に従うと、「システム、ソフトウェア製品又はソフトウェアサービスを得るためのプロセス^[1]JIS X 0160:2012 ソフトウェアライフサイクルプロセス、４頁。 」を意味しています。
動詞として「取得する」と使う場合は、「システム・ソフトウェア製品、ソフトウェアサービスを得ること」と捉えても大過ないでしょう。

プロセスとしての取得

プロセスとしての取得はプロジェクトを構成するプロセスの１つであり、顧客のニーズを認識することから始まり、取得者が必要とするシステム、ソフトウェア製品又はソフトウェアサービスを受入れたところでこのプロセスが終了します^[2]JIS X 0160:2012 ソフトウェアライフサイクルプロセス 、20頁。。
この取得はプロジェクトを完遂させるための１つの工程というよりかは、プロジェクトを通じて影響を及ぼすものです。
そのため、プロジェクト・マネジャーや取得者は定期的にこのプロセスの進捗を確認し、 必要となるアクティビティ及びタスクが完了しているかチェックするとよいでしょう。

取得の成果

なぜこの取得のプロセスは必要なのでしょうか。
JIS X 0160:2012はこの取得のプロセスを完了することで、 プロジェクトが以下のような状態になるとしています ^[3]JIS X 0160:2012 ソフトウェアライフサイクルプロセス 、20～21頁。 。

• 取得ニーズ、目標、製品及び／又はサービスの受入れ基準並びに取得戦略が定義されている
• 取得者及び供給者両者の期待、責任及び義務を明確に表した合意書が作成されている
• 一つ以上の供給者が選定されている
• 取得者が記述したニーズを満たす製品及び／又はサービスが取得されている
• コスト、スケジュール、品質などの指定された制約が満たされるように、取得が監視されている
• 供給者の納入品が受け入れられている
• 識別された未決定事項については、取得者及び供給者が合意した満足な結論が得られている

JIS X 0160:2012では形式ばった表現をしているため、簡単に言い換えると、以下のような事項が取得のプロセスを通じて明らかになると言えるでしょう。

• ニーズに基づいて、どのように取得のプロセスを進めていくか
• 実際に依頼をかけた供給者との間でどのような合意書を作成するか
• どのような供給者を選ぶか
• 当初のニーズ通りの製品・サービスが得られるか
• その製品・サービスのコスト・スケジュール・品質をどのように監視していくか
• どのように供給者から製品・サービスを納入してもらうか
• 未決定事項をうやむやにせず、取得者・供給者の間でどのように合意を得るのか

こうした取得プロセスの成果はプロジェクトの成功を下支えするものであり、プロジェクトの初期で行う重要な意思決定の１つであると言えます。
たとえば取得戦略があいまいだと、「なんとなく担当者が話しやすい雰囲気だったから」という感覚的な理由で供給者を選んでしまったり、「価格が安かったから」という一面的な指標で選択してしまったりすることになります。
その結果、供給業者がニーズを満たせず、プロジェクトが失敗に終わってしまいます。
このような失敗に陥らないために、取得プロセスの内容を把握しておく必要があります。

取得のアクティビティとタスク

では、上述の成果はどのようにして得られるのか、取得プロセスのアクティビティとそのタスクを見ていきましょう。
JIS X 0160:2012では取得プロセスのアクティビティとして、以下７つのアクティビティを定義しています^[4]JIS X 0160:2012 ソフトウェアライフサイクルプロセス 、21～24頁。 。

• 取得の準備
• 取得の通知
• 供給者の選定
• 契約の合意
• 合意の監視
• 取得者の受入れ
• 取得プロセスの終了

以下、各アクティビティの内容とタスクを見ていきましょう。

取得の準備

取得の準備は、その名の通り取得プロセスを始めていくアクティビティを指しています。取得プロセスの中で最もタスクの多いアクティビティであり、はじめの準備が何よりも大切であることを物語っています。
JIS X 0160:2012の内容をまとめた共通フレームによると、取得の準備のタスクは以下のようにまとめられています^[5]共通フレーム2013、92～94頁。

• 構想又はニーズの記述
• システム要件、ソフトウェア要件の定義と分析
• システム要件、ソフトウェア要件の定義と分析の委託
• システム要件、ソフトウェア要件の承認権限
• テクニカルプロセスの使用
• 選択肢の検討
• 取得条件の確認
• 取得計画の作成と実行
• 受入れ戦略及び条件の定義
• 要件の文書化
• 対象プロセスの決定とテーラリング（修整）
• レビュー及び監査実施時期の設定
• 要件の提示

以下、さらに各タスクの中身を見ていきましょう。

構想又はニーズの記述

構想又はニーズの記述のタスクでは、組織内のニーズをヒアリングし、文書化していきます。 JIS X 0160:2012では「システム、ソフトウェア製品又はソフトウェアサービスを取得、開発又は強化するための構想又はニーズを記述する ^[6]JIS X 0160:2012 ソフトウェアライフサイクルプロセス 、21頁。 」としています。
実際にプロジェクトを開始する上で組織に「何が必要なのか」をまとめる重要な作業です。

システム要件、ソフトウェア要件の定義と分析

システム要件、ソフトウェア要件の定義と分析では、必要とされるシステム・ソフトウェアの要件を定義し、分析していきます。
JIS X 0160:2012では「関連する設計、テスト、適合標準及び手順と一緒に、事業、組織及び利用者の要求事項に加えて、安全性、セキュリティ及び他の重大要求事項を含むことが望ましい ^[7]JIS X 0160:2012 ソフトウェアライフサイクルプロセス 、21頁。 」としています。
より簡単な言葉に言い換えれば、 システム要件、ソフトウェア要件の定義と分析は以下の事項を考えるタスクであると言えるでしょう。

• 求めるシステム・ソフトウェアをどのように設計するか
• どのようにテストを行うか
• どのような規格・標準に沿ってプロジェクトを進めるか^[8]この項目について、JIS X 0160:2012では「適合標準及び手順」としており、 JIS X … Continue reading
• どのようなセキュリティ対策を行うのか

これらの項目を明確にし、要件定義書を作成することがこのタスクのゴールです。

システム要件、ソフトウェア要件の定義と分析の委託

上記のような要件定義の策定は、システムやソフトウェアに関する十分な知識が必要になります。そのため、システム要件、ソフトウェア要件の定義と分析を外部に委託するかどうかを考えることも必要です。
その判断を行うのがシステム要件、ソフトウェア要件の定義と分析の委託のタスクです。これは企画プロセスや要件定義プロセスにも影響する意思決定でもあります。

システム要件、ソフトウェア要件の承認権限

システム要件、ソフトウェア要件の承認権限はタスクと言うより確認事項に近い内容です。
たとえ要件の分析や要件定義の策定を外部の供給者に委託したとしても、最終的にその内容を承認するかどうかは取得者側であることを確認するタスクです。

テクニカルプロセスの使用

要件定義が終わり、実際に開発に入るテクニカルプロセスを実行します。
要件定義が不十分であれば、要件定義プロセスをテクニカルプロセスに先んじて進めてもよいでしょう。

選択肢の検討

選択肢の検討では、目的のシステム・ソフトウェアをどのように取得するのかを検討していきます。

取得条件の確認

取得条件の確認では上述の選択肢の検討で「要件を満たす市販のシステム・ソフトウェア製品又はサービスを購入する。」を選択した時に考慮すべき条件です。
共通フレームでは、以下のような条件を示しています^[9]共通フレーム、93頁。。

• そのシステム、ソフトウェア製品又はサービスに対する要件が満たされている
• 必要な文書が入手できる
• 専有権、使用権、所有権、保証及びライセンス付与権が満たされている
• そのシステム、ソフトウェア製品又はサービスに対する今後の支援が計画されている

市販の製品・サービスの購入を検討する際は、システム要件を満たしていることだけでなく、必要に応じて仕様書などの文書が入手可能かどうか、権利関係がどのようになっているのかまで確認しておく必要があります。
とくにソフトウェア製品であると、最近ではWebサイト上から購入することが可能である場合もありますが、今後の支援が計画されていない製品を導入してしまうと、不具合が発生した際の対応が遅れ、大きな問題につながってしまうこともあります。
また、近年では環境負荷を考慮したグリーン調達を行うこともあります^[10]共通フレーム、95頁。。

取得計画の作成と実行

目的とするシステム・ソフトウェア製品を市販のもので賄うにせよ開発するにせよ、取得者は取得計画を策定し、文書化した後に、その内容を実行していくことが望ましいとされています^[11]共通フレーム、93頁。。

受入れ戦略及び条件の定義

システム・ソフトウェア製品の取得が現実的となってきたら、取得者は受入れ戦略と受入れの条件・基準を定義し、文書化しておく必要があります。