CNDS2024 https://event.cloudnativedays.jp/cnds2024/
![定量データと定性評価を用いた技術戦略の組織的実践 / Systematic implementation of technology strategies using quantitative data and qualitative evaluation](https://cdn-ak-scissors.b.st-hatena.com/image/square/706c7ef9c5526fdc9eb74839e712c7c80ee64a3f/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fa0b61ec07fc842b8a011693079ebfb18%2Fslide_0.jpg%3F30616266)
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか? Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか? あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス(指標)を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe
経営層の方針をチームに伝え、実行に移すミドルマネジメントの現場において、「問い」のデザインがますます重要になってきていると感じます。 本記事では、2023年10月に開催し、大変好評だったウェビナー「チームを覚醒させる「問い」のデザイン:新時代のミドルマネジメントの真髄」の内容より、「問い」を活用したミドルマネジメントの新原則について、ケーススタディとともにご紹介します。 『問いのデザイン』の大幅アップデートを目指して2020年に刊行した『問いのデザイン』の出版から4年近くが経ち、内容の改訂を検討しはじめています。特に組織の課題解決を担うミドルマネジャーに向けてコンテンツを肉付けし、アップデートに取り組んでいるところです。 きっかけは、2023年10月に開催したウェビナーでした。2023年6月にはじめて開催した一般向け大型ウェビナー「新時代の組織づくり」が非常に好評だったことを受け、その第二
言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター
はじめにクレディセゾンに来てちょうど5年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない!」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません! 2019年:ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか?」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
変化の激しい社会で成長を続けるため、新規事業の立ち上げに乗り出す企業が増えています。そんな中、タスクの進捗管理・日程調整・社内外との交渉など、多岐にわたる仕事を抱え、責任者としての重圧に悩んでいるプロジェクト担当者も多いのではないでしょうか。本記事では、DXサービスの新規事業を立ち上げた、エン・ジャパン株式会社の高橋淳也氏がゲストに登場。業務改善のためゼロからDXを勉強し、最終的にサービス化するまでに至った高橋氏が、プロジェクトマネジメントの課題を解決するヒントをお届けします。前編は、プロマネの仕事にまつわる誤解や、プロジェクトにおけるチームの重要性について語られました。 サイボウズ社員の4人に1人が受けた、人気のプロマネ勉強会 小林悠氏(以下、小林):それではみなさま、こんにちは。「なぜプロジェクトは難しいのか ーチームで旅するプロジェクトマネジメントー」という40分間のセッションを始め
はじめに 今の会社に転職してきて2ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました! 現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。 前職 スクラムを導入するまでの背景 前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き方としてはフル出社になります。 チーム構成は以下で、私はメンバーでした。 チーム構成(7名) ディレクター(PM) 1名 リーダー 1名 アーキテクト 1名 メンバー 4名 はじめからスクラムを導入していた訳ではありませんでした。 開発の流れとしては、クリニックスタッフまたは関係者からディレクター(
現状把握のために実施したこと じゃあ、これを基に実際にどういうふうに考えてどういうところをやってきたかをこれからお話しできればなと思います。 まず現状把握です。(スライドを示して)今見てもらっているのが、これまで自分が体験してきたり、ほかの企業の方との情報交換とかで出てきた、製品開発におけるよくある問題だと思ってもらえればと思います。みなさんもたぶん、これまでの経験の中で、こんな声や課題は、かなりあったんじゃないかなと思っています。 前職のECの経験でもこのあたりはありました。例えばシステムが肥大化して品質維持のためにかかる工数が多くて、「新規機能開発になかなか時間がかかりますよ」となったり、事業部とかから要望、HOWの指定がけっこう多くて、顧客の課題がぼんやりしていたり。 あとは、ビジネス側からすると、思ったとおりのタイミングでリリースできないことがあるとか、もっと多くの要望を実現したい
はじめに約1年ぶりのエントリーになります。今回はマネージャーの評価基準というタイトルで書きたいと思います。 マネージャーを評価する基準というのはありそうでないなと、この1年色々な経営者・マネージャーの方と話す中で感じていました。 その時残すべき成果が出ていればマネージャーとしてOKとしている会社もあれば、「マネージャーとしての行動リスト」のようなものが5個〜多くて30個程度であり、その行動リストを評価とまではいかなくとも、チェックリストのように使っている会社もあります。 しかし、前者の場合は「成果が出ていれば色々な犠牲が出てもよし」となりますし、後者の場合は「行動リストのうち今必要が無いことも行動せよ」となるので、両方ともマネージャーを評価する基準としては何か違うなと違和感を覚えてました。 しかし、何を以て良いマネージャーなのか、それを判断する基準がなければ、マネージャーに何を求めて良いか
ありがたいことに年末にメルカリの小泉さんとランチをご一緒させてもらいました。 CTO(@yutadayo)が作成した過去の失敗スライドに、リプライをいただいのがきっかけだったのですが、長らく競合事業(現ラクマ)をやっていたこともあり、きちんとお話ししたことがなく、とても学びが深かったので、ご本人に許可をいただいて、メモした内容と学びをシェアさせていただきます。 なんでメルカリに?噂ではフリルにも入社してもらえる可能性もあったとか?2007年よりミクシィに入社し、2012年の退任までCFOを務めていた その後、1年以上は他の会社の社外取締役をしたりフリーランスをしていた フリルは2012年夏リリース、メルカリは2013年春リリース 小泉さんは2013年冬にメルカリ入社 フリルのことは入社前から知っていて、2012年冬のIVSでコミュニティファクトリーの松本さんに「フリル知ってる?紹介してよ」
味の素が打ち出した「適所適財」の考え方 髙倉千春氏(以下、髙倉):じゃあ(日本企業が成功するために)何をやればいいか。今、企業側が考えているのは「将来の未来戦略は大きく変わるよね」という資料の左上のところです。 経営理念と合わせて将来戦略を考えなきゃいけない。「優秀層はどういう人なんだっけ」と考えると、その将来の職務要件や人材要件が大きく変わるでしょうと。 もう1つ大事なのは個の尊重。「うちにはどんな人がいるんだっけ」「どういう思いで何を大切にしてるんだっけ」という可視化が必要です。今HRテックの必要性がすごく言われていて、可視化のツールがあらためて重要になっている。 会社のニーズというか、将来戦略と人材ポートフォリオ、事業ポートフォリオの合体なんですけど「こんな人がいるから、こういうポジションを作ろう」というのが、日本企業の今までのセオリーだったんです。 でも私たち味の素は、「適材適所」
2023年12月は、『TBS NEWS DIG』や『PIVOT』なので動画が立て続けに出るのですが、動画だけでは話しきれなかった部分があるので、今年1年間で考えてきたテーマについて、本記事で書いていきます。 問いとしては、下記の5つを網羅したものとなります。 ① なぜ働かない社員が生まれるのか?(静かな退職/逃げ切り社員問題) ②「多様性」を推進しても、逆に亀裂が生じるのはなぜか?(フォールトライン問題) ③ メガベンチャーやブランド化した企業はなぜ衰退するのか?(◯◯Wayの絶対視) ④ 自社愛が強い人ほど、企業を滅ぼしてしまうのはなぜか?(盲目的自社愛) ⑤ メディアで持て囃されている企業から衰退していくのはなぜか?(メディアトラップ) そして、結論というか総括として、下記の画像に集約される現象が発生し、組織が硬直化していくという話をします。 8000文字くらいあるので、10分くらいは
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事:『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
循環する学び~現場とコミュニティの境目で考える~/Learning Cycle between a team and a community
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか? いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く