勉強会を全部英語でやってみた

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

4/11

これが何の日か分かりますか。

ご明察、Prahaで技術勉強会 in Englishを開催した日です。

Prahaでは以前にもピザパーティや

praha-inc.hatenablog.com

LT大会を主催してきましたが

connpass.com

せっかく勉強・交流するなら英語にした方が外国語も学べて一石二鳥じゃない？という発想のもと、海外エンジニアをゲストに招いて英語プレゼン合戦を繰り広げました。

TASKEOのCEO兼エンジニア、Kamil。プロジェクト管理ツールTASKEOを開発している、ポーランド出身の起業家です。とあるイベントで一緒にビールを飲んでいたら意気投合したので声をかけてみました。

プレゼン内容は「ReactでPWAを実現するまでの道のり」。WorkboxやOneSignalの説明と実際の設定周り、苦労した点を学びました。

フォントのセンスが良いな、と思った

ちょうど英語を勉強中のエンジニア、しのっち（篠原）が続いて登壇。

全然喋れないですよ〜と、ずっとハードルを下げ続けていたものの

普通に喋れてた。やるやんけ。

ちなみにPrahaはスタートアップの0 -> 1開発に特化しているため、初期の実装作業を自動化する事が肝要です。なので様々な形式のwebサービスに対応するテンプレートを作成しており、インフラ周りにはTerraform, AWS CodeBuild, ECR, ECS, Dockerを採用しています。

今回のプレゼンはインフラ構築時に直面した詰まりポイントと解決法の紹介です。割と随所にトラップがあったようで

プレゼンタイトルは「AWS CodeBuildを用いたCIと、苦難の物語」

インフラ周りで似たような辛酸を嘗めている方は、ぜひ篠原に詳しく話を聞いてみてください。

最後にPrahaが関わっているプロジェクトの一例や、海外展開の進捗などを紹介して終わりました。

実はPrahaの海外展開のカギとなる自社サービスのリリースが来月を予定しているのですが、あー残念！ここでは書けない！気になる人はオフィスに遊びに来てね〜

圧倒的グローバル人材が集まり、インターナショナルでファンタスティックなPrahaでは英語力を問わず「モノづくりが好きな人」を募集中です。

気になった人は ↓Click here! ↓

www.wantedly.com

年功序列をリファクタリングする

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

世のみなさまを悩ませる人事評価。

この記事では、そんな人事評価に対するPraha Inc.の考え方を紹介します。

※ロードオブザリングの序章くらい長いです。

Praha人事制度の特徴１：人事評価をしない

Prahaでは人事評価をしません。

半期ごとに目標を決めて「君はAね」「君はSね」と評価する事はありません。

Praha人事制度の特徴２：階級は2つだけ

全員が「一人前」か「修行中」のいずれかに該当し、課長、部長、リーダーみたいなポジションはありません。「一人前」なら給料は全員一律なので、役員も社員も同じ給料です（例外的に1期目は社長の給料だけ0円にしてますが）

Praha人事制度の特徴３：一人前になるのに必要なのは「在籍期間」

修行中の人が一人前になるにはどうすればよいのか？一定の期間、例えば1年をPrahaのエンジニアとして過ごした人は、必ず一人前になります。細かなチェックリストを設けて「この人はスキルレベルが達したから一人前だ」みたいな人事評価はありません。

2018年創業のITスタートアップが年功序列に近い制度を導入しているのは不思議に思われるかもしれません。そこでここから先は、なぜPrahaがこのような人事制度になったのか経緯を解説したいと思います。

定期的に達成度を振り返る方法

一般的な企業で最も多く採用されているのが「一定期間ごとに目標設定して、達成度を評価する制度」だと思いますが、コレにはいくつも問題が潜んでいます。

・目標設定に膨大な時間がかかる

・目標達成度の評価に膨大な時間がかかる

・事前に目標設定しなかった行動が評価されない

・達成度を評価しにくい職種の場合、評価の納得感が得にくい 

・短期的に評価可能な目標が設定されやすく、中長期的な取り組みが評価されにくい

・自分を評価する人の顔を見て働くようになる

・本人の能力と無関係な要素に成果が影響される事が多い

・実力よりアピールの巧さが評価される

・評価されにくい仕事を誰もやりたがらない

総括すると「えらく時間がかかる割に漏れが多くて納得感がない」制度です。この制度を取り入れた3つの上場企業、10人程度の上司の元で働いてきましたが、どの上司も人事評価に非常に多くの時間を割かれているのを見て、Prahaが目指すモノづくりが好きな人が、モノづくりに集中できる環境からは程遠い評価制度だと感じていました。

「人が人を評価する」手法の亜種として以下のような制度がありますが、やはりそれぞれ無視できない問題が潜んでいます。

評価者を複数人に増やす

「360度評価」「全員でお互いを評価する」といった制度が当てはまります。一人が評価の全てを担うよりは評価に対する納得感が得られるのでしょうが、人事評価にかかる時間が爆発的に増えていくので、やはりモノづくりに集中できる環境とは言えません。

また別の副作用として、会社のカルチャーが育っていくと今度はカルチャーにそぐわない人が評価されにくくなり集団思考が強化されます。例えばスピード最優先のカルチャーが根付いた会社では「スピードを多少落としてでも品質を改善する」ような仕事に挑んだメンバーが評価されません。

市場に評価を委ねる

「自分と似たスキルセットを持った人の転職市場における年収を指標とする」といった制度が当てはまります。人事評価をアウトソーシング出来るので、確かに人事評価にかかる時間は短縮できます。

しかし市場が常に正しいとは限りません。オランダのチューリップや日本の不動産が体を張って証明してくれたように、特定のリソースが市場に過剰評価される事は多々あります。

また市場価格はあくまで平均であって、平均に対する被評価者の位置付けを測るものではありません。例えば努力を怠った未熟なエンジニアが「俺と同じ年代のエンジニアはだいたい800万円もらってるから、俺も800万円ほしい」と主張しても、正当性がないですよね。被評価者が平均より上なのか下なのか評価する必要があるため、結局は人を評価しているのと変わりません。

より精密な評価をアウトソーシングするため「転職エージェントに半年に一回行って評価されてこい」みたいなルールを作ったとしても、評価にはノイズが混入します。まず転職エージェントは転職者の年収がそのまま利益になるので、高い年収を提示するバイアスがかかります。ノルマ未達なら年収を下げてでも決めたいし、手数料割合の高いA社に優先的に紹介する事もあるでしょう（面談社数を増やす事で緩和されるかもしれませんが）

更に転職エージェントとの面談や企業面接での評価は「面接という限定的な場でのコミュニケーション能力」が優先されやすいので、ごく一部の能力が不自然に重み付けされた評価になります。何年も一緒に働いたメンバーからは評価の低いメンバーが、たった数回面談した転職エージェントに高く評価されたからと昇給したら納得できるでしょうか。

限定的な条件下の、ある意味で歪んだ評価をそのまま自社の評価に反映するのは些か乱暴だと思うわけです。

 

年功序列

上記のような理由から「人が人を評価する」制度の限界を感じて他の方法を模索し始めました。評価をしない制度の代表といえば年功序列ですが、純粋な年功序列を導入すると、何もしていない年長者が高給を貪る姿が若手の意欲を削ぐでしょう。

しかし特定の状況下では、今でも年功序列は有効な制度になり得ると考えています。

ある「時期」は年功序列が有効

突然ですが、皆さんは自動車の運転技術を一通り身に着けるのに何時間かかりましたか？AT車の技能教習が最短31時間なので、だいたいの人は40時間に収まるのではないでしょうか。

では運転経験ゼロから自動車の運転を学び始めて、40時間後に生じる技量差はどの程度でしょうか？卒業試験でドリフト走行をキメるような技術を持った卒業生は少ないはずです。では20年後に運転技術を比較した場合はどうでしょうか？差は大きく開いているはずです。

言ってしまえば当然なのですが「未経験〜初学者」など習熟期間が短い時期は、経験と成果の誤差が少ないのです。となると、年功序列は「未経験から数ヶ月〜数年」あたりまでは誤差の少ない評価方法かもしれません。

上記の観点から「年功序列が適切な時期がある」可能性に着目しました。

評価と年功序列のハイブリッド

では「人が人を評価する」と「年功序列」の良いとこ取りをすると、どうなるのか？ここからPrahaの人事制度を説明します。

まず「年功序列が適切な時期」を考慮し、年功序列を用いるのは比較的キャリアが浅いメンバーに限定します。Prahaでは「一人前」と「修行中」という2つのクラスがあると申し上げましたが、修行中から一人前に昇格する条件に年功序列を採用しています。

「修行中」クラスでPrahaに入社した方は、一定期間を経ると必ず「一人前」になり、昇給します。では「一定期間」をどのように決めているのか？ここで「人が人を評価する」制度を用います。

Prahaでは面接2~3回と週1日以上の業務委託期間を1ヶ月経て採用が決まります。その間に接点があったメンバーを選抜して「このメンバーは何ヶ月で一人前になるか？」を一斉にコールします。接点量の多さで重みを調整した平均が「一人前になるまでの期間」です。プロジェクトマネジメントで用いられる「プランニングポーカー」を「修行中」クラスの人事評価に限定して活用しているわけです。

こうする事で

・人事評価の時間を大幅に短縮

　（評価するのは修行期間を決める時だけ）

・中長期的な取り組みを阻害しない

　（そもそも評価が無いため）

・評価される側の顔色を伺う必要はない

　（期間が過ぎれば必ず一人前になり、その後は評価がない）

・育成のインセンティブが生まれる

　（育成が間に合わないと、実力が伴わない「一人前」が増えてしまうため）

といった具合に

「一般企業が人事評価にかける大量の時間を削減したうえで、部分的に評価を行いつつ、大半の時間はモノづくりに専念できる環境」が期待できます。

評価の時間を減らす＝妥協、ではない 

一人前になって以降、人事評価は基本的にありません。こう言うと稀に勘違いされるのですが、我々は「えらく時間がかかる割には不正確な人事評価」に時間を取られたくないだけで、人事評価そのものをおろそかにしているわけではありません。

面接期間の1ヶ月と、場合によっては1年近く及ぶ修行期間を経て一人前になるわけですから、言い換えれば1年以上面接をしているようなものです。それだけの時間をかけて心底一緒に働きたいと全員が思った人だけを採用しているわけですから、エンジニアやデザイナーとして、それ以前に一人の人間として常にベストを尽くしてくれると信頼しています。

そのため給料も「一人前」なら全員横並びです。給料は会社の売上に比例します。売上が伸びれば昇給するし、売上が下がれば減給です。

また売上を人数で割るという事は、人を採用すれば必ず一時的に自分の給料が下がります。必然的に「この人は将来的に会社に対して自分以上に貢献できるのか？」という観点で考えなければいけません。本当はどの会社もそうなんですけどね。横並び一律だと余計に意識しますよね。なので採用は非常にシビアに行われます。

もちろん、この制度にも懸念点は多々あります。

・セルフマネジメントに大きく依存する 

・評価されない事による気の緩み

・一人前の中での実力差に対する不公平感

・組織的な行動統制を取りにくい

今の段階では観測されていませんが、こういった問題が肥大化した時に備えた追加制度は常に検討しています。それ以前に突出した才能に出会った時、大きな事業転換を迎えた時、圧倒的な成果が生まれた時、制度も合わせて形を変えるかもしれません。

人事制度に完成はありません。会社の形にあわせて常に流動的であるべきです。しかし根底にある「モノづくりが好きな人がモノづくりに集中できる環境」はしばらく変わりませんし、今のPrahaにとっては、これが適当な設計だと考えています。

普段はカルボナーラ型ペペロンチーノとか本棚のリファクタリングの話しか書いていないので、社内で話した内容を言語化する意味も込めて、たまには真面目な話を書いてみました。

そんなPrahaの考え方に興味を持ったそこのアナタ！

ぜひ会社に遊びに来てね〜！

www.wantedly.com

平成最後のオフィス移転をみんなで祝った

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

あの頃の僕たちは

ただ全てにひたむきで

ガムシャラに生きていたんだ

意味深なポエムから始まりましたが、

弊社は今のところ順調に成長しています。

5月に社員も1人増えるしね！！！！ヒャッハー！！

そんなPrAhaは19年1月、平成最後のオフィス移転で四谷に来ました。

せっかくなので移転祝いをしよう！という事で近くの居酒屋を探していたところ、たまたま近所にチェコ料理のお店を発見。これを逃す手は無いと、日本発のITベンチャー「プラハ」の移転祝いを四谷のチェコ料理屋で執り行いました。ややこしいですね。

「帰ったらすぐブログに書くね！」と僕が言っておきながら、しこたま酔ったので完全に忘れていたのと、忙殺されて書く時間が取れませんでした。すでに移転祝いから3ヶ月近く経過しているため、当時の記憶を懸命に手繰り寄せながら書きます。

乾杯しました。それしか覚えてない。

左に写っているのがエンジニアの篠原くんで、週末はジャズトランペッターとして空間工房というバンドで演奏しています。

kukan.tokyo

松原「週末は何をされていますか？」

篠原「ジャズトランペットを吹いています」

僕もこんな回答ができる大人になりたかった。

すごい顔でシチューを見ているのがエンジニアの大関です。実は水球でIHに出場した経験を持つスポーツマンです。水球は「水中の格闘技」とも呼ばれる接触の激しいスポーツなので、非常に良いガタイをしています。四方を水に囲まれた日本では勝ち目がないので、彼には控えめに接しています。

これがチェコ料理屋の店内の様子。チェコといえば木のオモチャと、チェック柄のテーブルクロスを思い浮かべる方が多いのではないでしょうか。その通りでした。小物が非常に多くて可愛らしい空間です。

ちなみに店員さんは本当にチェコの方だったと思います。まだ日本語は勉強中のようでしたが、懸命に注文を取ろうとする姿が非常に初々しかった。間違えないようスピードを緩めて丁寧に注文しました。

これがチェコ料理。残念ながら料理名は忘れてしまいましたが、味は忘れられません。美味でした。社員数（5名）に合わせてくれたのか、ちょうどパンも5枚でした。4枚だったら確実に内紛が勃発していたので、店長の計らいに感謝です。

ちなみに僕はカルボナーラパスタが大好きなので、このお店でもすかさずカルボナーラを頼みました。ところがチェコのカルボナーラは味付けが違うのか、少し塩っぽい感じがしました。ベーコン、ニンニク、赤唐辛子も入っていましたし、何より卵もクリームもチーズも入っていない。

「これ、カルボナーラっぽくないね！美味しいけど」

「チェコのカルボナーラってこんな感じなんですかね」

「なんか色もカルボナーラっぽくない」

「ペペロンチーノみたいだけど、美味しい」

「あー確かに！ペペロンチーノっぽい味だね！」

「チェコのカルボナーラはペペロンチーノみたいな味がするのか〜」

みたいな会話を10分くらい交わしてから気づいたんですが

これペペロンチーノだわ

「生を3つ！」みたいな日本的な注文は完璧に聞き取ってくれたのに、まさかペペロンチーノが出てくるとは。

ちなみに食べかけの写真しか無いのは、ここまで食べるまで「これはペペロンチーノなのではないか」と誰も疑問を挟まなかったからです。常識を疑う。言うは易し、行うは難しです。肝に銘じました。

でもめちゃくちゃ美味しかった。

こんな感じでプラハのオフィス移転をメンバー全員で祝い、今は四谷でガンガン働いています。今度はいつオフィス移転するのかな〜。

ちなみに「ガンガン働いてます」と言いつつPrAhaは出社自由、基本は全員リモートの会社なので、ほとんどオフィスに人が居ません。僕、なんのためにオフィス借りたんだろう。

バカ人より少しだけ楽観的な社長と優秀なエンジニア・デザイナー集団のプラハでは、一緒にペペロンチーノを食べる仲間を募集中です！ぜひ遊びにきてね！

www.wantedly.com

zeplinへ愛を込めて

はじめまして、Praha Inc.デザイナーです。
この記事では、みんな大好きzeplinについて愛をしたためます。

Zeplinとは、デザイナーと開発者をつなぐ強力なコラボレーションツールです。 デザインをアップロードすることでマージンやカラーなどの情報を抽出したり、スタイルガイドを制作することができます。 

そんなZeplinの好きなところを語らせてください。

多くの主要デザインソフトに対応している

「案件・クライアントによって使用するデザインソフトは異なるけど、デザインを一括で管理したい…」

zeplinなら、Sketchはもちろんのこと、 Photoshop や XD、 figma にも対応しているので、デザインを一括で管理することができます。また、プラグインを設定を行えば、各ソフトの UI からダイレクトにファイルのエクスポートができるので、作業を止めて別のソフトを立ち上げる必要はありません。

ヒストリーが見やすい

アップロードしたデザインの履歴がかなり分かりやすいです。

デスクトップアプリでしか使用できないのですが、便利だなと思っている機能は過去のデザインを透過させることができる機能です。

これを使うことで、新しいデザインの上に重ねて差分を探すことができます。 特に実装と並行してデザイン作業を行うときに、エンジニアたちに「どこが変わったのか」 と聞かれても 一瞬で変更箇所が分かります。画像は文言の変更前後で重ねて見た様子。

画像の書き出しが楽

画像制作時にアイコンを指定することで、だれでもpng/jpg/svgで2倍3倍の画像を書き出すことができます 。頻繁に発生する「あの画像書き出しといて」という 無駄なやり取りの往復を減らすことができます.。

デスクトップアプリの細かいUX

デザイン 一覧からドラッグアンドドロップするだけで画像をフォルダにコピーできたり、 文言やURLのコピーがワンクリックで済んだりと、 かゆいところに手が届くような体験が提供されています。

簡単にデザインシステムを構築することができる（らしい）

実はまともに使ったことがないのですが、シンボルをアップロードすることで、zeplin上で コンポーネントの管理をすることができるそうです。 各デザインのプレビューでシンボルを選択すると何のシンボルが使われているかが表示されます。 エンジニアが実装する際に既存コンポーネントを使い回しやすくなりますね。 

👆👆👆👆👆👆👆👆👆👆👆👆
ここまでが愛で、ここからが愛ゆえの要求（デメリット）です。
👇👇👇👇👇👇👇👇👇👇👇👇

スマホでプレビューできない

figma や XD と比べて弱い点として、スマートフォンでのプレビュー機能がないことがやや死活問題でした。 iOSもアプリを会社で製作している時は、その場で sketch Mirror を使って確認することで事足ります。 しかし、私用のスマホが Android のため、 Sketch で作ったモバイル UI を実機で確認しようとした時にsketch Mirror も使えず、 invisionを使用しました。 Zeplinを使ってスマホでプレビューできるようになれば動き以外大体完結するのに…。

------

小規模チームでのやり取りはもちろんですが、特に中〜大規模サービスで使用すると真価を発揮できるZeplin。私はで画面のデザインだけではなく、アイコンの一覧化やイラストの整理としても使っています。zeplin号のネーミングセンスもアイコンもキュートでグッド。

以上、最近はFigmaを使った制作も楽しいデザイナーのzeplinへの愛を語る回でした。

ピザとお酒とLT合戦

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして。Praha Inc.の社長兼エンジニア、松原です。

「3月1日」

これが何の日かお分かりでしょうか。

正解です。PrAhaで初めてピザパーティが行われた日です。

知名度で圧倒的に劣るスタートアップでもピザを配れば人が来てくれるのではないか、と淡い期待を抱いてこんなイベントを作ってみました。

connpass.com

参加者に無料でピザとお酒を振る舞うことで、AIDMAモデルで言うところのAttention, Interest, Desireは全部ピザにアウトソーシングします。たらふく食べた後はPrAhaメンバーによるLT3連発と、触発された方が自由にその場でLT登壇できるセッションを用意しました。

当日の様子はこんな感じです：

https://en.wikipedia.org/wiki/Pizza

ごめんなさい、話すのと食べるのに夢中で写真を撮るのを忘れてしまったので、イメージ画像だけ貼っておきます。

LTその1：PrAhaについて

僕がプレゼンしている間、4人も社員が居たのに誰も撮ってくれませんでした。悲しい。なんて撮れ高の少ない会でしょう。代わりに僕のアイコンでも貼っておきます。

肝心のプレゼンではPrAhaのプロジェクトを紹介したり、海外展開やVCとの協業の取り組みや、社内制度の紹介を行いました。この記事では社内制度を一つだけ紹介します：

 

毎月10万円の研究開発費について

PrAhaでは全ての従業員に毎月10万円の研究開発費を支給しています。理由は「製作者の熱意に水を差したくないから」です。

良いモノを作るにはお金が要ります。調査費用、awsのインスタンス代やapiの利用料、専門家との提携や広告宣伝費、人件費、などなど。

普通の会社であれば、会社のお金を使うためには様々なプロセスを経ます。

上長を説得するために話を組み立てたり、パワポを作ったり、MECEにしたり、「それお金になるの？」と聞かれてオドオドしたり、許可が降りたら申請書を書いて、上長・上々長・上々々長の承認を待って、支払いコードが違うと差し戻されたり。まぁ色々あって運がよければ1ヶ月後にはお金が使えるようになるのではないでしょうか。

その頃には作り手の意欲は削がれています。

なんでモノ１つ作るのにこんな面倒なプロセスを経なきゃならんのじゃ！と苛立つわけです。

PrAhaはモノづくりが好きな人が集まる会社であって欲しい。

そんな会社が、費用申請みたいな事務作業で作り手の意欲を削いで良いはずがない。

そう考えた結果、全員に毎月10万円を渡して好きに使ってもらう事にしました。

あと人間というのは不思議なもので、自分のお金を使うのは気が引けるかもしれませんが「会社のお金」と思った瞬間、湯水のように使いたくなりますよね。

「ちょっと気になってたけど買うほどじゃないな」と思っていたモノを「会社の金だから買ってみるか」と手に入れたら思った以上に気に入ってしまい、使っているうちに新しいアイデアが生まれる。

こんなセレンディピティにも期待しています。

・・・みたいな会社説明をしてました。

話した内容を全部ココに書くとロードオブザリングみたいな長さになってしまうので、もっとPrAhaの事が知りたい人はwantedlyの会社ぺージへgo！

www.wantedly.com

LTその2：tellusプロジェクト（大関）

これまでJAXAなど一部の組織しか使えなかった人工衛星データを誰でも使える分析基盤を開発する「Tellus」プロジェクトの一員として、PrAhaでは雪質解析アプリケーションや、衛星画像を用いたゲームを制作しました。

sorabatake.jp

sorabatake.jp

そのプロジェクトの開発手法や技術構成などを説明しました。

これは余談であるが、僕は小学生の頃から宇宙に関わる仕事がしたくて大学でも宇宙工学を学びました。しかし紆余曲折があり宇宙から遠ざかっていた自分が、ここにきてようやく宇宙に関わる仕事ができた事に不思議な縁を感じています

LTその3：botプロジェクト（篠原）

話題に挙げておきながらごめんなさい、このプロジェクトは現在進行中で書ける事が非常に少ないのです。LTでも関連技術の説明がメインだったので、内容が気になる方はコチラをご覧ください・・・！

praha-inc.hatenablog.com

ここで一旦PrAhaのLTは終了したので、お開きかと思いきや・・・

一緒にお仕事をさせていただいているA1A株式会社のエンジニア、@mncさんが飛び込みLTをしてくれました！

www.a1a.co.jp

マルチテナントアーキテクチャに関するLTで、濃厚な内容に参加者が前のめりになっていました。マルチテナントにおいては通常テナント間の情報のやりとりは分離されますが、今回のプロジェクト特性上テナントを分離しつつ、かつ一部情報を相互にやりとりする必要が生じるため、どんな技術課題に直面したのか共有いただきました。

さて今度こそLTは終了かと思いきや別の参加者からも飛び込みLTが！

映画「イミテーションゲーム」で一般知名度が向上したであろうアラン・チューリングの半生を詳しく解説いただきました。アラン・チューリングがフルマラソンを2時間台で走れるなんて知らなかった。

ここで長かったLTセッションが無事終了。

僕は途中で帰りましたが、残った方々で残飯を肴に深夜まで飲み続けたそうです。やっぱり金曜日って良いですね！

そんなPrAhaではエンジニア・デザイナーを大募集！深夜までお酒を飲めなくても全く構わないので、少しでも気になった方はぜひお声がけください。

またピザパ開催するので遊びにきてね〜

www.wantedly.com

AWS Lambda(for Ruby2.5)で画像合成をやってみた！

はじめに

株式会社プラハ(PrAha)のエンジニア、篠原です。

AWS re:Invent 2018で、AWS Lambda(for Ruby2.5)がリリースされましたね！

早速使ってみました。

AWS Lambda(for Ruby2.5)の詳細はこちら↓ https://aws.amazon.com/blogs/compute/announcing-ruby-support-for-aws-lambda/

今回はAWS Lambda(for Ruby2.5)で、画像に任意のテキストを合成するデモをハンズオン形式で共有します！

AWS Lambdaで合成した画像↓

今回の記事のリポジトリはこちら↓

https://github.com/praha-inc/composite-image-ruby25

想定読者

• AWS Lambdaを知っている、もしくは使ったことがある人
• AWS Lambdaを使ったことがないRubyist(これを機に使ってみましょう！）
• AWS Lambdaで画像合成をやってみたい人
• AWS Lambdaを使ってみたい人
• 株式会社プラハに興味がある人

ん？プラハってなんだ？という方はこちらへアクセス！ https://www.praha-inc.com/ Wantedlyもやっています！https://www.wantedly.com/companies/praha-inc

準備

AWSアカウントを持っていること

AWS Lambdaとは

公式: https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html

簡潔にまとめると、自分の書いたプログラムを任意のタイミングで実行してくれるサーバです。

AWS Lambdaには無料枠があります。

1,000,000 件のリクエスト
400,000GB秒

(2019年2月15日現在)

単純に考えると

• 100万件のリクエストを並列に捌ける
• メモリ(RAM)1GBのPCが400,000秒動作する

上記のマシンを毎月無料で扱うことができます。 参照: https://aws.amazon.com/jp/lambda/pricing/

割り当てるメモリ量は関数に応じて変更可能です（最小128MB~最大3008MB)。

無料で画像処理のみ行うマシンが欲しい場合、これで十分なのではないでしょうか。

AWS Lambdaを使用するユースケース

例えば、以下のようなユースケースが考えられます。

Heroku(APIサーバ)からLambdaを実行し、結果を受け取るようなケースです。

Herokuのスペックは無料枠だとRAMが512MB(2019年2月20日現在)。

そこで、画像合成の処理のみをLambdaに委譲し、Herokuの負担を抑えられることが期待できます(要検証)。

画像合成をするLambda関数を作る

では、Ruby2.5で画像処理を行うLambda関数を作ってみましょう！

Lambda関数を作成する

AWSマネジメントコンソールのLambdaにアクセス

https://ap-northeast-1.console.aws.amazon.com/lambda/

Lambda関数を作成しましょう。

入力項目	設定値
名前	CompositeImageRuby25
ランタイム	Ruby2.5
ロール	既存のロールを選択
既存のロール	lambda_basic_execution

関数を作成ボタンを押下。

作成したLambda関数の詳細ページが表示されます。

また、作成したLambda関数はCloudWatchLogsにアクセス可能なことがわかります。

画像合成後のファイル保存先のS3バケットを作成する

AWSマネジメントコンソールからいい感じにぽちぽちっと。 https://console.aws.amazon.com/s3/home?region=ap-northeast-1

※ここで作成したバケット名は、後述するプログラム上で扱います。

画像合成プログラムの実装

お好みのエディタを立ち上げて、まずはLambdaで実行するプログラムを書いていきます。 プロジェクトのディレクトリ構成は、先程示したリポジトリを参照して下さい。 (再掲)https://github.com/praha-inc/composite-image-ruby25

Rubyはバージョンを2.5系を使用してください。 (バージョンが違う場合、Lambda環境で実行できない可能性があります）

環境構築

$ mkdir composite_image_ruby25 && cd composite_image_ruby25
$ gem install bundler
$ bundle init
$ vim Gemfile

source 'https://rubygems.org'
gem 'aws-sdk-s3'
gem 'mini_magick'

$ bundle install --path vendor/bundle

画像合成プログラムからAWS S3へPutするための認証周りの設定

$ direnv edit . // direnvを使用していない場合は.env.copyを参照して環境変数を設定してください
$ direnv allow

export AWS_ACCESS_KEY_ID=AWSマネジメントコンソールで発行したID
export AWS_SECRET_ACCESS_KEY=AWSマネジメントコンソールで発行したSECRET

画像合成プログラムを書く

任意のテキストの画像合成後、S3に画像をアップロードします。

require 'aws-sdk-s3'
require './image_helper'

def lambda_handler(event:, context:)
  s3 = Aws::S3::Resource.new(region: 'ap-northeast-1')
  bucket_name = 'YOUR_BUCKET_NAME'
  file_name = 'helloworld.png'

  # Upload Image to S3
  file = ImageHelper.build(event['message']).tempfile.open.read
  s3.bucket(bucket_name).object(file_name).put(body: file)

  # Get Image from S3
  object = s3.bucket(bucket_name).object(file_name)
  {
    statusCode: 200,
    url: object.public_url,
  }
end

# for exec local
if __FILE__ == $0
  lambda_handler(event: { 'message' => 'Hello, PrAha!' }, context: nil)
end

ローカルで実行

$ bundle exec ruby lambda_function.rb

AWSマネジメントコンソールのS3を参照して画像がアップロードされていることが確認できればOK

画像合成プログラムをAWS Lambdaにデプロイ

ローカルからAWS Lambdaにデプロイするための設定をする

先程取得した、AWS_ACCESS_KEY_ID、とAWS_ACCESS_SECRETをaws-cliの設定ファイルに記述します。

$ aws configure
AWS Access Key ID [****]:
AWS Secret Access Key [****]:
Default region name [ap-northeast-1]:

ローカルからAWS Lambdaにデプロイ

aws-cliの設定後、プロジェクトディレクトリのルートで下記を実行し 先程作成したLambda関数(CompositeImageRubuy25)にデプロイします。

$ zip -r function.zip lambda_function.rb image_helper.rb assets vendor
$ aws lambda update-function-code --function-name CompositeImageRuby25 --zip-file fileb://function.zip
{
    "LastModified": "2019-02-20T10:14:42.632+0000",
    "Version": "$LATEST",
    "Runtime": "ruby2.5",
    "FunctionName": "CompositeImageRuby25",
    "CodeSize": 5658411
    ...略
}

動作確認

AWSマネジメントコンソールで先ほど作成したLambda関数を開いてください。

デプロイに成功すると恐らく以下のように表示されていると思います。

テストを実行

テストを行う前に、AWSマネジメントコンソールの右上からテストイベントの設定を行います。 「テストイベントの設定」を押下してください。

テストイベントの設定で以下のように入力してください。 入力後、作成を押下。

作成後、「テスト」を押下してください。

恐らくエラーが発生するので後述の章で対処していきましょう。

エラーの対処

タイムアウト時間の設定

以下のようなエラーが発生する場合

Lambdaの実行時間が足りないので、基本設定でタイムアウト時間を10秒にしましょう。

再度、「テスト」を押下してください。

S3への書き込み権限の付与

以下のようなエラーが発生する場合

LambdaからS3への書き込みをする権限がないため、書き込みを可能にするよう権限を付与します。

LambdaからS3へのアクセス権を付与する

「実行ロール」を確認してください。

「実行ロール」からカスタムロールの作成を押下。 ページが表示されたら、任意のロール名を入力（ここでは lambda_write_s3)。「許可」を押下。

作成後、以下のように表示されます。

「lambda_write_s3」をクリックし、「ポリシーをアタッチします」を押下してください。 「AmazonS3FullAccess」にチェックボックスを入れて、ポリシーのアタッチを押下してください。

AWS Lambdaのマネジメントコンソールに戻り、ロールを新規に作成したものに変更し、右上の保存を押下してください。

以下のように表示されればOKです(LambdaからS3へのアクセス権が付与されたことがわかります)。

再度、「テスト」を実行

実行に成功することを確認します。

最後に、画像がS3にアップロードされていることが確認できれば完成です！

おわりに

今回はAWS Lambda(for Ruby2.5)で画像合成を行いました。いかがでしたでしょうか。 Lambdaを使ったことがない人、Lambdaで画像合成をやってみたい人の参考になれば幸いです。

不明点、指摘点などありましたらコメントをお待ちしております！

次はAWS Lambdaで動画合成をやってみた、を書く予定です！

Happy Coding!

いきなりスカッシュ

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

4年間働いたリクルートを退職して今はスカッシュをしています。

最近この前振りがパターン化してきた気がします。

 

 

 

みなさん、スカッシュというスポーツをご存知でしょうか？

僕は最近初めてこのスポーツを知りましたが、要は四方を壁に囲まれた状態で行うテニスです。壁に向かって黒いゴムボールを打ち付けて、床に2バウンドする前に壁に打ち返します。先に横の壁を打ってもよし、なんならピンボールみたいにボコボコ壁をバウンドさせても良い。打球の不規則な軌道を予測する感覚が他のスポーツとは大きく異なり、今やPrAhaは社員の８割がスカッシュ経験者という空前のスカッシュブームが起きています。

 

（社内slackで異彩を放つsquashチャネル）

 

 

PrAhaは出社時間も退社時間も自由な会社なので、15時くらいに一度仕事を切り上げて、スカッシュをして、汗を流してから仕事を再開することにしました。

こんな感じで、スカッシュコートは四方を壁に囲まれています。左上の小さな点がゴム製のスカッシュボールです。テニスやバドミントン等のラケット競技は力任せに叩くと簡単にアウトになってしまいますが、スカッシュボールは思いっきり壁に打ち付けても思ったほど弾まないので、全力でぶっ叩けます。日々のストレス解消になりますね！

 

ただ写真を見てお分かりいただけると思うのですが・・・

 

狭い密閉空間を肉体的ピークに達した成人男性2名が鈍器を振り回しながらダッシュするスポーツなので、割と危険です。スカッシュボールが背後から耳を掠めてカッ飛んでいく度に「もう少し上手い競技形態があったのではないか？」と疑念が止まりません。

ちなみに僕は写真右側の大関くんに顔面をラケットで強打されて悶絶しました。本人は「ヒッハハー！ごめんなさい！」って笑ってたけどアレは本当に痛かった

 

（オーストラリアンフォーメーションを試したり） 

 

壁際を攻められて苦しんだり（壁スレスレに打たれると、まず返せない） 

 

（五感を奪われたり）

スポーツの締めくくりはジャグジー！

こんな感じで汗を流したあとは施設備え付けのジャグジーでサッパリ！体は完全に寝る準備が整っていますが、まだ17時台なのでココから仕事再開です。

 

明るいうちにスポーツを楽しんで、風呂に入ってから、好きな時間に仕事に戻れる。自分たちの会社を作ってよかったな〜、と思う瞬間の一つです。