開発プロセス
システム開発は、いくつかの開発プロセスと呼ばれる工程に分けて行うのが通例です。
開発プロセスの分け方は、各コンピュータメーカーやSIerによって若干異なります。
開発プロセスの基本
エンドユーザは、システムについて詳しくない場合もあります。要求が曖昧だったり、矛盾することもあります。実現可能なものとして、エンドユーザの要求をITコンサルタントやSE（システムエンジニア）がとりまとめていきます。
エンドユーザとシステム開発者で認識のズレが生じると、致命的な設計上の欠陥や実装漏れにつながる可能性があります。
ユーザトレーニングや、サポートなどの作業も発生します。ユーザがシステム操作に慣れるために、操作トレーニングやサポートを行う場合もあります。
ウォーターフォール型
この開発手法の特徴は、各工程で仕様や機能を確定させていき、前工程が終了するまで次工程を開始しないという手法です。
もう一つの特徴は、ウォーターフォール型は、別名「V字型モデル」ともいい、要件定義の工程で確定した仕様を検証する運用テスト、概要設計の工程で確定した仕様を検証するシステムテスト、詳細設計内容を検証する結合テスト、プログラミング設計内容を検証するプログラムテストというように各設計工程とテスト工程が対応するようになっています。
ウォーターフォール型は、長年多くのシステム開発で使用されてきましたが、いくつかの課題があります。
1.作業や工程の手戻りが発生する
上流工程の要件定義で、全ての要件を洗い出すことが困難なため、漏れや齟齬が必ず発生し ます。また、概要設計でも、ユーザが画面イメージを見たところで、やはり多少の齟齬や仕様漏れが発生します。要件漏れや仕様の欠陥は、実際にシステムができて、テスト工程に入って初めて露見されることが多いです。時には大きな手戻りになるケースもあります。
最悪な場合は、本稼動直前や直後に致命的な要件不備や設計上の欠陥が発見されることです。修正作業のためのコストが極めて大きなものになったり、システム自体が稼動に至らない、動いても使われないといったことに繋がります。
2.技術者確保の問題
以下の図のように、開発作業に携わる技術者の数が、上流工程からプログラム設計の工程に向かって増加し、プログラミング、プログラムテストをピークに少しずつ減少していきます。
従ってプログラミング工程時には、多くのプログラマー、SEを必要とすることになります。SI業界は慢性的な人材不足に陥っており、即戦力の技術者を大量に確保することは極めて困難です。技術者の数が不足していると、納期に間に合わなかったり、そのプロジェクトに参画している一人一人の技術者の負荷が高くなり、品質が悪くなったり多くの弊害が出てしまいます。
プロトタイプ型
プロトタイプには、プロトタイプで試作したものを最終的なシステムに組み込まずに捨ててしまう方法と、作成したプロトタイプをベースに機能を追加して、最終的なシステムを開 発する方法がありますが、通常は、後者になります。システムをバージョン管理し、少しずつユーザの要件に合ったものに作り上げていきます。
ウォーターフォール型のような大きな手戻りのリスクは減りますが、試作品を開発することにより、総開発工数はかかってしまうことがあります。また、プロトタイプの機能実装に完全を求める傾向があり、プロトタイプの修正作業に大きな負荷がかかってしまい、全体の作業工数に影響が出てしまうこともあります。
デメリット
・プロトタイプの開発に時間が掛かり、全体工数が肥大化する傾向がある
アジャイル型
アジャイル型では、ユーザから大まかに要件と仕様をヒアリングして詳細まで決定せずに開発工程へと進みます。要件追加や仕様変更があることを前提としているため、ユーザの要望を最大限盛り込んだものがリリースできます。新規でリリースするWebサービスやスマートフォン向けアプリ開発は、途中で仕様変更が発生する確率が高いためアジャイル型の開発プロセスが向いています。
アジャイル型での開発は、開発途中にユーザからのフィードバックを受けるため、ユーザと開発側との齟齬が減少します。そのため、手戻りが発生しにくく、発生したとしても最小単位の機能のためリスクが少ないというメリットがあります。
要件と仕様を明確に決めないため、当初の方向性からずれが生じてしまうというデメリットがあります。ユーザからの要望を全て取り入れようとした結果、開発工数に遅れが出てしまう可能性もあります。事前に詳細を決めないため、スケジュール管理がしにくくプロジェクト全体の進捗が分かりにくくなりがちです。
アジャイル型では最小単位の機能で開発を行うため、膨大な数の技術者を確保せずに進められます。ウォーターフォール型と比較し、技術者の確保がしやすいことが特徴です。
メリット
・ユーザからのフィードバックを受けながら開発を進めるため、要件漏れのリスクを軽減できる
・初回リリースまでの開発工数が、従来の開発プロセスに比べて短期間で行える
・技術者の確保が比較的しやすくなる
デメリット
・要件や仕様を細かく決めないため、方向性のずれが生じやすい
・仕様変更や追加が多くなると開発工数が、ウォーターフォール型よりも増える場合がある
・全体の作業進捗が把握しにくいため、スケジュール管理が難しくなる
開発標準化
開発標準化とは、これまで説明してきた開発プロセスモデルのような「開発プロセス」の標準化や、成果物とするドキュメント（設計書やテスト仕様書など）の標準化、コーディング規約などのことを言います。
開発プロセスやドキュメント、コーディングを今までのシステム開発の経験、積み上げた技術から 最適と思われる形で標準化することにより、開発を効率良く進め、開発期間を短縮し、開発コストを削減、また、品質を向上させる目的があります。
開発手順のモデルとなるような開発プロセスが考えられてきたのと同様に、成果物である設計書やテスト仕様書などのドキュメントの標準化やコーディングの仕方を詳細に定義した規約などがあります。通常は、各開発プロジェクトによって、ドキュメント規約やコーディング規約が定義され、各開発者に遵守するよう通達されます。また、大手SIerには、社内標準と言われる開発プロセス、ドキュメント規約、コーディング規約があり、各プロジェクトは、それを遵守する形で、開発を進めていきます。
ドキュメント規約には、成果物の定義（何を成果物とするか）や各フォーマットや記述のルール（フォントタイプ・フォントサイズ・項番・記述内容）などが定義されています。また、コーディング規約には、プログラムや変数名のルールである命名規約や、コーディングのルールなどが詳細に定義されてい ます。これらの規約によって、統一されたドキュメントやプログラムのソースとなり、メンテナンス性や品質の向上に繋がっていきます。
標準の形骸化？
システム構築全てに関する手順・手法と成果物を標準化し、品質保証の根拠となる開発標準と呼ばれる、大手システム会社を中心に策定しています。実際の開発現場レベルで準拠されているケースは少なく、形骸化しているといっても過言ではありません。
ひどい場合は、成果物のシステム設計書がほとんどなく、口頭による仕様伝達のため、齟齬が発生しても、文書がないため原因を究明することがでず、責任の所在が不明確となり、トラブルとなるケースもあります。準拠されない原因としては、開発標準の複雑・煩雑さと、技術者の文書化能力不足が挙げられます。
前者は全て文書化すると、その作成に膨大な時間を取られ、結果としてユーザ企業に資金負担を強いることとなりますので、敬遠されがちです。またユーザにとってみれば、よくわからないシステム設計書をたくさん記述してもらったところで、ありがたみが薄いというわけです。後者は、プログラム言語は得手としている技術者でも、日本語という言語が苦手であるがゆえに、作成できないという、皮肉な現実があります。
無意味な文書作成をせず、必要なものを必要な量作成していくことが重要です。現実的に適用可能な開発標準の制定を事前に決めて、システム会社はそれに準拠したシステム構築を行っていくことが必要となっています。
次はプログラムとはです。
