implementation は「契約や計画の実行、実施、履行」。
情報システムやソフトウェアの場合、implementation は、要求分析段階に得られた発注者や顧客の要求仕様と、その実現手段を決めた設計仕様に基づいて、それを満たすように、プログラミング言語を用いて各々の詳細なプログラムを作成し、その作成したプログラムを稼働する予定のコンピュータと装置を導入したシステム構成の上で、機能的に正しく作動させることを意味する。
設計段階では、design specifications 「設計仕様書」を作成する。
また、これ以降の開発のproject management を計画する。
プロジェクトマネジメント（英語: project management、プロジェクト管理）とは、プロジェクトを成功に導くための総合的な管理手法のことで、スケジュール、人員、資金、物的資源などの管理を含む[1]。
プロジェクトとは
プロジェクトマネジメント協会(PMI)のPMBOKガイドでは、プロジェクトとは「独自のプロダクト、サービス、所産を創造するために実施される有期性の業務である」と定義する。
またNASA (米航空宇宙局)は「相互に関連するタスクから構成され、多くの組織が参画して実施される3年以下程度の期間の活動」と定義する[2]。
プロジェクト活動には以下の特徴がある
- 明確に定義された目標
- 必ず開始時点と終了時点がある
- 永続的でない一時的な組織が担当する
- 1人のリーダ（プロジェクトマネジャー）と複数のメンバーから構成される
- 目的達成のための予算が与えられる
- いくつかの工程から成り立つ
- ライフサイクルの各段階で必要資源が変化する
- 予期できない事態が発生することがある
- 後工程ほど変更・修正の困難度が増す
- 期限内に
- 予算金額内で
- 期待レベルの技術成果のもと
- 割り当て資源を有効活用して
- 顧客が満足する状態で完了する
プロジェクトマネジメントに含まれる活動
- 企画
- リスク測定
- 利用できる資源の見積り
- 作業の系統化 WBS (Work Breakdown Structure)の作成
- 必要な人的・物的資源の確保
- 費用の見積
- チームメンバーへの作業の割り振り
- 進捗管理
- 目的に沿った結果が出るように作業の方向性を維持する
- 達成した結果の分析
プロセス群（プロジェクトライフサイクル）
プロジェクトマネジメントでは計画 (Plan)、実行 (Do)、チェック/評価 (Check)、改善/是正 (Act)という管理サイクル（PDCAサイクル）が常に稼動している必要がある。また開始時には立ち上げプロセスが、終了時には報告書をまとめるプロセスが必要になる。立ち上げ、計画、実行、監視、終結の５つのフェーズをプロジェクトライフサイクルとして管理する。[3][4] 明確な探索要素（研究開発など）があるプロジェクト環境においては、各ステージにおいてプロジェクトの継続可否が議論され決定される判断ポイントが追加される場合がある（例えば、フェーズゲート）。
立ち上げのプロセスでは、プロジェクトの性質と範囲を決定する[5]。この段階がうまくいかない場合、プロジェクトが要求を満たし成功する可能性は低い。ここでは、プロジェクトの周辺環境を理解すること及び必要なすべての管理項目がプロジェクトに組み込まれていることを確認することが重要である。不備があれば報告し、修正案を作成する。
- プロジェクト存在の認識
- プロジェクトが達成すべき事柄の認識
- ゴールの設定
- 利害関係者の期待の明確化
- プロジェクトスコープの明確化
- プロジェクトメンバーの選定
立ち上げ段階では、今後のプロジェクトの領域を包括した計画を作成する。これらの領域は、プロジェクト開始文書と呼ばれる一連の文書としてまとめてもよい。プロジェクト開始文書には次に代表される要素が含まれ、プロジェクト期間中のリソース配分や優先順位を明らかにするために使用される。
- プロジェクト提案書：プロジェクトの背景、全体目標、期間
- プロジェクトのスコープ：プロジェクトの方向と道筋
- PBS (Product Breakdown Structure, 製品の内部構造)：成果物もしくは結果の階層とその構成要素
- WBS (Work Breakdown Structure, 作業分解構造)：日々の作業にまで分解された実行されるべき作業の階層構造
- RACI図：成果物/結果に合わせた役割分担と責任
- 暫定プロジェクトスケジュール：マイルストーン、節目となる重要な日付、期限
- 計測可能な目標に対するビジネスニーズと要件の分析
- 現在のオペレーションのレビュー
- 予算を含む費用と利益の財務分析
- プロジェクトのユーザーとサポート担当者を含む利害関係者の分析
- コスト、タスク、成果物、スケジュールを含むプロジェクト憲章
- SWOT分析
開始段階の後、プロジェクトを適切なレベルに詳細化する。主な目的は、時間、コスト、リソースを適切に計画し必要な作業を見積もり、プロジェクトの実行中、効果的にリスク管理を行うことである。開始プロセス群と同様、十分な計画を怠ると、プロジェクトが目標を達成する可能性が大幅に減少する。 計画段階の一般的実施事項は次の通り[6]。
- プロジェクトが従べき管理の方法論の決定（例：計画を[ウォーターフォール・モデル|事前に完全に定義]するか、もしくは反復的にまたは定期的に再定義するかどうか）
- スコープステートメントの作成
- 計画策定チームの選択
- 成果物の特定とPBS及びWBSの作成
- 成果物の完成に必要な作業の特定と、個々の作業の実行順序及び関係を示すネットワーク図の作成
- 作業に必要なリソースの要件の見積もり
- 作業時間と費用の見積もり。
- スケジュール作成
- 予算編成
- リスクの見積もり
- 品質マネジメントの計画
- 作業開始の正式な承認
また、コミュニケーションやスコープ管理のための計画、役割と責任の特定、プロジェクトのために何を購入するかの決定、キックオフミーティングの開催などのプロセスを追加することも一般的に推奨される。 製品開発プロジェクトの場合、最終製品の動作の概念的デザインは、プロジェクトの計画活動と並行して行われることがあるが、成果物や作業計画を決定する際に計画を策定するチーム内で共有しておくと良い。
実行中は、実施されるべき計画が何であるかを常に意識していなければならない。実行/実施の段階において、プロジェクト管理計画で規定された実施内容を確実に実行する。この段階には、人的資源および材料や予算などその他のリソースの、適切な割り当て、調整と管理が含まれる。この段階のアウトプットはプロジェクトの成果物である。
- チームの統率
- メンバーとの面接
- 利害関係者とのコミュニケーション
- 問題を解決する闘争心
- 必要な資源（カネ、ヒト、モノ、時間等）の確保
design「設計」とは、「方式やシステムなどを計画、準備し、そのすべての詳細を決めること」
情報システムやソフトウェアの開発では、systems design 「システム設計」は、前段階で作成された要求仕様を満たすように、システム構成、採用する具体的な装置、ファイルやデータベース、アルゴリズムや処理手順、利用するソフトウェア、入出力方法等の実現手段を決定する。
「アルゴリズム」というのは、コンピューターで計算を行うときの「計算方法」のことなんですが、広く考えれば、何か物事を行うときの「やり方」のことだと言っていいでしょう。その「やり方」を工夫して、より良いやり方を見つけよう、というのが、アルゴリズムの研究です。同じ計算を行うんだったら、いい方法でやればより速く計算できますね、ということです。
例えば、簡単な例。にんじんが星型の輪切りになっているもの、あれを、にんじん一本から30個作る方法を考えましょう。1例目として、まず、
・ 輪切りをたくさん作ってから、それぞれの角を落として星型にする方法
というのが考えられます。これだと、包丁を入れる回数は、輪切りを作るのに31回（端っこを落とすのに2回使ってます）、それぞれを星型にするのに、10回、包丁を入れるので、合計 31+10*30 = 331 回、包丁を入れます。結構大変ですね。でも、ちょっと工夫をすると、
・まず、にんじん本体を星型に切って（断面が星型の棒になります）それから輪切りにする
という方法を考えると、
これは、本体を星型にするのに10回、輪切りにするのに31回なので、なんと包丁を入れる回数は 41 回に減ります。にんじん本体を星型に切るのは、輪切りにするほど速くはできないとは思いますが、3倍ぐらいのスピードにはなるでしょう。まあ、あたりまえのアイディアなんですけど、これはすごいですね。331回から 41回ですから。同じ星型の輪切りを作るのに、ちょっとやり方を変えただけでこの違い。やり方かえるだけで作業効率が3倍違うんですから、がんばって修行して包丁さばきのスピードをあげる前に、「やり方」の工夫を考えたほうがよさそうです。
キャベツの千切りなんかでも、葉っぱを一枚一枚千切りにするより、10枚くらい重ねてやったほうが、10倍スピードが速くなりますよね。こういった工夫がなかったら、とんかつ屋さんで山盛りキャベツを食べる、なんて楽しみは味わえなかったでしょう。
この「やり方の工夫」というのは、包丁さばきだけに限ったことではありません。コンピューターの計算方法にもあります。簡単な例は、辞書の単語の検索です。コンピューターのディスクに辞書のデータがあって、この中から、指定した単語を探し出す、よくある検索の問題ですね。さて、じゃあ、辞書から「アルゴリズム」という単語を見つけましょう、という問題を考えます。どうやってみつければいいでしょう？ まず思いつく簡単な方法は、
・辞書を頭から調べて、一つ一つの単語と「アルゴリズム」を比較する。一致したら「見つけた」
という方法。広辞苑第5版の項目数は約23万だそうですが、「アルゴリズム」はあ行ですから、この方法でやってもたぶん5000回くらいの項目と比較すれば見つかりそうですね。ですが、もっと後ろに載っている言葉ならば、もっと時間がかかるでしょう。ちなみに広辞苑第5版の最後の言葉は「んとす」（終りな－、という意味だそうです）ですので、この言葉を捜すときには約23万回比較するわけです。最近のパソコンは、だいたい1秒間に1000万回くらい計算ができます（だいぶいいかげんな表現ですが）。ですので、この23万回というのはそんなに莫大な数ではありません。普通にプログラムを組めば、1/50秒くらいで計算が終わるでしょう。この方法なら、プログラムを組むのも簡単だし、めでたしめでたしですね、といいたいところですが、さて、皆さんが辞書を引くときに、こんな方法を使うでしょうか？ 普通、辞書というものはあいうえお順でソートされているので、たぶん、こんな方法を使っていると思います。
(1) だいたい真中をえいや、と開く
(2) 調べたい単語がそこより前あれば、そこより前の部分の、後ろにあれば後ろの部分のだいたい半分を、またえいや、と開く
(3) 調べたい単語が見つかるまで、(2) を繰り返して、範囲を小さくして行く。
実際は、辞書には「あかさたな列」の見出しがついているので、最初の１文字で大体のあたりをつけて、その周辺を探すという方法をとっていると人が多いと思いますが、あたりをつけ終わった後、いよいよ探す範囲が狭くなると、こんな方法を使っていると思います。こういう方法を使えば、全部の単語を調べる必要なんてないんですよね。（この方法は、学術的には「2分探索」と呼ばれています）
コンピューターでも、プログラムの設計を変えれば、こういう方法で単語を検索できます。一回、真中を開くと、調べる範囲が半分に減るので、真中を開く回数は、単語数を n とすると、log2 n 回になります( log を知らない人は、気にしないで先を読んでください）。広辞苑の23万単語の場合は、18回、真中をえいや、と開けば、調べたい単語が出てきます。このスピードの違いはすごいですね。かたや 23万回の計算、それに比べて、かたや 18 回。1万倍くらい違います。
そうすると、今一週間かかる計算が、ひょっとしたら、アルゴリズムを工夫しただけで、1分で解けるようになるかもしれません。最近のスーパーコンピューターを1億円くらいで買っても、パソコンの1万倍くらいしか速くなりませんから、なにかしらの計算の工夫でスーパーコンピューターを買うのと同じ効果が得られるかもしれないのです。全ての計算が速くなるわけではないですが、工夫すれば、早くなる可能性はあるわけです。
このように、いろいろな計算が（プログラムの書き方を変えただけで）どこまで高速に計算できるのか、また、高速に計算できる場合は、どんな性質を満たすのか、同じような計算でも、計算速度が大幅に異なってしまうのはなぜなのか、理論的に算定した計算時間と、実際に実験してみた計算時間がどの程度違うのか、そんなことを研究するのが、アルゴリズムの研究なのです。
要求には2種類ある。
第一には、開発対象システムに、発注者、顧客、ユーザが、機能として、何をさせることを望んでいるかと言うfunctional requirements 「機能要求」。
第二には、性能要求(システムへの負荷、1時に活きている端末の台数、応答時間他)、開発コストや運用コスト、開発のデッドラインなどからなるnon-functional requirements 「非機能要求」。
requirements engineering 「要求工学」は、「要求の獲得、仕様化に関係する科学と技術の分野」のこと。
非機能要件とは
非機能要件とは、その名の通り「機能以外の全ての要件」のことです。
機能要件が「システム構築にあたり、顧客が必要とする機能の要件」であるのに対し、非機能要件は「必要とする機能以外の要件」を指します。例えば、性能や可用性、セキュリティなどが上げられます。
構築したシステムが顧客の希望する機能全てを実装していたとしても、処理性能があまりに悪かったり、障害から復旧するのに時間がかかったりするようでは、運用に耐えられません。そのため、これらについても要件をきちんと定義することが大切です。
顧客によっては、実装する機能の要件にばかり時間を費やしてしまい、非機能要件が決められないまま進めてしまったがばかりに、十分な性能が発揮されないシステムが出来上がることも少なくありません。非機能要件は機能要件と同じくらい大事であると考えましょう。
非機能要件で定義すべき項目
非機能要件で定義すべき項目は多岐にわたるため、「FURPS+」や「JIS X25010：2013(ISO/IEC 25010：2011)」など、整理されているものを参考にするとよいでしょう。
ここでは、IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」をご紹介します。非機能要求グレードでは、6つの項目に分類しています。
①可用性
可用性は、システムを継続利用するための要件です。機器の冗長化や運用スケジュール、障害時の復旧方法などを定義します。
②性能・拡張性
システムの処理性能および拡張に関する要件です。構築するシステムで処理するトランザクション数や利用ユーザー数、負荷などを決めます。また、将来のキャパシティ・プランニングを検討します。
③運用・保守性
システムの運用・保守に関する要件です。システムの監視方法やバックアップ方法、問題発生時の体制などを決めておきます。
④移行性
現行システムからの移行に関する要件です。新システムへ移行するための移行期間、移行体制、移行リハーサルなど、移行計画についての要件を定義します。
⑤セキュリティ
システムのセキュリティ確保について定義します。アクセス制限や不正検知・監視の方法、システム運用者に対する情報セキュリティ教育について定義します。
⑥環境・エコロジー
システムを設置する環境・エコロジーに関する要件を定義します。環境負荷を低減する構成や、電気設備・規格の適合性について定義します。
非機能要件を定義するには
それでは、非機能要件を定義するための具体的な流れについて解説します。
機能要件を決めておく
非機能要件を決める前に、機能要件を決めておきましょう。なぜなら、実装する機能によって非機能要件が変わる場合があるからです。
また、機能要件を決める場合は、顧客がシステムに求める要件の背景や目的が明確になります。非機能要件も、それらを加味して考えることが必要です。
非機能要件を定義する手順
ここでは、具体的に非機能要件を定義するための手順について解説します。
手順1. システムの方向性を確認
対象システムがどのような方向性のものであるかによって、非機能要件も大きく変わります。例えば、基幹システムのような企業にとって極めて重要なシステムであれば、性能や可用性は高いものが求められます。逆に小規模で影響の小さいシステムであれば、ある程度許容された要件となります。
手順2. 非機能要件の草案を作成
IPAの非機能要求グレードでは、各項目について推奨される要求レベルが定義されており、顧客要望に併せて推奨値を調整することで、非機能要件がまとめられるようになっています。これらを参考にし、非機能要件の草案を作成していきます。作成したら、それが実現可能である内容であることを確認しておきましょう。
【非機能要求グレード2018 システム基盤の日機能要求に関する項目一覧】
※引用:IPA「システム構築の上流工程強化（非機能要求グレード）」
手順3. 非機能要件の推奨案を提示、顧客と合意を得る
システムや顧客要件に合わせて推奨値を決めたら、草案を顧客に提示・説明して合意を得ます。草案を提示することで、初めて顧客から細かい要件が出る場合もあるでしょう。それらを盛り込みながら要件を少しずつ定義していきます。顧客から出された要件は、その理由についても確認しましょう。代替案を提示するために必要です。
非機能要件を決めたら、その内容を要件定義書に記載します。要件定義書を元に設計が行われるため、要件定義書は誰が見てもわかるように曖昧な文言は避けましょう。また、図示化しておくのも有効です。
非機能要件の定義をスムーズに進めるために
非機能要件を定義するのに、機能要件とは異なるアプローチを取る場合があります。ここでは、機能要件との違いを元に、非機能要件をスムーズに定義するためのポイントを解説します。
顧客からは非機能要件が出てこない
顧客から非機能要件について出てくることは、なかなかありません。機能要件については話が出ることはあっても、可用性やセキュリティなど細かい点について、顧客が意識して要件をまとめているケースは少ないと考えたほうがよいでしょう。顧客が他のシステムも持っている場合は、それと同様と考えている場合もあります。
そのため、開発側から決めるべき非機能要件をまとめておき、顧客に対して提案することで顧客の意識を向けることができ、スムーズに進められます。
提案は比較できるようにしておく
非機能要件を決めるのに、最終決定権は顧客にあることを忘れてはいけません。開発側から提案するにしても、顧客が最終決定するための材料もあわせて提示できなければ、顧客は決断することができません。
可用性やセキュリティなどの項目について、いくつかの案とともにメリット・デメリットを提示します。ここは、システムの専門家としての腕の見せ所です。顧客とコミュニケーションを取りながら、顧客からの期待以上の案を提案できれば、満足度を高められます。
その他の非機能要件も考えておく
IPAの非機能要求グレードに記載されている項目以外にも、考慮すべき非機能要件はあります。例えば操作性（ユーザビリティ）が上げられます。利用ユーザーを想定した操作性にしなければ、あまりに使い勝手の悪いシステムになる可能性があります。
画面の見た目など操作性の基準となるものを作ってまとめておくと、操作性の高いシステムを構築できます。
まとめ
本記事では、非機能要件について解説しました。非機能要件は、顧客に意識されにくい部分ではありますが、機能要件と同じくらい重要です。
機能要件は顧客からヒアリングして定義していきますが、非機能要件は事前に項目や決めるべき内容を開発側から提示して、顧客に判断してもらうという点でアプローチが異なります。
要件定義の工程で機能要件・非機能要件を細かく決め、顧客と合意を取っておけば、満足度の高いシステムを構築できます。
要求を分析して得られる文書のことをrequirements specifications 「要求仕様書」と呼ぶ。
要求分析では、発注者、顧客、ユーザの要求を正確に理解し、正確で曖昧さのない要求仕様を作成することが望まれる。
要求仕様は、後続の設計や実装の時に、開発中のシステムが、要求にあった正当な機能と妥当な性能を持つかどうかを決めるための基準となる。
例文例文
Difference in specification例文帳に追加
仕様違い - Weblio Email例文集
a functional specification発音を聞く 例文帳に追加
機能仕様 - 研究社 英和コンピューター用語辞典
