いもろぐ

思い立ったら書いていくスタイルで

Design Sprintに対する疑問点の解消

前回のエントリDesign Sprint Night! 参加してきた - 非開発者がプログラム技術を使ったQAを目指すブログ の中で「デザインスプリントに対する疑問点」を書いたのですが、なんと馬田さんに質問する機会があり、回答をいただけました!ありがとうございます!

以下、私はこう理解した、を書きます。(あくまで馬田さんとのやりとりの中で得た私の解釈です)

質問1

DSの効果としてBlueBottoleCaffeとかPocketで「こんな成果でました」という話があるが、これは最初からKPIとして設定していたのか、結果としてこうなったのか(なぜならデザインスプリント(以下DS)のプロセスの中で目標値の設定の話が出てこないから)

  • Blue Bottle CoffeeもPocketも「KPI的な(数値としての)目標設定をしたかどうかはわからない。
  • だけど結果の振り返りができる程度での目標設定はやっておくべき。
  • 効果があったのか、なかったのか、どの程度だったのか、はわからないと意味が無いですよねー。
  • ということはやはりDay1での課題設定の時に「何をどうすることがゴールなのか」をちゃんと決めよう、ということに繋がるんだなと思いました。

質問2

「ユーザーストーリー」というのがよく理解できていない。そのシステム、画面を使って、「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」かな?

  • 「ユーザーストーリー」というワードは明確に「これ!」という感じでは使われていないようです。
  • GoogleVenturesのサイトで参考になるURLを教えてもらいました。

  • ↑これを読んだ私の感想としては当初思っていた「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」というよりも「ユーザーに、どういう行動をしてほしいか」のほうがしっくりくるなと思いました。

  • システムの画面遷移だけでなく、「Creating a new product concept」の時や「Improving conversion rate from a landing page」の時にもストーリーを書くようです。
  • つまりモニタの中の話だけじゃなく、こちらの理想とする「ユーザーの行動(電話をかける、とか、旅行に行く、とかも含む)」を絵(図)に書くことなんだと理解しました。

質問3

Day5でユーザーテストするときはプロトタイピングしたもの。それを本実装するのはいつ?Day5で出てきた課題を解決できたかどうかは再度ユーザーテストが必要になると思うのだけど、そこはまぁ自分たち判断でいいのかな。

  • 本実装への移行は自分たち判断になる。
  • そこに関しての正解があるわけではない。
  • ここでも「本番に反映したあとに測定」して効果を判断することが必要(例えばABテストしてみるとか、単純にBefore/Afterで比較するとか)
  • それにはやはり「ゴール」が必要

質問4

前進している感じがある」のと「やった結果が成果につながる」かは別だと思うのだが、成果になっているのかの確認もスプリント内にあるのかな?

  • ここは「成果」を何であると定義するか、による。
  • Day1 の課題設定に対して、Day4 のプロトタイプを用いて Day5 で仮説検証ができたのならそれは成果になる。
  • 一方で「本番実装した後にわかる定量的な改善結果」に関しては(本番実装自体がDS後のものなので)スコープ外と考える。
  • つまりDSの中では数字にとらわれるよりも、いいと思ったことをじゃんじゃんやってみようぜ、ってことかなと思った。

…というのが私の理解です。この辺りを踏まえた上で来週から社内で1スプリントチャレンジしてみます。


Design Sprint Night! 参加してきた

  • 2015/3/6に行われたDesign Sprint Night! 〜 先駆者たちから聞くDesign Sprint の実際 - connpassに参加したときのメモと感想です。
  • プログラムの話じゃないですけど、最近仕事でこういうのも関わるようになりまして、メモメモ。
  • 本人の発言やスライドの内容をそのまま書いているわけではなく、私の受け取ったイメージで書いてるところもあります。
  • 予備知識として「デザインスプリント」について知るには、まず下記の2つのスライドを抑えておくのがいいです。

私の疑問点

  • この勉強会の話をきいて、私が疑問に思ったことを先に書いておきます。教えて偉い人!

  • DSの効果としてBlueBottoleCaffeとかPocketで「こんな成果でました」という話があるが、これは最初からKPIとして設定していたのか、結果としてこうなったのか(なぜならデザインスプリント(以下DS)のプロセスの中で目標値の設定の話が出てこないから)

  • 「ユーザーストーリー」というのがよく理解できていない。そのシステム、画面を使って、「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」かな?
  • Day5でユーザーテストするときはプロトタイピングしたもの。それを本実装するのはいつ?Day5で出てきた課題を解決できたかどうかは再度ユーザーテストが必要になると思うのだけど、そこはまぁ自分たち判断でいいのかな。
  • 前進している感じがある」のと「やった結果が成果につながる」かは別だと思うのだが、成果になっているのかの確認もスプリント内にあるのかな?

追記:こちらのエントリで疑問を解消できました↓ Design Sprintに対する疑問点の解消 - 非開発者がプログラム技術を使ったQAを目指すブログ

デザインスプリント概要 (Microsoft Ventures 馬田 隆明さん)

  • スプリント=短い時間で区切って、いかに解決していくか

  • 5日目のインタビューをとおして検証する。その結果の学習を活かして、新しいアイディアを回す

  • 背景コンセプト

  • 締め切り駆動開発&制限による創造性
    • 短いタイムボックスでどんどん決める、進める
  • 集団の力
    • 従来のブレストの効果を否定的に見てる。
      • みんなで出すけど、決まったことに関して納得感が薄い、あるいは「結局誰かが決める」
    • DSは「アイディアは個人。意思決定は集団」
  • Art&Fear
    • 「質優先で一個つくる」より「量を優先してたくさん作ったものの中から出てくるもの」のほうが優秀
    • 素早く作って、素早く失敗、そこから学ぶ
  • 5日目にユーザーテストした時に「これじゃない」といういう声が聞けているのは成果だ

  • DSは顧客発見、開発、運用改善、あたりに効果がある(下記スライドのP12)

  • Day1

    • 今あるチームの課題を知る → ユーザーストーリーを書いて、どこにフォーカスするか決める
    • 「どの問題を解決するか」が最重要。課題を全ては解決できないので優先度を決める。
      • これは登壇者みんなが言ってた。ここがズレてると無駄になるって。
    • 小さい過ぎると意味が無い(1人でできるから。みんなで、1週間かけて取り組める粒感…)
    • フォーカスポイントを決める時に、「HEART」フレームワークが有効。課題に対して解決するか、を決める。
  • Day2
    • 発散は個人、決断は集団
  • Day3
    • ユーザーストーリーをつくる。紙でもいい。
      • 画面遷移図とか
  • Day4
    • プロトタイピング。ユーザーに触ってもらえるレベルに仕上げる
      • パワポKeynoteでいい、ってことだったけど、ここパワー使うよなと思った
      • これをDay5でユーザーに見せるので、ここの出来具合によって左右されるところも大きい
  • Day5

    • インタビューの結果、よかったところ、わるかったところ、気づいたところ、を色分けして書き出す(ヒートマップ的に)
    • 30分インタビュー、30分振り返り、そのあと別の人に30分インタビュー、、、の繰り返し
    • 1人がインタビュー、もう1人がメモ役。
      • 操作しているところを録画する、画面キャプチャする、とかもありそうだが手間かかるよね
    • 結果のメモを付箋に書いて張っていく → 学習が進む
    • 課題が出てくる → 優先度が必要 → Day1に戻る
  • 上記が基本だけど自分たちにあったプロセスに変えてく

    • その後のセッションで数社の人の話があったけど、どこも「集まる人」とか「投下時間」は自分たちなりに変えていた
    • 確かに通常業務がある中で5日間フルで拘束する、は厳しいよね...
  • DSは全ての問題を解決できるわけじゃない

THE GUILD 深津 貴之さんの話 

  • 大事なこと

    • 部署をまたいでいろんな人を呼ぶ
    • 作業を時間で区切る
    • 個人ワークとグループワークを高速で回す
  • Googleでは「お試し」として5日間ではなく、2時間でやるプランがある

    • 5日版は全方向から情報を共有
    • 2時間バージョンは、5枚の仮想ペルソナが設定してあってその人の1人に対して何かする
  • 発散

    • HMWの精神
      • How might we?「我々はいかにして解決できるか?」
      • 「どうせできない」という否定的な考えを排除する
    • Crazy8
      • 元はGameStormingの6-8-5の手法
    • アイディアの共有では「YES AND」で答える。他人の意見に上乗せする
    • DotVote アイディアの温度感がでる。最終決定者はいる。半民主主義みたいな感じ。
  • 決断

    • バトルロイヤル(複数の案をもっと練ってから決める) or ベストアイディア(この時点で「これだ!」を一点決める)
  • 試作

    • 個人で画面遷移(とは限らないけど)をつくる
  • 評価

    • 2時間のワークショップではユーザーインタビューの代わりに1分間のプレゼンをした

スプリントの長所

  • 最初から全員を巻き込める
  • ステークホルダーからの多角的なアイディア
  • (関係者の思いの)全体を俯瞰できる
  • 民意を把握しつつ責任が明確になる(合意形成)
  • →軸がぶれない、政治でひっくり返らない
  • エース不在でも、安定して85点を出せる手法

有効に機能しないケース

  • メンバーに突出した人がいるとその人に任せた方がいい(権限の集約)
  • 自分の意見を通したい人がいる
  • 思ってるより重い。スケジュールの確保とか。軽くする工夫どころが重要
    • 全員が参加するだけの重要度が高いところだけやる工夫
    • 参加出来ない人には決まったことに対して意見できないくらいの権限委譲をしてもらっておく
    • 意思決定に高度な専門知識が必要なもの(新薬とか統計とか)←いろんな視点からの意見を持ち寄れる
  • 最低条件
    • スプリントの対象(何を改善したいのか)が的確
    • 意思決定者から現場まで巻き込む
    • フラットな立場で意見いえること
    • 何度も繰り返すこと

こういう時は有効

  • 全員が初めて会って思い・価値観がバラバラ
  • 各人が何を考え、何を大事にしているのかわかる
  • チーム内に声の大きい人がいる
  • 後半に入ってきた人がひっくり返されることがある
  • ボスの権限できまるかつ打率が低い

まとめるとこんないいことがある

  • 俯瞰することで、ミスをなくす、
  • 全員の共通認識で進められる
  • 政治的にひっくり返されることをなくすために最初に合意できる

  • デザインスプリントの記事を翻訳している

ここでワークの時間

  • 「ビルの入り方」の改善をテーマにCrazy8をやる
  • 背景
    • ヒカリエに入る時に名刺出したり、名前やIDを申告したりして大変
    • もっとラクに入館したい
    • とはいえセキュリティも大事
    • これを解決するようなアイディアを8つ上げる
  • やってみたが7つしか埋まらなかった…
  • これだけじゃ何のことやら、ですよねw f:id:sakaimo:20150306123425j:plain

  • ワークはここまで。以下、感想

    • 35秒というなかで絵に書くって、慣れないと大変。でも楽しい。
    • その後のススメ方として
      • 自分で書いた中で有力案3つくらいを人に見せられるように清書するみたい
      • 全員分張り出す
      • Voteする

DeNA 坪田 朋さんの話

  • なぜDSか?
    • アジャイルスクラム、リーンUX、、、いろいろ試してる
    • DSは「アウトプットがある状態で議論/評価する」ので一番早く進行する
  • 過去の課題
    • ビジョンは分かったが、具現化フェーズで詰まる
    • 特定の人(UI担当者とか)に負荷が集中する
    • 思考フェーズが長いとスケジュールが押す。やり残したままリリース
  • 作って、壊して、評価して、を超高速で回したい(半強制的に)

  • こんないいことが

    • アイディアの具現化からユーザーテストまでが一連の流れになっていて、ゴールが現実的
      • 時間が長い、プロセスが長いと論理破綻がしない
    • 短い時間で可能性を出すような設計→全てのプロセスが高速に進む
      • 知恵を「ひねり出す」のに体力は使うが、早い。
    • 複数のブレストより、1人で考えた案を持ち寄るほうが質が高い
      • サイレントクリティーク
    • 意思決定者を中心にベストなデザインを決定するルールになっている
      • 意思決定をしたことの納得度
    • ???もう一個あったけど聞き逃した
  • やってみると疲れる
  • やりきった感、前進してる感がある
  • エンジニア、企画の人、が中心になるといい

サイバーエージェント 大塚 敏章さんの話

  • なぜDSか?
    • ブレストで意見がまとまらない
    • 結局、限られた人で集まって決める
    • エンジニア、デザイナー、プロデューサーの思いや大切にするモノ、違う時間の使い方、ユーザー像が違う
    • それで「ユーザーの事を考えて」作っていけるのか?
    • みんなが譲りあって、曖昧になる
    • 自分のアイディアも捨てきれない(採用されても思ってたんと違う)
    • これまでの手法ではユーザーテストは終盤

坪田さん、大塚さんの対談

  • DSにファシリテーターは必要か?
    • チームメンバーの誰か、でもいいと思う
    • ただ、始めの何回かは馬田さんのようにプロセスに慣れた人がいた方がいい
  • ムズカシイところ
    • いっしょにやる人に理解してもらうところ。
    • デザイナ以外は絵を描くとか苦手
    • それを促す雰囲気作り
    • 時間の作り方。特に運用している案件に対するスプリント
    • 集まった情報に対する個々人の理解度、専門性が高いとやりにくい
  • 実際は?   O:5日でやってみた。が、次の週また5日拘束、とかは厳しい   T:新規案件の時は5日でガッツリ。
    • とはいえ運用案件は全員フルコミットはムズカシイので、フレームワークは使いつつも、必要な人でやる
  • ファシリテーターはどの立場の人がいいか?
    • T:意思決定者に近い人はしないほうがいい。明るく場を和ませることができる人
    • O:中立的な人。決定者はちがう。
    • T:得手不得手はあると思うので、全員が回せるようになる、がいい。だれでもできる
  • 大手企業ならではの導入しにくさ
    • 採用までに政治で一苦労、とかあるらしい
    • プロセスを可視化して共有する、のは大事。
    • プロデューサーが数字しか見てないことがある。一回でも巻き込むと印象、意識が変わる。
    • デザイン、てついてるけど、デザイナーがやるとは限らなくていい
    • 「やって意味あるの?」に対しては「5日でデザインできてユーザーテストもできる」という返しは有効。
  • オリジナルに忠実?変えてる?
    • 試作を全員でやる、は重いので、出来そうなメンツでやっている
    • 最初はフレームワークにそってやってるけど、次第に「ここはデザイナとエンジニアで」とかやってる
  • スプリントが終わった後のレビューはやってるか?
    • やっていない。ひたすら作る。レビューは評価の中で。それを活かして次にやる
    • 繰り返しやっていく中でアイディアが固まったら分業になっていく。そこの切り替えしがムズカシイ
  • 社内の反響は?
    • そんなに浸透してないw ブログ書いて外から評価されてると中でもやりやすい。
  • 偉い人からの理解
    • O:事業責任者がいっぱいいて、その人が事業をやるときに「DSっていうのがあるんだけどやってみない?」っていって広めてる
  • エンジニアの人たちの巻き込み方は?コードを書きたがると思うのだが・・・
    • 新規のときはやりやすい
    • やってみるとエンジニアの感想もいいものになる
    • なんでこのデザインになったのか、がわかる。
    • 特にUIがなんでこうなってるのか、あるいはUIを作るまでの経緯(の大変さ)が考えられるようになる
    • プロセス自体が面白い。UIを一緒に考えられる。オーナーともデザイナともシンクロできる。
    • UIのプロセスがエンジニアはよくわかってない、が解消される
  • やることになって、工数見積もったら間に合わない、的なこと
    • 結局やれといわれるのかよ、的なことになりがち
    • 品質を求められるときはスケジュールを動かす
    • 期間内に成果をだす、は求められる

ココナラ 新明 智さんの話

  • スタートアップに大事なこと=Issue(ユーザー課題)を特定、解決するための多様な観点がある
  • プロトタイピング(を元にして下記が生まれる)

    • concept
    • communication
    • improvement
  • タイムボックス

    • 時間をかけるほど壊しにくくなる。愛着がわく
    • 100%のものではなく、70-80%をどんどん出していく
  • ユーザーテスト
    • 出す前に触ってもらう
    • 意図通りかどうか確認できる
  • これを繰り返す(Iteration)

  • 苦労したこと

    • ユーザーテスト協力者の確保
    • 課題の収束のコントロール
    • 意思決定者を長い間拘束できない

Standard Inc. 鈴木 健一さんの話

  • サービス全体として
    • 誰の、どんなことのために作るのか
    • どのようにつかわれるのか、使ってほいのか
    • どうすれば利用者、事業者にメリットがあるのか

新明さんと鈴木さんの対談

  • スタートアップにとってデザインは重要
  • いろんな観点の人を巻き込むか(ユーザーのことを知ってるのはCSの人だったりする)

  • DSはスタートアップに対して効果はあるのか?

    • 中にデザイナがいないこともある
    • 何をしたらいいかわからない
    • 短期間で発散と収束ができるのは有効
  • プロダクト製品(組込みなどH/Wがあるものとか)にも適用できるか?

    • スプリント中にプロトタイプができるもの、なら実践できる
    • 作って試してもらう、というのが重要
  • 一体感は?

    • チームとして何が課題で、どう解決するか、がわかっているのでその後の話がやりやすい
  • ダメだったところ

    • Day1での共通認識が取れなかった
    • 課題の設定をミスるとだめ。1週間かけてやることか?と
    • 学びたい範囲をはっきりさせる(KPIが明確、とか。それを上げるにはどういう選択肢があるのかとか)
  • インタビューイの集め方

    • 代々木公園で話しかけることもあった
    • 1周目が大変。2周目は集めやすくなる
    • 協力者に協力してくれる人を聞く
    • ユーザーテストを常に回してないと集めにくい
    • FBの友達経由が多かった
  • ユーザーテストする歳に、どれくらいペルソナに近い人を集めたのか

    • 実際は外れた人もいた
    • ココナラ:年代と性別は重視(サービスによって変えるんだろうな)
    • ココナラ:自分たちのサービスを知らない人(というターゲットだったのでここは意識した)
  • スタートアップならではの難しさ

    • 人数が少なくてみんなでやってる、事業には向いている
    • 分業になってくる(13人位?)になってくるとやりにくいかも
    • 時間拘束はされるので大変
  • 何を課題にするか、は大事。ハマるもの、ハマらないものはある。

  • Day1で問題意識とか、ギモンを解消させるのはものすごく重要

まとめ

  • 会社、文化にあったスタイルに変えていく

RSpec、Capybaraのお勉強中

このところ、Qiitaの@jnchitoさんの記事を見ながら。RSpec、Capybaraを勉強しています。 何がすごいって、この方の記事がものすごくわかりやすく、いい感じでまとまっていて初学者にとっても優しい感じなのです。

Ruby - 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita シリーズ

RSpecの入門とその一歩先へ ~RSpec 3バージョン~ - Qiita シリーズ

RSpecもCapybaraも進化していて、何も考えずにGoogle先生に聞くとバージョンの古い記事がHITしてしまって困ったなーと思っていた時に出会ったのでとてもありがたいでございます。

そもそも本職プログラマではない私が無理くり「テストコード書けるようになりたい!」ってやってるので、Rubyで :name の「:」って何よ!?みたいなこととか調べつつやっております。休みの日もあれこれ楽しみで調べては動かしてみてます。とはいえ、早く実戦で使えるようにならないとな。

Ruby on Rails の基礎編終了

年明けから始めていたドットインストールのRails講座、ようやく完了。 初心者のとっかかりとして、このサービスはピカイチだと思う。(他のサービスを使ったことないから比較できないけど)

動画を見ながら、もちろん自分でも書いて動かしてみて、なんだけど一回やっただけだと絶対忘れるし、わかんないところを調べて記録に残しながらやってたので、1レッスン3分なのに、30分くらいかかったりもした、、、まぁ今は時間かかるのはしょうがないと思ってます>< 早く慣れて勘所を掴みたい。(困ったときの調べ方とか)

ドットインストール - 3分動画でマスターする初心者向けプログラミング学習サイト

これでひと通り * SeleniumWebDriver * Rails * RSpec

のホント基本的なところはわかったつもり。 ちょうど社内案件のちょうどいいのがあるので、それをローカル環境(会社のPCね)で動かしてみて、そこにテストコードを書いていく、というのをやる。

っていうところにきて、このプロジェクトはCapybaraでテストが書かれてるみたいなので、ひとまずここにテスト追加できるようになろう。

書籍「実践SeleniumWebDriver」のPageObjectパターンをRSpecでテストコードにしてみた。

このブログは2014/1/1から始めましたが、丸1年経っていったい何ができるようになったんだと。「非開発者がプログラム技術を使ったQAを目指すブログ」って言ってるけどお前ホンキで目指しているのかと。

なんて思いながら新年を迎えてしまいましたが、「Qiitaは「プログラミングに関する知識を記録、共有する最適なサービス」です。」ってことなので、そっちに乗っかってみようかと思いました。あは。

ということで、前回の続きはQiitaで。

書籍「実践SeleniumWebDriver」のPageObjectパターンをRSpecでテストコードにしてみた。 - Qiita

RSpec: beforeで詰まった(itの中から見えるもの見えないもの)

ディレクトリ構成

E2Etest
 └ pages
   └ admin_login_page.rb
 └ spec
   └ test_spec.rb
# admin_login_page.rb
class AdminLoginPage
  def initialize(driver)
    @driver = driver
    @driver.get("https://xxx.wordpress.com/wp-admin/")
  end
~後略~
# test_spec.rb
require 'selenium-webdriver'
Dir[File.expand_path("../../pages/", __FILE__) << '/*.rb'].each do | file |
  require file
end

describe "ログインして書いて編集して削除するシナリオ" do
  @driver = Selenium::WebDriver.for :firefox

  it "正しいID/PWでログインできること" do
    # ログインページでログインする
    @login_page = AdminLoginPage.new(@driver)

    # loginの戻り値は AllPostsPage
    @all_posts_page = @login_page.login

    # 今回はtitleに「投稿」という文字列が含まれているかで比較
    expect(@driver.title).to include "投稿"
  end
end

を実行すると下記のようなエラーになる

:spec sakaimo$ rspec test_spec.rb 
F

Failures:

  1) ログインして書いて編集して削除するシナリオ 正しいID/PWでログインできること
     Failure/Error: @login_page = AdminLoginPage.new(@driver)
     NoMethodError:
       undefined method `get' for nil:NilClass
     # /Users/sakaimo/mydev/selenium/E2Etest/pages/admin_login_page.rb:5:in `initialize'
     # ./test_spec.rb:13:in `new'
     # ./test_spec.rb:13:in `block (2 levels) in <top (required)>'

Finished in 0.00099 seconds (files took 2.96 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./test_spec.rb:10 # ログインして書いて編集して削除するシナリオ 正しいID/PWでログインできること

admin_login_page.rb の initialize に渡される driver が nil みたい。

# test_spec.rb
require 'selenium-webdriver'
Dir[File.expand_path("../../pages/", __FILE__) << '/*.rb'].each do | file |
  require file
end

describe "ログインして書いて編集して削除するシナリオ" do
  before do #←ここ!
    @driver = Selenium::WebDriver.for :firefox
  end

  it "正しいID/PWでログインできること" do
    # ログインページでログインする
    @login_page = AdminLoginPage.new(@driver)

    # loginの戻り値は AllPostsPage
    @all_posts_page = @login_page.login

    # 今回はtitleに「投稿」という文字列が含まれているかで比較
    expect(@driver.title).to include "投稿"
  end
end

で解決しました。

  • 元のコードでは@driverはitの中からは見えない、ってことなのかな。
  • beforeは「exampleの実行前に毎回呼ばれる」からitの中でも見える、ってことなのかな。


ruby: まとめてrequireする

前回↓

書籍「実践SeleniumWebDriver」のPageObjectパターンをRubyでやってみた。 - 非開発者がプログラム技術を使ったQAを目指すブログ

の課題を解決したい

  • ruby 2.0.0p481
  • mac OS10.10.1


E2Etest
  └ pages
    └ add_new_post_page.rb
    └ admin_login_page.rb
    └ all_posts_page.rb
    └ delete_post_page.rb
    └ edit_post_page.rb
  └ test.rb

という構成( 前回と少しディレクトリ構造を変えています)で、test.rbに

#test.rb
require File.expand_path(File.dirname(__FILE__) + '/pages/add_new_post_page')
require File.expand_path(File.dirname(__FILE__) + '/pages/admin_login_page')
require File.expand_path(File.dirname(__FILE__) + '/pages/all_posts_page')
require File.expand_path(File.dirname(__FILE__) + '/pages/edit_post_page')
require File.expand_path(File.dirname(__FILE__) + '/pages/delete_post_page')

って書くのが大変だなという話。


Rubyで指定ディレクトリ以下のファイルを全てrequireする方法 - くろの雑記帳

にまさにドンピシャな内容が書かれていたので参考にさせていただきました。

Dir[File.expand_path("../pages/", __FILE__) << '/*.rb'].each do | file |
  require file
end


以下、自分メモ

File.expand_path('相対Path', __FILE__)
  • "FILE"(現在のファイル。この場合test.rb)を基準として'相対Path'の位置にあるファイルの絶対パスを文字列で返す。
  • ってことは test.rb からみて "../" が "E2Etestディレクトリ" を指すので、結果として
E2Etest/pages/*.rb

のファイルがrequireされる、と。

こちらも参考にさせてもらいました

Rubyを知ろう

RubyのFile.expand_path('相対パス', __FILE__)の意味 - maeharinの日記