はじめに チーム全体の管理をするようになって1年程度が経過しました。今回記事を作成した目的は以下になります。 これまでチームで実践してきたことを整理し、今後の活動に向けた振り返りとする 同じような環境やこれからマネジメントを行う人の一助になれば かなり記事のボリュームが大きくなってしまいました…🙇 自分が実践してきたことや考えていることを振り返るのが主目的なので大目に見てもらえるとありがたいです。興味がある章や節だけでも、かいつまんで読んでいただければ幸いです。 前提 元々メンバー間の横のつながりは強いチームでしたが、上長や部長、その他ステークホルダーを巻き込んだ情報共有に弱みを感じていました。 私自身、チーム管理を引き継ぐ前はチーム内の1プロジェクト(3,4人規模)の開発と管理を担当しており、上記情報共有に頭を悩ませていました。 チームの開発スタイルについても少し補足します。 私達は社
必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす
チームビルディングの始め方
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 8週目の記事です！ 1年間連続達成まで 残り45週 となりました！ はじめに チームビルディングというとチーム開発をしている人ならばありふれた取り組みで普段からやっているよ！という人も多いかと思います。 しかしながら、初めてチームビルディングをリードする人にとってはどうやって取り組んだらいいか悩む人もいるのではないでしょうか？ 特に「いつやればいいのか？」「どうなったら成功と言えるのか？」といった疑問については言語化が難しいところでもあります。 この記事ではこれからチームビルディングにトライする人向けに、チームビルディングを始める際の考え方やHowの接続について解説します。 チームビルディングとは チームやチームビルディングの定義についてはペパボさんの以下のスライドが非常にわかりやすいので、
スタートアップで働くエンジニアが銀の弾丸を求めて愚直に働いている話 ~ 銀の弾丸なんてものは存在しない ~ - ANDPAD Tech Blog
こんにちは。こんばんは。おはようございます。アンドパッドで現在はバックエンドの方のエンジニアをやっている北村です。 アンドパッドには2021年4月にJOINしまして、現在までANDPADボード(以下ボード)の開発に携わっています。ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対してANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 lp.andpad.jp 半年ほど前に同チームのバックエンドエンジニアの原田さんに技術的負債を粉砕する記事を投稿してもらいました。今回はその続きの話をしようと思います。 前回記事は塵積もった技術的負債に対する技術的なアプローチがメインでしたが、今回はプロセスやチームビルディングの参考になりそうな話をバックエンドエンジニア目線で書いたものになります。 ANDPADボードの開発チーム紹介 話をイ
大塚流フロントエンド開発の歩き方
フロントエンド開発は考えることが多い。とくに 0 -> 1 の場合だと、何からはじめたらいいのか？が全然わからず、途方にくれてしまうこともあるでしょう。実際、ぼくがそうでした。 そして、そういった情報はなかなか検索しても出てこない。設計方法や実装方法みたいなものはたくさんあるのに。なので、書いてみました。 これは、ぼくがいくつかのフロントエンド開発を経て「これを最初に知っていれば、もうちょっとうまくできたかも？あの失敗がなかったかも？？」をまとめたものです。 フロントエンド開発に不慣れな方の参考になれば、これ幸いです。 まずは仕事のゴールを確認する プロジェクトや各フェーズごとに仕事のゴールは異なるため「何をもって仕事が完了したと言えるか？」を確認する。たとえば、要件定義フェーズであれば「画面仕様書が完成する」とか、開発フェーズであれば「API結合試験がすべて完了し、バグチケットがすべてク
3~4年前はモブプロにめちゃくちゃ苦手意識があったんだけど、最近はなぜか(?)モブプロを推進していく旗振りをしている。モブプロの取り組み自体については今度会社のTech Blogに書く予定だけど、このエントリでは自分の心境の変化にフォーカスを当てる。人間、数年すると割と変わるもんだなぁと思って面白かったので、記録に残しておく。 モブプロが苦手だった頃 なぜモブプロしようとなったか 今はどうモブプロしているか 所感 モブプロが苦手だった頃 前職の開発チームにいた頃(3年前くらい)で、状況はこんな感じ。 7~8人くらいの規模の開発チーム 京都と東京でそれぞれメンバーは分かれているが、まだ物理出社している時期だったので、大きなディスプレイに写された自分の画面をみんなが見るスタイル 時間は60~90分くらいだったかな タイピストはガンガン交代するスタイルではなく、1回を1~2人のタイピストで回して
読み物としてストックしておいてもらえると嬉しいです 時々読み返すことで、システムリプレイスのヒントになるかと思います 『「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022』のアドベントカレンダーに投稿させていただきました！ なぜこの記事を書こうと思ったかというと、世の中でこれから動きそうな（動いている）システムリプレイスPjが成功することを祈って自分が経験したこと、こうすればよかったことを書かせていただきました。 この記事を読んだからって大成功するかというと正直難しいかもしれません。 ただ、読んだからこそ大事なポイントの発見や事前に手を打てることが増えると思いますので、是非とも活用してシステムリプレイスの成功確率を上げてもらえればと思います。 タイトルが少し釣りっぽ
こんにちは。スクラムマスターの渡部です。 最近出版された「心理的安全性のつくりかた*1」という本が、発売から2ヶ月経たずに4版決まった*2り、Tech系カンファレンスでも心理的安全性についてのセッションがあって*3かなり盛り上がったりと、心理的安全性機運の高まりを感じている昨今です。 当然（？）ながら僕も「心理的安全性のつくりかた」を読んで、短期的にも長期的にも今後のふるまいを見直す良いきっかけになりました。 ただ、いかんせん「心理的安全性ってわかりにくい言葉だなぁ」という感想は今でも変わっていないので、備忘的な意味で次の2つのことをブログに残したいと思います。 このブログで扱うこと そもそも、心理的安全性ってなに？どんな効果があるの？ 心理的安全性を阻害するBadパターン このブログで扱わないこと 心理的安全性を構成する4つの因子の詳細 いかにして心理的安全性を高めていくか？ これらは書
こんにちは id:yoichi22 です。今回はチームビルディングの取り組みについて紹介します。 チームビルディングと聞くと、ドラッカー風エクササイズなどのワークショップを思い浮かべる方が多いかもしれません。チームメンバーが互いのことを知る、知ってもらう機会を作り、組織としてよりうまく動けるようにメンバーの関係性を高めるのがチームビルディングであり、その活動はワークショップに限ったことではありません。 ワークショップの場だけでなく、日々の仕事をこなしながら、チーム内のコミュニケーションの中で互いのことを知り合い、継続的にチームビルディングが進んで行くのが望ましいのですが、リモートワーク環境では、リアルなオフィスで席が近くに固まっている環境ではなかった、コミュニケーションの制約が存在します。 トピックが限定される。具体的な案件の相談とか、明確に形になったトピックについてコミュニケーションを始
続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜 - Repro Tech Blog
こんにちは、Platform Team というチームでマネージャーをしている荒引 (@a_bicky) です。 Platform Team は、データエンジニア・アーキテクト的な役割を担う Repro Core Unit と、インフラエンジニア・SRE 的な役割を担う Sys-Infra Unit から成るチームです。 先月 SRE Lounge #15 で「何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜」と題して次の発表をしたんですが、時間の都合上話せなかった内容があるので、それらについて触れたいと思います。 なお、当日の発表内容は動画でも視聴可能です。 アジェンダ 本エントリーのアジェンダは次のとおりです。 SRE Lounge #15 での発表内容の要約 Repro Core と Sys-Infra の棲み分け R
こんにちは。SmartHRで基本機能を開発しているプロダクトエンジニアの田中です。 私が所属するチームでは、新しくメンバーがジョインした際にチームビルディングのためにムービングモチベーターズを実施しています。 本記事ではムービングモチベーターズの紹介とやってみての感想をお伝えします。 背景 私が所属するチームでは、オンボーディング時はチームビルディングのためにドラッカー風エクササイズを実施していました。 ドラッカー風エクササイズとは、「アジャイルサムライ」の著者Jonathan Rasmussonが提唱したチームビルディングのための手法です。 チームメンバー同士で以下の4つの質問に答えてもらい、お互いの価値観や得意なことなどを知ることができます。 自分は何が得意なのか? 自分はどうやってチームの成果に貢献するつもりか? 自分が大切に思う価値は何か? チームメンバーは自分にどんな成果を期待し
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 私のチームでは2～4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。 ただ、チームの振り返りにて、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事はないでしょうか？ 過去の私のチームはそうでした。 それを改善し、全員が発言しまくる振り返りができるようになっても、だんだん振り返りがマンネリ化してしまう事はないでしょうか？ 過去の私のチームはそうでした。 また、チームに問題がなく順調すぎて、振り返りで挙がる改善アクションが些細なものになってしまう事
【入社エントリ】エンジニアから技術広報にジョブチェンジ！ - RAKUS Developers Blog | ラクス エンジニアブログ
4/16にラクスに入社しました、技術広報の飯野です。 入社して1ヶ月と少し経ちましたので入社エントリを書いてみることにしました。 本投稿は社外の方はもちろんですが社内メンバーにも自己紹介の絶好の機会ですので、社内外を問わず読み物としてお楽しみいただければと思います。 「技術広報って何をしているの？」「なぜエンジニアから技術広報に？」という方から「ラクスってどんな会社か知りたい！」という方にまで幅広く読んでいただければ幸いです。 目次 経歴 転職のきっかけ 入社の決め手 ラクスの技術広報とは 入社後やっていること 社内の雰囲気 入社後の課題感 まとめ 経歴 大学 文学部日本文学科を卒業しており、生粋の文系です。 入社1社目の常駐先で「好きな古文は源氏物語です」と言ったところ、大層変わった子扱いをされていました。（そんなに変わった人間ではないです。） 1社目 前述の中小SIerに新卒で入社し、
こんにちは。株式会社JMDC プロダクト開発部の三井です。 らくらく健助という健康保険組合の保健事業を支援するWeb分析サービスの開発を担当しています。 今年、JMDCではアドベントカレンダーに参加しています。 qiita.com 本記事は、JMDC Advent Calendar 2023 6日目の記事です。 2023年上期のOKRの一環として、チームにスクラムを導入したのでその活動を振り返ってみようと思います。 ※スクラムの説明は省略していますので、ある程度 知識がある方向けになります ざっくりまとめ なぜ導入するに至ったか やったこと 1. 導入準備 発足編 ● ゴールや方針、進め方はどのような形か？ ● チーム体制はどのような形か？ ● ツールは何を使うのか？ ● その他 勉強会編 直前編 1. スプリント0の期間はいつからいつまでにするか 2. スプリントの期間は何週間にするか
ベイジは創業13期目にしてはじめて「社員旅行」なるものを実施してみました。任意で参加者を募ったところ、39名の社員のうち30名が参加。その中には入社1ヶ月目のメンバーや来年4月入社予定の新卒学生もいました。 参加した社員のなかで以前に社員旅行の経験があったのは5名のみ。ほとんどのメンバーが社員旅行へ持っていたイメージは「いやいや参加するもの」「上司に気を使ってめんどくさそう」「昭和の行事」などのネガティブなものでした。 ところが旅行後にとったアンケートでは93%の社員が「とても満足」と回答する結果に。「社員旅行がこんなに楽しいとは思ってなかった」「旅行に行ってから社内のコミュニケーションが取りやすくなった」「会社がもっと好きになった」などのコメントが寄せられました。日報でも長文の感想が連日投稿され、「社員旅行ロス」という言葉が出るくらい大いに楽しんだ社員が多かったようです。 昭和の社内行事
今日は RubyKaigi Takeout 2020 の初日でした！でもまだ全部見れてません！ Ractor の話だけ聞いてそれ以降は弊社プロダクトのRe:Buildイベントに参加してました。 このイベントはそーだいさん(@soudai1025)をお招きして、アドバイスをいただきながら、プロダクトの価値の再確認やチームの方針の再定義などを目的にワークショップをするものです。 RubyKaigi を後回しにして参加したこのイベントですが、思ってた以上の収穫があったので、久しぶりに技術以外で記事を書くことにしました。 記事といっても忘れた頃に後から見返して思い出せるようにするためのメモです。 何が得られたか 一社員としてではなく一個人として得られたことを列挙すると... 漠然と抱いていた危機感や不安感の正体を掴めた これからの人生においてキャリアの軸に何を据えるかについてのヒントが得られた 仕
この記事は、マネーフォワード関西拠点 Advent Calendar 2022- Adventar の25日目の投稿です。 私はマネーフォワードの大阪開発拠点長として、また、エンジニアリングマネージャとして良いプロダクトを作れる良いチームを作るために日夜奮闘しています。 この記事では今年一年を振り返って、考えてきたこと、悩んできたこと、学んだことを言語化していこうと思います。 ちなみに筆者ってどんな人？についてはこちらの記事を閲覧いただけると喜びます。 私たちのチーム私の所属している関西開発拠点の多くのメンバーがビジネス向けのプロダクトの開発に携わっています。 具体的には以下の３プロダクトの開発を担当しています。 マネーフォワード クラウド会計Plus マネーフォワード クラウド連結会計 マネーフォワード クラウド アプリポータル 私はこの３つのプロダクトの開発チームに責任を持ち、マネジメ
こんにちは。食べログでAndroidアプリ開発をしている @sada と申します。 この記事は 食べログ Advent Calendar 2021 22日目の記事です。 はじめに 先月、TECH HILLS #1 というイベントで登壇させていただきました。 その時の資料はこちらです。 今回は上記資料でも触れている「レガシーコードと向き合う辛さ」についてお話できればと思います。 イベントにご参加いただけた方は発表やその後のパネルディスカッションなどでお話ししたような内容も含まれるかと思います。その点はご了承ください。 簡単にチーム紹介 私は食べログシステム本部アプリ開発部基盤チームに所属しています。 アプリ基盤チームはリファクタリングや環境改善を専門にしたチームで、以下のような業務を行っています。 OSバージョンアップ対応 ライブラリ、ツールの継続的なバージョンアップ・差し替え アーキテクチ
STORES で EC の開発をしているバックエンドエンジニアの @rry です。 今年の1月に入社してから、もう半年になります（早い） 最近はオフラインでの勉強会も開催されず、他社のエンジニアさんと話す機会がめっきり減った今日このごろです。 STORES では毎日わいわいプロダクト開発をしているのですが、普段どんな風に開発を進めているのか、オンボーディングの視点から書いていこうと思います！ ※ STORES ブランドは STORES (EC) と STORES ターミナルの2つのプロダクトがあります。今回は STORES (EC) のほうのオンボーディングについてのご紹介です。 オンボーディングの様子 入社してから今までを振り返ると、比較的スムーズに開発プロジェクトにジョインしていけたなと感じます。私の場合はこんな流れでオンボーディングしていきました。 入社 〜 1週間 簡単な PR を
2023/5/19 福岡で開催されたTechBrew 〜 一杯のお酒で繋がるエンジニアたち〜@福岡 での発表資料 https://findy.connpass.com/event/281690/
実装系 実装系 Effective C++ Effective Java Java言語で学ぶデザインパターン入門 プログラミングGauche CODE COMPLETE Pthreadsプログラミング アルゴリズムクイックリファレンス モダンC言語プログラミング レガシーコード改善ガイド レガシーコードからの脱却 集合知プログラミング 設計系 ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 ユースケース駆動開発実践ガイド Clean Architecture 達人に学ぶソフトウェアの構造と設計 モノリスからマイクロサービスへ 開発プロセス ソフトウェア見積り 人月の暗黙知を解き明かす アジャイルサムライ カイゼン・ジャーニー カンバン仕事術 教養 Unix/Linuxプログラミング理論と実践 C言語ポインタ完全制覇 コンピュータの構成と設計 マスタリングTCP/IP 入
スクラムチームに新しい仲間が入るので、ドラッカー風エクササイズによるチーム期待値調整ワークをやってみた - ContractS開発者ブログ
こんにちは。Holmesでスクラムマスターをしている吾郷です。 今回はチームビルディングの一環として行ったドラッカー風エクササイズについて振り返っていきたいと思います。 前提・状況 現在弊社では、毎月会社に数名の新しい仲間が入ってくれています。嬉しいことに、半年一緒にやってきたスクラムチーム（開発メンバー４人）にも、7月から新しい仲間が１名加わってくれることになりました。既存のメンバーはすごく楽しみにしています。 また、タックマンモデルを参考として、チームの成長段階から考えてみましょう。 仕事ができる人は｢正しい衝突｣が超得意！から抜粋 半年ほど活動している自チームの段階は混乱期〜統一期といったところでしょうか。チームメンバーが変更になることで、再度形成期を過ごしながらチームを作り上げる必要があります。 目的 そこで、半年やってきたチームの練度をできるだけ保ちながら、チームにおける不安や緊
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? アジャイルプラクティス一覧 アジャイル開発で使えそうなプラクティスを一覧化してみました。（カッコ内）は別名です。ググる際など参考にして下さい。なお、ここで言う「プラクティス」は広い意味で使っています。詳細は末尾の「注意点」を参照願います。このリストが誰かのお役に立てば幸いです。 開発方針/コンセプトの定義 インセプションデッキ エレベーターピッチ （エレベータースピーチ、Lift speeche、Elevator Statement） プロダクトビジョン プロダクトゴール プロジェクト憲章 （チーム憲章） ゴールデンサークル （Star
"hey Talk" PdM #2「エンジニアと連携した優先順位決め」を聞いてきました #heytalk - tuneの日記
はじめに hey.connpass.com 「企画側と開発側で深く議論して優先順位決めるの難しいなー」と課題を感じていたところ、heyさん主催の勉強会を見つけたので参加してきました。 tl; dr; 「やらなければならないもの」はやった先に何が得られるかを明確にすることで、着手順を明確にできたり、取り組むモチベーションをあげることができる。 工数大・リターン大のものはロードマップ積む、工数小・リターン中のものは手が空いた時にやっていく。 職種間を超えて意思決定をするには腹落ちしてもらえるまできちんと伝え合う努力をする必要がある。heyでは随筆のような長文ドキュメントをしたためる文化があり、それを活用している。 LT① 「STORES 決済における【攻めの安定性】」 プロダクト開発で考えなければならないことは2つあり、バランスを保たなければならない。 やりたいこと やらなければいけないこと
組織のさらなるカイゼンを。SmartHRの「交代制スクラムマスター」制度のお話 - SmartHR Tech Blog
こんにちは、プロダクトデザイングループのkgsiです。普段はnoteでデザイナー向けの記事を書いたりしてますが、今回は開発組織の取り組み紹介なので、テックブログデビューとなりました、ドキドキしますね。 SmartHRはすでにスクラムに関連する記事が多数公開されているとおり、開発手法としてスクラムが採用されています。 スクラムはすでに開発組織内に十分浸透し、大小さまざまな取り組みが行われていますが、この記事ではSmartHRの組織・チームを活性化を狙った取り組みのひとつ「交代制スクラムマスター」制度の紹介と、実際にスクラムマスターとなって取り組んだこと、その感想を共有したいと思います。 そもそもスクラムマスターって？ 制度紹介の前に「そもそもスクラムマスターって何だっけ？」という方向けに説明しておきますと... スクラムマスターは「スクラムの促進・支援に責任を持って、スクラムチームが生み出す
あけましておめでとうございます。 人生40年以上生きていると、新年を迎えても「12月の次は1月ですね」ぐらいの気持ちしか無いのですが、お正月休みを使って去年の振り返りを書いてみようと思います。 前半 新規ソフトウェア開発のPLをやっていました。今まで担当していたシングルテナントアプリケーションとは違い、マルチテナントということで色々考えることが多かったです。その分、AWSのソリューションをガッツリ使った仕組みにできて満足しています。この仕組の詳細についてはryosmsの発表内容を御覧ください。個人的にはS3にCSVファイルをアップロードすることでJasperReportを使って帳票が出力される仕組みが萌えポイントです。 この開発では私にとって初めてスクラムを実践してみました。開発初期の頃は正直なところスクラム開発をやりたくて、スクラム開発していた感がありました。今にして思えば通常のスクラム
派遣/フリーランス中心でも良い感じにチームビルディングする方法 - アジャイルコーチの備忘録
はじめに、アジャイルにおけるチームビルディングの重要性 マサチューセッツ工科大学のダニエル･キム教授が提唱した「組織の成功循環モデル」という考え方があります。上手くいっている組織は最初にメンバーの信頼関係や相互理解などのメンバーの「関係の質」を高め、結果グッドサイクルが発生し「結果の質」向上に結びつく。という理論です。 mag.executive.itmedia.co.jp また、ジェームス・コプリエンによる『組織パターン』では、全てのパターン言語の起点に「信頼で結ばれた共同体」パターンがあるとし、どんなテクニックを適用しようとしても、最初に信頼関係を構築しなかったら無意味だということが示唆されています。 ですので、もしアジャイルを組織に導入する際にまず何をすべきか? と聞かれたら、私は「チームビルディング」と答えます。一見遠回りに思えるかもしれませんが、チームの相互認識や信頼関係を向上さ
kaonavi Tech Talk #6 〜教科書には書いてないリアルなチーム開発座談会〜 2022.06.29 - 2022.06.29 カオナビのチーム数の変遷小松史明氏（以下、小松）：座談会に向けたプロローグという立ち位置で、カオナビの中でチームがどう組織に馴染んでいったかについて話そうと思います。豆知識のつもりで聞いてください。今日は1人で出ようと思ったのですが、直前に尾張部さんを捕まえて出てもらいました。よろしくお願いします。 尾張部佑亮氏（以下、尾張部）：お願いします。 小松：まずチーム数の変遷から紐解きます。タレントマネジメントシステム「カオナビ」のサービスが動き始めたのは2012年からなので、約10年です。（スライドを示して）こうやって見ると、最初はチーム開発はしていませんでしたが2019年くらいからチームが増えてきましたね。 尾張部さんから見て少し懐かしいかもしれませんが
綿密なコミュニケーションとリーダーシップで、役割の異なるメンバーを集め仕事を進める、テクニカルプログラムマネージャー（TPM）。LINE社のTPM2名が、その役割や難しさ、やりがいについて話しました。全2回。後半は、実際のプロジェクトにおけるTPMの役割と仕事の難しさについて。前回はこちら。 プロジェクトがうまく進まない・何からスタートしていいのかがわからない…TPMが求められる場面横道稔氏（以下、横道）：入社した時から「このプロダクトです」と決まって入るというよりは、それぞれの組織から依頼があって、プロダクトやプロジェクトに入るというやり方をしていると思います。 なので、そこの依頼の期待値によって、やはり役割が変わってくるんだろうなと思うのですが、どういうプロジェクトが多いんですか？ 大井さん、いかがですか？ なんかちょっと言いにくいなとかがあるかもしれませんが（笑）。 大井宏友氏（以下
フルリモートワークで雑談を6ヶ月続けて感じた雑談の重要性 - KAKEHASHI Tech Blog
こんにちは、Musubi開発チームで開発ディレクターを担当している門垣です。 この記事はカケハシアドベントカレンダー2021の11日目の記事になります。 カケハシではコロナ前からリモートワーク環境が整っており、私の所属するMusubi開発チームは全員がフルリモート環境で働いています。長野県や三重県といった遠隔地のメンバーも所属しているため、出社日も設けておりません。 本日は「フルリモートワークのチームがオンライン雑談を6ヶ月続けてみて感じたこと」を共有したいと思います。 フルリモートの会社に転職したいけど少し不安がある 今のリモートワーク環境をもっと楽しくしたい と考えている方の参考になると嬉しいです。 オンライン雑談を始めた３つの理由 まず最初に、なぜ私たちのチームがオンライン雑談を始めたのか、その理由を紹介します。 同じような状況のチームや、共感いただける方もいるのではないでしょうか。
こんにちは！エンジニアの富田です。先月末に開催したスキルマップを使ったチームビルディングがとても良かったので、内容を紹介したいと思います。 なぜやろうと思ったのか 前提として私が所属しているプロダクト開発チームは以下の構成です。 PdM 1名 デザイナー 2名 エンジニア 4名 ご覧の通り職能横断型のチーム構成になっており、チームとして4ヶ月ほどプロダクト開発を進めているのですが、お互いのことをあまり知らないなと感じることがありました。もちろん自己紹介をしたり、スクラムの朝会でちょっとした小話をしているのですが、なかなか自分の得意なこと、苦手なことを開示する機会がありませんでした。 自己開示することで、自分のことを知ってもらったり、周りのことをより知ることができるので、結果としてパフォーマンスやモチベーションが向上するのではないかと考えました。何かしらチームビルディングのワークをやりたいと
今更ながら「カイゼン・ジャーニー」を読みました。 チームビルディングの話といえば、Google話、HRT、Team Geek がこれまで印象的だった。一方「カイゼン・ジャーニー」のポイントは、 「日本の現場」に寄り添った、アジャイル開発の実践！ 現場のストーリーで、開発の神髄を学ぼう という、日本のチーム、日本人ならではのメンタルに寄り添ったところだと思った。 キーワード ともかくこのカイゼンのためのキーワードを追うだけで勉強になったので、以下記載。 「ファイブフィンガー」、「5本指メソッド」 5本：とってもうまくやれている 4本：うまくやれている感触あり 3本：可もなく不可もなく 2本：不安は少しある 1本：全然ダメで絶望的 効用 良いとも報告しづらい、ダメとも報告しづらい、があるチーム。 私のチームは慎重な性格のメンバーが多く、「絶好調!!」と自分から言うことに躊躇いをもつ人が殆どでし
こんばんは、りょーまです。 私事ですが30になりました。 心はいつまでも少年です。 さて、今回は期待のマネジメントについて書きます。 マネージャーには必須のスキルではないでしょうか。 具体的にやり方も書いていくので気になる方は是非試してみてください。 期待マネジメントとは 目的や目標を達成するために、何をするべきか、どのように振る舞うべきか。 チームやプロジェクトの期待をすり合わせる行いを期待マネジメントと言います。 冒頭で期待マネジメントは必須と書きました。 その理由としては、チームの成立に大きく影響するからです。 チームは、「共通の目的を持ち、互いに協力し支え合う」事が出来て、初めてチームです。 期待のマネジメントを怠ると、チームは躓き、ただの集団化します。 チームが躓く最大の要因は期待と行動(結果)のギャップ A「先日のリリース、バグ起こしちゃったね」 B「Cさんがテストしてくれてい
こんにちは。コネヒトに8月に入社し、サーバーサイドエンジニアをしている高橋です。 今回は私自身のチームジョインや、更なる新メンバーのジョインもあったので、「お互いを理解し期待をすり合わせる」ことを目的に「ドラッカー風エクササイズ」を開催しました！ オンラインでも開催できるように今回はmiroを使って実施したので、ご興味ある方はぜひご覧ください。 目的・背景 メンバーのスキルや経験、価値観、期待値などをお互いに理解し、期待をすり合わせる →背景は新メンバージョインに伴いチーム人数が多くなったので、チーム内でお互いの得意なことや期待値を把握し、理解促進を図りたいと思ったからです。 ドラッカー風エクササイズとは ドラッカー風エクササイズとは、アジャイルサムライの著者Jonathan Rasmusson(ジョナサン・ラスマセン)が名付けたチームビルディングのことです。 4つの質問に全員が答えること
STORES 予約 でエンジニアをしている natsume です。生後半年の子猫をお迎えし毎日癒やされています。 はい、かわいい STORES 予約 の開発チームは、自分が入社した2021年6月の段階ではエンジニア6名のチームでしたが、1年経った2022年6月では15名になり、エンジニアリングマネージャー（以下、EM）一人では全員を見るのは難しい人数となっていました。 そこでEMをもう一人立って半々で見ることとなり、そこに推薦していただきEMとなりました。 2022年7月からEMとして、開発をしつつもプロダクト開発に向き合う組織をよりよくしていくための施策を振り返っていきます！ 施策は同じEMの ykpythemind さんと議論しながら考えているものです。いつもありがとうございます！ 組織と開発チームの体制変更 組織構造の説明 STORES の組織構造は ◯◯部門 > ◯◯本部 > ◯◯
こんにちはCX事業本部IoT事業部のさかじです。 ハードウェア開発チームのチームビルディングの最初の一歩を行いました。 メンバーは北海道・千葉・大阪と離れているため直接会って話すことがありませんでしたが、都合よく北海道と大阪メンバーが東京へ行くことになりましたので全員で集まりチームビルディングを行いました。 なぜ「チームビルディング」するのか？と言いますと。 1. いつ案件が入ったとしてもスムーズにチームとして活動できるように 2. ハードウェア開発メンバーが一同に集まったことがない 3. ハードウェア開発できるメンバーは少ないため、案件が出てきた場合今回のメンバーが対応することになる 可能であれば1日ぐらいかけて行いたいところですが、まだ案件が無いのとそれほど時間が取れなかったため、2時間程度で実施できる内容を行いました。 別の案件でハードウェアを開発していたときのふりかえりはこちらです
配属初日〜1週間で実施
配属初日〜1週間 #[重要] 組織・チームのミッションを説明する #状況 #新メンバーが組織やチームのミッションを理解できていない場合、自律的な行動が困難になります。たとえば、新メンバーがアウトプットを出したとしても、ミッションからずれていて手戻りが発生するなど、パフォーマンスが出ないことがあります。 また、目的を表面上は理解したとしても、その必要性を腹落ちしていなければ、モチベーションが上がらないことがあります。 解決策 #チームリーダーから組織やチームのミッションを丁寧に説明します。達成すべき組織目標は何なのか、その中でチームはどのような役割を担っているのか、そして新メンバーが担当する業務はなぜ必要なのか、新メンバーと対話して、新メンバーが腹落ちして意義を理解できるようにします。新メンバーが自身のミッションを理解することで、より積極的に業務に取り組めるようになります。 このとき、組織に
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の 2 日目の記事です。 ログラスでエンジニアをしている塩谷 @shioyang です。こんにちは！ ログラスではエンジニア主体で採用活動を進めており、カジュアル面談の資料の改善なども現場で進めています。今回は「エンジニア向けの会社説明資料」の内容を更新したところ、なんと組織文化の自己認知につながってしまったお話しをします。 なぜ会社説明資料を更新することが組織の自己認知につながるのか？ そして、組織の自己認知を高めるためにはどんな要素が必要なのか？ 今回、気付いたことをまとめました。 組織作りに関心がある方、これから関わる方に届くと嬉しいです！ 会社説明資料の更新弊社では全社員で採用活動にコミットしていて、エンジニア採用では各エンジニアがカジュアル面談をしています。カジュアル面談の中で会社紹介を
この記事は Retty Advent Calendar 2020 18日目の記事です。 adventar.org はじめに こんにちは。RettyでWebエンジニアをやっている池田です。 技術的にはバックエンド系が好きなのですが、最近CSSの楽しさにも目覚め始めました。楽しいですよね、CSS。 さて、今年は新チーム編成〜チーム移籍があった年でした。 新チームになってチームビルディング的なものを意識してあれこれ取り組み、編成初期と後期でチーム文化が大きく変わったなーという経験をしました。 そこでチームのワーキングアグリーメント（Working Agreement）をふりかえりながら、どんなことに取り組んでどんな風にチーム文化が育ってきたのかをご紹介したいと思います。 ワーキングアグリーメントの導入 今年の3月に新チーム体制になり、ちょうど良いタイミングだと思ったので「チームとしての目標を決め
今回は、つい先日行った「期待交換エクササイズ」というオリジナルのチームビルディング施策をご紹介します。 なお、2025年2月に開催されるEMConf JPのプロポーザル供養企画でもあります☺️ 「遠慮せずに求め合うチーム」が最強説皆さんは普段、どんなチームをマネージしていますか？そしてそのチームは今、どのような状況にありますか？ 成果は出ているけどなんとなく雰囲気がよくない、あるいは雰囲気はいいけど成果に直結していない……などなど、いいところはそのままに、「もっとこうしたいのに！」と日々葛藤を抱える方も多いのではないでしょうか。 私は、最大最速で成果を出すプロダクト開発チームには、チームメンバー同士がお互いを認めながらも、遠慮せずにより期待し合う・求め合うことが不可欠だと考えています。皆の「背伸び」がチームの価値の総量を増やすなら、それはマネージャーだけがサポートするのではなく、メンバー同
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
10人規模のチームを自律自走させ、成長組織へ変革するため実践していること
チームトポロジー を読んだ - 下林明正のブログ
昔は苦手だったモブプロを今は推進する側になっていた - yasuhisa's blog
システムリプレイスするならこれだけは絶対知っておけ！知らないと失敗するぞ！ - Qiita
心理的安全性がもたらす効果と、安全性を阻害するBadパターン - ユニファ開発者ブログ
緩やかな自己開示による継続的チームビルディング - MonotaRO Tech Blog
チームメンバーの価値観を知る「ムービングモチベーターズ」の実践！ - SmartHR Tech Blog
どんよりマンネリした振り返りが、皆が主体的に発言してマンネリ化しないようになったプラクティス - Qiita
スクラムを0から導入してみた話 - JMDC TECH BLOG
昭和の社内行事を再構築～ベイジ流・社員旅行のススメ | knowledge / baigie
Re:Buildという社内イベントを行いました - 俺たちは雰囲気でコードを書いている
良いチームを目指して｜Keisuke Ookura@Money Forward
食べログアプリでの技術的負債との向き合い方 - Qiita
STORES (EC) のオンボーディングについて書きます - STORES Product Blog
「合意のない期待」を防ぐためのドラッカー風エクササイズ
これまで読んだソフトウェア関連で良かった本 - zigeninの日記
【リスト】アジャイル開発で使えるプラクティスを集めてみた - Qiita
2020年振り返り - tech-kazuhisa's blog
チーム開発は放っておいても組織には馴染まない 「試行錯誤・仲間・根気」の大事な関係性 | ログミーBusiness
「テクニカルプログラムマネージャーはオーケストラの指揮者」 メンバーの多様性を活かし、良いハーモニーを作るTPMの難しさとやりがい | ログミーBusiness
スキルマップを使ったチームビルディング - コネヒト開発者ブログ
「カイゼン・ジャーニー」を読んだので、その要点 - カイゼンのためのキーワード - Qiita
チームの期待をマネジメントする - Adwaysエンジニアブログ
ドラッカー風エクササイズをやってみました! - コネヒト開発者ブログ
初めてEMになって半年間でやってきたことの振り返り - STORES Product Blog
ハードウェア開発チームのチームビルディングをしてみた | DevelopersIO
エンジニア組織の隠れた魅力発見と組織文化の強化｜Tomohiro SHIOYA
ワーキングアグリーメントからふりかえるチーム文化の成長 - Retty Tech Blog
チームの「期待」を可視化しよう！「期待交換エクササイズ」をやってみた｜ar_tama