クラウドソーシングから舵を切る ── エンジニアの働き方を追求する及川卓也さん×ランサーズ、怒濤の「2万字」座談会 - はてなニュース
フリーランス総合支援プラットフォームを運営するランサーズは、2018年末、高いスキルを持つフリーランスとのマッチングを提供する「Lancers Pro」（ランサーズプロ）をスタートしました。これまでの「匿名が可能なクラウドソーシング」から、実名・顔写真登録を行う個人（タレント）と人材を必要とする企業との仲介をする“タレントソーシング”へ──多様な働き方を推し進めるランサーズの新しい取り組みについて、聞き手として技術面での企業支援を行う及川卓也さんをお迎えし、エンジニアの働き方、キャリアへの考え方などについて伺いました。 Lancers Pro - 厳選フリーランス最短即日ご紹介サービス クラウドソーシング「ランサーズ」 ※この記事は、ランサーズ株式会社によるSponsoredContentです。 出演者プロフィール 及川 卓也さん DEC、Microsoft、Googleを経て、2015年
米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - ログミーTech
2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。2日目のKeynote「敢えて属人化せよ！ エキスパートの集団こそが最強のチーム」に登壇したのは、Microsoft本社で活躍するエンジニア、河野通宗氏。日本からアメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。 マイクロソフト本社で働くエンジニア 河野通宗氏（以下、河野）：Microsoftの河野と申します。ふだんはシアトルでAzureサービスを作っているんですけど、今回は川口さんにご縁があってお呼び
Webベンチャーから電機メーカーに転職して思うこと (近況まとめ) - sseze's blog
(おはようございます|こん(にちは|ばんは))。 この記事は mixi OB/OGによる ex-mixi Advent Calendar 2017 の10日目です。 例によって技術的な話ではない上に、個人的な話題ばかり書いてしまったため、自分も個人ブログにて投稿します。 想定する読者 お世話になった現役ミクシィの皆様 (近況報告です) お世話になったミクシィOB/OGの皆様 (ご無沙汰しております) これからWebベンチャー→メーカーエンジニアへシフトチェンジしようとしている稀有な方 長いのでTL;DR 大学が電子情報系だと電機メーカーは結構楽しい ワークライフバランスがだいじな件 大企業をテラフォームするのは正直シンドい 職場環境、東京で消耗しなくなった話 ミクシィで学べたこと、今後について 在職期間のこと 自分がミクシィに在籍した期間は、2012年9月から2017年3月末日までの4年7
「PDCAクルクル教」という面白記事にみるPDCA 4つの誤解～「計画必達教」という呪縛：データイズム：オルタナティブ・ブログ
「PDCAクルクル教」というネーミングが面白い田中靖浩氏の人気記事、"「PDCAクルクル教」だから変化に弱い日本企業" は四つ大きな間違いがあります。第一に、PDCAを田中氏は間違った説明をしている点です。第二に、日本企業はPDCAサイクルをクルクル回せているわけでなくて、むしろアメリカ企業とかの方がよくやれています。日本企業はPDCAクルクル教ではなく、「計画必達教」と呼ぶほうが適切です。第三に、PDCAがクルクル回せているならむしろ、変化に強く「想定できない変化」に早く気づき、対処や改善（= Adjust）が早くできるはずなのです。そして第四に、PDCAはクルクル回す短期的なものだけでなく、中長期的なPDCAもあり大きな変化に対処するにも重要という点です。 第一の間違い：PDCAは 計画、行動、管理、実行ではない 田中氏のPDCAの説明は少し間違っています。PDCAを田中氏は、「計画、
はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
