この記事を読むたびに学びがあるなぁと感じていたが読むたびに忘れている気がするので現時点での理解を書き留めることで今後の学びの糧にしたい。本記事は元記事の全体を和訳する事や内容の全てを解説する事を目的としておらず、僕自身の学んだ事や振り返った事や噛み砕いた解釈を大いに含むので、本記事に書かれている内容は元記事の主張と一致している保証は全くない事を念頭においてほしい。 apenwarr.ca To paraphrase the book, the job of an executive is: to define and enforce culture and values for their whole organization, and to ratify good decisions. この本を言い換えると、幹部の仕事とは文化と価値を定義して強制し、良い決定を承認する事です。 元記事で言
本記事は BASE アドベントカレンダー 2024 の 24 日目の記事です。 こんにちは、エンジニアリングマネージャーの松原(@simezi9)です。 新型コロナウイルスの流行に端を発する世の中の変動からもうじき5年が経過しようとしています。 当時の感染対策の流れで多くの企業がリモートワーク制度の導入を進めました。この記事を読んでいる方の中にもそのタイミングではじめてリモートワークに取り組んだ方も多いのではないでしょうか。 私もその当時に、BASE株式会社のリモートワークへの取り組みをエントリとして公開したことがありました。 参考：エンジニアのリモートワーク in BASE このエントリを書いてから4年。その間、マネージャーという立場からリモートワークの制度を運用してきた経験を踏まえて、私がいまリモートワークというシステムに対して思っていることを率直に書いてみたいと思います。 この文章が
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは、同じエンジニアである妻から聞いた話なのですが、彼女の案件で「メンバー全員で公式ドキュメントを読みあわせる」という取り組みがあったそうです。 で、この方法「チーム全体にとって大きなメリットがあるんじゃないか？」と思ったので、共有させていただきます。 「誰も知らない」から「みんな知ってる」に 私は開発職なので、めずらしいことなのかそうではないのか判断がつかないのですが、その案件では、導入対象の製品について詳しい知識を持っているメンバーが一人もいなかったというのです。 誰もその製品をさわったことがなく、とりあえず強そうなメンバーを入れ
名古屋支社所属。新しい技術・怪しいデバイス・GISが好き。名古屋から影響力のある開発チームを作って発信していくのを目標としている はじめに 三河からこんにちは。名古屋支社の北河です。 新年度も始まり、新入社員や新規案件でチームが誕生したり変化したりしていると思います。皆さんのチームは “ちゃんと” チームしていますか？今回はそんなチームにフォーカスを当てて、チームの誕生や変化時に行われるチームビルディングについてお話したいと思います。 是非最後まで見てくださいね！ チームビルディングとは？ 歴史 チームビルディングを語る前に、実は歴史については意識したことが無いことをさきほど自覚しました。チームビルディングと言えばタックマンモデルが頭に浮かびますが、これは誕生というよりもチーム形成の段階についてです。ではチームビルディングはそもそもどういった経緯で誕生したのか？「誕生した背景を知る」という
「スクラムでやっているんですが、問題が多くて、スクラム合わないのかなと思って……」 「問題あるならスクラムが上手くいってますね」 という会話をした。 スクラムをやっていて、いろいろ問題が起きる。スプリントゴールがわからないとか、チームの協力が難しいとか、プロダクトオーナーの権限がないとか。スクラムちゃんとできないなあ、うちには合わないのかなあ、と思う人は多いようだ。 だが、こうした問題が起きているならば、スクラムは正しく機能している。スクラムはチームや組織の問題を検出し、明らかにする仕組みだ。みんなが問題を意識できているなら、上手くいっているわけだ。「うちは〇〇だから、スクラム難しい」と思ったなら、その〇〇を解消できれば仕事がもっと上手くいき、よりよい成果が作れる。 スクラムが上手くいくと、問題が次々に現れる。問題を次々に解消していくと、仕事しやすくなり、コミュニケーションがスムーズになり
それデイリーやない。レイニーや。 はじめに こんにちは。学園アイドルマスターにハマっているスクラムマスターの池永です。 レバテック開発部ITSプロダクト開発グループに所属しており、日々チームが強く、楽しくなれるように試行錯誤しております。 先日、以下の記事を投稿したのですが、他のスクラムイベントにもあるあるはあるよなと思い、デイリースクラムのあるあるも早く言いたくなりました。 こちらも何か参考になる情報がありましたら幸いです。 話すこと スクラムにおけるデイリースクラムのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと スクラムにおけるデイリースクラムの詳細な目的 デイリースクラムの具体的な進め方 では早速... 例に漏れずあるあるを早く言いたいので、挙げていこうと思います。 1. ただの進捗報告会になりがち スクラム導入間もないチームでは、デイ
はじめに はじめまして。レバテック開発部ITSプロダクト開発グループ所属の池永です。 私は現在スクラムマスターとしてチームに参画しており、日々チームが強く、楽しくなれるように試行錯誤しております。 かれこれ一年半ほどスクラムマスターを経験させていただいてきましたが、色んな壁にぶつかってきました。 特にスクラムにおける「ふりかえり（レトロスペクティブ）」において生じた壁について色んなエンジニアと話しているうちに、あるあるなんだなぁ〜と感じたため、この記事を書いております。 この記事では自身のぶつかってきた壁と、そこに対してどのようなアプローチを取ったか、そしてどうなったかを少しだけ共有しようと思います。 何かしらの参考になったら幸いです。 話すこと スクラムにおけるふりかえりのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと 色んなふりかえり手法に
悩み：すぐに「合宿しよう」と言い出す上司、理解できません 創業から約10年で上場した企業に新卒で入り、4月で4年目になります。上場している企業ではあるものの、経営陣をはじめスタートアップ気質が抜けていません。少ないメンバーでも新しいことに前向きに挑んでいくという点ではいいのですが、議論を深めたいときに経営陣が「合宿をしよう」と言い出します。私は合宿が嫌で仕方がないのですが、先頭に立ってそれを言うのが私の上司で、当たり前のようにメンバーに組み入れられます。 通常のオフィスではなく、異なる場所でメンバーが集まって1つの議論に集中する。たしかにそれで導き出した答えを基にサービスを生み出したこともあります。それが成功体験なのか、ことあるごとに「合宿しよう」と言うのです。 私はオンとオフをきっちりと分けたいタイプです。みっちり議論をした後に食事をし、お酒を飲む。セクハラやアルハラはありませんが、仕事
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに チームのメンバー皆に意見を出してもらいたいような会議をすることはよくあると思います。 本稿は、そういう時に積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。 チームの皆に意見を出してもらいたい会議とは いろいろあると思いますが、以下に2つの例を挙げます。 UXレビュー 私のチームでは、開発中のプロダクトに対する改善点を皆で挙げるという活動を行っています。 チーム内では「UXレビュー」と呼んでいます。 具体的には、開発メンバーが開発中のプロダクトを実際にユーザーがよく使うユースケースでどんな体験をするのかを
会社勤めの人について回る人事考課。自分への評価に一喜一憂する人もいるかもしれません。労働研究者の熊沢誠さんは、日本企業は人事考課で労働者を追い詰めていると問題視します。労働者が奪われてきたものとは―…
2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。 6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。 8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。 また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。 大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開
先日、『質の高い課題解決できる人が「こうすべき」を主張すべきだけど、それが苦手な人も多いからチームで解決したら良いのでは』という雑な考えを書いたのですが、僕のブログにしては多くの人に読んでもらえました。 読んでくれた人、ありがとうー fujii-yuji.net ただ、この記事へのコメントで「質の高い決定ができない上司や社長はダメだろ」みたいな意見もそれなりに多くあって、けっこう驚いたのですよね。 僕が雑に書いたわかりにくい文章だったことが原因で誤解されてしまったのでしょうけれど、今日は補足として「部下がやれることを上司もやれる必用はないですよね」的な話を書きます。 上司が「自分ではできないからお前に頼むわ」と言ってくれたお陰で、"上司のして欲しいこと探し"をしなくて済んだ。 僕が若いころお世話になった上司はよく「自分ではできないからお前に頼むわ」と言っていました。 実際のところ、その上司
関連キーワード 人工知能 | コンプライアンス | 機械学習 2023年7月に米国ニューヨーク市は、自動人事採用決定ツール（AEDT：Automated Employment Decision Toolに対する規制法を施行した。AEDTは、AI（人工知能）技術やデータ分析などを活用して雇用を自動判断するツールを指す。AEDT規制法は、企業がAEDTを利用する場合、差別的な判断をしていないかどうか第三者の監査を受け、結果を公表することを義務付けている。この法律が新たなリスクを生み出し、ツールの利用にブレーキを掛ける可能性があると専門家は慎重視する。 AI技術を用いた人事採用ツール（AI人事採用ツール）の利用時に、企業が直面し得る課題は幾つかある。どのような課題なのか。 依然として危険なAI技術 必要なのは“健全な懐疑心”？ 併せて読みたいお薦め記事 連載：AI人事採用ツールがもたらすリスク
心理的安全性という概念がある。ここ十年ほどチームづくりの最重要ファクターであるともてはやされ、他方では粗雑な理解によって批判されてきた。急に人気の出たアイドルの宿命みたいなものを背負っている。 世間的なイメージがどのようなものか、少し羅列してみよう。 なんでも言える。否定されない。安心して働ける。不安がない。感情を大切にしてもらえる。あなたはあなたのままでいいと肯定される。 こうしたイメージを抱いている人もいるかもしれないが、残念ながらこれらは、心理的安全性の正しい姿からは遠くかけ離れている。ただ安心してほしいのは、こうした誤解をしている人は決して少なくないということだ。 手持ちのグーグルで「心理的安全性 誤解」と検索してみると、何ページにもわたって理解を正す記事が並んでいる。NewsPicksも、プレジデントも、朝日新聞も、Qiitaも、東洋経済も、あらゆるメディアが心理的安全性の誤解に
パワハラしていた先輩＝Aさん パワハラされていた新人＝Bさん Bさんが入社したのは2021年1月。 3月で退職する社員がいて、その後釜だった。 前任者から引き継ぎを受けた後は、Aさんがサポート係になってペア組んで仕事してた。 Aさんのパワハラっぽい行動が目立ち始めたのは、たしか2021年の秋ごろ。 「それ何回教えたら覚える？」という言葉が頻繁に聞こえてくるようになった。 Bさんが何か質問すると「マニュアルに載ってる」「自分で調べなさい」「前回教えたときにメモしてなかったの？」と突き放すような言動が目立ち始めた。 そうやって突き放すわりに「なんで勝手に判断した？こっちに確認してから動いて」みたいなこともよく言っていた。 Bさんの仕事の覚えが悪いことは何となく察していたが、それにしたって言いようがあるだろと思っていた。 だんだんとAさんの態度はきつくなっていって、部署の雰囲気が悪くなっていった
はじめに こんにちは！ NE開発ブログリレーもいよいよ大詰めとなって参りました。 本日28日目は、さくらいがお送りします。 以前Qiitaでも書きましたが、私は弊社でも異例となるカスタマーサクセス部→未経験で開発部のジョブチェンを経まして、現在エンジニア2年目に入りたてのヒヨッコです。 今回は、そんな私だから言える「CS時代に開発部に抱えていた不満」、そしてそれが「異動してどう変わったか」を、弊社先輩エンジニアの目を恐れず赤裸々にお話ししたいと思います。 CSと共に仕事をするエンジニアはもちろん、エンジニアの考えてることが分からん！というCSにとっても、この記事が一助となれば幸いです。 なぜエンジニアになったか Q, さくらいさんは、なぜエンジニアになったんですか？ A, 開発部に不満があるのに、何もできない自分が悔しかったからです。 ジョブチェン後、社内外問わず何度もいただいた質問です。
こんにちは。Magic Momentの髙橋です。 現在Magic Momentではチーム全体でプロダクト品質の向上と設計力の向上に積極的に取り組んでいます。 もちろんMagic Momentのエンジニアは技術力向上に貪欲で、自分たちで勉強会をしたり新しい技術の使い所について議論をすることが本当に大好きだと思います。しかし個人の日々の勉強ではなかなか得られない経験というのが「顧客向けに作るサービスの設計」だと思います。 いくら自社サービスを作っているMagic Momentであっても、すべてのエンジニアが等しくすべての設計の経験ができるとは限りません。そこで少しでも設計の経験を積んでもらい、それがプロダクトの品質向上にも貢献するような取組をはじめました。 それが「Product Development会」という設計を議論する会議体を作ったことです！ ここからは「Product Develop
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く