まとめてみたいと思います。
主にこの業界に入った人向けのエントリの記事となります。
ソフトウェア開発は、
皆で分業して進めていきますので、
一人で全てをすることは基本的にありませんが、
全体像を把握することで、自分の担当業務を
スムーズに進めることができることがあります。
ですので、早いうちに全体像をざっくりとでも
掴むことは大事だと私は考えています。
しかしながら、ソフトウェア開発プロジェクトとって言っても、
様々な分野や、所属する企業によっては大人な事情があるため、
ひとくくりにまとめるのは難しいので、
あくまでも私の経験に基づいて書かせていただきます。
問題や意見がございましたら、ご指摘いただけると助かります。
◾️開発方法論について
開発方法論は巷にたくさんあふれていますが、
「こうでなければならない」とか
「これ通りにすれば、どんなプロジェクトであれ100%成功する」といった
方法論はないんです。
ですので、先人が残してくれた、
幾つか体験例を元に成功に導くノウハウを利用します。
（ベストプラクティスとかグッドプラクティスとか言われてますね。）
作るシステムの種類や特性、または時代の流行によって、
プロジェクトマネージャやお客さんやシステム開発者の知識や経験を頼りに、
適してると思われる開発方法論を決めて進めていくのが一般的です。
ただし一番大事なのは、プロジェクトに関わる皆さんが
「成功させたい！」
という一体の気持ちを持っていることだと思います！
[wiki]
ソフトウェア開発方法論
[IT pro]
開発プロセスを学ぶ
▼ウォーターフォール
古くからある、一番基本になるやり方です。
きっちり一つ一つ決めながら進めていくので、
全体の作業が見通しやすい反面、
融通が利かなかったり、現実と乖離するデメリットがあります。
▼アジャイル（反復形）、プロトタイピング、スパイラル、RAD
ウォーターフォールの欠点を改善するために考えられた方法論たちです。
現在の多くのシステム開発企業では、
既存のウォーターフォールの欠点を補えるよう、
このような開発方法論を取り入れるなどの、工夫をしています。
◾️システム開発作業例
ウォーターフォールは、色々と欠点を抱えていますが、
システムを開発する上で必要な作業がわかりやすいので、
はどんな手順かざっくり書いてみますね。
引用：it pro 開発プロセスの基本を学ぶ
1.プロジェクト計画の概要と予算見積もり・契約の取り決め
（提案依頼(RFP)作成、要件定義、プロジェクト実行計画立案）
お客さん（またはシステム開発会社やコンサルタント）が
どんなシステムを作るのか計画(提案依頼)し、
その計画をもとに、システム開発会社とお客さんで綿密に話し合って、
どんな製品や技術や人員を入れるのか、どういうスケジュール・進め方をするのか、
何を納品するのか、性能はどのくらいを目標にするのか、
セキュリティ対策はどうするのか、
プロジェクトとして、どこまでの範囲をやるのかというきっちりとした枠組みをつくり
（要件定義、プロジェクト実行計画）、お金の見積もりや注意事項の取り決めをして契約を締結します。
※以下ソフトウェアに特化した記述で、
インフラ（ネットワーク、サーバやH/W）については割愛しています。
実際には、インフラの調達や設計、構築、設定なども同時に進めていきます。
2.主にお客さんに見てもらうためのシステム設計書を作成
（基本設計書作成、外部設計書作成、概要設計書作成などと呼び方は様々です。）
要件定義で決めた内容をもとに、
さらにお客さんと相談したり、システム開発会社で検討して
どういう機能にするか、どういうデータを利用するか
デザインはどうするか、どういった技術要素を使用するかをより具体的に、
煮詰めて設計書として、目に見えるものに落とし込んでいきます。
そして、お客さんとの合意を得た上で次の工程に進みます。
3.主にプログラム開発に必要なシステム設計書を作成
（詳細設計作成、内部設計作成）
お客さん向けのシステム設計書をもとに、
どういう処理フローやデータを使って、機能を実現するかを
プログラムが作成できるくらいまで落とし込みます。
主にプログラマやシステム設計者という立場の人たちが、
相談したり考えたりしながら進めて、
情報共有できる設計書として残します。
お客さんが技術に強い場合は、逐一合意が必要なケースもありますが、
そうでない場合は重要な部分を除いて、
システム開発会社内で決定していくケースもあります。
4.プログラム開発
プログラム開発向けの設計書をもとに、コーディングをします。
プログラムをする時は、コーディングするときのお作法（コーディング規約）が
あるところが多いので、それに従いましょう。
（これは、各自が独自の思想でコードを書いてしまった時に、
他人がコードを理解しにくかったり、バグが発生しやすかったり、
個人の能力に必要以上に依存しないための先人の知恵だと
私は思っています。）
出来上がったコードは基本的にデバッグしてちゃんと動くか確認します。
場合によっては、他の人に自分が書いたコードが
問題ないか確認してもらうこともあります。
5.単体テスト（ユニットテスト、ホワイトボックステスト)
プログラム開発向けの設計書をもとに、テスト仕様書を作成し
プログラムが仕様通りに動くか確認します。
ユニットテストは、プログラムを部品レベルで動かして
入力値に応じた結果が仕様通りかとか、
全ての判定処理を網羅しているかとかチェックします。
単体テストは、機能の一つ一つのログ（システム動作の記録）や
画面の表示項目だとか、
データの登録値が仕様通りかを細かいレベルでチェックします。
プログラム不具合がある場合は、プログラム修正をします。
6.結合テスト（疎通テスト、インターフェーステスト）
お客さん向けの設計書やプログラム開発向けの設計書をもとに、
テスト仕様書を作成し、プログラムが設計した使用を満たしているかを確認します。
幾つかのプログラムをつなげたり、一つの機能や一連の機能の流れに着目したり、
他のシステムとの連携が仕様通りに動くかチェックします。
主にシステム開発会社や、開発側に関係する人たちで作業を進めます。
また、想定外のことが起きた場合の動きや、
セキュリティ機能もしっかり働いているかなども確認します。
問題がある場合は、要件にミスがあるのか、設計にミスがあるのか、
開発にミスがあるのかを特定して、優先度に応じて対応します。
7.総合テスト（受け入れテスト、運用テスト、リリース）
お客さんと一緒に、全部のシステムの連携させて、
実際の業務のシナリオ通りに動くかチェックします。
専門会社にセキュリティ診断を依頼することもあります。
ここで問題がある場合も、現象や原因を特定して、
予算や期間と照らし合わせて、優先度や重要度をつけて
対応するか、システムリリース（システムを動かして、実際の業務で使用できる状態にする）後に対応するかなどを適宜決定していきます。
場合によっては、システムのユーザマニュアルを整備したり、
ユーザのトレーニングをしたり、
システムを運用するためのマニュアルを整備したります。
消費者向けシステム（B to C）の場合は、サポートセンターのオペレーション作成や、
問い合わせQAサイトの整備が必要になることもあります。
8.保守・運用
実際にシステムを使い続けていく上で、
問題が発生したり、不具合が発生した場合、
その都度対応していくことになります。
ユーザからの問い合わせに対応したり、
システムが止まった場合は復旧させたり、
データ不具合が発生したら、データを修正したり、
プログラム不具合が発生したら、プログラムを修正したりします。
もちろん設計書や運用マニュアルも合わせて、
メンテナンスが必要です。
また、システム使い続けていく上で、他の機能が必要になったり、
機能を変更したりする必要や問題点が出てくる場合は、
システム改修プロジェクトとして新たに予算を作成して
対応していくこともあります。
◾️まとめ
また、ソフトウェアは使い続けていくと劣化していきます。
劣化を防ぐには、保守や運用での工夫も必要ですが、
最初に開発するときに考える前提条件の影響が大きいので、
気をつけましょう。
どうしても手に負えなくなったら、
作り変えるという選択肢が常套手段ですが。。。
(ソフトウェアライフサイクルとか言われてますね。。。)
以上、ざっくりとした流れで話をしましたが、
これは、あくまでの一例です。
具体的な作業やノウハウについては、別途理解を深めていってくださいね！
[関連キーワード]
・ソフトウェア開発プロセス
・プロジェクトマネジメント
・ソフトウェア品質管理
最後までお読みいただき、ありがとうございます！