Content-Length: 276650 | pFad | http://b.hatena.ne.jp/takaesu/wantedly/
レガシー化していた課金周りのシステムを改善するためにやったこと | Wantedly Engineer Blog
エンジニアの富岡です。2ヶ月ほど前まで、Wantedly 利用企業向けのプラン契約や料金請求周りのシステムの改修と機能追加を行うプロジェクトをやっていました。1年半ほどの長期プロジェクト、かつステークホルダーの多いプロジェクトだったので、プロジェクトマネジメントの観点でも書くべき話題はあるのですが、今回はより技術的な部分に焦点を当てて、プロジェクト開始時点でレガシー化していたシステムの状態を改善するために行った取り組みを紹介したいと思います。 背景Wantedly は SaaS 型のビジネスを提供しており、利用企業の契約プランに従って毎月の料金の請求を行ったり、契約の自動更新を行ったりといった処理が発生します。こうした処理を行うシステムは、今から8年ほど前までにそのベースとなるものが作られました。それ以降は消費税率の変更や、新しい支払い方法の対応など、必要に応じて散発的に変更は行われていま
ユーザーヒアリングという悪・思考停止
久々にとても良い本に出会いました。そしてスッキリしました。 “Over Crowded”（邦題『突破するデザイン』）という書籍で特に刺激になったのはソリューションに対するイノベーションは外から内というプロセスを経ることが多いが、意味のイノベーションにおいては絶対的に内から外でないとダメだということ。意味のイノベーションとは人々の生活を一変するような今までの延長線上にはない価値を創り出すこと。 外から内というのはユーザーヒアリングや行動観察などによって気づきを得て、それをソリューションに対してのイノベーションを起こすために活かすということ。例えば、IDEOがスーパーマーケットでの顧客行動を観察し、カートというソリューションをデザインしたという話など。 但し、ソリューションではなく、意味のイノベーションにおいては外から内というプロセスでは何も生まれない。例えばAirbnbなどを考えればわかりや
SquadとOKR - 開発チームが無駄なく高い成果を出すために大事にしていること | Wantedly Engineer Blog
こんにちは。Wantedly Visit 開発チームで"Squad Leader"をしている森脇です。 この記事では、エンジニアブログでいつも紹介している技術の話ではなく、開発チームが普段どのようにシゴトをしているのかを紹介したいと思います。エンジニアだったらクールな技術を使っているかはもちろん重要ですが、どのような組織体制で、どのような目標を持って、どのように意思決定をするかは、それ以上に大切なことでしょう。 まずは重要なキーワードであるSquadとOKRについて簡単に説明してから、実際のチームを例にしてより詳しく具体的な話をしていきます。 チーム編成: SquadとTribeさっき自分のことを"Squad Leader"と紹介しましたが、いきなり登場したこの"Squad"という言葉について説明します。 Squadとは、いわゆるチームのことなのですが、同じ目標をもち、互いのシゴトが強く依
Rails に RESTful API のレールを敷く - Qiita
背景 今年の1月に弊社のネイティブアプリ向け API を刷新し、API v2 として導入した。機能開発やリニューアルなどのタイミングで徐々に移行して行っていて、振り返ると体感で生産性が2倍くらいになっていたように思う。やったのは基本的に少しきちんと RESTful API のプロトコルを定義し、それに則る形で API を書くためのレールを敷くということだった。 RESTful API は割とこなれたテーマかなと思いつつ、意外と Rails で RESTful API を導入しようとすると、そんなにメジャーな方法があるわけではなく、一個一個自分で考えてレールを敷く必要があった。 もちろん、それができるだけの融通性があるのが Rails の良いところではあるのだけど、逆に言うとあんまり全体のデザインを考えずに作って微妙なものが出来るということもまた同時に起こりうる（今回移行するきっかけになった
Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話 | Wantedly Engineer Blog
こんにちは、Wantedly Visit の開発をやっている竹野（@Altech_2015）です。 今年の1月に Wantedly に当初からあるクライアント向けの API を再検討し RESTful API に移行しました。これまで曖昧だった部分を RESTful の制約を活かしていくつかレールを敷いた結果、以前の Rails API と比較して生産性が2倍以上になったと感じています。 �Wantedly Visit は一番大きなアプリケーションなので大掛かりなフレームワークを入れることは難しかったのですが、やってみると ActiveModelSerializers やいくつかの汎用モジュールを組み合わせるだけで簡単に生産性が上がったので、この記事ではそれについて紹介します。 特に、API を RESTful にすることを考えた際、リクエスト本数が増えすぎたり、関連データを一緒に取ってく
技術面接を受ける前に確認しておくといいこと | Wantedly Engineer Blog
ここで書くのは基本的なことなので、実際の面接ではもう少し複雑な問題になるかもしれません。 逆にいうと、このあたりの問題は一度は解いておいた方がいいので列挙しました。 普段ウェブの開発をしているだけでは考えたことがない場合もあるので、一度確認するといいかもしれないです。 アルゴリズムチェックポイント計算量, ハッシュと二分木, ソート, 再帰 計算量計算量の話 http://qiita.com/cotrpepe/items/1f4c38cc9d3e3a5f5e9c 二分探索とは https://ja.wikipedia.org/wiki/%E4%BA%8C%E5%88%86%E6%8E%A2%E7%B4%A2 ハッシュテーブルとは https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%83%86%E3%83
ユーザファーストの嘘
ユーザファーストと聞いて、何を思い浮かべるだろうか？よく、ユーザの声をしっかり聞いていないからユーザファーストではないとか、顧客第一ではない、なんて話を聞くけど、それは全くのナンセンスだ。 ユーザは自分のほしいモノはわかっていないし、無責任まず大前提として、ユーザは自分がほしいものは分かっていない。いくらグループインタビューを重ねても、そこからipodは生まれなかっただろうし、Appleもユーザヒアリングはしないことで有名だ。それから、ユーザに「このボタンの位置についてどう思いますか？」と問われれば、「そうですね、もっと右にあったほうがいいと思います」と、意見を言わないと！いう善意から、責任も伴わない思いつきの意見をどんどんいう。だから、ユーザに「どう思うか」と聞くのは愚の骨頂だ。 長期的視点と短期的視点それから、ユーザファーストという時に、それはユーザにとって短期的にいいものか、長期的に
開発フロー研修 @ Wantedly - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/takaesu/wantedly/
Alternative Proxies:
Not Found
Wantedlyの成長を支える管理画面 #admin_night