どうやってマイクロサービスを "開発" する？ - 開発速度を落とさないための試行錯誤 rejected Abstract 本発表では，マイクロサービスアーキテクチャを推進するにあたって無視できないであろう，開発生産性・開発スピードにフォーカスし，実際にマイクロサービス化が進んでいる環境において，開発速度を落とさない = ユーザに価値を届けるスピードを下げないための，試行錯誤の過程を紹介します． 主なトピックは以下になります: Wantedly における"マイクロサービス" "マイクロサービス開発" の困難さ あらゆる技術スタックが存在する環境での開発 手元におけるサービスディスカバリ フロントエンドに立たないサービスのデバッグ 話すこと 単一のサービスではなく，サービス全体を複数の小さなのサービスを組み合わせることでさせることでユーザに価値を届ける「マイクロサービスアーキテクチャ」という

Abstract 概要 あなたのサービスのUIは、統一されていますか？ どんどん新しい表現が現れるUIの世界では、陳腐化してしまう速度もとても速いです。そのため、新しく作る画面などでモダンなUIを導入したくなります。そのタイミングで他の画面もデザインアップデートできればいいですが、サービスが成長するにつれて画面数は増え続け、全ての画面を更新することはできず、取り残されるページがどうしても現れてしまいます。 また、組織の変化による影響も大きいです。はじめに一人がデザインしていたことはUIを統一することは比較的簡単ですが、デザイナーが増えるにつれてそのコストはとても大きくなります。さらに、初期のデザイナーが抜けた場合などは、元のデザインを維持することはさらに難しくなります。デザイナーの数がエンジニアの開発速度に追いつかない場合は、デザイナーのチェックを通ることなくUIがリリースされてしまうよう

Abstract 概要 機械学習を活用したプロダクト開発には特有の難しさがあるのをご存知でしょうか？このセッションでは、Wantedly People の「名刺データ読み取り」など Wantedly での機械学習の活用事例や、生産性高く機械学習を活用するために Wantedly が構築した機械学習基盤についてお話しする予定です。 主なトピックは以下です。 Wantedly での機械学習活用事例 機械学習を活用したプロダクト開発の難しさ Wantedly の構築した機械学習基盤 BigQuery を利用した分析基盤 Kubernetes や Docker を利用した処理パイプライン、学習済みモデルのバージョニングやデプロイ Tensorflow などの機械学習ライブラリの利用 CI での予測精度評価 本番環境での予測精度評価 機械学習の活用に興味のある方、機械学習をプロダクトに組み込んだもの

みなさん、はじめまして。 Wantedlyの監査等委員の高原明子です。 2014年の4月から監査役としてWantedllyの監査に携わり、2015年の11月から監査等委員に就任しました。 さて、このブログで書かれているように Wantedlyでは、開発に限らず様々なプロセスでGitHubを活用しています。 今回は、監査等委員である私が、 監査業務の一環としてGitHubをどのように有効活用しているかをご紹介します。「監査対応面倒臭いな〜」 と思っているエンジニアの皆さんに日頃どんな点に注意を払っておくべきか何か気づきになることがあれば幸いです。 1. そもそも、監査等委員ってなんですか？ 監査等委員というのは、簡単に言うと 取締役が適切に職務を遂行しているかを様々な視点から確認する仕事です。（因みに、「監査役」も同じ仕事です。） ところで、どうして、Wantedly “Engineer"

ウォンテッドリー株式会社コーポレートチームの大谷です。 カスタマサービスチーム仲野さんが書いた ”GitHubで実現する、カスタマーサービスとエンジニアの非同期コミュニケーションのすすめ” に良い反響がありましたので、コーポレートチームでも行っている活動をお話したいと思います。 Wantedlyのコーポレートチームは”働くメンバーの生産性を上げる”ことをミッションとしています。インフラチームが開発チーム全体の生産性をあげることをミッションとしているように、コーポレートチームは会社としてやらないといけないことを担保しつつ、メンバーの負担を増やさないという観点で、会社全体の生産性を上げることを目指しています。 他社で契約書や規程の文書管理としてのGitを使う話はいくつか事例があるのですが、今回Wantedlyで行ったのはGitHubを使ったコミュニケーションを使って生産性を上げた話になります。

以下の記事が話題になっていたので、さっそく買って読んだ。 Wantedlyを支える技術をギュッと１冊の本にして技術書典に出展しました で、ちょうど最近自分で、マイクロサービスの開発フローを整えたところなので、反省した点を書いていく。 PUSHからDEPLOYまでのフローについて wantedlyのフロー 出展 WANTEDLY TECH BOOK 自分が構成した現在のフロー 反省した点 dockerの導入について Wantedlyのように、dockerを使ってテストや本番にリリースしたいとは当初思っていたが、以下の理由で諦めた。 AmazonLinux用のAnsibleから環境構築していた CircleCIを会社で利用していた CircleCIでAWSネットワークが利用できない AmazonLinuxのDockerimageを導入してもyum installができない Ansibleを書き

こんにちは、WantedlyでiOSエンジニアをしています杉上です。 僕達が普段チームで大事にしていることについてご紹介します。 何を作っているチームなの？僕達のチームは、Sync という気持ちのよいコミュニケーションで人と人がつながるビジネスメッセージサービスを開発しています。 マルチプラットフォームな展開のサービスでは、たくさんのエンジニアが開発に関わってるのではと思われますが、少人数のチーム体制に拘って開発を行っています。コンパクトなチームだとフレキシブルで迅速な意思決定が行えるのと、スピード感のある開発基盤（インフラ）のおかげで高い生産性のアウトプットを出しながらプロダクトの改善を進められています。 Wantedlyでは多様なサービス（Feed, Case, Tools）も展開していますが、他チームも少くない人数の少数精鋭体制で開発を行っています。各チームは入社１年目、２年目のエン

WantedlyでAndroidアプリの開発を主にしている住友です。最近グロースハック始めました。 単にプロダクトを作ってリリースしても自然とユーザーが付いて使い続けてくれることは稀です。どうすればプロダクトの良いところを知ってもらえるか、プロダクトを使い続けてくれるかを試行錯誤し、改善サイクルを繰り返すことで初めてユーザーさんが定着し、使い続けてくれるようになります。 Wantedlyは最近でこそデータに基づいたアプローチを行うようになりましたが、それまでには沢山の苦労と試行錯誤がありました。今回はそこまで辿り着くまでに何を行ってきたかのお話です。 ログを探してプロダクトを改善したと思っても、改善の成否の指標が無ければ判断できません。そしてログが無ければ指標も作れません。 WantedlyではWeb側のログは全てTreasure Dataというクラウド型データマネージメントサービスに集め

2016年6月7日付で、Syn.ホールディングス株式会社の連結子会社となったConnehito株式会社（以下コネヒト）。 今回は、同じくSyn.ホールディングス傘下のSupership株式会社で取締役をつとめるnanapi創業者 古川健介氏をお招きし、コネヒト代表大湯との対談をお届けします。 0から起業し事業をつくり上げた二人が、スタートアップ運営の裏側と両社の今後の展望を語ります。ママリではなく、もともと違うサービスで起業していた大湯：けんすうさんに初めてお会いしたのは、3年前ぐらい前、Creattyというクリエイター向けのサービスをやっていた頃でしたね。代々木にオフィスがあったときに、確かランチをご一緒したのが最初だったと思います。 古川：そうですね。ちなみに、コネヒトで、サービスの立ちあげは2つ目になるんですか？ 大湯：はい、ママリで2つ目です。 古川：Creatty時代と、ママリ時

Wantedlyインフラチームの @koudaiii です。 まずインフラチームでは、「Code wins Arguments」を支えるインフラ = 変化に強いインフラ作りに取り組んでいます。 Code wins Argumentsについては、こちらのインタビューを参照してください。 チームで1時間ミーティングするならコードをかこうという考え方のもと、エンジニアであれば、仮説を考えてあれこれ考えるよりも、プロトタイプを作って検証することや、営業であれば、エンジニアに頼む前に企画書を書いて5社程度の確約をとってきて、これなら行けると思ったらエンジニアに依頼するDocker を Production で使うのはなぜ？Wantedly では、 2014夏頃よりProduction で Docker を使っています。元々 Heroku からサービスをスタートしているので、コンテナ自体はずっと利用し

こんにちは、Wantedly でソフトウェアエンジニアをしている南です。自分は昨年の4月から Wantedly に新卒エンジニアとして入社し、スカウト機能の開発・グロース、ユーザー向け機能開発・グロース、新規サービス開発などに取り組んできました。 最近だと、今年の4月半ばにリリースしたポートフォリオサイト Case の開発を行ったり、2日前にリニューアルした Wantedly Tools の開発に携わったりしています。 さて、突然ですが、皆さんは「スタートアップで働く」という言葉に対して、どういったイメージを持つでしょうか？ なんとなく「大変そう」みたいなイメージはあるものの、具体的にどういった働き方をしているかはあまりイメージがつかないのではないでしょうか？ 「スタートアップ 働く」で検索してみると以下のように幾つか記事はヒットするものの、多くは創業者や経営者、または第三者の冷静な視点で

Wantedlyでは、React + Reduxを中心としたWebフロントエンドの技術スタックを導入しました。モバイル版の会社フィードや、このブログを書いているエディタ、企業が使う候補者管理の画面などがこのスタックで実装されています。 導入したスタックの詳細や導入の理由、既存のRails環境への導入方法は以前発表した以下のスライドを参照ください。 また、先日Wantedlyに導入した技術スタックを使った勉強会を開催しました。React + Reduxを使って実際にアプリケーションを構築していく演習になっていますので、ぜひ手元で動かしてみてください。 React + Reduxを使ったWebアプリケーション開発速習会＠Wantedly 今回はこれらの背景にある"なぜReactか？"という判断の背景と"どう技術選択するか？"という話を書きたいと思います。 JavaScript界隈の流れの早さフ

Wantedlyは、運命のチームや仕事に出会えたり、人脈を広げ、ビジネスの情報収集に使えるビジネスSNSです。

今は海外の同僚とやり取りすることも多く、英語でのコミュニケーションは読み書き聞き話す問わず日常的にやっているのですが、英語での言い回しや文法の改善についてはなかなか時間をとることができないでいます。英会話学校やオンライン英会話等に通い続けるのは 1 つのやり方だと思いますが、1 時間であっても固定の時間を確保し続けるのは自分の気質的にも難しく、結果としては野良英語を振り回し続ける日々です。 そんな中、とある経路でHiNative Trekを紹介してもらって、先月からずっと続けています。上記の課題に対して自分的にはピッタリハマっていて、今後も長く続けていきたいと思っています。というわけで、同じような悩みを持つ方がいれば是非使ってもらいたいと思い、簡単に紹介をしたいと思います。 完全非同期な英語学習 HiNative Trek の基本的な流れは以下の様な感じです。 毎日課題(基本はある状況での

目黒界隈のJavaScriptを書くエンジニアがあつまる勉強会、 “Meguro.es #3 in Drecom”に参加してきました。 会場はドリコムさんのオフィス内のカフェのようなスペースで、お酒を飲みつつ、ゆるやかで居心地良い雰囲気でした。 Wantedlyからは高松と森脇の2人で最近のWantedlyのフロントエンド開発で使っているツールやライブラリの話をしました。 WantedlyにReact + Reduxを導入した話 Wantedlyのこれまでのフロントエンド開発の歴史と、既存のRailsプロジェクトにReact + Reduxを導入した方法について話しました。 Immutable.jsとReact @Wantedly ~入門編~ Facebookが開発している不変オブジェクトライブラリの Immutable.jsの特徴や、Wantedlyでの活用例についての発表です。 We

13歳の頃、映画監督にひどく憧れていた。リュック・ベッソンの映画についての分厚い本を、飽きることなく何度も何度も、ページが手垢にまみれるまでめくった。ひとつひとつの写真を今でも思い出せる。熱を上げすぎて稚拙な自主制作映画もつくったし脚本も書いた。映像以外にも、イベント、ウェブサイト、油絵、デッサン、時間と場所を忘れさせてくれる創作活動が最高に好きだった。 年齢が上がるにつれて、どうやら創作活動の世界の人たちは社会的、経済的に評価され辛いことがわかってきた。資本が偉くて、クリエイティビティは原料として使い捨てられるのではないか、そんな思い。だから経済学にも、ビジネスにも興味が出た。 月曜にリリースしたCaseは、クライアントワークにとどまらず、それぞれのプロダクトを「誰が作ったのか」が明確になる世界が、組織の垣根を超えて実現されている。 映画のエンドロールと一緒だ。 ひとつひとつの作品に自分

Gunosy CTO, Corporate Officer, Business Development Office

こんにちは、株式会社GunosyにてCTOをしております松本です。 弊社にもこの4月から初めての正式な新卒採用で3名の方が入社しました。 実は自分も、3年ほどまえの大学4年の終わりごろにGunosyに入社しまして、そういう意味では新卒入社とも言えるのかなと思います。 社会人経験としては新卒の皆さんとそう大きく違うわけではないのであまり偉そうなことが言えるわけでもないのですが、自分が新卒の時にどんなことを聞いておきたかったかなと考えながら、主に今年新卒入社された皆さんになにかアドバイスになればと思い久々に技術の話以外でブログを書いています。 今回、3年間働く中で長くエンジニアとして必要とされるために大事だと感じたことについて書きます。 # 長くエンジニアとして活躍していくために自分がエンジニアを始めてからの数年の間にもベースになる技術は多くの進化を遂げており、1年前の状況が今では古いなどと言

Wantedly, Inc.に入る前エンジニアリングをはじめたのは 小学5年生ぐらいでしょうか、簡単なWPFアプリを作ったのが最初のように記憶しています。 その頃から 例えばそのアプリでチャットを実現するためにバックエンドを組んだり、他のプラットフォームを強化するためにWebアプリ化してみるなど「必要なものからやってみる」「純粋に作ってみたい」という単純な理由で取り組んでいました。 最終学年になりさて就活、というタイミングで 初めてインターンに来たのがWantedlyでした。 現在日数こそ少ないものの、長期のインターンを経て4月から新卒で入社しました。 現在はAndroidアプリエンジニアとして、Wantedlyアプリの改善を続けています。 今後どういうことをしていきたいかWantedlyのメンバーは社員もインターンも とにかくレベルが高く、自分の能力ではまだまだ追いつかないのが事実です。