けんちゃんくんさんの Web日記

本を読んだらまとめる癖をつけよう…その第一弾。

人間は筋道がたっているのを求める

ストーリーには構造があるという話から始まる。

本書では、ストーリーの構造を「ナラティブアーク（導入からクライマックスまで盛り上げていき、最後に落とすという起伏を表現する曲線）」と、それに沿った「7つのフェーズ」に分類して説明している。

ナラティブアークに沿ってストーリーを作ることは、ストーリーに起伏をつけることになる。これによって、ユーザにプロダクトを強く印象づけることができるし、オチやエンディングを設計することでクリフハンガー（ユーザの気持ちが最高潮に高まったところから、一気に落とされて印象に残らない、あるいはネガティブな印象を残すこと）を避ける効果があるとのこと。身近なプロダクトで今すぐ考えたほうがいいと感じた。(参考: ピーク・エンドの法則 - Wikipedia )

また、筆者による実際の映画やプロダクトを分析した実例がたくさん載っているので、実際にやってみるときのイメージがつかみやすいのも良いと思う。

3種類のストーリー

実際のプロダクト（特に既に世に出ているもの）のストーリーを収集し、マッピングしようと思うと超巨大なマップになってしまって、「そうだね。さて次は？」となってしまった経験はあるだろうか？（私はたくさんある…）

他の書籍でも様々な手法が提案されているが、本書では以下の3つに分類することを紹介しいている。

• コンセプトストーリー
• オリジンストーリー
• ユーセージストーリー

プロダクトのフェースや目的、あるいはチームの状況に合わせて、最初にユーザの心をつかむことに注力したいのか、ユーザのある特定の問題を解決してファンになってもらうことに注力したいのか、あるいはユーザも気づいていない潜在的な欲求を根本的に解決したいのか。どれに注力するのかが明確になっているのであれば、自分たちに必要な部分を同じフレームワークでマッピングすることができるのは、共通言語という意味でも勝ちがあるように思う。

まとめ

プロダクトを使うユーザのエンゲージメントを獲得したいなら、デザインスべきはシステムはなく、人間の体験です。システムは複雑です。しかし人間の体験は1本の線です。体験は時間の流れに沿ってしか起こりません。

最後の章にある文章が印象に残っている。「複雑だから」「たくさんの機能があるから」という言葉に負けずに、ユーザの体験をデザインしなければいけないし、それは人それぞれではあるけど時系列に並ぶ一本の線になる。

毎年恒例のアレ。

今年はなぜか見学枠という謎の枠も用意されていて、いよいよほんとによくわからなくなってきた。

この時期になると偉い人が「練習」や「稽古」などの理由でいなくなることがあるが、それ以外は基本的に秘密裏に物事が進むので、ほんとに社内の人間は何も知らないまま当日を迎えることになる。

準備してた皆さんお疲れ様でした ＆ 楽しいひとときをありがとうございました。

以下記録や素材など。

ケンタロマグマの衣装を担当いたしました。(全身なかったので袖からこっそり) #ペパボ新卒 pic.twitter.com/e8OxaMpyQW

— MiG (@huiyeop) 2017年4月12日

自分のパート終わりました。
今日のために作った楽曲はこちらで公開してます。https://t.co/W8aGOmlksA#ペパボ新卒

— 宇賀神wutang (@ugazin) 2017年4月12日

2冊！まじか！技術書が中途半端な感じになっているのがよくないなぁ…

このWeb日記にはsitemapを出力する機能が一切なかったので、 kjvarga/sitemap_generator を使ってsitemapを作るようにしていた。

URLを組み立てるために、DSLの中でhelperをincludeしたかったんだけどうまくいかなくて悩ましい。Rails力の低まりを感じる…

pragprogの積読がたまるいっぽうなので、少しずつ読んでいくという気持ちを高めて取り組み始めた。帰りの電車で「What Is RxJS?」あたりまで。

Callback、Promise、Event Emitterのそれぞれの課題と、Reactive Programmingはどういうアプローチなのかが整理されていて導入としてはとてもよかった。

Reactive Programming with RxJS: Untangle Your Asynchronous JavaScript Code by Sergi Mansilla | The Pragmatic Bookshelf

で一回休み。

聞いていると、小学校低学年まではレベルに合った曲やパートで楽しく、小学校高学年までが背伸びしたい感じ、中学校まで続けてるとさすがにレベルが上って安定してる、という印象。

まだまだ続けたいそうなので、来年度も頑張ってほしいところ。

昨日のWeb日記で、ConoHaの母艦作りなおすのだるいという話を書いたら、同僚が VPS（ConoHa）を docker-machine で操作する - kumak1’s blog というのを書いてくれた。便利そう。

このWeb日記は kenchan/tdnm: tdnm is simple weblog tool という自作のRailsアプリで、さすがにそろそろhttps化しないと恥ずかしいのでついでにDocker化もしてみた。

Docker化する

RailsアプリのDocker化については、jokerさんのQiita が参考になると思う。

最初は開発環境もDockerにしようかと思っていたのだけど、Gemfile にpath指定したいときに困る＆Dockerの旨味がなくなると感じたので、開発はローカルでやることにした。(2017年をキャッチアップする 三種の神器 / ghq_gem-src_and_bundler // Speaker Deck)

本番環境のイメージについては、静的ファイルの扱いを一旦おいておいて、bundle installとrails assets:precompileをしたイメージを作ることにした。

ベースのイメージは ruby:2.4-alpine にして、必要な依存関係をとかをバシバシいれていく。

• nativeビルドで必要なものは事前に入れておく
• bundle install --deployment オプション便利
• bundle installとgccやmake等のインストールをワンラインでやるとイメージは小さくなるが、nativeビルドに失敗した時にやり直しに時間かかる

というあたりが発見だろうか。

現時点で最終的なイメージが130MBくらい。

kenchan/tdnm - Docker Hub

https-portalでhttps化する

https化は docker で全自動 Let's encrypt - Qiita がめちゃくちゃ便利だった。

特に何も考えなくてもローカルでのオレオレ証明書での検証と、本番でのLet's encryptでの運用ができる。

一回ハマったのは、FORCE_RENEWオプションをつけたまま本番で何回かビルドしなおしたせいでLet's encrypt側の制限で証明書の取得が失敗するようになってしまったところ。たまたま過去のコンテナを雑に消したあとだったのでめっちゃ困った…結局、Railsを80番で直接出すことで1週間ほどをしのいだ。

docker-composeとデプロイ

ここはめっちゃ雑にやっている。dockerだけをインストールしたVMをConoHaに立てていて、その中に本番用のdocker-compose.ymlがある。

デプロイは、瞬断しても困らないのでイメージをpullしてrestartという感じ。

Docker Cloud使ってみたかったんだけど、母艦をArch Linuxで立ててしまったのでサポート外だと言われて使えなかった…Ubuntuで作り直そうかな…

バックアップとか

まだ特に何もやってないので、今壊れると何日か分のWeb日記消失することになる。これから考える。

まとめ

先月から少しずつDocker化、Ruby2.4化、https化を進めてみた。モダンな感じには程遠いが、実際自分で試してみると辛いポイントや工夫のしどころがわかって勉強になった。

昼前くらいに起きてお昼を食べて、息子が3時から公園で友達と約束しているからというので引率。

ポケモン交換をしたいとのことだったが、時間になっても友達はこなかったので別の子と1時間くらい遊んでおしまい。

公園行くだけだったら勝手に行かせてるんだけど、DS持っていくとなるとまだ心配なので一応ついていっている。他の家はこのあたりどうしてるのかなぁ。友達の家に持っていくなら全然気にしないけど、外だとちょっと心配。

星さんと1on1っぽいもの

星さん(@glover) と久しぶりにいろいろ話して、ECに来てから感じていた課題や、やらないことを決めようということについて、たぶん1時間くらい話していた。

見えるものが多くなると気が散ってしまうことが増えたり、自分のほうがうまくやれると思いこんで手を出してしまうことが多くなりがちなので、定期的にやってることや、続けるべきかどうかというのを見直さないといけない。

ショップオーナーさんとお話

たくさん面白いお話が聞けてよかった。また、正攻法では難しいと感じていた機能やアプローチについてヒントを見つけられたので収穫がとっても多かった。

カラーミーショップのお客様は「インターネットで何かを売っている」という以上の共通点はないので、個別のカスタマイズというのはなかなか難しい。ただ、その課題と解決方法を抽象化して機能として提供することで、より多くの価値が生み出せるというのが、こういうサービスに関わっている醍醐味とも言えるだろう。

汎用的な機能と個別のカスタマイズ、これを両立できるようにアーキテクチャと機能を練っていく。やっていくしかない！

送別会

春は出会いと別れの季節。今後のご活躍をお祈り申し上げます！

庄やの二階の治安が壊滅していたし、終電ダッシュして辛かった…

コードは https://github.com/WordPress/WordPress/blob/96b2923e625606aa174f3a2dc845e5483571dccd/wp-includes/pluggable.php#L2158 のあたり。

なんてことはないシンプルな実装。random_passwordフィルターはコアでは登録されていないようなので、このfilterを加えるとパスワードの生成ロジックをいろいろいじれるっぽい。

ランダムなパスワードを雑に生成して、それと強度と一緒にユーザに提示するというのは確かによいロジックのように思った。ついついちゃんと文字種が入っているかとかチェックしたくなってしまうんだけど、強度を見せておけばバリデーション自体はゆるくしておいてもいいのかもな、と。

Nougat 7.1.2

5Xに降ってきた。最近すこぶる調子が悪いので安定してくれるといいな。周りでは文鎮化してる人も増えてきたので毎日ドキドキしてる。

yatteiki.fm 21 & dex.fm 20

itopoidさんが盛り上がっている様子がよかった。中村氏の生活レベルの高さがやばい。京都行きたい。

メルカリのA/Bテストフレームワークの話( mercari/siberi-android: A/B testing library for Android )と、iPhoneは（？）振るとデバッグモードに入るというのが面白かった。モバイルアプリ全然わからんのでまずいなーと毎回聞きながら思う。

大江戸Ruby会議06 という素晴らしい会に参加してきたので感想等。

Docker時代の分散RSpec環境の作り方

Docker時代の分散RSpec環境の作り方 // Speaker Deck

起床に微妙に失敗したので途中から。

jokerさんの新作の紹介。テストの分散実行は、以下の3点がポイントだと考えている。

• アプリケーション（とテスト）の実行環境のポータビリティ
• テストを分散させるルール
• テスト結果の集約

それらの課題について、まずはDockerを前提とすることでポータビリティを確保。その上で、ECS・スポットインスタンス・S3をうまく利用することによって、分散ルールを単純にした上で妥当な金額の金で殴るという発想が面白かった。

My Open Source Journey

My Open Source Journey // Speaker Deck

3月から恵比寿に住むC社のjuanitoさん。

自身がどのようにOSS開発とか関わってきたのかを踏まえて、4つのフェーズ（？）においてどのように振る舞うとよいか・何を気をつけるべきかというのがとても参考になった。

また仕事とOSSについて、オープンにできるところを見つけて積極的にやっていくことは価値があり、今の自分にも求められているところだなと強く感じたのでやっていこう。

Text Editing in Ruby

shugo/oedo06: Slides for oedo06

(宇宙の均衡のために)Rubyでエディタを作っていて、プレゼンも自作エディタのプラグインという圧倒的な実装力を目の当たりに。

自分がほしいと思ったものをすぐに手を動かして作り、その過程でRubyの知らなかった機能を見つけたり、処理系への改善提案までやれるという、圧倒的で理想的な開発だなと強く感じた。

Ruby考古学II 1993~1997

基調講演のsorahさんが産まれるまでのRubyの歴史を掘り起こすということだったが、初期のRubyの文法は今のものはかなり違っていたというのがとても興味深かった。

今の文法になった時期や、コミッタ陣がMLに現れた時期など、こういう機会でないと知ることができない歴史ばかりで大満足。

また、yuguiさんの以下のツイートはとても考えさせられた。

我々のソフトウェア考古学にはメールアーカイブは重要な道具だが、slackは次世代にそういったものを残してくれるようになるであろうか

— Yuki Yugui Sonoda (@yugui) 2017年3月20日

多相型、推論、Ruby

多相型、推論、Ruby // Speaker Deck

Rubyに型を入れるために「何を犠牲にするのか」というのを、理想の型システムから考えて落としところを見つけていく過程がとてもおもしろかった。

とても丁寧に説明してくださっていたので、自分でも型がちょっとわかった気になってしまった。

その中でも、「anyを導入した上で型を絶対に書かないということは、anyの広がりをとめることができない」という話は、それこそ言われればその通りなんだけどなるほど～と口に出しそうになってしまった。

esaとRubyistと私

esaとRubyistとわたし // Speaker Deck

pplog、いつもお世話になっています！

デザイナーとしてというよりは、PdMとしてとても大事なことがたくさん詰まっているように感じて、資料公開されたら社の人たちに配って歩きたい。

Rationalを（もうちょっと）最適化してみた

こういった改善が日々のRubyの速度改善を支えてると思うと「本当にありがとうございます」という気持ちが溢れてくる。

Rationalは日常的には使わない側の人なので、直接の恩恵は受けられないとのことだったが、改善のプロセスを含めて勉強になった。

フルタイムコミッター対戦

超難問早押しクイズ大会。難しすぎるけど、コミッタ陣が唸る姿を眺めて楽しかったw

このために作ったシステムも面白そうだ。asakusarb/hayaoshi: 大江戸Ruby会議06の『フルタイムコミッター大戦』で使用した早押しクイズアプリ

高濃度雑談

thats-done-2017-03-20-oedork06-ujihisa - Google スライド

タイトルと導入の通りかなりのカオス。Cooking for Geeks と 発酵の技法 はやっぱり読まねばなと思った。

会場に thincaさん がいたそうなので、いつも一方的にお世話になっているとご挨拶したかった…次の機会に。

Ruby 2.4 Internals

笹田さんのドヤリングタイム。

Cは全くかけないといってもいいので理解が追いつかないところがおおいけど、いつか少しはわかるようになりたいな。

如何にして若き天才コミッタは生まれるのか

内輪のノリの中にしっかりとしたメッセージがあって、内容だけじゃなくてそのスタイルにもとても感動した。

育成においては、「密度を上げて時間でなぐる」というのは本当にそのとおりだと強く感じたので、身近なところからはじめていこうと思った。

あと、マジで優秀な若者たちは本当にやばいという危機感が強く残った…

Keynote

Keynote (Oedo RubyKaigi 06) // Speaker Deck

sorah氏の自慢話。rosylilly氏の話と合わせて聞くことで、ただの自慢ではなくて、正しく半生のふりかえりになったように思った。

インターネットを始める話、すごすぎて振り切られたけど応援していますｗ

まとめ

生活発表会という大江戸Ruby会議のコンセプト（？）はとても最高で、いつも最高の発表が聞けてありがとうございます。

そう。生活の中でこれだけのことをやっている人たちがいるってのをたまに忘れてしまうことがあるので、自分も生活発表できるような生活をしていかないとなと参加する度に思う。

去年くらいからいろいろやって軸がなくなってきたり、なんか文章やコードを継続的に書くこともできていないので、このあたりで一回リセットしてやりなおしていくぞ！

毎回ですが、こんな素晴らしい会をひらいてくれているAsakusa.rbのみなさんありがとうございました！

黒いカプ・コケコ

ゲームで！ カードゲームで！ カプ・コケコ キャンペーン開催！ | ポケットモンスターオフィシャルサイト

息子と一緒にセブンイレブンにいって受け取ってきた。セブンスポット限定だと勘違いしていて、買い物の帰りというとくに買うものもない状態で入店してしばらく居座ってしまった。

掃除と出品

開かずの間とは言わないけど、それなりに雑多なものを投げ込んでいる収納を整理して、いくつかメルカリに出したりしていた。

はじめて自分で買ったPC（Dynabook SSの最初の方のやつ）とか、Qiの充電器とかいろいろ。

無接点充電また盛り上がってこないかなぁ。

前回の記録がない…多分2ヶ月くらいかなぁ。

家でぐっさんの応援をしてから、今回は一人で行ってきた。来月改装があるらしく、息子はどうするかなぁという感じ。

もうちょっと読んだ気になっていたけど全然だった。生産性は良い内容だったな。

去年の年末パーティーのくじ引きで当たったホームベーカリー が届いたのでパンを焼いている。

Kenichi TAKAHASHIさん(@_kenchan)が投稿した写真 - 2017 1月 29 6:57午後 PST

Kenichi TAKAHASHIさん(@_kenchan)が投稿した写真 - 2017 1月 29 6:58午後 PST

自宅でパン焼く場合、パン切り包丁や、パンを同じ厚さに切るための器具が必要ということで、それらはニトリで購入した。器具については、おそらく同じものがamazonでも売っていて、使い勝手については大体レビューにある通りの感想。

焼き立てのパンが家で食べれるの、思っていたよりもだいぶよい体験なのとでどんどん使っていこうと思う。

ペパカレ1期生のぬまっちをCTL(Chief Takoyaki Lead)に任命しました。

意味がわからないツイートは一つだけだったので、一定の治安は維持されていたのではないだろうか。庄やは4時に閉店、始発は5時前。覚えた。

あと、初めてモーメント作ってみたけど、これはつまりtoget(ty

EC事業部新年会

昨年のふりかえりは 2015ふりかえり の通り。 今年は目標については あけおめ | けんちゃんくんさんの Web日記 にあるように手帳に書いていました。

技術面

今年は年始から ハンドメイド・手作り作品の通販、販売 tetote(テトテ) の技術支援をやっていたけれど、初めてのPythonで苦労していたような記憶がうっすらとあります。 Railsだったらこうするってのがなかなかすっきり書けなくてもやもやしながら、そういう面はチャンスだったにも関わらず、コードの量も質も今ひとつでした。 Githubの芝は去年より白い…

9月に EC事業部のCTLに就任 してからは、まずはキャッチアップと組織作りで3ヶ月が終わってしまったような感覚です。(ある程度は技術面も手をだせてはいるけど…)

発表等

社内含めて8本。複数回やっているのもありますが、純粋な技術という面ではPHP BLTのみなのでもっとがんばりましょう。

• ドラッカー風エクササイズのすすめ | けんちゃんくんさんの Web日記
• PHP BLT #2 | けんちゃんくんさんの Web日記
• ペルソナ作りで学んだソフトウェア開発の2つの成果物 あるいはチームの学習と成長 / pmjp-introduction-in-pepabo-director-meetup // Speaker Deck
• PMじゃなくてもプロダクトを育てたい!!1 / pmjp03-lt // Speaker Deck
• KPTAでふりかえり / minne-product-team-retrospectives // Speaker Deck
• PEPABO KPI Tree Workshop Ver. 01 // Speaker Deck
• Speee Cafe Meetup #03 | けんちゃんくんさんの Web日記
• メンタリング･最初の一歩 / jpengmgr-201612 // Speaker Deck

その他

2015~2016年はProduct Manager的な方々とお話させてもらう機会が沢山あったのですが、2017年は自分の今の職務により近いEngineering Managerの方と沢山話をしたいと思い、まずは場を作りました。

エンジニアリングマネージャー(とその周辺に関心がある人)が集まるSlackチームを作りました | けんちゃんくんさんの Web日記

現在、54名の方がjoinくださっています。来年はもっと盛り上げていきたいので、同じような職務を担っている方、興味のある方はjoin us!

まとめ

今年は完璧やりきったという感覚が薄い1年だったので、来年はバーンとしたと言い切れるように頑張って行こうと思います。

今年一年お世話になった皆様、ありがとうございました。来年も引き続きよろしくお願いします。

昨日、第1回 エンジニアリングマネージャー勉強会 - connpassが盛況のうちに終了しました。

特に懇親会の後半では、みんなでマイクを回しながら現状の課題や疑問を全員に問いかけ、それに全員で答えるというスタイルになり、今まで経験したことがないような盛り上がりを見せていました。

しかしながら、そのような状況でしたのでまだまだ話し足らない方や、登壇者に質問しきれなかった方もいらっしゃったのではないでしょうか。

そこで、エンジニアリングマネージャーの役割を担っている方や、そういった分野に関心のある方が集まるSlackチームを作成しました。

• Join emjp on Slack!

第2回を開催しようという機運も高まっておりますので、みなさん奮ってご参加ください!!1

プロダクトオーナー祭り2016 ～世界を創るのは俺たちだ！～ 2016/11/26(土) - POStudy ～アジャイル・プロダクトマネジメント研究会～ | Doorkeeper にスタッフTシャツと労働力を提供しました。

当日のスポンサートークでも紹介させてもらいましたが、今回のイベントグッズは POStudyのSUZURIアカウント で一般販売もしていますので是非お買い求めください。

今年も、運営関連は相変わらず fullvirtueさん さんのパワーで押し切った感じがあるので、来年はもっと仕事を奪っていきたいと思うのでした。

登壇者の皆さん、参加者のみなさん、会場提供&スタッフのgloopsさん、ありがとうございました。

｢基盤開発における各社の取り組み｣というテーマで4社のエンジニアが登壇するイベントがあり、そこでこの2年間でやってきたことを踏まえて、GMOペパボの技術基盤開発について自分が考えていることを話してきた。

会社の規模やステージが違う4社があつまると、当然のように技術基盤開発メンバーに求められるというものが違っているのがとてもおもしろかった。

懇親会ではSpeeeのみなさんといろいろお話して、たまたま自分が過去に経験したことのあるトピックだったので、その時のアプローチをお伝えしたりした。

次回お会いしたときにはどうだったか聞いてみたいので、同じようなテーマで勉強会をやるときは是非また声をかけてください！

Speee Cafe Meetup #03 - connpass

※ 資料を作りながら、｢この内容はむしろ社内の人に読んでもらいたい！｣と強く感じたので、ペパボ社の人は目を通してくれるとうれしい。

すぐバキバキの配色になってしまうからなるべく色を調整するのをやめていたんだけど、ノンデザイナーのための配色理論 を見直してリンクの色から調整してみることにした。

ついでにはてなブログとかLINEブログをみてマージンやline-heightも調整したのでちょっと読みやすくなったんじゃないだろうか。

[ HUE / 360 ] The Color Scheme Application

しばらくRuby界隈から離れていたのでリハビリを兼ねて。

CW社のElixir使い(@h3_poteto)や、@cesare と社内システムやdockerやデータ可視化の話を色々できたのでよかった。

秘匿情報を隠したビューを容易しておいて、そっちにSQLを投げることで閲覧権限を管理してるって話を聞いて試してみようと思ったのであった。

会場&スタッフの皆さんありがとうございました！

Ruby on Rails Tech Meetup - CrowdWorks Tech Meetup | Doorkeeper

前回が7/31だったので、3ヶ月位切ってなかったのか。息子と二人でばっさり。