Avanade tech talk #1イベントレポート【後編】——スクラム開発で気をつけるべきポイント

イベント
2019年7月1日(月)、アバナード株式会社による「Scrum on Azure DevOps - Avanade tech talk #1」が開催されました。 「Azure DevOps」と「スクラム」をテーマに、アバナード開発部隊の取り組み事例と「明日から現場で使えるティップスを、実際のデモと共にご紹介した今回のイベント。 本レポートでは、イベント後半のAzure DevOpsを利用したスクラム開発のデモ実演で伝えられた、現場で気をつけるべきポイントをお届けします。
Avanade tech talk #1イベントレポート【後編】——スクラム開発で気をつけるべきポイント

前編に引き続き、髙橋氏にDevOpsについて解説いただきます。

▲髙橋直樹(たかはしなおき)/テクニカルコンサルタント テクニカルアーキテクト アジャイルコーチ

アジャイルとDevOps

後半のデモ実演に入る前に、アジャイルとDevOpsについて簡単にご説明します。

まず、DevOpsとアジャイルは同義語ではないので注意してください。

お客様やエンドユーザー側と開発の間に発生する認識の隔たりを埋めるものがアジャイルで、実際の運用側と開発側の認識の隔たりを埋めるものがDevOpsです。

では、DevOpsとは具体的に何か?

DevOpsとは、組織・チーム・個人のゴールを、継続的かつ効果的に実現し続けるための文化やカイゼン活動のことを言います。だから、チームや組織が変わっていくことが重要です。

DevOpsが成功するためには3つの条件があります。

①人・組織文化
②プロセスコラボレーション
③技術・ツール・アーキテクチャ

何度も申し上げるようですが、失敗を非難しない文化が大事です。

そして、これを実現していくためには、3つのフローがあります。

DevOpsを実現する3つのフロー

3つというのが、

①高速フロー
②フィードバック
③継続的な実験・学習

です。

①では、アーキテクチャと技術プラクティスを活用し、開発チーム⇒運用チームへの高速フローを実現します。
②では、運用チーム⇒開発チームへ、高速で継続的なフィードバックを行います。
③では、アクシデントや失敗を糧とし、組織的に継続的に実験・学習していく文化を醸成していきます。

Azure DevOpsとは?

Azure DevOpsを利用したスクラム開発のデモに移る前に、Azure DevOpsについて少し紹介させていただきます。

AzureDevopsとは開発チームをサポートするためのツールで、タスク管理やリポジトリ、CI/CDパイプラインなど、様々な機能を有しています。

実際に、Azure DevOpsはDevOpsの全てをサポートしています。

この表では書かれていませんが、実際に開発を進めていく上ではコミュニケーションツールが必要になりますから、利用者の多いslackや最近流行りだしているMicrosoftのTeamsなどをつなぐことができます。


Azure DevOpsは多数の開発言語にも対応でき、様々な外部ソフトとも連携することができるのも大きな特徴です。

一通りの解説が終わったところで、ここからデモ実演に。Azure DevOpsを利用したスクラム開発の様子を再現しながら、スクラム開発におけるポイントを教えていただきました。

引き続き髙橋氏に解説いただきながら、ここからはアバナード開発部隊の関野 学氏も加わります。

▲関野 学(せきのまなぶ)/グループマネージャー アバナードでAzure、IoTといったらこの人!

さてここからは、我々が誇るスーパーハッカー関野も加えながら、デモをやっていこうと思います。

役割としては、私髙橋がPO、開発者を関野、スクラムマスターとステークホルダー役も私髙橋が行います。



これはあくまでもデモですのでこのような体制で行いますが、兼務はやめたほうがいいです。なぜなら、フレームワークでは禁止はしていないものの、兼務して中に入ってしまうことで当事者意識が芽生えてしまい、均一性を保てなくなってしまうからです。

集中の面からみても、他のことに気を取られてしまって、本来やるべきことにフォーカスできないなんてことも発生します。

ですから、現場ではプロジェクトを成功させるためにも兼務はしないこと。きちんと役割を独立させることが、大事なポイントになってきます。

Sprint Planning

まずはスプリントの計画をしていく、「Sprint Planning」から始めていきます。

これは全体が4週間の場合に8時間で行うので、スプリントが2週間ならば、最大4時間で行います。ただし「最大で」なので、別にそんなに必要ないという方は減らしても問題ありません。

製品仕様など、関わるプロダクトバックログの中から実際にこのスプリントでは何をするのかを検討して、バックログを作成していきます。


▲デモ:プロダクトバックログ一覧画面(上から優先度の高いものから順に並んでいる状態)

作成する上では、チームの生産性を加味する必要があります。チームの生産性というのは、例えば人数や休みなどで、優先度の高いものから選んでいきます。実際にやるべきタスクを定義していく時に注意しなければいけないのが、スプリント全体の長さを4週間とした時に、休暇等をきちんと差し引いて実働を見積もること。意外とこれができていない現場が多いので、注意したい点です。

そして、見積もりを決める時にも、重要なポイントがあります。


▲デモ:プラグインを利用した見積り画面

見積もりを決める時は、

①見積もりに関わる全員が、一斉に意見を表明する
②全員で見積もり数値を合わせる作業して合意する

ことが重要です。

今回のデモ画面では、フィボナッチ数列を使ったツールで見積もりを決めていきます。ここでは、見積もり決定に関わる全員が一斉に意見を表明する必要があります。なぜなら、一斉に表明することで、意見にバイアスがかからなくなるからです。

メンバーが複数人いると、発言権の強い人やスキルの高い人の意見が採用されがちです。スキルが高い人は1日でできるかもしれませんが、そうではない人は3日間かかるかもしれない。チームで仕事をしていくので、チーム内のギャップを埋め、みんなで同意をした上で仕事ができるようにすることが重要です。

議論が割れた時には、一番小さい数値を選んだ人と一番大きい数値を選んだ人に、意見を述べてもらいます。それぞれの考えをぶつけ議論することで互いの考えを理解していき、一致するまで続けます。


▲デモ:タスクをブレイクダウンしたタスクボード画面

見積りを終えてスプリントでやるものが決まりましたが、プロダクトバックログは粒度が大きいままなので、まだ作業レベルには落とし込めていません。プロダクトバックログを実現するためのタスクを、タスクボード上で作っていきます。

ここからは、日々の作業に移ります。

Daily Scrum

Daily Scrumは日々行います。毎日15分、実際のプロジェクト状況を共有していきます。

共有する内容としては、一般的には「昨日何やりましたか?」「今日は何やりましたか?」「こんなこと困っています」ということです。

しかしながら、毎日のことなのでマンネリ化する可能性もあります。でもデイリースクラムは、会話の場を設けること自体がとても重要なので欠かしてはいけません。チームには色々な人がいるので、日々の業務の中では相談のハードルが高いと感じてしまう人にとっては、相談できる場があるというだけで安心材料になってきます。

もちろん15分では収まらない内容も出てきますので、その場合には別の場を設けるようにしましょう。

Sprint Review

Workの期間を経て実際にモノができあがったら、Sprint Reviewをします。

ここに参加するのは、スクラムのチームと重要なステークホルダーです。ステークホルダーはルール上参加にはなっていないのですが、参加してもらったほうがいいです。そして、POが主導でお披露目をし、開発チームがモノを動かしていきます。

ここでの目的は、良かった点や悪かった点をステークホルダーからフィードバックをもらうことです。場合によっては、フィードバックから新たなプロダクトバックログが生まれることがあります。

間違えてはいけないのが、この場は進捗会議ではないという点で、プロダクトがいいのか悪いのかだけを議論します。進捗が遅い、プロダクトが思っていたより出来上がっていないなどという話は、ここでは行いません。その点には注意して臨みましょう。

Sprint Retrospective

Sprint Retrospectiveは、スプリントにおける最後の段階です。

ここまでスプリントをやってきた中で、人間関係や自分たちのプロセスなどについて様々な学びがあったはずです。これらに対して、次はどう改善していこうか、もっと良くするにはどうしたらいいだろうかなど、スプリント全体を振り返るための時間です。ここで挙がった改善案は最低でもひとつは次のスプリントバックログに入れましょう。

先ほどの Sprint Review はプロダクトに対してのものでしたが、Sprint Retrospective はあくまで自分たちのプロセスについてのみ話し合います。ですから、モノについての議論はしません。

今回のデモでは、一般的によくあるKPT(Keep、Problem、Try)を使っていますが、私はこの中でも「Keep(Good)」を重視しています。実行する中でよかったことは、他の人にとってもよかったことになるはずなので、それらをどんどん共有して、今後のスプリントをよりよくしていくことに繋がっていきます。

見積もりの時と同じようにみんなで一斉に実施すると、より意見が出やすくなり議論が活発になります。

これにて、デモ実演は終了。

今回のイベント参加者には、アーキテクチャに関わる方が多くいらっしゃいました。そこで急遽、髙橋さんがアーキテクチャについての講義も追加してくださいました。

アーキテクチャはいつ決めるべきか?



アーキテクチャはだいたい最初に決めるものなので、通称Sprint Zeroという準備期間で決めることが多いと思いますが、私はあまりおすすめしていません。

アーキテクチャはなるべく遅く決めるのがベターだと言われていますが、ベストとは言っていません。アーキテクチャは決めるのが大変ですが、決まらなければ始まらないので、いつまでもやっていられません。だからベターなのです。

そもそも不確実性が高いものについて取り組んでいるので、最初から予想できないのが実際のところです。この中で生まれるべくして生まれたものがベストではないでしょうか。

Sprint Zeroとは何か?

Sprint Zeroはスクラムの公式イベントではないのですが重要です。

ここでは、我々は何のために存在しているのか?何のためにやっているのか?何をもって完了(Definitionof Done: DoD)するのか?というところを定義していきます。

みんなで最初に定義することがとても大事なんです。定義をしないと、品質にすごくバラつきが出てしまいます。

また、働くための環境についての整備もここで行いますし、チームビルディングのためのエクササイズなども行います。

ちなみに、ここでの内容もキリがないのでタイムボックスにしたほうがいいです。

そして、内容がある程度固まったのであれば、実際にスクラムを始めてしまって、スプリントを走らせながら改善を続けていくほうがいい。結果的にもスピードも早くなります。

水平ではなく垂直で開発する

やはり大きなアーキテクチャには時間がかかります。

データを作って、アクセスして、業務ロジック書いて、画面に表示してって…なんてやってたら、最初の機能がリリースされるのはいつになるかわかりません。これまでの開発でも、だいたい誰にもコールされない関数があったと思います。

アジャイルでは、水平に割っていくアーキテクチャではなく、垂直に割っていくのです。これを「スライス」という言い方をします。実際に必要な機能に応じて縦に作っていきます。下からビルドアップするのではなく、一気に作ってしまうというやり方です。

Microsevice Architectureは現実解

マイクロサービスは、単なる流行りで生まれたわけではないのです。公式見解ではありませんが、アジャイルにやっていくために結果的に生まれたものだと思います。

概念自体は何十年も前からあるものの、近年のインフラストラクチャの進歩によって、そして色々な便利なものが出てきたことによって、簡単に実現できるようになった。これが、マイクロサービスアーキテクチャが流行ってきた背景なのかなと、個人的には思っています。

本日のまとめ

まず、アジャイルは方法論ではなく「文化や考え方」というお話をさせていただきました。

次に、DevOpsには3つの要素である「人・組織文化」「プロセス・コラボレーション」「技術・ツール・アーキテクチャ」が必要だとお話ししました。これらのどれがかけてもダメです。

デモ実演でご覧いただいたように、Azure DevOps を使うと、すぐにスクラムが始められることをお分かりいただけたと思います。

最後お話しさせていただいたのは、マイクロサービスアーキテクチャは単なるバズワードではなく、現実解だということ。ただし、ベストではなく今のところベターなんです。これについては開発者である私たちや、今日ご参加くださったみなさんが一緒になって、より良い方式を模索していく必要があり、それこそがアジャイルの本質なのではないかと思っています。ですから、今後も一緒により良いものを発信していけたらと思っています。

そして、アバナードはマイクロソフトソリューションのリーディングカンパニーです。ぜひこれだけは覚えて帰ってください(笑)本日はありがとうございました。

参加者懇親会

イベントの最後には、豪華ケータリングとお酒を楽しみながらの懇親会。

参加者の方々は、登壇者を囲って質問タイム。質疑応答の時間ではできなかった、より具体的な質問が飛び交っていました。

イベント後のアンケート回答で、参加者の満足度が非常に高かった今回のイベント。早速、第2回の実施も決定しました!

第1回目は、50人の枠に対して2倍近くの参加希望があった非常に人気の高いイベントです。ご興味のある方はお早めにご応募ください!

▼Azure VMとPowerShellで実現する効率的なシステム構築ノウハウ大公開。デモンストレーションで詳しく解説! -Avanade tech talk #2-
https://techplay.jp/event/738799

関連するイベント

おすすめのコラム

アビームコンサルティングが明かす「ビジネス改革をアジャイル活用で失敗しないための方法」とは?

イベント

アビームコンサルティング(以下、アビーム)ではアジャイルを正しく理解するためのイベント「アジャイルマニフェスト...

アビームコンサルティングが明かす「ビジネス改革をアジャイル活用で失敗しないための方法」とは?

システムに筋力トレーニングをさせるトレーナー!?カオスエンジニアって何者?

トレンド

どうも、totokoです。 SNSやWEBサービスを始め、今はとにかくなんでもネットに繋がっている時代です。 そして同...

システムに筋力トレーニングをさせるトレーナー!?カオスエンジニアって何者?