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



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

 

開発プロセス

システム開発は、いくつかの開発プロセスと呼ばれる工程に分けて行うのが通例です。
開発プロセスの分け方は、各コンピュータメーカーやSIerによって若干異なります。

開発プロセスの基本

システム企画
通常、受注をする前に営業やITコンサルタントが、エンドユーザのシステムに関する要望や、現状システムの問題点などをヒアリングします。要望や問題点を踏まえて企画を立て、エンドユーザにプレゼンをして内容のすり合わせを行います。

 

要件定義
要件定義では、エンドユーザの現状業務をシステム分析し、業務要件とシステム化するために必要なことを定義します。また、要件定義を、システム方式設計と呼ぶ場合もあります。
エンドユーザは、システムについて詳しくない場合もあります。要求が曖昧だったり、矛盾することもあります。実現可能なものとして、エンドユーザの要求をITコンサルタントやSE(システムエンジニア)がとりまとめていきます。
エンドユーザとシステム開発者で認識のズレが生じると、致命的な設計上の欠陥や実装漏れにつながる可能性があります。

 

概要設計
基本設計、UI(ユーザインタフェース)設計と呼ぶ場合もあります。概要設計では、主に入出力に関する機能設計を行っていきます。具体的には、画面設計、帳票(レポート)設計、データベース設計、ネットワーク構成などが該当します。どのような技術を使用し、システムを構成するかを設計していきます。

 

詳細設計
システム構造設計と呼ぶ場合もあります。概要設計で決まった機能について、仕様や動作をどのように実装していくかを決めていきます。具体的には、機能ごとの処理、フローチャート、画面の詳細項目、帳票(レポート)の詳細項目、データベースの物理設計などを行います。

 

プログラム設計
プログラム設計では、各プログラムを機能ごとに分割して設計を行います。アクティビティ図、クラス図、データベース構造、テストケースなどを決めていきます。プログラムを記述する前に、日本語で処理内容を記述をしていくようなイメージです。

 

プログラミング
プログラム設計書に基づき、プログラムを作成する工程です。コーディングとも呼びます。プログラミングの工程はチームとして取り組むことが多いため、分かりやすくプログラムを書くことも重要です。

 

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

 

運用保守
開発終了後(カットオーバー)、システムが実際に動いた後(本番稼動、サービスイン)、障害対応やユーザの追加要望に対応しながら、システム運用や保守を行います。
ユーザトレーニングや、サポートなどの作業も発生します。ユーザがシステム操作に慣れるために、操作トレーニングやサポートを行う場合もあります。

 


ウォーターフォール型

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

 

ウォーターフォール型は、長年多くのシステム開発で使用されてきましたが、いくつかの課題があります。

1.作業や工程の手戻りが発生する
上流工程の要件定義で、全ての要件を洗い出すことが困難なため、漏れや齟齬が必ず発生し ます。また、概要設計でも、ユーザが画面イメージを見たところで、やはり多少の齟齬や仕様漏れが発生します。要件漏れや仕様の欠陥は、実際にシステムができて、テスト工程に入って初めて露見されることが多いです。時には大きな手戻りになるケースもあります。
最悪な場合は、本稼動直前や直後に致命的な要件不備や設計上の欠陥が発見されることです。修正作業のためのコストが極めて大きなものになったり、システム自体が稼動に至らない、動いても使われないといったことに繋がります。

2.技術者確保の問題
以下の図のように、開発作業に携わる技術者の数が、上流工程からプログラム設計の工程に向かって増加し、プログラミング、プログラムテストをピークに少しずつ減少していきます。
従ってプログラミング工程時には、多くのプログラマー、SEを必要とすることになります。SI業界は慢性的な人材不足に陥っており、即戦力の技術者を大量に確保することは極めて困難です。技術者の数が不足していると、納期に間に合わなかったり、そのプロジェクトに参画している一人一人の技術者の負荷が高くなり、品質が悪くなったり多くの弊害が出てしまいます。

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

 


プロトタイプ型

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

 

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

 


アジャイル型

アジャイル型は、機能を小さな単位で区切り、設計、プログラミング、テストを反復(イテレーション)して行います。1つの反復を1~4週間で行い、短期間で機能を1つずつ開発します。従来の開発プロセスに比べ開発工数を短縮できるため、アジャイル(素早い)と呼ばれます。
アジャイル型では、ユーザから大まかに要件と仕様をヒアリングして詳細まで決定せずに開発工程へと進みます。要件追加や仕様変更があることを前提としているため、ユーザの要望を最大限盛り込んだものがリリースできます。新規でリリースするWebサービスやスマートフォン向けアプリ開発は、途中で仕様変更が発生する確率が高いためアジャイル型の開発プロセスが向いています。
アジャイル型での開発は、開発途中にユーザからのフィードバックを受けるため、ユーザと開発側との齟齬が減少します。そのため、手戻りが発生しにくく、発生したとしても最小単位の機能のためリスクが少ないというメリットがあります。
要件と仕様を明確に決めないため、当初の方向性からずれが生じてしまうというデメリットがあります。ユーザからの要望を全て取り入れようとした結果、開発工数に遅れが出てしまう可能性もあります。事前に詳細を決めないため、スケジュール管理がしにくくプロジェクト全体の進捗が分かりにくくなりがちです。


アジャイル型では最小単位の機能で開発を行うため、膨大な数の技術者を確保せずに進められます。ウォーターフォール型と比較し、技術者の確保がしやすいことが特徴です。

メリット
・ユーザからのフィードバックを受けながら開発を進めるため、要件漏れのリスクを軽減できる
・初回リリースまでの開発工数が、従来の開発プロセスに比べて短期間で行える
・技術者の確保が比較的しやすくなる
デメリット
・要件や仕様を細かく決めないため、方向性のずれが生じやすい
・仕様変更や追加が多くなると開発工数が、ウォーターフォール型よりも増える場合がある
・全体の作業進捗が把握しにくいため、スケジュール管理が難しくなる

 


開発標準化

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

標準の形骸化?

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

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




Tech Funの記事をシェアする