Process
開発の流れ
プロジェクトの進め方
Case 1：品質と確実性を重視
妥協のない高品質の
システムを開発したい
【要求分析】どのようなシステムが必要なのかを明確にします。
どのようなシステムが必要なのかを明確にします。
システムがどのような機能を必要とするのかを明確にします
必要な機能をどのように実現するのかの骨格を検討します
システムをどう実装していくかの詳しい検討を行います
プログラムを記述し、製作を行います。単体テストはテストコードを記述します。
フロントエンドとバックエンド、また外部システムを繋ぎあわせた際に不具合がないか確認します。
機能を横断してお客様が実現したいシステムとなっているかを確認します。
開発されたシステムが要件通りか、お客様にご確認いただきます。
メリット
しっかりと認識を合わせた後に開発に入るため、完成イメージのズレや開発途中の手戻りを防ぎ、計画通りにプロジェクトを進行できます。また、網羅的なテストを行うため、限りなくバグがない状態でリリースできます。ドキュメントがしっかり残るため、開発中も運用中も属人性をなくすことができます。
デメリット
要件定義や設計、それらの承認に多くの時間を使うため、合意がなされないと開発が遅延します。その結果リリースが予定通り行えない可能性があります。初期の設計段階で要件を固めるため、初期の投資コスト（予算・期間）は大きくなる傾向にあります。仕様変更をする場合は追加でお見積もりとご了承を得てからの着手となります。
Case 2：費用対効果を重視
まずは形にして
ビジネスを
前に進めたい
【要求分析】どのようなシステムが必要なのかを明確にします。その後、概算見積もりを行います。
どのようなシステムが必要なのかを明確にします。その後、概算見積もりを行います。
Q &Aや資料を作成して要件のヒアリングと開発の合意を行います。
画面ワイヤーで機能やレイアウトの認識合わせをします。デザインや内部の設計も並行して行います。
プログラムを記述し、製作を行います。単体テストはテストコードを記述します。
疎通試験と結合試験をミックスしたようなもの。業務シナリオレベルでの試験は行いません。
開発したシステムが要件通りか、お客様にご確認いただきます。
メリット
資料作成や意思決定にかかるコミュニケーションコストが抑えられるため、設計にかかる費用や期間を減らせます。テスト工程を簡略化することで、細かいバグや潜在的なバグは残ってしまう可能性が上がるものの、必要以上に網羅的なテストを行わないことでコスト削減になります。
デメリット
仕様を資料で逐一確認することはなく、当社のノウハウに基づき最適な仕様をスピーディーに判断・進行します。デザインや操作性にこだわりがある場合は事前にご相談が必要です。完成後の仕様変更は確定の範囲内で修正させていただき、それ以上のご要望は別途お見積もりで追加対応となります。
納品物について
要件定義書
- 機能要件
- その他要件合意の必要に応じたもの
システム設計書
- 機能一覧
- 画面遷移図
- 画面設計
- デザイン（Figma）
- API仕様書※画像1
- インフラ構成図
ソースコード一式※画像2
要件定義書
単体テストコード
要件定義書
結合試験仕様兼結果報告書
要件定義書
総合試験仕様兼結果報告書
要件定義書
受入試験仕様書
必要に応じて
システム開発の方法
システム開発には、大きく分けて2つのモデル（方式）があります。
当社はシステム開発を柔軟に進める「アジャイルモデル」を採用するケースが多いですが、
お客様の予算やスケジュールに応じて柔軟に対応しています。
ウォーターフォール
一連のシステム開発の工程を上流から下流に向けて流れるように進め、戻ることなく一方通行に進めるモデルです。「滝」になぞらえてウォーターフォールと呼ばれます。
メリット
- 緻密に要件を固めるので品質を担保しやすい
- 進捗の把握をしやすく計画的に工程を進められる
デメリット
- 不具合発生時に復旧する時間とコストがかかる
- 前工程が終わらないと進まないため時間がかかる
アジャイル
設計段階で詳細を固めすぎずに、開発状況に応じて臨機応変に変更や修正を加えるモデルです。「アジャイル」は日本語で「俊敏な」という意味で、柔軟にスピーディーに進められるのが特徴です。
メリット
- 要件を固めすぎずに進められる
- 開発スピードが早いため新規事業などに向いている
デメリット
- 工程の進捗や状況を把握するのが困難
- 担当者の責任範囲が不透明になりやすい
お仕事のご依頼・ご相談は
こちらから
システムやDX推進で課題を解決したいとお考えの方は
お気軽にお問い合わせください。ワンストップで最適な提案をします。