何らかの問題を解決しなくてはならなくなった時に、解決よりも深掘りを優先してしまう特性の人がいます。 たとえば問題に対する短期的な対策を考えることをおろそかにして、根本原因究明と根本対策方法をじっくり考え込んでしまうような人が該当します。他人事のように言ってますが、筆者もそうです。本記事は、そういう筆者が過去に仕事で困っていたこと、ある時から状況によって取り組み方を変えられるようになったという話をします。 上記のような特性の人は、調査のたびに深い知識が得られ、血肉となっていきます。それゆえ技術に明るい人とみなされることもあります。その一方で、困ることもあります。とくにそれは発生した問題が自分ではなく他の誰かのものだった場合、かつ、急ぎ問題解決が必要な場合です。業務ではこのような場面が非常に多いです。 この場合、問題の深掘りを最優先にしてしまうと仕事が遅くなりがちです。みなさんも、「あの人、技
はじめに Cloud Platform部のpddgです。2024年もサマーインターンシップを開催し、プラットフォーム(自社基盤)コースとして2名の方を受け入れました。 昨年の様子は以下からご覧いただけます。興味があれば是非ご覧下さい。 blog.cybozu.io 今回は受け入れたお二方のうち藤本陽人さん(static-fuji)に担当していただいた検証の中で発見したやや直感的でない挙動について、藤本さんによる検証結果を社員がまとめたものになります。 この記事内での検証のほとんどはインターン生である藤本さんによって実施されたものですが、一部社員がインターンシップ完了後にこの記事の執筆のために生成した図等も含まれます。 また、もう一人のインターン生の方にはRustでロードバランサを書くという課題に挑戦していただきました。こちらもインターン生の方に大活躍していただいています。是非ご覧下さい。
コーヒー好きのPM @coffee_nomimasu SIerでSE10年+PM10年 【ポスト】プロマネやシステム開発の経験談、本の紹介、趣味の話 【趣味】マンガ、ゲーム、ランニング、バスケ、落語 【好き】BUMP OF CHICKEN、カフェ、アイスコーヒー、デザート 【資格】情報処理(FE/AP/DB/NW/SC/PM)、PMP(失効)、AWS5冠 note.com/pgsepm コーヒー好きのPM @coffee_nomimasu 他社に転職していった同僚から聞いたのですが「このExcelにタスクの進捗いれてください、とメンバーに伝えても半分は進捗いれてくれないしExcelみもしない人さえいる」とのこと。メンバーが自主的に進捗入力したり遅延する前に教えてくれるのはすごいことらしい。
マン・カインド 作者:藤井 太洋早川書房Amazonこの『マン・カインド』は、至近未来ー近未来を主な舞台に選び、現実の社会情勢や技術の延長線上で様々な短篇・長篇を発表してきた作家、藤井太洋の最新長篇だ。最新とはいっても本作はSFマガジンで2017年〜21年まで連載しており、翌年の星雲賞(日本のSF賞で、SF大会の参加者の投票で決定される)の長篇部門を受賞している。 つまり連載当時から高い評価を受けていたわけだが、なぜ単行本化が今日まで伸びたのか? といえば理由は僕も何も知らないが、単純に忙しかったのか、もしくは連載版に比べて大幅に加筆修正をしたそうなので、「より完璧な」形を目指すのに時間がかかったのだろう。そんなこんなで期間があいたこともあって、連載版で読んではいるものの初読のような気持ちで読み始めたのだが、いやーこれがおもしろかった! 本作の舞台は2040年代の未来。この世界ではAIドロ
https://jp.quora.com/コールセンターで勤務しているのですが-怒鳴られる これ読んでコールセンターはやっぱり辛いって改めて思ったけど、怒られてる原因作ってるのは必ずしもコールセンターの担当者じゃないってことが唯一の救いだと思った。 だけど俺は本社と系列店舗向けの業務システムを一人で構築運用してコールセンターも兼務している。 なにか問題があって怒られるとコルセンター兼開発者の俺が原因ということになるので逃げ場がない。真正面から謝り続けている。そのうえで不具合の原因調査と説明、バグ改修、テスト、本番環境へのリリースまで一人で行っている。 よくあるのが、足りない機能があるから早く用意しろと散々叩かれて、俺がやっとのことで開発して運用にこぎつけて不具合がなくても、結局何も言われない。問題があるときだけ俺が怒られる。面白いくらいにワンパターン。 俺の構築したシステムは運用を開始して
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ(僕らは単にログファイルに吐いておい
抑うつリアリズム理論(英:Depressive realism)とは、抑うつ状態にある個人が非抑うつ状態の個人よりも現実的な推論を行うとする仮説であり、ローレン・アローイ(英語版)とリン・イボンヌ・エイブラムソン(英語版)によって提唱された[1]。 抑うつ状態の個人は、反復的で否定的かつ自動的な思考、不適応な行動、そして機能不全な世界観といった、否定的認知バイアスを持つと考えられているが[2][3][4]、抑うつリアリズム理論は、これらの否定的思考こそが世界をより正確に評価したものであり、抑うつでない個人の評価は肯定的思考に偏っているのだと主張している[5]。現在、いくつかの証拠は抑うつリアリズム理論の妥当性を擁護するが、同時に理論の妥当性を疑問視する証拠も存在している[6]。 参加者がボタンを押したときに、ライトが点灯したかどうかについて、彼らがコントロールを持っているかどうか感じたかを
TOPインタビューロードマップは決めきるべきじゃない。「売れない」から脱出するために、PdMがやるべきこと【エムスリー山崎聡】 エムスリー株式会社取締役CTO/VPoP エムスリーテクノロジーズ株式会社代表取締役 山崎聡 大学院博士過程中退後、ベンチャー企業、フリーランスを経て、2006年、臨床研究を手がけるメビックスに入社。2009年、メビックスのエムスリーグループ入り以降、エムスリーグループ内で主にプロダクトマネジメントを担当する。2017年からVPoE。2018年からエムスリー執行役員。2020年からはエンジニアリンググループに加えて、マルチデバイスプラットフォームグループとデザイングループも統括。2020年より初代CDOに就任。2022年よりCTO兼VPoP。2023年より取締役。2024年よりエムスリーテクノロジーズ株式会社代表取締役。 X Speakerdeck 人はつい「楽な
はじめに 概要 移行したメール基盤について AWS移行における制約事項 設計 機能要件の整理 移行過渡期の構成 移行後の構成 AWS移行前の準備 AWS上でのプロビジョニング OSレイヤでのプロビジョニング AWS移行中の課題 細かな設定値の調整とスケジュール AWS移行中に発生したトラブルの数々 AWS移行完了後の振り返り 普段からやっておいたほうが良いこと できればやっておいたほうが良いこと はじめに リブセンス インフラエンジニアのsheep_san_whiteです。お酒とロードバイクとランニングが好きなおじさんです。 リブセンスではオンプレミス環境からAWS環境への移行を進めてきました。移行対象がたくさんあったAWS移行が終わり、つい先日データセンタの解約も完了しました。今回は3年がかりの長期プロジェクトであったメール基盤の移行について振り返っていきます。 概要 移行したメール基盤
茨城大学と京都大学(京大)は9月12日、分子動力学計算による数値シミュレーションを用いて、気体と液体が共存する状態で重力に拮抗する弱い熱流をかけると、沈んでいた液体が気体の上に浮き上がり浮遊し続けることを発見したと共同で発表した。 同成果は、茨城大大学院 理工学研究科の吉田旭大学院生(現・京大 特定研究員)、同・大学 理学部の中川尚子教授、京大 理学研究科 物理学・宇宙物理学専攻物性基礎論講座の佐々真一教授らの共同研究チームによるもの。詳細は、米国物理学会が刊行する機関学術誌「Physical Review Letters」に掲載された。 地上では、水を沸騰させて100℃に達した場合、重力の働きがあるため、質量密度の重い沸騰した水(お湯)が下で、質量密度の軽い水蒸気は上に位置する。しかし、これが条件によっては変化し、無重力(微小重力)環境下で、なおかつ容器内に温度差があり熱流が流れていれば
これは私が普段いかに労働から逃げているかを示すものです。 前提となる考え方私は働きたくない。実際には仕事にやりがいを見出すこともあるので必ずしも働きたくないわけではないが、基本的には常に働きたくないと言っている。 ことプロダクト開発になるとこの傾向は顕著で、「何も作りたくない」「何も作らずにお金を稼ぎたい」などとよく言っている。プロダクトは作った瞬間に負債になる。世の中は絶えず変化・進化していくので、作った瞬間から陳腐化が始まる。それを防ぐために継続的なメンテナンスや改善が求められる。 通常、その負債が問題視されないのは、そのプロダクトが負債以上に大きな果実つまり価値をもたらすからである。アジャイルの名のもとに incremental delivery などと言うと聞こえはいいが、要するに負債より多くの価値を生み出すための自転車操業をかっこよく言っただけである。少しトゲのある表現になったが
YOSHIDA Hiroshi 吉田寛「NHK 世界サブカルチャー史 ゲーム編」放送中 @H_YOSHIDA_1973 先日のNHK番組でアメリカ人のゲーム研究者が「『ストリートファイター』のケンとリュウのライバル関係には、当時の日米の対立構造が表象されていたのです(プレイヤーはそう経験したのです)」と「解説」して、当時リアルタイムで遊んだ日本人が「そんなことない」と反発した問題はけっこう深刻です。 2024-09-12 15:29:45 YOSHIDA Hiroshi 吉田寛「NHK 世界サブカルチャー史 ゲーム編」放送中 @H_YOSHIDA_1973 私も(当時『ストリートファイター2』をプレイしていた日本人として)「そんなことない」と思うのですが、「客観的(歴史的、経済的、政治的)」には、そういう解説・解釈が整合的・合理的なものとして成立しえますし、反論する側にもそれを覆す(主観的
うれしかった。ので、メモ。 僕のいるチームのプロジェクトで、複数のチームにサポートしてもらいながら進める必要がある、ちょっと大きなものが始まりそうだったから、キックオフ前のキックオフやっとこかーってなって司会をした。オンラインミーティングね。 最初にこの会の目的を説明 今日のアジェンダのページのリンクは事前に共有もしていましたけど、いまSlackにもポストしておきましたー。 まだプロジェクトは始まってないんだけど、事前に調査とかをしたいから質問や相談をさせてもらいたいなと思っていて、そのときに「え?これなんの話?」って戸惑わせることがないように、プロジェクトの概要を共有しとこうと思ったー!だから、この会がうまくいったら、僕らが質問してもみなさんが戸惑わないようになっている! Bさん、Slackにメモ残してってください。お願いしまーす! からの、会の流れを説明 最初にPdMから10分くらいで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く