ワーパパエンジニアの学び手帳

ワーパパエンジニアの業務外での学びとかガジェットネタとか

スタディサプリENGLISH パーソナルコーチプランを開始しました

ひさびさ投稿でございます。
これまでプログラミングやガジェットネタなどを(とっても不定期に)更新してきたこのブログですが、プログラミング以外にも勉強したことや考えたことなども投稿していきたいと思っています。これは特に方針変換というわけではなくたまたま勉強してた内容がプログラミングの内容ばかりというだけの話なのですが。
で、最近というか12月までの3ヶ月、色々理由あって英語の勉強をすることになりまして、タイトルのとおり「スタディサプリENGLISH パーソナルコーチプラン」を開始したのでちょっとご紹介です。

目次

背景

わたくし某SIerのSEとして働いているわけですが、ここ数年はずっと同じお客様のシステム担当でシステムの新規開発や既存システムの機能改善などを行っています。
ただ、長く同じシステムの担当をしていることで、悪い意味で慣れが出てきてしまっています。技術的にも新たに学ぶところが少なく、モチベーションがなかなか上げられない日々。
そんな現状なので異動希望を長らく出しているのですが、今のシステム担当メンバーが少なくジョブローテするリスクが高いこと、去年新人が配属されてまだまだ育成が必要であることなどから、異動もさせてもらえていない状況です。
一方で、社内では英語圏の某国オフショアを活用した案件の拡大をかなり強く推し進めていて、有望な人(一定の業務経験があり英語がある程度使える人)はどんどんそっちに回されているという状況があります。
現状を変えるため、この流れに乗るため、声がかかるためには英語の運用能力を上げることが必要だ!ということで英語を勉強しようとなったわけです。

現状の英語力と目標地点

現状の英語力としてはTOEICで650点程度(数年前に一時期集中して英語を勉強した際に800点台前半を取っていますが、今年会社で受けたCASEC(類似のオンラインで受験可能な英語能力試験)ではTOEIC換算で650点程度でした)。
目標は今年12月のTOEICでAランクとされる860点オーバーを取ることです。

選んだ理由

世の中には英語学習のためのアプリやらマンツーマンの教室とか(最近ライザップ英会話なんかも話題ですよね)ありますが、なぜスタディサプリENGLISH、さらにはパーソナルコーチプランを選んだのかという点。
まあ簡単に言うと以下2点で、

  • とにかく評判がめちゃくちゃいい
  • マンツーマンとしては安い

という理由からです。

とにかく評判がめちゃくちゃいい
ネットの情報を漁ってみるとほんと評判がすごいです。軒並み100点~200点アップ。
スタディサプリENGLISHのアプリ自体が非常にいい出来、その上にマンツーマン指導が加わって死角なし、といったところです。
studysapuri-english.infonzplus.net

マンツーマンとしては安い
マンツーマン指導の英語教室ってウン十万なんて費用がかかり、正直そこまではかけられないと思ってしまうのですが、スタディサプリENGLISHのパーソナルコーチプランは\68,000(3ヶ月コースの場合)です。
それでも高いっちゃ高いのですが、この中に通常有料のテキスト8冊(通常購入で約\8,000)、パーソナルコーチ終了後12ヶ月間のベーシックプラン無料(通常\2,480/月)が付いてくるので実質月1万くらいでしょうか。個人的には「それならまぁ、、」と感じるくらいのラインかなと思いました。

ベーシックプランではなくパーソナルコーチプランを選んだのは、上記のとおり価格的にもまあ納得できたのと、過去に自分で勉強した際には800点台前半で止まってしまい(2回連続で同じスコアだった)、そこを超えるにはやり方を変える必要があるかなと感じた点、短期集中でスコアを上げるには評判のいい方法で少しでも確率を上げたいと思った点からです。

始めてみて思うところ

パーソナルコーチプランでやること(やってもらえること)は以下のような点があります。

  • 日々の学習報告
  • 個々の得意不得意にあわせたアドバイス
  • 疑問点の解消(質問)

1つ感じることとしては、当たり前なんですけどパーソナルコーチプランをやってるからといって点数が勝手に上がるわけではないというところです。求められる学習量が1日2時間とかなりハードルが高いのですが、日々の学習報告があるということで少しでもやらなくてはという気持ちになるという効果は少なからずあるなと感じています。
で、意識していないとただ日々の報告を行うだけのためのパーソナルコーチになってしまいかねないなぁと現状感じています。結構勉強時間を確保するので大変、そこに学習報告が乗っかるのでとにかく時間確保が大変という状況で、それに追われると本来のメリットであるはずの疑問点をいつでも質問できる点とかが生かしきれないなと思います。せっかくいつでも疑問に答えてくれる人がいる状況なので、3ヶ月間出来る限り活用したいなと思います。
なお、学習を開始する際に模試を1回受けるのですが、その際の点数は600点台前半とかなり低調なものでした。その回答内容も解答用紙をスマホで撮影してチャットに送信し、コーチの方で回答の傾向を分析してくれて学習方法を提案してくれたりと、自分では気づくことのできない点も気づかせてもらえます。

アプリ自体の出来がかなりいい

前回800点台をとったときも、TOEICの勉強方法といえば解説本を読んで解き方を学び、あとはひたすら問題を繰り返し解きまくる、といった感じだったのですが、今回はかなり同じ問題を深く理解することを求められています。それはコーチから言われる内容もそうなのですが、アプリ自体の内容が1つ1つの問題文から最大限学びを得させるような内容になっています。
具体的には、1つの文章に対して音声を聞いてのディクテーションをさせたり、シャドーイングをさせたりといった点。
アプリの作りがこれらの方法を取りやすいように作られており、シャドーイングも同じ文章を何回も繰り返し聞きやすいのでやりやすいなーと感じます。
こういった学習方法はこれまで採っていなかったので、これがどれだけ効果として出てくるのか楽しみです。
↓画像はディクテーションのスクリーンショット

現在キャンペーン中らしい

なにやら現在(2018年10月19日現在)パーソナルコーチプランのキャンペーン中らしいです。
1万円offプラス1万円キャッシュバックとか。わたくし申し込んだのが3週間ほど前なのですが、そのときはちょうどキャンペーンの狭間だったようで、もったいないことしたな~という気分。
もしかしたらTOEICのスケジュールとかも加味してキャンペーン期間を決めているのかもですね。とにかく今はお得な期間なので、気になった方はぜひ。

公式 TOEIC Listening & Reading 問題集 4

公式 TOEIC Listening & Reading 問題集 4

認定ScrumMaster研修を受けました

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

目次

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

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

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

筆者のスクラム経験

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

研修の内容

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

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

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

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

学んだこと

マインドセット

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

組織論

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

問いかけ、質問の効果

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

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

例えば、デイリースクラム。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-notifierというのがあるため、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