Paolo Perrotta氏のセミナー「アジャイルコーチへの道」に参加しました

「アジャイルコーチへの道」 とは

このセミナーです。整理と備忘のために纏めます。

LAND OF COACHING

アジャイルコーチに必要なスキルについての話がありました。

プロダクトマネージャーやスクラムマスターについて学んでいても感じますが、組織とか全体的なところに寄与する役割は、多能工さが求められる感が強いです。そうでないと、回らないとか効率が悪かったりするのかなと。大きく6つのスキルが定義されていましたが、その中で、印象深かったものを以下に記載します。

Conflict Navigator

Conflictにはレベルがあって、Lv0:Depressionだと、抑圧されていたり、自由に話せる雰囲気がないなど、チームとして問題がある可能性があります。

変に意識統一されてしまっていたり、思考停止してしまっている状態も恐らくこれに該当するのではないかと思います。

そういう場合、アジャイルコーチは、適度にコンフリクトが発生するようにNavigateする必要があるとのことです。本当にそれで良いの？とかなぜそれをやるんだっけ？とか、そういう感じですかね。

逆に、高いレベルに行き過ぎてしまったものは下げることも必要になります。（ただし、Lv5までいくとアジャイルコーチの扱うレベルではなくなるとのこと）

Problem Solver

問題を解決する人、ということですが、大切なのはtake it to the teamで、出来るだけ自分ではなく、チームに解いてもらうことです。

一方で、アジャイルコーチが正しい答えに誘導すること（していると感じること）は、とても不愉快に感じる、という意見もあり、なるほどな、と。

アジャイルコーチとしては、自分の中の仮説は持ちつつも、チームを誘導して答えを出す、という絶妙なバランスが必要なのかなと思いました。チームが出した答えは尊重しつつ、自分の中の仮説と照らし合わせて、矛盾があれば、それはどう考えるか聞く、みたいな感じかなー。

Collaboration Conductor

コラボレーションを誘発する（指揮する）存在という意味です。問題解決に必要な人を集めて、コラボレーションさせる役割。（必要な人が集まったら、勝手に問題が解決していく、ということらしい）

適切な人を見極めるとか、声をかけて呼ぶことが出来るとか、場をセッティングすることが出来る能力って感じかなと思います。

で、一番重要なスキルは？

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターンのLinda RisingさんいわくMind your manners.Be polite.ということらしいです。

礼儀正しく、感じの良い人であることが大事、ということですね。反省します。

Fearless Journey

続いて、Fearless Journey―組織を変革する48の影響戦略カードを使ったアクティビティを行いました。

自分が組織に対して変えたい課題を考え、それを解決する方法論として、Fearless Journeyのカードから選択し、その方法論を使ってどう実現するかを考えました。

同じようなカードを持つ2〜3人でチームになり、ワークを行い、最後にワークで見つけたInsightを共有しました。

自分のチームで見つけたInsight

課題

組織がコンフリクトレベルのLv0:Depressionになりやすいと感じていて、もっとコンフリクトが発生するように、変化を与えたいがうまく変化させられない

Fearless Journeyのカード

• 種をまく
• 成功の匂い
• みんなを巻き込む
• ステップバイステップ
• 経営層の支持者

当初の想定

• 良い機会がある度に種をまいて、変わるきっかけにならないか
• 現状よりも良くなる成功の匂いを感じてもらって、変わるきっかけにならないか

などなど

考えたこと

• 例えば、種をまいても変わる人と変わらない人がいる
• 変わる人は良いけど、変わらない人はどうすれば良いか
• 自分はなぜ変わって欲しいのか
  • （変わった方が良くなるとして）より良い状態に変化してもらいたい
  • もっと良い状態になると期待している
• 種をまくことは単に方法論やメリットを見せるだけになっているのでは
• まだ見せられていない期待を伝えられれば、変わろうという人がいるのでは

Insight

• 種をまくときは、相手に対する期待が分かるようにすると良い（のでは）

本当に良いかは検証してみないといけないですね・・・・

懇親会

セミナーの後はsushiパーティでした。セミナー参加者の方々が大変豪華だったので、参加者の方とお話するだけでも大変勉強になりました。

アジャイルとかスクラムをやっていると、「掘り下げ」とか「なぜなぜ」みたいな話が多くなりがちな気がしますが、そういう話ってとても性に合っているなと感じます。（懇親会とても楽しかったという意味です）

参考書籍

アジャイルコーチの勉強には以下の本が良いよ、と紹介してもらったので列挙します。

※紹介されていたのは全て日本語の本ではなかったですが、知ってる範囲で日本語版を貼っています

Agile Coaching

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Facilitator's Guide to Participatory Decision-Making (Jossey-Bass Business & Management Series)

Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

アイデアのちから

プロダクトオーナー祭り2015に参加して、プロダクトバックログについての話をしてきました

プロダクトオーナー祭り2015 ～世界を変えるのは俺たちだ！～にスピーカーとして参加させて頂きました。楽しかった！！

自分が発表してみての話と、他の方のセッションに参加してみての話を両方書かれて頂きます。

自分が発表した話

発表資料

プロダクトバックログビフォーアフター from bonbon0605

www.slideshare.net

発表のポイント

以下のような内容が主に伝えたかったことです。

• バッドノウハウの共有
• 課題との試行錯誤の様子を伝える
• 仮に内容が間違っていたとしてもTry大事

失敗の内容もその改善策も、企業やチームによって色々かとは思いますが、（そして自分も、もちろん正解に辿りついているわけではないですが、）同じようなことをしている方々に、何かしらヒントみたいなものになれば良いなという気持ちでした。

発表後に思ったこと

正直、若干後悔するぐらいプレッシャーを感じていたのですが、やった後はやってよかったと思うものですね。理由として、

• 自分の話にこんなに人が来てくれるのだという感動
• 「この内容あるある」みたいな共感が得られると嬉しい
• 「このやり方良いかも」とか言われると、報われた感が半端ない
• 発表後に色々な人に話しかけてもらえる（懇親会でぼっちにならなかった）
• 自分のやってることの整理になって、さらに色々考えられるようになる

などがあります。

ちなみに、大きなＡ会場と、Ａ会場と比較して小さめのＢ〜Ｄ会場で、発表が行われたのですが（私はＢ会場）、アンケートによると、Ｂ〜Ｄ会場で行われたセッションの中での投票数 第2位 ということでした。本当に感謝感激でした。田舎の両親に報告します。

他の方のセッションに参加した話

比較的自分は最初の方の発表だったので、発表後は主にワークショップに参加して楽しませて頂きました。その内容についても簡単にですが、触れさせて頂きます。

「プロダクトオーナー/プロダクトオーナーシップ」カイワヤ会(出張版)

カイワヤとは

「会話」＋「わや」という造語だそうです。「わや」というのは鎌倉ハムのＫウインナーで（私の出身）愛知県ではおなじみの、「駄目になる」みたいな意味の方言です。方言は知っているのに、会の意味がよく分からなかったのですが（笑）、たくさん（≒めちゃくちゃになるぐらい）話す会みたいな意味かなと想像しました。

内容

プロダクトマネジメントマニフェスト

こちらで扱ったのは、プロダクトマネジメントマニフェスト です。

ここに書かれた内容について、他の参加者の方と、「ここが素晴らしい」とか「これは難しいのでは」「自分はここまではできてるけど、これはできてない」みたいなことを、共有＆ディスカッションしました。

プロダクトマネージャに必要なのは「覚悟」

• 基本的に権限はない
• 製品に対するすべての責任を持っている
• 最も困難な仕事をしている
• すべての分野の専門家でなければならない

（そんなの現実的に無理でしょ、という意見もたくさん出つつ）。そんなプロダクトマネージャに必要なのは 覚悟 ではないか、という話をしていました。

別の機会で、実際にプロダクトマネージャをされている方と、 優れたプロダクトマネージャには、いわゆる「人間力」みたいなものが大事ですね というお話をさせて頂いたこととも通じるところがあるな、というのが自分の所感でした。

自分はまだまだ遠い・・・

『メトリクスによる「見える化」のススメ：No 見える化, No 改善』

課題解決のために、課題を「見える化」するためのメトリクスを考えて設定する、という内容のワークショップでした。内容だけでなく、ワークショップの進め方も大変勉強になる会でした。

ワークショップを通じて思ったことをざっくりまとめます。

メトリクスについて

• 「数値化」できて「問題の状況が分かる」項目の設定って結構難しい
  • 例えば「バグ数」って数値化はできるけど、問題の状況が分かるか。多くなったら良い？少なくなったら良い？
• 「問題の状況が分かる」ためには、解決したい問題が明確になった方が良さそう
  • 「優先順位が頻繁に変わる」が問題？「優先順位が変わるからスプリントが達成できない」が問題？「関係者が不満を持つ」が問題？
• 感情とか数値かできなそうなものも、挑戦してみると楽しそう
  • 「朝来たときの気分」とか「夕方帰るときの気分」とか「ありがとうの数」とか
• 「開発者が喜ぶメトリクスか」「マネージャが喜ぶメトリクスか」の両面を考えるのはとても良い視点
  • 片方だけに都合が良いメトリクスは、何か違っている部分があるのではないか、というヒントになりそう

ワークショップの進め方について

• チーム名を決めるのは良い
  • 連帯感が高まる。名前付けるの個人的にはとても苦手ですが
• 途中で一度発表して、他チームからフィードバックをもらえるのが良い
  • 自分たちだけでは気付きにくいことを言ってもらえる
  • チーム内でたくさんの人が発表できて、良い経験になる
• 複数のチームの進行状況によって、変化できる柔軟なシナリオ
  • 純粋に勉強になりました

反省

最後にちょっとした余談ですが、反省として、 名刺を持っていかなければ駄目 でした。。。

これまでエンジニア界隈の勉強会で名刺交換をした記憶なんてほとんどないのですが、今回は大変多くの方から名刺を頂きまして、普段念のため持っている名刺が一瞬で無くなった私は、ひたすらに頂くだけになってしまいました。。。

関係各位のみなさま、大変失礼致しました m(__)m

Inspired: 顧客の心を捉える製品の創り方

amazon-ecsでAmazon Product Advertising APIを使ってみました

背景

漫画本を扱うアプリを作りたいな、と考えていて、そのための調査として、AmazonのAPIはどんなことが出来るのかな、と調べてみました。

Rubyで使うためのgemを調べたらamazon-ecsというのが見つかったので、とりあえずそれを使いました。

触ったのは主に、商品検索関連です。

事前準備

AmazonのAPIが使えるようにユーザ登録しておく必要があります。

このページから行いました。

リファレンス

• amazon-ecs
• APIリファレンス

書き方・使い方

接続するためのキーなどを登録

Amazon::Ecs.configure do |options|
  options[:AWS_access_key_id] = '[your access key]'
  options[:AWS_secret_key] = '[you secret key]'
  options[:associate_tag] = '[your associate tag]'
end

商品を検索する

item_searchというメソッドを使います。　APIリファレンス

検索対象は、何も設定しないとデフォルトはBookになるようです。

res = Amazon::Ecs.item_search(
  '', # Keyword検索の内容を入力します
  :title => '僕だけがいない街', # titleだけで調べたい場合にはこちらを
  :sort => 'titlerank', # 取得された結果（レスポンス）の中でのソート順になるので、注意が必要です
  :tag_sort => 'Name', # 取得される結果をソートします
  :browse_node => '2250738051', # 検索対象をより細かく設定したい場合に使います。この値はKindleストアです
  :country => 'jp'
)

注意事項としては、一度のitem_searchメソッドでレスポンスとして受け取れるのは、最大10個までなので、全ての結果を取得するには、:item_pageのパラメータを使って、複数回問い合わせる必要があるようです。

取得されたデータから値を抽出する

上記のような処理を行うとAmazon::Ecs.Responseクラスが結果として返されます。この中身はXMLになっているようですが、準備されているメソッドで欲しい情報を取得できます。

流れとしては、Amazon::Ecs.ResponseクラスからAmazon::Ecs.Elementクラスを取得して、Amazon::Ecs.Elementクラスのメソッドでタイトルなどの値が抽出できます

res.total_pages # 検索結果が全部で何ページ分あるのか確認できます
res.items.each do |item| # itemsメソッドで、Elementの配列が取得できます
  puts item.get('ASIN')  #Amazonの商品コードを取得
  puts item.get('ItemAttributes/Title') # タイトルを取得
  p item.get_hash # Elementの内容をHashに変えて処理できるようになります
end

商品IDから商品を検索する

item_search以外にもitem_lookupというメソッドがあります。　APIリファレンス

こちらは、商品IDから該当する商品情報を取得するのに便利です

使い方としては、第一引数にASIN(Amazon Standard Identification Number)を渡してあげれば良くて、Responseから先はitem_seachとほぼ同じ流れになります

asins = ['B00UGU4LF4','B010N2825O'] # ASINはカンマ区切りの文字列で最大10個まで渡せます
Amazon::Ecs.item_lookup(asins.join(','),:country => 'jp').items.each do |item|
  puts item.get('ItemAttributes')
end

その他

item_searchもitem_lookupも:countryというオプションを使っていますが、このオプションはAPIリファレンスには無いものです。

amazon-ecsとして、リクエストを投げるURLを決めるのに使うようなのですが、APIリファレンスに無いために、私はよく書き忘れてしまいます。。。

対策として、最初のconfigureでoptions[:country] = 'jp'と書いてしまえば、毎回書く必要は無くなります。（何もしないとデフォルトはusになっているようです）

[まとめ買い] 僕だけがいない街

僕だけがいない街(6)<僕だけがいない街> (角川コミックス・エース)

SeleniumのActionBuilderを使ってみました

実践 Selenium WebDriverを読んで以来、使ってみようと思いつつ使っていなかったActionBuilderを先日使ったので、メモとして残します

リファレンス

Class: Selenium::WebDriver::ActionBuilder

環境

Rubyです

背景

あるページを開いて、そこにあるアンカーリンクを一通り順番に叩いて、リンク切れしていないか

を確認したい、ということがありました。結構リンク数があったので、Selenium使いたいなという感じです。

ちょっと話は逸れますが、リンク切れしていないかの確認でHTTP STATUSの200 OKを確認しようかと思ったのですが、どうやらSeleniumだとHTTP STATUSが取得出来ないようで、HTTP STATUSを確認する良い方法を模索中です。ちなみに、今回は、諸事情あって、かなり力技で、全部の画面キャプチャを撮りましたww。普通であれば、タイトルとかh1とかで値をチェックすれば大丈夫かなと思います。

話を戻しますと、アンカーリンクを一通り叩くというので、find_elementsを使って、aタグをごそっと取ってきて、ループさせようかと思ったのですが、1回叩くとページ遷移してしまうので、ループがうまくいきませんでした（ページ遷移したタイミングで、Elementがいなくなってしまうので）

なので、アンカーは別ウィンドウで開いて確認しようという考えになり、SHIFT押しながらクリックしたいなで、ActionBuilder使おうとなりました

使い方

正直、リファレンスそのまま使えば大丈夫なのですが、流れとしては、以下のようになります（今回の場合）

• Elementを見つける

element = driver.find_element(:id,'hogehoge')

# ちなみに、「アンカータグ全部拾う」は
elements = driver.find_elements(:tag_name,'a') # => 配列が返ってきます

• Actionの流れを作って、実行する

driver.action.key_down(:shift).click(element).key_up(:shift).perform

ポイントは、最後のperformですかね。それまでは、ひたすらActionを作っていくイメージで、最後にperformすると作ったActionを実行してくれます。

ちなみに、key_down(:shift)の後にkey_up(:shift)しないと、私の環境ではちょっと変な動きをしていましたので、しておいて方がおそらく良いかと思います。

あと、ページが大きかったりすると、Elementがウィンドウの中に見えていなくて、クリック出来ないということもありました。そういうときには、Actionの中にmove_toメソッドを入れて、そのElementのところに移動してからクリックするなど工夫する必要があります。

補足

過去記事もよろしければ参考にして頂ければ幸いです

genius.hateblo.jp

genius.hateblo.jp

genius.hateblo.jp

Selenium WebDriverの基礎的な使い方

少し前からSeleniumをしばしば触っているのですが、最近社内で初めて使う人向けにQiita:Teamで記事を書いたので、それの転用でブログ記事を書いてしまおうという魂胆になります。

リファレンス

• SeleniumのAPIリファレンス(Ruby)
• Selenium webdriverについてのページ
• 英語ですが、Rubyでの書き方については、Selenium Design Patterns and Best Practicesも参考に出来ます

Selenium Design Patterns and Best Practices

仕組みのイメージ

あくまでもイメージで、正確ではないかもしれませんが、Browserを動かすものとしてDriverがあって、DriverをProgramで動かすことで、Browser操作が自動化できる、みたいに考えています。

program -> selenium-webdriver -> browser

（私は最初の頃、Driverって言われてもピンと来なかったので、Browserを動かす何かのことをDriverと言うことが分かれば捗る人が少しはいらっしゃるのではないかと思ってます）

HelloWorld的なもの

まず、webdriverを生み出します 参考ドキュメント

driver = Selenium::WebDriver.for :firefox

driverを使ってブラウザを操作をします　参考ドキュメント

# 特定のURLにアクセス
driver.navigate.to 'http://genius.hateblo.jp/'

## driver.navigateでNavigationクラスが取得されます。
## Navigationクラスはブラウザ操作と似た感じのことが出来るみたいで、
## 特定のURLに遷移したり、ブラウザバックしたり、というような操作ができます

# titleを取得する
driver.title

# ページのソースを取得する
driver.page_source

# ブラウザを閉じる
driver.quit

もっと色々な操作を行う

これも正確性には欠けるかもしれませんが、ページ内のボタンを押したり、プルダウンを選んだり、というような操作は、以下のようなイメージだと考えています。

driver.find_element -> Element#action

Driverがいるページから、ボタンだったりプルダウンだったり（=Element）を見つけます。そのためのメソッドがfind_elementです。find_elementで見つかったElementに対して、clickなどのElementが持つメソッドを実行して、具体的な操作を行います。

• find_elementはSearchContextというモジュールで実装されていますので詳しくはこちらを参照してください

• find_elementで見つかったElementで実施出来る操作はElementのドキュメント を参照してください

ちなみに、Element自身もfind_elementを継承していますので、一回のfind_elementで特定しきれない要素などを複数回find_elementを実行することで特定する、というようなこともできます

実装例

# ボタンをクリック
driver.find_element(:id,'hogehoge').click

# テキストボックスに入力
driver.find_element(:id,'hogehoge').send_keys 'HELLO WORLD'

# テキストボックスを空にする
driver.find_element(:id,'hogehoge').clear

# ラジオボタンを選択する、チェックボックスをクリックする（elementが特定されている場合）
driver.find_element(:id,'hogehoge').click

# ラジオボタンを選択する、チェックボックスをクリックする（値などでクリックするものを選びたい場合）

driver.find_elements(:name,'hogehoge').each do |element|
  element.click if element.attribute('value') == 'fugafuga'
end

## radioやcheckboxの要素がidなどで特定される場合には、
## そのidでfind_elementしてクリックすれば良いだけです。
## そうではなくて、「値で判断してクリックするものを選びたい」場合などは、
## find_elementsメソッドを使い、いったんradioやcheckboxを構成するelementを一通り取得してしまい、
## それらのループの中で期待する値と同じだった場合にクリックする、というようなことをしています。

# セレクトボックスから選択する
Selenium::WebDriver::Support::Select.new(driver.find_element(:id,'hogehoge')).select_by(:value,'list value1')

## リストの選択は、Selectクラスにelementを渡してnewした後、Selectクラスのメソッドを使って選択などの処理を実施します

補足

重複している内容もありますが、過去にもSeleniumについての内容を書いていますので、そちらのリンクも貼っておきます

genius.hateblo.jp genius.hateblo.jp

システムテスト自動化 標準ガイド CodeZine BOOKS

Windows環境でTurnip+Seleniumの受入試験シナリオを動かす

背景

るびまのエンドツーエンドテストの自動化は Cucumber から Turnip へという記事からすでに四半世紀が過ぎ去ろうとしていますが、私の手元の環境（Windows7 64bit）ではTurnipがうまく動いていませんでした。

原因はこのissueだったりするのかなと思いつつ、色々と試して、結論としては、私のWin環境では、 Ruby 2.0.0 の32bit版インストーラーを入れれば動く という状態でした。

TurnipのためにRubyのバージョンが固定されるのは大変遺憾であると思いつつも、大元の問題を解決する自信もなく、結局しばらく二の足を踏んでいました。

ちなみに、仮想OSを使ってテストすることも考えたのですが、エンドツーエンド試験として、違うOSでブラウザを動かすのがテストとして正しいのか疑問で、実施していませんでした。

この流れの中で、最近ふと、「仮想OSからWindowsのブラウザを動かせば良いのでは？」と思い付いて、実際やってみました、というのが背景になります。

システムテスト自動化 標準ガイド (CodeZine BOOKS)

Selenium Serverというものがあります

SeleniumにはSelenium Serverというツール（？）があって、クライアント／サーバの関係で、クライアント側からサーバ側のブラウザを動かすことが出来ます。

今回は、クライアント側を仮想OS（CentOS）にして、サーバ側をWindows7にすることで、テストシナリオを仮想OS側で動かし、実際のブラウザ操作はWindows上で行う、という環境を作りました。

環境について

当初の目的を達成するだけであれば、単にWindowsと疎通出来るクライアントがいればそれで良いはずですが、社内の環境として、Vagrant + Dockerという環境がすでにあったので、それを利用して環境構築をしました。

ちなみに私のチームは、普段メインの環境がRubyなわけではなく、私が何とかして何かにRubyをねじ込めないかと日々画策している状態なのですが、Docker イメージとしてRuby環境を配布すれば、個々に環境構築する必要もなく、普段メインで使っている環境（Windowsと仮想OS環境の両方）にも影響しませんので、似たような推進活動をしている人にはお薦めです。

サーバ側

• Windows7
• Vagrantを使ってVirtualBoxにCentOSを構築

クライアント側

• CentOS
• Docker
• Rubyをインストールしたimageを作成（Docker Hubから取得しても良のではないかと思います）

Windows上に置いたプログラムソースをRubyコンテナから実行するように設定

• プログラムソースそのものは、Windows上に配置（編集はWinでやりたかったので）
• Vagrant のファイルsyncとDockerのマウント(-v オプション）を使って、WindowsのプログラムとCentOS側のプログラムを同期
• bundle installはCentOS上のRubyコンテナで実施。インストールしたgemのファイルはWinに保存（ファイルsyncされる状態にしておく）

今回はVagrantやDockerについては、あまり深掘りはしませんが、やっていること自体はドットインストールを見ればすぐ出来るような、そこまでややこしいものではないと思います。

今後のTodoとして、プログラムの実行の度にvagrant sshしてRubyコンテナを実行するのも甚だ面倒ですので、Windows側から簡単にDocker経由でプログラムを実行するための何かは作っておこうと考えています。

サーバ側の設定(Selenium)

Javaが実行出来る状態が必要ですので、入っていない場合にはインストールをして下さい。

Selenium Serverのjarがこちらからダウンロード出来ますので、好きな場所に配置します。ダウンロードした場所でコマンドプロンプトから、java -jar selenium-server-standalone-x.xx.x.jar -role hubと実行すれば任務完了です。

IPアドレス:4444という形でアクセスすることになりますので、念のためクライアント／サーバ間で疎通が出来る状態かを確認しておくと良いかもしれません。

クライアント側の設定(Selenium)

クライアント側は、普通にSeleniumを動かす場合とあまり違いはないです。イメージとしては、Driverのインスタンスを作成するときに、リモートを指定してあげればあとは普通に動く、という印象です。

自分のローカルPCにあるFirefoxを動かす場合の書き方

driver = Selenium::WebDriver.for :firefox

リモートのブラウザを動かす場合には、ここをリモートとして設定すれば良いです

リモートサーバにあるFirefoxを動かす場合の書き方

caps = Selenium::WebDriver::Remote::Capabilities.new(:browser_name => :firefox)
driver = Selenium::WebDriver.for :remote, :url => "http://(サーバのIPアドレス):4444/wd/hub", :desired_capabilities => caps

Selenium::WebDriver::Remote::Capabilitiesというクラスがありますので、そこに諸条件を設定してDriverに渡せば、動いてくれます。

より詳しくはリファレンス:WebDriverやリファレンス:Capabilities を参照下さい

こちらの書籍も参照して作りました。（言語はJavaですのでご注意ください）

実践 Selenium WebDriver

Turnipについて

本当は、Turnipについても書こうかと思っていたのですが、冒頭のるびまの記事以上のものが特に書けなさそうでしたので、割愛します。

SEOを学ぶのに検索エンジン最適化スターターガイドはとても良いと思います

背景

社内のSEOチーム（有志の勉強会みたいなもの）に参加しているのですが、最近、Google 検索エンジン最適化スターターガイドの読書会を始めました。

これまではどちらかというと、 ヴェニスアップデートと思われるものが実施されているっぽいですね とか スマホ最適化が遂にページランクに影響するようになった!! みたいな感じで、近々のニュースの共有みたいなことが多かったのですが、それも当然大事なんですが、改めて初心に返ってというか、ちゃんと基礎を理解しておかないと駄目だよね、みたいな流れから読書会をするようになりました。

• 守破離の守
• 型がある人間が型を破ると「型破り」、 型がない人間が型を破ったら「形無し」

という感じで、ちゃんと型を身につけましょうという感じです。

安定のよちよち.rb形式

スターターガイドを読むことまでは決まっていたのですが、具体的な勉強会のやり方について、最初、SEOチームの運営者から相談を受けました。

その時仮で出ていたのが、 毎週範囲を決めて、誰かがレポートを纏めて共有する みたいな、ゼミっぽい（？）やり方や、 順番に講師をやって、教え合う という感じの、教えるのが一番の学び形式のやり方でした。

それはそれで有意義だとは思うのですが、私としては、参加者にSEO知識の浅い人が多いことから、馴染みのある、いわゆるよちよち.rb形式*1が合いそうだなと思い、提案してみました。そうしたら採用してもらえまして、そしてこれが思いの外好評でした。

気軽に聞ける、深く考えられる

勉強会の課題として、どうしても、初学者がこんな基礎的なことを聞いても良いのか、と臆してしまったり、逆に大事なことでもスルーしてしまったり、というようなことがありました。でも、主催している側としては、初学者にこそ学んで欲しいと思っているのに、、、というジレンマがありました。

スコープが限定されて、質問しやすい

よちよち.rb形式の良いところは、まず、扱うスコープが狭いので、逆に話題が出しやすく、質問がしやすいことです。

例えば、スターターガイドの4ページ目は 適切なページタイトルを付けよう ですが、SEOについて質問ある？というより、ページタイトルについて質問ある？と言われた方が、具体的に考えやすくなるので、質問が出やすいです。

経験者も勉強になる

スターターガイド自体は、ひとりで読めば、1時間ぐらいで読めるものではないかと思います。ただ、よちよち.rb形式で読むと、30分で2ページぐらいだったりします。

これは、単に効率が悪い、ということではなくて、普段1人で読んでいるだけでは気付かないような点を誰かが気付いてくれて、それについて考えていたり、それから派生して他の話題を考えていると時間があっという間に過ぎてしまうからです。

そのため、スターターガイドを叩き台として、より深く学習出来ている実感があります。これはスターターガイドという優れた資料とよちよち.rb形式の合わせ技というイメージがあります。

まとめ

半分ぐらいよちよち.rb形式の紹介になってしまった気もしますが、言いたかったことは、改めて読んでみて、検索エンジン最適化スターターガイドはSEOの知識を得るのに優れた資料だという実感を得ました、ということです。

Webに公開されていますし、PDFでも取得出来ますので、1人でサクッと読むのも良いと思いますし、今回のように勉強会の資料とするのも良いかと思います！

いちばんやさしい新しいSEOの教本 人気講師が教える検索に強いサイトの作り方

*1:グループになって、順番に輪読をしていく形の読書会。1段落や1ページなど比較的短い範囲で交代をしていきます。分からないところなどがあれば都度確認していくのですが、その際、横に広がってそれが勉強になったりもします。