マイクロサービスアーキテクチャは、ソフトウェア開発をビジネス機能に沿った複数の小さな分類に分けそれらを組み合わせて開発を行うことを指します。 近年注目の開発方法ですが、そんなマイクロサービスアーキテクチャをAWSを活用することで簡単に導入することができます。 この記事ではそんなAWSを活用したマイクロサービスアーキテクチャに関して、具体的にどのようなものなのか徹底解説していきます。 これらに当てはまる方におすすめの記事となっています。この記事を読めばマイクロサービスアーキテクチャを実現するために必要なサービスがわかりますよ。 マイクロサービスアーキテクチャとは マイクロサービスアーキテクチャとはソフトウェア開発技法の1つで、ThoughtWorks社のマーチン・ファウラーとジェームス・ルイスによって提唱されました。 ビジネス機能に沿った複数の小さなマイクロサービスに分割し、それらを組み合わせて単一のアプリケーションを開発するアプローチのことを指します。 マイクロサービスアーキテクチャは「ピザ2枚ルール」をもとに作られたと言われています。 「ピザ2枚ルール」とは、チーム編成や会議において、無駄がなく生産性が高い人数の条件は、ピザ2枚を配りきれる程度の人数（8～10名程度）という考えのことです。 このルールを取り入れることで効率的に作業ができ、お互いを助け合うことができるためチームの団結力が強くなると考えられています。 実際、マイクロサービスアーキテクチャにより、迅速な開発や機能の改善、柔軟な拡張などが可能になります。 マイクロサービスアーキテクチャが注目されているわけ 近年のシステム開発ではITの急速な発展に伴い、ビジネスのニーズにスピーディーに対応することが求められています。そのためアジャイル開発などが注目を浴びるようになりました。 このアジャイル開発は顧客の要求に素早く柔軟に対応できるように、短期間でシステム・ソフトウェアの実装とテストを繰り返して開発を進める手法のこと。 そしてこのアジャイル開発は、小さな機能単位で分割して開発するマイクロサービスと相性がよく、これらを組み合わせて開発やリリースの時間を短縮できることができるのです。 AWSを活用したマイクロサービスアーキテクチャの実現 マイクロサービスアーキテクチャの構築にはサービスを分割したり、それに伴うトランザクションの分割を行うなど、さまざま点に考慮しなくてはいけません そのため、AWSではマイクロサービスアーキテクチャを構築するために以下のサービスが提供されています。 それぞれ見ていきましょう。 Elastic Load Balancing Elastic Load Balancingとはアプリケーションから受信したトラフィックを複数のターゲットへ自動で分散させるサービスのこと。負荷を自動的に分散することでサーバーがダウンすることを防ぎます。 さらにElastic Load Balancingは負荷分散の機能の他にもヘルスチェック機能も備えているので、サーバーのパフォーマンスをリアルタイムでチェックすることもできます。 Amazon ECS Amazon ECSはコンテナ化したアプリケーションを簡単にデプロイ、管理、スケーリングすることができるサービスです。 Amazon ECSを利用することで、アプリケーションを簡単に実行することが可能になります。 Amazon API Gateway Amazon API Gatewayとは規模に関わらず簡単にAPIの作成、公開、保守、モニタリング、保護が行えるサービスです。 そもそもAPIとは2つのアプリケーションやソフトウェア同士の情報のやり取りの際に、プログラミング上で窓口になる場所のことですが、Amazon API Gatewayを利用すればクライアントから受け取ったリクエストをそれぞれのマイクロサービスにルーティングすることが可能になります。 AWS Lambda AWS Lambdaはクラウド上にプログラムを定義しておけばサーバーレスで、インターネットを通じて実行ができるサービスです。 通常プロラムの実行にはサーバーOSやアプリケーションサーバーソフトウェアを準備する必要がありますが、AWS Lambdaはこうした環境があらかじめ準備されているので、ユーザーは実行するプログラムを作成して登録するだけで良いのです。 そもそもAWSとは これまでマイクロサービスアーキテクチャを構築するためのAWSでのサービスを紹介していきましたが、そもそもAWSとは何なのかここで改めて整理しておきます。 「AWS」はAmazon社が提供するクラウドコンピューティングサービスで、世界18カ国で提供されてそのシェアは世界1位。 導入や運用がスムーズで初心者にも使いやすく、先ほど紹介したサービスをはじめとするさまざまな機能を利用することが可能です。 まとめ いかがでしたか。本日はマイクロサービスアーキテクチャを実現するためのAWSのサービスについて紹介していきました。 […]

アジャイルソフトウェア開発宣言とはアジャイル開発という概念がはじめて定義された論文のこと。 アジャイル開発を行う上でこの論文は非常に重要ですが、一歩読み間違えてしまうとアジャイル開発の強みをうまく生かすことができなかったり、逆に手間になってしまうことも。 そこでこの記事ではアジャイルソフトウェア開発宣言に関してどんな内容なのか、どう読み解けばいいのかなど徹底解説していきます。 これらに当てはまる方におすすめの記事となっています。これを読めばアジャイル開発の特徴はもちろん、アジャイル開発宣言の正しい読み解き方まで丸わかりですよ。

現在、「アジャイル」はIT業界の開発だけではなく、様々なビジネス分野でも注目され始めています。なぜ世界中でアジャイル開発が主流になってきているのでしょうか？ 今回はアジャイル開発の概要を解説してみたいと思います。

アジャイル開発は仕様書変更が柔軟に対応でき、リリース時間も短縮できることから、注目の開発手法ですが、近年世界的に見てどのような状況や動向なのでしょうか。 この記事ではそんなアジャイル開発の世界トレンドについて「15th State of Agile Report」を元に解説をしていきたいと思います。 これらに当てはまる方におすすめの記事になっています。これを読めばアジャイル開発の傾向や課題など丸わかりですよ。

小売業界は新型コロナウイルスによる外出自粛による影響で、大幅な打撃を受けました。 その一方で、売上を着実に伸ばしている企業があります。それがWalmartです。2021年度のWalmartの売上高はなんと5592億ドル！ そんな小売の帝王Walmart、成功の秘密はデジタル化とアジャイルへのシフトがあげられます。 今回の記事ではその秘密を徹底解説していきます。 これらに当てはまる方におすすめの記事となっています。これを読めばWalmartの成功の秘密とアジャイル開発の仕組みについて丸わかりですよ。

スクラム開発では、チームや個人に役割を設けワンチームとなり開発を行います。 この記事では、そんなスクラム開発の体制を徹底解説していきます。 オフショア開発にスクラム開発を取り入れたいと思っている方に必見の記事となっています。 これを読めば の疑問が解決できますよ。

スクラムマスターはメンバーが成果を上げるために支援や奉仕をする役割があります。 スクラムマスターによって、スクラムチームがより優れたものになります。 実際、良いスクラムマスターがいるスクラムチームは開発が円滑に進んでいます。 この記事ではそんなスクラムマスターの役割について解説しています。 この記事を読めば、「スクラムマスターの役割は何か」「スクラムマスターに必要なスキルは何か」の疑問が解決できますよ。 合わせて読みたい >> スクラム開発における開発チームの概要

スクラムチームではプロダクトオーナーが重要な役割を果たしています。 プロダクトオーナーによって、プロダクトの価値を最大化することができます。実際スクラムチームを設ける際は、プロダクトオーナーをどう決めるかが重要です。 そんな重要なプロダクトオーナーについてこの記事で徹底解説をしていきます。 オフショア開発でのスクラム開発に興味がある方は必見ですよ。 プロダクトオーナーの役割 プロダクトオーナーは、スクラムチームの3つの役割の1つを担う人であり、開発チームから生み出されるプロダクトの価値の最大化に責任を持ちます。 さらに、プロダクトオーナーはプロダクトのビジョン、プロダクトの特徴・価値を把握していく必要があり、プロダクトの機能を決めてプロダクトの全ての側面に責任を持たなければなりません。 プロダクトオーナーの責任 上記で定義したように、プロダクトオーナーは開発チームの仕事の実績として製品の価値を最大化する責任があります。 具体的には以下の2つの責任があります。 プロダクトオーナーは、ステークホルダー ステークホルダーとスクラムチームの間の架け橋として見なされます。 プロダクトオーナーは個人であり、グループではありません。プロダクトオーナーは、プロダクトバックログ経由でグループの希望を表す代表です。しかし、プロダクトオーナーは、プロダクトバックログに各項目の優先度を変更することが決定できます。 プロダクトオーナーが注意するべきこと アイテムを最適な順序で配置するためにプロダクトオーナーは以下の問題に注意する必要があります。 プロダクトオーナーのタスク プロダクトオーナーの主なタスクは次のとおりです。 製品のビジョンを構築の構築 製品のビジョンを構築し、それが関係者と共有されるようにする保証する（ product roadmap）。 プロダクトオーナーは、この製品は誰が使用する、かどうしてそれを開発するかどのような価値をもたらすかよく理解していきます。 概要計画を立てる 製品リリースを目的とし、概要計画を立てます。 プロダクトオーナーが関係者から必要な情報を収集してロードマップを作成します。そしてその責任者および決定者はプロダクトオーナーでなければなりません。 プロダクトバックログを管理 プロダクトバックログを管理します。プロダクトオーナーは、プロダクトバックログの管理に対して単独で責任を負います。プロダクトバックログの管理には以下が必要です。 プロダクトオーナーは、上記のタスクを自分で実施するか開発チームにその実施を要求することができます。しかし、責任を持つ人はプロダクトオーナーです。 スクラムチームのスプリントイベント プロダクトオーナーは、チームの目標作成者としてスプリントプランニングというイベントに参加し、スプリントで何をするかを決定し、必要な項目を説明します。その目標を達成する方法は、開発チームが決定します。 プロダクトオーナーは、デイリースクラムイベントに参加してもしなくてもかまいませんが、参加したら進捗の全体情報を取得してプロダクトの重要な情報をお知らせ、チームのやり方・計画を干渉しないほうがいいです。 プロダクトオーナーは、ビジョン、スプリントの目標、およびプロダクトバックログの各アイテムの計画に基づいて、進捗の検証者としてプロダクトレビューに参加し、開発チームにフィードバックを行います。 プロダクトオーナーは、スクラムチームのメンバーとしてレトロスペクティブミーティングに参加し、プロダクトオーナーと開発チームの作業を改善するための提案をします。 プロダクトオーナーは、スクラムチームメンバーが一つあるとしてリリースレトロスペクティブに参加してプロダクトオーナーとチームの連携方法を改善するための意見と提案を挙げます。 必要なスキル プロダクトオーナーの役割および責任はプロジェクトにとって非常に重要であると言えます。これらの責任を負担して、関係者とスムーズに連携するために、プロダクトオーナーは次のスキルが身に付いてないといけません。 プロダクトオーナーに重要なクラックの原則とは 記者のBarry Boehm と Richard Turnerによって書かれている「Balancing Agility and Discipline」という著書の中ではプロダクトオーナーが優良なプロダクトオーナーになるためにクラックの原則を守らなくてはいけないと書かれています。 Collaborative 直接な働いている時に開発チーム及びステークホルダーとスムーズに協力できます。いつどんな連絡手段（ライブチャット、メール、電話）でも開発チーム及びステークホルダーに連絡します。 あなた自身をチームのメンバーの１人として考えます。 Representative 顧客と開発チームの両方の代表者です。 顧客との信頼関係を築き、顧客のニーズに応じてプロダクトのビジョンを構築して結び付け、製品の価値を取り次ぐためにスクラムチームを代表します。 Authorized プロダクトオーナーは決定する権限を与えられています。プロダクトオーナーは、一人または大勢を代表する「中間者」ではなく自分が製品の「真の所有者」である事を表さなければなりません。 しかし、プロダクトオーナーは直接決定し責任を負う人ではありません。 Committed […]