三十路SEの学び記録とかなんとか

子育て中三十路SE♂の業務外での学びとかガジェットネタとか

認定ScrumMaster研修を受けました

先日、認定スクラムマスターの研修を受講したので、その内容を記事にしたいと思います。 ※記事の内容はあくまで個人の感想であり、研修の内容を保証するものではありません。

認定スクラムマスター研修について

認定スクラムトレーナーによって開催されるScrum Alliance認定研修です。
認定スクラムトレーナーは世界で250人ほどいるそうですが、日本人は江端一将さんただ一人ということです。
江端一将|Kazumasa Ebacky Ebata|チーム|株式会社 Odd-e Japan
なお、公開で参加者を募っているもの(パブリック研修)と企業内で開催するもの(プライベート研修)があるようです。
今回私が参加したのは所属会社で開催したものです。
そのため受講した日程などは伏せさせていただきます。

研修を受講し、研修中の評価を元にオンライン試験の受験資格が与えられます。
これをクリアすると晴れて認定スクラムマスターとなります。
(私も無事資格取得できました。)

筆者のスクラム経験

全くのゼロです。アジャイル自体経験なし、これまでの経験は全てウォーターフォール
今回研修を受講したのは、こういった現状を打破したい、これまでと違う案件へのアサインを自身で選択するために必要な知識を習得しようという意図があってのものです。

研修の内容

江端さんから出された課題に答えていくという形式。 研修を作り上げるのは受講者で、上記以外の研修の進め方や時間の使い方など全て受講者に任される。 受け身ではなく限られた時間で多くのものを得ようという姿勢が求められる。 色々教えてもらう体で参加するといきなり背筋を伸ばされる感じです。

実際のところ、私が参加したクラスでは最初に出された課題の答えに3日間かけてもたどり着くことができませんでした。
それはスクラムに必要な考え方、ベーススキルが全体として不足していたということだと思いますが、
かと言って何も学べなかったわけではなく、課題の取り組み方に対するコメントやスクラムと関連付けた考え方を聞くことができ、
スクラムにおけるやり方、考え方も学ぶことができました。

とはいえ3日間考えても最終的に答えにたどり着かなかったのはかなり精神的にしんどいものです。苦笑
研修が終わっても、「こうやったら上手く行っただろうか」などと考えてしまい、しばらくは夢に出てくるほど悶々とした日々を過ごしました。。
きっと実践する際にもやり方を試行錯誤して悶々とする日々なんだろうなぁ、なんて想像しました。うーんツラい。

学んだこと

マインドセット

世に出ている書籍はスクラムフレームワークとして定義されているものだけでなく、著者の経験などから現場で役に立つツールや方法論などが追加されて書かれています。
明確に区別している本であればよいのですが、多くの本はそれらをスクラムの一部であるかのように書かれています。
その結果、スクラムのココロを理解せず、「プランニングポーカーやってるからスクラムだ~」みたいな、やり方だけなぞった似非スクラムが横行しています。
この研修では手法的なところや教科書的なところはほとんど触れず、スクラムのココロに主にフォーカスして進められました。

組織論

中央集権型とチーム中心型の衝突、他にも組織論における組織のパターンは全て押さえておく必要がある。
 ⇒スクラムマスターはスクラムを無理矢理適用するのではなく、スクラムが適さない場合に別の選択を提示する
 ⇒チーム中心型:論理的優位性が全て。権威者の考えが通るのではなく、論理的に優位な考えが正しい。論理的矛盾がある考え方を無理に通す、許す、とすると、途端にチームは考えなくなる。
 ⇒スクラムマスターはチームの障害となるものからチームを守る必要がある。会社組織は中央集権型組織が殆ど。チーム中心型との間で生じる衝突からチームを守るために、どういった衝突が発生しやすいか、衝突発生時にどう対処するかを考える上で組織論に精通している必要がある。

問いかけ、質問の効果

問いかけや質問を繰り返すことで、本人が気づいていない課題に気づくことができたり、論理的矛盾を正していくことができる。
しかし、実はこれらはスクラムマスターが最もやってはいけないこととのこと。
スクラムマスターはスクラムの「促進」と「支援」に責任を持ち、チームは「自律的」であることが求められます。
問いかけや質問で介入することで、チームが「自律的」であることを阻害してはならない、というわけです。
スクラムマスターは、目の前でチームが問題を抱えていても、助けを求められない限り自分から動いてはいけないという、「忍耐力」が求められるとも。

スクラムの手法の勘違い的な

例えば、デイリースクラム。3つの問いかけ「昨日やったこと、今日やること、気になっていること」から進捗確認が主目的と考える人がいる。 3つの問いかけで最も重要なのは「気になっていること」。 チームは「生産性を上げること」に責任を持つ。生産性を上げるために障壁となること、改善できそうなことを挙げ、必要に応じて改善策を打っていくことがデイリースクラムの主目的である。
ここで「気になっていることはありません」というのは、チームの責任を放棄していることと同義。ここでも、スクラムマスターは例えこの状況を目の当たりにしても自分からは「ほんとに無いの?」的なことを聞いたりすることはNG。。チームが自律的に現状を打破していくことが求められる。

アンチパターン

手法だけをなぞっているとアンチパターンにものの見事にハマります。「スクラムやってます」という人でもアンチパターンをまんま実行しているということが多々あるとのこと。
今回の研修におけるディスカッションでも見事にアンチパターンにハマりまくってました。。

製品品質(付加価値的なもの)と技術品質(最低限満たすべきもの)

プロジェクトでは技術品質を後回しにして製品品質を満たすことを先にしようとするが、これはNG。
スクラムでは、プロダクトは常にリリース可能な状態であることが求められる。つまり、技術品質は常に満たしている必要がある。

アジャイルは「とりあえず回す」?

アジャイルは「とりあえず回す」みたいにイメージを持たれるが、スクラム(に限った話ではないと思いますが)の考え方としては「評価基準(≒受入基準 acceptance criteria)を明確に定め、その基準を満たす(であろう)方法で進める」。
最大の効果が得られるか分からないが、効果があるかどうかは評価をしたうえで手法を選択する。
本来の考え方はこれですが、いつの間にやら「基準だけ用意し、ひとまず始めて後で評価する」「基準も用意せずとりあえず始める」となってしまうことは本当によくある、とのこと。

総括

冒頭にも書きましたが、3日間ずっと頭使いっぱなし、しかも1人でではなくディスカッションしてクラスで答えを作り上げていくというプロセスはなかなかハードなものでした。
スクラムの研修ではありますが、それ以外の面でも勉強になった面が多々。
今回スクラムの経験が全くない状態で研修を受講し、スクラムの考え方の理解も進みましたがそれよりもスクラムのハードさを思い知らされたという方が強いかもしれません。。
ただ、学んだだけでは面白くないので、実際にスクラムでプロジェクトを進めたり、それ以外でも今回学んだ考え方を色んな場面に適用していきます、という宣言。
がんばろう。

なお、今回研修受講にあたって「カイゼン・ジャーニー」を事前に読みました。考え方や手法の適用方法をイメージするのにいい本だと思います。
もっと前には「アジャイル・サムライ」も読んでたけど、内容忘れてるので読み返して研修の内容と照らし合わせたいなと。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

予約サイトから空き情報を定期的に取得しslackに通知する

再開してからだいぶ間が開いてしまいました。     

今回の内容は、railsのジョブをheroku上で稼働させて、とある予約サイトから情報を取得してその内容をslackに通知するというものです。     

slackは仕事のチームで使っているとかではなく、個人でRSSリーダーやこういった通知のために利用しています。仕事でも使いたい。。    

f:id:us_key:20180809175027p:plain

目次

動作環境

  • Ruby 2.3.0p0
  • Rails 5.0.7
  • slack-notifier 2.3.2

railsでタスクを作る

ひとまずrails newRailsアプリケーションを生成した後、ジョブ実行するためのrakeファイルを作成します。

$ rails new schedulerSample

$ rails g task scheduler

slack通知する

slack-notifier

railsからslackにメッセージを送るためのgemslack-notifyというのがあるため、gemfileに追加してbundle installしておきます。

# Gemfile
gem 'slack-notifier'

slackの設定

以下にアクセスしてslackにAPPを作成します。 Slack API: Applications | Slack

開いた画面で「Create New App」を押します。 f:id:us_key:20180809122009p:plain

アプリケーションの名前を適当に決めて入力し、ワークスペースを選択して「Create App」を押します。 f:id:us_key:20180809122103p:plain

「Incoming Webhooks」を押します。 f:id:us_key:20180809122106p:plain

「Activate Incoming Webhooks」を「On」にします。 f:id:us_key:20180809122111p:plain

すると下の方に説明やら何やらが出てくるので、「Add New Webhook to Workspace」を押します。 f:id:us_key:20180809122114p:plain

確認画面が出てきます。投稿先をChannelやDirect Message先の中から選択し、「許可する」を押します。 f:id:us_key:20180809122119p:plain

リダイレクトされた画面の下の方に説明と合わせてWebhook用のURLが表示されます。これを後で使います。 f:id:us_key:20180809123505p:plain

rakeタスクの実装

今回空き情報を取得する予約サイトは、とあるパスに配置されているjsonを取得してその内容を表示しているというものです。
なのでそのjsonを取得し、rails上でslackに通知する内容に編集します。

先ほど作ったrakeタスクを編集します。

# /lib/tasks/scheduler.rake
namespace :scheduler do
end

生成された状態はこんな感じ。namespaceというのはタスクをまとめる単位ってところです。
この中にタスクを書いてあげます。

# /lib/tasks/scheduler.rake
namespace :scheduler do
  task :test do
    require 'net/http'
    require 'uri'
    require 'json'

    notifyMsg = ""

    notifier = Slack::Notifier.new("https://hooks.slack.com/services/hogehoge") #hogehogeの部分は生成されたWebhook URLに合わせて変えてください

    uri = URI.parse('https://hogehoge.json') #取得するjsonのURLを指定

    msg = ""

    json = Net::HTTP.get(uri)
    result = JSON.parse(json)

    #jsonの取得結果を編集してmsgに詰める…

    notifier.ping(msg)
  end
end

ここまでできたらローカルで動作確認してみます。

$ rake scheduler:test

想定通りにslackに通知が飛べばOK。

heroku schedulerからタスクを起動する

herokuへのデプロイ

ローカルでherokuコマンドが使用できるようになっている前提で。。
作成したrailsアプリをgit管理したうえで、heroku createでheroku上にアプリを作成します。

$ git init
$ git add .
$ git commit -m "first commit"

$ heroku create schedulersample

そして、herokuのリポジトリにpushしてアプリをデプロイします。

$ git push heroku master

と、ここでエラーが発生。

remote:  !
remote:  !     Failed to install gems via Bundler.
remote:  !     Detected sqlite3 gem which is not supported on Heroku:
remote:  !     https://devcenter.heroku.com/articles/sqlite3
remote:  !

herokuでサポートされていないsqlite3がgemfileに含まれていたからでした。
今回はデータベースを使わないので、gemfileの該当部分をコメントアウトします。
(herokuでデータベースを使う場合は、productionでは別のデータベースのgemを指定します)

bundle updateしたうえで再度herokuにデプロイします。

$ bundle update
$ git add .
$ git commit -m "gemfile revised"
$ git push heroku master

さて、デプロイはできましたがこれだけではまだ定期実行してくれません。 herokuでスケジューラの設定をします。

heroku schedulerの設定

herokuに作成したアプリケーションにaddonを追加します。

$ heroku addons:add scheduler:standard

$ heroku addons:open scheduler

開いた画面で「Add new job」を押します。
f:id:us_key:20180809173025p:plain

実行するタスクの内容(ローカルで実行したのと同じコマンド)、FREQUENCY(Daily/Hourly/every 10 minutesから選択)、次回の実行時間を指定し、「save」を押します。 f:id:us_key:20180809173409p:plain

ジョブの稼働時間が課金対象になりますが、簡単な処理であれば複数稼働していても無料範囲(クレジット登録ありで月1000時間)を超えることはないと思います。
今回のような内容であれば1回の稼働での処理は数秒で終わるので、1時間おきに稼働させたとして1日あたり数分、1か月で数時間ってところかなと。
(もちろん処理内容によるのでログを確認するなどしてください。)

まとめ

ということで、heroku schedulerを使うと簡単にrailsでジョブスケジューラが組めるよという内容でした。
もちろん複雑なスケジュールを組むには別の方法を採る必要があるかもしれませんが、個人で実装するような簡単な内容ならこれで十分かなと感じます。
クローリングなんかにも使えそうですね。

参考

qiita.com

qiita.com

こちらも1年以上ぶり

子育てブログの方も1年放置してましたが、こちらも1年ぶりの投稿をば。

1年更新してなかったわけですが、なぜか1年前より最近の方がアクセス数は増えていました。
なぜかなと思いアクセス解析を見てみると、最もアクセス数を稼いでいた記事がこちら。

us-key-tech.hatenablog.com

うーん、Web系のプログラミングで躓いたとことかの記録で書き始めたブログなのですが、最もアクセス数が多いのがザ・SIergrepに関する記事という。。複雑な心境。。
直近のアクセスの65%がこの記事でした。そしてその結果として、アクセスが平日に集中しており土日はほとんどアクセスがないっていう。業務中にググってもらってるわけですね。 確かに「サクラエディタ 拡張子 除外」で検索するとトップに出てきました。ありがたや?
そんなわけで、業務外の勉強内容を中心に書いていきつつ、業務で役立ちそうなネタもちょいちょい書いていけたらと思います。
ま、1年放置したくらいなので、マイペースでぼちぼち書いていこうかなと。

てな感じでこれからもよろしくお願いします。