よしたく blog

ほぼ週刊で記事を書いています

アジャイルなチームをつくる ふりかえりガイドブックを読んだ

本

以前、「スクラム」をテーマにしている SCRUM BOOT CAMP THE BOOK を読んだところ、ふりかえりにあたる「レトルスペクティブ」に対する言及が少なかったので、この本を手にとった。

yoshitaku-jp.hatenablog.com

内容

これから始める人を対象にしていることが SCRUM BOOT CAMP THE BOOK と同じで、優しく手ほどきをするように書かれていた。 さらに SCRUM BOOT CAMP THE BOOK で少なかった「レトロスペクティブ」を補う目的で書かれたのか、本の表紙から中身まで似たような構成で作られていた。 例えば、内容がストーリー仕立てで書いてあったりマンガも多く差し込まれていた。 続編のような形で本作りが似ていたため、読み手としてはスムーズに内容に入っていけた気がする。

内容としては 4 部構成になっていて、「基礎編」「実践編」「手法編」「TIPS 編」となっている。 SCRUM BOOT CAMP THE BOOK と違う部分で言えば、基礎編実践編でのストーリーは本の半分ぐらいで、手法編で「ふりかえりの型 手法」が多く載っていた。

個人的に良かったところ

手法がまとめられていた

このあたりはよく耳にする KPT や Fun/Done/Learn をはじめ、耳にしたことがないようなものも含めて 20 個挙げられていた。 個別での形で手法は名前をよく耳にしていたが、他のものと対比できるような形でまとめてあるのはありがたいと感じた。 他にもふりかえりで使うタイミングなども明記されているのが、自分たちの現在地と照らし合わせて手法を選べるような気がしてよかった。

行動と気持ちの振り返り

ふりかえりというと実際に行動したことを中心におこないそうだが、気持ちの面もふりかえろうと書いてあったのが良かった。人間は感情な生き物でもあるので、この時この場面でどう感じたかを自分で認知し周りと共有することもとても大切だと思った。

すべての問題を解決する銀の弾丸ではない

ふりかえりをはじめるときには「ふりかえりが問題を全部解決してくれる」と過度な期待を抱きがちです。問題を明らかにしたり、次のアクションをみんなで考えたりすることはできますが、アクションを実行して問題を解決するのはあくまでチーム自身の力によるものです。

P62 より引用

この言葉は自分の中に気づきを与えてくれた。

例えば、なにか一区切りついたときに「ふりかえりをしましょう」と言う誰かの発言から、一連の流れをふりかえることがある。 しかし、せっかく長い時間賭けてふりかえった後に、そのふりかえりを活かせていないことが多かった。 その結果、自分の中でふりかえりは「やる人たちの満足感を得るためだけのものになっていて、正直やる意味はないんじゃないか」という思いになっていった。

ここでわかったことは、ふりかえりの責務は問題の可視化であったり、次のアクションを決める場を提供するだけということだった。 あくまでもやるのは自分達自身だし、またそのための仕組み作りも大切であることを得ることができた。

まとめ

ふりかえりガイドブックを読んだ。 チームとしてふりかえりの場を設けることは現時点でなさそうだが、個人としてのふりかえりはできるので少しずつ実践していく気持ちになれた。 ふりかえりの真価はふりかえり以外の部分での変化を促進するという言葉もあり、ふりかえりの時間を設けて日々の生活をアップデートしていこうと気持ちを新たにできた。

さっそくふりかえりの良い作用が出てきていて、タスクツールを使ってタスクを管理しようとしていたが、アプリを起動しないと見ない現状をふりかえってみた。 いつもその問題点に気が付かず、色々なアプリを巡っていたが、今回は問題点を書き出して対応した。 今は常に見えるものとして小さいホワイトボードを購入し卓上で管理している。

ITエンジニア向け図書館読書法

雑記

以前「メルカリ読書法」が話題になったが、自分には合わなかったので図書館にアレンジして実践してみた。 メルカリ読書法の詳細は下記に書いてある。

note.com

要するに実践していくと、メルカリに出品することで本を読み終えるプレッシャーをかけ、積ん読の解消ができるような感じである。

合わなかった点

読む本の種類

自分が読む本が偏っていて「IT系の技術書が多い」というのがある。 このブログを読んでいるメインの人にも共通すると思う。

本の内容として難しかったりもするし、手を動かして理解をする場合もある。 そうなったときにメルカリ読書法だと、出品直後に売れたりすると明らかに間に合わない。 逆に読み終わりそうになってから出品する方針とすると、途中で読むのをやめてしまい結局積んでしまって、そもそもメルカリ読書法のメリットを得ることができない。

メルカリ読書法はビジネス書だったり、自己啓発系があっていると感じたので、こちらでは実践していこうと思う。

技術書は高い

IT系の技術書は最初に手を出す金額が高い問題がある。 ビジネス書や自己啓発系は1500円前後で手に入るし、過去に有名になった本は文庫化されていたりしてより安くなっている。 一方、技術書は3000円あたりが普通だし5000円なんてものもある。

値段のあたりは仕方がないが、読み終わったら売ればいい思考がありつつも、初手に出す値段が高いために失敗したくない思いが働いて、そもそも手を出さないという悪循環になってしまった。

図書館に変えてよかった点

図書館に変えてよかった点を上げていくが、あくまでも自分が住んでいる市区町村の話であり、自分が住んでいる場所のことは調べて対応してほしい。

借りれる期間が決まっている

これはメルカリ読書法の「売れるまでに読み切る」をうまく置き換えられたと思う。 自分が住んでいる場所では通常2週間借りられるので2週間の間に読み終えればいいという思考になれた。 終わりが決まっているので分量が多いものもペースを作って読むことができた。 場所によっては借りる期間の延長もできるので活用してもらうと良さそう。

費用がかからない

費用がかからないので少し値段が高い本も気軽に読むことができた。 また、近い図書館に本がなくても、同じ市区町村内、または近隣の市区町村から取り寄せてくれたりする。

自分の場合は

  • 同じ市区町村内
    • 2,3日前後
  • 近隣の市区町村
    • 2週間前後

で、本が最寄りの図書館に届いた。 急ぎのものは買うしか無いが、気になっていた系なら頼んでおいてまったり待つのが良さそう。

費用がかからないと書いたが、手元においておきたいと思ったものは改めて購入するようにしている。 このあたりは自分の気持ちの面もあるので、無理に強要するものではない。 少し後ろめたい人は、感想ツイートだったり、ブログなどでアウトプットすると良さそう。

まとめ

在宅で家にいることが多くなった人にはとても有効だと思うのでぜひやってみてほしい。

Dockerにssh公開鍵認証でログインする

Docker

Dockerでsshでログインしようとしたら思ったよりハマったのでメモをしておく。

まずはDockerでdebianを起動する。

docker run --name ssh_sample -it -p 127.0.0.1:2022:2022 debian:stable

設定ファイルなど必要なものをインストールする

apt -y update 
apt install -y sudo ssh vim
vim /etc/ssh/sshd_config
  • Port
    • 2022
  • PasswordAuthentication
    • yes
  • PermitRootLogin yes
    • yes

編集が終わったらservice ssh restartでsshを再起動する。

ローカルPCに戻って、鍵を作成する。 さらに、鍵をDockerの中へ送る。

ssh-keygen -f ssh_sample
ssh-copy-id -p 2022 -i ~/.ssh/ssh_sample.pub root@localhost
ssh-add -K ~/.ssh/ssh_sample

公開鍵認証にするために再度設定を変更する。

vim /etc/ssh/sshd_config
  • PubkeyAuthentication
    • yes
  • PasswordAuthentication
    • no

編集が終わったらservice ssh restartでsshを再起動する。

これで公開鍵でログインすることができる ssh -p 2022 root@localhost

自分なり勉強時間捻出法

雑記

資格試験を3月末までに合格しなければいけなかったため、どうしても勉強時間を捻出する必要があった。 結論から言うとSNSに滞留する時間を削った。 無事に資格試験にも合格して、その後もいい勉強のサイクルが生まれているので現時点での記録としてメモをしておく。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

スマホからアプリを消す

まずスマホにアプリが入っている場合はスマホから削除する。 いきなり一番難しそうだけど、これが一番効果がある。 手に届く場所から消えるので起動する回数が減った。

何を消して何を残したかは次になる。

LINEはSNSというより連絡手段のツールなので仕方がないし、常駐して楽しむものでもないのでこのままにした。 Instagramをそのままにした理由は2つある。

  • そもそもフォローしている人数が少ない
  • 基本的には写真をつけないと投稿できない制約

という面から情報が流れるスピードが遅いと判断できたからになる。 情報が少なければ、すぐにInstagramから現実世界に戻ってくることができる。

Twitterはこの理由の逆になり、フォローしている人が多いし、テキストで気軽につぶやかれる。つまり情報が流れてくるスピードが早いため削除の対象になった。 スピードが早いと貯まる情報の量も多くなり、それを消費するために時間も使い…と悪循環になる。 コミュニケーションのツールとしては素晴らしいので、アカウントを削除したり、フォロー整理をすることは考えなかった。

次に難しそうなものがSlackになる。 自分は在宅な上に業務でSlackを使っていないのでスマホから排除することができたが、そうでない人は会社のSlack以外はサインアウトしておくといったことで対応できるかなと思った。 これも情報が溜まる場所を少なくしていく考え方に近い気がする。

削除することへの弊害にどう対処するか

削除をすると情報が得られない可能性があるので難しいという話があるかもしれない。 だが、少し悲しい話になるが、そんなに急ぎで重要な話が飛んでくることは少ない現実がある。 業務用Slackの話は置いておくが、突然Twitterで可及的速やかに知らせないといけないという理由でメンションされることがあっただろうか、コミュニティSlackで今すぐにも知らせたいと話題を振られることがあっただろうか。 たぶんほとんどの人がないんじゃないかと思う。 自分も最初は心配だったので、TwitterのDMが来たらメールアドレスに通知する設定したりして対処した。 今ではこれで全く問題なく回っている。

SNSでアクティブに行動しない

主にTwitterの話になる。スマホからアプリを削除した結果ある程度快適な環境が完成した。 次に実行したことは、より勉強の時間を捻出するために自分からSNSでアクティブに行動する時間を減らした。 Twitterでいうとつぶやく回数を減らした。

iPadやPCのブラウザからTwitterにアクセスして気分転換することはあったが、そこでつぶやくことを控えた形になる。 自分からつぶやかないことによって、「なにかリアクション来ているかな？」の確認を減らすことができた。 そもそも、このご時世なのでなかなかつぶやけることも少ないので、それも相まった。

まとめ

3月末までに合格しなければいけないプレッシャーもあったが、もう一つプレッシャーを感じていて、それはコロナに対する慣れだった。 生活様式がガラリと変わって1年経つが、ある意味で慣れてきたこともあり、そんな中でこのままだともう一年同じように過ごすのではないかというプレッシャーが自分の中に掛かってきた。 ここで大きく何かを変えようと思ったら、SNSから離れることだった。

ここにメモ書きしたように今のところうまくいっていて、仕事について落ち着いて考える時間だったり、勉強する時間だったり、それ以外のことだったり自分の時間を取り戻すことができたように感じている。 時間を投資する方向を少しずつだけど修正できていて、何よりその時間が楽しい。次は、投資した結果がいい方向に向いてくれることを祈っている。

SCRUM BOOT CAMP THE BOOKを読んだ

本

社内でアジャイル開発研修を受けたので、そのままいくつか深堀りしたくなり、「スクラム」をテーマにしている SCRUM BOOT CAMP THE BOOK を読んだ。

はじめて「スクラム」をやることになったら読む本

と表紙に書いてあるように、内容がストーリー仕立てで書いてあったりマンガが差し込まれていたり、とてもわかりやすかった。

内容

本の内容は、スクラムマスターを任されることになった「ボク」を中心に話が進んでいき、その中でスクラムを実践していくというもの。 ページ数としては 250 ページほどになり、前にも書いたが挿絵が豊富だったりもするのでサクサク読める。 集中して読めば 1 日で、もしくは土日で読み終えることができそう。

最初の 20 ページは基礎編としてスクラムを聞いたことない人のための用語解説があり、今スクラムという単語を聞いた人にもわかりやすいようになっている。 残りは実践編として、ストーリーに沿ってスクラムをおこなっていく姿を見ていくもので、なんとなく概要を知っている人はこちらから入っても良さそう。

あえて書かれなかった「ふりかえり」から見るこだわり

この本にはふりかえり（スクラムとしては、スプリントレトロスペクティブ）については書かれていなかった。 終盤に差し掛かったとき「ふりかえりついては解説が無いのかな？」と読み進めていたが、なぜ振り返りについては書かなかったかがきちんと記されていて納得した。

けれど、最初の頃のスプリントレトロスペクティブは、スプリントで起きた問題に対処しようとして、問題解決のイベントになりがちになる。ボクくんたちも、そうなっていただろう。それだと本来のスプリントレトロスペクティブの姿を誤解させてしまうので、実践編では伝えなかったんだ。

本書256ページより引用

スクラムについてアレコレ詰めるのではなく、対象読者を絞った上で内容から外したあたりからも、この本がしっかり考えられた上で書かれたんだなということが実感できた。

個人的に良かったところ

活きたコラム

個人的に良かったところは 8 本のコラムだった。

  • 遠慮がちなプロダクトオーナー
  • インセプションデッキでチーム共通の言葉を作ろう
  • 少しずつ前に進もう
  • リリースレゴで「達成の積み重ね」を可視化しよう!!
  • 楽しくふりかえりをするためのテクニック
  • なぜこの機能を作るのか？
  • コミュニティイベントを利用してチームビルディング
  • タスクをみんなで寄ってたかって終わらせるスウォーミング

自分は本のコラムを結構飛ばしてしまうことが多いのだが、「リリースレゴで「達成の積み重ね」を可視化しよう!!」がとても面白く、そのまますべてのコラムに目を通した。 先人たちの知恵や工夫が載っており、片面 1 ページの内容ではあるのだが、スクラムを上手に回していく潤滑油のようなものを感じた。

参考文献が豊富

「理解を深めるために読んでほしい文献」として 14 冊の本が紹介されていた。 この本の先にある本として、テスト駆動開発など有名な本が並んでいて参考になった。 スクラムを実践の中で使える機会はまだなさそうだが、ふりかえりの項目が気になるので紹介されているものの中から手にとってより深く入ってみようと思う。

まとめ

スクラムについてはもちろん、スクラムを通してアジャイル開発に踏み出していく最初の一冊としておすすめできる本だと思った。

Azure: DP-201: Designing an Azure Data Solutionに合格した

資格試験 Azure

2021/03/30 に Azure の資格試験、「DP-201: Designing an Azure Data Solution」に合格した。

この試験の受験者は、Azure データ サービスを使用するデータ ソリューションを設計するためのデータ要件を、ビジネス関係者と協力して特定および満たす Microsoft Azure データ エンジニアです。Azure データ エンジニアは、リレーショナル データ ストアとノンリレーショナル データ ストアを使用する Azure データ記憶域ソリューション、バッチおよびリアルタイムのデータ処理ソリューション、データ セキュリティとコンプライアンス ソリューションの設計など、データ関連のタスクを担当します。本試験の受験生は、次の Azure サービスを使用するデータ ソリューションを設計できなければなりません。Azure Cosmos DB、Azure Synapse Analytics、 Azure Data Lake Storage、Azure Data Factory、Azure Stream Analytics、Azure Databricks、および Azure Blob ストレージ。

https://docs.microsoft.com/ja-jp/learn/certifications/exams/dp-201 概要より引用

とあるように、Azure 上で提供されているリソースでデータ分析基盤の設計が中心に問題が出題される。

DP-200も同じ日の午前に受けて合格し、2枚抜きしてきた。 はっきり言って疲れるのでおすすめはしない。

yoshitaku-jp.hatenablog.com

問題の範囲

公式サイトによると、次のような範囲と割合で出題される。

問題の範囲 出題の割合
Azure データソリューションのデザイン 40-45%
データ処理ソリューションのデザイン 25-30%
データ セキュリティとコンプライアンスの設計 25-30%

英語にはなるが、より詳しい出題範囲が乗っている PDF が提供されているのでこちらも目を通すのが良さそう。

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3VRMb

問題の形式

問題の形式に関してはDP-200とほぼ同じなので、引用する。

ベンダーの試験を受けたのが、数年前の Oracle Bronze と半年ほど前の Microsoft AZ-104 のみで問題の形式に慣れなかった。 AZ-104 が Microsoft 試験の初回だったけど記憶にないので、同じような感じだったか明言ができない。

問題数としては 40-50 問ほどになる。 すべての問題に共通しているのが選択問題ということがある。記述はなかった。 しかし問題の出され方に特徴があり、あとから見直せる問題と、見直せない問題がある。 見直せる問題は単発の問題になり、見直せない問題は要件定義があるケーススタディ問題だった。 ケーススタディ問題は 2 つあり、その中で 4,5 問ほど問われた。つまりケーススタディ全体の問題数としては 10 問ほどになる。 そこに単発の問題が 30-40 問で、「問題数としては 40-50 問ほどになる。」が構成される。

見直せない問題は、問題文も読めなくなるのでとても不安になるが自信を持って答えよう。 単発問題はあとから見直せるので、わからないところもササッと答えて、他の問題を見た結果思い出されたら戻ってこれるようにしておこう。

勉強教材

MS Learn

ゼロから始める人は MS Learn で概要を把握するのがいいと思う。 なかなか知られていないが Microsoft の勉強教材は結構良いのが揃っている。 下記ページの下部に、対象の勉強資材が乗っている。

docs.microsoft.com

mstep

mstep も Microsoft の勉強教材となる。こちらは少し試験に特化されている。

partner.microsoft.com

Udemy

より試験勉強の問題に特化したい場合は外部のサービスもある。

www.udemy.com

本

設計を問われるので、時間がある人は「図解即戦力　ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書」を読むのもいい。この本は、ビッグデータを扱うに当たり、どういう経緯でデータ分析処理基盤が生まれたのかとか、それを実現するためにどういうアーキテクチャを組めばいいかとかが載っている。ラムダアーキテクチャが何を言っているかとか、それを実現するためにどういうアプリケーションを使えばいいかとかの概要がつかめればいいと思う。

図解即戦力　ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書

図解即戦力　ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書

まとめ

とここまで紹介しておいて、この試験と DP-200 は 2021/06/30 に終了となる。 少し期間を開けて DP-203 を受けるのが良いかも知れない。

この試験の最新版 DP-203 は 2021 年 2 月 23 日に可能となります。2021 年 6 月 30 日に終了となるまでこの試験を受けることができます。注:試験は中部標準時の２３時 59 分に終了致します。

yoshitaku-jp.hatenablog.com

Azure: DP-200: Implementing an Azure Data Solutionに合格した

資格試験 Azure

2021/03/30 に Azure の資格試験、「DP-200: Implementing an Azure Data Solution」に合格した。

この試験の受験者は、Azure データ サービスを使用するデータ ソリューションを実装するためのデータ要件を、ビジネス関係者と協力して特定および満たす Microsoft Azure データ エンジニアです。Azure データ エンジニアは、データ ストレージ サービスのプロビジョニング、ストリーミング データとバッチ データの取り込み、データの変換、セキュリティ要件の実装、データ保持ポリシーの実装、パフォーマンスボトルネックの特定、外部データ ソースへのアクセスなど、データ関連の実装タスクを担当します。この試験の受講希望者のの方は、下記 Azure サービスを使用するデータソリューションを実装できる必要があります: Azure Cosmos DB、Azure Synapse Analytics (前の Azure SQL DW)、Azure Data Factory、Azure Stream Analytics、Azure Databricks そして、Azure Blob storage。

https://docs.microsoft.com/ja-jp/learn/certifications/exams/dp-200 概要より引用

とあるように、Azure 上で提供されているリソースでデータ分析基盤の実装が中心に問題が出題される。

DP-201も同じ日の午後に受けて合格し、2枚抜きしてきた。 はっきり言って疲れるのでおすすめはしない。

yoshitaku-jp.hatenablog.com

問題の範囲

公式サイトによると、次のような範囲と割合で出題される。 個人的には、試験を終えた後に「あの問題がこのカテゴリか〜」と気がつくことはないので、まんべんなく準備することが大事になるかもしれない。

問題の範囲 出題の割合
データストレージソリューションの実装 40-45%
データ処理法の管理と開発 25-30%
データソリューションの監視と最適化 30-35%

「実装」を問う問題の中には、「想定される結果がほしいときに、Stream Analytics で実装される分析関数は 「LAG」「LEAD」「hoge 」ではどれか」を選択する問題もあった。

英語にはなるが、より詳しい出題範囲が乗っている PDF が提供されているのでこちらも目を通すのが良さそう。

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3Vzx2

問題の形式

ベンダーの試験を受けたのが、数年前の Oracle Bronze と半年ほど前の Microsoft AZ-104 のみで問題の形式に慣れなかった。 AZ-104 が Microsoft 試験の初回だったけど記憶にないので、同じような感じだったか明言ができない。

問題数としては 40-50 問ほどになる。 すべての問題に共通しているのが選択問題ということがある。記述はなかった。 しかし問題の出され方に特徴があり、あとから見直せる問題と、見直せない問題がある。 見直せる問題は単発の問題になり、見直せない問題は要件定義があるケーススタディ問題だった。 ケーススタディ問題は 2 つあり、その中で 4,5 問ほど問われた。つまりケーススタディ全体の問題数としては 10 問ほどになる。 そこに単発の問題が 30-40 問で、「問題数としては 40-50 問ほどになる。」が構成される。

見直せない問題は、問題文も読めなくなるのでとても不安になるが自信を持って答えよう。 単発問題はあとから見直せるので、わからないところもササッと答えて、他の問題を見た結果思い出されたら戻ってこれるようにしておこう。

勉強教材

MS Learn

ゼロから始める人は MS Learn で概要を把握するのがいいと思う。 なかなか知られていないが Microsoft の勉強教材は結構良いのが揃っている。 下記ページの下部に、対象の勉強資材が乗っている。

docs.microsoft.com

mstep

mstep も Microsoft の勉強教材となる。こちらは少し試験に特化されている。

partner.microsoft.com

Udemy

より試験勉強の問題に特化したい場合は外部のサービスもある。

www.udemy.com

まとめ

とここまで紹介しておいて、この試験と DP-201 は 2021/06/30 に終了となる。 少し期間を開けて DP-203 を受けるのが良いかも知れない。

この試験の最新版 DP-203 は 2021 年 2 月 23 日に可能となります。2021 年 6 月 30 日に終了となるまでこの試験を受けることができます。注:試験は中部標準時の２３時 59 分に終了致します。

yoshitaku-jp.hatenablog.com

Azure: Logic AppからTeamsへ通知を送る

Azure

Azure上の処理を結果をTeamsに送信したい要件がよくあり、すぐに案内ができるように手順をまとめておく。

Logic Appを作成する

AzureからLogic Appリソースを選択し、作成をおこなう。

f:id:yoshitaku_jp:20210328114141p:plain

リソース作成時のパラメータは特殊なものはないので、「サブスクリプション」「リソースグループ」「リージョン」が作成したい場所になっているか確認、またロジックアプリ名を記述し作成する。今回は「test-la」とした。

f:id:yoshitaku_jp:20210328114305p:plain

Logic App デザイナーで処理を作成する

次にLogic App デザイナーで処理を作成する。初回起動だとデザイナーがすぐに表示されることが可能性がある。下記の画像のようにリソースの詳細ページが開かれたときは、赤枠の場所をクリックすることでデザイナーの画面を表示する事ができる。

f:id:yoshitaku_jp:20210328115702p:plain

デザイナーは次のような画面となっている。

f:id:yoshitaku_jp:20210328115925p:plain

Logic Appには「トリガー」と「アクション」がある。この2つは何が起きたらの「トリガー」部分と、何をするの「アクション」部分で構成されている。

「トリガー」部分はよく使われる例にもあがっている通り、次のようなものがある。

  • メッセージがService Bus キューで受信されたとき
  • HTTP要求の受信時
  • 新しいツイータが投稿されたら
  • Event Gridのリソースイベントが発生するとき

今回の「アクション」部分は「Teamsへ通知を送る」となる。ブログ内では「トリガー」部分は「メッセージがService Bus キューで受信されたとき」で進めていく。

Service BusとLogic Appを接続する

Logic AppからどのService Busを確認するかや、接続設定したときの名前などを決定する。

「bus2teams」（Bus to Teams）などわかりやすい名前をつけて進めていく。

f:id:yoshitaku_jp:20210328131856p:plain

Teamsへ通知をする

Teamsへの通知はいくつか方法があるので紹介する。

Microsoft Teams

「アクション」の中にMicrosoft Teamsがあるので、こちらを選択するのが最も簡単にできる。

しかし、2019年からプレビューとついていて、2021年になっても外れていないので、そこだけ注意が必要となる。

f:id:yoshitaku_jp:20210328133728p:plain

実際に設定すると、個人のTeamsアカウントでログインし、GUIで設定していく。

メッセージもこの画面上から装飾し設定できるのですぐに実装することができる。

f:id:yoshitaku_jp:20210328134431p:plain

f:id:yoshitaku_jp:20210328134621p:plain

HTTP

次はHTTPで送信する方法になる。 こちらは送信先TeamsチャンネルのURLを取得し、そこに送信する方法になる。

Teamsで「コネクタ」を選択し、Incoming webhooksを選択する。作成が完了するとURLが発行されるのでメモしておく。

f:id:yoshitaku_jp:20210328135319p:plain

f:id:yoshitaku_jp:20210328135419p:plain

Logic Appでの作業に戻り、「アクション」でHTTPを選択する。

f:id:yoshitaku_jp:20210328140210p:plain

今回の設定値は次のようにする。

名称 値 値2
方法 POST
URI Teams Web Hookでメモした値
ヘッダー Content-type application/json
本文 {
"text": "Hello World"
}

Teams上では次のように表示される。

f:id:yoshitaku_jp:20210328142429p:plain

本文の設定がJson形式でおこなうため柔軟にできる反面、カスタマイズする部分が多くなればドキュメントを見なければならなくなりコストが増えることが懸念される。

docs.microsoft.com

Teamsのメールアドレスにメールを送信

メールを送信する形で通知をおこなうこともできる。まだ検証をしていないので詳しくは別の機会にするが、Logic AppでTeamsログインが出来ず、コネクタでIncoming webhooksが使えないときに使うことが想定される。

まとめ

Logic AppからTeamsへ通知を送る方法をまとめた。 Teamsへの送信部分は3種類あり、適切な場面で適切なものを選択できればいいと思う。

分析関数について

SQL

業務で分析関数を使うことがあったが、今まで簡単な SQL しか触ったことがなかったので苦労した。 調べた中で整理を兼ねて、複数回に渡りまとめておく。

分析関数を一言でいうと、入力された値を集計し、各行に値を返すものとされている。 集計の動作を聞くと、SUM や AVG といった集計関数が思い出されると思う。 しかし分析関数は、集計関数が入力された値を集計し 全体で 1 つの値を返しているのに対し、各行に値を返している点で違う。

分析関数のメリットについては、問い合わせ速度の工場と、開発作業の効率化がある。 分析関数を使うことで、複雑な処理を記述しなくなるようになり、SQL 文を簡単に書くことができる。 簡単に書けることで読むタイミングでも理解がしやすい、複雑な処理がなくなるので処理パフォーマンスも上がるようになる。

yoshitaku-jp.hatenablog.com

SSMS: 「変更の保存が許可されていません。」エラーを回避する

エラー

SQL Server Management Studio（以下SSMS）で、「変更の保存が許可されていません。おこなった変更には、次のテーブルを削除して再作成することが必要になります。再作成できないテーブルに変更を行ったか、テーブルの再作成を必要とする変更を保存できないようにするオプションが有効になっています。」というエラーが出た。

最初はテーブル側の権限設定が足りないと思っていたが、SSMS側で回避できることもわかり、そのやり方をメモしておく。

発生したタイミング

まずは、自分が発生したタイミングについて書く。 まずは最初にテーブルを作成した。

f:id:yoshitaku_jp:20210314120738p:plain

次にデータ型を変更する必要が出てきたため、変更を実施し保存しようとした。

f:id:yoshitaku_jp:20210314121549p:plain

しかし、その後「変更の保存が許可されていません。おこなった変更には、次のテーブルを削除して再作成することが必要になります。再作成できないテーブルに変更を行ったか、テーブルの再作成を必要とする変更を保存できないようにするオプションが有効になっています。」エラーが発生した。

f:id:yoshitaku_jp:20210314121610p:plain

解決するための設定

まずはタブから「ツール」->「オプション」をクリックする。

f:id:yoshitaku_jp:20210314121654p:plain

「オプション」のウィンドウで、「デザイナ」に移動する。その後「テーブルの再作成を必要とする変更を保存できないようにする」にチェックをする。 これで完了となる。

f:id:yoshitaku_jp:20210314121650p:plain

注意するべきところ

今回は調査段階での部分だったので良かったが、SSMS側で変更を制御していた部分をゆるくすることでもあるので、テーブル操作については引き続き注意してやっていきたい。