開発の流れ〜システムの開発プロセスと工程の流れ〜
製品開発等をする上で、どのような流れ（フェーズ）に沿っていくか一般的な例で説明していきたいと思います。
開発行為はとてもリソースが必要になります。詳しくは開発設計する前にをみてください。
これから説明する内容はソフトウエア面、ハードウエア面の両方で使える開発プロセスです。
まず、なぜ開発行為に流れがあるのかと言いますと「効率化を図る」ためです。リソースをできる限り抑えながら最良のものを作成するに越した事はありません。これから説明していくのはその一般的な例になります。実際にそのように開発を進めなくても簡単にできてしまう内容や、開発の規模や開発品目によってはもっと良い方法もあると思います。それは各々の開発の中で見極めていってください。
開発概要
個人レベルで開発する内容や小規模・短期間の開発では段階を踏んで開発プロセスを進む必要はありません。
先ほども言いましたように、リソースをできる限り抑えつつ方向性を間違わないやり方として開発プロセスがあります。
開発の方法としても、開発当初から開発完了まで全く問題がなければ開発プロセスなども色々なものが出てきません。
この限りではありませんが、開発していく中で以下のような部分が出てきてしまうため、設計自体を検討する機会が必要になります。
・テスト・評価してみないとわからない部分
・実際に使用してみないとわからない部分
・評価した後に原理的に実現できない部分
・顧客の要望が変化した部分
開発プロセスの前に
PDCAサイクル
PDCAサイクルはより良くしていくことでは非常に重要になる内容です。
管理業務を円滑に進める手法の一つですが、個人レベルの進め方でも使えます。
以下の１から４を繰り返し行い改善・改良をしてスパイラルアップしていくサイクルです。
これらをすることで、やってきた内容を次にフィードバックすることができるため改善・改良に非常に役に立ちます。
回数を重ねることでより良くなっていきます。
2.Do（実施・実行）
3.Check（点検・評価）
4.Act/Action（処置・改善）
開発の流れを説明していきますが、ループになっている部分は全てPDCAサイクルになっていると言っても過言ではありません。
開発においてこのサイクルはどの点においても使用でき効果を発揮します。
きちんと計画を立てて、実行し、見直しをして、改善をしていきましょう。
PDCAサイクルは開発だけでなく、より良くしていくためには非常に重要なサイクル
DR（デザインレビュー）
何回か言っていますが、開発行為はとてもリソース（人、モノ、金、時間）を非常に使います。間違った方向に突き進んでしまうととても疲弊してしまいます。そのために、一度立ち止まって方向が合っているか確認する必要があります。それをDR（デザインレビュー）と呼びます。
集団的知性を働かせて個人や特定グループでは見つけられなかった点を見つけていきます。
開発の振返りのしにくいウォータフォールモデル開発では、多用されます。
ですが、アジャイル型開発でも全体把握する時や開発メンバー以外を集めて開発方向の検討をすることもあります。
確認する上では、重要なポイントとなるのでなるべく機会を持ちましょう。
・DR（デザインレビュー）とは
各開発のポイント（開発プロセスの次の工程にいく前）で基準を満たしているか、方向性が間違っていないかを企画、開発、設計、製造、品質、購買が一堂に集まって次のステップに進んで良いか決めることです。
開催のタイミングは各開発の区切り（次のステップ前）がほとんどですが、重要度に応じて開催を飛ばしたりしているところもあります。
・DRで決定する内容
そのプロセスで行ってきた内容はポイントでの基準をみたしているか？
残課題は極力潰しているか？
方向性、目的が間違っていないか？
特に残課題は後回しにすると次のプロセスで修正する労力は倍になります。
極力、自工程完結で進めていきましょう。
・DRを進める上でのポイント
DRを進めるポイントと言いましたが、どんな会議でもポイントは同じです。
会議というのはとても会社として費用がかかります。（人数分の工数が会議時間分、必要なため）
どんな会議でも7人以上になると、1人増える毎に会議の決定率10%低下するという論文もあります。
決定率も下がりますが、参加者の責任感も落ちます。
発言しない者がいるということは異常です。
何かしらの考えを話してその中での最善策・妥協点を見出して行かないといけません。
また、複数の部署のスペシャリストを集めます。
開発を進めていく上で問題がないか、前と変化した点で参加部署の関係項目に問題がないかを再確認します。
・事前に内容を理解する、事前に問題点を挙げておく。
・なるべく10人以上集まらない（事前資料で問題点を挙げておく）する必要があります。
・複数部署を集めて行う
・資料の上でのポイント
資料が多くなりがちですが、必要最低限の資料づくりを心がける必要があります。
多すぎても理解できないし、情報を正確に伝えることが資料の目的です。
また、次に進んで良いか判断する場所ですので嘘の資料で固めてしまうと会社に大損害を与える可能性があります。
その辺を注意して資料を作り、発表してください。
・発言者が考える懸念点、問題点の提示
問題点発言・提案でのポイント
揚げ足をとるような発言をしたりする人（人は欠点を見てとるのが得意）が必然的に多くなりがちですが、なるべく短時間で建設的な話し合いをするように第一声は肯定的なことを心がけましょう。
詳しくはDESC話法をお読みください。
DRは重要なポイントです。
開催自体の必要性を出席者一人一人がしっかり持って望まないと、決定方向と会社の進むべき道が違ってきます。
DR（デザインレビュー）は一度立ち止まって本当に必要な開発か見直すポイント
こちらも開発プロセスを詳しく書いてあります。
よかったら参考にしてみてください。
本当に使える開発プロセス
開発の手法
開発の手法として３種類の開発プロセスを説明します。
一概にこれがいいとは言えず、それぞれ特徴があります。
最近はテストプロセスをとても重視し、手直しを極力避ける方向にあります。
そのため、ウォーターフォールモデルよりもアジャイル型が良いとされてきました。
ですが、ウォーターフォールモデルにテストプロセスを取り入れたV、W字モデル開発も頻繁に行われてきています。
・ウォーターフォールモデル開発（V字モデル開発）（W字モデル開発）
「要求定義」「概要設計」「詳細設計」「開発」「テスト・評価」などの作業工程にトップダウンで分割します。
特定の顧客がいない場合や顧客のやりとりは最初のみの場合がほとんどです。
段階を踏んでの開発の流れは管理上とてもやりやすいので、昔から使われてきた開発の流れになります。
リソースや期間も仕様変更がなければ、概算で予想がつきます。
・V字モデル開発
V字モデル開発、W字モデル開発はウォーターフォールモデル開発の変化形になります。
これらは開発プロセスですが、厳密に言いますとテストプロセスを組み込んで出戻りを少なくしようとするものです。
それを説明していきます。
「要求定義」「概要設計」「詳細設計」「実装」「テスト・評価」との流れでした。
ここでの「テスト・評価」をより具体的に上位工程の対になるような「テスト・評価」を行っていくことです。
流れとして小さなテストから大枠に移るように「テスト・評価」を行なっていく形が、開発プロセスの逆行しているように見えるためVモデルまたはV字モデルと呼ばれます。
ここでの開発の流れとしては
「要求定義」→「概要設計」→「詳細設計」→「実装」→「単体テスト」→「統合テスト」→「システムテスト」→「受入れテスト」
のような形になります。（項目は開発により変化します）
これが範囲の大小で並び替えると以下のようにV字型になります。
また、それぞれの実装までの検討内容の動作確認を各テストプロセスで行うため、ほぼ対になります。
・W字モデル開発
先ほども言いましたが、W字モデル開発はウォーターフォールモデル開発の変化形になります。
V型と違い更にテストプロセスが細かく分かれています。
理由としてはV字モデルでは実装及び実装以前の検討内容に誤りがあった場合でも、実質の確認はかなり後になってしまうため出戻りがとても大変になります。
工数もとてもかかってしまうため事前にそれらを潰していこうとする考え方で行う開発・テストプロセスです。
先ほどまでのV字モデル開発の流れの例としては
「要求定義」→「概要設計」→「詳細設計」→「実装」→「単体テスト」→「統合テスト」→「システムテスト」→「受入れテスト」
でした。
W字モデル開発の流れの例としては
「要求定義」⇆「要求テスト」→「概要設計」⇆「設計テスト」→「詳細設計」⇆「詳細テスト」→「単体実装」⇆「単体テスト」→「統合実装」⇆「統合テスト」→「システム統合」⇆「システムテスト」→「導入」⇆「受入れテスト」
のような形で検討内容及び実装の範囲でテストを入れる形になります。（項目は開発により変化します）
繰り返しになっている部分はPDCAサイクルで回ってフィードバックをします。
それにより精度を高めていきます。
V字モデルと同様に範囲の大小で並び替えると以下のようにW字型になります。
また、それぞれの実装までの検討内容の動作確認を各テストプロセスで行うため、ほぼ対になります。
メリット
・管理面から言うと管理しやすいモデル
・顧客要求と開発機能が初期段階で明確になる
・当初の要求仕様通りに製品が出来上がる
・工程ごとに専門家が分かれているため、工程内の品質に差が出にくい
デメリット
・各上位の工程で間違いがあると問題が徐々に大きくなる
・リソースを多く必要になりがち
・顧客要求が変更になった際に対応しにくい
・開発完了まで製品がリリースできない
製品が設計図から一気に具現化する形
・スパイラルモデル開発
トップダウン設計とボトムアップ設計の長所を生かした開発工程のモデルです。
設計とプロトタイピングを繰り返して開発していく手法です。
ただしアジャイル型と違い全体機能を網羅しつつ現在の全体でPDCAを回して開発していきます。
顧客とのやりとりは概要から徐々に明確になるように密接に行うことが多いです。
1回のループ期間は6ヶ月から2年程度であることが比較的多いです。
ここでのスパイラルモデル開発の流れの例としては
「要素設計」→「試作設計」→「量産試作設計」→「量産設計」
のような形になります。それぞれの中でサイクルを回していきます。（項目は開発により変化します）
メリット
・顧客の要求仕様の変更などに対応しやすい。
・設計工程が伸びて実装に費やせる期間が短くなるということが起きにくい。
・アジャイルモデルよりも比較的大きな規模では管理しやすい。
デメリット
・開発完了まで製品がリリースできない
製品がぼやけていたものから徐々に具現化する形
・アジャイル型開発
迅速に適応するようにソフトウェア開発を行う開発手法群の総称です。
ですが、ソフトウエアだけでなくハードウエアでもかなり有効です。
イテレーションと呼ばれる短い期間で細かな機能・部位に分けてPDCA(設計→試験→調査→改善)を回すことで、リスクを最小化しようとします。
1つの反復の期間は、1週間から1ヶ月くらいであることが比較的多いです。
ここでのアジャイル型開発の流れの例としては
「機能/部位」→「機能/部位」→「機能/部位」→「機能/部位」
のような形になります。それぞれの中でサイクルを回していきます。（項目は開発により変化します）
その中で顧客とのやりとりは、機能・部位ごとにかなり密接に行うことが多いです。
組合せを行う際はリグレッションテスト（回帰テスト：使えていた機能が使えなくなるバグを確認）をしなければなりません。
以下は複数同時に並列に行いながらアジャイル型開発の流れになります。
単体の場合はこの図の１つのラインになります。
メリット
・製品の機能に対する品質が保てる
・顧客の要望か通り製品になりやすい
・仕様変更から修正までが対応が早い
・納期に合わせて機能を制限しつつリリースできる
デメリット
・個々で仕様変更時の対応力が求められる
・顧客も含めて製品に最大限にしようとする意識が求められる
・コミュニケーションを密に取らないと対応ができない
・試験（テスト）方法がいい加減だと、品質が保てない
・組み合わせのたびにリグレッションテストをしないといけない
・当初の要求仕様と異なることが多い
・大きな規模になると機能ごとにチームが分かれる。
そのため、工程単位の専門家が分散するため、各工程の品質に差ができやすい。
製品が徐々に機能追加・部位追加していく形
開発の手法でどれを使えばいいの？
下記に説明する限りではありません。
所詮開発プロセスなので自社の強み、優先事項等を考慮すると、ここに記載した内容と全く異なることもあります。
・顧客の要求からの機能を制限できる場合
（納期・コスト優先、ただし導入した機能に対しての品質を求められる場合）
→アジャイル型開発
・顧客の要求から納期・コストを制限できる場合
（導入機能優先、納期とコストは当初の見積もりと差が出やすい）
→スパイラルモデル開発
・自社開発で自社の技術を高めたい、新製品を出したい場合
（リソースが多い、開発規模が大きい場合、管理をしっかりしたい場合、特定の顧客がない場合）
→ウォーターフォールモデル開発（V字、W字モデル含む）
開発プロセスは所詮開発の流れの一例になります。
それぞれに特徴があるため、それに合わせた開発方法や自社の開発方法の強みを最大限活かせるように開発プロセスも踏んでいきましょう。
開発プロセスは所詮開発の流れの一例。自社の強みの開発方法を見つけていくのが一番良い
こちらも開発プロセスの参考になります。
