■イベント アジャイル開発における、さまざまな立場でのリーダーシップ https://sansan.connpass.com/event/257322/ ■登壇概要 タイトル:必要なのはリードであってリーダーではない 登壇者:技術本部 Bill One Engineering Unit S…

ネイト・ベルコペック (@nateberkopec) SpeedShop(詳細),Railsパフォーマンス・コンサルタンシー 要約:Rails開発者の多くが、ActiveRecordがSQLクエリを実際に実行する条件を理解していません。よくある3つのケースを見てみましょう:countメソッドの誤使用と、サブセットをセレクトするためのwhereの使用、そしてpresent?です。 断言しましょう。あなたはこの3つのメソッドを使い過ぎていて、無駄なQueryとN+1を発生させているでしょう。 (字幕:なんて奇妙な謎だ、バットマン!) "いつActiveRecordがクエリを実行するかって?知るか!" ActiveRecordは素晴らしいです。本当に。しかし抽象化されているので、データ・ベース上で実行されている実際のSQLクエリに無頓着になりがちです。ActiveRecordがどのように動作す
「プロダクトマネージャーカンファレンス 2021」は、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨することを目的に開催されるイベントです。エムスリー株式会社からは山崎氏が登壇。プロダクトマネージャーの育成・成長のための「7つのプロダクトシコウ」について話します。 山崎氏の自己紹介、エムスリーの紹介 山崎聡氏:全国のプロダクトマネージャー(PdM)およびプロダクトマネジメントファンのみなさま、こんにちは。エムスリー株式会社で、執行役員 VPoE プロダクトマネージャーをやっている山崎聡です。今日は「非連続な環境、変化、プロダクトに対応していくためにPdMが習得するべき7つのシコウ」という話をします。よろしくお願いします。 もともと8歳からプログラミングを始めたエンジニアで、VPoEをやっています。今はアプリのプロダクトマネージャーをメインに、その他のSaaS製品も扱っています。デ
プロダクトマネジメントを最近は生業としていますが、プロジェクトマネジメントについても必要となることが多くあります。 最近、周囲でもプロジェクトマネジメントが必要な機会を見聞きすることがあり、需要はあるのではないかと思い、私が学んできた知識や経験を書き記してみます。 仕事の終わらせ方は2つしかない プロダクトマネジメントとの違い プロジェクトマネジメントの3種の神器 プロジェクトマネージャーの仕事は不確実性を潰していくこと チームマネジメントについて 「運用でカバー」は最終手段 まとめ 仕事の終わらせ方は2つしかない 新人研修で、仕事の終わらせ方は2つしかないという話を教えてもらいました。その2つは「成果で終わらせるか」、「期限で終わらせるか」です。 (こちらの企業の研修だったと思います http://www.onevision.jp) 言い換えると、あらかじめ定めた成果物が完成した時、ある
プロダクトマネージャーという職業が、日本のスタートアップでも認知されてきました。単体のプロダクトの価値向上や複数のプロダクト展開による非連続な成長をリードする中心的存在です。また、「キャッシュ効率」や「利益の創出力」が重視されるマーケットの環境においてカギとなる役割を担っているとも言えるでしょう。 近年では、日本でもプロダクトマネジメントの知見が、書籍やブログなどで流通するようにもなりました。確かにプロダクトマネージャーの仕事は、大まかに見れば共通する部分は多くあります。 しかし、協働するステークホルダー(顧客・社内)や事業特性によって、プロダクトマネージャーがとるべき戦略や目標、実行は大きく異なるものです。その違いを理解しないままに、“プロダクトマネージャー”という言葉でくくられている情報を鵜呑みにすることは、自社にとって最適ではないプロダクト組織を作ってしまうリスクがあります。 そこで
Twitterでのつぶやきの半分以上は組織づくりやマネジメント関連なんですがどこかにまとめたこともなかったので整理の意味も含めて書いていきたいと思います。これが正解だ!なんて言えるわけもなく、個人的な経験をもとに書いていきますので後日読んでくださった方々と語らう場が設けられたら幸せだなと思っています。ですから温かい目と心で読んでくださると幸いです。 マネジメントの基本理念マネジメントの基本理念は「成功したらメンバーのおかげ、失敗したらマネージャーの責任」これに尽きると思います。基本的な役割はメンバーが保有している能力の総和を超える成果を出すことだと考えていますがそのためには上記の理念が欠かせないと思っています。 もちろん組織によって役割はそれぞれだと思いますが、ことベンチャーにおいてはとくに「成果を出すこと」と「人材を育てること」の両軸が必要であり、両立する難易度が極めて高いのですがそれで
こんにちは。アルバイト事業部エンジニアのmnmandahalfです。 私たちは積極的にエンジニアの仲間を募集していますが、もっと私たちの組織・文化・利用技術について知ってもらおうと思いLivesense Engineering Handbookというものを作りました。 *1 Livesense Engineering Handbookについて livesense-inc.gitbook.io こちらはGitBookにホスティングされている、エンジニア採用における広報を目的に作られた資料です。主にスカウトやSNS、カジュアル面談を通じて出会った採用候補者の方や、新入社員の方向けの資料となっています。 カジュアル面談にいらした方よりも少し広めの層にリーチする目的で、リブセンスでエンジニアとして働くことの概要がわかるような形で書かれています。 この資料は常に鋭意執筆中であり、「自律共創」のコンセ
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに?」「TDDってなに?」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
サービスを横断したチームはあるのか 平山光太郎氏(以下、平山):私は今LINE Fukuokaでフロントエンド組織の室長をしている平山と言います。先ほど福島から説明があったように、UIT2室という拠点もあるのですが、そこの室長もしていて、京都と福岡を主に見ているマネージャーです。今日はよろしくお願いいたします。 さっそくですが、今日は時間も限られているのでガンガンQ&Aに答えていきたいと思います。 さっそく今日いただいた中で一番多いものからいきましょうか。一番多いのは「Front-end Dev1からDev10まで分かれていますが、それぞれの役割はサービスごとに分かれている状態なのでしょうか? またサービスを横断したチームはあるのでしょうか? それともサービス軸ではない理由で分かれているのでしょうか? あとは1チーム何人ぐらいの体制でしょうか?」という質問です。では、これは福島さんに。 福
iCARE の提供しているサービス Carely では 2020年の 10月から半年ほどかけて Webpacker からの脱却を行いました。似たような記事はいくつかありますが、まったくの未着手から解説したものはないと思うので、記録をかねてまとめました。長めの記事になりますが同じことで困っている方の参考になれば幸いです はじめに - Carely の構成について もともとは Rails5 のスタンダードな構成だったものを、 Webpacker を導入して GraphQL + Vue2 の構成に移行。SPA ではなくエンドポイントごとにエントリーポイントがあるような構成になっています ルーティングなどは Rails に則りつつ、画面はほぼ Vue2 で構成されています。もちろん古い slim + sprockets の画面も残っているため coffee script のファイルも一部健在です
こんにちは!@ar_tamaです。「技術的負債に立ち向かう」シリーズは①実装編と②ドキュメント編で終わりの予定だったのですが、小出しにしていたロコガイドでの実践についてもまとめておこうと思い、再度筆を執りました。 今回は ③ロコガイドの現在地編 と称しまして、現在私たちがどのような課題を抱え、それをどのように乗り越えていこうとしているかをご紹介します。 ※ あくまでも2021年5月時点でのスナップショットであり、今後取られるであろう様々な舵によって着地点が大きく変わる可能性があります 課題とアプローチ ロコガイドが運営するトクバイのコードが抱える負債や課題についてはCTO前田の記事「トクバイにおけるレガシーシステム改善への取り組み」にて概説されているとおりで、意図しない密結合によるエンバグや、歴史的経緯の紐解きによりデリバリーコストがかさむといった問題がだんだんと無視できない状況となってき
リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウェア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』などを運営するIncrementsに転職。17年6月より独立し、プロダクト戦略やエンジニアリングマネジメントなどの領域で企業の支援を行う。17年9月、ヘッドハンティング・人材紹介を展開するクライス&カンパニーの顧問に就任。2019年1月、テクノロジーにより企業や社会の変革を支援するTably株式会社を設立。「プロダクトマネージャーのキャリア戦略」 及川卓也のプロダクト視点 アマゾン、アップルといった米国企業や中国企業からの遅れが目立ち始めた日本企業。かつ
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
「仕様通りだけど使いづらい」を解消する、探索的テストの考え方:アジャイル開発における品質管理(4) 少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。前回から、スプリント内でのテストと品質保証について、2回に分けて解説している。後編となる今回は、探索的テストとアジャイル開発における品質改善事例について。 前回は、アジャイル開発におけるスプリント内のテストと品質保証について「完成の定義」や「受け入れ条件」の設定、テストの考え方の一つである「V&V」について解説しました。 前回の内容と重複しますが、V&VとはVerification(検証:以下、ベリフィケーション)とValidation(妥当性確認:以下、バリデーション)の頭文字を取ったものです。ベリフィケーションとは、「仕様通りに作
一言でいうと コロナ禍のストレスやフルリモートでの働き方に適応出来ずどうしても厳しいと判断したので、少なくとも人に会ったり出来るようになるまでは勤め仕事は辞めて休養をすることにしました。 もう少し詳しく 1年前にコロナによる自粛が始まって以来、自分は不要不急の外出を控えるという行政の指示に従い極力外出をしないようにし、友人などと会うこともなく、ほぼ家とコンビニの往復しかしないという生活をしていました。 もともと自分は過去にひきこもり状態だったこともあるし、数ヶ月の休暇を取ることも珍しくなかったので、「外に出なくてもそれほど困らない方だろう」と思っていました。 しかし、自粛が数ヶ月続いた去年の夏ごろから徐々に心身ともに調子が悪くなっていき、それから今に至るまで慢性的な体調不良に悩まされています。 また、フルリモートでの業務委託の仕事というのも上手く適応することが出来ず、かなりストレスの高い状
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く