DX Criteriaから学ぶDX基礎知識（Vol.2 システム編）

![ダウンロード (7).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/c9287fd3-a252-515e-5055-e7e7ce27f6dd.png)

# はじめに
企業内でシステム開発に携わる方々に向け、以前こちらの記事で[日本CTO協会](https://cto-a.org/)の「[DX Criteria](https://github.com/cto-a/dxcriteria)」をご紹介しました。

[技術負債の削減に向けた提案～「DX Criteria」の活用～ - Qiita](https://qiita.com/yasuoyasuo/items/4dab8988ce793603265c)

この「[DX Criteria](https://github.com/cto-a/dxcriteria)」は、DXに前進させる上で有益な指針かつチェックリストであり、弊社でも積極的に活用しています。

ただ資料中には前提知識を要する言葉もいくつか登場し、経験年数や職種を超え幅広いメンバーが正しく理解を深めるには一定の時間がかかりました。

そこでより多くの企業やチームの方に「[DX Criteria](https://github.com/cto-a/dxcriteria)」を活用読んでいただくために、弊社内で用意した資料に出てくる用語や背景をまとめたメモを、再構成の上こちらで公開することにしました。

今回は5つのテーマの中から、「システム」についてご紹介します。他のテーマについても順次公開していきたいと思います。お役に立てば幸いです。

関連記事
- [DX Criteriaから学ぶDX基礎知識（Vol.1 チーム編） - Qiita](https://qiita.com/yasuoyasuo/items/94e66f2151a31c2aec11)

# 「[DX Criteria](https://github.com/cto-a/dxcriteria)」のおさらい
![ダウンロード (8).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/3c8097d5-83f9-c684-2ee5-b50c5e0f717d.png)
![ダウンロード (11).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/037e6022-02ee-42db-3940-526062274823.png)

# （2）システム
![ダウンロード (22).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/38880614-49f7-f334-f0fe-508c70688b4d.png)

## 01 バージョン管理
![ダウンロード (23).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/4e715bac-9bef-e723-3d8b-488e7ee54071.png)

###Code Chum：
どのくらいのコードが追加・削除・変更されたかという情報から、開発ステージごとのコードの安定性を見る指標です。
複数人で複数回にわたって編集されたファイルは複数の目的でコードが編集されている訳ですから、「単一責務原則」を違反している可能性が高く、潜在的にバグを内在していそうだということです。

参考：[アジャイル開発におけるメトリクスには、どういうものがあるのか - ソフトウェアの品質を学びまくる2.0](https://www.kzsuzuki.com/entry/agileMetrix)
[あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita](https://qiita.com/hirokidaichi/items/5a5cb63ef5499143bc40)

###ブランチ戦略：
Gitを利用する際のブランチの運用ルール。
「機能Aと機能Bの開発を同時に進めたいが、各々影響を与えあわない状況下で同時に開発を進めたい」といった場合に活躍する仕組み。

参考：[ブランチ戦略とは - Qiita](https://qiita.com/pi-su/items/01837215ed230f7507f2)

###プロビジョニング：
自律コンピューティングによるハードウェアの自動構成やサーバの自動起動、仮想化されたコンピューティングリソース（CPU、メモリ、ストレージ、アプリケーションなど）をオンデマンドかつ動的に割り当てる技術などをいいます。

参考：[プロビジョニング（ぷろびじょにんぐ） - ITmedia エンタープライズ](https://www.itmedia.co.jp/im/articles/0606/18/news005.html)

###Infrastructure as Code：
AnsibleやChefなどのプロビジョニングツールを利用し、インフラ構成や設定内容をコード化すること。ソフトウェアと同様にバージョン管理が可能になると同時に、共有化再利用が可能となります。クラウド化により環境移管が容易になることでその価値は高まります。

参考：[Infrastructure as Codeの留意点とメリット　～サーバー更改プロジェクトへの適用で得られた知見・実感　 - アイマガジン｜i Magazine｜IS magazine](https://www.imagazine.co.jp/infrastructure-as-code%E3%81%AE%E7%95%99%E6%84%8F%E7%82%B9%E3%81%A8%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88%E3%80%80%EF%BD%9E%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E6%9B%B4%E6%94%B9%E3%83%97%E3%83%AD/)

## 02 ソースコードの明確さ
![ダウンロード (24).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/6a19d5a3-6450-8b9f-0e09-6832a4cec2b6.png)

###循環的複雑度：
ソフトウェア測定法の一種。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われます。
プログラムのソースコードから、線形的に独立した経路の数を直接数えます。

参考：[循環的複雑度について - Qiita](https://qiita.com/yut_arrows/items/16749e02313109071338)

###デッドコード：
コンピュータ・プログラムの一部として存在するが、決して実行されないコードのことをいいます。

参考：[到達不能コード - Wikipedia](https://ja.wikipedia.org/wiki/%E5%88%B0%E9%81%94%E4%B8%8D%E8%83%BD%E3%82%B3%E3%83%BC%E3%83%89)

###Linter：
エディタ上でlint（コンパイラやインタープリタよりも厳しくソースコードをチェックするプログラム）に引っかかるようなコードの書き方が良くない部分を指摘してくれるものをいいます。

参考：[linter を使ってコードレビューのコストを削減する - Qiita](https://qiita.com/fiftystorm36/items/f8ad30ea5eb92c36a6ed)

## 03 継続的インテグレーション
![ダウンロード (25).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/26d0d4d0-1e6f-8504-9a52-313fe4bd4da0.png)

###テストカバレッジ：
ソフトウェアテストにおいて、対象のプログラムがテストによってどこまで実施されたのか網羅する割合をいいます。

参考：[ホワイトボックステストの必須知識！　コードカバレッジをご紹介！ | Qbook+](https://www.valtes.co.jp/qbookplus/865)


## 04 継続的デプロイ
![ダウンロード (26).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/ddea6f52-cad0-084d-0c93-35d5047f917f.png)

###カナリアリリース：
プロダクトやサービスの新機能を一部ユーザーのみが利用できるようにリリースし、新機能に問題がないことを確認しながら段階的に全体に向けて展開していくデプロイ手法のことをいいます。

参考：[カナリアリリースとは 意味/解説 - シマウマ用語集 - マーケティングやビジネスの用語集](https://makitani.net/shimauma/canary-release)

###スモークテスト：
開発・修正したソフトウェアを実行可能な状態に組み立て、起動するかどうかや基本的な機能が動作するかなどをざっと確認することです。

参考：[Qbook - 用語集](https://www.qbook.jp/qpterm/search?keyword=smoke%20test&link=1)

###Serverspec：
サーバー向けのテストフレームワーク。Rubyで実装されており、RubyやRuby向けのテストフレームワーク「RSpec」の機能を活用して構築されています。LinuxなどのUNIX系サーバーだけでなく、RubyがインストールされていればWindows環境でも利用できます。

参考：[「Serverspec」を使ってサーバー環境を自動テストしよう | さくらのナレッジ](https://knowledge.sakura.ad.jp/2596/)

###ブルーグリーンデプロイメント：
現状の本番環境（ブルー）とは別に新しい本番環境（グリーン）を構築した上で、ロードバランサーの接続先を切り替えるなどして新しい本番環境をリリースする運用方法のことをいいます。

参考：[3分でわかる ブルーグリーンデプロイメント | 日経クロステック（xTECH）](https://xtech.nikkei.com/atcl/nxt/keyword/18/00002/070800077/)

###Feature Toggle：
システムの一部機能をon/off可能にしておく仕組みです。

参考：[システム開発全般 | Feature Toggleによるリリース機能制限とそのリスク - Tbpgr Blog](http://tbpgr.hatenablog.com/entry/20131203/1386078587)

###Soft Launch：
新製品や新サービスの販売に先駆けて、限定地域・対象にのみ試験的に公開することをいいます。

参考：[soft launch（ソフトローンチ）の意味 - goo国語辞書](https://dictionary.goo.ne.jp/word/%E3%82%BD%E3%83%95%E3%83%88%E3%83%AD%E3%83%BC%E3%83%B3%E3%83%81/#jn-285505)


###Dark launch：
新機能のリリースをこっそり一部のユーザーにだけ行うことをいいます。

参考：[安全に新機能を公開できるダークローンチ(Dark Launch)とは何か - Qiita](https://qiita.com/devneko/items/bdbe61e2b432a35a18cd)

## 05 API駆動開発
![ダウンロード (27).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/980ceb69-e7f5-2fa4-a881-09b14be8c5a5.png)

###Schema定義言語：
おもにAPI仕様を記述するための言語。

参考：[API 記述言語や API ドキュメンテーションツールの比較（Swagger、API Blueprint、RAML） - Qiita](https://qiita.com/tetsukamp/items/a05f40fcab6d528b1e4f)

###モックアップサーバー：
開発(テスト)用のJSONをRESTfulに提供するHTTPサーバ。

参考：[オープンソースのAPI連携 / JSON Serverとは](https://www.ossnews.jp/oss_info/JSON_Server)
　　　[JSON ServerでRestAPIのモックを作成した話 - 弥生開発者ブログ](https://tech.yayoi-kk.co.jp/entry/2018/06/25/120611)

## 06 疎結合アーキテクチャ
![ダウンロード (28).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/ff274934-e153-3464-321c-53c909de9abb.png)

###アーキテクチャ適応度関数：
アーキテクチャに求められる要件を定量化し、それを評価するテストコード（これが関数。つまりプログラミングにおけるfunctionである。）を書き、テストして目標を満たしているか評価します。

参考：[システムにおける適応度関数 〜進化的アーキテクチャを読んで〜 | サムワンズドードー](https://someonesdodo.site/2019/02/16/summary_evolutionary_architectures/)

###ドメインイベント：
ドメイン駆動設計（DDD）で定義。ドメインモデルの一部であり、ドメイン内で発生する何かの出来事を表します。

参考：[実践DDD本 第8章「ドメインイベント」～出来事を記録して活用～ (1/3)：CodeZine（コードジン）](https://codezine.jp/article/detail/10392)

###冪等（性）：
同じ操作を何度繰り返しても、同じ結果が得られることをいいます。

参考：[冪等性とは「同じ操作を何度繰り返しても、同じ結果が得られる性質」のこと - Qiita](https://qiita.com/suin/items/316cb8aaf8dfcf11abae)

###分散トレーシング：
分散されたシステムで処理されるリクエストを追跡（トレーシング）するためのものをいいます。

参考：[分散トレーシングシステムのZipkinを使ってみた話 - Qiita](https://qiita.com/miya10kei/items/2532b80fcd8d19eb2e75)


## 07 システムモニタリング
![ダウンロード (29).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/fc329eb7-6fd2-af92-8b55-eee39380e607.png)

###SLI：
システムの信頼性/安定稼働というものををどう計測するかの指標をいいます。

###SLO：
SLIの数値をモニタリングして、何をもってシステムの信頼性が高いと言えるか、安定稼働しているといえるかの基準値です。

###エラーバジェット：
損失可能なシステムの信頼性、許容できる可用性低下の妥協点をいいます。

参考：[システムのスピードと品質を両立する為のエラーバジェットとSLI/SLOという考え方 - Qiita](https://qiita.com/SoarTec-lab/items/992b9ddfe7838932c3b1)

###APM：
主に企業の基幹システムなどを担うWebアプリケーションのレスポンス状況を監視したり、さまざまな機能の応答時間を調べたりすることにより、アプリケーション全体の稼働状況を管理するシステムをいいます。

参考：[APM（アプリケーション性能管理）ツール6選 | ニーズが高まる理由・重要性を解説 - アプリケーション性能管理 | ボクシルマガジン](https://boxil.jp/mag/a3041/)


###フォルトインジェクションテスト：
システムが欠陥を検出し、欠陥から復旧できることを確認する目的で、意図的に欠陥をシステムに追加するプロセス。フィールドで発生する可能性のある故障を模倣することを目的とします。

[Qbook - 用語集](https://www.qbook.jp/qpterm/search?initial=F)

###カオスエンジニアリング：
本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にもちゃんと耐えられるようにしようとするもの

参考：[カオスエンジニアリングと聞いてカオスになった人必見 - Qiita](https://qiita.com/naokiiiii/items/de20997a70922c01f754)

## 08 セキュリティシフトレフト
![ダウンロード (30).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/14ce8a5f-e82f-ff17-f119-7ecfdd45d9ae.png)

###DevSecOps：
ソフトウェアもしくはITサービスの開発から運用をするためのDevOpsプロセスにセキュリティ対策を組み込んだものです。
![TH400_001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131112/59587927-b717-1472-0f2f-174dc2aa637b.png)

参考：
- [第1回　DevOpsからDevSecOpsへの近道（前編）：コードの安全性・安定性を高める開発サイクル ～テスト管理の効率を上げ，脆弱性診断を自動で行う～｜gihyo.jp … 技術評論社](https://gihyo.jp/dev/serial/01/code_dev_cycle/0001)
- [マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント：特集：マイクロサービス入門（終） - ＠IT](https://www.atmarkit.co.jp/ait/articles/2003/17/news004.html)

###セキュアコーディング：
攻撃者やマルウェアなどの攻撃に耐えられる、堅牢なプログラムを書くことをいいます。

参考：[なぜ、いま「セキュアコーディング」なのか？ (1/2)：もいちど知りたい、セキュアコーディングの基本（1） - ＠IT](https://www.atmarkit.co.jp/ait/articles/1210/24/news005.html)

# 最後に

色々と「DX Criteria」を周りの皆様ご紹介したところ

- 「DX Criteria」を使ってみたいけどもう少し詳しく中身を知りたい。
- 自分たちが依頼しているITパートナー企業に適用したいけどその依頼や監査を自社だけでやるのは不安

という方も多くいらっしゃることがわかりました。

そこで弊社で「DX Criteria」の適用を支援するサービスを用意しました。

 [IT組織 DX対応度診断サービス](https://ari-jp.com/lp/dx-survey/)

もしよろしければ上記ページからお問い合わせください。