システム開発プロジェクトにおける非機能要件に関する関係部門との連携について
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2018h30_1/2018h30h_pm_pm2_qs.pdf
見出し
第1章 プロジェクトの特徴、非機能要件の概要と関係部門と連携を図る際の注意点
1-1 プロジェクトの特徴
1-2 非機能要件の概要と関係部門と連携を図る際の注意点
第2章 関係部門と十分な連携を図るために検討して実施した取組みについての主なタスクの内容と関係部門、及び関係部門の役割
2-1 主なタスクの内容
2-2 関係部門、及び関係部門の役割
第3章 実施結果の評価、及び今後の改善点
3-1 実施結果の評価
3-2 今後の改善点
本文
第1章 プロジェクトの特徴、非機能要件の概要と関係部門と連携を図る際の注意点
1-1 プロジェクトの特徴
私は関西でソフトウェア開発を主な業務として行う、システム開発会社A社で働くITエンジニアである。今回、A社は大手自動車メーカT社からカーナビゲーションシステム開発の案件を受注した。私はこのプロジェクトのプロジェクトマネージャに選ばれた。私がT社から受注したプロジェクトのプロジェクトマネージャを担当するのは今回で3回目となる。開発期間は2015年4月1日から翌年3月31日までの12ヶ月間。開発規模は200人月となる。
今回のプロジェクトの特徴としては、T社から非機能要件として高い可用性が求められていることが特徴となる。
1-2 非機能要件の概要と関係部門と連携を図る際の注意点
カーナビゲーションシステムでは、システムの不具合が思わぬ事故に繋がり、ユーザの命に関わることがある。そうした理由から、今回のプロジェクトでは非機能要件として高い可用性を求められている。具体的には、システムの強制終了やフリーズは何があっても避けなければいけない。システムの機能を一時的に縮小してでも、動き続けることが求められる。
A社では開発を行う開発部門と、システムテストを行うテスト部門が別れており、通常のプロジェクトでは深い連携を意識することなく作業を分担している。今回のプロジェクトで重要なのは開発部門とテスト部門が一丸となって、高い可用性を実現することが大事だ。今のままでは目標達成に向けて、十分な連携を図ることが出来ないと私は考えた。
（671文字）
第2章 関係部門と十分な連携を図るために検討して実施した取組みについての主なタスクの内容と関係部門、及び関係部門の役割
2-1 関係部門と十分な連携を図るために検討して実施した取組みについての主なタスクの内容と関係部門
私は開発部門とテスト部門の間で十分な連携を図るために、対策を検討し、実施することにした。なぜならば、プロジェクトに関連する部門が一丸とならなければ、T社の求める高い可用性を実現することは困難だと考えたからだ。具体的には外部設計、内部設計は開発部門、テスト部門それぞれのメンバを集め、ウォークスルーによるレビューを行った上で完了とすることを検討した。
レビューについて開発部門、テスト部門へ周知を行い、理解を得られたので、ウォークスルーによるレビューを実施することとした。
2-2 関係部門の役割
A社の通常のプロジェクトでは外部設計から単体テストまでが開発部門、結合テストやシステムテストはテスト部門の担当となる。テスト部門は開発部門が作成した外部設計書、内部設計書からテスト項目を作成するが、外部設計書、内部設計書に書かれた内容の裏に隠れる意図を読み取るのは難しい。今回のプロジェクトでは開発部門が作成する外部設計書、内部設計書の裏に隠れた意図をテスト部門と共有するためにウォークスルーを実施する。具体的には、定期的に処理を行うタイマー処理の設定値が10秒となっている場合、なぜ10秒という数値なのかという内容となる。数値には必ず元となる理由がある。元となる理由がテスト部門に伝われば、試験項目の作成もより正確な試験項目となる。また、レビューをウォークスルー形式としたのは、テスト部門から意見を積極的に出させて、上流工程で一定のの品質を確保するためでもある。上流工程で品質を確保することにより、T社が求める非機能要件である高い可用性を得ることに繋がる。
以上のことから、開発部門とテスト部門の役割は外部設計、内部設計完了時点での仕様の共有と、上流工程での品質確保となる。
（854字）
第3章 実施結果の評価、及び今後の改善点
3-1 実施結果の評価
2016年3月末、私はプロジェクトを無事に終えることが出来た。T社から求められていた高い可用性についても、T社から高い評価を得ることが出来た。これは、今までは連携を意識することなくプロジェクトを進めていた、開発部門とテスト部門が一丸となって目標達成に向けて進んできた結果だ。
従来のプロジェクトではシステムの強制終了や、フリーズしてしまう減少が少なからず発生してしまい、納期ギリギリになって慌てる場面も多かったが、今回は上流工程で品質を高めたため、そのような現象も発生しなかった。結果として、従来のプロジェクトと比較して80%コストを抑えることにも繋がった。これにより、私はA社の役員からも高い評価を得られた。
3-2 今後の改善点
開発部門とテスト部門の強い連携を意識してプロジェクトを進めたのは、あくまでこのプロジェクト内だけの話である。今後の改善点としては、A社全体で同様の取り組みを行うことで、ソフトウェアの品質を高めることが出来ると私は考えた。なぜならば、今回のプロジェクトは従来のプロジェクトに比べてバグの件数が50%少なかったからだ。具体的には、A社全体で取り組むため、私はA社の開発標準に追加するのが良いと考えた。開発標準に追加するには、役員会議で承認を得る必要がある。私は開発部門とテスト部門で連携して進めた今回のプロジェクトの内容を整理し、役員会議にかけるべく準備を行った。
以上
（637文字）
書いてみた感想
はじめは何を書いていいかわからなかったが、可用性 = 品質と思い至ってからはスラスラ書けた。
やっぱり実際の業務に繋がる内容は書きやすい。カーナビで強制終了とかフリーズすると事故ってユーザの死に繋がる可能性があるという話のネタは色々応用が効きそう。
あと、今回から自分の会社をA社、大手自動車メーカをT社とすることにした。
あとあと、[ウ]の最後には"以上"って入れるの今まで忘れていたので、今回はちゃんと入れた。本番は忘れないこと！