Belong Inc. の実例を含めた SDLC の紹介

Belong Inc. CTO の tty です。本ブログではソフトウェア開発をする時に常に意識する SDLC について触れつつ Belong Inc. での取り組みを紹介します。

TL;DR

• SDLC はソフトウェアの品質を一定に保ち開発を進めるためのプロセス
• チーム全体が SDLC を意識する文化を持つことでプロセスが安定する
• ツールによる強制を用いて安定した SDLC を作る
• Belong Inc. では様々なツールや規則を導入して SDLC の実現をしている

SDLC は品質を保つためのプロセス

SDLC の概要

SDLC (Software (System) Development Life Cycle) とはソフトウェアの品質を保ちつつ開発を進めるためのプロセスです。ウォーターフォール型やアジャイルなどの開発手法を指し、実際の運用方針は組織毎に少しづつ異なりますが、目的はどれもソフトウェアの品質を保ち長期的な持続性を得るためという点は共通しています。本ブログでは特にプロセスを実現する方法に触れつつ話を進めます。

SDLC プロセスのフェーズ:

1. プランニングと分析
2. 開発
3. テスト
4. リリースと運用
5. #1へ

開発をアジャイル手法的に進める場合はソフトウェアを一度リリースして終わりではなく、継続的に機能追加や改善を行います。 SDLC の各フェーズを何度も繰り返すため各リリースの間を 1 サイクルと考えます。DevOps 同じものという印象を持つかもしれませんが、DevOps は SDLC を実現するために使えるものと考えています。

一般的に、ソフトウェア開発は以下の図1の流れで進みます。本記事では特に図中の開発開始後のプロセスに主眼を置いています。

SDLC Flow

SDLC の必要性

次に、SDLC が確立されている状態・されていない状態のはどのような特徴が有るかを挙げ、SDLC の必要性を説明します。

SDLC が浸透しているプロジェクトの特徴:

• 開発の目的や変更の履歴がわかりやすく、後から振り返ることも容易
• 個人の変更がチーム全体に共有されるには品質管理のためのレビューを経る必用がある
• 本番変更前にはテストが行われ、テストの結果は再現性・客観性の有るものとして残される
• 本番・開発(検証) 環境は別れており、変更を加えるための自動化プロセスが CI/CD のツールなどを用いて定められ、変更が起こったことはチーム内に共有される
• 運用中のソフトウェアのフィードバックを得る仕組みが整っており次の変更のプランニングにフィードバックが反映される

SDLC が守られていない例:

• 変更後テストによる確認なく即本番へリリースが可能
• 開発環境と本番環境が共存
• 各開発者が各々のタイミングで本番環境を変更する

上記のような特徴のある SDLC が浸透しているプロジェクトでは情報に透明性や即時性が生まれチームとして取り組みやすい状態になっています。問題が事前に発見されやすく、万が一問題が起きた場合でも素早い確認や対応が可能な状態になります。一方で SDLC が守られていない状況下では属人性が高まり、意図しない変更による問題も起きがちになります。

ここで、SDLC は全ての開発で必用というわけではありません。SDLC を構築し守るのは多少なり手間もかかり開発速度が落ちることもあります。例えば大学生が個人の研究で使うものや、1度だけ利用する分析レポートツールなどではプロセスに従うと余計な管理が必要になり返って効率が悪くなるかもしれません。
SDLC を守るべきプロジェクトは以下の特徴があるものです。

• 成果物は長期的な利用を前提にしている
• チームで開発に取り組む
• 問題が起きた場合に自分以外への影響が見込まれる

SDLC を保つための取り組み

SDLC を尊重する文化の浸透

SDLC を守りソフトウェア開発を健全に保つためにはチームのリーダーや主導者のみが気をつけるのではなく、それぞれの開発者が SDLC の重要性を理解し自主的に行動する必要があります。
SDLC の主導者はプロジェクトに張り付いて行動を監視することでプロセスを守りたくなるかもしれませんが、その形ではスケールせず、主導者不在のときには崩壊する可能性もあります。
健全な SDLC を保つためには、各開発者がプロセスの必要性を理解し、どういう状況では何をするべきという判断を各々出来るようになる必要があります。そのためには特定の人間が一方的に管理をするのでなく、最終的に達成したいことを共有し、プロセス自体はチームにフィットする形で柔軟に変更できた方が良いでしょう。

理想的にはただ予め定められたルールを守るだけではなく、チーム内で何が問題でどうしたら解決出来るのかという議論が自発的に生まれ、プロセス自体を有機的に発展出来るような環境を育てていくことです。
これが出来るようになると、後から入ってきたチームメンバーに対しても文化が伝播していき、チーム全体が自ずと問題が起こりやすい行動を避けるようになります。

SDLC の過程で達成したいこと例:

• 検証されていないコードが本番で使われない
• 本番環境に予期せぬ破壊的変更が入らない
• 再現性のない状況をつくらない

ツールによるサポート

チームに SDLC を守る意識がある場合にもツールによるサポートは必用です。
ツールを用いる目的は行動の再現性を高め、行動を制限することで手動での場当たり的な変更による意図しない変更を防ぐことです。
また、属人性を排除し同じルール・環境での行動が自然と必要になるためチームメンバーの入れ替わりにも対応しやすく、持続可能性が高まります。

ツールによるサポート例:

• git のコミットとチケットの紐付けを必須にし自動で確認する
• git ブランチのマージにはレビュー必須の自動検知がある
• 実環境へのデプロイ権限を個々人に与えず CI/CD ツールを用いてのデプロイを必須にする
• CI/CD 環境での自動テストや設定ファイルやプログラムの検証(lint や値のバリデーション) を行う

Belong Inc. における SDLC の実現

Belong Inc.では私自身が旗振り役となり SDLC を守ることを社員や協力会社を含めた全ての開発者にお願いしています。以下では SDLC を守るために Belong Inc. で実際に行っている取り組みやツールの使い方について紹介します。

プランニングフェーズ

開発タスクのプランニングには Jira のチケットを用います。プロジェクト企画段階ではユーザーストーリーマッピングを作成し、そちらを参考により粒度の小さいタスクをここで切り出します。
チケットを用いる目的は誰が・いつ・何の目的で作業を行うかを明確化するためです。チケットには期待する変更の内容・理由・受け入れ基準(テストで確認したいこと)を予め書き記すことでこれから開発を始める人が何をするべきなのか、後から振り返った時にどうしてその変更が行われたのかを理解できるようにしています。

開発フェーズ

開発中は git でバージョン管理を行っています。これは最近は常識となっていますが、Belong Inc. では git のコミットメッセージのプレフィックスに変更の理由となるチケット番号を入れることを pre-commit hook を用いて必須としています。これを行うことで変更で気になる点があった場合に git history を振り返り関連の在るチケットへ飛ぶことができ、プランニングや開発中であった議論や背景を簡単に理解できるようになります。
コミットメッセージ例: "JIRA-123 add new process function“

git のリポジトリのホスティングには Jira や Confluence と連携しやすい BitBucket を用いており、プロジェクトによって必須のレビュアーの指定や、ブランチの権限を設定することで SDLC から逸脱した行動を仕組み上取れないようにしています。
CI/CD には CiecleCI を用いており、コミットプッシュ毎にテストや lint が行われたり、適切なタイミングでの GAE や Cloud Run などのクラウド上の実行環境へのデプロイが行われ、間違いの起こりやすい手動でのデプロイは基本的に行わないようにしています。

テストフェーズ

テストでは可能なものから自動化しできる限り手動での作業が発生しない状態を目指しています。
リリースの前には開発ブランチからリリースのスコープに入っている変更を RC (Release Candidate) ブランチに退避し、RC ブランチに対して集中的なテストを行います。特に重要なシステムではテストの結果は再現性・客観性のある形で残す事が期待され、変更の性質や影響度に応じて必用なメンバーからの承認をそれぞれ得て初めてリリースが可能になるというルールで運用しています。これにより、リリース前にバグや期待しない変更を発見し本番環境での問題を防ぎやすくしています。

リリース・運用フェーズ

テストを経て承認の得られた変更は本番環境へとリリースされます。
リリースは基本的に CircleCI を用いて行われ、git 上で tag の作成をトリガーとして、自動通知を行う承認フローを経た上で実環境へのデプロイが行われます。
弊社では GCP をメインで利用していますが、本番環境は IAM を利用してアクセスを制限を厳し目に設定し、変更が必要な場合は terraform に記述、手動で変更する必要がある場合もコマンドで記述し他の人のレビューを通すという形を取っています。

おわりに

私が SDLC を意識するようになったのは新卒入社した投資銀行です。金融機関はシステム上のひとつのミスが数億円以上の(機会)損失を生み出すことが起こり得る環境であり、そういったバグやミスを極力防ぎシステムを安定稼働するための仕組みへ貢献をしていたのが SDLC をサポートするツールの整備と社員への意識付けでした。
Google でも利用するツール自体は異なりますが、チケットの利用やリリースまでのフローは近いものがあり、根底には同じ目的があることが理解できました。(問題の頻度やテストの重要性は会社ごとに異なる様に見えましたが、規模や複雑性が影響しているのかもしれません)

私自身業界をリードする会社でどういった SDLC が用いられているかを見てきましたが、 Belong Inc. でのアプローチは会社の規模を考えるとかなりレベルの高いものに既になっていると思います。
しかし、まだまだ専用のチームを持てないなどエンジニアリングリソースにも限りが在るため、できるだけ SaaS や OSS を用いて管理コストを抑えた方法を用いています。
エンジニアが更に増えてきたら、テストカバレッジを継続的に取得したり、サービス毎に散らばった権限やワークフローの管理を一元化するダッシュボードの作成といった改善をしていきたいと考えています。
弊社ではプロダクト開発のみでなく、本ブログで紹介した 開発のプロセスの改善にも興味のあるソフトウェアエンジニアや SRE を募集中です。ご興味の有る方は弊社採用ページよりお問い合わせいただけたら幸いです。
https://about.belong.co.jp/recruit/