システム開発の工程（流れ）の内容は？
一般的な話となりますが、システム開発は次のような流れで進められます。
・要件定義
・概要設計（外部設計）
・詳細設計（内部設計）
・開発
・単体テスト
・結合テスト
・運用
会社によって多少の呼び方の違いはありますが、概ね上記のようなイメージとなります。
またアジャイル型の開発でも、設計→開発→テストを細かく繰り返す点においては変わりません。
※ウォーターフォールやアジャイルについては、後述します。
各工程を具体的にみていきます。
要件定義
作りたいシステムを決める段階です。家の設計図を作る部分となります。
どういう目的で使うシステムか、どういう機能が欲しいかを明確にして、
その要望に沿った形式でシステムの設計図を作成します。
家の設計も同じですが、欲しい機能（バリアフリー、オープンキッチンなど）や、
どういう部屋の配置にするか、などを決めて家の設計図を作成します。
その際に必要な機能を検討することは必要ですが、開発期間や予算によって内容を変更することも必要です。
開発期間や予算内でおさまるように、必要な機能を優先的に開発することも検討します。
予算におさまらない場合は、次回以降のステップとして検討課題にしておいたりします。
基本設計（外部設計）
要件定義で作成した設計図に基づき、各機能の画面を作成していきます。
実際にユーザーが使用する画面のイメージを作成していく部分で、入力項目の並びや
ボタンの配置なども決めます。
画面のイメージも重要な要素で、ユーザーが使いやすいものになるか否かが決まってきます。
ある程度、各画面で統一感を出せた方がよいと思います。
システムを使用するために、ユーザーも使い方を学ぶ必要がありますが、
この学習時間は業務にとっては無駄となります。
その時間が少ないほど無駄な人件費もかからなくなります。
詳細設計（内部設計）
基本設計で作成した内容を作成するために必要な内容を、細かく決めて仕様書（設計図）を作成していく部分です。
家の設計でいうと、この流し台を設置するために、この壁から何ミリ分のスペースが必要で、
というように、詳細に配置図を作成していきます。
詳細設計の部分に関しては、ほぼほぼ開発側で作成するようになります。
今後の拡張に備え、データ枠に余力をもたせておくか否かなど、細かい判断も必要となってきますが、
昔に比べれば、個人向けのハードディスクやメモリでも、かなりの容量が確保できる時代です。
以前のように１バイトの無駄もなくすような方法ではなく、ある程度の余裕をもたせた設計の方が、
後々の改善もやりやすくなると思います。
開発（実際のシステム開発）
作成した仕様書（設計図）に基づいて、実際にシステムを開発していきます。
実際に作成する機能は一つだけではない事が多いので、複数人で分担して開発を行う事が多いです。
また、機能を作成する時に書くプログラムのソースコードは、個人差も大きいため
一定以上の規模となると、一定の決まりに則った書き方をする必要がでてきます。
その他、使用するプログラミング言語で、得意な分野、不得意な分野がありますが、
一般的な機能であれば、どの言語でも作成することは可能です。
できれば流行り廃りの影響が少ない言語での開発ができればよいと思います。
※業務システムであれば、Windows系なら.NET関係がオススメです。
Windowsとの相性もよく、バージョンアップなどの影響も非常に少ないためです。
※使用するプログラミング言語に関しては、開発の会社との相談となります。
ソースコード付きでの納品が可能かどうかも、併せて確認するとよいと思います。
テスト
開発が完了すると、作成したプログラムのテストを行います。
作成した仕様書を確認しながら、その内容通りの動きをしているか確認をします。
また、テストで不具合が発生した場合、その部分を修正して改めてテストを行っていき、
不具合がなくなるまでテストを繰り返します。
テストは「単体テスト」と「結合テスト」に分けて語られることが多いです。
「単体テスト」はシステムがパーツ単位で、きちんと動くかを確認する初期レベルのテストです。
「結合テスト」は単位テストでテストしたパーツが、複数のパーツの間できちんと動くかを
確認する段階のテストです。
簡単な言い方をすると、単品でバラバラに動作を確認して、それぞれが大丈夫であれば、
実際に組み合わせたときの動作の確認を行います。
正直な話ですが、個人的にはこれらは分ける必要があるのかな？とは思います。
単体テストをやりながら、結合テストも行ってしまうのが、流れとしては自然な場合も多いからです。
ですが、こういう分け方をしているというのは事実なので、分けた概要も記載しました。
また、運用のための事前テストも分けて考える場合があります。
詳細化すればよいとも思えないのと、事前テストは基本的にお客様（開発の依頼元）側でのテストと
なるため、開発会社からみるシステム開発の流れには、項目として含めていない場合も多いです。
しかし、事前テストは必ず行います。お客様側で事前テストを行うことで、
不具合のつぶしこみだけでなく、次回以降の開発項目もピックアップされるケースが多いです。
家を建てるときでいうと、単体テストで各備品などを個別に確認し、受け取った時のダンボールの中で
壊れていたりすれば、新しいものと取り替えたりします。
全ての備品が揃ったら、実際に部屋に組み込んで結合テストをしていきます。
組み込んだ際に、例えばシステムキッチンの寸法が違うなどが発覚した場合、
そこを修正していきます。
その後、事前テストの段階でお客様にて現地にきていただき、実際のものを触って確認していただきます。
ここまでがOKとなったら納品となります。
運用（運用・保守）
納品後、実際に運用していく段階です。
仕様の漏れなどがあった場合、この段階で問題が発生してくることになります。
その点については、次回以降の開発で補うのか、内容的に開発の会社の不具合として修正してもらうのか、
その時々での判断となります。
追加の開発の要望を検討しつつ、実際に使用していきます。
システム開発の手法はどういうものがあるか？
システム開発の手法は様々なものがありますが、一般的には２つの有名なものがあります。
「ウォーターフォール」と「アジャイル」です。それぞれについてみていくとともに、
メリットとデメリットを記載していきます。
古くからあるウォーターフォールより、アジャイルの方が優れていると妄信的に思い込んでいる人もいますが、
開発の手法は新しいものが最善ではありません。ケース・バイ・ケースとなります。
ウォーターフォールとは？
ウォーターフォールとは、滝のイメージで水が上から下に流れるように、設計→開発→テストの順で進めます。
最初の設計の段階で、全ての機能や仕様を決めてから開発が開始されます。
一度先に進んだら、後には戻れないとも言われることがあるように、最初の設計の段階で
全体像を詳しく、細かく決めてしまうことが特徴としてあげられます。
１００の機能が欲しい場合、最初の設計の段階で１～１００まで全てを決めてしまうイメージです。
アジャイルとは？
基本的に設計→開発→テストの順で進めるのですが、ウォーターフォールのように最初の設計で、
全体を決めてしまわず「設計→開発→テスト」の工程を繰り返しながら、徐々に完成させていきます。
反復する（繰り返す）ことで、各段階においてお客様からのフィードバックを受けやすく、
その都度、方向性を修正しやすいのが特徴としてあげられます。
また、各段階ごとの開発となるので、開発する単位が小さくアジャイルの言葉通り、
「機敏な」、「すばしっこい」開発手法となります。
１００の機能が欲しい場合、１～５、６、７～１０のように細切れにして、
開発を進めていくイメージとなります。
ウォーターフォールとアジャイルのメリットとデメリットとは？
ウォーターフォールとアジャイルのメリットとデメリットについて、考えていきます。
ウォーターフォールの特徴として、
最初の設計の段階で全体像を詳しく、細かく決めてしまうこと
をあげましたが、最初の設計で全体像が把握できるので、
ウォーターフォールのメリットは、
・工程の管理がしやすい（専任の工程管理者も不要）
・工数（費用）の見積りがしやすい
・お客様側からは最終の完成形のイメージがしやすい
という点が挙げられます。
逆にウォーターフォールのデメリットは、
・仕様の決め不足による途中からの戻りなどの手間が多くなる
・完成版がイメージとズレていることもある
という点が挙げられます。
一方、アジャイルの特徴として、
最初の設計で全体を決めてしまわず「設計→開発→テスト」の工程を繰り返しながら、徐々に完成させていきます。
という点をあげましたが、小さな単位で徐々に完成させていくので、
アジャイルのメリットは、
・仕様の決め不足で手戻りがあった場合、手戻りの工数が少ない
・イメージのズレがあった場合、途中段階で対応できる
という点が挙げられます。
逆にアジャイルのデメリットとしては、
・全体の工期が見えづらい
・開発が小分けに繰り返されることで、工程管理が難しくなる
という点が挙げられます。
正直な話ですが、どちらも一長一短です。
個人的には、基幹システムの開発では最初の版をウォーターフォールで行い、
それ以降の開発については、細かく対応していく方向がよいと思います。
そのシステムの不具合などで障害が発生した場合、影響が大きいものはウォーターフォールがよく、
影響が小さいものや、影響範囲の少ない機能の追加などはアジャイルがよいと思います。
また、アジャイルは１０人程度の小規模なチームでの作業に効果的といわれることもありますが、
個人的には少人数である方がよいとは思いますが、２０人でも３０人でも問題なく採用できる手法だと思います。
先の展開が見えきっていない中で、手探りでも先に進みたい場合は、アジャイル型での開発が向いています。
あくまでもケース・バイ・ケースです。
また、根本を理解すれば、どちらも採用できるようになります。
ここまでご覧いただき、ありがとうございます。
ご質問やご要望などがございましたら、下記のお問い合わせフォームより、
お気軽にお問い合わせ下さい。