#チーム・組織論 186件

プロダクトの機能追加における2つのアンチパターン　「数値悪化」「関連プロダクトに対する要求漏れ」への対策

「ペルソナ別スクラムチーム」で生まれた2つの課題　開発チームの“最適な優先順位付け”を実現したLeSS導入

各社で微妙に異なる「MVPの定義」の捉え方　MoT・カウシェの「toB・toCプロダクト」が位置付けるMVP

“リリース直前ちゃぶ台返し”が減少、開発の属人化が解消…　大規模スクラム内で取り組んだ4つの改善施策と効果

マネージャーの調整力に左右されていた、開発の優先順位　大規模スクラム導入で目指す、組織・チームのありたい姿

「生産性向上は“共感ポイント”から取り組むと良い」　チーム開発の技術的観点における生産性向上の改善例

ふりかえりのマンネリ化をどうやって解消するか？　チーム間の“交換留学”で得られた新しい視点

打ち合わせで笑顔がない、フィードバックを喜べない、「なにを言ってもダメなんだろう」な雰囲気が蔓延…　チームの問題を改善させた、“少人数で話す場”からの関係性づくり

いいチームづくりのために重要な“関係の質”の改善　味方を増やすための「失敗してみる」挑戦

ふりかえりがチームの日常に“溶けた”ことで生まれた効果　仕事の中でも、雑談の中でも、当たり前に「ふりかえる」

みんなで取り組み、みんなで楽しみ、カオスも変化も歓迎する　”ふりかえり”で毎日変化を起こし続けるチームビルディング

非アジャイルな環境をアジャイルにするために　“ふりかえり”を土台にした事業づくりとチームづくり

無計画に見える計画・チーム感の欠如・とりあえずがんばる文化　 “ふりかえりエバンジェリスト”が異動先で直面した組織の課題

「外部組織による不確実性の対処は？」「バッチサイズ分割の基準は？」　アジャイル開発現場の不確実性に対してのQ＆A

サービス開発における5つの“不確実性”パターン　曖昧さをコントロールするために、ユーザーストーリーを活用する

外圧で嫌々変えるのと、自分たちで気づいて変えるのとでは決定的に違う　市谷聡啓氏・小田中育生氏が語る、“組織をアジャイルにする”ということ

何かを変える時に大切なのは、過去を否定しないこと　日本の組織の課題と、乗り越えに必要なアンラーニング

“組織アジャイル”を探求する・学び合うなら「ご近所さんを探せ」　市谷聡啓氏が語る、『組織を芯からアジャイルにする』

「何をするか」「何をやるか」以上に必要なのは「どうやるか」　“体の動かしかた”に焦点を当てた『組織を芯からアジャイルにする』

『組織を芯からアジャイルにする』執筆につながった日本組織への課題意識　「いき過ぎた“最適化への最適化”は、単なる思考停止である」

コミュニケーションのイライラ・モヤモヤは軽減できる　「通信不確実性」をカバーする3つのヒント

「ノーリアクション」「時間帯を考慮しないメンション」「そんなこと一言も言っていない」　人間関係の悪化と職務の不満足を引き起こす“通信不確実性”

「わがままを言いたい」から始めた環境作り　健全に話し合えるチーム作りに必要な“役割”と“責任”の意識

全員の思考プロセスを一致させて、アイデアを“実験”する　チームビルディングと向き合う時に意識していること

「もっとコミュニケーションがとれたら、もっと楽しく開発できるのに」　カオナビのメンバーがチームビルディングに向き合うきっかけ

チーム開発は放っておいても組織には馴染まない　「試行錯誤・仲間・根気」の大事な関係性

「アジャイルの回転の数だけ組織が変わるチャンスがある」　回転の動力を保つのに必要な、スプリントを止めない3つの作戦

チーム・組織が「効率化のための最適化を続けてしまう」問題　今までとは違う判断を下すのに必要な“エンジニアのちから”

可もなく不可もないチーム・組織は“闇落ち”する可能性がある　引き金を引く5つの感覚と、日本の組織が持つ判断基準の問題

「ドッグフーディング」「PdM的な発想」「自己組織的な働き方」　Nota開発部が大切にする3つの価値観

「大企業向けSaaSは、関わる人もカスタマイズ要望も多い」　大規模プロジェクトのPMが気をつけている“透明性”の担保

単体で動くPMの即戦力化にはナレッジ共有が必要　自律的に動ける場を作り、成功体験を積み重ねる大切さ

モチベーションの違いはリレーションシップ作りで解消する　業務委託エンジニアの“一線引いた”状況への対処法

自律性は後から育てることも可能なのか？　PM観点で語る“自律的に動かざるを得ない”評価と環境

人事がリードする日本、チームがリードするアメリカ　“現場”を想定した採用インタビュープロセスで見られること

新人教育の文化がない組織をどうリカバリーするか？　“痛み”を伴うからこそ意識したい、言語化と障壁の排除

エンジニアよりも難しいプロダクトマネージャーの採用　GoogleとSalesforceが人材獲得のために工夫していること

専門が違うメンバーでできたチームは、どう仕事を進めている？　開発体制の変化で得られたメリット・生まれた課題

エンジニア、PM、デザイナーは仲良くやれるものなのか？　“三権分立で三方良し”を叶える「プロダクトのゴール」の共有

マネージャーの成長のためにメンバーができること　オープンな関係と成長機会を作るために大切な「相互のフィードバック」

「設計からリリースまで、開発チーム全員で取りかかる」　PdM+デザイナー+エンジニア+QA+UXライターで進めるプロダクト機能改善

「強いプロダクト組織」はどんなかたちをしているのか？　GoogleとSalesforceの“組織づくり”と“チームの秘訣”

事業の多角化や育成可能なエンジニア組織を実現するために　ソウゾウとSmartHRが抱える課題と、解決のための取り組み

「よりスピーディにより良いプロダクトを作る」　チームの変遷から読み解く、SmartHRのチーム開発

ソウゾウ・SmartHRの組織図から見るチームの分けかた　取締役が語る、現在の構成がつくられたそれぞれの背景と意図

1

2

3 4 5