2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手
こんにちは。BASE株式会社上級執行役員SVP of Developmentの藤川です。2023年のアドベントカレンダーも実施したいと思っており、この記事が１日目になります。 自分自身がBASE社に正式ジョインしたのは2014年8月、取締役CTOとして入社しました。僕は２代目のCTOですが、その後、３代目にCTOを渡し、今では上級執行役員SVP of Developmentというちょっと珍しい肩書で仕事をしています。組織としてはCTOの上長でもあり、自己紹介では技術担当役員と表現することもあります。 自分がBASE社に入社した段階ではシリーズBを迎えていました。象徴としては藤田ファンドから出資をいただいてから、上場を意識した組織に変えていくという空気感だったと思います。 BASE社には正式ジョインする前から技術顧問として関わっていて、週一だけ会社にあらわれるおじさんだったのですが、そのタイ
すごい開発チーム育成ハンドブック プロダクト開発の｢やること｣リストはTrelloで順序立てておくとうまくいく ビジネス上の要求が変化しやすいときは、タスクの優先順位を2週間変えないようにする ビデオ会議で遠方チームに「伝わらない」と思ったら、一度「顔合わせ会」を開催する 「これは使えない」と言われたら、機能の意思決定を「担当者」に委ねる エンジニアに期間が「わからない」と言われたらタスクを細分化して具体的に 仕様を考えるときはエンジニアと対話する 開発チームの開発速度がわからないときは、短い期間で速度を計測する 開発状況を把握できないときはスクラムで開発する 「Scrum for Trello」でストーリーポイントをチームで共有する やってみないと分からないタスクは調査する スクラムが定着しないときは、2日のスプリントで慣らす ストーリーポイントの見積もりは「比べる」が基本 ストーリーポ
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
こんにちは。 ソウゾウのエキスパートチーム所属の@tenntennです。 7月9日に3時間半かけてみっちりと「エキスパートGo」という社内勉強会を開催しましたので、今回はそのレポートを書きます。 また良い機会ですので、私が所属するエキスパートチームについても少し触れようと思います。 なお、当日の発表資料はSlide Shareに公開しておりますので、ぜひご覧下さい。 www.slideshare.net エキスパートチームについて ソウゾウでは「技術をアウトプットするところに技術は集まる」という思いから、稼働の50%以上を技術コミュニティへの貢献や担当する技術の普及に取り組むエキスパートチームが存在します。 メンバーはGo Conferenceやgolang.tokyoなどを運営している私@tenntenn（Go/GCP担当）とDroidKaigiや技術書典などを運営する@mhidaka（
情報共有ツール「Qiita:Team」のプロダクトマネージャー（PM）を務める海野弘成さん。海野さんは「良いチーム＝自律的なチーム」と定義し、構成要素を共有した。 海野弘成が語った、「自律」と「心理的安全性」の重要性 ※2016年10月24日に開催された「Japan Product Manager Conference 2016」よりレポート記事をお届けします。 映し出されたスライドのタイトルは『Product Team Management』。 登壇したIncrements株式会社CEOで、情報共有ツール「Qiita:Team」のPMを務める海野弘成さんは、 自身の経験から「プロダクトマネージャー（PM）の関わるチームビルディング」に絞って発表した。セッションの冒頭で、海野さんは2つの条件を満たしているのが「良いチーム」であると定義する。 まずは「成果が出せるチーム」。プロダクトにおいて
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
99U ：貴重な戦力だったメンバーが会社を去ってしまい、急に補充が必要になった。もしくは、大きなプロジェクトが決まったため、必要なスキルをもっている人材を増員する必要が生じた。多くの採用に関する決定は、スピードが求められます。長期的な安定よりも短期的な痛みの埋め合わせのために、スピーディーな採用が実施されるのです。 とはいえ、クリエイティブなチームを築くために重要なのは、長期的な視点です。クリエイティブな職場の成功例・失敗例を見ると、強いチームをより強くするためには、押さえなければならない重要なポイントがあります。 この重要なポイントを押さえれば、バランスのとれた生産的なチームが生まれ、次のようなカルチャーがチームに浸透します。 重要なポイントとは、チームに取り入れるべき「5つの存在」です。ただ与えられるだけの仕事をこなすのではなく、情熱をもって仕事に取り組むチームを築くのに欠かせない、そ
「理研八十八年史から」の説明 † 理化学研究所のWeb「理研八十八年史から」にある 量子力学草創の渦中へ では、 「コペンハーゲン精神」は、「協力の精神、形式張らぬ自由な討議、しかもユーモアに裏打ちされた傾倒の精神」といわれる。 と書かれている。 ↑ P. Robertson, "The Early Years: The Niels Bohr Institute 1921-1930" から † This particular approach to the problem of physics, characterized by its emphasis on cooperation and its informal atmosphere, and stamped to no small degree by Bohr's own personality and outlook on lif
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
