皆さんはGTDという言葉を聞いたことがあるでしょうか?**GTDは最近注目されているタスク管理手法のこと**です。GTDは「Getting Things Done」の略で、和訳すると「仕事を成し遂げる」という意味です。単に「成し遂げる」というよりは、*「効果的に成し遂げる」*というニュアンスです。

その「効果的に成し遂げる」ためには、*頭の中にある、タスク(やらなければならない仕事など)を外に出し、整理することで、今「やるべきこと」に集中できるようにするという手法がGTD*です。

例えば、今頭の中にある「やるべきこと」がスパゲッティのように絡み合い、何から手を付ければ良いのかと頭を悩ませている状態は誰にもあることですね。例えば、

*・今日中に提出しなくてはならないレポートがある*

*・後で取り組もうと考えている仕事もある*

*・他の部署の担当者と調整が必要な案件もある*

*・時間があったら調べたいこともある*

こんなタスクが頭の中でぐるぐる回っていると、気持ちばかりか焦ってしまい、ストレスの元になってしまいます。こうしたモヤモヤを解消し、*今やるべきことを明らかにし、仕事の効率化の助けとなるのがGTD*なのです。

GTDはアメリカでは既に主流のタスク管理手法となっていますが、この手法を編み出したのは、*デビッド・アレン*としいう生産性向上を専門とするコンサルタントです。デビッド・アレンの著書*「ストレスフリーの仕事術」*(初版は2006年に発行)にはGTDについて書かれており、**フォーチュン100の企業の内、既に40社でGTDが採用されている**とのことです。

GTDを仕事術と考えると、興味が薄れるかもしれませんが、実はGTDは仕事だけにかかわらず、あらゆる場面で活用できます。今、**抱えている仕事、仕事以外のタスク(やらなくてはならないこと)などを効率的に管理し、頭を悩ませているものを取り去り、今集中すべきことに専念できるようにしてくれるのがGTD**だからです。

GTDは個人の抱えるタスクばかりか、*プロジェクトの管理にも有効*です。例えば、プロジェクトではいくつかの難題に直面した時に、どこから手を付ければよいのか分からなくなることがあります。こうした場合もGTDを用いることで、「今やるべきこと」が明らかになり、*プロジェクトの進行が円滑になる*のです。

このように*GTDはオフィシャルとプライベート、個人と集団を問わず応用範囲が非常に広い*からこそ、多くの企業で採用されているのです。

GTDには多くのメリットがあります。まず最初にその**メリットを知り、GTDに対する理解を深め**てください。

GTDが大きく注目されたのは、**GTDが目の前に山積するタスクの山を崩し、整理することでストレスから解放される状態を作り出してくれる**からです。単なる整理術ではなく、心理的な*ストレスフリー効果*がGTDの大きな魅力なのです。

GTDでは最初に「収集」というプロセスで、頭の中にあるタスクを可視化させます。つまり、外に向けて投影するのです。この**外部環境への投影によって、何をしなければならないのかが明らかになり、タスクの管理をスタートさせる**ことができます。

人は多くのタスクを抱えて頭を悩ます状態に陥ると、とかく収集と整理を同時に行いがちです。これを同時に行うことで、さらに混乱が増し頭を抱えることになってしまいます。**GTDではタスクの収集と整理のタイミングを完全に分けます**。分けることで肩の荷が下り、*楽な気持ち*で前に進めるのです。

GTDではタスクをやりっ放しにはしません。**一旦終了したタスクや、未完了のタスクを見直すためのレビューを必須**にしています。タスクは終了したとしても、タスク要件が変更となって未完了のステータスになることもあれば、未完了タスクが中止となることもあります。常に*タスクの状態を最新の状態に保つこと*がタスク管理の精度を上げることになるのです。

コードレビューを初めて行う人必見！やり方を1から解説！

メリットの多いGTDですが、タスク管理という面で見ると**デメリットになりかねない要素**もあります。

GTDに従ってそのまま実行した場合、それぞれのタスクのスケジュールが未定のままです。なぜなら**GTDの中ではタスク・スケジュールの観点が入っていない**からです。スケジュール管理に関しては自ら行えば良いのですが、GTDをそのまま丸のみした場合に起きるデメリットとして記しておきます。

### 実行記録を付けるルールがない

タスクはいつ着手し、いつ完了したのかの記録を取ることが大切です。**GTDではタスクの実行記録を取るということに触れられていません**。タスクを実行したら、必ずその*スケジュールや要した時間を記録するようにしましょう*。記録は次の計画に必ず活きてきます。

### 目標による管理に触れていない

GTDは目の前に混在しているタスクを実行に移すための手法としては有効ですが、**長期的な目標による管理などについては触れられていません**。タスクは目先の課題から長期課題まであります。目先のタスクにとらわれて、*中長期の課題やタスクを疎かにしないよう留意*する必要があります。

**GTDを実践するには5つのステップ**があります。そのステップでは具体的な何を行うのか、それぞれのステップごとに見ていきましょう。

まず自分の頭の中にあるタスクを可視化します。タスクはやらなくてはならないと考えているもの・アイデア・ルーチン業務・保留中のものなど、プライベートなものも含めて**すべて書き出します。ノート・手帳・パソコン・スマホなど何でも構いません**。気になっていることすべて書き出すことが重要です。

書き出したタスクを処理(分類)していきます。

*2.重要ではあるが緊急性はないもの*

*3.重要ではないが緊急性はあるもの*

*4.重要でもなく、緊急性もないもの*

この**4つのカテゴリーに分けてみます。4番目のカテゴリーに入ったものはタスクから除外します。こうすることで、重要なタスクに神経を集中させることができます**。

こうしてカテゴライズしたタスクを整理します。**タスクをビジネスとプライベートに分け、さらに優先度順に並べ、それぞれに期限を設けます**。

優先順位が付けられたタスクは状況の変化によって、優先度が変わったり、新たなタスクが追加されたり、刻々と変化します。この変化を見逃さないために、**定期的にレビューを行い、タスクを最新の状態にします**。

以上のプロセスを踏むことで、頭の中で整理がつかなかったタスクが抽出され、整理がされました。後は**優先度の高いタスクから順に全力投球するだけ**です。悩みや雑念が取り払われ、ストレスフリーで、すっきりした頭で自分の力を発揮できます。

GTDを始めたいと思われた方はいらっしゃると思いますが、**GTDは思い立ったら直ぐに始めることが可能**です。*準備すべきものは特にありません*。とりあえず普段使っている手帳やメモ用紙があれば大丈夫です。もちろん、使い慣れたPCやスマホでも構いません。ご自身の頭の中にあるタスクを書き出すものがあれば、GTDを始められます。

多くの方は何らかの形で「TO DOリスト」を作成された経験があると思います。今でも続けている方もいらっしゃるでしょう。しかし多くの人が続かなかった理由は、頭の中にあるタスクをすべて書き出すという作業が、大変だと感じたからではないでしょうか。

それは、ただ頭の中にある「やらなくてはいけない、やりたい」と感じていることをそのまま「TO DOリスト」に書いたからです。頭の中でもやもやしたものを書き出すことで、多少は頭がクリアになったような気がしたかもしれませんが、それは*頭の中のものを外にコピーしただけで終わっている*のです。

*GTDを「TO DOリストの作成」と同じだと感じた方は、GTDに疑問を持って当然*です。

では、「TO DOリスト」を作成した方は*「ストレスフリー」*を感じられたでしょうか?感じた方は「TO DOリスト」を続けた方です。*「TO DOリスト」*を続けられなかった方は*「ストレスフリー」*を感じられなかったのでしょう。

さきほど述べましたが、**GTDのメリットは「ストレスフリー」**なのです。だからこそ、GTDにトライした方の多くがGTDを習慣化し、フォーチュン100社の40%がGTDを採用しているのはそのせいです。

### GTDは単に手順に従って行うだけ

GTDは、ただ**単に手順に沿って、タスクを可視化していくだけ**です。それだけで効率よくタスクをこなしていける仕事術です。

*GTDは、個人的なタスクの管理だけではなく、会社や組織のプロジェクトなど、集団的なタスクの整理や管理にも効果的*です。集団でタスクを抽出し、皆でそれを共有し、優先順位をつけ、分担を決め、実行し、定期的にレビューするだけです。これをご覧になっている*ITエンジニアの方のプロジェクトでも活用できます*。

あなた自身も、プロジェクトも*GTDの手法を上手に利用すれば、タスク管理に関わる多くの問題をクリアにし、タスクが効率よく進展*するでしょう。

**GTDは特に準備も要らず難しい講習や教育も不要で、また手順もシンプルです。簡単に導入できるタスク管理法です**。しかし、それでもGTDにはいくつか*留意点*があります。

*■ストレスフリー*
*GTDはあくまでも「ストレスフリー」が命*です。GTDは実際に効果を実感しながら、自発的に浸透させていけばよいのです。誰かが、どこかの組織がGTDを採用し、成果があったことを口コミでも構わないので、広めていけば良いのです。

GTDを半強制的に導入しようとする企業や組織もありますが、そうするとルールや縛りが設けられがちです。それが逆にストレスを招きます。**押し付けない、ストレスフリーが大原則**です。

*■GTDは目的ではない*
**GTDは、今やるべきタスクに集中し、タスクの効率を上げることが目的です。GTDをやることが目的ではありません**。

人によって、チームによって、あるいは職種によって、*やり方はまちまちで構いません。それぞれがベストと感じられるやり方で構わない*のです。変化の激しいところでは、レビューは日々行ってもかまわないし、ルーチン業務中心なら、レビューは3日に1回でも構わないでしょう。

*GTDはタスクを効率化するための手段です。あなたらしく、あなたのやり方で肩の力を抜いて行えばよいのです。気軽に是非トライしてみてください。*

GTDは世界の著名な大企業でもよく利用されている「ストレスフリー」のタスク管理手法です。大変シンプルで手間要らず、誰でもすぐに利用できて、仕事の効率化が実感できると評判のツールです。あなたもGTDを活用して仕事やプライベートのタスクを効率的に実行してみませんか?

1.GTDはストレスフリーのシンプルなタスク管理手法で、仕事の効率化に効果がある

2.GTDは万能のタスク管理手法ではない。スケジュール管理や目標管理は別途行う必要がある

3.GTDは強制しない。各自が、各組織が最も効果的と思える方法で主体的に進めるのがよい

ストレスフリーのタスク管理ツールGTDを使って効率的に仕事を！

データベースは今や、IT用語とは言えない程に一般的な言葉になりました。では、あなたはデータベースについて何と説明しますか?当たり前に使っている言葉は逆に説明を求められると困ってしまうものです。

ここでは、**データベースに関するおさらいをしながら、ITエンジニアとして知っておくべきこと**をまとめています。

データベース(Data Base)は”データの基礎”とか、”データの土台”という意味で、**蓄積され、再利用できるようになったデータの集合体のこと**です。略してDBと言うこともあります。

広い意味では、*電話帳もデータベース*です。また*Excelで作成した名簿などもデータベース*です。

ITの世界では、商用で使われているものや、規模の大きなものを言います。絵や図で表す時にはドラム缶の形を絵描きます。

### データウェアハウスとの違いは

データベースとよく似た言葉で、*データウェアハウス(DWH)*があります。この両者の違いは何でしょうか?

データウェアハウスはデータ倉庫と訳し、データベースよりは大きな概念です。倉庫と呼ぶからには、当然必要なデータを必要なだけ取り出せなくてはなりません。きちんと整理され、分類されて格納されている必要があります。

**データベースは検索や蓄積が簡単に行えるように整理されたデータの集まりですが、データウェアハウスは大量のデータが分析しやすい形で保管されているデータの保管庫**です。電話帳がデータベースだとすると、データウェアハウスは書棚と言えるでしょう。

### データウェアハウスとの違いはビッグデータの関係は

データウェアハウスと切っても切れない関係にあるのが、*ビッグデータ*です。**ビッグデータは解析の対象となる大量のデータを指しますが、その大量のデータを保管しているのがデータウェアハウス**です。つまり、ビッグデータはデータそのものを指し、データウェアハウスはその入れ物だと考えれば分かりやすいでしょう。

### データベースにするメリットは

データベース化のメリットは多くありますが、**集約すると以下の4つ**にまとめることができます。

*1.データが共有できる*
データベース化によって、**同時に複数の人がデータベースにアクセスして、利用することができます**。これによって情報共有や、仕事や作業の効率化を図ることができます。

*2.データを簡単に分析ができる*
データベース化し、データに分類などの属性をつけることで、その**属性で抽出し、簡単に分析することができます**。例えば、購買データと顧客データを1つのデータベースにすると、ある商品が男女や年齢ごとにどれだけ購入されたのかが簡単に分かるようになります。

データベースが導入される前は、Excelなどで個々人が必要なデータを管理していました。この個々人が管理していたデータをデータベース化し、集中管理することで、**無駄がなくなり、データが管理しやすく**なります。さらにデータの*セキュリティを高める*ことも可能となります。

*4.データの再利用がしやすくなる*

1度収集したデータを**簡単に編集して、再利用**ができます。たとえば、顧客情報データベースから、必要な条件で顧客氏名や住所を抽出し、DMラベルを作成するといったことが簡単に行えます。

データベース化のメリットは以上の折ですが、この便利な**データベースを管理するためには、DBMS(データベース管理システム)が必要**となります。DBMSは「大量のデータを自動的に整理」してくれますので、データベースのメリットを得ることができます。すなわち、*DBMSとデータベースはセット*なのです。DBMSが無ければ、データベースは作れません。DBMSが無い段階では、ただのデータファイルでしかないのです。

DBMSによってデータベースは管理されますが、データを抽出や追加などのデータベース操作には、それを**DBMSに指示するための言語が必要です。それがデータベース言語の1つであるSQL**です。SQLは何かの略語ではありません。読み方は「エスキューエル」または「シークェル」です。

*データベースには大別して3つの型*があります。**現在の主流はリレーショナル型ですが、他に階層型、ネットワーク型があります**。それぞれ特徴がありますので、データベース構築の際は、データベースの活用方法を想定しながら構築する必要があります。

階層型データベースは、その名の通りデータが組織階層のように構成され、*ツリー構造*となっています。**親ノードと子ノードの関係は1（親）：ｎ（子）**です。特定データを検索する際にはルートが1つしかないため、*検索の速度が速いという利点*がありますが、階層が複雑になると、同一データの重複登録が必要になるなど、柔軟性に欠ける点がデメリットとしてあげられます。

### ネットワーク型データベース

ネットワーク型データベースの階層構造は、一見階層型と似ていますが、**親ノードと子ノードがｎ：ｍで構成**され、*子は複数の親を持つことができるネットワーク構造*のため、同一データを重複登録する必要がないという点では階層型データベースよりも柔軟性があります。

### リレーショナルデータベース

Excelのように、「行」と「列」からなる**「表」のイメージでデータを管理することができるデータベースの型**の1つです。「列」には重複しない項目名（見出し）が設定され、行にデータを追加していきます。表のイメージでデータが位置づけられるため、関係性が分かりやすいのが特徴です。

他の2つのデータベース型と比較して、*柔軟性に富んでおり、現在は主流のデータベース*になっています。

## データベースで押さえておきたい用語

データベースの利用に当たっては、知っておくべき用語があります。**よく使われる用語について簡潔に解説**しますので、これから*データベースに関わる方*は是非覚えておいてください。

テーブルとは、データベースの種類ごとの単位です。Excelなど**「シート」がテーブルに該当**します。

カラムは、「コラム」とも呼ばれ、属性を意味します。**Excelの「列」に該当するもの**です。カラム名はExcelの列名と同じです。

レコードとは、データそのもののことです。また**Excelの「列」であるカラムに対して「行」に該当するもの**です。

フィールドは、データベースの*最小単位*で、**Excelで例えると「セル」に該当**します。Excelのセルも書式設定で文字項目や数値項目があるように、フィールドも同様に書式の設定が可能です。

正規化とは、**テーブルの整合性を保ち、データに矛盾や重複が生じないようにすること**です。正規化された表を正規形と呼びます。正規化を行ことで、*データの追加や更新・削除などによるデータの不整合を防止*し、データベースのメンテナンス効率を高めることができます。

インデックスは「目次」や「索引」のことです。**データベースのどこに、どのデータがあるのかを示した一覧表のようなもの**です。このインデックスを利用することで*素早く必要なデータを見つけることができる*ようになります。インデックスがないと、先頭から該当データを探すことになるため、非常に検索の時間が掛かることになります。

スキーマとは図式とか概要などの意味を持つ英単語ですが、データベースにおけるスキーマは、**データベースにどのような種類のデータが、どんな構造で格納されているのかを定義したもの**です。*データベースの設計図*の役割を果たすものと考えればよいでしょう。

スキーマは3層に分けて用いることが多く、*外部スキーマ・概念スキーマ・内部スキーマ*に分かれます。3層に分けることで、設計変更などがあっても、該当するスキーマだけを変更すれば済むため、影響を小さく抑えることができるからです。

## よく使われるデータベース管理システム（DBMS）

ここでは、**よく使われるDBMS製品**について触れておきましょう。以下のDBMSを知っておくと、大半のDBMSを理解したことになるでしょう。

日本国内では**圧倒的シェアを有する、Oracle社の有償のRDBMS(リレーショナル型DBMS)**です。まずは最初に覚えておきたいRDBMS製品です。

**マイクロソフト社製の有償のRDBMS**で、Oracleに次ぐシェアを占めています。

無償のRDBMSです。無償のため、**プログラム開発での練習用に利用されるケースや、小規模システムでのデータベースとして利用**されるケースが多いのです。

**オープンソースのRDBMS**で、個人利用の場合は無償ですが、商用利用は有償です。オープンソースの中では高いシェアがあり、また*有償のソフトとそん色ない機能*を有し、最近では法人でもよく利用されています。

### 最近注目のデータベース「NoSQL」とは

## データベースに関する資格試験

データベースエンジニアを目指したい方、データベースに明るいSEを目指す方には資格の取得をおすすめします。*資格を有することで、客観的評価が高まり、活躍の機会が増します*。また、スキルアップが図れ、収入アップにもつながるでしょう。ここでは、**データベースに関わる主な資格試験**をご紹介しておきます。

### データベーススペシャリスト試験

データベーススペシャリスト資格は、かなり**難易度の高い国家資格**です。実務経験のない方の合格はかなり厳しいでしょう。特定のDBMSに依存せず、データベースに共通する理論や、データベース設計に関する出題が中心です。

[データベーススペシャリスト試験]( https://www.jitec.ipa.go.jp/1_11seido/db.html) (合格率15.8%)

### ORACLE MASTER（オラクルマスター）試験

ORACLE MASTERは国家資格ではありませんが、**権威ある資格**です。またBronze、Silver、Gold、Platinumと4段階のレベルがあり、実力に応じたレベルの資格を取得できます。*ORACLE製品を主に扱うエンジニアは、この資格の取得をおすすめ*します。

[ORACLE MASTER]( https://www.oracle.com/jp/education/certification/index-172250-ja.html)

特定非営利活動法人LPI-Japanが運営する**民間資格**です。*オープンソースのデータベース（OSS-DB）*に関するIT技術者認定資格で、商用データベースとの連携に優れ、企業システムでも多く活用されている「PostgreSQL9.0以上」を基準のRDBMSとしています。レベルはベーシックなシルバーと、コンサルティングまで行えるゴールドの2つがあります。

[OSS-DB技術者認定試験](https://oss-db.jp/outline)

システムエンジニアがキャリアアップするのにおすすめの資格を解説！

## データベースエンジニアとして活躍しよう

ここまで、データベースに関する入門から初歩について解説してきました。日頃、データベースに触れているエンジニアの方には物足りない内容だったかと思いますが、原点に立ち返ることが大切だと感じられたら幸いです。

**ビッグデータやAIといった分野で、データベースエンジニアの活躍の場は益々広がっています**。*データベースエンジニアの仕事は専門性が高く、他の職種のエンジニアに代替することが難しいため、業界では大変重宝される職種*です。この記事でデータベースに興味を持った方は、是非データベースエンジニアを目指してみてください。

ITエンジニアの大半はデータベースに関わっていると思いますが、いざ説明を求められると説明に窮することがあるでしょう。入門者にも分かるよう、おさらいを兼ねてデータベースについてやさしく解説していきます。データベースエンジニアを目指す方にも参考になれば幸いです。

1.データベースとは何か、ITエンジニアとして知っておくべきことを入門からやさしく解説します

2.データベースの3つの種類、押さえておきたい用語、よく使われるDBMSについて再確認します

3.データベースを学びたい、データベースエンジニアを目指すための資格試験、データベースエンジニアの重要性について認識します

データベースとは？今更聞けないその内容をITエンジニアとして改めて学ぶ

ソフトウェアの開発手法としては、従来主流だった*「ウォーターフォール開発」*と最近主流になりつつある*「アジャイル開発」*の2つの手法がよく知られています。

**「アジャイル開発」では、少人数の開発メンバーが協力しあいながら作業を進めていきます。**また、「ウォーターフォール開発」方式のような、一度決定した事を絶対視せず、*都度見直しながら柔軟*に進めていきます。各チームメンバーから定期的にフィードバックを得て、*その時点でベストと思われる方法*を採用していきます。システム開発においては、1度にすべての機能をまとめて作るのではなく、*機能単位に、あるいは一定期間ごとに開発を繰り返し、積み上げ*ていきます。

**「スクラム開発」は「アジャイル開発」の代表的な手法で、特にチームメンバーのコミュニケーションを重視した手法**です。この「スクラム開発」には次のような要素があります。

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

スクラム開発の要素は大きく分けると以下の4つですが、この手法はシステム開発以外のプロジェクトにも適用が可能です。

*1.機能単位で開発*
していくのがスクラム開発の特徴ですが、機能はプロダクトに対する要望を優先順位の高いものから並べ、その順番に従って機能を作ります。

*2.個別の開発期間は短期間（1～4週間程度）*
に区切って、その中で計画を立てていきます。

*3.メンバー同士のミーティング*
は毎日行い、その中でプロジェクトの状況を共有し、進捗に問題がないかなどを確認**していきます。

*4.プロダクトの機能*
がユーザーの要望通り正しく作られているのかを、*定期的にレビュー*します。

スクラム開発ではチーム単位で活動をしていきますが、1つのチームは3人から多くて10人程度までで編成します。またその活動は責任者に任せず、**メンバーが主体的に行動**するのが原則です。

*1.プロダクト・オーナー*
プロダクト・オーナーと言うと仰々しいですが、**プロダクト・オーナーの役割はチームの舵取り役**です。舵取りはしますが、チームへの*口出しはしません*。チームが最高のパフォーマンスを発揮できるよう側面からサポートする役目を負っています。

*2.スクラム・マスター*
**スクラム・マスターはメンターという立場**です。よき助言者といえば良いでしょうか。*チームメンバーとの関係は対等*です。メンバーが困っていることや、不都合な問題などに目を向け、その改善や治療を行います。*ドクター*のような存在です。

*3.主役はメンバー*
スクラム開発のチームにリーダーはいません。舵取りをしてくれるプロダクト・オーナーや、ドクターのような存在のスクラム・マスターはいますが、*チーム・リーダーの立ち位置の人はいない*のです。リーダーのいないチームとは？と不思議に感じると思いますが、一般的な組織のリーダーとは役割が違います。一応、リーダーに近い存在はスクラム・マスターですが、**スクラム・マスターはメンバーのサポートに徹します。あくまでもスクラムチームの主役はメンバー1人1人**なのです。

## スクラム開発のメリット・デメリット

**スクラム開発は新しく編み出されたアジャイル開発の1つの手法**で、多くのメリットがありますが、一方でデメリットもあります。スクラム開発をより理解するために、そのメリット、デメリットについて確認しておきましょう。

*1.チームメンバーが当事者意識を持って主体的に取り組める*
**スクラム開発の主役はメンバー個々人**です。スクラムを組んで全員でシステム開発を進めていくため、1人でも手抜きをすればスクラムは崩れます。そうならないよう、うまくサポートし、全員がモチベーションを維持しながら取り組めるように動くのが*スクラム・マスター*です。このため、メンバーはチームメンバーと協力し合いながら最高のパフォーマンスを発揮できるのです。

*2.問題が起きても迅速に発見し、迅速に解決できる*
スクラム開発では毎日ミーティングを行い、昨日の成果、今日の課題、問題点などを共有します。**問題点や障害となっていることはスクラム・マスターがさらに浮き彫りにし、メンバーと共同でその解決**に努めます。そのため、問題発見と問題解決が早く行えるため、プロジェクトが予定通り進みます。

*3.工数見積もりの精度が上がり予定通り開発が進む*
最初にプロジェクトの全工数を見積もる「ウォーターフォール開発」と異なり、アジャイル開発の一種であるスクラム開発では、**機能単位で工数を見積もりながら開発を進めていき、障害などの早期発見、早期対応が行えるので、計画通りに開発が進行**します。

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

スクラム開発は開発の生産性を高める上で大変効果的な手法なのですが、一方で**必要な条件を満たさないと、スクラム開発の効果が得られない**ことがあります。その*デメリット*ついて述べていきます。

*1.短い期間での対応でメンバーの協力体制が整わないことがある*
スクラム開発の最短のスパンは1週間です。**未習熟のメンバーが参画した場合、ウォーミングアップ期間や教育機関が十分に設けられない**ため、力を発揮することなく期間が終了してしまいます。開発リズムを崩さないよう、*できるだけメンバー編成を変えずに開発を進めること*が求められます。

*2.コミュニケーションが苦手なエンジニアには不向き*
スクラム開発では*メンバーのコミュニケーション力が問われます*。日々のミーティングで自分のタスクの進捗や課題を簡潔に発表し、他のメンバーの状況を正しく理解する能力が求められます。仕事はできるが、**コミュニケーションが苦手というメンバーはスクラム開発に不向き**です。こうした事を考慮し、メンバーの人選や、メンバーの育成に配慮する必要があります。

*3.開発全体のスケジュール管理がしにくい*
スクラム開発は柔軟な開発ができるメリットがある一方で、柔軟が故に開発の方向が変わることがあり、スケジュールそのものがぶれる可能性があります。また**工程が機能ごとに細かく分かれており、それも全体スケジュールの管理を難しくする要因**です。クライアントからスケジュールの進捗の確認を求められた際、説明が難しい点は、ウォーターフォール開発と比較してデメリットと言えます。

*スクラム開発が失敗する原因は非常に多くあります*が、ここでは絞って、代表的な失敗の原因について解説します。

スクラム開発という手法は、従来の開発手法とは大きく異なります。単なる掛け声だけで進められる手法ではありません。**チームメンバーの理解と協力も欠かせませんが、会社全体、経営者、利用部門など幅広い理解とコンセンサスが必要**です。これらを飛ばして、いきなりスクラム開発を進めると必ずと言ってよいほど失敗します。そのためには、関係者に対して、アジャイル開発・スクラム開発の目的や狙い、得られる効果、スクラム開発を進める上で必要なことをきちんと説明し、承認を得ておくことです。「単なるシステム開発の一手法だから、予算さえ確保しておけば問題ない」という甘い考えは通用しません。*周到な準備*を忘れないでください。

###  2.導入までの準備がおろそか

これは1.の失敗原因とも共通する部分がありますが、性急な導入は失敗する原因です。例えば、システム開発案件があり、そのプロジェクトを任されたとしましょう。納期が厳しく、従来型のウォーターフォール開発では間に合わないと判断し、スクラム開発方式の採用が頭に浮かびます。しかし、**スクラム開発方式を採用するには準備期間が必要**です。これまでに開発メンバーを含めて十分な経験があれば、問題はありませんが、*初めての経験なら6カ月程度の準備期間が必要*です。まさに「急がば回れ」です。

*アジャイル型開発に計画は不要だという誤った考え*を持つ方がいますが、これは大きな誤解です。どんなプロジェクトでも目標や計画は必要です。ただ、アジャイル開発の場合は機能単位に計画が分解されるだけのことで、**少なくとも全体の大まかな計画は立てなければなりません。**また、スクラム方式が初めての採用であるなら、スタートするまでの準備期間のスケジュールも組んでおく必要があります。関係者への根回しや説明、勉強会やセミナーの実施、進め方の決定、会議体やレビューボードの設定、役割分担など、やるべきことは山ほどあります。それらを進めるための*緻密なスケジュールも必要*です。これらを飛ばしていきなり着手するのは、飛行プランも立てずに飛行機を飛ばすようなものです。

###  4.企業や組織の体質に合っていない

アジャイル型開発が適した組織やプロダクトがあります。**若い組織、古い考えに侵されていない組織、あるいは従来のプロダクトとは全く異なる新しいプロダクトにおいてアジャイル型開発は向いています。**

一方、古い組織や成熟したプロダクトを対象にアジャイル開発、スクラム開発がブームだからと飛びついたら、失敗する可能性が高まります。スクラム開発を検討する際は、どの開発方式がベストパフォーマンスを得られるのか、きちんと精査することが求められます。

###  5.スクラム・マスターが役目を果たせていない

スクラム・マスターはスクラム開発におけるリーダー役ですが、一般的なリーダーとは立ち位置が異なります。**スクラム・マスターはチームを牽引するというよりは、ユーザーとの調整弁であり、チームのドクター的存在**で、チームメンバーのサポートに徹しなければなりません。一般組織の古いタイプの管理者のような振る舞いをしてしまうと、メンバーが萎縮し、それぞれの能力を発揮できなくなることがあります。スクラム・マスターはスクラム・マスターとしての研修を受け、しっかり役割を認識しておく必要があります。

## スクラム開発を成功させるためには

従来型の開発手法、**ウォーターフォールはあくまでもプロセス重視ですが、スクラム開発は人であり、マインド**です。細かいプロセスが規定されているわけではなく、あくまでも*メンバーが主役のやり方*です。スクラム開発成功の鍵はそこにあると言えます。以下、もう少しかみ砕いて説明をしていきます。

### スクラム開発(アジャイル開発)を正しく理解する

先ほど、スクラム開発の失敗原因として、コンセンサス不足をあげました。スクラム開発は関係者の理解が最大の力になります。まずはアジャイルの考え方、マインドを関係者が正しく理解することが前提です。それはシステム部門だけではなく、経営層、マネジメント層、人事や管理部門、関係者全員の正しい理解が必要です。*「アジャイル型組織」とは変化即応型で、迅速な意思決定と対応ができる組織*です。できれば、経営者の理解と共感を得て、**企業そのものを「アジャイル型組織」に変革できれば、それがベストです。**まずは、企業変革と併せて、スクラム開発方式を利用できると、成功に大きく近づくでしょう。

### 目指すゴールを全員が共有する

システムやプロダクト開発には必ず目的があり、ゴールがあります。スクラムチームとして何を目指すのか、メンバーの意見を集約しながら目指すゴールを設定し、それを全員で共有する必要があります。**メンバーのベクトルが一致した時に組織は最大限の力を発揮できます。**また、なぜアジャイル開発・スクラム開発方式を導入するのかについても、しっかり*メンバーのコンセンサス*を得ておくことが大事です、スクラム開発にはスクラム方式のルールがあります。ゴールを決め、ルールに従って進めていくことが成功の秘訣です。

### チームメンバーが主役であることを忘れない

スクラム開発のチーム*メンバーは全員が主役*です。主役ということは、メンバー1人1人を尊重し、その働きに対して感謝をすることからスタートします。**スクラム・マスターがメンバーを尊重し、感謝の気持ちを伝えることで、チームメンバーが相互に尊重し合い、強い結束力が生まれます。**チームに必要なのはロボットではなく、人です。血の通った人間です。*ともに悩み、ともに汗を流し、ともに喜びを分かち合う仲間*です。アナログ的な発想かもしれませんが、*これがスクラムの強みとなるのです*。

アジャイル開発の中でも重要な位置を占めるスクラム開発ですが、スクラム開発に失敗するとプロジェクトそのものがとん挫しかねません。スクラム開発の概要、メリット・デメリットを知り、アジャイル開発を成功に導くスクラム開発の効果的、効率的な方法について学びましょう。

1.アジャイル開発の1つの手法、スクラム開発の主役は1人1人のメンバー

2.スクラム開発はメリットが多い反面、使い方を誤ると失敗する

3.ウォーターフォール開発はプロセス重視だが、スクラム開発はマインド重視

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

エンジニアの方は"デグレ"というと分かると思います。**「デグレ」（ディグレーションの略語）は、プログラムの改修の際に引き起こされる性能劣化や品質劣化のこと**ですね。

ディグレーションによって、パフォーマンスが低下することもあれば、バグが発生して品質劣化することもあります。

大抵の場合は、ユーザーの変更要求仕様は満たしたものの、*後工程のプログラムなどで不具合を生じて、ディグレーションとなるケース*が多く見受けられます。

いずれにしても、改修の結果、性能劣化を招いたのなら、一旦元に戻し、その原因究明と正常化を図らなくてはなりません。

「ディグレーション」とよく似た用語に「リグレッション」があります。正確には「リグレッションテスト」ですが、この違いをよく認識しておきまょう。

そもそも*ディグレーションはディグレード（degrade）の名詞で、「悪化」とか「退化」を意味*します。プログラムの改修をした際に、予期せぬ新たな不具合が出てくることをディグレーションといいます。品質や性能が改修前よりも悪くなることです。

**プログラムの改修によってディグレーションが起きていないかどうかを検証するためのテストが「リグレッションテスト」です。**リグレッションテストには「ノンディグレードテスト」や「回帰検証」という呼び方もあります。

### ディグレーションの発生のパターン

**ディグレーションは主にプログラムの改修で起きますが、それ以外にもディグレーションは発生します。**主に以下のパターンで発生します。

*1.プログラムの改修ミス*
ユーザーからの変更要求に従って当該プログラムを修正し、**単体テストや連結テストにも問題が無かったのに、別のタスクに影響を及ぼすのが、このパターン**です。このタスク内では問題がなくとも、別タスクのプログラムがこの改修されたプログラムを呼び出し、正しい応答が無かったために呼び出した側のプログラムに悪影響を及ぼすというような事例もあります。

*2.ミドルウェアなどの設定誤り*
ディグレーションの大半はプログラムミスで起きますが、利用している**ミドルウェアのバージョンアップミスなどでも起きます。**ミドルウェアにバグがあり、その改修版が提供されているにもかかわらず、アップデートを忘れていた結果、ある日突然システムダウンが起きるというようなパターンです。システム担当者はメーカーからの通知で、ミドルウェアのバージョンアップの必要性を認識していましたが、*本番業務で特に問題が起きていなかったので、しばらく様子を見ようと考え、その内にバージョンアップを失念していた*のです。

*3.ドキュメントの記述誤り*
これは1.のプログラム改修ミスの原因でもあるのですが、**改修対象プログラムの影響対象プログラムがドキュメントに正しく記されていれば、防げたディグレーション**です。ドキュメントを作成した人のミスですが、ドキュメント作成者には「プログラマーが分かっているだろう」という*思い込み*があり、プログラマーにはドキュメントを盲信し、自ら影響範囲を確認しなかった責任があります。

前述のディグレーションが起きるパターンから、おおよそ発生原因は分かりますが、**根本的な原因**について整理しておきましょう。

システム開発やシステム改修の際には仕様書や指示書などのドキュメントがあり、プログラマーやシステムエンジニアはドキュメントに従って作業を行います。しかし、*ドキュメントが100%正しい、完全であるという保証はありません*。人が作成しているのですから、その人の性格やスキルに影響されます。漏れや不備もあるという前提で、改修時には影響範囲の調査をしなければなりませんが、これをシステムエンジニアもプログラマーも怠っていたことがディグレーションを招いたのです。こうした**「思い込み」や「怠慢」という人的ミスがディグレーションの主な原因**なのです。

人が行動をする際は、行動指針や行動ルールが必要です。「ミドルウェアの設定誤り」のパターンでは、「ミドルウェアのバージョンアップ」に対する対応指針やルールが定められていなかった事、担当者が勝手に判断したのがディグレーションの原因でした。**判断を必要とし、判断が人によって変わる可能性があるものは基準やルールを設けておかなければなりません。**そして、その基準やルールは関係者に*周知徹底*し、その*遵守を義務化*すべきです。また判断に迷うケース、ドキュメントに記述されていない事象が起きた時には*誰に判断を仰ぐのか*についても明記しておく必要があります。

人はミスを犯しやすい生き物です。しかし、他者とコミュニケーションを取り、互いに意見を交換し、力を合わせ、相互にチェックしあってミスを防ぐ*知恵*があります。仮にドキュメントに不備があっても、情報共有を徹底しておけばミスの多くは防げます。プログラム改修やミドルウェアの変更などは、**関係者全員に共有し、全員が影響確認を行えば、ディグレーションを防げた可能性は高い**です。システム開発にかかわらず、*情報共有の重要性*を再認識しておく必要があります。

*ディグレーションが恐ろしい*のは、一度正常に稼働していたシステムが停止や性能劣化を招くことです。リリース前のエラーであれば影響は大きくなりませんが、**リリース後ということで顧客に直接被害が及ぶ**ということです。

ディグレーションは軽微の影響で済む場合もありますが、**最悪の場合は企業の存亡危機に至るケース**もあります。例えば、銀行オンラインシステムが何年も正常に稼働していながら、軽微なシステム改修によってディグレーションが起き、オンライン業務が全て停止し、顧客に甚大な被害を及ぼしたという例もあります。この営業損失は計り知れません。*金銭的な実害以外に企業ブランドの失墜*という大きな影響を及ぼし、*顧客からの信用が一気に失墜します*。一度信用が失墜すると、それをとり戻すためには大変なエネルギーと時間が必要です。この事は関係者が予め十二分に認識しておく必要があります。

### 本来不要な工数、コストが余分にかかる

システム開発に対して対価がありますが、**ディグレーションによって発生する工数やコストに対する対価はありません。すべて開発側の自己責任、自己負担です。**ディグレーションが重大な場合には、システム開発に伴う利益が全て吹き飛んでしまい、タダ働きと同じ結果になることも珍しくありません。それでころか、*最悪の場合には損害賠償請求を受けるリスク*もあります。

### 多重事故を招き、負の連鎖に陥る

*ディグレーションが起きると、その対応に時間的猶予は許されません*。特にオンラインシステムや業務スケジュールに直接影響するシステムはできる限り速やかな対応が求められます。悠長に原因究明している場合ではありませんので、動けるエンジニアをかき集め、徹夜で復旧に当たります。こうした時に2次障害を招きがちです。ディグレーションの対応をした結果、また別のタスクに影響を及ぼし、別タスクで大規模障害を招くことすらあります。こうして**負のスパイラルに陥り、障害が長期化することすらあります。ディグレーションの恐ろしさは、予期せぬ時に予期せぬことが起きるというところにあります。**

## ディグレーションを起こさないために

以上、ディグレーションの原因や影響について述べてきましたが、経験したことがあるエンジニアは、*ディグレーションは思い出したくもないトラウマ*になっている方もいらっしゃると思います。

ディグレーションは野球で例えるなら、好投していたピッチャーが野手の連係ミスから突然乱調になり、あれよあれよという間に失点を重ねて、わけも分からず降板させられるようなものです。この事で、ピッチャーとしての自信を喪失し、ボールを投げられなくなる人もいます。名投手の呼び声が高かったのに、登板機会を失い、2軍に落ちて、そのまま消えていったピッチャーもいます。システムの世界でもディグレーションのせいで、このピッチャーと同じ道を辿るエンジニアもいます。**百害あって一利なしのディグレーション、何としても避けたいものです。**これから、その忌むべきディグレーションを避ける方法について述べていきます。

### 影響範囲の調査を着実に行う

ディグレーションの多くがプログラミングのミスで起きますが、そのプログラムミスを防ぐには、*プログラム改修の影響範囲を徹底的に調べておく事*です。自ら担当したプログラムを修正するのは比較的たやすいため、改修依頼を受けるとプログラマーは簡単に修正作業に着手しがちです。単体テストで修正指示書通りの結果も得られ、そこで安心しがちです。

それが他タスクに重大な影響があるとも知らず、既に自分の仕事は終わったと解放感に包まれます。

**プログラム修正作業に着手する前に、全員に改修内容について情報共有し、影響調査をしっかり行っておけば、ディグレーションを回避できた**のです。

### イレギュラー時の自己判断は厳禁

組織で動く時に、マニュアルなどに載っていない事象に直面した際は、*自己判断は厳禁*です。上司の判断を仰ぐ、上司が判断できな時は組織で共有し、*組織として意思決定すること*です。また、マニュアルやドキュメントの不備も必ず追記、修正をしましょう。「自分はマニュアルの担当者ではない」と言うようなエンジニアは失格です。便宜上、マニュアル担当者は決まっていますが、マニュアルのオーナーは関係者全員です。マニュアルは全員が担当者だという意識を持って、逐次改定していくことが求められます。また**マニュアルに記されていな事が起きた時の対応ルールはきちんと決めておきましょう。**

### リグレッションテストの範囲を広げてテストする

ディグレーションを回避するためにリグレッションテストがありますが、**リグレッションテストは可能な限り広い範囲で実施すべき**です。例えば、日次処理の改修だったため、日次処理範囲だけリグレッションテストを行い、月次処理でディグレーションが発生したという事例があります。これも影響調査の漏れが原因ですが、**リグレッションテストでは、システム全体図を見て繋がっている関連システムは一通りテスト対象とすべき**です。これをすることによって、影響調査の漏れもカバーできます。

### システム開発はリスクマネジメントも忘れずに

システムは経営向上や業務改善を目的に行われますが、ディグレーションが生じると、それらの目的がすべて吹き飛んでしまいます。その**ディグレーションによる損失を回避、最小限にするためのプロセスがリスクマネジメント**です。

リスクマネジメントと経営とは一体ですが、システムも経営の一部です。そのため**システム開発にはリスクマネジメントの視点が欠かせません。**エンジニアの皆さんは、常にこの視点を忘れず、ディグレーションとは無縁のシステム開発を心がけてください。

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