ソフトウェアをシンプルに保ち、ビジネス上の様々な要求に応えやすくするためには、開発者の活動を支援する様々な自動化やアーキテクチャ設計への投資が必要不可欠です。
ですが、目に見える機能と異なり、ソフトウェアの中身に宿る品質への投資は経営者やエンジニアでないものには理解されにくいものです。
目に見えない投資について、「見える化」をしながら改善がなされていることが重要な視点です。
1.バージョン管理
なぜ重要か
ソースコードのバージョン管理は、最も基礎的な開発者の習慣です。 このような習慣がない場合、共同でソフトウェアを開発すること自体が困難になり、属人化したノウハウや暗黙的なルールの温床になりえます。また、GitHubなどのサービスはさまざまな開発者向けツールの起点となる重要な基盤でもあります。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-1-1 | メトリクスの計測 | バージョン管理システムの履歴情報(Code Churn)の分析をもとにバグ予測や品質上の問題を指摘するツールを導入し、継続的に改善しているか。 |
SYSTEM-1-2 | 学習と改善 | 明文化されたブランチ戦略が存在するか。そして、それは守られているか。 |
SYSTEM-1-3 | プラクティス | すべてのアプリケーションコードをGit/GitHubなどのバージョン管理システムで自社管理しているか。（権利を有する全てのソースコードについて、自社がアカウントを管理する統一のバージョン管理システムで扱っているか） |
SYSTEM-1-4 | プラクティス | インフラ構成とシステム要素のプロビジョニングをソースコードとして実行可能な形式にした上で、バージョン管理システムで管理しているか。（Infrastructure as Code） |
SYSTEM-1-5 | プラクティス | 統合テスト/デプロイメントの自動化に関わるソースコードをアプリケーションコードと同一のバージョン管理システムで管理しているか。 |
SYSTEM-1-6 | アンチパターン | ソースコード自体のセキュリティレベルを高く設定しており、開発支援系SaaSの利用を禁止している。 |
SYSTEM-1-7 | アンチパターン | バージョン管理システムが複数存在していたり、１つのツールからすべての履歴を閲覧できないなど、中途半端な状態のままになっていないか。 |
SYSTEM-1-8 | アンチパターン | システムのソースコードの閲覧を関連するエンジニアのみに限定している。（別チームのエンジニアや他のステークホルダーが閲覧できない。） |
2.ソースコードの明確さ
なぜ重要か
複雑なソースコードは、それだけで自動的なテストを難しくしバグや障害を生み出しやすいだけでなく、開発者のモチベーションや生産性に悪影響を与えます。 ソフトウェアの内部的な品質は経営から不可視であるため軽視される傾向がありあす。だからこそ、十分な注意をはらい続けなければなりません。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-2-1 | メトリクスの計測 | アプリケーションコードの循環的複雑度などのメトリクスを、ツール/サービスを用いて継続的に計測しているか。 |
SYSTEM-2-2 | 学習と改善 | デッドコードを四半期以上のサイクルで定期的に棚卸しし、削除や分解をしているか。 |
SYSTEM-2-3 | プラクティス | コードレビューをする習慣や規則があり、本番用ブランチ(master / mainなど)へのマージはコードレビューを必須としているか。 |
SYSTEM-2-4 | プラクティス | 明文化されているコードレビューガイドラインが存在するか。 |
SYSTEM-2-5 | プラクティス | コードレビューガイドラインを満たさないコードを自動的に検出・補正する各種Linterやフォーマッタなどのツール群を整備しており、ソースコードを変更する誰もが使うことができるか。 |
SYSTEM-2-6 | アンチパターン | コードレビューをできる人物がチームの中におらず、レビュー待ちに1、2営業日がかかる。 |
SYSTEM-2-7 | アンチパターン | コードレビューガイドラインは１年以上メンテナンスされておらず、形骸化している。 |
SYSTEM-2-8 | アンチパターン | コードレビューガイドラインの多くの項目が、自動的なフォーマッタなどで統一・解決可能な些末な事柄である。 |
3.継続的インテグレーション
なぜ重要か
継続的インテグレーションとは、自動的で定期的に実施される結合テスト環境のことです。 この環境が簡単でかつ信頼できるほど、開発者は誰かの手作業によるテストを待つ必要がなくなり、自分の手元でソースコードの改善を繰り返しやすくなります。これは生産性と品質向上に寄与します。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-3-1 | メトリクスの計測 | すべてのインテグレーションテストにかかる時間が計測されており、それは30分以内に完了するか。 |
SYSTEM-3-2 | 学習と改善 | テストカバレッジ基準や自動テストガイドラインを用意し、これらを継続的に改善するための工数がチームで割かれているか。 |
SYSTEM-3-3 | プラクティス | プロダクトの半分以上のモジュール/クラスファイルに対して、ユニットテストが存在しているか。 |
SYSTEM-3-4 | プラクティス | テスト用データやスタブ/モックなどを整備し、テストを書きやすくするための環境整備をしているか。 |
SYSTEM-3-5 | プラクティス | 継続的インテグレーション環境が存在し、開発者は開発ブランチの全テストをリソース調整することなく、自由に行うことができるか。 |
SYSTEM-3-6 | アンチパターン | 一部の人だけがテストを書き、一部の人はテストを書かないといったように自動テストを個々人の努力目標などになっている。 |
SYSTEM-3-7 | アンチパターン | テスト自体が複雑になって、長期間メンテナンスされていない。 |
SYSTEM-3-8 | アンチパターン | 自動テストが失敗したまま、そのコードが本番デプロイされることを許容している。 |
4.継続的デプロイ
なぜ、重要か。
継続的デプロイとは、完成したソースコードを自動的かつ簡単・安全にサービスインするための仕組みです。 この環境への投資が整っていない場合、開発者は本番環境のリリースのたびに様々な作業負荷がかかり、仮説検証や継続的な品質改善に対しての足止めになってしまいます。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-4-1 | メトリクスの計測 | デプロイ頻度とデプロイ成功率を継続的に測定しており、これらを改善することを目標管理しているか。 |
SYSTEM-4-2 | 学習と改善 | デプロイ時に社内のユーザーや開発者のみを対象もしくは、一部のサーバのみにサービスをリリースしてエラーがないかを確かめるカナリアリリースができるか。 |
SYSTEM-4-3 | プラクティス | デプロイ完了時、および構成変更時にインフラ構成に関する自動的なテスト(e2eのスモークテストおよびServerspecなどのインフラ環境テスト)を実行しているか。 |
SYSTEM-4-4 | プラクティス | ブルーグリーンデプロイメントができるか。（稼働中のサーバーを切り替えるのではなく、別環境にデプロイ作業をしてから本番の向き先を切り替えるデプロイ手法。） |
SYSTEM-4-5 | プラクティス | デプロイ作業を伴わず、一部の機能を安全にオフにしたり、オンにしたりできるか。( Feature Toggle /Soft Launch/ Dark launchなどの仕組みを導入・実装しているか。) |
SYSTEM-4-6 | アンチパターン | デプロイされたコードに問題が発生した際に、前のバージョンへの切り戻しを意思決定してから5分以内に切り戻すことができない。 |
SYSTEM-4-7 | アンチパターン | 開発者のメンバー自身が、権限を持つ人物の承認があっても、自分のコードを本番環境にデプロイできない。 |
SYSTEM-4-8 | アンチパターン | デプロイ工程が自動化されておらず、本番反映に1時間以上かかっていたり、特定の時間帯しかできないなどの制約事項がかかっている。 |
5.API駆動開発
なぜ、重要か。
ネットワーク経由のAPIを基準にシステムを開発することで、他のシステムと連携しやすくなります。 またシステムがレガシー化した際に交換したり、改善したりといった手が打ちやすいものになります。 人が使う見た目の作りだけでなく、エンジニアにとっての作りが質を生み出します。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-5-1 | メトリクスの計測 | 社内外のAPIの利用者にとってのユーザビリティについてヒアリング/アンケートを行い継続的な改善が行われているか。 |
SYSTEM-5-2 | 学習と改善 | 各APIについて、動作するインタラクティブなドキュメントや管理サービスを持っているか。 |
SYSTEM-5-3 | プラクティス | プロダクトに対して外部あるいは内部の別のシステムと連携するためのAPIが提供されているか。 |
SYSTEM-5-4 | プラクティス | APIは何らかのSchema定義言語によって規定され、そこから自動的にクライアントの生成やバリデータの生成が行われているか。 |
SYSTEM-5-5 | プラクティス | APIに関わる要件は、SDD(スキーマ駆動開発)で開発され、直ちにモックアップサーバーが提供できるか。 |
SYSTEM-5-6 | アンチパターン | ViewやControllerの層に処理が集中しており、機能をAPIに切り出すことが困難な設計になっている。 |
SYSTEM-5-7 | アンチパターン | 各APIに対して、ネットワークを経由したE2E(ステージング・本番どちらに対するE2Eテストかは問わない)のテストが存在しておらず、死活監視ができていない。 |
SYSTEM-5-8 | アンチパターン | APIがバージョン管理されておらず、破壊的な変更が利用者から検知できない。 |
6.疎結合アーキテクチャ
なぜ、重要か。
システムの役割は単純であればあるほど、高速に改善しやすくなります。 複雑な問題を解くときに単純な問題の組み合わせにするというのは重要な設計技術です 疎結合なアーキテクチャとは、このように改善する単位を単純に保つための技術です。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-6-1 | メトリクスの計測 | 目指すべきアーキテクチャに対してそぐわない点を洗い出すための仕組みが存在しており、それらの情報をもとに改善を進めているか。（アーキテクチャ適応度関数） |
SYSTEM-6-2 | 学習と改善 | システムアーキテクチャの決定・変更・改善に関するドキュメントを管理し継続的な学習機会を設けているか。 |
SYSTEM-6-3 | プラクティス | ドメインイベントの発火に伴いPublish/Subscribeモデルを利用した仕組みで、関連サービスとの連携が可能か。またその履歴データが保存管理され、これらのイベントリプレイから再突合や監査の自動化が可能か。 |
SYSTEM-6-4 | プラクティス | 結果整合性を考慮したサービスレベルの合意が要件のガイドラインの中に組み込まれているか。 |
SYSTEM-6-5 | プラクティス | バッチ、ジョブ、プロシージャに対する冪等な設計ガイドラインが存在しており、再送によって整合性が担保できるようなシステムになっているか。 |
SYSTEM-6-6 | アンチパターン | １つのデータベースに対して複数のシステムからの直接的な参照または書き込みがなされていて、それらの依存性が簡単には追跡できない状況になっている。 |
SYSTEM-6-7 | アンチパターン | 疎結合なシステムであるが、分散トレーシングの仕組みがなく、問題発生時の原因特定に時間がかかる。 |
SYSTEM-6-8 | アンチパターン | 自動テストとスキーマ定義の存在しない外部システムとの依存関係が１０ケース以上存在しており、機能開発の影響範囲を特定できない。 |
7.システムモニタリング
なぜ、重要か。
システムの品質は、エラーや障害などから学び改善していくことで生まれます。 そのためには、エラーや障害について検知し、復旧するためのモニタリングとその改善を支援するための文化と技術が必要になります。 ミスを許さない懲罰的な文化のもとでは、重大事故が起きやすくなります。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-7-1 | メトリクスの計測 | SLI/SLO/エラーバジェットがビジネスオーナーとエンジニアが協議して合意の上設定され、計測されているか。 |
SYSTEM-7-2 | 学習と改善 | 開発と SRE が共有する障害報告リストがあり、それぞれに有効な再発防止の仕組みが整うようにリソースを割いているか。 |
SYSTEM-7-3 | プラクティス | APMのためのSaaSやツールが導入され、ユーザーからみた応答速度などについて、要因ごとの影響度を定常的に分析できる状態になっているか。 |
SYSTEM-7-4 | プラクティス | フォルトインジェクションテストや、カオスエンジニアリング等の仕組みを導入することで、重大事故につながりうるシステムの欠陥を早期に発見するための試みをおこなっているか。 |
SYSTEM-7-5 | プラクティス | オートスケールなどの仕組みにより、開発者やSREが介在しなくても、適切なキャパシティコントロールができているか。 |
SYSTEM-7-6 | アンチパターン | 障害の発生に対しての罰則や謝罪などの、開発者が萎縮したり障害を隠蔽する方向につながるような慣習が存在する。 |
SYSTEM-7-7 | アンチパターン | 定常的に発生しているサービス上の警告を問題ないものとして無視したり、ログ自体を出さないようにしている。 |
SYSTEM-7-8 | アンチパターン | システム構成要素の構築方法や運用方法が属人化しており、同じインスタンスを構築できない。 |
8.セキュリティシフトレフト
なぜ、重要か。
ソフトウェアが完成したあとにセキュリティの課題が見つかると、そのための対応に追われたり、リリースが遅れたりと良いことがありません。 できる限り早い工程でセキュリティの課題を見つけ出す技術と文化を、DevSecOpsあるいはセキュリティのシフトレフトと言います。
| Name | PointOfView | Criterion |
|---|---|---|
SYSTEM-8-1 | メトリクスの計測 | CI/CDのパイプラインにソースコードの自動的なセキュリティチェック（静的解析または動的解析）が組み込まれていて、一定の基準を達さないとリリースされない仕組みになっているか。 |
SYSTEM-8-2 | 学習と改善 | セキュアコーディングについて、開発者を対象とした教育カリキュラムや研修を実施しているか。 |
SYSTEM-8-3 | プラクティス | 専門的なアプリケーションセキュリティの知識を持つメンバーが、専任でセキュリティチームにおり、動向や最新情報をもとに自社サービスをレビュー・改善できているか。 |
SYSTEM-8-4 | プラクティス | OSSのライブラリやミドルウェアを使用する際、それらの脆弱性情報を自動的モニタリング・警告・パッチ適用するための仕組みまたはサービス等を利用しているか。 |
SYSTEM-8-5 | プラクティス | 4半期から1年の間で定期的に、全体的なアプリケーションとインフラの脆弱性診断を受けているか。 |
SYSTEM-8-6 | アンチパターン | 開発速度（デプロイ頻度）を低下させるようなセキュリティルールが、施行されていて現況に合わせたアップデートが行われていない。 |
SYSTEM-8-7 | アンチパターン | ソースコード中に、漏洩してはならない情報がハードコーディングされている。（それらを分離して管理するようなツールまたは仕組みを導入しているか） |
SYSTEM-8-8 | アンチパターン | 開発企画要件の段階で、設計レベルのセキュリティレビューが実施されていない。(Security by Designの未実施) |