皆さんは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を使って効率的に仕事を！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サービス・ツールの記事（40ページ目）