自分自身の開発経験から、もっと早くからスクラムとスクラムマスターを経験しておけばよかったと思っています。スクラム未経験の方には、この記事がスクラム導入のきっかけとなればば幸いです。また、スクラム経験者の方にとっては、より良いスクラム開発プロセスを考えるきっかけになることを願っています。 --- 私たちは長いソフトウェア開発プロセスの終盤をむかえ、ようやくお客様に製品を届けることができて興奮していました。開発開始時に受け取ったお客様からの要件使用書を元に、何ヶ月もかけて熱心に作業した結果、お客様が求めていたものをすべて実現した素晴らしい製品ができあがりました。 少なくとも私たちはそう考えていました。 残念ながら、それはお客様の求めていたものではありませんでした。私たちの理解に誤解があったようです。いくつかは明確に私たちのせいでした。しかし、いくつかはお客様側に原因があるように感じることもありました。お客様から受け取った要件仕様書を見直してみると、ある事項については仕様に曖昧な部分があることがわかりました。いずれにせよ、ソフトウェアはお客様の要望に応えられず、その場の誰も満足できない結果になってしまいました。 このとき、私は明らかにチームリーダーとして失敗しました。しかし、もし私がスクラムマスターとしてスクラムプロセスで開発していたら、物事は違った方向に進んでいたでしょう。 スクラムやアジャイル開発プロセスを導入したのは、その苦い経験があったためです。いま、私はスクラムの熱狂的なファンになっています。 私がスクラムを好きな理由の一つは、途中でチェックイベントがあるため、間違った機能の開発に何ヶ月も無駄にすることなく、プロセスの非常に早い段階で問題や誤解を発見することができるためです。もしスクラムをずっと使っていたら、何ヶ月もかけて間違った開発をすることはなかったと思います。 スクラムとは? スクラムは、アジャイル開発のために最も広く使われているプロセス/プロジェクト管理フレームワークであり、チームワークを使って迅速な反復サイクルで製品をリリースすることを重視したソフトウェア開発アプローチです。 Photo by: Smart Works for Upsplash スクラムマスターとは? スクラムでは、小さなチームで協力して仕事を進めていきます。スクラムマスターは、スクラム開発チームの「サーバントリーダー」(奉仕型リーダー)です。 「サーバントリーダー」とはどういうことなのでしょうか？従来のリーダーは組織の頂点に立ち、上から指示を出してメンバーにタスクを割り振るのに対し、スクラムマスターはメンバーを下から支える立場です。従来のリーダーと同じように、チームに方向性を示してプロセスをスムーズに進行させていきます。しかし従来のリーダーとは異なり、スクラムマスターは自分の仕事をメンバーに割り振ることはありません。そうではなく、スクラムチームの生産性を向上させるために、全力でサポートすることが仕事です。 スクラムチームには誰がいるのか？ スクラムの教科書によると、スクラムチームは、開発のあらゆる側面に対応できる3人から9人の自己完結型のユニットであるべきだとされています。つまり、あなたのチームはスクラムマスターに加えて、デザインスキル、エンジニアリングスキル、品質保証スキルなどすべてのスキルを一通り備えている必要があります。各機能の専門家が一人ずついる必要はありません。チームのフロントエンド開発者が同時に熟練したデザイナーであったり、プログラマーがテスターを兼務することもあります。 現実のプロジェクトは、教科書に載っているような完璧な世界とは限りません。スクラムチームの中には、10人以上のメンバーがいるチームもあります。会社によってはフロントエンド開発のみに特化したスクラムチームと、バックエンド開発作業のみに特化したスクラムチームがあるかもしれません。しかし、これらは理想的なスクラムチームとはいえません。 スクラムマスターの仕事内容は? スクラムマスターには3つの大きな責任があります。成功するためには、すべてを上手くこなさないといけません。 1.      スクラムチームのミーティングを促進するスクラムのフレームワークでは、プロジェクトは「スプリント」と呼ばれる1週間から4週間程度の短い期間に分割されます。各スプリント期間中はミーティングが何度も行われます。 スプリントの最初で、スクラムマスターは「スプリント計画」会議をリードします。このミーティングでは、プロダクトオーナーが顧客のニーズを説明し、タスクの優先順位を決めます。その後、あなたのスクラムチームは、各タスクを完了するために必要な難易度と時間を議論し、このスプリント中に実施する項目を選択します。 スプリント期間中、チームは毎朝集まって、各チームメンバーのタスクの状況を確認するための短いスタンドアップミーティングを行います。ここでのスクラムマスターの仕事は、全員がスケジュール通りに進んでいることを確認し、タスクに遅れが生じているメンバーがいる場合には、軌道に乗るようにサポートすることです。…

アジャイルマニフェストは、ソフトウェア開発に大きな影響を与えただけでなく、ビジネスの世界にも応用されています。しかし、ソフトウエア開発を取り巻く環境が大きく変わってきた今、それでもまだ有効といえるでしょうか？ 1. アジャイルマニフェストの概要 アジャイルマニフェストは、2001年にユタ州のリゾート地での開発者が集まる小規模な会議で考案されました。 短いながらも非常に影響力があり、「4つの価値」と「12の原則」で構成されています。「4つの価値」は以下のとおりです。 アジャイルマニフェストの4つの価値 プロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を 12の原則では、迅速性、コラボレーション、継続的な反復プロセス、および定期的な製品リリースなどを重視することが述べられています。 アジャイルがうまく機能すると、これらの要素が連携して、開発者、顧客、およびその他の利害関係者間の強力なフィードバックループが確立されます。 マニフェストがソフトウェア開発に及ぼす影響は非常に大きいと言えますが、その影響力ゆえに、ソフトウェア開発の状況が変化した現在においてもマニフェストが当てはまるかどうかについては論争の的となっています。 実際、初版のマニフェストの署名者の中にも「見直す時期だと思う」と述べている人もいます。 マニフェストの原作者の1人であるAndy Hunt は、「口先だけでアジャイルを語る熱狂的なグループがいます。熱狂的なファンというものは、目的を忘れて無駄な努力だけを続けるものです。そして最悪なことに、アジャイル "手法" 自体はアジャイルではありませんでした。これはまったく皮肉なことです。」と述べています。 ソフトウェア開発者が増加し多様化する今の時代においても、アジャイルマニフェストは役に立つのでしょうか？ Photo by Bonneval Sebastien on Unsplash 2. マニフェストが今も有効であるという意見 アジャイルマニフェストが現代のソフトウェア開発においても引き続き有効であるという証拠として以下の3つをあげることができます。 多くのベストプラクティスの土台 アジャイルマニフェストは、最新のソフトウェア開発における複数のベストプラクティスのコア要素となっており、これらは広く影響力を持つようになっています。 その影響力の例は次のとおりです。 スクラム：アジャイルのアイデアに基づく小規模チーム向けのフレームワークユニファイド・プロセス：ラショナル・ユニファイド・プロセス(RUP)…

プロジェクトマイルストーンは、どのようなプロジェクトにおいても重要であり、チームメンバーには重要な日付を、利害関係者には透明性を提供し、プロジェクトマネジャーにとっては、プロジェクトの管理を容易にしてくれるものです。 プロジェクトマネージャーとして、様々な部署や個人にまたがる大規模プロジェクトの計画と実行を行う際、プロジェクトマイルストーンはタスクを時間通りに維持するために不可欠です。しかし、具体的にどのようにしてプロジェクトのマイルストーンを定義するのでしょうか？ プロジェクトマイルストーンとは？ プロジェクトマイルストーンとは、プロジェクトの明確な成果を表す特定の時点のことです。高速道路に沿ってマイルマーカーが設置されていることで、どこまで運転したかを知ることができるように、プロジェクトマイルストーンでプロジェクトの進捗状況を知ることができます。 プロジェクトマイルストーンには通常「幅」はありません。プロジェクトの進捗状況をチームメンバーや利害関係者に正確に伝えるためには、確定した日付が重要です。これらのマイルストーンは、長いプロジェクトや大規模なプロジェクトをより管理しやすい期間毎に分割するのに役立ちます。 幹部や上位の利害関係者は、プロジェクトの日々の活動を意識していないかもしれませんが、マイルストーンが近づくにつれて、だんだん関心を持つようになります。マイルストーンに支払いが含まれている場合は、ベンダーや業者も特別な関心を持つことがあります。プロジェクトのマイルストーンに注目が集まる中、マイルストーンを正しく定義することが重要です。 マイルストーンの設定方法は？ Photo by Startaê Team on Unsplash https://unsplash.com/photos/7tXA8xwe4W4 適切なマイルストーンを決定することは、プロジェクトの健全性の維持に不可欠です。プロジェクトの進捗状況を関係者全員にわかりやすく共有してくれます。 マイルストーンは、ほとんどの場合、作業の重要なフェーズの開始または終了、締め切り、またはプロジェクトのその他の主要な分岐点を表しています。プロジェクトの開始日と終了日は重要なマイルストーンですが、プロジェクトの種類によっては、その間にも数多く設定されます。 一般的なマイルストーンには、以下のようなものがあります。 主要業務の完了Go /No Go の決定テスト段階の完了最終サインオフ 家を建てることに例えると、主な成果物は家そのものであり、あなたはプロジェクトマネージャーであり、家に住む家族は利害関係者です。 プロジェクトマイルストーンのリストには、以下のようなものがあるでしょう。 月曜日に壁が完成する水曜日に屋根を仕上げる金曜日に配管工事が完了する 家族のほとんどは、自分の家に含まれているパイプの一つ一つには興味を示さないでしょうが、配管が完成したときに知りたいと思うでしょう。ここでマイルストーンの出番です。上記のリストは、あなたが家の作成に必要な全てのタスクを把握することなく、家の現状についてどこまでできているのかを通知するのに役立ちます。また、作業者も何が期待されているかを知ることができます。マイルストーンは、プロジェクトに関わる全ての人を同じ認識に保つのに役立ちます。 もちろん、マイルストーンはプロジェクトの特定のポイントをマークするだけではありません。一工夫することで、あらゆることを「スケジュール」することに役立ちます。プロジェクトのマイルストーンを使って、重要な会議やワークショップをチームに思い出させることができます。業者への支払いや、納品を期待していることを思い出すときにも使えます。プロジェクトのマイルストーンは、プロジェクトの重要な部分を皆に思い出させるシンプルで効果的な方法です。 プロジェクトマイルストーンを使ってスケジュールを組むには？ プロジェクトマイルストーンは、プロジェクトマネージャがプロジェクトの特定のフェーズを完了するのに必要な時間を正確に見積もるのに役立つだけでなく、プロジェクト自体を完成させるのにも役立ちます。 プロジェクトを開始する際には、いくつかのプロジェクトマイルストーンを設定しておくと便利です。月によっては他の月よりも活動量が多い場合もありますが、経験則としては、1ヶ月に1回以上の区切りを設けるのが良いでしょう。プロジェクトの開始時からマイルストーンを組み込むことで、スポンサー、役員、その他の利害関係者からの期待を管理することができます。また、どのタスクを完了させたか、どのタスクが遅れてしまったかを記録しておくのにも役立ちます。 そのようなプロジェクトマイルストーン前に発生する様々な問題を簡単に管理するために、Sleeek…

アジャイル手法は、絶えず変化する市場のニーズに素早く対応したいと考える技術系企業に適した手法であり、近年、規模を問わず様々なソフトウェア開発に活用されています。アジャイル開発を採用することで、開発チームは迅速な反復サイクルで製品を作り、テクノロジー業界の変化に容易に適応することができます。 VersionOne 社のState of Agile Report　2018年版によれば、「何らかの形でアジャイル手法を実践している」と回答した組織はアンケート対象の97%にのぼりました。 しかし、アジャイル手法が広く受け入れられる一方で、アジャイルの概念については間違った解釈をされることも少なくありません。そもそも「アジャイル」とは、手法やプロセスを指すものではなく、アジャイルによってもたらされる価値や実践すべき原則を示したものです。 1. アジャイルの歴史 Photo by İrfan Simsar on Unsplash 1970年代から2000年頃までの間に、従来の製品開発プロセスがソフトウェア開発においては機能しないことが明らかになりました。 ソフトウェアプロジェクトが完了する頃にはビジネスニーズがすでに変化していた、ということが頻発し、いわゆる「アプリケーション開発の危機」あるいは「アプリケーションの完成までのずれ」などと言われました。プロジェクトが途中でキャンセルされり変更を求められることが続き、開発者たちはもっと良いやり方を探す必要に迫られました。 その後、業界が市場に適応できないことに不満を抱いた17人の思想的リーダーが集まり、ソフトウェアを開発するより良い方法について議論し、2001年に「アジャイルマニフェスト」をまとめました。彼らの定義した以下の4つの価値と12の原則は、多くのソフトウェアチームに採用され、製品を常に最新の需要にキャッチアップさせるために役立っています。以下に引用しましょう。 4つの価値 プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 12 の原則 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。動くソフトウェアこそが進捗の最も重要な尺度です。アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。シンプルさ（ムダなく作れる量を最大限にすること）が本質です。最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 © 2001 Kent Beck, Mike Beedle,…

スクラムは、最も人気のあるアジャイルソフトウェア開発手法です。 Coding Sansが2019年に実施したソフトウェア開発の状態に関するレポートでは、回答者の60.58％がスクラムを使用し、35.4％がカンバンを使用し、19.71％がアジャイルモデリングを使用していると回答しました。 スクラムの人気が高まっているのと同時に、リモートで作業する開発者の数も急増しています。OWLLabsによる2019年のリモート作業の現状についてのレポートによると、米国の労働者のほぼ3分の2が少なくとも一度はリモートで働いたことがあり、ほぼ半分が週に一度以上リモートで働いています。 TecLAのリサーチでは、世界でリモート勤務する職業トップ5の中にソフトウェア開発者が入っていることが報告されています。 また、ソフトウェア開発者の仕事に従事する人は2026年までに24％増加すると見込まれています。 スクラムは本来物理的に一カ所に集まるチームのために作られた開発手法であり、毎日スタンドアップ・ミーティングを開いたり、スプリントレトロスペクティブ(振り返り)という情報共有の機会が含まれています。そのため、リモートで働くソフトウェア開発者がスクラムを使って開発するには、スクラムの方法を変えなければなりません。 ソフトウェア開発においてスクラムを導入すると、以下のような利点が得られるでしょう 製品リリースを加速させる 製品の品質とチームの生産性を向上させる コストを削減させる チームの士気を向上させる 顧客満足度を向上させる 複雑なタスクの実行を可能にする 関係者により透明性を提供する リモートワークには多くの利点がありますが、リモートチームがスクラムを行う場合、スクラムにおける各種イベントや情報伝達を効果的に実行し、リモートチームであることで生じる課題を克服するという新しいチャレンジがあります。 私たちスリークは、数カ国に分散したチームを持つソフトウェア開発企業として、リモートのスクラムチームが直面する問題を過去に経験しました。 以下に、リモートであることによって悪化しがちな問題とそれに対するアイディアをいくつか挙げていきます。 スクラムを妨げるリモート作業の5つの困難 1.フィードバックの遅れ 例えば米国の開発チームがアジアにいる開発者に何か質問をする場合、現地が朝になるまで返事を待たなければならないことがあります。 返事の遅れは、開発プロセスの遅れを引き起こします。5分のチャットで済むはずの同僚とのチャットが、現地が週末に入ってしまったために週明けまで3日待たなければならないということも起こりえます。 2.困難なスケジュール調整 各開発者が時差のある場所で勤務している場合、全員が同時に参加できる会議を開くことができる時間帯は限られます。時には片方のチームが他の開発者に合わせて、通常の勤務時間外に作業をせざるを得ないこともあるかもしれません。3つ以上のタイムゾーンがある場合、スケジューリングはさらに大きな課題となるでしょう。 リモートチームとの間に時差がない場合でも、同じオフィスにいれば数分で済むような会話をするためにスケジュール調整をしなければならないこともあります。 3.プロセス統一のためのマニュアル作成 作業プロセスを記録したマニュアルの作成は、多くのチームが苦労する課題です。 しかし、リモートチームの場合には、自分が担当した作業を他のチームに引き継いだり、他のチームから引き継いだりする際に、作業プロセスを記録したマニュアルが必須です。ドキュメントが不十分であったりコミュニケーションが不足していれば、チームが作業を進めるのは難しいでしょう。マニュアルの作成は退屈で時間がかかるのに加えて効果も見えにくいため、担当者には面倒な作業と思われがちです。 4.ツールの不備 リモートチームと一緒に仕事をするためには、さまざまなツールを活用すべきです。テレビ会議や電話、メール、コラボレーション・ツールなどは、リモートチームとのコミュニケーションと作業プロセスを容易にしてくれます。…

アジャイルとは、プロジェクト管理とソフトウェア開発の一手法で、大規模で複雑なプロジェクトを管理しやすい小さなかたまりに分解するというインタラクティブなアプローチです。 多くのソフトウェア開発において、プロジェクトの速度を上げるためにアジャイルの手法が使われています。 “スクラム”と“カンバン”は、アジャイルでよく使用される一般的なフレームワークです。以下でその違いを見てみましょう。 スクラム(Scrum) チームにおける役割: プロダクトオーナー、スクラムマスター、チームメンバーで構成 時間管理: スプリントと呼ばれる事前に決められた時間枠（通常2〜4週間）で運営 タスクボード: タスクボードの列にはワークフローの期間を反映するような項目を記載(例：概要、開始前、進行中、完了など) 適したプロジェクト: スクラムは、複雑な作業を開発、提供、および維持するためのフレームワークです。 スクラムは、複雑な作業を小さな、管理可能なタスクに分解します。タスクは、スプリントと呼ばれる所定の時間枠の間に、必要な能力をひととおり備えたチームによって実施、完了されます。 各スプリントの期間は通常2〜4週間です。スクラムを採用すると、開発チームは突然の変更に対しより機敏に対応できるようになるため、要件が急に変わる可能性のあるプロジェクトに適しています。 カンバン(Kanban) チームにおける役割: 各メンバーに固定の役割を割り当てない 時間管理: 時間枠を設定せず、タスクの優先順に実施する タスクボード: タスクボードの列にはワークフローの状況を示すラベルを付け、併せて、同時に処理可能なタスクの最大数も表示する。 適したプロジェクト: カンバンは、現在のプロセスを徐々に変更していくことでも適用可能なプロジェクト管理ツールです。 スクラムと同様に、カンバンは複雑なプロジェクトを管理可能なタスクに分解し、カンバンボードを使用してプロジェクトの進捗状況を可視化します。 スクラムが特定の作業量を達成するために投入される時間を制限するのに対し、カンバンはワークフロー内のセグメント毎に投入される作業量を制限します。 あなたのチームでプロセスの視覚化と最適化が必要な場合は、カンバン手法が適しています。 スクラムとカンバンのどちらを採用するか スクラムもカンバンも、さまざまなプロセスとテクニックを管理するためのフレームワークです。 どちらのフレームワークでも、プロセスを視覚化して効率を上げることができますし、どちらか１つの方法しか使えないという訳ではありません。実際、両者を合わせたスクラムバン(ScrumBan) というフレームワークもあります。また、プロジェクトの成功のために必要な原理原則は他にもあります。まず最初にあなたの開発プロジェクトにおけるビジネス要件をよく理解した上で、プロジェクトに適したアジャイル方法論を選んでください。