開発生産性Conference 2024 登壇・協賛レポート - KAKEHASHI Tech Blog
カケハシで技術広報を担当している櫛井です。 カケハシは2024年6月28日から29日の期間で開催された、ファインディ株式会社主催の「開発生産性Conference 2024」にてゴールドスポンサーを務めました。また、カケハシのエンジニアリングマネージャーが登壇いたしました。 こちらのエントリでは、当日の会場での様子やセッション資料を基に雰囲気をお伝えします。 会場となった虎ノ門ヒルズフォーラムでは、協賛各社のロゴが並び壮観でした。 プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの こちらのセッションではエンジニアリングマネージャーの笹尾から、各メンバーが役割を跨いで協業しつつも個人のスペシャリティを活かしながらプロダクト検証サイクルを効率化する目的・チャレンジ・成果についてお話ししました。 会場では沢山の方が視聴してくださいました。オンライン配信も実施され、大変
スクラムマスターはスクラムマスターを育成する - KAKEHASHI Tech Blog
はじめに 私はカケハシでエンジニアリングマネージャーをしている伊豆本です。約5年スクラムマスターを経験しています。 カケハシにはスクラムマスターが複数いるので、この記事で記載するのはあくまで私の持論です。 スクラムマスターでよくある課題感 自身がスクラムマスターをしている中で見聞きしたり経験した課題感には以下のようなケースがありました。 スクラムイベントに遅れて参加する 参加者が集まらずスクラムイベントを開始して良いかわからない スクラムイベントに無断で欠席 スクラムイベントがあると休みづらい スクラムイベントが予定していたタイムボックスに終わらない プロダクトバックログの完了の定義がない 外部要因でスクラムバックログが進捗しない プロダクトオーナーが差し込みタスクを追加する頻度が多い スクラムはミーティング多いとメンバーから声が上がる 開発系のバックログは大体できたのでステータスをレビュ
目標管理と評価制度の考え方 - KAKEHASHI Tech Blog
本エントリはカケハシ Advent Calendar 2023 の 11日目の記事です。 今年はPart2もあるのでぜひそちらもご覧ください！ カケハシのVP of Engineeringの湯前（@yunon_phys）です。皆さん、目標設定と評価は順調ですか？私はこれまで何年にも渡って、様々なメンバーの目標設定や評価をしてきました。残念ながら、こうすれば良い目標設定や評価が出来る！という銀の弾丸は無さそうです。でも、こう考えたら目標設定はやりやすいかも、こうすると評価はより納得感のあるものになるかも、というのはあります。 そこで今回は制度を施行・運用していく立場の人間として、目標管理と評価制度の考え方について、私の意見を述べていきます。 目標管理 目標はそもそも変わるものである みなさんこんなことありませんか？ やる気満々であんなことやこんなことを色々考えて、壮大な目標を期初にがんばって
Engineering Managerという役割がなぜわかりづらいのか - KAKEHASHI Tech Blog
カケハシでVP of Engineeringをやっています、ゆのん(id:yunon_phys)です。僕はEngineering Manager(EM)とは何かについて、かれこれ5年ぐらいEM.FMというPodcastや、ブログを通じていろんな発信をしてきました。そうすると色んな質問を各所から受けるわけなんですが、一番聞かれる質問第一位は、「結局EMって何する人なんですか？」 です。一口にEMって言っても、なんか人によって得意な領域が違っていたり、大事だと思うポイントがバラバラなので、この疑問を持つのはそりゃそうだよなあ、とは思います。というわけで、このエントリーではEMは何する人なのかを明らかに・・・と思ったのですが、一言で語るのはやっぱり難しいなと思っています。なので、なぜ僕がEMという役割を説明するのが難しいと思っているのか、を書いていきます。 マネージャーの本質はチームの足りてない
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
