こんにちは。GMOリサーチシステム部のかげです。
今年から、セキュリティ関連の業務を担当しています。
今回は、弊社の開発プロセスについて、紹介します。
開発プロセスについて
弊社の開発プロセスは、大きく分けて、「運用」と「開発プロジェクト」の2つがあります。
下記のプロセスがはいっているところがポイントです。
- 品質管理レビュー
品質担保のために設けているプロセス。
設計や実装の問題を、担当者以外がチェックすることにより、仕様の齟齬や想定外の不具合が防げるようにしています。
また、より最適な設計、実装方法を考えるポイントにもなります。
- 承認ゲート
こちらも品質担保のために設けているプロセスです。
では上記の「品質管理レビュー」と何が違うのかというと、こちらは監査で必要となるプロセスとなっています。
不要な開発が行われて、無駄なコストを発生させない、スケジュールの遅延や障害の要因となるような問題を事前に取り除く、というような目的で設置されています。
運用開発
業務からの要望、システム観点からの改善、バグフィックスなど、小規模開発。
スクラムを基本にしています。
Redmineの「Redmine Backlogs」プラグインを使ってタスク管理をしています。
| 項目 | プロセス | レビュアー/承認者 | 説明 |
| ①計画 | バックログ検討会議 | マネージャー | 2週間に1回開催します。※チームにより開催頻度が異なります。Redmine Backlogsブラグインの「バックログ」で、各スプリントのバックログを管理しています。2週間を1スプリントとしています。1チームで複数プロダクトを担当しているため、マネージャーが各プロダクトオーナーの意向や、要望の重要度/緊急度を把握しています。その他システムチームの意見も踏まえ、そのスプリントのバックログの一覧と、優先順位、リリース日を決定します。 |
| ②要件定義 | 詳細設計 テーブル定義・アーキテクチャ設計 レビュー財務報告目的 内部統制設計レビュー | アーキテクトCTOシステム部部長 | テーブル定義やアーキテクチャ変更があった場合に行います。 全体的な整合性、他機能への影響等を検証します。ポイントに関連する機能は会計に影響するため、仕様変更があった場合、会計への影響を含め、仕様が妥当かを検証します。 |
| ③開発・テスト | 開発・単体テスト ソースレビュー 単体テストレビュー 結合テスト | チーム内チーム内 | Redmine Backlogsプラグインの「かんばん」を利用して、詳細なタスクの洗い出しと進捗状況の管理を行っています。Githubを利用し、チームメンバー同士でレビューコメントをつけています。 チームメンバーからOKが出ないと開発完了できません。jenkinsを利用し、UTが全部OKであること、カバレッジが100％であることを確認しています。 |
| ④全体テスト・移行 | システムテスト/ユーザー受入テスト リリース承認 リリース リリーステスト/リリース受入テスト 事後作業 | マネージャー | テスト設計を事前に行い、チームメンバー同士でレビューします。 また、思い込みを防いだり、違う観点を入れるため、なるべく、担当者以外にもう一人テストをやるようにしています。設計、テストとも問題なく、リリースがしてよいかを最終確認します。週に一度、定時リリースがあります。リリースノートを書いたり、バックログを終了としたりします。 |
プロジェクト開発
ウォーターフォールを基本にしています。
プロジェクト全体のスケジュールはWBSを作成しています。
チームによっては、一部、RedmineのBacklogプラグインを使ってタスク管理をしています。
| 項目 | プロセス | レビュアー/承認者 | 説明 |
| ①計画 | インセプションデッキ作成 プロジェクト開始承認 | インセプションデッキをもとに、経営陣がプロジェクトの実施可否を判断します。 | |
| ②要件定義 | 業務要件定義 概要設計 詳細設計 システム運用設計 テーブル定義・ アーキテクチャ設計レビュー 財務報告目的 内部統制設計レビュー 再審議 リリース日決定 | アーキテクトCTO CTOシステム部部長 | （概要設計）そのシステムをよく知らない(忘れた)人にも、一目でわかるように、概要図を作成しています。 関連しているモジュール、データ、システム連携箇所等を記載しています。 障害対応時や引継ぎの際に、役に立っています。（再審議）詳細設計をもとに、再見積します。 ここで、最終的な開発の範囲やコスト、スケジュールを確定します。 |
| ③開発・テスト | 開発・単体テスト ソースレビュー単体テスト レビュー結合テスト | チーム内チーム内 | |
| ④全体テスト・移行 | 全体テスト開始判定 システムテスト ユーザー受入テスト サービスイン承認 リリース リリーステスト リリース受入テスト 事後作業 | マネージャー CTO システム部部長 | （全体）結合テストまでの状況と、全体テストの準備状況を確認し、全体テスト開始可能かを判断します。 バグの発生件数、それらについて修正が完了しているか、カバレッジが100%になっているかなどを確認します。（システムテスト）セキュリティテスト、システム運用テスト、負荷テスト、シナリオテストなどを行います。（サービスイン承認）全体テストの状況と、サービスインの準備状況を確認し、サービスイン可能かを判断します。 システムでは、システムテストが完了しているか、リリース手順・本番環境(新規作成時)の準備が完了しているかなどを確認します。 サービスでは、ユーザーへの告知、契約、トレーニング等が完了しているかを確認します。 |
終わりに
この開発プロセスは、2015年ごろ、弊社の基幹システムMarket Observer(以下MO)を大規模リプレイスするにあたり、動くものを見ないと具体的なアイデアが出てこないためスクラムを導入した際にまとめたのが始まりでした。
当初は、教科書通りににスクラムをやってみようとし、混乱したこともありました。
「ドキュメントは作らない」を曲解して、本当に必要なドキュメントを作る時間を確保できずに、現場で困ったり。
大規模にもかかわらず、スプリント会議で要件決めるんでしょ、ってとこからどんどん工数が膨らんでいったり。
監査で提出するエビデンスも、RCMの更新を含めて再定義となりました。
全体テスト開始判定やサービスイン承認は、チェックリストの記載とその承認ですが、実施する度に、そのリスト自体に課題がでてきて、都度見直ししていったりしました。
結果、抜け漏れが減っていき、単にエビデンスのためというのではなく、非常に意味のあるプロセスになっています。
その後、不要と思われるプロセスは自然に淘汰され、かなり最適化されてきました。
自分たちで、常に課題を見出して、改善していけるのは、弊社のシステム部の強みの一つだと思います。
また、お互いにレビューしたりテストしたりがうまく回るのも、チームに対する責任感や信頼感があるからです。
私は開発現場からは離れてしまい、少しさみしい思いをしていますが、新たなミッションである、セキュリティの分野で、ちょっとでも貢献できたらなと思います。
それでは、読んでいただきありがとうございました。
