従来、システム開発やソフトウェアの開発手法は、ウォーターフォール開発が一般的でした。2000年代以降は、アジャイル開発という開発手法が注目されています。アジャイル(Agile)sとは「素早い」を意味する英語です。まさにその意味の通り、**アジャイル開発は、大まかなシステムの仕様が決まったら、「手直しを前提に、まずは作ってみる」という考え方にのっとり、極力少ない工数で、短期間で開発をする手法**のことです。

### ウォーターフォール開発とは

アジャイル開発が一般化する前は、「ウォーターフォール開発」がシステム開発手法の中心でした。**ウォーターフォール開発は、システム開発の際に、最初にプロジェクトの要件定義や綿密な設計をしてから開発に取り掛かる手法**です。「*システム分析→システム設計→システム開発→システムテスト→保守*」というシステム開発の一連の工程を、一斉に最初から順番に実行していくため、*滝のように上から下に水が落下するイメージからウォーターフォール開発*と呼ばれています。

ウォーターフォール開発はメインフレーム(汎用コンピューター)で主に用いられた伝統的な開発手法ですが、ダウンサイジングやクラウド、モバイルといった新しい技術が主流となり、日進月歩で技術が進展する中、ウォーターフォール型の開発手法は時代にマッチしなくなってきました。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

ウォーターフォール開発よりもはるかに**システム開発の期間短縮が可能なアジャイル開発**の基本的な流れについて触れておきましょう。

*■リリース計画*
**仕様やユーザー要求の取りまとめ過程を、アジャイル開発では「リリース計画」と称します**。「リリース計画」は開発における方向性を示したもので、厳密さは求められません。開発の過程で、当初の「リリース計画」ではなかった仕様やユーザー要求が追加されるのは当たり前にあるという前提に立っています。

*■イテレーション*
リリース計画が決まると開発に着手します。アジャイル開発では**各機能単位で「要件定義→設計→実装→テスト」のサイクルを短期間で繰り返します。これをイテレーション(反復)と称します**。

このように、時代の変化にそぐわなくなってきたウォーターフォール開発に代わって、仕様変更に柔軟に対応できるアジャイル開発が主流となってきましたが、**アジャイル開発にもいくつかの手法が存在します**。ここでは代表的な3つの手法について簡単にご紹介します。

*1.スクラム開発*
スクラム開発のスクラム（Scrum）とは、ラグビーのスクラムが語源です。**ラグビーの様にチーム一丸となって、システム開発を進めるフレームワークです**。

スクラム開発とは？エンジニアが知っておきたい情報をまとめました！

*2.エクストリーム・プログラミング(XP)*
エクストリーム・プログラミング（Extreme Programming）は「XP」と略され、技術者、**とくにプログラマーを重視した開発手法です**。仕様変更、要求変更、機能追加を当然のこととして想定し、プログラマーが常にペアで相互チッェクをしながら開発を行います。

*3.ユーザー機能駆動開発(FDD)*
ユーザー機能駆動開発（Feature Driven Development）は「FDD」と略され、**ユーザー(顧客)の機能価値（feature）という視点に重きを置いた開発手法です**。初めにユーザー機能一覧を作成し、短い間隔で反復 (イテレーション) を繰り返しながら、ユーザー機能を実装していきます。

## アジャイル開発のメリット・デメリット

アジャイル開発はウォーターフォール開発に苦手な部分をカバーし、**システム開発の生産性を高める優れた手法ですが、アジャイル開発にも弱点は存在します**。その弱点、デメリットを理解した上で、適切な手法を選択していくことが重要です。

まずは、アジャイル開発のメリットを理解しておきましょう。**アジャイル開発手法の強み、メリット**を整理すると以下のようになります。

*1.仕様変更にスムーズに対応することが可能*
仕様変更が当たり前だという前提で、あまり細かく仕様を決めないため、逆に*仕様変更に対応しやすくなります*。

*2.開発スピードが早い*
仕様変更を前提とした開発手法のため、ウォーターフォール開発のような*大きな手戻りが発生しにくくなります*。

*3.顧客の要望を満たしやすい*
開発途中で顧客の要望(=仕様変更、仕様追加)に柔軟に対応できるため、*顧客の要望を満たせる確率が上がります*。

*4.UI(User Interface)重視のシステムに強い*
途中で仕様変更が発生しやすい*WEB開発、WEBアプリ、スマホアプリの開発には対応しやすい*のもメリットと言えます。

### アジャイル開発のデメリット

良いことずくめに見えるアジャイル開発ですが、実は次のような**弱点、デメリットもあります**。

*1.開発の方向性や目的がぶれてしまうことがある*
現状調査や分析、要件定義のフェイズを大きく省略するため、*仕様変更を繰り返している内に当初のシステム開発の目的から外れてしまうことがあります*。

*2.全体の進捗管理がしづらいことがある*
アジャイル開発では、開発スケジュールを詳細に決めず、*進捗状況を把握するための物差しが明確ではないことから進捗管理がしづらくなることがあります*。

*3.要件が定まっているプロジェクトには向かない*
汎用系やレガシー系システムのリプレイスなど、*要件が定まっており、途中での仕様変更が発生しにくいプロジェクトではウォーターフォール開発が適しています*。

スクラム開発手法のメリット・デメリットと失敗から学ぶ成功の秘訣

## IT人材の枯渇とアジャイル開発

日本ではIT人材の枯渇が国家的な問題として指摘されています。一方で経済産業省が警鐘を鳴らす*「2025年の崖」問題*があり、このギャップ解消を図らなければ、日本経済は致命的な損失を被るとされています。その**解決手段がDX(テジタル・トランスフォーメーション)と言われています**。

世界ではソフトウェア開発の生産性向上にアジャイル開発が当たり前になっていますが、*日本ではいまだにウォーターフォール型の開発が主流であり、世界との格差が顕著になっています*。

**日本が世界に追いつくためには、アジャイル人材の育成や確保が急務なのです**。では、アジャイル人材にはどのような知識、スキルが求められるのてしょうか?

### アジャイル人材に求められる知識

**■アジャイル開発の原理・原則の理解**
アジャイル開発を担ううえで、アジャイル開発に関する原理、原則の理解が欠かせません。アジャイル開発の原理、原則を理解するには、*「アジャイルソフトウェア開発宣言」*を知っておく必要があります。「アジャイルソフトウェア開発宣言」は2001年にソフトウェア開発の将来について議論をするために、17人の著名な有識者が集まり、その議論の結果を宣言としてまとめたものです。
この宣言では*アジャイルソフトウェア開発がもつ4つの特徴と価値*を明らかにしています。

◆“プロセスやツール”よりも*「個人と対話を」*
◆“包括的なドキュメント”よりも*「動くソフトウェアを」*
◆“契約交渉”よりも*「顧客との協調を」*
◆“計画に従うこと”よりも*「変化への対応」*　を価値とする。

すなわち、『”左記の事柄”に価値があることを認めつつ、*「右記のことがら」*により価値をおく』として、この他にも12の原則を示しました。
これらが、今日のアジャイル開発における礎(いしずえ)となっているのです。

### アジャイル人材に求められるスキル

アジャイル開発のメンバーには、ソフトウェア開発の基本スキルに加えて、次のスキルが求められます。

**■技術スキル**
アジャイル開発の参加メンバーには、ソフトウェア開発に関する基本スキルと合わせ、以下のような技術スキルが求められます。

●ペアプログラミング
●テスト駆動開発
●テスト自動化
●継続的インテグレーション

**■チーム運営スキル**
アジャイル開発は*スクラム*と呼ばれるチームで進めることが多くなりますが、そのスクラムの成否は*スクラムマスター*と呼ばれるリーダーの手腕にかかっています。*スクラムマスター*がメンバーの力を最大限に引き出すには、次のようなチーム運営ノウハウを押さえておくことが必要です。

●スプリント計画、推進
●日次ミーティング
●タスクかんばん
●バーンダウンチャート
●振り返り

**■ヒューマンスキル**
アジャイル開発には*ヒューマンスキルも重要な要素*です。これは*自ら体得*していくしかありませんので、アジャイル開発に参加し、失敗を経験し、試行錯誤で悩みながら、身に付けていくしかありません。例としては次のようなものがあります。

●継続的改善
●コーチング
●ファシリテーション
●サーバントリーダーシップ

以上、学ぶべきことが多いというよりは、それらの**概念を理解した上で自ら獲得していくもの**が大半です。これらの体得には不断の努力が求められますので、自らのステップアップ計画と連動させ、ぜひアジャイル人材を目指してください。

## アジャイル開発はDX実現の切り札となる!

アジャイル開発においては、**テクノロジー面も必要ですが、何よりも行動変容が求められます**。アジャイル組織、アジャイル人材が求められています。一方、経済産業省が提唱している**DX(：Digital Transformation）も、単にデジタル化ということではなく、行動変容を通じて組織を変え、人を変え、ビジネスモデルの変革することを目的**としています。そうした意味では、**アジャイルとDXは表裏一体の関係にある**と言っても過言ではないでしょう。

DXのタイムリミットは2025年、余すところ4年もありません。この間に、企業は大転換を迫られています。一方で冒頭に述べたように、*IT人材の不足は深刻化*しています。この**限られた時間の中で、システム開発のスピード、生産性を飛躍的に向上させる必要があるからこそ、スピード開発に強いアジャイル開発が求められるのです**。

DXとは？その意味と日本の現状、DX推進の障壁となる要因を分かりやすく解説！

今や、ペーパーレス、印鑑の廃止、ワークフローやSFAが当たり前になっています。一方で、古い組織や、古いやり方をなかなか打破できないのも事実です。その原因は人です。だからこそ行動変容が必要なのです。過去の成功体験は捨てましょう。頭をまっさらにして、まずは自分を変えることです。**意識が変わらなければ行動は変わりません**。

今、DXを実際に推進する多くの企業では、DX推進の有効なアジャイル開発の検討や適用を始めています。**アジャイル開発の普及や成功が、企業の競争優位を獲得する重要なバロメーター**になってきます。

しかしアジャイル開発は、IT部門だけの問題ではありません。トップも含めて企業全体にアジャイルの導入や定着が必要です。マネジメントそのものもアジャイル思考に変えなければなりません。

ウォーターフォール型の組織や開発手法を全面否定する必要はありません。ウォーターフォールが適した業務やシステム開発はあります。これまでウォーターフォールで培ってきた考え方は理解し、必要な部分は活かし、企業や組織の目的、方針や戦略に合わせた、それぞれのアジャイルを志向すべきでしょう。いずれにしても、今変わらなければ、未来はありません。**DX推進の鍵はアジャイルにある**といっても過言ではないのです。

DXの取組事例に学ぶDX成功のポイントとITエンジニアへの期待

迅速なソフトウェア開発を目的として生まれた「アジャイル開発」手法の特徴やメリット、デメリットは？伝統的な開発手法「ウォーターフォール開発」との違い、「アジャイル開発」はDX推進の切り札となるのか、「アジャイル開発」人材に必要なスキルなどについて考察します。

アジャイル開発とは何か？ウォーターフォール開発との違い

アジャイル開発のメリット・デメリット

アジャイル開発はDX推進の切り札になる

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

## ITシステムの品質確保の考え方は？

*ITシステムにおける品質とは、想定したことが想定通り動作する度合い*のことをいいます。仮に、仕様通り作成されたシステムでも、*操作方法が使いにくかったり、エラー処理が複雑だったりするもの*は、**ユーザの満足度が低下**します。この状態では、高品質のシステムとは言えません。ここでは、ITシステムにおける品質に関して、開発者側とユーザ側での対応を解説します。

開発者は、ユーザの満足度を高めるために**品質特性**を考えて、*企画・設計・開発・テストを進めます*。*品質特性とは、ソフトウェアの品質を評価する基準*のことで、ISO/IEC 9126(JIS X 0129)に定義されています。ISO/IEC 9126(JIS X 0129)では、以下の6つの特性と、それぞれの品質特性をさらに細分化した21の副特性が定められています。**以下が6つの品質特性です**。


◆ *機能性*(Functionality)
　目的から求められる必要な機能の実装の度合いで、想定条件の下で要求仕様を満たす能力
◆ *信頼性*(Reliability)
　想定条件の下で機能が正常動作し続ける度合いで、障害の起こりにくさの度合い
◆ *使用性*(Usability)
　ソフトウェアの想定動作に関して、利用者に対する分かりやすさ、使いやすさの度合い
◆ *効率性*(Efficiency)
　与えられた条件で、目的達成のために使用する時間や資源の度合い
◆ *保守性*(Maintainability)
　保守作業や改修作業に対する、必要なコストの度合い
◆ *移植性*(Portability)
　別の環境へ移した際、移植のしやすさや、そのまま動作する度合い

ユーザ側は、*業務システムに実装したい要求を、要求仕様としてまとめていきます*。同様に、運用に必要な各種要求についても要望として整理します。特に、レスポンス時間保証が求められるシステムや、システムダウンの影響を最小化する場合は、**動作品質の十分な考慮が必要**となってきます。ユーザ側で開発を主導する場合はこのような内容をもとに検討していきます。

*テスト工程は、要求発生から納品までの流れに従ってステップ化*していきます。その際は品質特性を意識したチェック項目を作成し、**品質基準をクリアする判断**を進めていきます。

開発者はユーザ側から要求を受けてから、以下の**ステップに従って、開発工程を進めていきます**。まず*要求分析*(Requirements analysis)の工程で、ユーザの要求を理解するために、ユーザから要望書である*要求仕様書を入手*します。続いて*要件定義*(Requirement definition)の工程で、ユーザの要求が実装可能なIT要素で実現できるかどうかを確認し、*要件定義書*として作成します。

次に、*基本設計*(Basic design)の工程で、要件定義書の記載事項に基づき、*外部設計仕様*として設計していきます。さらに、*詳細設計*(Detailed design)の工程では、基本設計書の各項目に対応する開発を想定し、*設計の詳細化*を進めていきます。その後の詳細工程では、*開発・製造*(Development / Manufacturing)で、詳細設計の項目・ルールに従い、*モジュールの開発・製造*を行います。

上記の開発工程の品質を保証するために、以下の**ステップでテストを進めていきます**。まず*コードレビュー*(Code review)では品質を確保するために、*ソースコードの品質評価*を行います。続いて*単体テスト*(Unit Test)では、開発・製造の工程での品質を確保するために、テストデータとテストロジックに基づいて*単体動作の妥当性を検証*します。

次に、*結合テスト*(Integration Test)では、詳細設計工程での品質を確保するために、テストデータにより、*モジュール間の動作の妥当性を評価*します。加えて、上限値・下限値やエラー処理の振る舞いが妥当かを確認します。その後に*システムテスト*(System Test)で、疑似ユーザデータを用いて*システム全体での動作が妥当か確認*します。また高負荷環境での動作が安定するかどうかや、運用想定のエラー処理が妥当かどうかもみていきます。

最終工程となる*運用テスト*(Operations Test)では、要件定義工程の品質を確保するために、ユーザの運用環境と実データを用いて、*ユーザの要求が満たされていることを確認*していきます。この工程では、ユーザ側からも運用担当者を派遣し、運用方法の*要員教育*を並行して実施することもあります。

ここでの要員教育とは、「*想定した環境下で、運用方法の差異をユーザ側から派遣し、確認すること。差異がある場合は、受入テスト前に差異について習熟し、不備がないことを事前評価し、受入準備を図ること*。」です。

その目的を果たすために、ユーザ側の要員が運用テスト期間に実施するパターンです。これにより、受入テストを円滑に進めることも可能となります。並行して、引渡しに際し、別途運用計画と要員育成計画を作成・実施します。


*運用テスト*(OT: Operations Test)は、**開発者側が責任を持ち**、進めていきます。*要件定義書の記載が、開発システムでカバーされていることを保証*するために実施します。この運用テストについて具体的な内容を見ていきましょう。

運用テストは、ユーザ側の要求する機能が満たされていることを確認し、保証するものです。そのために、ユーザの動作環境や実際のデータを用いて、*商用環境を想定した操作方法・手順を用い、確認*していきます。同様に、誤ったこと(エラー)が、想定通りに(想定エラーとして)処理されることを、**最終評価**していきます。

加えて、機能性のみならず、性能維持が高負荷でも守られるか、操作が安定しているか等の*非機能要件の適合状況を検証*します。さらに、ユーザ側は、運用テスト工程を活用して、*受入後の操作の習熟を図る*ことができます。

運用テストでは、開発者の作成したテスト計画書とテスト仕様書、テストデータを用います。*テスト環境の定義が妥当か、開発者側の責任範囲の設定が適切かについて確認*しましょう。

*応答時間、処理時間、操作エラー、障害発生時の動作や、エラー処理手順、障害検知・障害対応フローの確認*についても、**運用テストで見極めます**。

*運用テストは開発者の責任により実施*されます。しかし、求められる要件はユーザ環境で必要とされる事項です。したがって、**ユーザ側の立場に立って計画立案・実施をすること**が求められます。そのため、テストシナリオを事前に用意し、ユーザ環境に合わせたテストパターンを複数定義して適合性を確認します。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

*受入テスト*(UAT: User Acceptance Test)とは、発注要件を満たしているかについて、**ユーザ側が最終確認をする**ものです。*検収テスト*とも言われています。したがって、*ユーザのニーズや要件を満たしているか*が、**判断基準**となります。同様に、ビジネスプロセスを満足していることが重視されます。

ユーザの作成した要求仕様に従って、要求定義書が作成されます。その際、運用環境や想定事項を考慮し作成します。ここでは、要求仕様の内容が実際に正しく反映されていることを、*ユーザ側が受入時に判断する必要があります*。そのため、**検収の判断として受入テストを実施**します。この受入テストは、大規模なシステムや複雑なシステムの多くで、受入工程に取入れられています。

運用テストで実施している同じことを繰り返すだけでは、個別に受入テストを実施する必要性が低くなります。主な*実施理由は、運用テストで実施することができない商用環境固有の処理や、業務データ処理に起因する確認を、ユーザ視点で行うため*です。特に重要な機能を、有限の評価時間の中で効率的・重点的に実施します。同様に、*運用時に発生するリスク*について業務影響の有無を想定し、**リスク低減を図ります**。

ユーザ側では、上記開発者の品質確保のための各ステップを理解し、進捗報告を受けていきます。そのため、*進捗報告に従い、受入可能な品質かどうか、事前に評価を進めていきます*。

ユーザ側の受入テストでは、合否判断のための受入基準を定めて、事前にユーザ側・開発者側双方が合意して進めていきます。本番稼働後の影響、障害発生の対策を意識し、**重点的に確認したい項目を定義**しておきます。同様に、*障害発生時の処理フローや、業務フローへの影響を調査*します。これによって、運用時に発生する事態への**対策を事前に講じ**、運用時の**リスク低減を図ります**。

## テスト工程を理解し、運用時の安定性を高めよう

各テスト工程が理解できると、関連仕様書をはじめとする成果物の理解度が高まります。同時に、*顧客要件の理解が高まり、必要な確認事項が理解できます*。理解度が高まるにつれて、自身の責任範囲も広がり、**より多くの責任が任されるエンジニアとなるでしょう**。

テストエンジニアの求人の探し方と、そのポイントを解説！

ITシステムでは、品質を確保するための手法が設けられています。ここでは、業務システムの運用を想定したテストとして、運用テストと受入テストを紹介します。運用テストと受入テストの違いを理解し、システムの安定度を高めていきましょう。

運用テストとは、納品前の最終検査です

受入テストとは、検収の確認です

両テスト共に、ユーザ運用環境を理解したテスト環境で計画・実施することがポイントです

運用テストと受入テストの違いとは？
相違点を理解してシステムの品質を高めよう！

## マイクロサービスアーキテクチャについて徹底解説

「マイクロサービスアーキテクチャ」とはどういう意味かご存知でしょうか？ここでは、「マイクロサービスアーキテクチャ」の理解を深めるために、マイクロサービスアーキテクチャの詳細について詳しく紹介しましょう。

### そもそもマイクロサービスアーキテクチャとは

近年、システム開発・運用において「マイクロサービス」というアーキテクチャを利用するプロジェクトが増えています。**「マイクロサービスアーキテクチャ」とは、サービスを構成している要素を「マイクロサービス」と呼ばれる小さな独立した機能に分割して実装する手法のことです。**

「マイクロサービス」は、ソフトウェアエンジニアであるマーチン・ファウラー氏によって書かれた「Microservices」という文書が発表されてから、一種の「流行語」のような言葉として使われるようになりました。

*「マイクロサービス」の対比として使われるのが、「モノリシック（モノリス）」という言葉です。*モノリスとは、日本語に訳すと「一枚岩」を意味します。つまり、モノリスは、大きな岩の塊のように、大きな単一の機能により、ひとつのサービスを実現するアーキテクチャのことです。

モノリシックとは？主な特徴と適用領域を解説！

### マイクロサービスアーキテクチャの機能分割について

これまでに説明しましたが、マイクロサービスとは、「小さな独立した機能を組み合わせる」ソフトウェアのことです。では、どこまで機能を小さく分割すればマイクロサービスになるのでしょうか。

*機能を限りなく小さくすると、マイクロサービスアーキテクチャの利点と欠点が最大化されると言われています。*限りなく小さくすると、相互依存関係に関わる利点が増加するでしょう。一方、可動部が増えることによって複雑さも増加してしまいます。この両者のバランスを追究していくことが重要と言えるでしょう。言い換えれば、マイクロサービスアーキテクチャが目標とするのは、複雑さを考慮しながらできるだけ細かくサービスを分割することであるといえます。

結論、どの程度まで細かく機能を分割するべきかについては、一概に「正しい」と言えるものが存在しないため、「細かくサービスを分割し、それぞれが自律する」という開発基準で取り組むことが、マイクロサービスアーキテクチャの方法だと言えるでしょう。また、マイクロサービスアーキテクチャは、「どのようにサービスを作るか」という方法論や、「どのような組織で作るか」という組織論の側面を持っています。

マイクロサービスアーキテクチャとは？詳細と課題について徹底解説！

## マイクロサービスアーキテクチャのメリットとデメリット

ここまでに、マイクロサービスアーキテクチャの詳細について紹介してきました。ここからは、マイクロサービスアーキテクチャを採用する上でのメリット、デメリットと注意点について詳しく解説しましょう。

### マイクロサービスアーキテクチャのメリット

**マイクロサービスは新しい技術を簡単に利用できる点がひとつのメリットと言えるでしょう。**マイクロサービスでは、それぞれのサービスはネットワークを介して公開したインターフェースを読み込むだけでいいため、依存関係などの制約はありません。そのため、インターフェース仕様の決まりを遵守している限り、さまざまなサービスに対して、異なる技術を採用することができます。

例えば、新しいシステムを作成するとしましょう。Aという技術が適している部分、Bという技術が適している部分があります。技術というのは開発言語のこととしましょう。モノリシックサービスの場合、AもしくはBのどちらか一方の技術を選択する必要があります。つまり、技術を統一する必要があることになるでしょう。一方、新しく作成するサービスに対して、マイクロサービスではどの技術を利用しているかを気にする必要なく、最適な技術を選択することができます。

したがって、マイクロサービスを採用することによって、システムを開発するスケジュールの短縮が期待できるでしょう。そのため、新しい機能を取り入れることや新しい技術を採用することが比較的容易にできます。また、新しくシステム開発をする場合だけでなく、システムの保守・運用する際に新しい機能を追加することが容易であったり、障害対応がしやすかったりするというメリットにも繋がります。

マイクロサービス・アーキテクチャのメリットを解説！DX推進の切り札となるか?

### マイクロサービスアーキテクチャのデメリットと注意点

一方、マイクロサービスアーキテクチャにもデメリットはあります。マイクロサービスアーキテクチャでは、機能を小さく分割していくため、**コストや効率性などに大きな負荷が発生しやすいことがデメリットと言えるでしょう。**例えば、マイクロサービスはそれぞれ別のプロセスで実行するため、メモリの使用量は増加する傾向があります。さらに、ネットワークを通じてデータや通信をやり取りする際に、多くの時間を要する場合もあるでしょう。

また、マイクロサービスアーキテクチャを利用するにあたって2つの注意点を紹介します。1つ目は、マイクロサービス同士のやり取りは一般的に公開APIを用いて行うことため、APIの仕様について事前に確認し、検討しておく必要があるということです。APIとは、ソフトウェアそれぞれの機能が互いにやりとりするために使用するインターフェースの仕様のことです。

2つ目は、データベース設計時において、複数のマイクロサービスに関連するトランザクションを実現させることが難しい点です。一般的に、マイクロサービスアーキテクチャでは、マイクロサービスごとに独自のデータベースをもっています。そのため、別のマイクロサービスのもつデータベースに直接的にアクセスすることができないように設計していることが多いです。

以上より、マイクロサービスアーキテクチャを利用する場合、「機能をどのように分割するか」ということが重要です。機能を細かく分割しすぎてしまうと、コストや効率性に対する負荷は大きくなってしまいます。

## マイクロサービスアーキテクチャを採用する上での3つの課題

ここまでに、マイクロサービスアーキテクチャにはメリットとデメリットがあることを説明しました。ここでは、マイクロサービスアーキテクチャを採用する上での課題について3点紹介しましょう。

*1.運用を担当する技術者への負担と中央機関の必要性*
これまでに説明したように、マイクロサービスアーキテクチャでは、機能を細かく分割しすぎてしまうと、コストや効率性に対する負荷は大きくなってしまいます。サービスを運用するにあたっての課題として、監視する対象が増加してしまうことにより、運用業務である死活監視やログ管理を行うことが複雑になるという問題点があります。そのため、技術者への負担が増加してしまう傾向があるでしょう。マイクロサービスアーキテクチャを採用する場合は、運用を担当する技術者への配慮を考慮した設計や検討が重要でしょう。

繰り返し説明しますが、マイクロサービスアーキテクチャでは、ひとつのシステムを複数のサービスで構成することになります。そこで、1つ1つのサービスの情報からシステム全体の状況を把握する監視体制と障害対応を徹底することが重要となります。そのため開発方法だけでなく、開発を実施する上での中央機関の体制をどうするかについての考慮も大切でしょう。

*2.マイクロサービスに関する専門的知識やスキルをもっている技術者が少ない*
マイクロサービスアーキテクチャは最先端の開発手法のため、スキルのある経験者が少ないのが現状です。マイクロサービスアーキテクチャを採用する規模を大きくしていくためには、今後、多くの技術者が必要です。海外では浸透しているマイクロサービスの手法ですが、日本では発展途上な開発手法のため、今後、マイクロサービスの導入を進めていくためには専門的な知識やスキルを身につけた技術者を増やしていくことが重要でしょう。

さらに、セキュリティを担保するための専門的な知識やスキルも必要でしょう。マイクロサービスは、機能を細かく分割していくため、モノリシックサービスと比較すると、サービスのセキュリティが脆弱になってしまう可能性があります。そのため、マイクロサービス全体のセキュリティ性を担保するためにも、セキュリティに関する専門的な知識やスキルを持った技術者も必要となります。

*3.チーム間でのコミュニケーションが難しくなる*
マイクロサービスアーキテクチャを採用する場合、サービスによって開発しているチームが異なるため、サービスの数が増加すると、開発するチームの数も増加することが多いため、チーム同士の連携が難しくなるでしょう。そのため、チーム同士のコミュニケーションを円滑にするために、各チームの間を横断し、統一したコミュニケーションルールを作成することが重要でしょう。

以上のように、マイクロサービスアーキテクチャは最先端の開発手法であり、発展途上のため、マイクロサービスアーキテクチャを採用する上で、「専門的な技術者が少ない」、「ノウハウが確立されていない」などの課題があることが言えるでしょう。

## 最先端の開発手法である「マイクロサービスアーキテクチャ」の導入は慎重に！

マイクロサービスアーキテクチャとは、サービスを構成している要素を小さな機能に分割して実装する手法のことです。どこまで機能を小さく分割すればマイクロサービスになるかという議論がありますが、「これが正しい」というのは存在しないため、開発するシステムに対して、メリットとデメリットを考慮することが大切です。

マイクロサービスアーキテクチャの開発手法は海外では浸透し始めていますが、日本ではまだまだ発展途上であるため、課題が多く存在します。*IT技術の発展のひとつの鍵である、マイクロサービスですが、導入については、今後も慎重な検討が必要と言えるでしょう。*

マイクロサービスアーキテクチャとは、サービスを構成している要素を小さな機能に分割して実装する手法のことで、日本ではまだまだ発展途上の開発手法です。当記事では、そんマイクロサービスアーキテクチャについての詳細やメリット・デメリット、課題について解説します。

マイクロサービスアーキテクチャとは、サービスを構成している要素を小さな機能に分割して実装する手法！

マイクロサービスアーキテクチャを利用する場合、「機能をどのように分割するか」ということが重要！

マイクロサービスアーキテクチャを採用する上で、「専門的な技術者が少ない」、「ノウハウが確立されていない」などの課題がある！

## ITシステムで用いる要件とは？

ITエンジニアが遭遇する用語として「要件定義」があります。「要件定義」は*顧客の行うことをまとめた要望書*となります。それに基づき、ITシステムで実装できる設計書を作成します。顧客の要望を網羅するために、「機能要件」と「非機能要件」として**見えない要望を可視化**していきます。

機能要件は、顧客が実際にしたいことを指します。例えば、経理システムに経費精算情報を入力すると適切な費目に集計され結果が格納される機能をつけて欲しいと顧客側が要望した時、この機能を**機能要件**といいます。これは*直接的な顧客の要望を要件化*したもので、顧客とのヒアリングの中で比較的簡単に汲み取れるものです。しかし*システム設計には追加の検討*、つまり**非機能要件**も必要となってきます。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

上記の機能要件の例において、経理システムでは経費精算が集計・格納できれば良いのですが、本当にそれだけでしょうか？例えば、月曜日の朝一の定時処理にアクセスが集中してシステム負荷が高まったり、結果が所定時間内に戻ってこなかったりした場合は、本来の顧客要望が満たされないことになります。そのために、*本来必要とされる処理能力を定義したり、動作条件を定義したり、信頼性や保守の容易性*についても要件にまとめたりする必要があります。この**見えない要件を非機能要件**と言います。

## 非機能要件で定義される項目は？

非機能要件は、*機能要件を満たすシステム設計の動作環境や動作特性を保証する*ために**必要な検討事項**となります。したがって*非機能要件は、システム単体の設計より広範囲の動作特性を考慮して、総合的に検討する必要があります*。以降で具体的なガイドラインを見ていきましょう。

### IPA情報処理推進機構が定義した非機能要求グレードとは？

 IPA情報処理推進機構では、*要求定義の品質を確保するため*に、**非機能要求グレード**を策定しました。

背景としては、*システムが大規模化・複雑化したこと、および利用の広がりの観点から情報システムに安定的な提供基盤のニーズが高まった*ためです。利用用途としてはユーザと開発者の認識のずれを削減し、要求項目の漏れを削減することにあります。

### 非機能要求グレードの実際の項目は？

非機能要求グレードの実際の項目に触れていきます。*非機能要求グレード*では、*非機能要件*を以下の**6種類238項目に分類**しています。
・*可用性*
　継続性(11項目)、耐障害性(15項目)、災害対策(4項目)、回復性(3項目)
・*性能・拡張性*
　業務処理量(14項目)、性能目標値(15項目)、リソース拡張性(9項目)、性能品質保証(5項目)
・*運用・保守性*
　通常運用(19項目)、保守運用(13項目)、障害時運用(8項目)、運用環境(8項目)、サポート体制(16項目)、その他の運用管理方針(7項目)
・*移行性*
　移行時期(3項目)、移行方式(2項目)、移行対象機器(1項目)、移行対象データ(6項目)、移行計画(6項目)
・*セキュリティ*
　前提条件・制約条件(1項目)、セキュリティリスク分析(1項目)、セキュリティ診断(3項目)、セキュリティリスク管理(7項目)、アクセス・利用制限(5項目)、データの秘匿(3項目)、不正追跡・監視(8項目)、ネットワーク対策(3項目)、マルウェア対策(項目3)、Web対策(2項目)、セキュリティインシデント対応/復旧(項目1)
・*システム環境・エコロジー*
　システム制約/前提条件(2項目)、システム特性(7項目)、適合規格(3項目)、機材設置環境条件(18項目)、環境マネージメント(6項目)
参考：[IPA情報処理推進機構 非機能要求グレード](https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html)

上記URLより、**どなたでもドキュメント一式、並びに評価シートがダウンロード可能**です。

*非機能要件を定義することは、多くの経験を必要とする難しい工程*です。IPA情報処理推進機構の*非機能要求グレードを活用することで、これを比較的簡単に行うことができる*ようになります。というのも、汎用的に利用できる6種類の項目について漏れなく各項目がカバーされていることに加え、**ユーザおよび開発者で共通利用が可能**であるからです。

### 非機能要求グレードの利用方法は？

*IPA情報処理推進機構の非機能要求グレード*には利用ガイドと活用シートが同梱されています。利用ガイドは解説編・利用編・活用編の3種類のドキュメントからなり、手順が記載されています。これらを利用することで、**要求項目をレベル化し潜在的な要求を可視化**していくことができます。最初の段階では、要求を一意に決定できませんので、ユーザ側と開発者側で協議して収束させていきます。同様に参考モデルをグレード化してシステム間の差を段階的に定義しているため、必要な要求が確認できるようになっています。

### 非機能要件の指標「RASIS」とは？

*RASISとは、コンピュータシステムのサービスサイクルをカバーする指標*となります。各項目は英語の頭文字からなり、以下の項目に分類されます。
・*(R) Reliability*　　： 信頼性、故障や障害への耐性
・*(A) Availability* 　 ： 可用性、システムの継続性
・*(S) Serviceability* ： 保守性、障害復旧の保守容易性
・*(I) Integrity*　　　： 完全性、データの一貫性
・*(S) Security*　　　： 機密性、情報アクセスの安全性の維持

すでに気づかれた方も多いと思いますが、*RASISの項目は非機能要求グレードの各分類に含まれています。RASISを要件定義に盛り込むこと*で、**大部分がカバーされる**ことになります。

### 非機能要件の評価基準「SLAおよびSLO」とは？

クラウド事業者との契約や、クラウドサービスを利用する際にSLAやSLOという用語が出てきます。*SLAはService Level Agreementの略で、サービス提供時にどの程度のサービス品質を保証するか提示したもの*です。項目としては**測定可能**なもので、高負荷時の性能や速度を保証したり、稼働時間を保証するために提示する項目となります。同様に*SLOはService Level Objectiveの略で、上記SLAで保証される実際の性能や速度、あるいは稼働時間等の目標水準や目標値*となります。

**これらの項目はサービスイン後の品質を保証するための評価基準となります**。

クラウドエンジニアとは？従来型エンジニアとの違いや市場性・年収について解説します！

## プロジェクトへの適用方法は？

実際の非機能要求グレードをプロジェクトに適用する流れについて簡単に説明します。非機能要求グレードでは複数のモデルシステムが定義されており、まずはその中から*対象業務に近いモデルシステムを選定*します。続いて、*業務で必要とされる重要項目のレベルを決定し、重要項目以外のレベルを決定*していきます。

*一定の成果が確認されれば、関連システムの標準化を行い*、**プロジェクト適応範囲を順次拡大**していきます。

*非機能要件の要件定義は、見えない要件や暗黙の了解を可視化し、顧客と合意すること*です。そのために、**顧客とのコミュニケーションが重要**になってきます。コミュニケーションを円滑に進めるために、ヒアリングシートを作成し、統一化されたコミュニケーションを目指しましょう。

要件定義では、想定したグレードを仮置きでも設定し提示することで議論の基準を作成します。併せて、コスト面の提示も行うことで、実現の妥当性を判断していきます。その際、いくつかの*アーキテクチャの選択肢を持つ*ことで、*レベルとグレードを決定*していきます。同様に、保守対象システムと保守レベルを決めたり、将来の法令準拠への対応も必要に応じて検討していきます。

各要件に対して、**重みづけ**を行い選択肢を決定していきます。また過度にグレードを上げても、システムが利用されないと検討の意味がありませんので、*利用状況・需要予測を調査して検討*していきます。*グレードの選定には実装コスト等のトレードオフが発生*することがありますので、これらも決定時に考慮します。また意思決定には時間がかかるため、*PDCAを短いサイクルで回し、決定時間を短縮*しましょう。初期コストが高いと決定判断がつきにくいので、段階的拡張(スモールスタート)の案を用意します。さらに、長期ビジョンの計画を別途検討することが、**成功への近道**です。

## 非機能要件を理解し高品質なシステムを設計しましょう

今後、*ITシステムはさらに複雑化し、大規模化していきます*。同様に、*利用用途が爆発的に拡大します*。当初想定していた範囲外の利用も増えていきますから、*非機能要件の考え方をマスターして、システム設計に活かせるようになりましょう*。その結果、**自身の経験値も大幅に高まることでしょう**。

今後、ITシステムはデジタルトランスフォーメーション(DX)の推進により*利用用途が拡大*していきます。同様に、*利用ユーザの拡大や大規模化により、予期せぬ問題が将来的に発生するリスク*も高まります。本記事では非機能要件に焦点を当て、より安心して利用できるシステム設計のために、要件定義を進める手法を解説します。

非機能要件定義は、見えない要件を可視化することから

コンピュータシステムの要件定義は、非機能要求グレードを活用しましょう

一度プロジェクトで作成すると、関連システムへの展開が可能に

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

## ITエンジニアが枯渇しているって本当?　

DXという言葉をご存じの方は多いと思います。DXはデジタルトランスフォーメーションの略で、この**DX推進の成否が日本経済再生の鍵**とも言われています。DXは経済産業省主導で進められており、各企業にはITを用いたビジネスの変革、新たなサービスの創出が求められています。既に取組を始めた企業もありますが、思うようには進んでいません。その大きな原因は、*ITエンジニアの不足*です。

ITエンジニアはInformation Technology（情報技術）に関わる技術者たちを指す言葉です。ITエンジニアには、**ITコンサルタント、SE(システムエンジニア)、PG(プログラマー)、サーバーエンジニア、セキュリティエンジニア**など20以上の職種があります。

ITエンジニアはきついがやりがいがある！その仕事内容や年収、求められるスキルを解説

### すでに22万人のIT人材が不足している

経済産業省の調査（※）では2018年の時点で、すでに**IT人材は需要に対して供給人数が22万人も不足しています。最悪の想定では、2030年には約79万人のIT人材の不足が懸念されています**。この結果、何が起きるでしょうか?

単純に考えると、**DX推進に成功した企業は生き残り、DX推進を怠った企業は淘汰される**ということです。極端な話、DX倒産という言葉すら生まれるかもしれません。これを回避するために*IT人材の育成と確保が日本経済にとって大変重要な課題*であるということです。

※[経済産業省 IT人材需給に関する調査（概要）](https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf?_ga=2.139817712.293849879.1610600760-301351239.1610600760)

耳にタコかもしれませんが、ここでもう一度おさらいしておきましょう。今なぜDX推進の必要性が叫ばれているのでしょう。経済産業省は**DXが進まないと、「2025年の崖」が訪れる**としています。「2025年の崖」とは、各企業で既存のITシステムが、老朽化や肥大化、複雑化などによって時代に合わなくなり、企業の競争力を大きく低下させ、**日本にとって莫大な経済損失をもたらす**という問題のことです。

経済産業省の試算では**最大で年間12兆円の損失が想定**されています。あの東日本大震災のよる経済損失は16.9兆円(内閣府推計)です。（※）*毎年12兆円の経済的損失が生じるとすれば、日本経済に対するダメージの大きさは計り知れません*。

 ※[東日本大震災の被害額、16.9兆円　阪神の1.8倍に: 日本経済新聞](https://www.nikkei.com/article/DGXNNSE2INK01_U1A620C1000000)

### ITエンジニアには転職のチャンス到来?

やや悲観的な話になりましたが、この危機的状況を逆にとらえると、**ITエンジニアにとっては絶好のチャンス到来**と言えるかもしれません。これだけ多くのIT人材が必要ということになれば、ITエンジニアの皆さんは引く手あまたの状態になるでしょう。いや、既に争奪戦は始まっています。

「数が少なくなれば価値が上がる」のが市場の原理です。ITエンジニアの希少性が高まっている以上、**収入アップを目指すチャンス**と言えます。

## ITエンジニアの転職のメリット

収入アップ、**待遇改善の方法として思いつくのが転職**です。同一企業で働く限り、年功序列制度が邪魔をして、給与が一気に30%アップなどということはまずありません。しかし転職ならこれが実現可能です。

とはいえ、転職も良い事ばかりとは限りません。また転職にも中小企業から大企業に転職する場合と、逆に大企業から中小企業に転職するケースが想定されます。それぞれの**メリット、デメリット**をあげてみますので、ご自身に最適な転職モデルをイメージする材料にしてください。

### ITエンジニアが中小企業から大企業に転職するメリット

大企業の平均年収は中小企業と比較して大きな格差があります。**中小企業からの転職で年収が倍近くになった**という話も聞こえてきます。

収入も仕事へのモチベーションにもつながるため、無視できないメリットです。

大企業は相対的に中小企業よりも経営的には安定しています。**公的支援も受けやすく、簡単には倒産しません**ので、安心して働ける環境です。

中小企業と比べて大企業は**従業員の教育や研修に予算を投じ、社員育成を行います**。また**公的資格の取得には手当を出す企業も**多く、自己研鑽に励むことが可能です。

クレジットカードやローンの契約でも大企業社員というだけで、審査に有利です。

**営業職は大企業の名刺を持っているだけで、新規顧客の開拓がやりやすくなる**でしょう。

**家族手当、住宅手当、各種慶弔祝金、福利厚生施設など**、給与面以外のメリットが期待できます。

厚生年金に加え、企業年金などがあり、**老後の生活が保証されている**のも大企業ならではのメリットです。

大企業は株主の目もあってコンプライアンスに熱心です。ブラック企業にみられるようなサービス残業は明確に禁止されています。

**働き方改革の一環でワーク・ライフ・パランスの取り組みが進められ、定時退社や余暇活用が奨励されている**点も魅力です。

### ITエンジニアが大企業から中小企業に転職するメリット

中小企業では大きな歯車として、自らの存在感を感じながら、**主体的に仕事ができるの**はメリットです。**自分の仕事が成果がすぐに見えたり、顧客の評価を肌で感じられたりする**点も魅力の1つでしょう。

*2.責任ある仕事を早くから任せられる*

大企業経験者は、それなりの処遇で迎えられるでしょう。**即戦力として期待され、いきなり責任ある仕事を任せられる**ことも少なくありません。

中小企業は大企業のようにだらだらと稟議書を回したり、根回しに奔走したりすることもなく、即断即決です。

また**大企業時代よりも裁量権があり、自ら判断する機会が増えます**。

中小企業は大企業と比べて拠点が少なく、エリアも限定されています。**大企業のように地方への転勤の心配をすることなく、落ち着いて仕事に専念でき、家族との触れ合いを大切にできます**。これが魅力で大企業から中小企業に転職する人もいるくらいです。

## ITエンジニアの転職のデメリット

基礎知識の記事（96ページ目）