新年あけましておめでとうございます、清水 (@takayuki_shmz) です。 年末にFiNCのエンジニアリングマネージャー陣で振り返りブログを書くこととなり、その先人を切らせてもらいます。このあと android / ios / backend / sreと続いていきます。 今回は自分はVPoEとしての振り返りということで主にエンジニア組織に関することを書こうと思います。 2019年は登壇も3度ほど機会をいただきましたが、登壇の内容につきましてはSpeaker Deckのリンクを貼っておくのでそちらからご覧ください。 Presentations by takayuki shimizu — Speaker Deck 2019年当初の目標から振り返る年はじめに組織戦略と名うって決めた重点項目は以下の3つでした。 若手・リーダー育成アウトプットFirst全員採用そもそもなんでこの3つ？とい

qsona (twitter) です。以前、7,600行のコードを安全にこの世から抹消した話 という記事を投稿しましたが、今回はそれよりもずっと泥臭い話を書きたいと思います。あまりテクニカルな話はありませんが、現場における取り組み・試行錯誤の経過を読んでいただければ幸いです。 たくさん消しました、がんばりました〜背景肥大化するRailsサービスFiNCはマイクロサービスを指向しており、主にRuby on Railsで書かれたサービスが30個ほど存在します。しかし、FiNCアプリのメインとなるRailsのサービスは、テーブル数800を超える大きなサービスになっています。 FiNCのサービスは2014年から書きはじめており、かなり初期の段階(2015年)からマイクロサービス化を意識してきました。にもかかわらず1つのサービスが肥大化している理由はいくつかあります。 最初の1〜2年ですでに大量のコ

みなさま、こんにちは。FiNCデータ分析グループの湯通堂です。 先日、「グロースチームを作ってみてわかった、成果を上げるために最も重要なこと」というタイトルで、データ分析と施策実行を担うチームにおいて、なぜKPI設定が重要なのか？というLTをさせていただきました。 こちらがその時の資料です。 伝えたかったこととしては、何をするにしても目標設定と目標の定期的なメンテナンスが重要だ。ということです。 LT後の懇親会では、様々な会社の方から 「この考え方に至るまでにどんなことをしたんですか？」 「スライド全部あるあるで、ずっとうなずいてました」 「最近グロースチームを作ったのですが、どうしたらよいですか？」 等々の共感や相談をいただき、非常に嬉しかったです。 データ分析の業界は意外と狭い業界なので、データ分析に携わる職業の方とは、積極的に意見交換したいです！

はじめまして。7月から業務委託として、FiNCのサーバーサイドエンジニアを担当している@yhirano55です。最近、来年3月に開催予定のRails Developers Meetup 2019の準備を始めました（次回は3トラック同時で進行する予定です）。 本記事では、Railsエンジニア向けに npm initから始める、TypeScript対応の Reactボイラープレートの作り方を紹介します。チームや組織で共通するボイラープレートがあると、SPA（Single Page Application）を量産する際に生産性が爆速になるのですが、ちょうど最近、Reactボイラープレートを作る機会を得まして、その過程で得られた試行錯誤を記事としてまとめてみました。 モチベーション Ruby on Railsを通してフロントエンドの実装をしていると、各種設定は、webpackerを使って簡単（暗黙

UIT#3 The “Backends for Frontends” sharing

ふむふむ、なるほどと思っていたのですが、いざ入社してみるとあらびっくり、僕がマネージャーの立場でした。 入社してみるといきなり部下がいたのです。 ※もちろんマネージャーだから偉いとかではなく、あくまでも役割です。 しかも、お気付きの通り部下が外国人なんです。笑 自分のプロフィールを補足すると、 留学経験はなし、高校の時に英検２級をとったというくらいです。 入社後３ヶ月でやったことを振り返ってみると （もちろん開発）開発WBS作成チームのOKR作成チームメンバーとの隔週の1on1バグ対応と後処理（各所への報告等）etc…あっという間の３ヶ月でした。 そこで得た知見を３つ共有したいと思います。 1. ベンチャーにおいては本当に新卒とか中途とか関係ない最近の世の中の流れとして、いわゆる大手ではなくベンチャー企業に就職する人が増えているように思います。 その理由の一つに「若いうちから活躍できるから

TL;DR- RuboCop良いよ - 入れるだけだと誰も使わないよ - 運用フローに入れると良いよ - 千里の道も一歩からだよ RuboCopとはRuboCopはコーディング規約に従っているかをチェックし、コードの品質を保ってくれるgemです。 RuboCopのイメージ例えば以下のようなrubyとしてはあまり良くないコードだった場合に、RuboCopはルールに沿って問題点の指摘や自動修正を行ってくれます。 これ以外にもRuboCopは多様なルールをサポートしており、その中にはバグりやすいコードを回避するようなルールもあります。 RuboCopを使う事でコーディング規約に沿っていないコードや、バグを含んだコードを自動である程度抑制でき、レビュー等でそれらの指摘する手間を大きく削減できます。 導入方法gem install rubocop するか、Gemfileに書いてインストールしてくださ

2017 - 01 - 12 もうNativeOnly開発者はいらないのかもしれない 駄文 ReactNativeさえあればもう Android / iOS 固有のスキルはいらないんじゃね？と思い始めてしまいました。 Qiita他を見る限り、 Web専門の人が結構ReactNativeでアプリを組み始めている んですよね。 間違いなく自分のReactNativeより上手に組んでいるでしょう。 となると、もう Java /Swift/Obj-Cでアプリを組む必要ってない＝ガチNativeしか開発できない人はもう不要になるのではないかという気がしました。 OS固有環境(以下ガチNativeと呼びます)とくらべてReactNativeで開発するメリットとして クロスプラットフォーム View構築が楽 間違いなく iOS -AutoLayoutよりは楽 Android でも同じViewの使い回しは

みなさんは言いたいことがあるのにうまく伝えられなかったり、相手が納得してくれなかったりして悩んでしまった経験はありませんか？　これはとてもストレスフルですよね。こうした問題を回避するための“より良い伝え方”の1つにアサーションと呼ばれるコミュニケーションスキルがあります。 もう少し詳しく説明すると、「相手を不快にさせず、相手に自分の言いたいことを伝え、なおかつ相手が納得しやすい伝え方」です。アサーションはさまざまなところで紹介されているので、みなさんも言葉は聞いたことがあるかもしれませんね。今回はそのアサーションの技法の中の1つであるDESC法を紹介します。 アサーションとは アサーションは1950年代の米国で、自己主張が苦手な人たちへの心理療法から生まれたコミュニケーションスキルです。自己主張することが非常に重要な意味を持つ米国で、それが苦手というのは日々の暮らしを困難にしてしまいます。

2016/10/26 現在26歳で業界歴は6年ほど。 まあ、若いと言えば若いであろう。実際色んな人と話をして年齢の話になると若いねとよく言われる。 が、もうそこまで若いとは言えないだろう。 あと3ヶ月も立つと自分も27になる。新卒の子や学生からしてみると、もはやおっさんであろう。 とまあ自分レベルの人間が自分をおっさんと言うと色んな人に怒られると思うので、おっさん予備軍とでも呼称するか。 で、そのおっさん予備軍として今後若く優秀なエンジニアと対抗する際に何が出来るのかと振り返ってみたが、何も残せていない。 例えば、 OSSで何か作っているか 有名OSSにContributeしているか CxOや役員などの経営者経験をしているのか OSSは趣味で作ったものをGithubで公開はしてはいるが、Star数が0のところを見ると利用されてるとは言えないだろう。 そんな感じで若く優秀な人からすると引っ込

ぼくは5年程前に、本格的に英語の勉強を始めた。英語関係の参考書は有名どころはだいたい試し、ECCでの英会話授業、フィリピン英語留学、Skype英会話も経験し、映画やアプリなど多くのツールも試した。その甲斐あってか、今では毎日 英語を使って仕事をしているし、TOEICも900点を超えた。 ただ振り返れば、英語が話せるようになるまでにかなり時間をかけてしまい、数倍効率良く勉強ができたと思うところが多い。今回はその反省を踏まえ、怪しい方法抜きで現実的に、最短ルートで英語を話せるようになる方法をまとめてみようと思う。 最短ルートで現実的に英語が「話せる」ようになる勉強法まとめ目次を兼ねて、ざっくりと英語勉強のステップを紹介する。決して楽ではない。しかし最短ルートだ。 ステップ1：基礎的な英単語・文法を一気に詰め込む ステップ2：そのまま使える英語のフレーズを一気に覚える ステップ3：実際に英語を話

Housmart高松です。 最近、ビジネスの世界でデザインの重要性が増してきているという話を良く聞くようになってきたのではないでしょうか？ 5/17に品川の Microsoft のオフィスでシリコンバレーのデザイン会社である btrax 主催のイベント 「Design for Innovation 2016」 が開催されました。 今回このイベントに参加してきたので、簡単な参加レポートと雑感をまとめます。 「DESIGN ≠ Design」 btrax の Brandon CEO のオープニングでの言葉です。 日本でデザインというと、見た目を美しくする仕事、きれいなチラシを作ったりWebページのHTMLやCSSを作ってくれるいわゆる「デザイナーさん」のことをイメージしがちです。それは狭義の意味での小文字の”Design”。 一方で、 世の中の様々な事柄をデザイン的な感性とアプローチで改善して

Housmartの宮永です！ 先週（4/18 - 4/22）は熱海で開発合宿（スプリント）を開催しましたので、 そのことについて書きたいと思います。 どんなに素晴らしいオフィスでもずっと同じ場所で作業をしていると 何となく集中力がなくなったり、生産性や創造性を劣化させていたり、というか根本的に飽きてきますよね（笑） ってことで試しに今回は環境を変えて熱海でスプリントをしてきました。 合宿スケジュール 過去ブログ(スタートアップのCTOになって2ヶ月で作った開発サイクル)でもご紹介させていただきました通り、弊社は1weekスプリントを採用しております。 事業サイドのメンバーはオフィスを離れられない事情もあったので、 スプリント計画だけ（月曜日）オフィスで過ごし、火曜ー金曜を男３人で熱海で過ごしました。 ※開発チームの自由な行動をいつも許容してくれる針山さん、三瓶さんにはいつも感謝ですm(__

Housmart高松です。 「ログ分析基盤」というと、すでにかなり大きいサービスでの事例がSlideShareなどで共有されているのをよく目にしますが、 立ち上がったばかりのサービスに適用するには”too much”な内容となっていることが多いかと思います。 そこで今回は、まだユーザが少ないフェーズでも 「お金と時間をあまりかけずに」 導入できるログ分析基盤について、カウルでの事例をご紹介いたします。 小規模のサービスであってもログをしっかりと収集・分析してサービスの改善に役立てていくことは非常に大切なことです。 一方で、データ収集のためのJavascriptの開発やWebサーバの構築と管理、データストアやデータ処理基盤の選定や設定などに専属で人を割くことができないのもスタートアップの実情ではないでしょうか。 そこでカウルでは 安価に利用できるSaaSをいくつか組み合わせることで、簡単に始

Housmartの松江です。 Railsでアプリケーションを開発していると、管理者機能や周辺機能も含んだ巨大なプロジェクトになってしまうこと や、 分割したプロジェクト間の管理・同期が煩雑になってしまうこと ありますよね。 今回は以下の要望に応えるべくカウルの開発現場で実施した、Railsプロジェクトの分割と運用をご紹介します。 巨大な1つのRailsプロジェクトにせず、管理機能部分を分けたい 分割後はプロジェクト間で必要なロジックを共有したい 複数のRailsプロジェクト間でロジックを共有したい状況 不動産を扱うカウルの裏側では以下のような多種多様なデータを扱っています。 詳細情報: 最寄り駅・エレベータの有無・ペット可否など 部屋情報: 間取り・方角・契約の進行状況など 上記を社員が効率よく管理するため、管理者用のアプリケーションが別途用意されています。 ユーザ用のRailsプロジェク

Housmart高松です。 先日、テレビ東京のWBS（ワールドビジネスサテライト）で弊社サービス「カウル」をご紹介いただきました。 前編ではテレビ放送に向けたAWS上のシステムの事前準備について説明しました。後編では放送当日と事後の振り返りについて書いていこうと思います。 ※前編をご覧になっていない方はこちらを先にご覧ください。 WBSサイト(不動産流通に革新は起こるか): http://txbiz.tv-tokyo.co.jp/wbs/feature/post_107290/ 仲介手数料無料の不動産サイト「カウル」: https://kawlu.com/ 内容 前提 [前編] 事前準備 [前編] 放送当日 直前の放送時間変更 放送内容 アクセス数まとめ 振り返りとまとめ アクセス予想振り返り まとめ 3.放送当日 直前の放送時間変更 WBSは通常23時からの放送なのですが、この日は前の番

今日はとても素敵な一日になりました。 私を含めたチームメンバー9人が、一つの技術的な話題に対して30分話し合う会を開けた日。 何より嬉しかったのは、この会そのものが、メンバー間でのやり取りからほぼ自然に出てきたことなんです。 回想：本当に「スモール」だった時期 私の今のチームは総勢9名のチームなのですが、大まかに分けても4種類くらいののサービス（検索から予約、管理画面も。）を担当している、プロダクト的にはかなりマッチョなチームです。 これらのサービスはどれも「似ている」のですが、歴史的にバラバラに作られてきたため、アーキテクチャやフレームワーク、コードの思想は全部バラバラです。 以前は、このバラバラなプロダクトを、チーム内でもバラバラに担当がついていて、2～3人の少人数チームが3つ、という状態でした。 「似ている」ものをバラバラに作っているので、同じようなものをお互い作っていたり、同じよう

不動産広告には、パッと見ただけではなかなか「良い不動産」なのか「悪い不動産なのか」見分けが付きにくい広告があります。今回はそんな広告の注意して見て頂きたいチェックポイントをご紹介します。 前面道路が狭過ぎないか 良くあるのは前面道路が狭過ぎる物件です。前面道路が狭い一番のデメリットは「車が通らないこと」です。自動車が通る為には前面道路の広さは最低でも３m以上欲しいところです。 自動車を持っていない人でも、車が通らない物件を買うことはデメリット尽くしです。まず、救急車や消防車などが家の前まで来る事が出来ません。万が一火事になったら、消火活動にもの凄く手間取ることになります。 また前面道路が狭い物件は、家の建設・リフォーム・解体にも多額の費用がかかります。工事車両を家の前まで持ってくる事が出来ないため、材料は全て手運びになり人件費が膨れ上がります。工事の種類によってはそ、もそも対応出来ない場合