中国・四川省で発見された新種の肉食恐竜の足跡化石に、『ドラえもん』のキャラクター「のび太」の名前がつけられた。その名も「エウブロンテス・ノビタイ」。この新種を発見した中国の研究者が大のドラえもんファンであることがきっかけだという。 【写真】のび太が新恐竜に「ノビサウルス」と名付けた名シーン 2021年7月、中国地質大学（北京）の恐竜足跡研究チームが、「中国四川省の白亜紀前期足跡化石の新種エウブロンテス・ノビタイ」に関する論文を公開した。恐竜名の最後の「ノビタイ」の部分が、ドラえもんの「のび太」に由来する。 この貴重な化石が中国四川省で発見されたのは2020年7月のこと。四川省を襲った集中豪雨の後、ひっくり返った板状の岩石の上に4つの足跡が刻まれているのが見つかった。中国地質大学（北京）のシン准教授らがこの足跡を詳しく調査した結果、肉食の恐竜エウブロンテス類の新種であることがわかり、この研究

プロジェクトが始まるときにかなり初期の段階でWBSを作ることは多いとおもいます。そのWBSの作成、プロマネやディレクターに任せっぱなしになっていないでしょうか。WBSはスケジュールをガントチャートで表したものを指していると思われがちですが、実はスケジュールだけでなく見積もりやアサインを精度高く行うためにも重要なものです。 たとえば「Webデザイン作成」というスコープにどのような実作業が含まれているかはWBSを作ることによって見える化しプロジェクトメンバーやクライアントと共有できるようになります。ときどき下記のように書かれたWBSを見ることがあります。 Webデザイン作成 ・作成 ・確認 ・修正 ・確認2 ・修正2 ・確定 しかし、これでは「Webデザイン作成」に必要な知識、さらには作業量・スケジュール・予算も分かりません。Webデザイン作成の例を続けると、下記のように「作成」のスコープを分

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお

今日はクラスメソッドの創立記念日です。クラスメソッドは年度も創立の月である7月はじまりで、今は新年度に切り替わったばかりです。 さて、その新年度の今期から私は危機管理室の室長を拝命しました。 危機管理室。 あまり聞き慣れない部署ですし、なんだか仰々しい名前ですね・・・ 私が室長になったということで旧室長が「新生危機管理室」と表現したのですが、社内から「地球外生物を駆除するチームみたいだな」というツッコミがありました。それなんて巨災対。（そしてよく考えたら全然名前似てない） 「どういうチームなんだろう？」と思われる方も多いと思うので、この機会に「危機管理室」とはどういったチームなのか、簡単にご紹介したいと思います。 危機管理室とは 一言でいうと会社のさまざまな危機やリスクに対応する部署です。英語名は少し違って、Information Secutiry Management Office、略称

Web APIやWebサービスのステータスページは大事です。障害が発生した際に、ステータスページがあれば状況が把握できます。何も情報がないのが最も不安を煽るので、ダメな場合でもダメという情報を伝えるのが肝心です。 今回紹介するStatsigはGitHubを使って構築する静的サイトなステータスページです。 Statsigの使い方 ステータスページです。 Statsigはマウスオーバーで簡易的な情報は表示しますが、基本的にこのページだけで完結します。過去30日における稼働率も可視化されています。GitHub Actionsを使ってチェックする仕組みが自動化されているのが特徴です。 StatsigはJavaScript製のオープンソース・ソフトウェア（ISC License）です。 Statsig Status statsig-io/statuspage

部下のマネジメントをするようになった人が、もっとも頭を悩ませるのは「フィードバックのやり方」ではないだろうか。 私はディレクターだが、社内におけるマネジメントも主な業務だ。前職での経験を合わせると、マネージャー歴は通算15年ほど。そんな私も、いまだにフィードバックするときは悩んでいる。 世の中にフィードバックの方法論はたくさんあり、私も勉強中ではあるが、これまでのマネージャー経験の中で最も重要だと感じていることが一つある。それは「タイミング」だ。 基本のタイミングは「スグ」に伝えること フィードバックが必要だと感じたら「スグ」に伝えよう。なぜなら時間が経つほど、フィードバックを受ける側の記憶が薄れ、心に響かなくなるからだ。また、何日も経って忘れた頃に「あの時のことだけど…」と掘り返されるのは気分が悪く、正論であっても素直に受け取りにくい。 具体的なタイミングとして活用しやすいのが、クライア

AWS テクニカルサポートを 5 年経験して アノテーションの荒川です。 クラスメソッドメンバーズをご契約いただいているお客様のテクニカルサポート業務を始めて、早 5 年が経過しました。 私が対応したチケット件数をざっくりと調べたところ、本日時点で 1685 件でした。 最近は私がチケット対応する機会は減りまして、チケット対応メンバーの教育（新入社員から各チームへ所属するまでの育成）やチケット相談に使う時間がメインです。 その中で、今まで何となくこうやって対応すると上手くいくと感じていた暗黙知をメモ書きしていたので、今回ブログとして公開します。 回答者側で意識したいこと 技術的なお問い合わせに関するガイドラインを参考にする AWS サポートのガイドラインは、一般的なカスタマーサポートでも使えます。 一文を短くし、適宜改行を挿入する 例: 一行にぎっしり × お客様環境をお調べしたところ、E