【勉強会】VP of Engineering Meetup by CA #2 に参加しました

CTOというのは何となくわかるものですが
VP of Engineering（以下、VPoE）とはどういう役割で何をやるのか？
ということがわからないままでした。

そして、今の自分がやっていること、やりたいことはVPoEなのではないか？
という考えもあり参加することになりました。

申し込みした時期が遅く補欠でしたが無事に繰り上がり当選しました。

概要

cyberagent.connpass.com

内容

イベント趣旨説明

まず、参加者全員で「VPoEとはどういうものか？」というのを定義しました。 以下、メモした内容です。

素晴らしいマネージャーであり、偉大なチームビルダー
優秀なリクルーター、素晴らしいコミュニケータ、大きな問題解決者となる
エンジニアとしては、エンジニアリング組織を全員を成功させ、道を切開ること

CTOはTechに特化しているのに対して
VPoEは採用、育成、評価などを含むエンジニア組織全体のパフォーマンスを最大限出せるようにする

スライドにも書かれていましたが、VPoEの役割は組織全体に対してであり
手広くカバーをしなければいけない役割だと思いました。

スライドの内容が開催ブログに上がっていました。

developers.cyberagent.co.jp

『組織フェーズにおけるリーダーシップの変革』

speakerdeck.com

ベンチャーに近い状態の組織に参画して、そこでどうやったか？という話でした。
自分の立場上、こちらの内容が1番身近に感じられました。

以下、メモした内容です。

最初はエンジニアリーダーで、徐々にエンジニアリングマネージャーとなった。

組織コンテキスト
組織フェーズとリーダーシップ
エラスティックリーダーシップという本がその通りの内容。

・サバイバルフェーズ：めいれいさせろ
とにかく技術的負債をなんとかする
・アラートメールがたくさんくる
・デプロイフローなし
など

負債払拭のため合宿も行った。

負債払拭のまとめはスライドがあるためそちらを参照。

失敗談として、専門外は自分でもどうこうできなかった
なので、優秀な人を味方につけてやってもらった

・学習フェーズ：いろいろやろうぜ
エンジニアとマネージャーが揺れ動いたがマネージャーに注力した1年にした。
井の中のカエルにならないために他の会社の人とあったりもした。

ストレッチゾーンに導くミッション設定
・コンフォートゾーン
・ストレッチゾーン
・パニックゾーン
があり、うまくストレッチゾーンに導いてあげることにしていた。

目標設定ぐるぐる共有会
オフラインで目標設定をして、1つの目標を書いて
メンバー全員にコメントをもらう。
→ブログにまとまっているのでそちら参照

失敗談は1on1をまとめて3時間やっていた。
1on1は聴くなどとても集中力を使う場になってしまった。
毎日1人30分に変更した。

・自己組織化フェーズ：オーナーシップをだいじに
権限移譲をした。
推進責任者をしてリーダー以外にもオーナーシップを持たせる
チームのアイデンティティ強化してチームの中でミッションを持つ。

権限委譲はDelegationBoardを使ってやっていた。

よく言っていたのが「あなたのチームの組織フェーズはどこだろう？」ということ。
各チームにとってはまだまだなところもあるので、言語化していき意識させるようにした。

失敗談はエンジニア組織のことばかりに目がいってしまった。
組織全体を考えたアクションを実施できていなかった
　エンジニア組織だけ良い状態でも意味がない
　ビジ、テク、デザでシナジーを生むようにしている

まとめ
組織は生物で日々変化する
組織フェーズに合わせた、リーダーシップの柔軟性が求められている。

『チームビルディングの技術』

チームビルディングの技術(Fix) from Takahiro Ogoshi

www.slideshare.net

エンジニアという立場ではないが、目線、やり方は1番インパクトがあった内容でした。

以下、メモした内容です。

ビジネスサイドのVPofE
20 〜 30人になったら他にチームを渡すような感じ。

チームビルドはワークさせるだけじゃない。
別のスライドに採用に関することが詳しく書かているのでそちら参照。

既存チームメンバーと合わない人はいれないのは当たり前だが
給料テーブルで合わない人も採用しない方が良い。

経営情報を共有することにより目標設定を設定しやすくなる。
また、自走する人が現れる。
ネガティブなこともできる限り伝えたほうがプラスに働くことが多い。
ビジョンでひっぱってもいいがビジョンは劇物なので、売上ベースが良い。

1on1は最初にたくさん聞いて、その人の問題点などを解決してあげることが大事。
その人が考えてること以外のアドバイスをしても意味がないし、聞いてもらえない。

まず、期待していることを伝える。

課題の解決と解消は違うので間違えないようにすること。

1on1は全メンバーに画一な面談をしなくてもよい。
飲みに行ったりしている人がいたらそれでOK。また同じゲームをやっているメンバーとか。

イグジットマネジメントでは
退職と異動でチーム力を落とさないことを念頭に置くこと。

ミスマッチな人が離れることはポジティブなこと。

絶対に出さない！というのはデメリットである。
属人化はマイナス要素になる。

NPSを取ったほうがいい。

無責任な離職や異動は怒るべき。

また出戻り組は貴重な採用ソース。

キーマンの退職は退職の連鎖を防がないといけない。
メンバー層を個別にケアをする。

※自分用メモ：スライドはいい話ばかりだったので、後で読み返すこと

『変革、組織づくりに責任者がまずやるべきこと』

www.evernote.com

こちらの発表もかなりインパクトがある内容でした。 徹底したやり方に凄みを覚えました。

以下、メモした内容です。

エンジニア120人レベルの会社
合宿でエンジニア全員と1on1を実施
　自分の略歴を書いて、相手に対して聞きたいことをすべて見せて話した。

定例や意思決定を特になにも言わず参加した。
　何をするか決める前に以下のことを実施
　　組織に対してのいいこと悪いことをすべて出す。
　　カテゴリ化
　　カテゴリを解決方法を洗い出す。
　　解の候補が解決できるインパクトと労力で優先付け
　　1年、半年、3ヶ月がどんな状態になるかを定義する
　　3ヶ月の細かい計画を立てる

　洗い出しのときは、できていることも上げていく
　わかりやすいワードでまず浸透第一にする
　1つの軸に対して3つのカテゴリにしてアクションを決めていくとやりやすい。かつ浸透しやすい
　やりたいことをとにかく言い続ける。またかというくらい言い続ける

変えるときは空気を読まずに変える。調整よりも変化の抵抗からの火消しが楽。
ボトムに合わせるのではなく、Topに合わせてそれがカッコイイと思うように。
自分を信じてやる。
行動してくれる理解者は抜擢する。変化をマジョリティにしていく。
全部は見れない。しばらく赤点にならないところは放っておく。

面談時
どんなに熟慮しても何だかんだ結論は決まっているから伸ばさない
スキルではなく、ノウハウだけで仕事しているケースは今後伸び悩む旨を危機感を与える対話をちゃんとする
エンジニアの行動で注意するところはちゃんと注意する

計画時
べき、ねばならないだけしか洗い出せてなければまだ足りない。できていることもちゃんと出す。
最適解だけを求めてもイレギュラーに弱くなる。解の候補をどれだけ持つかを意識して手札を充実させることを意識する。
アウトプットにより生まれるストーリーを考える
ストーリーを作るために必要なアウトプットを考える。
ルールを作るのは最終手段。期待にそれたらかっこ悪いという状況をどう作るかに注力して考える。

実行時
自分の報告が同じフォーマットこなすだけになって来たら変えるタイミング
報告受ける際、アップデート特になしの報告メンバは問題あり
ツール導入も人が重要で理解できていない場合アナログにまずやることを考える
ゴールさえぶらなきゃやり方はどんどん変化して問題ない。
3ヶ月に1回は最低振り返り、洗い出しをやる。
※途中書き漏れた
マイナスを０にした場合、前よりいいからと安心するメンバが出てくるから気をつける

全体を通しての感想

このような勉強会（Meetup）は答えがなくマネジメント寄りなところがあります。
なので、結構胡散臭い部分が出てくると思い価値ですが、VPoEとしての
役割や目線、課題などが参加者全員が一致していたようで
下手なものよりも充実していて、とても濃い内容でした。

また、今回のMeetupで聞けなかったこともいくつかあり
アンケートには書いたのでその辺も次回聞ければいいなと思います。

なお、次回開催も前向きなようで今後参加者も増えると予想されるので
今後も毎回参加して知見を得て共有していければと思いました。

ツイートまとめ

twitter.com

【雑記】今年の振り返り

まだ2017年が続くんじゃないか？と思うぐらい仕事をしていますが
今日でもう終わりと思うと昨年以上にあっという間の1年でした。

さて、今年を振り返ります。

今年の振り返り

部署異動

今年が始まり数ヶ月経ったころに部署を異動しました。
転職とは違いましたが、初めて出会う人たちと仕事をすることに
なるので最初はどうなるかと思いましたが、楽しく仕事を行うことができました。

出向

部署異動した後、諸事情になりグループ会社へ出向することになりました。
現在、出向先でサーバーサイドとクラウドインフラをやっています。
ちょこちょこ顔が出ているので知っていると思いますが、いろいろ聞きたければ
連絡をお願いします。

システム開発

Ruby on Railsでのシステム開発

異動した部署、出向先もAPIをRailsで開発していて
それに携わることになりました。

仕様の理解とRubyの柔軟性にかなり苦労してしまい
一人前にまだRubyでご飯を食べられるような状態ではないことを
今年1年で痛感しました。

AWS, GCPに携われた

そんなにガッツリ！というほどではないですが
携われたことはとても大きく今後に繋がる内容だったと思います。

コンテナ技術

「仮想マシンで十分だろう」と数年思っていたのですが
コンテナ技術を覚えなければならず、現在進行系でやっています。
Docker自体はそうでもないかな？と思ったのですが
Kubernetesを使うとかなり便利で使えるものだと実感させられ
来年はこの辺の知識をインプットしていければと考えています。

ブログ

実はこのブログ、月1で記事を書こうという目標があったのですが
結局、10 〜 11月は書くことができませんでした。

アウトプットを意識してのインプットができていなかった
時期だと思うのと良いインプットがなかったのでは？と反省です。

反省をしつつ来年は短いサイクルで振り返りを行い
意識して良いインプットをしつつ良いアウトプットを出していこうと思います。

プライベート

ウイスキー

今年の2月ぐらいにウイスキー検定3級を受けて無事に受かりました。
来年もあるのですが、ちょっと仕事方面に力を入れようと思うので
次、受けるのは再来年です。

ただ、来年はいろいろな種類のものを飲んで知見を広げるべく
1杯から飲めるところを巡ってみようと思います。

ゲーム機

3DSを買い換えることはあっても据え置き機はPS3を最後に買ってませんでしたが
今年は「Nintendo Swith」「PS4」を購入しました。

メジャータイトルはやりましたが、どれも中途半端に止まっている状況です。
せめてゼルダのエンディングだけはちゃんと見みます。

あ、PS4はモンハンワールドのために買ったので同じ人がいましたら一狩り行きましょう。

グラブル

昨年に引き続きグラブっておりました。
去年と同じように毎日コツコツとやっており中くらいのプレイヤーにはなったかな？
と思っていますが、ガチャは恐ろしい！

総評

仕事関連でいうとまさに怒涛の1年でした。
また、プログラマとして技術力がまったくついていっていないと
痛感する場面が今まで以上にあったのでマネジメントはやってきたので
来年は技術力アップを目指してやって行こうと思います。

後は、何事にも自信を持てる度胸を持つことです。

【Ruby】define_methodについて調べました

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、ライブラリの挙動を確認していたところ
define_methodが書かれており、復習も兼ねて調べました。

環境

• max OS X Sierra
• Ruby 2.4.1

前提条件

• irbかPryが動作すること

やり方

define_methodに関すること

実行

[1] pry(main)> class Animal
[1] pry(main)*   { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[1] pry(main)*     # 動的にクラスやモジュールを定義でき、defによるメソッド定義をしなくてもよい
[1] pry(main)*     # メソッド本体はブロックで記述する
[1] pry(main)*     define_method(name) do
[1] pry(main)*       message
[1] pry(main)*     end
[1] pry(main)*   end
[1] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[2] pry(main)>
[3] pry(main)> puts Animal.new.cat
にゃー
=> nil
[4] pry(main)>
[5] pry(main)> class Animal2
[5] pry(main)*   { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[5] pry(main)*     # ブロックにブロック引数を加えるとブロック引数がメソッドの引数になる
[5] pry(main)*     # ブロック引数：name
[5] pry(main)*     define_method(name) do |num|
[5] pry(main)*       message * num
[5] pry(main)*     end
[5] pry(main)*   end
[5] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[6] pry(main)>
[7] pry(main)> # メソッドの引数：2
[8] pry(main)> puts Animal2.new.dog(2)
わんわん
=> nil
[9] pry(main)> class Animal3
[9] pry(main)* end
=> nil
[10] pry(main)>
[11] pry(main)> { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[11] pry(main)*   # ブロックをオブジェクトとして定義する
[11] pry(main)*   proc = Proc.new { |num| message * num }
[11] pry(main)*   # class_evalは、ブロックをクラス定義やモジュール定義の中のコードであるように実行する
[11] pry(main)*   # ブロックの戻り値がメソッドの戻り値になる
[11] pry(main)*   Animal3.class_eval { define_method(name, proc) }
[11] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[12] pry(main)>
[13] pry(main)> puts Animal3.new.cat(3)
にゃーにゃーにゃー
=> nil

まとめ

defでメソッド定義しなくてもメソッドを定義するという
初見殺しな面もありますが、メタプログラミングをする上で
扱うものの1つだと思うのでしっかり覚えておきます。

参考資料

define_method (Module) - Rubyリファレンス

【アジャイル】アジャイル(スクラム)をやり始めて5ヶ月ほど経ったので振り返る

はじめに

本エントリーは以下の続きです。

fujiyasu.hatenablog.com

fujiyasu.hatenablog.com

前回のエントリーから今まであったこと

• プロダクトオーナー（以下、PO）が交代
  • POが認定POを取得
• スクラムマスター（以下、SM）が交代
  • SMが認定SMを取得
• チームが成熟されてきたときに起きたこと
  • プロダクトバックログリファインメントの改善
  • スプリントレビューの改善
  • T字型人材への促進
• スクラムオブスクラムが始まる動きがある

簡単ですが、こんなところでしょうか。
それでは詳しく書いていきます。

プロダクトオーナー（以下、PO）が交代

前回のエントリーで

POがいない問題

というのを書きました。

前のPOも問題詩しており、解決策として
プロダクトに近い立場の人を新POにしました。
ただし、人が変わるということは会話の内容が変わってくるため
最初は認識合わせすることにかなり苦労しました。

しかし、開発をしていくごとに改善してきて
会話できる時間や量も増えて、スプリント中でも
スムーズに意思疎通をすることができるようになりました。

なお、この前後にPOは認定POを取得しており
POとしての基礎固めはできている状態となりました。

スクラムマスター（以下、SM）が交代

前SMが築き上げてきたものを筆者が引き継ぎ、新SMとなりました。
POのときと同様にそれぞれ認定SMを取得した状態です。

交代した理由は「認定SMを取得したのでやってみる」というのも
ありますが、もう1つの理由は「SMは思っている以上に大変」ということだと
思います。
常にチームを観察して、正しい方向に導き細かいタスクをやらなければならないので
1つのことに集中する以上に労力を使う立場です。
そのため、ずっとSMは現実的に難しいと思うので交代はありだと考えています。

また、前回のエントリーで

すでにローンチ済みのサービスのため、本番の調査依頼などが入ってくる

というのを書きましたが、POがすぐに対応できない場合
SMとして間に入ってSMがまず調査をすることにしていました。
どうしてもわからない、時間がかかる場合はPOに相談して
開発チームのリソースを使うということをしました。

チームが成熟されてきたときに起きたこと

プロダクトバックログリファインメントの改善

改善点

1. 一つのストーリーに費やす時間が多かったのでキッチンタイマーを導入して10分の制限を設けた。
2. 議論が白熱した際、SMが間髪入れず間に入って状況を整理する。
3. リファインメントでは詳細な機能の話はしない。詳細に考えなければいけないのを含めてポイントを出す。
4. 毎日1時間やっていたリファインメントを週にまとめて2時間にして効率化を目指す。

上記のおかげで今までストーリーポイントすらなかった状態が
見積もりされたバックログがある状態となってきました。

スプリントレビューの改善

改善点

1. スプリントレビューのやり方を調べてチーム展開して、共通認識を行った。
2. 大きなモニタを使って全員で画面を見れるようにした。
3. 離れた場所から参加する人がいたので、TV会議システムを使い同じ画面を見れるようにした。

スクラム以外でもレビューというのは行ってきましたが
全員集まってレビューというのは勝手が違う感じがしたようなので
最初は戸惑いもあったようですが、改善をした結果確かな手応えを
チーム全体で感じられたようなので良かったです。

T字型人材への促進

開発メンバーは、それぞれ得意分野というのがあり
そちらを伸ばして行く人が多い感じでした。
しかし、それだけでは属人化してしまうため一部のメンバーだけですが
ペアプロを実施していくようになりました。

現在進行系でやっていましたが、とても効率的であり
楽しくプログラミングをやっている印象を受けました。

スクラムオブスクラムが始まる動きがある

実は、別のチームでスクラムをやっているところがあり
それぞれのチームの知見を共有しようという話になってきました。
チームの文化というのは同じスクラムでもまったく違うので
お互いノウハウを共有していければと思います。

この辺は。また展開があったときに書きたいと思います。

まとめ

本当はもっとあったと思うのですが
詳しく書いてしまうと、それぞれの内容で1つのエントリーに
なってしまうレベルなので簡単に書きました。

スクラムチームとなって3ヶ月以上が経って
そろそろ半年になるにあたり、成熟度も増してきたので
今後、さらに良いチームになっていくと思います。

最後にSMとなって、参考にした書籍を列挙しておきます。

スクラム現場ガイド　スクラムを始めてみたけどうまくいかない時に読む本（リフロー版）

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

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

【Ruby】文字列リテラルのダブルクォートとシングルクォートの違いについて

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで
文字列リテラルのダブルクォートとシングルクォートの違いを調べました。

環境

• max OS X Sierra
• Ruby 2.4.1

前提条件

• irbかPryが動作すること

やり方

文字列リテラルのダブルクォートとシングルクォート

文字列リテラルのダブルクォートとシングルクォート

実行

[1] pry(main)> # ダブルクォート
[2] pry(main)> # ・バックスラッシュ記法と式展開が有効になる
[3] pry(main)> str1 = "式展開も試してみます"
=> "式展開も試してみます"
[4] pry(main)> puts "ダブルクォートのサンプル文字列です\n\nそして、#{str1}"
ダブルクォートのサンプル文字列です

そして、式展開も試してみます
=> nil
[5] pry(main)>
[6] pry(main)> # 文字列内でダブルクォートを使いたい場合、エスケープ文字を入れる
[7] pry(main)> # ※「サンプル文字」をダブルクォートで括ってみる
[8] pry(main)> puts "ダブルクォートの\"サンプル文字列\"です\n\nそして、#{str1}"
ダブルクォートの"サンプル文字列"です

そして、式展開も試してみます
=> nil
[9] pry(main)>
[10] pry(main)> # シングルクォート
[11] pry(main)> # ・\\ (バックスラッシュそのもの)と \' (シングルクォート) を覗いて、文字列の中身の解釈しない
[12] pry(main)> str2 = "式展開されないことを確認します"
=> "式展開されないことを確認します"
[13] pry(main)> puts 'シングルクォートのサンプル文字列です\n\nそして、#{str2}'
シングルクォートのサンプル文字列です\n\nそして、#{str2}
=> nil
[14] pry(main)>
[15] pry(main)> # シングルクォートの場合、中身の会社はしないのでエスケープ文字を入れなくてもそのまま表示される
[16] pry(main)> puts 'シングルクォートの"サンプル文字列"です\n\nそして、#{str2}'
シングルクォートの"サンプル文字列"です\n\nそして、#{str2}
=> nil
[17] pry(main)>

まとめ

ダブルクォートとシングルクォートの違いに気づかず、シングルクォートで式展開を書いてしまっていて
なぜ展開されない？と数分考え込んでしまったので、簡単ですがまとめみました。

基本、ダブルクォートを使うのが良さそうなのでこちらを使っていきます。

参考資料

リテラル (Ruby 2.4.0)

【Ruby】キーワード引数

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで キーワード引数を調べました。

環境

• max OS X Sierra
• Ruby 2.3.0

前提条件

• irbかPryが動作すること

やり方

キーワード引数（デフォルト値あり）

キーワード引数（デフォルト値あり）のサンプルソース

実行

[6] pry(main)> # 引数を元にメッセージを表示する
[7] pry(main)> def display_message(name: 'Smith', message: 'Sample')
[7] pry(main)*   p "#{name} : #{message}"
[7] pry(main)* end
=> :display_message
[8] pry(main)>
[9] pry(main)> display_message
"Smith : Sample"
=> "Smith : Sample"
[10] pry(main)> display_message(name: 'John', message: 'Hello')
"John : Hello"
=> "John : Hello"
[11] pry(main)> display_message(message: 'Hello', name: 'John')
"John : Hello"
=> "John : Hello"
[12] pry(main)> display_message('John', 'Hello')
ArgumentError: wrong number of arguments (given 2, expected 0)
from (pry):8:in `display_message'
[13] pry(main)>

デフォルト引数を定義することで、何も受け取らなかった場合
デフォルトのものが表示されていることがわかります。

また、引数を設定するとその値にとなり、引数の順番を変えても
問題なく表示されていて便利です。

ただし、引数の値だけではエラーとなってしまいキーワードは必須です。

キーワード引数（デフォルト値なし）

キーワード引数（デフォルト値なし）のサンプルソース

実行

[13] pry(main)> # 引数を元にメッセージを表示する
[14] pry(main)> def display_message(name:, message:)
[14] pry(main)*   p "#{name} : #{message}"
[14] pry(main)* end
=> :display_message
[15] pry(main)>
[16] pry(main)> display_message(name: 'John', message: 'Hello')
"John : Hello"
=> "John : Hello"
[17] pry(main)> display_message(message: 'Hello', name: 'John')
"John : Hello"
=> "John : Hello"
[18] pry(main)> display_message
ArgumentError: missing keywords: name, message
from (pry):16:in `display_message'
[19] pry(main)> display_message('John', 'Hello')
ArgumentError: wrong number of arguments (given 2, expected 0)
from (pry):16:in `display_message'
[20] pry(main)>

デフォルト値なしの場合、エラーとなってしまったので
こちらを使った方がいい場合もありそうです。

まとめ

今まで意識して使ったことなかったのですが、明確に記述したい場合などがあったら
積極的に使っていきたい機能だと思いました。

ただし、参考資料先でも書かれている通り、冗長になる可能性が十分あるので
適材適所として使っていきます。

参考資料

改訂2版 パーフェクトRuby

ruby-rails.hatenadiary.com

robots.thoughtbot.com

【Ruby】可変長引数と配列の展開

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで 可変長引数と配列の展開を調べました。

環境

• max OS X Sierra
• Ruby 2.3.0

前提条件

• irbかPryが動作すること

やり方

可変長引数

可変長引数のサンプルソース

実行

[12] pry(main)> # 引数を元にメッセージを表示する
[13] pry(main)> def display_messages(name, *messages)
[13] pry(main)*   messages.each do |message|
[13] pry(main)*     p "#{name} : #{message}"
[13] pry(main)*   end
[13] pry(main)* end
=> :display_messages
[14] pry(main)>
[15] pry(main)> # 実行
[16] pry(main)> display_messages 'John', 'Hello', 'Goodbye', 'Thank you'
"John : Hello"
"John : Goodbye"
"John : Thank you"
=> ["Hello", "Goodbye", "Thank you"]
[17] pry(main)>

値を個別に渡していますが、2つ目以降は配列として受け取られているのがわかります。

可変長引数

配列の展開のサンプルソース

実行

[39] pry(main)> # 引数を元にメッセージを表示する
[40] pry(main)> def display_messages(name, message_first, message_second)
[40] pry(main)*   p "#{name} : #{message_first}"
[40] pry(main)*   p "#{name} : #{message_second}"
[40] pry(main)* end
=> :display_messages
[41] pry(main)>
[42] pry(main)> # 実行（正常動作）
[43] pry(main)> messages = %w(Hello Goodbye)
=> ["Hello", "Goodbye"]
[44] pry(main)> display_messages 'John', *messages
"John : Hello"
"John : Goodbye"
=> "John : Goodbye"
[45] pry(main)>
[46] pry(main)> # 実行（例外発生）
[47] pry(main)> # 受取先のメソッドの引数以上に渡した場合、エラーとなる
[48] pry(main)> messages.push 'Thank you'
=> ["Hello", "Goodbye", "Thank you"]
[49] pry(main)> display_messages 'John', *messages
ArgumentError: wrong number of arguments (given 4, expected 3)
from (pry):50:in `display_messages'
[50] pry(main)>

まとめ

最初見た時は「なんだこれ？」と思いましたが、コーディング量が減るのはいいことで
使えるところには積極的に使っていきたいです。

ただ、変数名などをちゃんとしないと変に勘違いする可能性もあるかな？と思ったので
要注意のものだと感じられ巻いた。

参考資料

改訂2版 パーフェクトRuby