会員登録
/
ログイン
ログミーTechとは
広告掲載のご案内
会員登録
ログイン
技術・運用
チーム・組織論
キャリア・採用
UI/UX
企画・アイデア
ログミーTechとは?
広告掲載のご案内
技術・運用
チーム・組織論
キャリア・採用
UI/UX
企画・アイデア
#チーム・組織論
184件
各社で微妙に異なる「MVPの定義」の捉え方 MoT・カウシェの「toB・toCプロダクト」が位置付けるMVP
カウシェ
“リリース直前ちゃぶ台返し”が減少、開発の属人化が解消… 大規模スクラム内で取り組んだ4つの改善施策と効果
Retty
マネージャーの調整力に左右されていた、開発の優先順位 大規模スクラム導入で目指す、組織・チームのありたい姿
Retty
「生産性向上は“共感ポイント”から取り組むと良い」 チーム開発の技術的観点における生産性向上の改善例
株式会社ウーオ(UUUO, Inc.)
ふりかえりのマンネリ化をどうやって解消するか? チーム間の“交換留学”で得られた新しい視点
XPJUG
打ち合わせで笑顔がない、フィードバックを喜べない、「なにを言ってもダメなんだろう」な雰囲気が蔓延… チームの問題を改善させた、“少人数で話す場”からの関係性づくり
XPJUG
いいチームづくりのために重要な“関係の質”の改善 味方を増やすための「失敗してみる」挑戦
XPJUG
ふりかえりがチームの日常に“溶けた”ことで生まれた効果 仕事の中でも、雑談の中でも、当たり前に「ふりかえる」
Scrum Fest Sendai
みんなで取り組み、みんなで楽しみ、カオスも変化も歓迎する ”ふりかえり”で毎日変化を起こし続けるチームビルディング
Scrum Fest Sendai
非アジャイルな環境をアジャイルにするために “ふりかえり”を土台にした事業づくりとチームづくり
Scrum Fest Sendai
無計画に見える計画・チーム感の欠如・とりあえずがんばる文化 “ふりかえりエバンジェリスト”が異動先で直面した組織の課題
Scrum Fest Sendai
「外部組織による不確実性の対処は?」「バッチサイズ分割の基準は?」 アジャイル開発現場の不確実性に対してのQ&A
DMM.com
サービス開発における5つの“不確実性”パターン 曖昧さをコントロールするために、ユーザーストーリーを活用する
DMM.com
外圧で嫌々変えるのと、自分たちで気づいて変えるのとでは決定的に違う 市谷聡啓氏・小田中育生氏が語る、“組織をアジャイルにする”ということ
DevLOVE
何かを変える時に大切なのは、過去を否定しないこと 日本の組織の課題と、乗り越えに必要なアンラーニング
DevLOVE
“組織アジャイル”を探求する・学び合うなら「ご近所さんを探せ」 市谷聡啓氏が語る、『組織を芯からアジャイルにする』
DevLOVE
「何をするか」「何をやるか」以上に必要なのは「どうやるか」 “体の動かしかた”に焦点を当てた『組織を芯からアジャイルにする』
DevLOVE
『組織を芯からアジャイルにする』執筆につながった日本組織への課題意識 「いき過ぎた“最適化への最適化”は、単なる思考停止である」
DevLOVE
コミュニケーションのイライラ・モヤモヤは軽減できる 「通信不確実性」をカバーする3つのヒント
DMM.com
「ノーリアクション」「時間帯を考慮しないメンション」「そんなこと一言も言っていない」 人間関係の悪化と職務の不満足を引き起こす“通信不確実性”
DMM.com
「わがままを言いたい」から始めた環境作り 健全に話し合えるチーム作りに必要な“役割”と“責任”の意識
カオナビ
全員の思考プロセスを一致させて、アイデアを“実験”する チームビルディングと向き合う時に意識していること
カオナビ
「もっとコミュニケーションがとれたら、もっと楽しく開発できるのに」 カオナビのメンバーがチームビルディングに向き合うきっかけ
カオナビ
チーム開発は放っておいても組織には馴染まない 「試行錯誤・仲間・根気」の大事な関係性
カオナビ
「アジャイルの回転の数だけ組織が変わるチャンスがある」 回転の動力を保つのに必要な、スプリントを止めない3つの作戦
Qiita株式会社
チーム・組織が「効率化のための最適化を続けてしまう」問題 今までとは違う判断を下すのに必要な“エンジニアのちから”
Qiita株式会社
可もなく不可もないチーム・組織は“闇落ち”する可能性がある 引き金を引く5つの感覚と、日本の組織が持つ判断基準の問題
Qiita株式会社
「ドッグフーディング」「PdM的な発想」「自己組織的な働き方」 Nota開発部が大切にする3つの価値観
Nota株式会社
「大企業向けSaaSは、関わる人もカスタマイズ要望も多い」 大規模プロジェクトのPMが気をつけている“透明性”の担保
開発PM勉強会
単体で動くPMの即戦力化にはナレッジ共有が必要 自律的に動ける場を作り、成功体験を積み重ねる大切さ
クライス汐留アカデミー
モチベーションの違いはリレーションシップ作りで解消する 業務委託エンジニアの“一線引いた”状況への対処法
クライス汐留アカデミー
自律性は後から育てることも可能なのか? PM観点で語る“自律的に動かざるを得ない”評価と環境
クライス汐留アカデミー
人事がリードする日本、チームがリードするアメリカ “現場”を想定した採用インタビュープロセスで見られること
クライス汐留アカデミー
新人教育の文化がない組織をどうリカバリーするか? “痛み”を伴うからこそ意識したい、言語化と障壁の排除
エンジニアtype
エンジニアよりも難しいプロダクトマネージャーの採用 GoogleとSalesforceが人材獲得のために工夫していること
クライス汐留アカデミー
専門が違うメンバーでできたチームは、どう仕事を進めている? 開発体制の変化で得られたメリット・生まれた課題
株式会社SmartHR
エンジニア、PM、デザイナーは仲良くやれるものなのか? “三権分立で三方良し”を叶える「プロダクトのゴール」の共有
クライス汐留アカデミー
マネージャーの成長のためにメンバーができること オープンな関係と成長機会を作るために大切な「相互のフィードバック」
エンジニアtype
「設計からリリースまで、開発チーム全員で取りかかる」 PdM+デザイナー+エンジニア+QA+UXライターで進めるプロダクト機能改善
株式会社SmartHR
「強いプロダクト組織」はどんなかたちをしているのか? GoogleとSalesforceの“組織づくり”と“チームの秘訣”
クライス汐留アカデミー
事業の多角化や育成可能なエンジニア組織を実現するために ソウゾウとSmartHRが抱える課題と、解決のための取り組み
エンジニアtype
「よりスピーディにより良いプロダクトを作る」 チームの変遷から読み解く、SmartHRのチーム開発
株式会社SmartHR
ソウゾウ・SmartHRの組織図から見るチームの分けかた 取締役が語る、現在の構成がつくられたそれぞれの背景と意図
エンジニアtype
「カルチャーはバリューで伝える」「ロールモデルを作る」 スタートアップ2社が取り組んだ、成長と自立を促す施策
エンジニアtype
エンジニアの“自立”には2種類ある ソウゾウとSmartHRの取締役が語る、成長と育成
エンジニアtype
1
2
3
4
5