品質管理ポリシー | miracleave株式会社

1. なぜ開発の初期段階でCI/CDを導入するのか

一般的な開発プロセスでは、デプロイ環境の準備やリリース作業が後回しにされる傾向があります。ソフトウェアエンジニアが目前の設計や実装に集中するあまり、システム結合といった工程がプロジェクトの最終段階に集中しがちです。

その結果、プロジェクトの終盤になって初めて、次のような問題が顕在化することが少なくありません。

リリースに必要なコンポーネントの不足
お客様との間に生じていた認識の齟齬
セキュリティ診断（脆弱性診断）での指摘

これらの問題がプロジェクトの最終盤で発覚すると、品質基準を満たすために手戻りが発生し、結果としてリリースの遅延へと繋がってしまいます。加えて、保守・運用期間が長期化するにつれ、品質計画が不十分なシステムは追加改修のコストやリスクが膨らみやすい傾向にあります。

2. miracleaveのアプローチがもたらす価値

miracleaveでは、このようなリスクを回避するため、開発プロセスの初期段階にCI/CDを導入します。これにより、以下の価値をお客様にご提供いたします。

進捗の可視化と早期フィードバック： 開発中のシステムが常に動作する状態に保たれるため、お客様にはいつでも進捗状況をご確認いただけます。これにより、早い段階で貴重なフィードバックをいただくことが可能となり、認識の齟齬を未然に防ぎます。
品質の維持： CI（継続的インテグレーション）の仕組みにより、ソースコードとシステム全体の品質は、常に高い水準で維持されます。テストの自動化により漏れや人的ミスを抑え、レビューを介して関係者間の認識のズレを防ぎます。
中長期でのコスト抑制と属人化の排除： 設計段階から品質を考慮することで、その後の追加・改修を容易にします。ビルド・デプロイ・リリースの自動化により人為的ミスを減らし、特定の担当者に依存しない体制を構築します。

近年、脆弱性に関する報告や、利用するフレームワークのバージョンアップの頻度はますます高まっています。開発開始時点の技術がプロジェクト終盤には陳腐化してしまったり、新たな脆弱性の原因となったりするリスクがあります。CIは、ソースコードを本流のブランチに統合する際に、品質基準を満たさないコードやセキュリティ上の問題があるコードの混入を自動的に防ぐ「品質ゲート」としての役割も果たします。

プロジェクト計画の段階から品質向上の視点を組み込み、各工程ごとにレビューを実施することで、計画で定めた品質基準の達成状況を確認しています。出荷判定基準を事前に定め、フェーズごとに品質に影響を与えるリスクが含まれていないかをチェックし、コスト・納期の増大を防ぐ取り組みを行っています。また、プロジェクトの範囲や役割分担の明確化、会議体や納品物などコミュニケーションルールの標準化、情報共有ツールの活用などにより、関係者間の認識のズレが生じないよう、円滑なコミュニケーションに努めています。

3. モックアップを活用した「手戻り」のない開発プロセス

miracleaveでは、システム開発に着手する際、要件定義が完了した直後にデータベース設計、バックエンド、フロントエンドといった各担当領域に分かれて実装を進める、という手法は原則として採用しておりません。これは、プロジェクト初期段階における関係者間の認識のズレが、後の工程で大きな手戻りを生む原因となりうるためです。

仕様書や口頭での確認だけでは、関係者間で意図した内容が正しく伝わっているか判断しづらいものです。実際に動作する形（ワイヤーフレーム、プロトタイプ、α版・β版など）で早い段階に確認して初めて、齟齬が明らかになることは少なくありません。

モックアップによる合意形成の容易化

miracleaveでは、要件定義や基本設計といった上流工程において、まずモックアップ（画面の試作品）を作成します。文章や言葉による仕様の確認だけでは、どうしても解釈の違いや誤解が生じやすくなります。そこで、実際に見て触れるモックアップを用いることで、視覚的かつ直感的に完成後のイメージを共有し、お客様との合意形成を取りやすくします。

モックアップを「動くもの」へと変えていく開発工程

開発工程では、基本的にこのモックアップをベースに進めます。データベース設計やフロントエンドの作り込み、APIおよびデータベースといったバックエンドとの連携を行いながら、モックアップを「動くもの」へと変えていく形でアプリケーションを構築していきます。完成イメージが明確に共有されたモックアップは、仕様の解釈に迷うことのない、信頼性の高い設計図として開発チーム全体で活用されます。

CI/CDとの連携による相乗効果

この開発プロセスにCI/CD（継続的インテグレーション/継続的デリバリー）を取り入れることで、モックアップはよりリアルに、そして実際に使えるものへと進化していきます。

CI/CDにより、開発の進捗に応じてお客様がいつでも触れる環境へと自動的にデプロイされます。その過程で、お客様との合意形成を積み重ねていくことが可能となります。こうすることで、認識の齟齬をなくしながら正確に実装を進めることができ、プロジェクトの終盤での手戻りを防ぎます。これが、モックアップを活用した開発手法がもたらす価値です。

4. 徹底したソースコード管理体制

利用環境とセキュリティ

ソースコードは、お客様からの特別なご指定がない限り、miracleaveが管理するクラウド環境上のGitLabにて一元管理いたします。複数の開発メンバーが参加するプロジェクトにおいても、一元管理によりレビューや変更履歴の共有がしやすく、ソースコードの品質を保ちやすい体制となっております。

この環境は、定期的な計画に基づきバージョンアップを実施し、二要素認証（2FA）を必須とすることで、セキュアな管理体制を構築しております。また、定期的なバックアップも取得しており、障害発生時にも開発資源を迅速に復旧できる体制を整えています。

権限管理とトレーサビリティ

miracleaveの情報セキュリティ基本方針に定められた「Need-to-knowの原則」（知る必要のある者のみが情報にアクセスできるという原則）に則り、ソースコードを本流のブランチに統合できる開発者を厳格に制限しています。さらに、誰が・いつ・どのような理由で変更を行ったかの記録をすべて管理しており、いつでも追跡可能な状態を維持しています。

AIエージェントを活用した開発における品質保証

昨今注目されているAIエージェントを活用した開発手法を取り入れる場合も、この品質管理プロセスを遵守します。AIが生成したコードであっても、必ず「Human-in-the-Loop」（人間が介在する仕組み）を徹底し、開発者による目視での厳密なレビューと承認を経てから、本流のブランチに統合されます。これにより、AI活用の効率性と人間による品質担保の両立を実現します。

5. 開発成果物の一元管理とトレーサビリティの確保

miracleaveでは、開発プロセスにおける透明性と追跡可能性（トレーサビリティ）を最大限に高めるため、以下の成果物を原則としてすべてGitリポジトリで一元管理いたします。併せて、課題管理ツールを用いたチケット管理により、タスクや不具合の共有を実現し、プロジェクト内外での情報の所在を明確にしています。

要件定義書
基本設計書
コーディング規約
ソースコード
各種マニュアル

従来の開発における課題

従来の開発現場では、要件定義書や設計書がExcel、マニュアルがPowerPointといったバイナリ形式のファイルで個別に管理され、ソースコードのみがバージョン管理システムの対象となる、といったケースが散見されました。このような環境では、成果物間の関連性が不明確になり、仕様変更時の影響範囲の特定や、過去の経緯の確認が困難になるという課題がありました。

また、ドキュメントは「誰が見ても理解できる内容か」「必要なものを必要な分量だけ作成しているか」といった観点で常に検証する必要があります。文書の整合性や仕様に関する認識のズレが、開発の進行とともに顕在化し、大きな手戻りにつながる事例も少なくありません。

miracleaveのアプローチ：すべてをテキストベースで管理

miracleaveでは、こうした課題を解決するため、プロジェクトの初期段階で作成する要件定義書から始まり、それを基に作成する基本設計書（※）、そしてソースコードに至るまで、開発に関わるすべてのドキュメントをGitリポジトリ上でテキストベース（Markdown形式など）で管理することを標準としています。

このアプローチにより、開発環境は常に「AI Ready」、すなわちAIによる解析や処理に適した状態に保たれます。これにより、AIを活用したドキュメントの要約、仕様書からのコード自動生成支援などを効率的に行うことが可能となります。

何よりも重要なのは、トレーサビリティが確立される点です。たとえば、あるソースコードがどのような意図で実装されたのかを確認したい場合、その根拠となる基本設計書の該当箇所を即座に参照できます。同様に、基本設計書は要件定義書にその根拠を求めることができます。

このように、すべての成果物が明確な階層構造で関連付けられることで、実装の根拠をいつでも容易に追跡することが可能となり、仕様変更への迅速な対応と、プロジェクト全体の品質維持に大きく貢献します。

※プロジェクトの特性により、ドキュメントの名称は異なる場合がございます。

6. 保守・運用フェーズにおける継続的な品質維持の重要性

システムの開発が完了し、保守・運用フェーズに移行した後も、その価値と安全性を維持し続けることは極めて重要です。品質を保たれたシステムは、追加・改修がしやすくビジネススピードの向上やリスクの低減に寄与します。一方、品質が十分でないと、追加改修のコスト増や陳腐化に伴うリスクの増大を招きがちです。

miracleaveではそのための最適なプラクティスとして、最低でも週に一度はCI（継続的インテグレーション）を定期的に稼働させることを強く推奨しております。

なぜ定期的なCIの稼働が必要なのか

システムを稼働させている間にも、それを構成するOS、ライブラリ、フレームワークは日々変化しています。サポート期間が終了したり、情報漏洩に繋がりかねない致命的な脆弱性が発見されたりすることは珍しくありません。

長期間CI/CDパイプラインを稼働させていないと、いざセキュリティパッチの適用や機能修正が必要になった際に、以下のような問題に直面するリスクが高まります。

ライブラリの依存関係が解決できず、ビルドが失敗する
OSやミドルウェアのバージョンが古く、修正に必要なソフトウェアが動作しない
環境の陳腐化により、予期せぬ不具合が多発する

長期間メンテナンスされていないシステムに急な変更を加えようとすることは、多くの手戻りを発生させ、結果として迅速な対応を妨げる大きな要因となります。

システムの「健康診断」を習慣に

定期的にCIを稼働させ続けることは、いわばシステムの「健康診断」を継続的に行うことに他なりません。適度な間隔でシステムのビルドやテストを自動実行することで、小さな問題を早期に発見し、深刻化する前に対処することが可能です。

このような健全な状態を維持することで、緊急の修正や機能追加が求められる不測の事態においても、検証済みのプロセスを通じて、迅速かつ安全に変更を適用することができます。

miracleaveは、開発時だけでなく、保守・運用フェーズにおいてもシステムの品質を維持し続けることが、お客様の事業継続性にとって不可欠であると考えております。このための継続的な取り組みについても、ぜひご相談ください。

7. お客様のビジネス環境に応える非機能要件

miracleaveでは、機能要件だけでなく、セキュリティ・性能・可用性・運用保守性といった非機能要件を、プロジェクトのご要望に応じて要件定義段階から議論・合意し、可視化することを重視しています。

ソフトウェア品質の国際規格であるISO/IEC 25010では、使用性、セキュリティ、信頼性、保守性などの品質特性が定義されています。当社では、これらの観点を参照しつつ、お客様のビジネス環境に合わせた非機能要件を整理・検討しています。

インフラの選定・構築、データ保護、セキュリティ対策については、CI/CDや本ポリシーで述べた開発プロセスと整合を取りながら、各プロジェクトの規模・用途・リスクに応じて適切な水準を提案いたします。お客様のご要望や規制要件にあわせた非機能要件の策定についても、ぜひご相談ください。

Quality Control Policy 品質管理ポリシー