こんにちは、最近プロダクトオーナーにジョブチェンジしてコードを書く機会が減ってきたyo-iidaです。 クラウドワークスでは、開発チームをプロダクトオーナーと数人のエンジニアで構成し、スクラムをベースにしつつ細かいプロセスは各チームでカスタマイズしながら開発を進めています。 今回はそのカスタマイズの事例の1つとして、困難な目標や高い目標を追うため、既存の開発スタイルにとらわれないプロセス改善にチャレンジした話をお送りします。 目次 目次 プロセス改善で新しく試したプラクティス AARとは SMART Goalsとは Mob Programmingとは プロセス改善の歴史 モブプロ導入期 バーンダウンできない期 プランニングボリュームアップ期 夕会地獄期 AAR祭り期 ミーティングダイエット期 開発チームとプロダクトオーナーのコミュニケーション改善期 いいかんじに施策リリースできるようになっ

日々Datadogのダッシュボードを眺めながらニヤニヤしている @minamijoyo です。 定期的にSQLを実行した結果をDatadog送信するcyqldogというツールを作ったので紹介します。 はじめに クラウドワークスでは日々のデータ分析にAWSのRedshiftを利用しています。 Redshiftはサービスの主要なKPI集計から、ちょっとしたアドホックな分析まで、 利用者はエンジニアだけにとどまらず、プロダクトオーナーやマーケティングのメンバーも含め広く利用されており、 ひとたびシステム障害などでRedshiftが利用できないと業務に大きな影響が出ます。 そんなRedshiftを安定稼働させるためには、日々の監視が大切です。 AWSで監視といえば、まずはCloudWatchが思い浮かびますが、RedshiftのCPU使用率やディスク使用率などの基本的なメトリクスであれば取得できる

昨日Macで使えるGitフロントエンドの紹介を書いたところ、友人のPishenさんからForkというツールもあることを教えていただきました。 How about https://t.co/fDZq7jzQoo ?— Pishen Tsai (@pishen) 2017年8月30日 Webサイトはこちら。現時点ではMac版（動作にはMacOS X 10.11以降が必要）のみですが、Windows版も提供予定のようです。 git-fork.com リリースノートを見ると昨年から開発されていたようですが、完全にノーマークだったので早速試してみました。 1ウィンドウで複数リポジトリをタブ切り替えで操作できる ブランチの状況も把握しやすい履歴ビュー（見た目的にはSourceTreeに近い） コミット時点のファイルツリーを確認できる 動作は軽快（ただし安定度についてはまだ不明） ターミナルから起動する

こんにちは、UXデザイナーの八尾です。 京都に旅行して久しぶりに自転車に乗ると筋肉痛になりました。運動不足です。 UXデザイナーとしてデザイン組織に入り、主に定性調査を任されています。 （ユーザーインタビューやユーザビリティテストを通じてユーザーの真のニーズの把握や仮説の検証を行なっています。） 今回は、社内で初の試みであった、自社サービスの本格的なユーザビリティテスト（ユーザーテスト、ユーザビリティ評価って呼ばれたりもしますよね）について書かせていただきます。 まだ体制の整っていない中で行った手探り感と自社で定性調査を実施する上での気づきがお伝えできればと思っています。（暖かく見守ってやってください） 本を読んでみる。でも、本のようにはいかない まず、どういう流れで進めればいいのかすらわからないのでとりあえず本を読みながら考えました。 主に参考にしたのはこちらの本です ユーザビリティエン

ブログ記事『5分で分かるアジャイルムーブメントの歴史』を手がかりに、アジャイルムーブメントに関連する人や書籍に注目しながら、モダンアジャイルに至るまでのアジャイルムーブメントの歴史を辿ります。

webpackでJavaScriptライブラリを利用する webpackで様々なJavaScriptライブラリをコマンドラインからインストールして利用する事が可能になります。 webpackのインストールと利用方法 まずプロジェクトフォルダで以下のコマンドでpackage.jsonを作成します。 npm init -y 次にwebpackを以下のコマンドでインストールします。 npm install --save-dev webpack webpackをインストールしたならpackage.jsonと同一階層にwebpack.config.jsという設定ファイルを作成します。 設定内容はひとまず以下のようにしておきます。これは./src/script.jsの内容をコンパイルして./dist/script.jsに出力するという命令です。 module.exports = { entry: __

ピクスタ開発部で毎日ヒィヒィ言いながらエンジニアをやっております @muramurasan です。 今回はPIXTAのとあるリポジトリにおいて、未使用のメソッドを削除しようとした際、gemを組み合わせることで、効率的かつ安全に削除することができたという話をしたいと思います。 よくやる方式 外部の勉強会などで、「未使用のメソッドを削除する際にどうしているか？」ということを聞いた際、よく聞くのが「未使用らしきコードを見つけ次第、ロギングを行うメソッド呼び出しを挟み込んでいく」というものでした。 この方式は、動的なメソッド呼び出しにも当然対応できますし、お手軽なので、一般的に好まれているようです。 問題点 ただし、この方式では以下の問題点があると私は考えています。 そもそも、未使用らしいメソッドを見つけるのが大変 プロダクションコードを汚してしまう これらの問題を解決するために、PIXTAでは

「立ち飲み」を愛するアイドルを知っていますか 最近ではすっかりポピュラーな趣味となった「せんべろ飲み」。ホッピーとチューハイ、煮込みと串が織りなす甘美な世界は、かつてのオヤジ趣味というイメージから脱しつつあります。 でも「せんべろ飲みが趣味のアイドル」がいる、と聞いたら驚きますよね。というかキュンキュンときめきますよ！ そんなアイドルが「清竜人25」の清亜美さん。 そのパワフルかつキュートな楽曲とエンターテインメントに満ちたステージ、そして恋愛禁止が当然と言われる業界で「夫とその妻によるアイドルグループ」と話題になった清竜人25の第3夫人である彼女。ブログで巣鴨・大井町・月島……とシブい街で「せんべろ飲み」を楽しむ姿をアップしだしたところ、たちまち話題に。最近では「せんべろ飲み」を振り返るトークイベント「スナック亜美」を開催するまでに。 ▲清 竜人25 2ndアルバム『WIFE』初回限定版

こんにちは。エンジニアの廣瀬です。連休中に『ラ・ラ・ランド』観てきました。とても良かったです。もう一回観に行きたいです。 さて、冒頭に書いた通り、僕はエンジニアで、つい最近までは他のエンジニアと一緒に開発チームで実装などを行っていましたが、今年の春からは“UXデザイングループ”というデザイン組織でデザイナーと一緒に仕事をしています。 とは言っても、ジョブチェンジをしたわけではありません（社内では「廣瀬、エンジニアやめるってよ」みたいな誤解も一部ありました）。いわゆるデザイナー、ビジュアルデザイナーになるつもりも今のところはありません*1。 それではなぜエンジニアがデザイン組織に所属することになったのか？――そのあたりも含めて、先日、弊社のオフィスで開催された『文化の違いを多角的に捉える UX & Service Sketch #27』（Media Technology Lab. さん主催）

All slide content and descriptions are owned by their creators.

先日、転職活動、キャリア形成に悩む若者の相談にのる機会があった。20代後半をむかえ、とある会社からひょんなことから声がかかり、とんとん拍子で面接が進み、いよいよオファーレターがでるというところまで一気にきてしまい、いざ転職の決断を迫られたが、なかなか決断に踏み切れないとのこと。 面接が進んでいく過程では意外と気にならなかったが、いざ決断するタイミングになると、「自分は本当にその会社に行きたいのか」、「他にもっと良い機会があるのではないか」、そして「自分は本当の本当に何をしたいのか」、「自分にとって職を選ぶ上で最も大事なことは何か」と迷い始め、とまらなっくなってしまったとのこと。 これは私も経験があるので非常によくわかるところ。結局のところ、その人はまだ転職を決断するに十分な判断材料をもっていないように思えたので、納得がいく決断をするために、必要十分な判断材料を集めることをすすめた。判断材料

みなさんさようなら，最近デプロイが趣味の@h3_potetoです． この記事は，僕が趣味で改善していたCrowdWorksのデプロイ周りの大改造の歴史を振り返ります．基本的には，デプロイが趣味の方向けの記事です．とても長いです． 手動構築の時代 その昔，CrowdWorksのサーバは手動で構築されていました． 手動でRuby等の設定をいれたサーバを複数台用意し，そこにcapistranoデプロイをしていました． インフラは手動構築だった割に，なぜかBlue/Greenデプロイを実現していました． Blue/Greenの実現方法 まずはじめに， Blueが稼働系 Greenが待機系 です． Blue/Greenデプロイをする際には，Green系にデプロイをして，Blue系と挿げ替え，旧Blue系をそのまま廃棄します． この動作をどこで実現しているかというと，なんとCrowdWorksのアプリ

クラウドワークス人事チームの上田と申します！いつもはWantedlyのブログなどでクラウドワークス社内の情報を発信しております。年明け一発目のエンジニアブログ、かなり緊張しております…！ さてさて、なぜ私がここにいるかと申しますと、弊社プロダクト開発Div.の年始の取り組みをご紹介したかったからです！それは「C（クラウドワークスを)S(整地しよう)P(プロジエクト)」で行ってきた開発合宿！ C（クラウドワークスを)S(整地しよう)P(プロジエクト)とは？ 「まだ見ぬ『道』を創ろう」をテーマに、サービスの中で日ごろ気にはなっているけど ・片手間では直せないなぁ。 ・こうすればもっと良くなるんじゃ！？ という部分に2~4人のチーム単位でじっくりと取り組み、CrowdWorksを外から中からもっと良くしていくプロジェクトです！ スタートは年明けの1月4日からの11日間。1月13日と14日にその総

はじめに この記事はHeroku Advent Calendar 2016 17日目の記事です。遅くなってすみません。。 過去に書いた記事で書けなかった補足の情報を出すかんじでいきます。 Herokuで起こりうるメモリ関連のエラー Herokuで起こるメモリ関連のエラーはR14とR15エラーの2つがあります。 Herokuにおけるメモリの上限はプランによって制限され、たとえば無料で使える上限のFreeプランだと512MBのメモリしか使えません。 このようにHerokuはプランによってメモリの上限が決まります。 Herokuではメモリの使用量がそのプランの上限を超えると、スワップが発生するようになっています。 プランの上限を超えてスワップが発生するとR14エラーが発生するようになります。R14エラーの状態ではDynoはそのまま動き続けます。 このスワップが元のプランのメモリ上限の200%を超

Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる

この記事は クラウドワークス Advent Calendar 2016 19日目の記事です。 昨年の、あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。に引き続き、エンジニアのキャリアについて書いてみます。 クラウドワークスにおけるエンジニアの3つのキャリア 当社では、エンジニアのキャリアを以下の3本の柱で考えています。 技術（アーキテクトやCTOを目指す） プロダクト（PO・PMを目指す） マネジメント（マネージャー・VP of Engineeringを目指す） 「技術」のキャリア 基本的に、多くのエンジニアはこのキャリアを望みます。エンジニアなので当たり前と言えば当たり前ですが。ただしその一方で、多くのエンジニアは、30歳前後でキャリアに悩む時期が訪れるように感じます。 一般的に、年齢が上がると「マネジメント」を求められるようになる、という環境のせいもあります。結婚（あるいは同

はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ

この記事は CrowdWorks Advent Calendar 2016 17日目の記事です。 はじめに クラウドワークスのエンジニアで、現在プロダクト開発Div.にてマネジメント職についている @teriyakisan です。 社内には田中が数名いることもあってか、テリヤキさんと呼ばれることも増えてきました。 今回はもともとマネージャーをやりたくなかった私が、なぜやることになったか、やってみてどうだったかを（緊張感ありますが）書いてみます。 なぜやりたくなかったか エンジニア界隈で「マネージャーやりたくない」という声は多いと思います。 現場寄りでいたい コードを書き続けたい 給与は上げたいけど昇進にそこまで興味はない マネジメント職につくとMTG増えて大変そう とかが代表的かなと。 例にもれず私もそうで、クラウドワークスの組織拡大に伴いマネージャーポジションが全社的に増えつつあった昨年

ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ