めちゃめちゃ使いこなす観察、理解、知識、解像度! そしてコンテキスト!!/observation-understand-knowledge-resolution-context
https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15981 私たちは観察、理解、知識を用いて仕事をこなしています。 これらは「心の働き」といえるものです。 仕事の成果の質を左右する重要な活動で、 子供の頃から慣れ親しんだ活動です。 では、心を働かせるとはどのような活動なのでしょう。 私はほとんど答えることができませんでした。 このセッションでは何気なくしてきた観察、知識、理解を 明らかにし、その質を高め方を紹介します。 プロフィール https://note.com/mryy/n/n6f01561a6253 関連動画 シン・仮説検証 70000枚の付箋で分かった仮説検証のエッセンス https://speakerdeck.com/moriyuya/shin-hypothesis-testing 仕組みと働
一休の現在と、ここまでの道のり
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
重大事故の時にどうするか？｜miyasaka
ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して
Introducing GitHub Package Registry
ProductIntroducing GitHub Package RegistryWith GitHub Package Registry your packages are at home with their code—sign up for the limited beta to try it out. Today, we’re excited to introduce GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code. GitHub Package Registry is fully integrated with GitHub, so you can use
チームの症状と処方の考察｜Megumi Kaneko
はじめに自己紹介を少しさせてください。 私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。 その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。 チームの健康状態とはチームの状態を表す指標として心理的安全性はよく聞きますよね。 広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。 「問題点の指摘」や「自分の弱
研修中に爆睡して学んだ 1on1 で「待つ」ことの大事さ(How I learned the importance of patience in one-on-one MTGs from sleeping) - masartz->log(type=>'hatenablog')
(English follows) 前置き この記事は Engineering Manager vol.2 Advent Calendar 2018 6日目の記事です。 メルカリで Engineering Manager をしている masartzです。 今日は、先日自身が体験したことから得た、1on1の学びについて書いてみようと思います。 1on1コーチングの研修 メルカリでは、急拡大する組織に対応するため、Managerなどの中間層の教育・育成も急務となっております。Managerとしては、HR部門のサポートもあり研修プログラム等も受講する機会が与えられます。 先日 「1on1コーチング」のための時間があり、外部のプロコーチの方を相手に「コーチングを受ける側」の立場から勉強しようという機会でした。 当日、会議室に着き、挨拶と自己紹介を済ませ、いよいよ本題です。 コーチ:「最近の課題はあ
Teslaでは社員の推薦がない契約社員は月曜から出社禁止だそうです
Teslaでは社員の推薦がない契約社員は月曜から出社禁止だそうです2018.05.08 12:0069,443 satomi ｢フジツボ落としの時がきた｣ Tesla（テスラ）のイーロン・マスクCEOが下請けと孫請けの契約社員を全部まとめてフジツボと呼んで出社を禁じ、｢正社員から推薦のある者だけ入ってよし｣とするお触れをくだしました。 Electreckが先月入手した全社メールでCEOは、5月7日の朝から社外ワーカーが工場で一斉に締め出されると警告。入場を許されるのは、優秀な人材であることをテスラ社員に連帯保証してもらった契約社員だけだと言っていますよ。 契約企業およびコンサルタントに関し、下記の通告を確認ください。業績評価の期限を延長して貢献度表明の機会を与えてきましたが、その期限も終了です。 社屋や社内システムへのアクセス権限を持つ非正規雇用者は（下請け企業単位ではなく）個人単位で、当
Fearless Changeの48のパターンのチートシートを作りました。 - kawaguti’s diary
Fearless Change のパターンリストを A4 x 2枚 のシートにしました！ PDFファイルはこちらです。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者:Mary Lynn Manns,Linda Rising出版社/メーカー: 丸善出版発売日: 2014/01/30メディア: 単行本（ソフトカバー）Fearless Change: Patterns for Introducing New Ideas (English Edition) 作者:Linda, Ph.D. Rising,Mary Lynn, Ph.D. Manns出版社/メーカー: Addison-Wesley Professional発売日: 2004/10/04メディア: Kindle版
Cloud design patterns - Azure Architecture Center
These design patterns are useful for building reliable, scalable, secure applications in the cloud. Each pattern describes the problem that the pattern addresses, considerations for applying the pattern, and an example based on Microsoft Azure. Most patterns include code samples or snippets that show how to implement the pattern on Azure. However, most patterns are relevant to any distributed syst
ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
仕事の生産性と質を高めるために「完了バイアス」を利用せよ | ビジネススキル｜DIAMOND ハーバード・ビジネス・レビュー
人の脳は、目の前の仕事を完了することで生じるドーパミンを欲する。本記事では、この「完了バイアス」による悪影響を避け、仕事の向上につなげる方法を紹介する。 「私は2種類の問題を抱えている。至急のものと重要なものだ。至急のものは重要ではなく、重要なものは決して至急ではない」 ――ドワイト・D・アイゼンハワー これはアイゼンハワー大統領に限った話ではない。人は仕事をするうえで、早急な対応を要するタスクと重要なタスクとの間で常に揺れている。後者は、長期的な目標の達成に近づくためのものだ。 しかし残念と言うべきか、我々や他の人々の研究によれば、人間には後者を犠牲にして前者（重要でないメールへの返信など）に過度に集中するという、生来の傾向があることがわかっている。 その主な一因は、人間の脳は何かを完了すること、およびそれがもたらす喜びを求めるようにできているからだ。我々はこの傾向を「完了バイアス（co
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームをデバッグするには: QCon London Q&A
1on1を上達するために
心理的安全性の育て方.pdf - Speaker Deck
improving technical organization by many ways
Why WebRTC is the next phase of real-time communications - TelecomLead
Why WebRTC is Critical to Your Communications Strategy