職場の同僚の素晴らしさに後から気付いても、その時にはもう居ないから今を精一杯生きよう、と
過去に共に働いたエンジニアチームで歴代最高のチームというのがあったが、そのチームで働いていた当時はそのことに気付いていなかった。今現在、目の前に居る同僚達も後になってから「歴代最高のチームだったな」なんて懐かしく思うかもしれないし、今を大切にしなければ、という話。
英語圏での転職を頻繁に繰り返したのでそれなりにバラエティーに富んだエンジニアチームで働いてきた。「英語で多国籍なエンジニア集団の中で働いている」と言っても全部が全部、素晴らしいチームな訳がない。今から思い起こしても「あれはダメなチームだったな」というのもある。そんな中で歴代最高のチームというのがあって、現行チームを別にすればシンガポールに在住していた際に勤めていたあるITスタートアップのエンジニアチームだ。主要メンバーは私を含めて５人で、それぞれアメリカ人、ベトナム人、ポーランド人、ブラジル人、日本人（私）の多国籍チームだった。
５人はちょっとずつ専門性が異なっていて、誰かひとりが欠けてもプロジェクトが成り立たないような状態でかつ、それぞれの技術スキルが高く、不思議に調和が取れてプロジェクトはガンガン進んでいた。エンジニアひとりひとりの生活スタイルも国際性に富んでいて、誰もが何カ国も移住してきた経験を持っていた。彼らとのちょっとしたランチでの会話もなにかと刺激的だったのを覚えている。
今でもその会社はシンガポールで存続しているがオフィスに行ったとしても私が経験した素晴らしいチームは跡形も無い。当時のエンジニア５人全員がシンガポールを離れて別の国に移住しており、ひとりはスイスに、ひとりはオーストラリア、ひとりはアメリカ、ひとりはロンドン、そして私は今ベルリンにいる。時々SNSなんかで「あの時なんかオモロかったな」とメッセージを送るとみんなが「そうだったよね」となる。でももうあの５人が同じ国に住んで、同じ会社で同じプロジェクトで仕事をするなんてことは無い。あの時、奇跡としか言いようのないタイミングで同じ職場に偶然に集まった５人だった。
じゃあ当時はそんな環境に「いいなー。サイコーだなー」と思っていたか、というと決してそんな事なかった。個性派集団であることから「なんでこいつらは言うことを聞かねーんだ」とイラつくことが多々あった。しかもそれは５人全員が他４人に対して思っていたことだった。
英語圏でのエンジニア職は人材流動性が高い。会社もあの手この手でいいエンジニア人材を会社に引き留めようとするが、それでもチャンスや刺激を求めてエンジニアは職場と転々とする傾向がある。いい人材ほど自分が世界市場において「どこ行っても食えるわ」という自信があるので、気の向くままにポンポン居住国も職場も変えてしまう。そういう人材を留まらせる手段はほぼ無い。だからこそ素晴らしいチームメンバーを大切にしなければならない。「こいつスゲー」と思う人と仕事ができたら、そんな人と共に働くことができる環境はあっという間に終わってしまうので今を大切に思った方がいい。
というようなことを考えていたら、私にしても今の職場の多国籍エンジニア達を数年が経過してから「歴代最高のチームだったな」なんて思うかもしれないので大切にしよう、と。
実はこのエントリーは下書きを書いてから、ずっと公開しなかった。書いてることは真実であり、私の意見に違い無いが、説教臭くて、私の嫌いな自己啓発本の香りがしてイヤだったからだ。ところが先日、同僚エンジニアのひとりが会社を去ってしまって、ここに書いた思いが一層強くなったので「やっぱり公開しよ」と思ったのだった。
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
ショボい企画を持ってきたカッコ悪いようで、実はとてもカッコいい青年に見習う
あるインド人青年が彼曰く「スゲー企画」があるから、それについて意見が欲しい、となって会社の昼休みに会って意見した。ぶっちゃけその「スゲー企画」とやらは強烈なショボさだったのだが、そんな彼の態度はとても尊敬に値するし見習おうと思った話。
職場の同僚インド人エンジニアKが「インドから来た若い男で『いい企画があるのでちょっと見て、エンジニアとしての意見が欲しい』って言われているが、ひとりで行くのはイヤだから一緒に来てよ」と言われた。ひとりで行くのがイヤという理由で他人を誘うのはいかがなものか、と思っていたのだが、なんか流れで私も参加することになった。
職場近くのカフェに行くとその彼が居た。見た目だけで異人種の年齢を推測するのはなかなか難しいが、きっと彼は若い。
で、さっそく彼の「スゲー企画」のプレゼンが始まった。私の正直な感想としては「しょうもなー」だった。まずプレゼンが洗練されてないし、その内容も一昔前のアイデアを「え？いまさら」感が半端なかった。その企画自体はあえて詳しく説明するまでもなく、そこがここで書きたいことではない。企画はまーよくあるヤツと思っていただければいい。
その青年は自分でそれなりのプロトタイプを作って、私達に見せながら下手なプレゼンで「これはいずれスケールして、フェイスブックやグーグルを追い越す」と言っていた。同僚のKと私が率直な意見を言った後、青年と分かれて職場に戻った。青年と別れた後の帰り道でK曰く「あまりにもイケてなさすぎて、どこから指摘していいのか迷っちゃったよ」と。企画がイケてないのは一目瞭然だ。だからその青年は意見を求めていた。正直、その青年に会った当日は「しょうもないことに無駄な時間使ったな」ぐらいの感想でしかなかった。
ただそこから２，３日経ってなんだかモヤモヤと心に残るものがあった。そして伊藤穰一の「9プリンシプルズ」を読んでついに腑に落ちるモノがあった。
私は青年の企画のショボさに目を向けるのではなく、彼の素晴らしい態度から学ばなければならなかったのだ。
実はこころのどこかで、ショボい企画でも屈託なく突き進んで作ったプロトタイプをどこの誰かも分からない日本人にまでプレゼンしてしまう、あの青年を羨ましいと思っていた。ウェブ上には他人の行動に対する斜に構えた評論で溢れている。しかしどう考えても実装するヤツの方が、批評するだけのヤツなんかより断然カッコいい。
その青年は一見するとなんかかっこ悪い奴に見えてしまいがちだが、じっくり考えるとカッコいい男だな、と。どんなに少なく見積もってもこんな「ダメな企画持ってきた奴がいたわー」なんてブログ書いてる私の数千倍はカッコいい。
あの青年の企画はそのままではきっと成功しない。ただあの青年と同じ態度で挑む人達の中から次の成功が生まれる。（「同じ態度で挑む人達の中から」と言っただけで、「彼が成功する」とは言ってない）
私のMacBookのフォルダにはやりかけて途中で放置した個人プロジェクトがわんさとある。もしそんな放置プロジェクトをあの青年が閲覧したら、言葉には出さずとも、こう思うに違いない。「なぜ完遂して、公開しないのか？」「批評されるのが怖いのか？」「面倒で怠けているだけだろ？」「実装してなんぼのエンジニアって分かってんのか？」と。
という訳で私も彼に見習い、個人プロジェクトのひとつを完成させて公開させることにした。公開すればボロクソに言われたり、辛辣な意見を受けてヘコむかもれない。それでも「言う側」より「言われる側」に立つほうがずっと意味があるからだ。
今、地球上でもっとも頭脳明晰な人のひとり伊藤穰一が「実装！」「実装！」と考える理由は9プリンシプルズにある。とてつもなく情報量の多い書籍なので、じっくり考えてから書評を書くつもり。
９プリンシプルズ 加速する未来で勝ち残るために (早川書房)
- 作者: 伊藤穰一,ジェフハウ
- 出版社/メーカー: 早川書房
- 発売日: 2017/07/15
- メディア: Kindle版
- この商品を含むブログを見る
Whiplash: How to Survive Our Faster Future (English Edition)
- 作者: Joi Ito,Jeff Howe
- 出版社/メーカー: Grand Central Publishing
- 発売日: 2016/12/06
- メディア: Kindle版
- この商品を含むブログを見る
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
Rails 5 モデルの条件付きbefore_destroy
Rails 5 でモデルに条件付きbefore_destroyを設定する方法。
例えばPostモデルがあって、レコードを消す前に条件判定をするとする。ステータスがアクティブだったら消さない。アクティブ以外の場合だけレコードを消してもOkとしたい。
そこで以下のようなコードを書いても動かない。
class Post < ApplicationRecord before_destroy :do_not_destroy_active_post private def do_not_destroy_active_post return false if active? end end
どうすればいいのかはここ(Active Record Callbacks)に書いてある。
If the before_validation callback throws :abort, the process will be aborted and ActiveRecord::Base#save will return false. If ActiveRecord::Base#save! is called it will raise an ActiveRecord::RecordInvalid exception. Nothing will be appended to the errors object.
動くコードはこんな感じになる。
class Post < ApplicationRecord before_destroy :do_not_destroy_active_post private def do_not_destroy_active_post throw(:abort) if active? end end
エラーメッセージを加えたければ、throw(:abort)をする前にerrors.addすればできる。
ほとんどお約束みたいなことで、現行のプロジェクトを検索してみたらたくさんthrow(:abort)が引っかかるが、全てこの条件付きbefore_destroyだった。私自身の経験としてもこれ以外でthrow(:abort)を使ったことが無いのだが。。。
結論としてはthrow(:abort)したらOkってことなんだけど、他の技術ブログでRails４からの歴史的経緯とか長々と書いてあって「ググってこういう記事に辿り着いた人ってそんなゴチャゴチャと昔話しまで求めてないのでは」と思ったので簡素に結論だけ書いて終わりにしたい。
