並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 122件

新着順 人気順

ドラッカー風エクササイズの検索結果1 - 40 件 / 122件

  • 10人規模のチームを自律自走させ、成長組織へ変革するため実践していること

    はじめに チーム全体の管理をするようになって1年程度が経過しました。今回記事を作成した目的は以下になります。 これまでチームで実践してきたことを整理し、今後の活動に向けた振り返りとする 同じような環境やこれからマネジメントを行う人の一助になれば かなり記事のボリュームが大きくなってしまいました…🙇 自分が実践してきたことや考えていることを振り返るのが主目的なので大目に見てもらえるとありがたいです。興味がある章や節だけでも、かいつまんで読んでいただければ幸いです。 前提 元々メンバー間の横のつながりは強いチームでしたが、上長や部長、その他ステークホルダーを巻き込んだ情報共有に弱みを感じていました。 私自身、チーム管理を引き継ぐ前はチーム内の1プロジェクト(3,4人規模)の開発と管理を担当しており、上記情報共有に頭を悩ませていました。 チームの開発スタイルについても少し補足します。 私達は社

      10人規模のチームを自律自走させ、成長組織へ変革するため実践していること
    • チームトポロジー を読んだ - 下林明正のブログ

      必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンター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ボードの開発チーム紹介 話をイ

            スタートアップで働くエンジニアが銀の弾丸を求めて愚直に働いている話 ~ 銀の弾丸なんてものは存在しない ~ - ANDPAD Tech Blog
          • 大塚流フロントエンド開発の歩き方

            フロントエンド開発は考えることが多い。とくに 0 -> 1 の場合だと、何からはじめたらいいのか?が全然わからず、途方にくれてしまうこともあるでしょう。実際、ぼくがそうでした。 そして、そういった情報はなかなか検索しても出てこない。設計方法や実装方法みたいなものはたくさんあるのに。なので、書いてみました。 これは、ぼくがいくつかのフロントエンド開発を経て「これを最初に知っていれば、もうちょっとうまくできたかも?あの失敗がなかったかも??」をまとめたものです。 フロントエンド開発に不慣れな方の参考になれば、これ幸いです。 まずは仕事のゴールを確認する プロジェクトや各フェーズごとに仕事のゴールは異なるため「何をもって仕事が完了したと言えるか?」を確認する。たとえば、要件定義フェーズであれば「画面仕様書が完成する」とか、開発フェーズであれば「API結合試験がすべて完了し、バグチケットがすべてク

              大塚流フロントエンド開発の歩き方
            • 昔は苦手だったモブプロを今は推進する側になっていた - yasuhisa's blog

              3~4年前はモブプロにめちゃくちゃ苦手意識があったんだけど、最近はなぜか(?)モブプロを推進していく旗振りをしている。モブプロの取り組み自体については今度会社のTech Blogに書く予定だけど、このエントリでは自分の心境の変化にフォーカスを当てる。人間、数年すると割と変わるもんだなぁと思って面白かったので、記録に残しておく。 モブプロが苦手だった頃 なぜモブプロしようとなったか 今はどうモブプロしているか 所感 モブプロが苦手だった頃 前職の開発チームにいた頃(3年前くらい)で、状況はこんな感じ。 7~8人くらいの規模の開発チーム 京都と東京でそれぞれメンバーは分かれているが、まだ物理出社している時期だったので、大きなディスプレイに写された自分の画面をみんなが見るスタイル 時間は60~90分くらいだったかな タイピストはガンガン交代するスタイルではなく、1回を1~2人のタイピストで回して

                昔は苦手だったモブプロを今は推進する側になっていた - yasuhisa's blog
              • システムリプレイスするならこれだけは絶対知っておけ!知らないと失敗するぞ! - Qiita

                読み物としてストックしておいてもらえると嬉しいです 時々読み返すことで、システムリプレイスのヒントになるかと思います 『「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022』のアドベントカレンダーに投稿させていただきました! なぜこの記事を書こうと思ったかというと、世の中でこれから動きそうな(動いている)システムリプレイスPjが成功することを祈って自分が経験したこと、こうすればよかったことを書かせていただきました。 この記事を読んだからって大成功するかというと正直難しいかもしれません。 ただ、読んだからこそ大事なポイントの発見や事前に手を打てることが増えると思いますので、是非とも活用してシステムリプレイスの成功確率を上げてもらえればと思います。 タイトルが少し釣りっぽ

                  システムリプレイスするならこれだけは絶対知っておけ!知らないと失敗するぞ! - Qiita
                • 心理的安全性がもたらす効果と、安全性を阻害するBadパターン - ユニファ開発者ブログ

                  こんにちは。スクラムマスターの渡部です。 最近出版された「心理的安全性のつくりかた*1」という本が、発売から2ヶ月経たずに4版決まった*2り、Tech系カンファレンスでも心理的安全性についてのセッションがあって*3かなり盛り上がったりと、心理的安全性機運の高まりを感じている昨今です。 当然(?)ながら僕も「心理的安全性のつくりかた」を読んで、短期的にも長期的にも今後のふるまいを見直す良いきっかけになりました。 ただ、いかんせん「心理的安全性ってわかりにくい言葉だなぁ」という感想は今でも変わっていないので、備忘的な意味で次の2つのことをブログに残したいと思います。 このブログで扱うこと そもそも、心理的安全性ってなに?どんな効果があるの? 心理的安全性を阻害するBadパターン このブログで扱わないこと 心理的安全性を構成する4つの因子の詳細 いかにして心理的安全性を高めていくか? これらは書

                    心理的安全性がもたらす効果と、安全性を阻害するBadパターン - ユニファ開発者ブログ
                  • 緩やかな自己開示による継続的チームビルディング - MonotaRO Tech Blog

                    こんにちは id:yoichi22 です。今回はチームビルディングの取り組みについて紹介します。 チームビルディングと聞くと、ドラッカー風エクササイズなどのワークショップを思い浮かべる方が多いかもしれません。チームメンバーが互いのことを知る、知ってもらう機会を作り、組織としてよりうまく動けるようにメンバーの関係性を高めるのがチームビルディングであり、その活動はワークショップに限ったことではありません。 ワークショップの場だけでなく、日々の仕事をこなしながら、チーム内のコミュニケーションの中で互いのことを知り合い、継続的にチームビルディングが進んで行くのが望ましいのですが、リモートワーク環境では、リアルなオフィスで席が近くに固まっている環境ではなかった、コミュニケーションの制約が存在します。 トピックが限定される。具体的な案件の相談とか、明確に形になったトピックについてコミュニケーションを始

                      緩やかな自己開示による継続的チームビルディング - MonotaRO Tech Blog
                    • 続・何でも屋になっている 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

                        続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜 - Repro Tech Blog
                      • Manager不要論はなぜ起きる?|dora_e_m

                        OSTで「マネージャーを救え!」テーマを出させてもらいました。ご一緒していただいた方々に感謝です!終わった後に自分の整理のためにまとめてみました。#RSGT2020 pic.twitter.com/XUWU6OKxfY — gaoryu/ (@DiscoveryCoach) January 10, 2020 RSGT3日目のOSTで、gaoryuさんが「マネージャーを救え!」というテーマを掲げていた。 ここには大勢の人が集まっていた。マネージャーに何かしらの必要性を見出している人、「No One Left Behind」の精神でマネージャーと協働する道を探そうとしている人々だろう。こういった人々がいる、というだけで救われる気持ちだ。 この場で中村洋さんと話したのが、「マネージャーへの期待値が曖昧なので、不要論が出るのではないか」ということだった。 マネージャー何する人ぞ「マネージャーへの期

                          Manager不要論はなぜ起きる?|dora_e_m
                        • チームメンバーの価値観を知る「ムービングモチベーターズ」の実践! - SmartHR Tech Blog

                          こんにちは。SmartHRで基本機能を開発しているプロダクトエンジニアの田中です。 私が所属するチームでは、新しくメンバーがジョインした際にチームビルディングのためにムービングモチベーターズを実施しています。 本記事ではムービングモチベーターズの紹介とやってみての感想をお伝えします。 背景 私が所属するチームでは、オンボーディング時はチームビルディングのためにドラッカー風エクササイズを実施していました。 ドラッカー風エクササイズとは、「アジャイルサムライ」の著者Jonathan Rasmussonが提唱したチームビルディングのための手法です。 チームメンバー同士で以下の4つの質問に答えてもらい、お互いの価値観や得意なことなどを知ることができます。 自分は何が得意なのか? 自分はどうやってチームの成果に貢献するつもりか? 自分が大切に思う価値は何か? チームメンバーは自分にどんな成果を期待し

                            チームメンバーの価値観を知る「ムービングモチベーターズ」の実践! - SmartHR Tech Blog
                          • どんよりマンネリした振り返りが、皆が主体的に発言してマンネリ化しないようになったプラクティス - Qiita

                            1. はじめに 私のチームでは2~4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。 ただ、チームの振り返りにて、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事はないでしょうか? 過去の私のチームはそうでした。 それを改善し、全員が発言しまくる振り返りができるようになっても、だんだん振り返りがマンネリ化してしまう事はないでしょうか? 過去の私のチームはそうでした。 また、チームに問題がなく順調すぎて、振り返りで挙がる改善アクションが些細なものになってしまう事はないでしょうか? 過去の私のチームはそうでした。 本稿は、その状態から脱却し、皆が主体的に発言するマンネリ化しない振り返りを実施し、新しいチャレンジをたくさんするようになったプラクティスを紹介します。 なお、前提として以降で紹介する振り返りはすべてリモート

                              どんよりマンネリした振り返りが、皆が主体的に発言してマンネリ化しないようになったプラクティス - Qiita
                            • 【入社エントリ】エンジニアから技術広報にジョブチェンジ! - RAKUS Developers Blog | ラクス エンジニアブログ

                              4/16にラクスに入社しました、技術広報の飯野です。 入社して1ヶ月と少し経ちましたので入社エントリを書いてみることにしました。 本投稿は社外の方はもちろんですが社内メンバーにも自己紹介の絶好の機会ですので、社内外を問わず読み物としてお楽しみいただければと思います。 「技術広報って何をしているの?」「なぜエンジニアから技術広報に?」という方から「ラクスってどんな会社か知りたい!」という方にまで幅広く読んでいただければ幸いです。 目次 経歴 転職のきっかけ 入社の決め手 ラクスの技術広報とは 入社後やっていること 社内の雰囲気 入社後の課題感 まとめ 経歴 大学 文学部日本文学科を卒業しており、生粋の文系です。 入社1社目の常駐先で「好きな古文は源氏物語です」と言ったところ、大層変わった子扱いをされていました。(そんなに変わった人間ではないです。) 1社目 前述の中小SIerに新卒で入社し、

                                【入社エントリ】エンジニアから技術広報にジョブチェンジ! - RAKUS Developers Blog | ラクス エンジニアブログ
                              • スクラムを0から導入してみた話 - JMDC TECH BLOG

                                こんにちは。株式会社JMDC プロダクト開発部の三井です。 らくらく健助という健康保険組合の保健事業を支援するWeb分析サービスの開発を担当しています。 今年、JMDCではアドベントカレンダーに参加しています。 qiita.com 本記事は、JMDC Advent Calendar 2023 6日目の記事です。 2023年上期のOKRの一環として、チームにスクラムを導入したのでその活動を振り返ってみようと思います。 ※スクラムの説明は省略していますので、ある程度 知識がある方向けになります ざっくりまとめ なぜ導入するに至ったか やったこと 1. 導入準備 発足編 ● ゴールや方針、進め方はどのような形か? ● チーム体制はどのような形か? ● ツールは何を使うのか? ● その他 勉強会編 直前編 1. スプリント0の期間はいつからいつまでにするか 2. スプリントの期間は何週間にするか

                                  スクラムを0から導入してみた話 - JMDC TECH BLOG
                                • 昭和の社内行事を再構築~ベイジ流・社員旅行のススメ | knowledge / baigie

                                  ベイジは創業13期目にしてはじめて「社員旅行」なるものを実施してみました。任意で参加者を募ったところ、39名の社員のうち30名が参加。その中には入社1ヶ月目のメンバーや来年4月入社予定の新卒学生もいました。 参加した社員のなかで以前に社員旅行の経験があったのは5名のみ。ほとんどのメンバーが社員旅行へ持っていたイメージは「いやいや参加するもの」「上司に気を使ってめんどくさそう」「昭和の行事」などのネガティブなものでした。 ところが旅行後にとったアンケートでは93%の社員が「とても満足」と回答する結果に。「社員旅行がこんなに楽しいとは思ってなかった」「旅行に行ってから社内のコミュニケーションが取りやすくなった」「会社がもっと好きになった」などのコメントが寄せられました。日報でも長文の感想が連日投稿され、「社員旅行ロス」という言葉が出るくらい大いに楽しんだ社員が多かったようです。 昭和の社内行事

                                    昭和の社内行事を再構築~ベイジ流・社員旅行のススメ | knowledge / baigie
                                  • Re:Buildという社内イベントを行いました - 俺たちは雰囲気でコードを書いている

                                    今日は RubyKaigi Takeout 2020 の初日でした!でもまだ全部見れてません! Ractor の話だけ聞いてそれ以降は弊社プロダクトのRe:Buildイベントに参加してました。 このイベントはそーだいさん(@soudai1025)をお招きして、アドバイスをいただきながら、プロダクトの価値の再確認やチームの方針の再定義などを目的にワークショップをするものです。 RubyKaigi を後回しにして参加したこのイベントですが、思ってた以上の収穫があったので、久しぶりに技術以外で記事を書くことにしました。 記事といっても忘れた頃に後から見返して思い出せるようにするためのメモです。 何が得られたか 一社員としてではなく一個人として得られたことを列挙すると... 漠然と抱いていた危機感や不安感の正体を掴めた これからの人生においてキャリアの軸に何を据えるかについてのヒントが得られた 仕

                                      Re:Buildという社内イベントを行いました - 俺たちは雰囲気でコードを書いている
                                    • 「高速」な開発を目指して。「minne」のAndroidエンジニアに、2020年の取り組みについて聞いてみた! - ペパボHRブログ

                                      インタビュー 「高速」な開発を目指して。「minne」のAndroidエンジニアに、2020年の取り組みについて聞いてみた! 2020.2.21 minne エンジニア ペパボでは現在Androidエンジニアの採用に力を入れています。 今回のインタビューでは「minne」のAndroidエンジニアの2人に、2020年取り組む施策への想いや、どんな人と働きたいかなどをインタビューしました。 ※現在、GMOペパボを含むGMOインターネットグループでは、新型コロナウイルス感染防止のため、在宅勤務を行っています。今回のインタビューも在宅勤務中に行ったため、画面越しの写真となっております。 夏坂 友輔(なつさか ゆうすけ) Twitter:@ntsk__ あだな:なっつ minne事業部マーケットグループ エンジニア。ぷよぷよ通が好き。 今年の重点施策は4つ! ーお二人は普段どんなお仕事をしているん

                                        「高速」な開発を目指して。「minne」のAndroidエンジニアに、2020年の取り組みについて聞いてみた! - ペパボHRブログ
                                      • 良いチームを目指して|Keisuke Ookura@Money Forward

                                        この記事は、マネーフォワード関西拠点 Advent Calendar 2022- Adventar の25日目の投稿です。 私はマネーフォワードの大阪開発拠点長として、また、エンジニアリングマネージャとして良いプロダクトを作れる良いチームを作るために日夜奮闘しています。 この記事では今年一年を振り返って、考えてきたこと、悩んできたこと、学んだことを言語化していこうと思います。 ちなみに筆者ってどんな人?についてはこちらの記事を閲覧いただけると喜びます。 私たちのチーム私の所属している関西開発拠点の多くのメンバーがビジネス向けのプロダクトの開発に携わっています。 具体的には以下の3プロダクトの開発を担当しています。 マネーフォワード クラウド会計Plus マネーフォワード クラウド連結会計 マネーフォワード クラウド アプリポータル 私はこの3つのプロダクトの開発チームに責任を持ち、マネジメ

                                          良いチームを目指して|Keisuke Ookura@Money Forward
                                        • 食べログアプリでの技術的負債との向き合い方 - Qiita

                                          こんにちは。食べログでAndroidアプリ開発をしている @sada と申します。 この記事は 食べログ Advent Calendar 2021 22日目の記事です。 はじめに 先月、TECH HILLS #1 というイベントで登壇させていただきました。 その時の資料はこちらです。 今回は上記資料でも触れている「レガシーコードと向き合う辛さ」についてお話できればと思います。 イベントにご参加いただけた方は発表やその後のパネルディスカッションなどでお話ししたような内容も含まれるかと思います。その点はご了承ください。 簡単にチーム紹介 私は食べログシステム本部アプリ開発部基盤チームに所属しています。 アプリ基盤チームはリファクタリングや環境改善を専門にしたチームで、以下のような業務を行っています。 OSバージョンアップ対応 ライブラリ、ツールの継続的なバージョンアップ・差し替え アーキテクチ

                                            食べログアプリでの技術的負債との向き合い方 - Qiita
                                          • ホワイトボードにかこまれて開発する - Sansan Tech Blog

                                            こんにちは、気づいたらSansanに入社してから1年が経っていました。 関西支店勤務で、プロダクト開発部のチーム MAIDO でエンジニアをしています、奥野です。 Sansan のオフィスやラボはオフィスデザインがどこも特徴的です。 草木があったり、オープンなスペース、京町家…といった多種多様なデザインが楽しめます。普段とは違うオフィスに行くと高揚感を感じますが、デザインの違いからくるものが大きいかもしれません。 さて、我らの関西支店にもそういった特徴があるのでしょうか? 関西支店は今年7月にリニューアルしており、スタイリッシュな要素が増えました。全面ガラス張りのオープン感が印象的です。 オフィスフロアの入り口からの光景です 今回は、私が推したい関西支店の特徴として、ホワイトボードにまつわるお話をさせていただきたいと思います。 ホワイトボードのある風景 共有スペースを遠景で写すと、ホワイト

                                              ホワイトボードにかこまれて開発する - Sansan Tech Blog
                                            • STORES (EC) のオンボーディングについて書きます - STORES Product Blog

                                              STORES で EC の開発をしているバックエンドエンジニアの @rry です。 今年の1月に入社してから、もう半年になります(早い) 最近はオフラインでの勉強会も開催されず、他社のエンジニアさんと話す機会がめっきり減った今日このごろです。 STORES では毎日わいわいプロダクト開発をしているのですが、普段どんな風に開発を進めているのか、オンボーディングの視点から書いていこうと思います! ※ STORES ブランドは STORES (EC) と STORES ターミナルの2つのプロダクトがあります。今回は STORES (EC) のほうのオンボーディングについてのご紹介です。 オンボーディングの様子 入社してから今までを振り返ると、比較的スムーズに開発プロジェクトにジョインしていけたなと感じます。私の場合はこんな流れでオンボーディングしていきました。 入社 〜 1週間 簡単な PR を

                                                STORES (EC) のオンボーディングについて書きます - STORES Product Blog
                                              • 「合意のない期待」を防ぐためのドラッカー風エクササイズ

                                                2023/5/19 福岡で開催されたTechBrew 〜 一杯のお酒で繋がるエンジニアたち〜@福岡 での発表資料 https://findy.connpass.com/event/281690/

                                                  「合意のない期待」を防ぐためのドラッカー風エクササイズ
                                                • これまで読んだソフトウェア関連で良かった本 - zigeninの日記

                                                  実装系 実装系 Effective C++ Effective Java Java言語で学ぶデザインパターン入門 プログラミングGauche CODE COMPLETE Pthreadsプログラミング アルゴリズムクイックリファレンス モダンC言語プログラミング レガシーコード改善ガイド レガシーコードからの脱却 集合知プログラミング 設計系 ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 ユースケース駆動開発実践ガイド Clean Architecture 達人に学ぶソフトウェアの構造と設計 モノリスからマイクロサービスへ 開発プロセス ソフトウェア見積り 人月の暗黙知を解き明かす アジャイルサムライ カイゼン・ジャーニー カンバン仕事術 教養 Unix/Linuxプログラミング理論と実践 C言語ポインタ完全制覇 コンピュータの構成と設計 マスタリングTCP/IP 入

                                                    これまで読んだソフトウェア関連で良かった本 - zigeninの日記
                                                  • スクラムチームに新しい仲間が入るので、ドラッカー風エクササイズによるチーム期待値調整ワークをやってみた - ContractS開発者ブログ

                                                    こんにちは。Holmesでスクラムマスターをしている吾郷です。 今回はチームビルディングの一環として行ったドラッカー風エクササイズについて振り返っていきたいと思います。 前提・状況 現在弊社では、毎月会社に数名の新しい仲間が入ってくれています。嬉しいことに、半年一緒にやってきたスクラムチーム(開発メンバー4人)にも、7月から新しい仲間が1名加わってくれることになりました。既存のメンバーはすごく楽しみにしています。 また、タックマンモデルを参考として、チームの成長段階から考えてみましょう。 仕事ができる人は「正しい衝突」が超得意!から抜粋 半年ほど活動している自チームの段階は混乱期〜統一期といったところでしょうか。チームメンバーが変更になることで、再度形成期を過ごしながらチームを作り上げる必要があります。 目的 そこで、半年やってきたチームの練度をできるだけ保ちながら、チームにおける不安や緊

                                                      スクラムチームに新しい仲間が入るので、ドラッカー風エクササイズによるチーム期待値調整ワークをやってみた - ContractS開発者ブログ
                                                    • "hey Talk" PdM #2「エンジニアと連携した優先順位決め」を聞いてきました #heytalk - tuneの日記

                                                      はじめに hey.connpass.com 「企画側と開発側で深く議論して優先順位決めるの難しいなー」と課題を感じていたところ、heyさん主催の勉強会を見つけたので参加してきました。 tl; dr; 「やらなければならないもの」はやった先に何が得られるかを明確にすることで、着手順を明確にできたり、取り組むモチベーションをあげることができる。 工数大・リターン大のものはロードマップ積む、工数小・リターン中のものは手が空いた時にやっていく。 職種間を超えて意思決定をするには腹落ちしてもらえるまできちんと伝え合う努力をする必要がある。heyでは随筆のような長文ドキュメントをしたためる文化があり、それを活用している。 LT① 「STORES 決済における【攻めの安定性】」 プロダクト開発で考えなければならないことは2つあり、バランスを保たなければならない。 やりたいこと やらなければいけないこと

                                                        "hey Talk" PdM #2「エンジニアと連携した優先順位決め」を聞いてきました #heytalk - tuneの日記
                                                      • リモートワークしながら自転車で1500km旅してきた - kubell Creator's Note

                                                        おひさしぶりです。サーバーサイド開発部PHPチームやまざきです。 クリーンなアーキテクチャはクリーンなペダリングができて初めてスタートラインにたてると思っています。 今回は、伊達と酔狂だけで自転車部をやっているやまざきがリモートワークしながら 太平洋から日本海までの本州縦貫 1215km 太平洋から瀬戸内海までの四国縦貫 364km 計1500km超のサイクリングをしてきた、誰にも得にならないようなことを共有しようと思います。 まあ、伊達と酔狂でやってますから仕方ないです。 自己紹介 はじめに 自転車部について 自転車トレーニング用のウェイトについて 部活動の拠点 表記について シーズン1 本州縦貫ライド DAY1 熱海から南伊豆 南伊豆の逗留地 SS1 石廊崎周遊 SS2 青野大師ダム周遊 DAY2 南伊豆から神奈川県愛甲郡清川村 DAY3 神奈川県愛甲郡清川村から神奈川県鎌倉市 SS3

                                                          リモートワークしながら自転車で1500km旅してきた - kubell Creator's Note
                                                        • チーム開発は放っておいても組織には馴染まない 「試行錯誤・仲間・根気」の大事な関係性

                                                          カオナビにおけるリアルなチームエピソード・チームビルディングのための試行錯誤を座談会形式で発信する「kaonavi Tech Talk #6 ~教科書には書いてないリアルなチーム開発座談会~」。座談会に向けたプロローグに、小松氏と尾張部氏が登壇。カオナビのチーム変遷について話します。 カオナビのチーム数の変遷 小松史明氏(以下、小松):座談会に向けたプロローグという立ち位置で、カオナビの中でチームがどう組織に馴染んでいったかについて話そうと思います。豆知識のつもりで聞いてください。今日は1人で出ようと思ったのですが、直前に尾張部さんを捕まえて出てもらいました。よろしくお願いします。 尾張部佑亮氏(以下、尾張部):お願いします。 小松:まずチーム数の変遷から紐解きます。タレントマネジメントシステム「カオナビ」のサービスが動き始めたのは2012年からなので、約10年です。(スライドを示して)こ

                                                            チーム開発は放っておいても組織には馴染まない 「試行錯誤・仲間・根気」の大事な関係性
                                                          • 組織のさらなるカイゼンを。SmartHRの「交代制スクラムマスター」制度のお話 - SmartHR Tech Blog

                                                            こんにちは、プロダクトデザイングループのkgsiです。普段はnoteでデザイナー向けの記事を書いたりしてますが、今回は開発組織の取り組み紹介なので、テックブログデビューとなりました、ドキドキしますね。 SmartHRはすでにスクラムに関連する記事が多数公開されているとおり、開発手法としてスクラムが採用されています。 スクラムはすでに開発組織内に十分浸透し、大小さまざまな取り組みが行われていますが、この記事ではSmartHRの組織・チームを活性化を狙った取り組みのひとつ「交代制スクラムマスター」制度の紹介と、実際にスクラムマスターとなって取り組んだこと、その感想を共有したいと思います。 そもそもスクラムマスターって? 制度紹介の前に「そもそもスクラムマスターって何だっけ?」という方向けに説明しておきますと... スクラムマスターは「スクラムの促進・支援に責任を持って、スクラムチームが生み出す

                                                              組織のさらなるカイゼンを。SmartHRの「交代制スクラムマスター」制度のお話 - SmartHR Tech Blog
                                                            • 2020年振り返り - tech-kazuhisa's blog

                                                              あけましておめでとうございます。 人生40年以上生きていると、新年を迎えても「12月の次は1月ですね」ぐらいの気持ちしか無いのですが、お正月休みを使って去年の振り返りを書いてみようと思います。 前半 新規ソフトウェア開発のPLをやっていました。今まで担当していたシングルテナントアプリケーションとは違い、マルチテナントということで色々考えることが多かったです。その分、AWSのソリューションをガッツリ使った仕組みにできて満足しています。この仕組の詳細についてはryosmsの発表内容を御覧ください。個人的にはS3にCSVファイルをアップロードすることでJasperReportを使って帳票が出力される仕組みが萌えポイントです。 この開発では私にとって初めてスクラムを実践してみました。開発初期の頃は正直なところスクラム開発をやりたくて、スクラム開発していた感がありました。今にして思えば通常のスクラム

                                                                2020年振り返り - tech-kazuhisa's blog
                                                              • 【リスト】アジャイル開発で使えるプラクティスを集めてみた - Qiita

                                                                アジャイルプラクティス一覧 アジャイル開発で使えそうなプラクティスを一覧化してみました。(カッコ内)は別名です。ググる際など参考にして下さい。なお、ここで言う「プラクティス」は広い意味で使っています。詳細は末尾の「注意点」を参照願います。このリストが誰かのお役に立てば幸いです。 開発方針/コンセプトの定義 インセプションデッキ エレベーターピッチ (エレベータースピーチ、Lift speeche、Elevator Statement) プロダクトビジョン プロダクトゴール プロジェクト憲章 ゴールデンサークル (Start With Why) チームビルディング ナイスなチーム名 (Team Branding、Team Naming、Group Identity) 星取表 (スキルマップ、スキルマトリックス) トラックナンバー (トラック係数、バス係数、ハネムーンナンバー) ドラッカー風エ

                                                                  【リスト】アジャイル開発で使えるプラクティスを集めてみた - Qiita
                                                                • GMOペパボに入社して3ヶ月が経った|maki

                                                                  この写真は年末の社員旅行で無人島に遊びに行った時のものです。 在宅勤務2週目にして、自宅の作業環境の悪さから腰が爆発しそうな私です。 さて、長いようで短い試用期間が終了しました。今はどちらかというと、もう3ヶ月経ってしまったのか、という思いの方が強いです。 入社の経緯は本当に運が良かったからだと思っています。大名エンジニアカレッジというプログラミングブートキャンプに参加して、そこからご縁がつながって採用していただけました。 エンジニアとしては何もできない私を、人間性や過去の異業種での経験など、ポテンシャルを見て採用してくださったのは本当にありがたいです。 アウトプットを大切にしている会社ということもあり、私のnoteなども見ていただけたようです。私がなぜアウトプットを大事にしているか、などを面接でお話しした記憶があります。 でも正直今でも、たまに自分で驚きます。 まさか、未経験の私が憧れて

                                                                    GMOペパボに入社して3ヶ月が経った|maki
                                                                  • 「テクニカルプログラムマネージャーはオーケストラの指揮者」 メンバーの多様性を活かし、良いハーモニーを作るTPMの難しさとやりがい

                                                                    プロジェクトがうまく進まない・何からスタートしていいのかがわからない…TPMが求められる場面 横道稔氏(以下、横道):入社した時から「このプロダクトです」と決まって入るというよりは、それぞれの組織から依頼があって、プロダクトやプロジェクトに入るというやり方をしていると思います。 なので、そこの依頼の期待値によって、やはり役割が変わってくるんだろうなと思うのですが、どういうプロジェクトが多いんですか? 大井さん、いかがですか? なんかちょっと言いにくいなとかがあるかもしれませんが(笑)。 大井宏友氏(以下、大井):やはりものすごくたくさんの人がサービスに関わっている、あるいはグローバルでさまざまな人たちと1つのプロダクトを作っているので、進め方や文化の違いなど、いろいろな理由でうまく進まない状態に陥っている時がけっこうあるんですよね。そういった時にリクエストが来ることがわりと多いと思います。

                                                                      「テクニカルプログラムマネージャーはオーケストラの指揮者」 メンバーの多様性を活かし、良いハーモニーを作るTPMの難しさとやりがい
                                                                    • 【Backlog導入・業務改善支援オプション】のご紹介 | Backlogブログ

                                                                      こんにちは、中村です!この度、ヌーラボからBacklogユーザーのみなさまに向けて「Backlog導入・業務改善支援オプション」の提供を開始しました。私たちが目指すものと、支援オプションの概要についてお届けいたします。 ヌーラボが目指すもの:「プロジェクトの成功」に向けて 最初に、私たちが目指すものについて簡単に説明します。 私たちが掲げているビジョン・もしくはユーザーのみなさまが望んでいることは「Backlogを使う」だけではなく、そのことによって「プロジェクトを成功させたい」ということでしょう。 そのために、Backlogというツールを10年以上も提供してきました。ありがたいことに、10年間サービスを提供し続けるなかで、Backlogユーザーもだいぶ増えてきました。 ここから「プロジェクトが成功する」現場をさらに増やすためには、「1. Backlogを適切に導入・活用」してもらえるかが

                                                                        【Backlog導入・業務改善支援オプション】のご紹介 | Backlogブログ
                                                                      • フルリモートワークで雑談を6ヶ月続けて感じた雑談の重要性 - KAKEHASHI Tech Blog

                                                                        こんにちは、Musubi開発チームで開発ディレクターを担当している門垣です。 この記事はカケハシアドベントカレンダー2021の11日目の記事になります。 カケハシではコロナ前からリモートワーク環境が整っており、私の所属するMusubi開発チームは全員がフルリモート環境で働いています。長野県や三重県といった遠隔地のメンバーも所属しているため、出社日も設けておりません。 本日は「フルリモートワークのチームがオンライン雑談を6ヶ月続けてみて感じたこと」を共有したいと思います。 フルリモートの会社に転職したいけど少し不安がある 今のリモートワーク環境をもっと楽しくしたい と考えている方の参考になると嬉しいです。 オンライン雑談を始めた3つの理由 まず最初に、なぜ私たちのチームがオンライン雑談を始めたのか、その理由を紹介します。 同じような状況のチームや、共感いただける方もいるのではないでしょうか。

                                                                          フルリモートワークで雑談を6ヶ月続けて感じた雑談の重要性 - KAKEHASHI Tech Blog
                                                                        • 派遣/フリーランス中心でも良い感じにチームビルディングする方法 - アジャイルコーチの備忘録

                                                                          はじめに、アジャイルにおけるチームビルディングの重要性 マサチューセッツ工科大学のダニエル・キム教授が提唱した「組織の成功循環モデル」という考え方があります。上手くいっている組織は最初にメンバーの信頼関係や相互理解などのメンバーの「関係の質」を高め、結果グッドサイクルが発生し「結果の質」向上に結びつく。という理論です。 mag.executive.itmedia.co.jp また、ジェームス・コプリエンによる『組織パターン』では、全てのパターン言語の起点に「信頼で結ばれた共同体」パターンがあるとし、どんなテクニックを適用しようとしても、最初に信頼関係を構築しなかったら無意味だということが示唆されています。 ですので、もしアジャイルを組織に導入する際にまず何をすべきか? と聞かれたら、私は「チームビルディング」と答えます。一見遠回りに思えるかもしれませんが、チームの相互認識や信頼関係を向上さ

                                                                            派遣/フリーランス中心でも良い感じにチームビルディングする方法 - アジャイルコーチの備忘録
                                                                          • チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで | 翔泳社

                                                                            「ともに考え、ともにつくる」――スクラムやアジャイルを導入した現場で 直面する開発チーム・マネジメントの問題に立ち向かうすべ、 チームづくりの要点をストーリーで学ぼう! 【本書の特徴】 ・現場のストーリーから、考え方とプラクティスを一緒に学べる ・単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う ・日本の現場を前提にしているので、実践しやすい ・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適 【本書に登場するプラクティス】 出発のための3つの問い / 段階の設計 / ドラッカー風エクササイズB面 / 割れ窓理論 / フォーメーション・パターン / コンウェイの法則 / 越境のデザイン / 重奏型仮説検証 ほか 【あらすじ】 チームによるプロダクトづくりができる環境を求めて “太秦(うずまさ)”が転職した先は、デベロッパー向けのツールを開発、提供す

                                                                              チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで | 翔泳社
                                                                            • スキルマップを使ったチームビルディング - コネヒト開発者ブログ

                                                                              こんにちは!エンジニアの富田です。先月末に開催したスキルマップを使ったチームビルディングがとても良かったので、内容を紹介したいと思います。 なぜやろうと思ったのか 前提として私が所属しているプロダクト開発チームは以下の構成です。 PdM 1名 デザイナー 2名 エンジニア 4名 ご覧の通り職能横断型のチーム構成になっており、チームとして4ヶ月ほどプロダクト開発を進めているのですが、お互いのことをあまり知らないなと感じることがありました。もちろん自己紹介をしたり、スクラムの朝会でちょっとした小話をしているのですが、なかなか自分の得意なこと、苦手なことを開示する機会がありませんでした。 自己開示することで、自分のことを知ってもらったり、周りのことをより知ることができるので、結果としてパフォーマンスやモチベーションが向上するのではないかと考えました。何かしらチームビルディングのワークをやりたいと

                                                                                スキルマップを使ったチームビルディング - コネヒト開発者ブログ
                                                                              • 「カイゼン・ジャーニー」を読んだので、その要点 - カイゼンのためのキーワード - Qiita

                                                                                今更ながら「カイゼン・ジャーニー」を読みました。 チームビルディングの話といえば、Google話、HRT、Team Geek がこれまで印象的だった。一方「カイゼン・ジャーニー」のポイントは、 「日本の現場」に寄り添った、アジャイル開発の実践! 現場のストーリーで、開発の神髄を学ぼう という、日本のチーム、日本人ならではのメンタルに寄り添ったところだと思った。 キーワード ともかくこのカイゼンのためのキーワードを追うだけで勉強になったので、以下記載。 「ファイブフィンガー」、「5本指メソッド」 5本:とってもうまくやれている 4本:うまくやれている感触あり 3本:可もなく不可もなく 2本:不安は少しある 1本:全然ダメで絶望的 効用 良いとも報告しづらい、ダメとも報告しづらい、があるチーム。 私のチームは慎重な性格のメンバーが多く、「絶好調!!」と自分から言うことに躊躇いをもつ人が殆どでし

                                                                                  「カイゼン・ジャーニー」を読んだので、その要点 - カイゼンのためのキーワード - Qiita
                                                                                • 個人の集まりではなくチームで開発するためのマネジメント手法とは 『チーム・ジャーニー』発売

                                                                                  個人やグループではなくチームとしてプロダクトを開発することは、より大きな仕事を成功させるために不可欠です。CodeZineを運営する翔泳社では、そのためのプラクティスをストーリーに載せて解説した『チーム・ジャーニー』を2月17日(月)に発売しました。理想のチーム開発を追い求める主人公・太秦の奮闘が描かれます。 『チーム・ジャーニー』では、3度目の転職を果たしてチームリーダーに任命された主人公・太秦がチームによるプロダクト開発に乗り出す姿を追いかけながら、要所ごとにチーム開発のプラクティスを解説しています。 ストーリーパートでは開発現場の実態が生々しく描写され、当初は個人が寄り集まっているだけのグループだった状態から、太秦の奮闘によって少しずつ1つのチームになっていく様子が描かれていきます。さらに、複数のチームが担当していたプロダクトの統合が発表され、太秦はその開発リーダーに着任。大規模プロ

                                                                                    個人の集まりではなくチームで開発するためのマネジメント手法とは 『チーム・ジャーニー』発売