タグ

2024年2月22日のブックマーク (5件)

  • いちいち全てを報告してくる部下をどう管理するか悩んでいる

    ある新入社員が入ってきた。 俺がある程度面倒をみるんだけど、この子で個人的に気に入ったのはきちんと報告を行う子だったということだ。 最初は「報告きちんとしてくれるから安心だな~」とぐらいに思っていた・・・んだけど、会社に慣れてくるとちょっと度が過ぎるということで周りにも迷惑をかけはじめた。 とにかくなにかにつけて全て報告をあげて指示を仰いでくるのだ。 ざっくりいうと「そんなもん大した話じゃねーからいちいち聞いてくんな、自分でなんとかしろ」と言いたくなるものも全部報告してくる。 例えばティッシュが切れたらそれをいちいち上司に報告をあげる。 「増田さん、3F の303会議室のティッシュが切れてます。どうすればいいですか? ちょうど近くのコンビニでティッシュ安く売ってましたけど」そんな感じだ。 しかも指示を仰いだ挙句、自分のオリジナリティをぶっこんでくるのが厄介なのだ。 下手にきっちり報告しつつ

    いちいち全てを報告してくる部下をどう管理するか悩んでいる
    nemoba
    nemoba 2024/02/22
    報告出来るようにしてフィルタリング出来るようにしてって権限委譲の王道パターンや!むしろそこに悩むのは上司側の育成不足や!
  • ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products

    3年ほど前に登場した比較的新しいサービスであるApp Runnerを商用環境で導入した事例を紹介します。 インフラの運用の手間を軽量化できる一方で、利用して初めて気づく課題もありました。 日は実際の導入事例に基づいて、ECS Fargateとの比較、CI/CD・監視の工夫から障害発生時の運用方法といった生の体験を紹介することで、これから導入を考えている方へ向けて、技術選定のポイントとなる"肌感"を共有できればと思います。 登壇アーカイブ:https://www.youtube.com/watch?v=YiE3n06tfCA

    ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products
    nemoba
    nemoba 2024/02/22
    ECSのDeploy周りとかもそうだけど単体サービスでは使えるのに統合版だと無いってのが罠になりやすいよね。ALBのログなんてのは盲点になりそう
  • 間質性肺炎を検出するAIを開発し、その有効性を検証した研究を論文化しました - エムスリーテックブログ

    こんにちは、AI機械学習チームの浮田です。最近、私が筆頭著者の論文が公開されたので、今回はその紹介をします。 発表した論文はこちらです: www.ncbi.nlm.nih.gov この論文では、 胸部X線 (レントゲン) から間質性肺炎を検出するAIの評価を行いました。 結果、このAIを使うことで医師の読影成績が統計的有意に改善しました。 このAIを使うことで間質性肺炎の見落としを減らすことができることが期待されます。 エンジニアリンググループで論文を書くのは珍しい機会でしたが、査読対応など大変な時も経て無事公開することができました。 図1. 今回開発・検証した医療AIの実際の画面。プレスリリースより転載 今回開発・検証した医療AIの概要 有効性を検証するための臨床試験 目的 データセット、実験設定 結果 評価方法の詳細 感想 We're hiring! 今回開発・検証した医療AIの概要

    間質性肺炎を検出するAIを開発し、その有効性を検証した研究を論文化しました - エムスリーテックブログ
    nemoba
    nemoba 2024/02/22
    機械はスケールするメリットもあるから撮影したら自動で判断かけるみたいな数でカバーするのに使うって手もありかもしれん。
  • SaaS アーキテクチャ概要

    SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか?をまとめました。

    SaaS アーキテクチャ概要
    nemoba
    nemoba 2024/02/22
    SaaSへの資料性も凄いけど。アーキテクチャってこういうことだよねつう考え直しにもなる資料。要求だけとか技術だけとかならんように自戒
  • フロントエンドの移り変わりは早すぎるのか

    インターネットでは毎日のように言われることですが、私はそこまでではないと考えています。 ネットでよくそう言われる理由として考えられるものと、それを踏まえてどう向き合っていくとよさそうか、個人的な考えをまとめてみます。 なぜ言われるのか 言語が実質的にJavaScript一択 バックエンド、というかサーバサイドでは技術選定に「言語の選択」が入りますが、フロントエンドでは実質的にはJavaScriptにほぼ固定されます(TypeScriptも別言語ではないので、ここではJavaScriptに含めます) サーバサイドと比較して「技術の移り変わりが早すぎる」と評される場合、多くはその人の使用しているとある言語と比較されているように思われます。 実質的に言語が固定なので、比較するならすべてのサーバサイドの変化の総量と比較するのが妥当でしょう。 PHP + Python + Ruby + go + J

    フロントエンドの移り変わりは早すぎるのか
    nemoba
    nemoba 2024/02/22
    COBOLだってまだまだ現役なので率先して拾って頂けるといいですね。人材と規模のミスマッチがフロントエンドで起きやすいって視点が抜けてるかな。