プロダクト開発組織のチームビジョンを作ったらすごいパワーが生まれた話 - Uzabase for Engineers
こんにちは。NewsPicks プロダクトチームの文字です。今日はプロダクト開発組織のチームビジョンを作ったら、すごいパワーが生まれた話をさせて頂きます。 「経済を、技術でもっとおもしろく。」 今年の春、NewsPicks のプロダクトチームでは、こんなチームビジョンを作りました。実は NewsPicks のタグラインは「経済を、もっとおもしろく。」なので、会社の掲げるタグラインをほぼ踏襲しているように見えます。しかし一見凡庸なこのビジョンが、実はとても大きなパワーを秘めていたのです。 1/ なぜビジョンをつくったのか 増大し続ける技術的負債と運用負荷 組織の急拡大 2/ みんなでビジョンをつくる 合宿の開催 腹落ちできるビジョンが完成 3/ ビジョンをつくったら、どうなったのか？ ビジョンはパワー 4/ これからのプロダクトチーム 1/ なぜビジョンをつくったのか そもそも、何故こんなチ
「攻撃的な人が1人入っただけで、チームの生産性は30〜40パーセント低下する」の体験談。仕事はできるが「なんで〇〇なんですか😡」と過干渉な人がいて生産性が下がった話。
みる兄さん⚽️元マーケの人 @milnii_san 「攻撃的な人が1人入っただけで、チームの生産性は30〜40パーセント低下する」って話。これ前に見聞きしたことがある。仕事はできるが周りに対して過度に求めて「なんで〇〇なんですか😡」って人がいた。これでチームの生産性が著しく低下した。チームで仕事をするときに「他人への干渉性」って大事よ 2021-12-20 23:01:46 みる兄さん⚽️元マーケの人 @milnii_san 他人への過干渉性の原因として、「バウンダリー・オーバー」（自他境界）が挙げられられます。判別方法は、 ①会話をしてるときに最後まで話を聞かずにかぶせ気味で自論を展開する。 ②トラブルがあったときに事象ではなく責任の所在（人）を探す。 ③人の「好き」を尊重できない。 ここらへんかな。 2021-12-20 23:08:26 リンク ログミーBiz “難しい人”が1人入
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
人類はWeb会議に向いていないので、もっとMiroを活用すべき - Cloud Penguins
Miro大好きjacopenです。エンタープライズなIT界隈ではおそらく日本でトップクラスにMiroを愛している自信がある。 さて今日はMiro Advent Calendar 2021の3日目。 今日は、人類がいかにWeb会議に不向きかという話と、そのギャップをMiroで埋めようという話。あとは自分が関わっているカンファレンスでMiroを使いまくっている話をする。 Web会議の8割はXX コロナ禍でだいぶ定着したWeb会議。でも、個人的には世の中のWeb会議の8割は上手くいっていないと思っている。数字に根拠はないけど。 何を持って上手くいっていないとするかだが、「対面の会議と比較して伝えられる度合いが低下している」とすると、8割くらいはそれに該当すると言っても過言ではないだろう。 何故そうなるかというと、基本的に人は言葉だけで物事を正確に伝えることはできないからだ。 人間の会話において、
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
なぜ組織の透明性が大切なのか - 30歳からのプログラミング
個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし
良い質問をして自己成長に繋げるためのあれこれ - Qiita
質問に関することで悩む若手エンジニアは多い 「ちゃんと調べてから質問した？」 「今日の進捗は？ない？ずっと同じ場所で悩んでいたの？？」 「わからないところあったらすぐ質問してね？」 「すみません。どうして欲しいのかわからないです」 他にもいろいろあると思いますが、 上記の様なことを言われているうちに質問することへの心理的障壁が上がってしまい、 質問する行為自体が悩みの種になってしまうことも多いです。 自身のキャリアのキャリア初期に「こうするとうまくいった」・「こうしておけばよかった」 また、エンジニアキャリアをスタートしたばかりの人をサポートする様になって「こうすればうまくいくんじゃない？」と アドバイスする機会もあったので、今回は質問という話題に絞って、残しておきたい。 カテゴリ分けするともっと見やすくなるかもしれないが、思いついたエピソードや事柄を羅列する形にしたいと思います。 稚拙な
「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
重要なのは経営層の視点と現場の課題をつなぐこと 技術的負債の返済に向けた現場の説明責任
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。続いては、組織における技術的負債の返済のための現場と意思決定層のアクションについて。前回の記事はこちらから。 技術的負債の現場視点のアクション 原トリ氏（以下、原）：では、ここからは技術的負債の返済inアクションという感じで、まずは現場視点での返済の進め方について、ちょっと見ていきましょう。現場視点の整理が済んだら、次は意思決定層の視点です。 まず一般的に、技術的負債の返済の提案や実行は、現場の立場から行われることが多いです。いわゆるボトムアップと呼ばれるものです。日々開発をして、運用している人たちです。理由は明確で、その技術的負債によって生産性低下の悪影響を直接的にモロに受ける立
リモートアジャイル開発のノウハウ集 第2版を公開しました | Agile Studio
Agile Studio プロデューサーの木下です。2020年の3月に公開した『リモートアジャイル開発のノウハウ集（第1版）』に続き、このたび第2版を公開しました。こちらからダウンロードいただけます。...
マイクロマネジメントは悪か？よりよい組織をつくるためのマネジメント形態についての考察 - クックパッド開発者ブログ
レシピ事業サービス基盤部で部長をやっています、新井(@SpicyCoffee66)です。引越しを機に MtG のカードをほとんど売ったはずなのに、そのときは存在しなかったポケモンカードのデッキが手元にあります。なぜ？ 私は 2017 卒のエンジニアとしてクックパッドに入社し、様々な業務を経験した後に 2020 年の 8 月から部長となりました*1。最近はコードを書いていないので Techlife の執筆内容に迷ったのですが、今自分の中にある「優れた組織づくりについての考え方」をまとめてみることとしました。部長になる前にも、グループ長として小規模なチームマネジメントの経験があるとはいえ、それを含めても２年弱のマネージャー経験しか持っていないので、これが絶対の正解というわけではなく一つの考えとして読んでいただけると幸いです。 組織の存在理由 優れた組織づくりについて考えるために、まずは組織の存
コロナ禍における人事の課題認識｜コラム | 人材育成・研修のリクルートマネジメントソリューションズ
新型コロナウイルス感染症への対策が優先される社会情勢（以下、コロナ禍）は、企業活動にもさまざまな制約や変化を促した。事業活動における対応が求められたのはもちろんだが、人事領域においても、出社の抑制をはじめとする予期せぬ働き方の変化により、さまざまな対応の必要性が生じた。2020年度は、人事の諸活動を止めないための急場の対応に追われた経営や人事も多かったのではないだろうか。 しかし、コロナ禍に対応しながらの2度目の年度、経営や人事の視点は、より中長期を見据えた人事基盤の再構築に向けられていることだろう。そこで当社では、人事の課題認識およびその変化、それらを踏まえた「人事の役割」の認識に関する実態調査を2021年2月に実施した。 本稿は調査レポート前編として、コロナ禍における人事の課題認識とその変化について報告する。 コロナ禍では、生活におけるこれまでの前提が大きく覆った。その結果、組織・人材
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
DXコンサルが絶対に言わない後ろめたい真実｜naoto
【お知らせ】200名以上の有名企業のCxO / 責任者クラスのトッププレイヤーを、月額定額でアサインできる「SHARE BOSS （シェアボス）」というサービスを運営しています。DXや事業開発に関するお困りごとや、お悩みがございましたら、まずはお気軽にお問い合わせください。 https://shareboss.net/about/ 2019年くらいから、デジタルトランスフォーメーション (DX) の相談を受けるようになって、今はアドバイザーみたいなのを含めて10社くらいお手伝いしています。 また、講演なんかも依頼されてたりして、そこではストルターマン教授がどうだ、とか、トレンドはー、みたいなことをしたり顔で言っていたりするわけなんですが・・・。内心では、定義とか事例の話から入るのはあんまり本質的じゃないのかな、と感じています。 足元の現場を見ると、DXDXディーエックスディーエックスいって
クラスメソッドが抱えていた組織の悩みを解決したProflly | DevelopersIO
2014年から10倍に拡大したクラスメソッド。私達は急成長する中でいくつもの悩みや課題を抱えてきました。本記事では私達が抱えていた組織の悩みをお伝えし、またその解決策として私達が開発しているProfllyというサービスをご紹介します。 はじめに 私がクラスメソッドに入社したのは2014年1月。当時は社員数も50人程度で、オフィスは東京にしか無く、和気あいあいと仕事していました。しかしその後組織は急成長。2017年末には100人、2019年頭には200人と急増しました。現在では日本本社だけで350人、グループ全体で500人弱と、2014年から比べて10倍に成長しています。 多くの企業が経験することだと思いますが、クラスメソッドも急成長する中でいくつもの悩みや課題を抱えてきました。本記事では私達が抱えていた組織の悩みをお伝えし、またその解決策として私達が開発しているProfllyというサービス
技術的なお問い合わせに関するガイドライン | AWS サポート
AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。 なお、サポート全般についての一般的な情報は、AWS サポートをご参照ください。 サポートレベル毎の技術サポートへのアクセスについては、AWS サポートのプラン比較をご参照ください。 基本情報の入力について サービス／カテゴリー お問い合わせ内容に最も近い項目をご選択いただくことで、適切な回答が早期に得られる可能性が高まります。 お問い合わせ言語 日本語を選択します。英語での技術支援をご希望の場合には English を選択します。 連絡方法 多くの場合、Web を推奨します。連絡方法の詳細については、連絡方法（Web、電話、Chat）の選択についてを
創業した会社がLINEに買収され、無事PMIも終えたところで退職します｜daimatz
FIVE というスタートアップを共同創業したのが2014年10月、そしてそれが LINE に買収されたのが2017年12月。企業買収後の統合（PMI）にも一区切りがつき、2021年1月末を最終出社として LINE 社を退職することになったので、退職エントリを書いてみようと思います。 これまでろくにインターネット上に記事を書いてこなかったため、自己紹介も兼ねています。 で、お前誰松本大介といいます。各種 SNS アカウントは daimatz という ID でやっています。 Twitter: https://twitter.com/daimatz Facebook: https://facebook.com/daimatz GitHub: https://github.com/daimatz 軽く経歴を書いておくと、東京工業大学でコンピュータサイエンスを学び（工学部情報工学科・大学院情報理工学
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
爆速で価値あるプロダクトをリリースするためのチームビルディング
一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく
チームの機能不全を起こす4つの “毒”を発生させないための感情の保ち方、心理的安全性を確保したチーム作りのために考えるべきこと【CEDEC2021】 | GameBusiness.jp
