マイクロサービスアーキテクチャは、ソフトウェア開発をビジネス機能に沿った複数の小さな分類に分けそれらを組み合わせて開発を行うことを指します。 近年注目の開発方法ですが、そんなマイクロサービスアーキテクチャを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のサービスについて紹介していきました。 […]

アジャイルソフトウェア開発宣言とはアジャイル開発という概念がはじめて定義された論文のこと。 アジャイル開発を行う上でこの論文は非常に重要ですが、一歩読み間違えてしまうとアジャイル開発の強みをうまく生かすことができなかったり、逆に手間になってしまうことも。 そこでこの記事ではアジャイルソフトウェア開発宣言に関してどんな内容なのか、どう読み解けばいいのかなど徹底解説していきます。 これらに当てはまる方におすすめの記事となっています。これを読めばアジャイル開発の特徴はもちろん、アジャイル開発宣言の正しい読み解き方まで丸わかりですよ。 アジャイルソフトウェア開発宣言とは アジャイルソフトウェア開発宣言とは2001年2月に17名の技術者がアメリカ、ユタにて出された開発手法に関する論文です。この論文にはソフトウェア開発を行う際のマインドセットが書かれており、アジャイル開発という概念が誕生したと言えます。 冒頭には、以下の文が記載されています。 私たちは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。 すなわち左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値を置く。（この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。）-「アジャイルソフトウェア宣言」   価値観の多様性や生活水準の進化によって、我々は変化に適応していくことが求められており、アジャイルソフトウェア開発宣言においてもこの考えを大前提としているのです。 個人との対話、動くソフトウェア、顧客との協調、変化への対応を念頭において、その上でプロセスやツール、包括的なドキュメント、契約交渉、計画を考えることこそが大切なのです。 12の原則 アジャイルソフトウェア開発宣言には12の原則があります。 顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供する 要求の変更はたとえ開発の後期であっても歓迎する。変化を見方につけることでお客様の競争力を引き上げる 動くソフトウェアを2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働く必要がある 意欲に満ちた人々を集めてプロジェクトを構成。環境と支援を与え仕事が終わるまで信頼し合う フェイストゥフェイスで話をする 動くソフトウェアこそが進捗の最も重要な尺度 アジャイルプロセスは持続可能な開発を促進する。一定のペースを継続的に維持できるようにしなくてはいけない 技術的卓越性と優れた設計に対する不断の注意さが機敏さを高める シンプルさが本質 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する それぞれ詳しく解説していきます。 顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供する 何が顧客満足度に必要なのか、何がどうなったら顧客満足度が上がるのかなどを徹底的に掘り下げて、継続的に提供していくことが大切です。 12の原則の最初にこの「顧客満足度」というワードが使われていることから、この原則が最も重要なものと考えても差し支えありません。 要求の変更はたとえ開発の後期であっても歓迎する。変化を見方につけることでお客様の競争力を引き上げる 要求があるということは、新しい価値を見つけたということ。いついかなる時も変更を受け入れることで、変化に強くなり企業の競争力を高めることができます。 従来は最初から作れる明確なシステムが大半でしたが、今の時代の人とモノの繋がりを重要視するビジネスでは、最初の時点で明確な要求を用意できることが少なくなっています。 このような現代のビジネススタイルにおいて、従来のままのやり方では対応していくことは不可能です。 変化を受け入れ、改善点を生み出すような開発を行うようにしましょう。 動くソフトウェアを2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする 短期間で納品するには仮説検証型で開発を行なっていく必要があります。成果物を短期でリリースして、顧客の反応で本当にほしいものを修正・開発していく手法です。 長期の開発になってしまうと、当初に求めていたものと今求めているものが変わってしまい顧客満足度を獲得することができないリスクがあります。 短期間のリリースの場合、要求に対してたとえ後戻りがあったとしても、修正もやりやすくなるのです。 ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働く必要がある ビジネス側の人と開発者が協業することで、開発や改善をスムーズに行うことができるようになります。 常に方針や目標を共有しあって、必要に応じて改善をしていきましょう。万が一、一緒に働くことができない場合は、打ち合わせの頻度を上げたり、チャットツールをうまく活用するなど工夫していく必要があります。 意欲に満ちた人々を集めてプロジェクトを構成。環境と支援を与え仕事が終わるまで信頼し合う 働きやすい環境は、意欲のある人を集め信頼関係を構築することです。たとえスキルが高かったとしても関係が悪ければ十分な能力は発揮することができません。 アジャイル開発の手法の1つのスクラムでは、開発者はプロジェクトを通じて学習し成長するというものがありますが、その前提には意欲の高さがあります。 フェイストゥフェイスで話をする 先述したようにビジネス側の人と開発者は対面で話をすることで、咀嚼や誤解を最小限にとどめることができます。 直接話すことで、表情や仕草などから言葉では伝わらない情報も伝達することができるのです。 この時、一方通行の報告のみではいけません。あらゆることを固定概念なしに直接話し合いをすることで、今まで気づかなかったことに気づくこともできます。 動くソフトウェアこそが進捗の最も重要な尺度 進捗を把握するために、タスクの消化状況を計画と照らし合わせる方法がありますが、開発中のソフトウェアの状況を見るには、動くソフトウェアを通じないとわかりません。 さらに、動くソフトウェアを通じて進捗を把握することで、実際にプロダクトを動かした際にわかる想定外の問題を把握することができ、早期にリスクヘッジを行うことが可能になるのです。 アジャイルプロセスは持続可能な開発を促進する。一定のペースを継続的に維持できるようにしなくてはいけない ゴールを目指して過負荷をかけてしまう開発者が多くいますが、そのような状態では改善の意欲やアイディアは生まれず、結果として生産性を下げてしまうことになってしまいます。 開発の目的は価値を生み出すことにありますが、疲弊すると目の前の作業を終わらせることに集中してしまい、目的が変わってしまう恐れもあるのです。 […]

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

アジャイル開発は仕様書変更が柔軟に対応でき、リリース時間も短縮できることから、注目の開発手法ですが、近年世界的に見てどのような状況や動向なのでしょうか。 この記事ではそんなアジャイル開発の世界トレンドについて「15th State of Agile Report」を元に解説をしていきたいと思います。 アジャイル開発に興味がある方 社内のIT人材が不足している方 アジャイル開発の世界トレンドを知りたい方 これらに当てはまる方におすすめの記事になっています。これを読めばアジャイル開発の傾向や課題など丸わかりですよ。 15th State of Agile Report 15th State of Agile ReportとはDigital.ai社がアジャイルのトレンドを調査したレポートになります。毎年1回発表していて、今回の調査では2021年2月〜4月の間にのべ4,182人から回答を受けました。 レポートでは、アジャイルの経験から導入の課題、アプローチについてやテクニックについて、ツールなどあらゆる調査を行っています。 新型コロナウイルスでの多様な働き方 新型コロナウイルスによるパンデミックでリモートワークが急激に広まった2020年。その後、ワクチン接種が広まった現在、欧米の一部では徐々にオフィスに戻る動きも出てきています。 そんな中でも、4分の1の企業はアフターコロナでもフルリモート、56％の企業がハイブリットの働き方を望んでいるそう。現時点ではオフィスに戻ることを計画している企業はたったの3％でした。 このように、ウィズコロナ、アフターコロナの世界では働き方の多様化が求められています。 アジャイル開発の導入率の増加 ソフトウェア開発企業におけるアジャイルの導入率は2020年には37％でしたが、2021年は84％に成長しました。 その一方で、非IT部門ではアジャイルの導入はまだまだ成長途中です。プロセスと実践が矛盾している点、文化的な問題、組織の変革の問題などがその要因となっているようです。 DevOps及びValue Stream Management 価値があるサービスが重要視される中、DevOpsやValue Stream Managementが注目されています。 DevOpsとは「開発側（Development）と運用側（Operations）が協力して開発するシステムの価値を高め、ビジネスの価値をエンドユーザーに届ける」という考え方のことを指します。15th State of Agile Reportの3分の4がDevOpsによる変革が重要だと回答しています。 また、2分の3がValue Stream Managementを実行、もしくは計画中と回答しています。そもそも、Value Stream Managementとは仕事の状況を分析し、将来的により効率的になるように調整していくことを指します。これにより、自分の仕事を可視化し、改善点を見つけることができるのです。 アジャイルに対する課題 本調査ではアジャイルに対する課題として以下があげられています。 チーム間のプロセスと実践に対する矛盾 組織文化 スキルや経験不足 リーダーがいない アジャイル手法について、リーダーがいないという回答は少し驚きですが、新しい手法に関する知識不足や社内環境の変化がその障壁になっていることに違いありません。 こうした企業はアジャイル開発を外部に依頼してみてはいかがでしょうか。また実際にアジャイルシフトに成功した企業の情報を参考にしてみるのもおすすめです。 合わせて読みたい＞＞小売の帝王Walmart！アジャイルシフトの軌跡 まとめ いかがでしたか。本日はアジャイル開発に関して、「15th […]

小売業界は新型コロナウイルスによる外出自粛による影響で、大幅な打撃を受けました。 その一方で、売上を着実に伸ばしている企業があります。それがWalmartです。2021年度のWalmartの売上高はなんと5592億ドル！ そんな小売の帝王Walmart、成功の秘密はデジタル化とアジャイルへのシフトがあげられます。 今回の記事ではその秘密を徹底解説していきます。 アジャイル開発に興味がある方 小売業界で働いている方 デジタル化によってビジネスを成功させたい方 これらに当てはまる方におすすめの記事となっています。これを読めばWalmartの成功の秘密とアジャイル開発の仕組みについて丸わかりですよ。 小売業界の現状 新型コロナウイルスによる外出自粛や店舗の営業時間短縮などで、小売業界は大きな打撃を受けました。 アメリカの2020年4月の小売売上高は、新型コロナウイルス発生前の2019年12月と比べると23.1％減の4,039億4,600万ドルでした。 日本でも同様に小売業界は打撃を受け、特に百貨店の市場規模は2020年は前年よりも25%減少したとのことです。（4兆2000億円）　これは、1975年以来45年ぶりの低水準でした。（参照：コロナ禍で世界の小売市場はどう変わった？　キーワードはデジタル×サステナビリティ×ローカライゼーション） 一方、オンライン販売は好調で、世界のEC市場は2020年に4兆ドル規模になりました。 これは前年比25％増とのことです。 今後は実店舗の売上高も回復する見込みと言われているため。実店舗（オフライン）とオンラインをうまく組み合わせたサービスが注目されていくでしょう。 Walmartの軌跡 Walmartはアメリカで1962年に創業されたスーパーマーケットです。「EDLP（エブリデイ・ロー・プライス）」を打ち出し、年間を通じて低価格を提供、34,763店もの店舗数を誇ります。（アメリカ国内～2018年度） そんなWalmartでは、2014年にダグ・マクミロンCEOが47歳の若さでトップに就任後、Walmartのデジタル化を進めました。 当時は巨大企業であるWalmartのデジタルシフトに対し、株式市場では懐疑の目が向けられ2015年7月には時価総額で米アマゾン・ドット・コムに抜かれ、2015年末の株価は前年比で3割弱低下してしまいます。 しかし、2021年度のWalmartの売上高は、5592億ドルとなりグローバルの小売トップに輝いているのです。 投資の内訳では、ITやECへの投資が68％となっていて、デジタルシフトが実行されたことがわかります。 店舗業務をデジタルツールで簡素化する Walmartのような店舗数の多い企業では、新サービスを導入すると店舗従業員の作業量が増えてしまうことが問題視されていました。 そこで、Walmartでは人を増やすことなくデジタルツールを導入して、現場の働き方を変えていったのです。 例えばロボット「Auto-S」はWalmart本社近くの都市、ロジャースで利用されています。ロボット「Auto-S」LEDで棚を照らしながらカメラで陳列のチェックを行います。 陳列棚に商品がない場合、スタッフに商品補充をするようアナウンスが伝達される仕組みになっています。 他にも、フロアクリーナーロボット「Auto-C」や配送トラックからの荷物を受ける検品機能付きアンローダー「FAST」などさまざまな単純作業をデジタルツールが補っているのです。 ネット通販での拡大 ダグ・マクミロンCEOは16年の新興ECサイト、ジェット・ドット・コムの買収のように、ECサイトの運営企業を次々と買収することでエンジニアを獲得していきました。 そんなWalmartでは店舗の小売の要素は残しつつ、自社ECの倉庫や配送拠点、ECのストアピックアップの要素として活用したのです。 つまりオンラインとオフラインのオムニチャンネル化を実現したのです。 エクスプレスデリバリーはアジャイル手法 エクスプレスデリバリーは人と人の接触を最小限に抑えた宅配サービスで、2020年4月からスタート、アメリカの2800店舗に広まっています。 商品の在庫情報や配送車、配達員の空き情報、交通状況や気象情報などをもとに機械学習を取り入れて、最適な配達経路を計算、注文を受けてから2時間以内に商品を宅配するサービスです。 配達状況の情報をユーザーにお知らせしているので、ユーザーも不満なく利用することができます。 このサービスは少人数のチームで開発を行うアジャイル手法によって手掛けられました。 アジャイル手法とは アジャイル手法とは顧客の要求に素早く柔軟に対応できるように、短期間でシステム・ソフトウェアの実装とテストを繰り返して開発を進める手法のことを指します。 機能単位を小さなサイクルに分け、「要求決定→設計→開発→実装→テスト→リーリス」の開発工程を繰り返します。 タスクを細分化することで、仕様書変更も柔軟に対応でき、普通の開発手法よりもリリース時間を短縮できると言ったメリットがあります。 近年ではテレワーク化が進み、コミュニケーションの量や質が低下してしまったことは言うまででもありません。 そんな中、タスクをしっかり可視化してチームで作業することで、テレワークであってもチームの生産性を維持していくことができるのです。 アジャイル手法のやり方 アジャイル手法では最大でも10人前後の少人数のチームで構成がされます。 その中にはスクラムマスターとプロダクトオーナーを組み込みましょう。 ただしこれらの役割はチームのリーダーではありません。 アジャイル手法ではメンバーそれぞれが専門分野を持ち、重要事項はチーム内で意思決定していくのです。 専門知識がある個人だからこそ、それぞれの視点で解決策やアイディアを出し、それをチームで議論、統合して方向性を決定していくのです。 スクラムマスターとプロダクトオーナーについてもう少し詳しく紹介していきます。 スクラムマスター スクラムマスターはメンバーが成果をあげるべく支援を行う人材のことを指します。 具体的にはスクラムチームとやり取りをするときに役に立つこと、立たないことをスクラムチームの外部の人たちに理解してもらうのです。 スクラムマスタ ーは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化していくことができます。 プロダクトオーナー […]

スクラム開発では、チームや個人に役割を設けワンチームとなり開発を行います。 この記事では、そんなスクラム開発の体制を徹底解説していきます。 オフショア開発にスクラム開発を取り入れたいと思っている方に必見の記事となっています。 これを読めば スクラム開発の開発チームとは何か？ スクラム開発のチームの役割は何か？ の疑問が解決できますよ。 開発チームとは 開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されています。 「完成」したインクリメントは、スプリントレビューに必要になります。インクリメントを作成できるのは、開発チームのメンバーだけになります。 開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられています。その相乗効果によって、開発チーム全体の効率と効果が最適化されます。 その開発チームのうち、開発以外の細かな調整はスクラムマスターやプロダクトオーナーが行います。 開発チームの作業内容 スクラムの活動では「プロダクトインクリメント」を生み出すために必要な作業を直接実行します。 スプリント中、開発チームは製品のプロダクトバックログアイテムの設計、開発、テスト、および製品のプロダクトインクリメントへの統合を実行します。 これを行うために、開発チームの計画立て、管理、および相互通信の手段を自己組織で決定し、すべてのスプリントに完了したプロダクトインクリメントを最後に転送する必要があります。 ここからはその詳しい方法について解説していきます。 スプリントの計画を立てる 開発チームは、各スプリントの最初の計画に参加し、スクラムマスターの指定を通じてプロダクトオーナーと協力し、スプリントの目標を設定します。 スプリント目標の設定以降、チームは優先順位を再調整し、その目標を達成するためのタスクを実行計画を立てます。 開発チームで必要な進捗確認  スプリントの実施中は、各スプリントの目標を達成するために、開発チームの役割の進捗を交換する毎日のスクラムに参加し、残りのジョブの完成計画を修正する必要があります。 チームメンバーの誰かがこのイベントに参加できない場合、チーム全体で情報が不足している可能性があり、全体像の一部が不足している恐れがあります。それにつれて、各スプリント、あるいはプロジェクトの全体の目標が達成できない恐れもあります。 グルーミングプロダクトバックログ（製品開発カテゴリを明確化） 各スプリントでは、開発チームは次のスプリントに向けて作業の準備をするために、プロダクトオーナーとの相談の時間の必要です。 相談のほとんどは製品の残りの要求を明確化、追加するためです。 そのため、各要求の情報を作成、修正、追加します。優先度に基づいてアイテムを見積もり、再配置します。 各スプリントの開発チームは、スプリント全体の時間の最大10％をこのタスクの実行に費やしています。 スプリントレビューとスプリントレトロスペクティブ 各スプリントの最後に、開発チームはスプリントレビュー（製品レビュー）およびスプリントレトロスペクティブ（ワークフローの改善）という、2つの検査と適応イベントに参加します。  スプリントのレビューでは、開発チーム、スクラムマスター、プロダクトオーナー、およびその他の利害関係者は、プロダクトオーナーから招待され、チームがスプリントで完了したプロダクトインクリメントについての試行、評価、フィードバックを提供します。  スプリントレトロスペクティブでは、スクラムマスターの調整の下で、開発チームがプロダクトオーナーとともに、チームでのコラボレーション方法および作業プロセスの検査と適応について商談し、プロダクトインクリメントをより早く、より多い価値を転送できるよう、または製品の質をより高めるよう、良い技術を探します。 開発チームの規模 開発チームの最適な規模は、柔軟性を維持できるほど小さく、スプリント中に重要な作業を完了するのに十分な大きさです。 メンバーが3人未満の場合、開発チームはやり取りが少なくなり、生産性が低下します。 そのような小さな開発チームは、スプリント中にスキルの制限を経験する可能性があり、開発チームは最終製品の段階的な仕上げを提供できなくなる可能性があります。 メンバーが9人を超えると、調整が必要になります。 大規模な開発チームは非常に多くの複雑化を引き起こし、実験プロセスの有用性を低下させます。 プロダクトオーナーとスクラムマスターの役割は、スプリントバックログの作業を行っていない限り、開発チームには含まれません。 開発チームのあるべき姿は「自己組織化」と「連結機能を持つチーム」 自己組織化 自己組織化とは、チームが生産プロセスを導き、決定を下す能力と権限を持っていることを意味します。 つまり、チームがツール、テクニック、および仕事を完了するための方法の選択肢、全てを制御できることも意味します。 同時に、チームメンバーの関与と責任は、コマンド・コントロールモデルで編成されているチームよりもはるかに高くなります。 スクラムの開発チームの自己組織的な性質は、以下のような点です。 チームに管理職はいない。チーム管理を担当する個人は一人もいない。 開発チームは、各スプリントを作成するプロダクトバックログの各項目の数を自己的に選択して決定する。 開発チームは、各項目のワークロードを自己推定する。 開発チームは、自身の作業の進捗状況を監視する。 すべてのジョブは、個人に割り当てられることなく、チーム集団によって「所有」される。したがって、結果が良いか悪いかにかかわらず、その責任は一人にではなく、チーム全体に与える。 連結機能を持つチーム 連結機能を持つチームとは、外部からの支援なしに、ジョブ全体を完了し、各スプリントの終わりに転送可能なプロダクトインクリメントを生み出すために必要なすべてのスキルを完全に備えていることを意味します。 これは、それぞれのメンバーがすべてのスキルをもっている必要があるという意味ではなく、特定の数のスキルしか持っていないが、お互いを補完し、チームが必要なすべてのスキルを持つという意味です。 連結機能を持つことで、チームが動作し、完全な生産ユニットとなり、生産性と製品品質を向上させることができます。これにより、チームは外部から待つことなく、迅速に意思決定を行えます。 開発チームでは、各メンバーが、テスター、プログラマー、設計の専門家、データベースの専門家などの特定の職種を持っていないません。すべて「開発者」と呼びます。 […]

スクラムマスターはメンバーが成果を上げるために支援や奉仕をする役割があります。 スクラムマスターによって、スクラムチームがより優れたものになります。 実際、良いスクラムマスターがいるスクラムチームは開発が円滑に進んでいます。 この記事ではそんなスクラムマスターの役割について解説しています。 この記事を読めば、「スクラムマスターの役割は何か」「スクラムマスターに必要なスキルは何か」の疑問が解決できますよ。 合わせて読みたい >> スクラム開発における開発チームの概要 スクラムマスターとは？ スクラムマスターとは、スクラムガイドで定義されたスクラムの促進と支援に責任を持ちます。 スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することでその責任を果たします。 スクラムマスターの役割  スクラムマスターは、スクラムチームのサーバントリーダーのこと。サーバントリーダーとはメンバーが成果を上げるために支援や奉仕をするリーダーを指します。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと、立たないことをスクラムチームの外部の人たちに理解してもらう必要があります。 スクラムマスタ ーは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化していくことができます。 スクラムマスターとプロダクトオーナーの関係性 スクラムマスターは、さまざまな形でプロダクトオーナーを支援します。 スクラムチームの全員が目標、狙い、プロダクトのドメインを可能な限り理解できるようにする 効果的なプロダクトバックログの管理方法を探す 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう 経験主義におけるプロダクトプランニングについて理解する  価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握しても らう アジャイルを理解・実践する 必要に応じてスクラムイベントをサポートする スクラムマスターとプロダクトオーナーの関係性 スクラムマスターはさまざまな形で開発チームを支援します。 自己組織化・機能横断的な開発チームをコーチングする 開発チームが価値の高いプロダクトを作れるように支援する 開発チームの進捗を妨げるものを排除する 必要に応じてスクラムイベントをサポートする スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチングする スクラムマスターはさまざまな形で組織を支援する スクラムマスターは、さまざまな形で組織を支援します。 組織へのスクラムの導入を指導・コーチングする  組織へのスクラムの導入方法を計画する スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう スクラムチームの生産性を高めるような変化を促す 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める スクラムチームの4つの役割 ITで15年以上の経験を持つチェコのアジャイルコーチのズザナ・ショホバによると、「The Great ScrumMaster-#ScrumMaster Way」で、スクラムマスターはスクラムチームとアジャイル型組織に4つの役割を持っていると述べました。 その４つは①Teaching and Mentoring  − 教育とメンタリング、②Impediment Remover − 障害の除去、③Facilitator − ファシリテーターと④Coaching […]

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