#1」が開催されました。DevOps」と「スクラム」をテーマに、アバナード開発部隊の取り組み事例と「明日から現場で使えるティップスを、実際のデモと共にご紹介した今回のイベント。DevOpsを利用したスクラム開発のデモ実演で伝えられた、現場で気をつけるべきポイントをお届けします。スクラムアバナード前編に引き続き、髙橋氏にDevOpsについて解説いただきます。アジャイルコーチアジャイルとDevOps後半のデモ実演に入る前に、アジャイルとDevOpsについて簡単にご説明します。DevOpsとアジャイルは同義語ではないので注意してください。お客様やエンドユーザー側と開発の間に発生する認識の隔たりを埋めるものがアジャイルで、実際の運用側と開発側の認識の隔たりを埋めるものがDevOpsです。DevOpsとは具体的に何か?DevOpsとは、組織・チーム・個人のゴールを、継続的かつ効果的に実現し続けるための文化やカイゼン活動のことを言います。チームや組織が変わっていくことが重要です。DevOpsが成功するためには3つの条件があります。1人・組織文化2プロセスコラボレーション3技術・ツール・アーキテクチャ何度も申し上げるようですが、失敗を非難しない文化が大事です。これを実現していくためには、3つのフローがあります。DevOpsを実現する3つのフロー3つというのが、1高速フロー2フィードバック3継続的な実験・学習です。1では、アーキテクチャと技術プラクティスを活用し、開発チーム⇒運用チームへの高速フローを実現します。2では、運用チーム⇒開発チームへ、高速で継続的なフィードバックを行います。3では、アクシデントや失敗を糧とし、組織的に継続的に実験・学習していく文化を醸成していきます。DevOpsについて少し紹介させていただきます。AzureDevopsとは開発チームをサポートするためのツールで、タスク管理やリポジトリ、CI/CDパイプラインなど、様々な機能を有しています。DevOpsはDevOpsの全てをサポートしています。この表では書かれていませんが、実際に開発を進めていく上ではコミュニケーションツールが必要になりますから、利用者の多いslackや最近流行りだしているMicrosoftのTeamsなどをつなぐことができます。DevOpsは多数の開発言語にも対応でき、様々な外部ソフトとも連携することができるのも大きな特徴です。一通りの解説が終わったところで、ここからデモ実演に。DevOpsを利用したスクラム開発の様子を再現しながら、スクラム開発におけるポイントを教えていただきました。アバナードでAzure、IoTといったらこの人!さてここからは、我々が誇るスーパーハッカー関野も加えながら、デモをやっていこうと思います。役割としては、私髙橋がPO、開発者を関野、スクラムマスターとステークホルダー役も私髙橋が行います。これはあくまでもデモですのでこのような体制で行いますが、兼務はやめたほうがいいです。フレームワークでは禁止はしていないものの、兼務して中に入ってしまうことで当事者意識が芽生えてしまい、均一性を保てなくなってしまうからです。集中の面からみても、他のことに気を取られてしまって、本来やるべきことにフォーカスできないなんてことも発生します。現場ではプロジェクトを成功させるためにも兼務はしないこと。役割を独立させることが、大事なポイントになってきます。Planning」から始めていきます。これは全体が4週間の場合に8時間で行うので、スプリントが2週間ならば、最大4時間で行います。「最大で」なので、別にそんなに必要ないという方は減らしても問題ありません。製品仕様など、関わるプロダクトバックログの中から実際にこのスプリントでは何をするのかを検討して、バックログを作成していきます。▲デモ:プロダクトバックログ一覧画面(上から優先度の高いものから順に並んでいる状態)作成する上では、チームの生産性を加味する必要があります。チームの生産性というのは、例えば人数や休みなどで、優先度の高いものから選んでいきます。実際にやるべきタスクを定義していく時に注意しなければいけないのが、スプリント全体の長さを4週間とした時に、休暇等をきちんと差し引いて実働を見積もること。意外とこれができていない現場が多いので、注意したい点です。見積もりを決める時にも、重要なポイントがあります。見積もりを決める時は、1見積もりに関わる全員が、一斉に意見を表明する2全員で見積もり数値を合わせる作業して合意することが重要です。今回のデモ画面では、フィボナッチ数列を使ったツールで見積もりを決めていきます。ここでは、見積もり決定に関わる全員が一斉に意見を表明する必要があります。一斉に表明することで、意見にバイアスがかからなくなるからです。メンバーが複数人いると、発言権の強い人やスキルの高い人の意見が採用されがちです。スキルが高い人は1日でできるかもしれませんが、そうではない人は3日間かかるかもしれない。チームで仕事をしていくので、チーム内のギャップを埋め、みんなで同意をした上で仕事ができるようにすることが重要です。議論が割れた時には、一番小さい数値を選んだ人と一番大きい数値を選んだ人に、意見を述べてもらいます。それぞれの考えをぶつけ議論することで互いの考えを理解していき、一致するまで続けます。見積りを終えてスプリントでやるものが決まりましたが、プロダクトバックログは粒度が大きいままなので、まだ作業レベルには落とし込めていません。プロダクトバックログを実現するためのタスクを、タスクボード上で作っていきます。ここからは、日々の作業に移ります。Scrumは日々行います。毎日15分、実際のプロジェクト状況を共有していきます。共有する内容としては、一般的には「昨日何やりましたか?」「今日は何やりましたか?」「こんなこと困っています」ということです。毎日のことなのでマンネリ化する可能性もあります。デイリースクラムは、会話の場を設けること自体がとても重要なので欠かしてはいけません。チームには色々な人がいるので、日々の業務の中では相談のハードルが高いと感じてしまう人にとっては、相談できる場があるというだけで安心材料になってきます。15分では収まらない内容も出てきますので、その場合には別の場を設けるようにしましょう。Reviewをします。ここに参加するのは、スクラムのチームと重要なステークホルダーです。ステークホルダーはルール上参加にはなっていないのですが、参加してもらったほうがいいです。POが主導でお披露目をし、開発チームがモノを動かしていきます。ここでの目的は、良かった点や悪かった点をステークホルダーからフィードバックをもらうことです。場合によっては、フィードバックから新たなプロダクトバックログが生まれることがあります。間違えてはいけないのが、この場は進捗会議ではないという点で、プロダクトがいいのか悪いのかだけを議論します。進捗が遅い、プロダクトが思っていたより出来上がっていないなどという話は、ここでは行いません。その点には注意して臨みましょう。Retrospectiveは、スプリントにおける最後の段階です。ここまでスプリントをやってきた中で、人間関係や自分たちのプロセスなどについて様々な学びがあったはずです。これらに対して、次はどう改善していこうか、もっと良くするにはどうしたらいいだろうかなど、スプリント全体を振り返るための時間です。ここで挙がった改善案は最低でもひとつは次のスプリントバックログに入れましょう。自分たちのプロセスについてのみ話し合います。モノについての議論はしません。今回のデモでは、一般的によくあるKPT(Keep、Problem、Try)を使っていますが、私はこの中でも「Keep(Good)」を重視しています。実行する中でよかったことは、他の人にとってもよかったことになるはずなので、それらをどんどん共有して、今後のスプリントをよりよくしていくことに繋がっていきます。見積もりの時と同じようにみんなで一斉に実施すると、より意見が出やすくなり議論が活発になります。これにて、デモ実演は終了。今回のイベント参加者には、アーキテクチャに関わる方が多くいらっしゃいました。そこで急遽、髙橋さんがアーキテクチャについての講義も追加してくださいました。Zeroという準備期間で決めることが多いと思いますが、私はあまりおすすめしていません。アーキテクチャはなるべく遅く決めるのがベターだと言われていますが、ベストとは言っていません。アーキテクチャは決めるのが大変ですが、決まらなければ始まらないので、いつまでもやっていられません。そもそも不確実性が高いものについて取り組んでいるので、最初から予想できないのが実際のところです。この中で生まれるべくして生まれたものがベストではないでしょうか。Zeroはスクラムの公式イベントではないのですが重要です。DoD)するのか?というところを定義していきます。みんなで最初に定義することがとても大事なんです。定義をしないと、品質にすごくバラつきが出てしまいます。働くための環境についての整備もここで行いますし、チームビルディングのためのエクササイズなども行います。ちなみに、ここでの内容もキリがないのでタイムボックスにしたほうがいいです。内容がある程度固まったのであれば、実際にスクラムを始めてしまって、スプリントを走らせながら改善を続けていくほうがいい。結果的にもスピードも早くなります。水平ではなく垂直で開発するやはり大きなアーキテクチャには時間がかかります。データを作って、アクセスして、業務ロジック書いて、画面に表示してって...なんてやってたら、最初の機能がリリースされるのはいつになるかわかりません。これまでの開発でも、だいたい誰にもコールされない関数があったと思います。アジャイルでは、水平に割っていくアーキテクチャではなく、垂直に割っていくのです。これを「スライス」という言い方をします。実際に必要な機能に応じて縦に作っていきます。下からビルドアップするのではなく、一気に作ってしまうというやり方です。Architectureは現実解マイクロサービスは、単なる流行りで生まれたわけではないのです。公式見解ではありませんが、アジャイルにやっていくために結果的に生まれたものだと思います。概念自体は何十年も前からあるものの、近年のインフラストラクチャの進歩によって、そして色々な便利なものが出てきたことによって、簡単に実現できるようになった。これが、マイクロサービスアーキテクチャが流行ってきた背景なのかなと、個人的には思っています。本日のまとめまず、アジャイルは方法論ではなく「文化や考え方」というお話をさせていただきました。プロセス・コラボレーション」「技術・ツール・アーキテクチャ」が必要だとお話ししました。これらのどれがかけてもダメです。使うと、すぐにスクラムが始められることをお分かりいただけたと思います。最後お話しさせていただいたのは、マイクロサービスアーキテクチャは単なるバズワードではなく、現実解だということ。ベストではなく今のところベターなんです。これについては開発者である私たちや、今日ご参加くださったみなさんが一緒になって、より良い方式を模索していく必要があり、それこそがアジャイルの本質なのではないかと思っています。今後も一緒により良いものを発信していけたらと思っています。アバナードはマイクロソフトソリューションのリーディングカンパニーです。これだけは覚えて帰ってください(笑)本日はありがとうございました。参加者懇親会イベントの最後には、豪華ケータリングとお酒を楽しみながらの懇親会。参加者の方々は、登壇者を囲って質問タイム。質疑応答の時間ではできなかった、より具体的な質問が飛び交っていました。イベント後のアンケート回答で、参加者の満足度が非常に高かった今回のイベント。第2回の実施も決定しました!第1回目は、50人の枠に対して2倍近くの参加希望があった非常に人気の高いイベントです。VMとPowerShellで実現する効率的なシステム構築ノウハウ大公開。2018/06/26どうも、totokoです。SNSやWEBサービスを始め、今はとにかくなんでもネットに繋がっている時代です。vol.13データ分析をする業種でお仕事をする人を改めて解説してみる。