開発プロセスと開発標準化

ここでは、システム開発における開発プロセスと、開発標準化について解説します。

 

開発プロセス

システム開発は、いくつかの開発プロセスと呼ばれる工程に分けて行うのが通例です。この分け方は各コンピュータメーカーやSIerなどが定義している開発標準(後述)によって若干異なり、呼び方(名前)も様々です。

開発プロセスの基本

開発プロセスは概ね下図のように、分類することができ、上流工程から下流工程まで各プロセスにおいて、行うべき内容が決まっています。それでは各プロセスの内容説明をしていきましょう。

システム企画
通常受注をする前に、営業やITコンサルタントがエンドユーザのシステムに関する要望や、現状システムの問題点などをヒアリングし、それに基づき、システムの企画を行い、エンドユーザにプレゼンテーションを行ったりします。

 

要件定義
システム方式設計と言う場合もあります。システム開発を行う際に、再度エンドユーザの現状業務やシステムを分析し、業務要件とシステム化要件を定義します。 エンドユーザは、システムに関する知識は持っていないことが多いため、その要求は、曖昧だったり、矛盾していたりしますが、ITコンサルタントやSE(シ ステムエンジニア)が、それらを取り纏め、実現可能な要件を定義する工程となります。ここがエンドユーザの認識とシステム開発者サイドで認識のズレが生じ ると、後工程で致命的な設計上の欠陥が顕在化する場合があるので、非常に重要な工程です。

 

概要設計
基本設計、UI(ユーザインタフェース)設計と言う場合もあります。ここでは主に入出力に関する機能設計を行っていきます。具体的には、画面設計、帳票(レポート)設計、データベース設計などがそれに該当します。

 

詳細設計
システム構造設計と言う場合もあります。概要設計で決まった機能を、プログラムレベルに分割し、それぞれのプログラムで実現する機能を定義します。

 

プログラム設計
詳細設計において機能ごとに分割したプログラム1本1本の構造や処理手順を、詳細に設計します。プログラムを記述する前に、日本語でその内容を記述するようなイメージです。

 

プログラミング
プログラム設計書に基づき、プログラムを作成する工程です。コーディングとも言います。

 

プログラムテスト、結合テスト、システムテスト、運用テスト
作成したプログラムをテストしたり、機能を検証したりする工程です。品質を担保するための重要な工程です。プログラムのテストをプログラムテスト(単体テス トとも言います)、各プログラムをつなげて機能レベルのテストを行うのを結合テスト、システム全体で検証することをシステムテスト、エンドユーザが実務 データに基づき検証するのを運用テストと呼びます。

 

運用保守
この工程は、開発終了後(カットオーバーなどという場合があります)、システムが実際に動いた後(本番稼動、サービスインなどと呼びます)、障害対応やユーザの追加要望に対して対応しながら、システムの運用や保守を行っていく工程です。
その他、ユーザトレーニングやサポートなどの工程も発生します。新しいシステムを導入するため、システムに不慣れなユーザは、導入後すぐにシステムを使いこなすことは難しいため、操作トレーニングや稼動後のサポートを行うこともあります。

 


ウォーターフォール型

古 くからあり、よく知られた開発プロセスモデルです。開発工程を上流工程から下流工程へと、滝の水が上から下へ流れ落ちるように開発していくことから、 ウォーターフォール型開発プロセスと呼びます。この開発手法の特徴は、各工程で仕様や機能を確定させていき、前工程が終了するまで次工程を開始しないとい う手法です。もう一つの特徴は、ウォーターフォール型は、別名「V字型モデル」ともいい、要件定義の工程で確定した仕様を検証する運用テスト、概要設計の 工程で確定した仕様を検証するシステムテスト、詳細設計内容を検証する結合テスト、プログラミング設計内容を検証するプログラムテストというように各設計 工程とテスト工程が対応するようになっています。

 

ウォーターフォール型は、長年多くのシステム開発で使用されてきましたが、いくつかの課題があります。
1つ目は、作業及び工程の手戻りの問題です。上流工程の要件定義で、全ての要件をその工程で洗い出すことは困難なため、漏れや齟齬が必ず発生し ます。また、概要設計でも、ユーザが画面イメージを見たところで、やはり多少の齟齬や仕様漏れが発生します。そういった要件漏れや仕様の欠陥は、実際にシ ステムができて、テスト工程に入って初めて露見されることが多く、時には大きな手戻りになるケースもあります。最悪な場合は、本稼動直前もしくは直後に致 命的な要件不備や設計上の欠陥が発見され、修正作業のためのコストが極めて大きなものになったり、システム自体が稼動に至らない、動いても使われないと いったことにもなります。
2つ目は、技術者確保の問題です。以下の図のように、開発作業に携わる技術者の数が、上流工程からプログラム設計の工程に向かって増加し、プロ グラミング、プログラムテストをピークに少しずつ減少していきます。従ってプログラミング工程時には、多くのプログラマー、SEを必要とすることになりま す。SI業界は慢性的な人材不足に陥っており、即戦力の技術者を大量に確保することは極めて困難となります。技術者の数が不足していると、納期に間に合わ なかったり、そのプロジェクトに参画している一人一人の技術者の負荷が高くなり、品質が悪くなったりと多くの弊害が出ることになります。

メリット
・工程が上流から下流に順番に流れていくため、管理がしやすい。
デメリット
・致命的な手戻りが発生する可能性がある。
・プログラミング工程前後の技術者の確保が、多数の場合は困難である。

 


プロトタイプ型

シ ステム開発の初期段階で、そのシステム機能と画面を試作し、エンドユーザーが評価することによって、システムの仕様や機能を確定して、本番のシステム開発 を行っていく手法です。開発側とユーザ側のシステムに対する要件の齟齬を早期に発見し、システム開発の手戻りをなくす目的があります。プロトタイプには、 プロトタイプで試作したものを最終的なシステムに組み込まずに捨ててしまう方法と、作成したプロトタイプをベースに機能を追加して、最終的なシステムを開 発する方法がありますが、通常は、後者になります。システムをバージョン管理し、少しずつユーザの要件に合ったものに作り上げていきます。ウォーター フォール型のような大きな手戻りのリスクは減りますが、試作品を開発することにより、総開発工数はかかってしまうことがあります。また、プロトタイプの機 能の実装に完全を求める傾向があり、プロトタイプの修正作業に大きな負荷がかかってしまい、全体の作業工数に影響が出てしまうこともあります。

 

メリット
・試作品を早期に開発することにより、ユーザの要件漏れや開発側との齟齬が減少する。
デメリット
・プロトタイプの開発に時間が掛かり、全体工数が肥大化する傾向がある。

 


スパイラル型

ウォーターフォール型とプロトタイプ型をあわせたような開発プロセスがスパイラル型です。システム開発プロセス(設計からテスト)を機能単位で区切り、短期間で 各機能を開発し、それを繰り返し行うことで完成に近づけることからスパイラルと呼んでいます。短期間のウォーターフォール型開発プロセスを何度か繰り返す ような方法です。Web系のシステムはユーザ企業でシステムの画面確認が容易であるため、この手法が用いられることが多くなってきています。最初の機能 は、プロトタイプ的になることもあり、完全に機能を実装せず、ユーザに確認してもらい、より詳細に要件を纏めて、次の開発を行うこともあります。 ス パイラル型は、早い段階で、一部の機能をユーザに確認してもらうことができるため、手戻りのリスクが少なくなりますが、各繰り返しの開発の中で、手戻りが 発生し、次の繰り返しの開発に影響が出ることがあります。大規模システム開発では、最初の開発単位の見積もりが難しく、見積もり誤差による開発作業の遅れ が発生することもあります。また、いくつもの開発工程が並行で進むため、管理が難しくなります。


ウォーターフォール型の技術者確保の問題は、スパイラル型では、段階的に開発を行うため、技術者の使いまわしが可能となり、技術者数の山が低くなり、技術者の確 保が比較的しやすくなります。また、同じ技術者が長期にプロジェクトに参画するため、技術や業務知識の蓄積がされ、開発期間後半での品質や生産性の向上が 図ることができます。

メリット
・機能の一部を早期にユーザに確認できるため、ユーザの要件漏れなどのリスクを軽減できる。
・一定の技術者数で開発を進めるため、各技術者に技術や業務知識が蓄積され、品質や生産性の向上が図れる。
・技術者の確保が比較的しやすくなる。
デメリット
・大規模システム開発の場合、最初の開発単位の見積もりが難しく、見積もり誤差により、開発作業に遅れが出ることがある。
・各工程で、手戻りが発生し、場合によっては、ウォーターフォール型より工期や工数が多くかかる場合がある。
・複数の開発が並行で進むため、管理が難しくなる。

 


開発標準化

開発標準化とは、これまで説明してきた開発プロセスモデルのような「開発プロセス」の標準化や、成果物とするドキュメント(設計書やテスト仕様 書など)の標準化、コーディング規約などのことを言います。開発プロセスやドキュメント、コーディングを今までのシステム開発の経験、積み上げた技術から 最適と思われる形で標準化することにより、開発を効率良く進め、開発期間を短縮し、開発コストを削減、また、品質を向上させる目的があります。
開発手順のモデルとなるような開発プロセスが考えられてきたのと同様に、成果物である設計書やテスト仕様書などのドキュメントの標準化やコー ディングの仕方を詳細に定義した規約などがあります。通常は、各開発プロジェクトによって、ドキュメント規約やコーディング規約が定義され、各開発者に遵 守するよう通達されます。また、大手SIerには、社内標準と言われる開発プロセス、ドキュメント規約、コーディング規約があり、各プロジェクトは、それ を遵守する形で、開発を進めていきます。
ドキュメント規約には、成果物の定義(何を成果物とするか)や各フォーマットや記述のルール(フォントタイプ・フォントサイズ・項番・記述内 容)などが定義されています。また、コーディング規約には、プログラムや変数名のルールである命名規約や、コーディングのルールなどが詳細に定義されてい ます。これらの規約によって、統一されたドキュメントやプログラムのソースとなり、メンテナンス性や品質の向上に繋がっていきます。

標準の形骸化?

シ ステム構築全てに関する手順・手法と成果物を標準化し、品質保証の根拠となる開発標準と呼ばれる、大手システム会社を中心に策定していますが、実際の開発 現場レベルで準拠されているケースは少なく、形骸化しているといっても過言ではありません。ひどい場合は、成果物のシステム設計書がほとんどなく、口頭に よる仕様伝達のため、齟齬が発生しても、文書がないため原因を究明することがでず、責任の所在が不明確となり、トラブルとなるケースもあります。準拠され ない原因としては、開発標準の複雑・煩雑さと、技術者の文書化能力不足が挙げられます。前者は全て文書化すると、その作成に膨大な時間を取られ、結果とし てユーザ企業に資金負担を強いることとなりますので、敬遠されがちです。またユーザにとってみれば、よくわからないシステム設計書をたくさん記述しても らったところで、ありがたみが薄いというわけです。後者は、プログラム言語は得てとしている技術者でも、日本語という言語が苦手であるがゆえに、作成でき ないという、皮肉な現実があります。あまり無意味な文書作成をせず、必要なものを必要な量作成し、納品物として定義した、現実的に適用可能な開発標準の制 定をすべきであり、システム会社はそれに準拠したシステム構築を行っていくことが必要となっています。

次はプログラムとはです。