本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Japan Azure User Group 9周年イベントに参加してきました!（その1）#jazug」を再編集したものです。
皆様こんにちは!!FIXERアルバイトの門下です。
今回のブログ記事は、先日開催されたJapan Azure User Group(JAZUG)の9周年記念イベント参加レポートです。JAZUGが発足してから9年も経つんですね…(9年前の私は小学生でした)
AIに飛びつく前に!!Azureサーバーレスで行う情報のスクリーニング(の一案)
AIに飛びつく前に!!Azureサーバーレスで行う情報のスクリーニング(の一案)
最初のセッションは、松村亮輔さん(@rxpaki)のサーバーレスのお話でした。インターネット上の情報を自動で収集・選別してくれるシステムをAzure Functionsで開発されたとのことです。
そもそもサーバーレスとは、開発者がサーバーを意識する必要がないと言う意味で、サーバーが存在しないわけではありません(キャッシュレスのレスと同じ意味合いです)また、サーバーレスというとFunction as a Service(FaaS)をイメージされる方がいらっしゃるかと思いますが、サーバーレス≠FaaSで、以下の画像のマニフェストに合致しているものがサーバーレスと呼ばれているようです。
サーバーレスのマニフェスト(登壇資料18ページより)
Azureにはサーバーレスのサービスがたくさんあり、これらを組み合わせることで、アプリケーションを効率的に開発・運用することが可能になります。
また、収集した情報のスクリーニング(取捨選択)の際には、なるべく判断を自動でできるよう、「仮に不要な情報であっても、判断に迷った場合は必要な情報と判定する」ようにロジックを作成したとのことです。
アプリケーションのアーキテクチャーとしては、Azure Functionsの一機能であるDurable Functionsを使用し、開発を行ったとのことです。Durable FunctionsはステートフルなFaaSを作成することが可能なサービスで、過去のAzure Functionsでは実装が難しかった様々な機能を用意に実装できるという特徴があります。また、アプリケーションのCI/CDにはAzure DevOpsを使用し、効率的・継続的なデプロイを実現されていました。
今後の機能追加案としては、除外リストに蓄積されたデータを用いて、AIによる自動判別機能を実装することなどを考えておられるようでした。
Azureサーバーレスで行う情報のスクリーニング from ryosuke matsumura
Azure DevOps × スクラム で実現するプロダクト開発のポイント
２つ目のセッションは関満徳さん(@fullvirtue)のAzure DevOpsとスクラムのお話でした。
まず、Azure DevOpsは「システムの開発と運用を行う上で必要となるサービスが集約されたソフトウエア開発チーム向けのチーム開発支援プラットフォーム」で、以下のようなサービスが利用できます。
・Azure Boards(タスク管理システム「カンバン」を提供するサービス)
・Azure Repos(ソースコードバージョン管理サービス)
・Azure Pipelines(CI/CDサービス)
・Azure Artifacts(ライブラリ・パッケージのホスティングサービス)
・Azure Test Plans(探索的テストを実行するサービス)
このように、各サービス名は複数形になっていることが特徴です。
続いてはスクラムの解説でした。2011年頃に日本で普及したスクラムは、もともと開発の現場のみで行われており、プロダクトオーナーが一人で頑張ってバックログ化を実施していたため、結果としてうまくいきませんでした。2019年時点でのスクラムは、チームがバックログ化、プロダクトオーナーは方針を意思決定という形に変わってきているようです。また、開発のすべてをスクラムで行うのではなく、プロダクション品質においてのみスクラムを実施することで、試行錯誤が容易に行えるようにすることが可能です。そしてAzure DevOpsを活用することで、このような開発手法を簡単に実現することが可能になります。
次はプロダクト開発の解説でした。現在は情報社会の次の段階(Society 5.0)への変革の段階にあります。このSociety 5.0はMicrosoftが提供している様々なサービスを活用することで実現可能な社会です。そもそも、これまでのビジネスモデルでは登場するすべての人物が１箇所に集まらないと価値の提供ができませんでした。例えばフィットネスクラブでは、インストラクターと同じ場所にいないと指導を受けることができません。これからのビジネスモデルでは、遠隔での価値の提供が可能になります。再びフィットネスクラブを例に取ると、KinectやHoloLensを活用することで、家にいながら指導を受けることができるようになるかもしれません。このように、今後は制約からの開放を実現していく必要があります。
また、四半期、中期、長期それぞれで目標を立て、プロダクトをマネジメントしていく必要があります。ここでいう目標はXM(Experience Management)の観点から見たプロダクトの価値を最も表している、測定可能な数値の目標です。(動画投稿サイトなら総視聴時間など)
最後は、「エピック、フィーチャー、ユーザーストーリー、タスクの各項目を、誰が、何を、どの粒度で書けばよいのかわからない」という疑問に対する回答でした。これらの各項目は、以下の画像のように書くのが良いようです。
このように、Azure DevOps x スクラムでプロダクト開発を行う際には、上記のポイントに気をつけながらすすめるのがベストプラクティスなようです。
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug from 満徳 関
だいぶ長くなってしまったので、一旦ここで区切ろうと思います。
