2019-02-10

シュッとやってみた文字列操作の処理速度比較

Ruby

Rubyの話です。

f:id:tanaken0515:20190210092928p:plain

↓の記事を読んでいたら実行速度の話が出てきたので気になってシュッと調べてみました。 moneyforward.com

動作環境: Ruby 2.5.1

単一の文字列とのマッチ

正規表現は、あるパターンに従う文字列の集まりを指したいときには便利ですが、単一の文字列とのマッチに正規表現を使うのはやめましょう。文字列を使うべきです。実行速度がだいぶ違います。

比較してみた。文字列を10,000回splitするのを100回やって処理時間の平均値を出す。

irb(main):001:0> str = 'abcdefgh'
=> "abcdefgh"
irb(main):002:0> 100.times.map{ Benchmark.realtime{ 10000.times{ str.split(/e/) } } }.sum / 100
=> 0.009860930000431836
irb(main):003:0> 100.times.map{ Benchmark.realtime{ 10000.times{ str.split('e') } } }.sum / 100
=> 0.003988147991476581

文字列を使ったほうが2倍くらい速い

パターンマッチするか否かの真偽値

=~はマッチに成功した場合にただのtrueではなくマッチの位置を返します。制御構造の条件や論理演算で使っても問題になることはありませんが、これは欲しい情報に対して過多な情報で、そのために実行効率を落としています。真偽値を返すString#match?やRegexp#match?に置き換えるだけで数倍速くなります。

比較してみた。パターンマッチの真偽値を10,000回出すのを、100回やって処理速度の平均値を出す。

irb(main):001:0> str = 'abcdefgh'
=> "abcdefgh"
irb(main):002:0> 100.times.map{ Benchmark.realtime{ 10000.times{ str =~ /e/ } } }.sum / 100
=> 0.002607569007668644
irb(main):003:0> 100.times.map{ Benchmark.realtime{ 10000.times{ str.match?(/e/) } } }.sum / 100
=> 0.0013666660047601908

String#match?を使ったほうが2倍くらい速い

完全一致

完全一致の場合は=~(もしくはmatch?)で比較するまでもなく、文字列にとって最も基本的な関係演算である==を使えばよいのです。

比較してみた。完全一致の真偽値を10,000回出すのを、100回やって処理速度の平均値を出す。

irb(main):001:0> str = 'abcdefgh'
=> "abcdefgh"
irb(main):002:0> 100.times.map{ Benchmark.realtime{ 10000.times{ str =~ /\Aabcdefgh\z/ } } }.sum / 100
=> 0.0026517410040833057
irb(main):003:0> 100.times.map{ Benchmark.realtime{ 10000.times{ str == 'abcdefgh' } } }.sum / 100
=> 0.000976948984898627

==を使ったほうが3倍くらい速い

まとめ

記事内には他にも比較できそうなものがありましたが、今回はこの辺で。実際に数字を出してみると「ほぉ〜」となりますね。

ではまた。

2019-02-02

Kindleを使い始めて2週間が経ちました

読書ふりかえり

先日インプットの手始めにKindle Paperwhiteをポチった。 - tanaken’s blogという記事を書きました。

ざっくりいうと

「最近読書していないなぁ」「読書ライフを快適にしたいなぁ」という想いがあったのでKindle Paperwhiteを買いました。

『自分インプット少なすぎじゃね？』という危機感を改めて感じているので、まずは一定量のインプットを習慣化しようと思います。

という内容です。
あれから2週間が経過したので振り返りを書いておきます。

f:id:tanaken0515:20190202113119p:plain

"一定量のインプットを習慣化" とは？

改めて前回の記事を読んでみると、目指している "一定量のインプットを習慣化" をちゃんと定義していなかったですね。
これでは「2週間経ったいま、良い感じなのかどうか」が分からないですね。(振り返りをしてみるとこういう雑さに気づけるから良い)

先の記事では

去年から読みかけになっていたSOFT SKILLSを読んでいます。

読み終わったらITエンジニアに読んでほしい！技術書・ビジネス書大賞2019を片っ端から読もうかな、という気持ちです。

と宣言しているので、当時の目標は「これらを1年間で全て読むこと」だったとしましょう。

この前提で計算してみると

1年間で合計21冊なので約17日間で1冊読むペース
1冊あたり約500ページとすると1日あたり約30ページ

という感じになります。

2週間経過しているので 30ページ x 14日 = 420ページくらいのペースで読めていれば達成できたと言えそうです。

達成できたのか...？

実際の読書量は...たったの167ページでした。すくな....
達成率40%くらいですね。

(あと地味に去年から読みかけになっていたSOFT SKILLSを読んでいます。が嘘で SOFT SKILLSじゃなくてCAREER SKILLSだった)

2週間のアクションを思い出す

やったこととやらなかったことを思い出してみます。

やったこと
- 睡眠前に枕元に置いてあるKindleで読書した
  - 毎晩ではない。14日間のうち9~10日くらい。
- 通勤時にスマホのKindleアプリで読書した
  - 14日のうち3日くらい
- 読書予定の本をAmazonのほしい物リストに全部入れた
- スマホの充電コードをベッドから遠ざけてリビングに置いた
やらなかったこと
- 睡眠前にベッドでスマホをいじる
- 読書のペースを気にする
- Kindleを外に持ち歩く

今後のアクション

目標をどうするか

さっき定義した 1日あたり約30ページ というペースは、(一般的な人からしたらすごく少ないんだろうけど)読書慣れしてない自分にはちょうど良い気がしたので、一旦それでやってみようと思いました。

ペースをどうやって改善するか

読書量 = 読書スピード x 読書時間なので、読書スピードをあげる方針と読書時間を増やす方針を考えてみました。

読書スピード:
- モチベーションが高いと上がりそう
  - モチベーションは「読書によって得られる価値が高いと感じている時」に上がりそう
  - モチベーションは「"読むぞ!"と決めた自分に対する(謎の)誓い」みたいなものが強いと上がりそう
- 頭の冴えている状態(眠くない,集中できている)だと上がりそう
- 読みやすい文章だと上がりそう
- 活字を読むことに習熟すると上がりそう(= 慣れ)
読書時間:
- 睡眠前に毎晩読むことにしたら増えそう
- 通勤時に毎回読むことにしたら増えそう
- 寝る前や通勤以外の時間も使ったら増えそう
  - 他のことをやりながら読むことにしたら増えそう(食事、歯磨き、トイレ、など)
  - 他のことをやっている時間を削ったら増えそう(ゲーム、youtube)

長期的に考えるとルーティーンに組み込んでしまうのが良さそうなので「睡眠前と通勤時に毎回読む」をやる感じかな〜と思っています。

通勤時に関しては14日のうち3日くらいしか読まなかったので、ここを改善するだけでも大きな効果がありそうです。
通勤時にはスマホのKindleアプリで読んでいましたが、これだと集中できずに別のアプリを開いてしまうことがあるので、Kindle Paperwhiteを持ち歩いて読むようにしてみようと思います。

あとは今回明確化した 1日あたり約30ページ という目標があるので、モチベーションを高く保つことができそうです。

Kindle Paperwhiteの使い心地

タイトルに"Kindle"が入っている割にKindle自体の話を書いていなかったので、使い心地を書いておきます。

軽い
- 軽くてめっちゃ良いです。寝転びながら読んでもあまり疲れないですね。
バックライトの光量と光り方がちょうど良い
- 薄暗い部屋でも読みやすい、ちょうど良いバックライトです。
読書に束縛される感が良い
- Kindleでは基本的に読書以外はできなくて、それが絶妙に良いです。
- 紙の書籍を読んで夢中になる感じって、読書だけに集中せざるを得ないあの感じによって生み出されている気がするんです。
マーカーをつけたりコメントを残したりできる
- 普通に便利です。ただし、Kindle Paperwhiteはテキストをタイピングしてから反映されるまでのラグがすごいので、コメントは残しにくいですね。
マルチデバイスでKindleを使うと、読みかけのページまでジャンプすることができる
- どちらかの端末で読み進めたあと別の端末で読もうとすると「XX端末でここまで読んでるけど、飛ぶ？」みたいなアラートを出してくれます。

まとめ

この記事では、先日書いたインプットの手始めにKindle Paperwhiteをポチった。 - tanaken’s blogの振り返りをしてみました。
1日あたり約30ページ という目安を作ったので、まずはこれを日々達成できるようにしていこうと思います。(Kindleの読書量を取れるAPIがあればいいな、あるかな？)

あと、振り返りを2週間後に設定してカレンダーに登録しておいたのが良かったです。おかげで忘れずに振り返りをすることができました。
また2週間後に振り返りを設定しておこう。

ではまた。

2019-01-19

インプットの手始めにKindle Paperwhiteをポチった。

読書

あけましておめでとうございます。今年最初のブログです。
「最近読書していないなぁ」「読書ライフを快適にしたいなぁ」という想いがあったのでKindle Paperwhiteを買いました。

f:id:tanaken0515:20190119090728p:plain

インプット

最近よく、インプットとアウトプットについて考えています。
職場で自分よりも優れた能力を持っている人がたくさんいると感じる*1し、その人たちが自分の数倍インプット＆アウトプットしている*2と感じます。

この人達に認められたい

この人達になんとかして追いつきたい

という思いがあります。目指しているイメージと比較して、自分の足りない部分やダメな部分を見つけては暗い気持ちになったり不安になったりすることもあります。
とはいえ、焦っても仕方ないし、少しずつでも日々前進*3していくために何かを積み上げていくしかないかなと思っています。

そのための第一歩として、インプットの量を増やそうという思いに至りました。 "アウトプットしようとすれば必要に迫られてインプットするからアウトプットしようぜ" 論みたいなものもあると思っていて、それ自体も激しく同意するのでアウトプットもやっていきたいのですが、それとは全く別次元で『自分インプット少なすぎ*4じゃね？』という危機感を改めて感じているので、まずは一定量のインプットを習慣化しようと思います。

Kindle Paperwhiteを買った

購入にあたって、この記事を参考にしました。

www.sin-space.com

気に入っているポイントは

読書だけに集中できる
目に優しい(らしい)
１ヶ月に１〜２回の充電で済む(らしい)

です。
生活のルーティーンに読書を組み込むために、枕元にKindle Paperwhiteを置くことにしました。
これまでは枕元にスマホを置いていて、寝る前にTwitterをみたりSlackをみたりYouTubeをみたり...を繰り返してしまう事があったので、スマホ(と充電ケーブル)はリビングに移動しました。
結果として寝る前の無駄な時間が良い読書時間になりそうです。

今は、去年から読みかけになっていたSOFT SKILLSを読んでいます。

www.amazon.co.jp

これが読み終わったら↓を片っ端から読もうかな、という気持ちです。

www.shoeisha.co.jp

それぞれ読み終わったら感想をアウトプット(たぶんブログ書く)します。

まとめ

今回はインプットについて思ってることとKindle Paperwhiteを買った話を書きました。
これでちゃんとインプットが習慣化できるかな...？うまくいってるかどうか、2週間後に振り返りを設定しておくことにします。

ではまた。

*1:優れていると感じる観点と、感じ方は人それぞれ

*2:Twitterで「読了。XXXX」とか流れてくる。OSS活動やブログ記事をよく見る。

*3:結果的には遠回りでも良いし前進に必要な後退なら良いかなとも思うけど

*4:2018年、漫画以外で読んだ書籍は4冊だけ。うち2冊は読みかけ。

2018-12-30

Enumerable#injectとArray#sumとActiveRecord#sumを比べてみた

Ruby Ruby on Rails

Ruby, Railsの話です。
ちょっとした集計処理には色々な書き方があるなぁと思っていて、今携わっているプロジェクトにもいろんな書き方があったので比べてみるコトにしました。

f:id:tanaken0515:20181230205821p:plain

検証環境

ruby 2.5.1
rails 5.2.1
postgresql 10.5

問題状況

例えば注文明細の情報があり、「単価(price)」と「数量(quantity)」のデータを持っているとしましょう。
このデータを使って注文金額の合計値を計算したい場合について考えてみます。

orders テーブルのスキーマ:

  create_table "orders", force: :cascade do |t|
    t.integer "price"
    t.integer "quantity"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
  end

計算ロジック

注文金額の合計値は全レコード分の price * quantity を足し合わせた値なので以下のような方法で計算することができそうです。

Enumerable#inject を使う場合

Order.all.inject(0){|sum, order| sum + order.price * order.quantity}

instance method Enumerable#inject (Ruby 2.6.0)

Array#sum を使う場合

Order.all.map{|order| order.price * order.quantity}.sum

instance method Array#sum (Ruby 2.6.0)

ActiveRecord#sum を使う場合

Order.all.sum("price*quantity")

https://devdocs.io/rails~5.2/activerecord/calculations#method-i-sum

比較してみた

毎回データを取得する場合

number_of_trial = 500
Order.uncached do
  Benchmark.bm 20 do |r|
    r.report "Enumerable#inject" do
      number_of_trial.times do
        Order.all.inject(0){|sum, order| sum + order.price * order.quantity}
      end
    end

    r.report "Array#sum" do
      number_of_trial.times do
        Order.all.map{|order| order.price * order.quantity}.sum
      end
    end

    r.report "ActiveRecord#sum" do
      number_of_trial.times do
        Order.all.sum("price*quantity")
      end
    end
  end
end

                           user     system      total        real
Enumerable#inject      6.380000   0.140000   6.520000 (  8.091545)
Array#sum              7.150000   0.040000   7.190000 (  8.771430)
ActiveRecord#sum       0.260000   0.070000   0.330000 (  1.081005)

前もって取得しておいたデータを使う場合

number_of_trial = 500
Order.uncached do
  Benchmark.bm 20 do |r|
    orders = Order.all
    r.report "Enumerable#inject" do
      number_of_trial.times do
        orders.inject(0){|sum, order| sum + order.price * order.quantity}
      end
    end

    r.report "Array#sum" do
      number_of_trial.times do
        orders.map{|order| order.price * order.quantity}.sum
      end
    end

    r.report "ActiveRecord#sum" do
      number_of_trial.times do
        orders.sum("price*quantity")
      end
    end
  end
end

                           user     system      total        real
Enumerable#inject      0.370000   0.000000   0.370000 (  0.408662)
Array#sum              0.350000   0.000000   0.350000 (  0.356449)
ActiveRecord#sum       0.260000   0.030000   0.290000 (  1.094346)

比較結果

Enumerable#inject を使うか Array#sum を使うかは、好みの話かも。
- 該当コードの文脈に合わせてわかりやすい方を使えば良さそう
合計値だけが欲しい場合は ActiveRecord#sum を使うと良さそう。
個別のデータは他でよしなに使いつつ、ついでに合計値も出したい、というケースでは Enumerable#inject なり Array#sum を使った方が良さそう。

まとめ

今回はちょっとした集計ロジックを比較してみました。
データの取得が絡んでいるのでキャッシュ使わないよう uncached したり、処理時間を比較するために Benchmark を使ってみています。(詳しく調べたらまた記事にしようかな〜)

ではまた。

2018-12-22

年末ジャンボ10億当選の準備をしておく

昨日数年ぶりに宝くじを買いました。
10億当選する予定ですがまだ心構えができていないので記事を書いておきます。

f:id:tanaken0515:20181222092130p:plain

当選発表はいつなの

2018年12月31日(月) 12:45~13:00(予定) です
NHK総合チャンネルでテレビ中継される予定です
テレビ中継というのは、そもそも「年末ジャンボ抽選会＆特別コンサート」なるものをやっているからです

www.takarakuji-official.jp

Webでも当選番号を確認することができます（宝くじってみずほ銀行が絡んでるんだなぁと思いました）

www.mizuhobank.co.jp

10億当選した瞬間の自分

冷静でしょう（この記事を書いたことで、心構えができているためです）
いまカバンに雑に入っている宝くじを、一旦安全などこかに移すでしょう

当選がわかってから受け取りまで

ググると~~ヘンテコな~~記事がいっぱい出てきます
公式サイトにちゃんとした受け取り方のページがあります

www.takarakuji-official.jp

購入方法と金額によって受け取り場所が変わります。売り場で買った場合は以下の通り
- ~ 1万円：売り場 or みずほ銀行
- 1 ~ 5万円：５万円マークのある売り場 or みずほ銀行
- 5 ~ 50万円：みずほ銀行
- 50 ~ 100万円：みずほ銀行（身分証明書必須）
- 100万円 ~：みずほ銀行（身分証明書＋印鑑必須）

僕の場合は10億当選するので、当選くじと身分証明書と印鑑を持ってみずほ銀行に行けば良いということがわかります。

流石に現金でもらうのはしんどい(100kg越えるらしい)ので、口座に入金してもらうことになりそうですが、普段使いのUFJの方に入金してほしいです。みずほ銀行さんごめんやけどお願いします。

受け取った後、どうする

手元に10億あったら何するでしょう
単純に使うことだけ考えてしまうと、
- 仮に90歳まで生きるとして、あと約60年間
- 年間1000万使ったとして6億か。4億余っちゃいますね。
- あまりにもつまらない、浪費するだけの人生になってしまいます
かといって、お金をかけて作りたい何かとか、支援したい何かとかが、決まっているわけではなく、面白いと思える使い道をすぐに見つけることができない自分に、気づかされたりします
(家を買ったりとか、犬を飼ったりとか、家具をええやつに買い替えたりとか、そういう使い道はすぐ見つかるけど、それとは別の話)
え、どうしよう、ふざけた記事だったのにちょっと病んできた
お仕事をしなくても生活できるお金がある状態というのは、死ぬまでの時間(生活の不安を感じることなく)好きなことだけしてて良いよ、みたいな話で。そうなった時、自分は何やろうかな〜と探すことから入るのか。というのに気づいたのが今です
改めて冷静に自分がその状況でどういう行動を取るかを考えてみると、
- 設備的なところを今より快適性が上がるように買い替える(家とか。家具家電とか(定期的に買い替えそう))
- 時間を作る
  - 今はお仕事に使っている時間を、別の何かに充ててみる
    - 結局webが楽しくてお仕事に戻ってきそうな気もする
  - 飽きるほど何かをやってみる（飽きなかったら勝ち）
- お金かかるからやめておこ〜となっていたコト(体験、旅行とか)を全部やる(= フットワークが軽くなる)
くらいかなと思います。

夢中になれるコトを見つけるために

自分は熱中しているコトや飽きずにずっとやっているコトは正直特にないです
そういうコトを見つけたいなと思っています
お金と時間があればそれが見つかるのか？と問われると、分からないです。
が、お金と時間があったら何をやるか？と思考してみることで、「自分本当はこれやりたいのか！」とか、「これ実はお金と時間がなくてもできるじゃん！」とかに気づくきっかけになるかもな、と思いました。

まとめ

今回は年末ジャンボ10億当たるのでその準備をしてみたら自分を見つめ直す時間になった話でした。
当選発表楽しみだな〜

ではまた

2018-12-08

Enumerable#all? が罠っぽかった

Ruby

Rubyの話です。
お仕事をしていたら「罠だよなぁ」といっている同僚がいたので調べてみたメモです。

f:id:tanaken0515:20181208132928p:plain

Enumerable#all?

instance method Enumerable#all? (Ruby 2.5.0)

すべての要素が真である場合に true を返します。偽である要素があれば、ただちに false を返します。ブロックを伴う場合は、各要素に対してブロックを評価し、すべての結果が真である場合に true を返します。ブロックが偽を返した時点で、ただちに false を返します。

例えばこう↓書く。全部３の倍数だったらtrue、３の倍数じゃないやつが１つでもあったらfalseみたいな。

irb(main):001:0> [3, 6, 9].all? {|item| item % 3 == 0}
=> true
irb(main):002:0> [3, 6, 8].all? {|item| item % 3 == 0}
=> false

罠っぽさ

Enumerable#all? はレシーバが空配列のときtrueを返します。

irb(main):003:0> [].all? {|item| item % 3 == 0}
=> true

なので例えば次のようなメソッドがあるとして

def all_multiple_of_3?(items)
  items.all? {|item| item % 3 == 0}
end

下のような感じになります。

irb(main):001:0> all_multiple_of_3?([3, 6, 9])
=> true
irb(main):002:0> all_multiple_of_3?([3, 6, 8])
=> false
irb(main):003:0> all_multiple_of_3?([])
=> true

👵「[] は全部３の倍数なのかい？」
👦『 そうだよ！』

罠っぽい。

何となくですが

👦『 ３の倍数じゃなかった奴はいなかったよ！』
(最初から誰もいなかった(=空配列だった)んだからそうだよね)

みたいなことなのかなと思いました。

罠っぽさパトロール 👮‍♂️

all? (Enumerable) - Rubyリファレンスには「関連項目」に次の３つがあったので、念のため罠っぽくないかパトロールしました。

any? : どれか○○かを調べる。

none? : すべて○○でないかを調べる。Ruby 1.8.7

one? : 1つだけ○○かを調べる。Ruby 1.8.7

irb(main):001:0> [].any?
=> false
irb(main):002:0> [].none?
=> true
irb(main):003:0> [].one?
=> false

罠っぽくありませんでした。よかった。

まとめ

👩‍🏫『Enumerable#all? はレシーバが空配列のときtrueを返すから気をつけましょう』

ではまた。

2018-12-02

"ペパボに入って良かった"と思った７つのこと

ふりかえり

この記事は GMOペパボ Advent Calendar 2018 の2日目の記事です。

GMOペパボ株式会社にWebアプリケーションエンジニアとして入社して、丸３ヶ月が経ちました。
今回はペパボで過ごす中で、"入社して良かった"と思ったことをいくつか書きたいと思います。

f:id:tanaken0515:20181201154702p:plain

"入社して良かった"と思った7つのこと
まとめ

"入社して良かった"と思った7つのこと

①コードレビューの心地良さ

日々の業務の中でコードを書いてプルリクを出すわけですが、プルリクに対するレビューがとても心地良いなぁと思っています。

コードの意図を聞いてくれる

『ここのコード、どういう意図があるのかを知りたいです！』という質問をくれます。質問部分にはもしかしたら「本当はこう書いた方がより良いかも？」という思いがあるのかもしれませんが、一旦それを抜きにして、自分のコードに歩み寄ってくれます。
意図を聞いてもらえると「なんでそう書いたのか＝自分の思い」をそのまま答えることができます。その上で『そういう思いだったらこういう実現方法もありますよ』というアドバイスをもらえるので、学びが身に染みます。
（副次効果として「意図の答えられないコード」が生まれるのを抑止する仕組みにもなるなぁと思っています）

指摘の理由をちゃんと伝えてくれる＆提案をくれる

時にはレビューによってちょっと大きめな修正が必要なケースもありましたが、そんな時は理由部分をしっかりと説明した上で『代わりにこうやってみましょうか』という具体案を提案してもらいました。

"コードレビューかくあるべし" という議論は色々とありますが、自分にとっては上記２つがすごく心地よく感じました。一見「コードレビューする上での当たり前のこと」にも見えますが、継続的にこういうレビューをする文化を持っているのはすごいことだなぁと感じています。自分がレビューするときにも同じようにやろうと思えるし、このような環境にいられるのはありがたいと思っています。

②技術への熱の高さ

ペパボでは様々な勉強会が様々な頻度で行なわれていますが、特に自分は、毎月開催されているPTF(Pepabo Tech Friday)というイベントがすごく良いなぁと思っています。
東京オフィスと福岡オフィスを繋いでの同時開催です。東京オフィスには約15〜20人くらい集まっているので福岡と合わせると30〜40人くらいの規模でしょうか。あらかじめ立候補した人が順に登壇していき、聞く側は発表を聞いて質問したりSlackでわいわいしたりします。新卒１〜２年目の若手からベテラン勢まで、いろんな人が登壇します。

このイベントに初めて参加したとき僕は「こんなに人が集まるんだ！！」とすごく感激しました。
前職で新卒1年目の時に、同じような勉強会の運営を先輩から引き継いで１年間回していたことがあるのですが、全く人が集まらず(多くて5人とか)すごくツラい思いをしました。なので、このイベントのわいわいしている様子を見た時には、めちゃくちゃ感動しました。

おそらくこのイベントが盛り上がってわいわいしているのは(もちろん運営の方々の事前準備や当日準備のおかげというのはある上で、それに加えて)、
・パートナー(=社員)それぞれがアウトプットすること＝大事なこと、という価値観を持ってるから
・ペパボという会社自体がアウトプットすることを重要視して、アウトプットしている人を評価する、という価値観を持っているから
だと思っています。

③プロダクトへの熱の高さ

『SUZURIではこういう表現を使おう』
『こういう言い方のほうが、スリスリくんっぽい』
『XXXという世界観、YYYという価値を追求したい』

自席で作業していると、何処からともなくこういう声が聞こえてきました。どういうサービスでありたいかを熱く語るメンバーたちの会話です。
自分はいま、SUZURIというサービスの開発に携わっています。

suzuri.jp

自分はこれまでtoCのWebサービスや忍者スリスリくんのようなイメージキャラクター(?)がいるWebサービスに携わったことがなく、サービスの世界観やキャラクターの振る舞いなどを考えたことはありませんでした。その時点で自分の知らない世界が広がっているなぁという感じではあるのですが、特にディレクターの@jitsuzonさんが記録していた『SUZURI事業部のミッションについて』のissueには、すごくアツい文章が書かれていてグッと来ました(お見せできないのが残念です)。

『どういう想いで、どういう価値を提供するためにサービスをやっているのか』というのは、サービス開発をする上ですごく大事だと思っています。アツい想いを持ったチームに加わることができたことを、すごく嬉しく思います。

自分は実際にはSUZURIチームのことしか分からないのですが、先日行なわれたデザインスクランブルというイベントでは、「ペパボのデザインプロセス展」という展示をしていて、全てのサービスにアツい想いが込められているんだろうなと思っています。

#デザインスクランブル
「ペパボのデザインプロセス展」が本当に凄くて。アワードのロゴができるまで、を始めペパボサービスの色んなデザインができるまでの工程を細かく展示されてました。昨日1日だけの展示では勿体ないので、ぜひ #DesignScrambe のタグで検索して、読んでみて欲しいです◎ https://t.co/lNJhBWbAUW
— OTO OTO®︎ (@otooto_hoi) 2018年11月25日

サービスロゴのデザインプロセス
Slackのやり取り最初から最後まであってロゴ作り分かって良かった。

じっくりみてる来場者多くて人気すごい

デザイン勉強なりました。#ペパボ
 #デザインスクランブル #DesignScramble pic.twitter.com/hwYg5iu3R1
— つーぺん (@ecw2001) 2018年11月24日

④Slackに統一されたオープンなコミュニケーション

入社して３ヶ月経ちましたが、僕はまだ１通もメールを送っていません。
全ての社内のやりとりがSlackに集約されているので、メールを使う必要がないためです。
「お疲れ様です。XX事業部のOOです。お世話になっております。」という無駄な文章を書く必要がないだけでかなり快適な生活を送れるなぁと思います。

Slackではpublicチャンネルでオープンなやりとりがされています。前職ではprivateチャンネルやDMでのやりとりが多々ありましたが、よくよく考えてみるとpublicチャンネルでやりとりできるはずの内容が多かったなぁと思います。

オープンにしておくことで色々なメリットがあると思っていて、例えばこれまで「他の人には関係なさそうなことだからDMで」となっていたやりとりがpublicチャンネルの「XXスレ」の中で行なわれるようになると、今後同じようなやりとりが発生した時に参考になったり、非効率なやりとりであれば効率化する方法を考えたり、というメリットがあります。

また、Reacji Channelerとの相乗効果もあってすごく良いです。
Reacji Channelerは、コメントに絵文字リアクションがついた時に、その絵文字に応じて特定のpublicチャンネルに通知を送る機能です。
例えば「勤怠の申請方法がわからないよ〜」というコメントすると、誰かが勤怠の絵文字をつけて人事のチャンネルに振り分けてくれたりします。
また、PTFのようなイベントの時にわいわいしながら絵文字リアクションをつけると、自然と通知が届いて巻き込み力を発揮したりします(楽しい)。

詳しくは@june29さんの記事が参考になります↓ june29.jp

⑤行動指針の刷新　〜私たちが大切にしている３つのこと〜

もともと社の行動指針のようなメッセージとして『大切にしてほしい3つのこと』という文章がありました。
この文章が最近『私たちが大切にしている３つのこと』に生まれ変わりました。
これについてはペパボデザイナー Advent Calendar 2018 で鹿さんが想いを綴っています。 note.mu

『私たちが大切にしている３つのこと』に込められた想いやその文章もすごく良くて、ぜひ↑の記事を読んでいただきたいのですが、何より『そもそもこういうことに時間を投資することができること』がめちゃくちゃ良いなと思いました。文章には"想い"が宿るし、人や組織は"想い"で動くと思っているので、こういう活動が行なわれてるペパボは強いなと感じました。

⑥社長からのメッセージ

今年9月の初め、北海道で大きな地震がありました。そのことはあまり深く考えず、入社したての僕は出勤しました。すると、Slackの全社チャンネルにあるメッセージが届いていました。社長からです。
そこには次のような内容が書かれていました。

北海道で大規模な地震と停電が発生していること
パートナー(社員)自身やご家族で被害にあっていたり安否が分からない場合は上長や人事に申し出てほしいこと
各サービスでお客様のことを想った対応をしてほしいこと

このメッセージに、僕はすごく心打たれました。僕自身や僕の家族で被害に遭った人はいなかったのであまり深く考えていなかったですが、周りの社員の中には家族の安否が分からない方もいたかもしれません。サービスの利用者の中にも被害に遭われた方がおそらくいたでしょう。

そういうことをすぐに思って社長自らメッセージを発信してくれていることに、僕はすごく感動しました。(と同時にそういう想像力や思いやりを欠いている自分に不甲斐無さを感じました)
ペパボの中の人にとってはこれが当たり前の感覚なのかもなぁと思った、印象的な出来事でした。

⑦『のっていき！』の安心感

ここまで書いてきたことだけでなく、その他にもペパボに入って感じたことがたくさんありました。これを何らかの形で共有したいし、「もしかしたら僕以外の中途入社された方々も、自分と同じように色々な思いを持っていて、それを共有したいと思っているかもしれない！」と考えるようになりました。
10月中旬くらいからそんなことを思っていたのですが、なかなか具体的なアクションができず、気づいたら１ヶ月が過ぎていました。僕の中では「もう何もやらなくても良いかなぁ...」という温度感になり始めていました。

そんな中で、1on1をしてくれている@kurotakyさんがこの話を聞いて、「それめっちゃ良いじゃないですか！"のっていき"させてください！」といってくれました。その後すぐ@kurotakyさんがイベントのissueを立ててくれて、そしたら人事の@achamixさんも"のっていき"してくれて、あれよあれよという間に明後日12/4の開催が決定しました。

Slackの全社チャンネルに出したイベント告知メッセージには、たくさんの方が150を超えるリアクションをつけてくださり、@achamixさんによると人事部の方から「すごく良いね〜、次年度からは定期的にやりたいね」というお言葉もいただけたようで、すごく嬉しかったです。

自分ひとりでは実現できなかったであろうこのイベントが、様々な方の"のっていき"のおかげで実現までこぎつけ、果ては定期イベントになろうとしていることに、すごく驚いています。"のっていき"してもらえることの安心感を強く感じたので、また何かやりたいなと思えたし、周りで何かやりたいと思っている人がいたら"のっていき"したいなと思いました。

「やっていき、のっていき」については CTOのあんちぽさんが↓で紹介しています。 speakerdeck.com

まとめ

今回の記事では、入社３ヶ月の自分が感じた「"ペパボに入って良かった"と思ったこと」について書いてみました。
こんな記事をアドベントカレンダーに出すのは微妙かな？とも思ったのですが、『入社３ヶ月の"いまの自分"にしか書けないことかもしれない』と思って、書いてみることにしました。

この記事を読んで、ペパボに興味を持ってくれる人が少しでもいたら嬉しいです。
（あとペパボの中の人たちとわいわいするきっかけになったら嬉しいなと思います）

GMOペパボ Advent Calendar 2018 明日(3日目)は@udzuraさんです。
楽しみです。

ではまた。

ここでの発言・記事は個人の見解であり、所属する組織等の公式見解ではありません。

単一の文字列とのマッチ

パターンマッチするか否かの真偽値

完全一致

まとめ

"一定量のインプットを習慣化" とは？

達成できたのか...？

2週間のアクションを思い出す

今後のアクション

目標をどうするか

ペースをどうやって改善するか

Kindle Paperwhiteの使い心地

まとめ

インプット

Kindle Paperwhiteを買った

まとめ

検証環境

問題状況

計算ロジック

Enumerable#inject を使う場合

Array#sum を使う場合

ActiveRecord#sum を使う場合

比較してみた

毎回データを取得する場合

前もって取得しておいたデータを使う場合

比較結果

まとめ

当選発表はいつなの

10億当選した瞬間の自分

当選がわかってから受け取りまで

受け取った後、どうする

夢中になれるコトを見つけるために

まとめ

Enumerable#all?

罠っぽさ

罠っぽさパトロール 👮‍♂️

まとめ

"入社して良かった"と思った7つのこと

①コードレビューの心地良さ

コードの意図を聞いてくれる

指摘の理由をちゃんと伝えてくれる＆提案をくれる

②技術への熱の高さ

③プロダクトへの熱の高さ

④Slackに統一されたオープンなコミュニケーション

⑤行動指針の刷新 〜私たちが大切にしている３つのこと〜

⑥社長からのメッセージ

⑦『のっていき！』の安心感

まとめ

⑤行動指針の刷新　〜私たちが大切にしている３つのこと〜