タグ

classmethodに関するopparaのブックマーク (41)

  • クラスメソッド社内のAIサービス利用のガイドラインを策定しました | DevelopersIO

    GPT-4が公開され、GoogleがPaLMやGoogle WorkspaceへのジェネレーティブAIの統合を発表するなど、AIサービスの進化のスピードは目を見張るものがあります。 この状況のなか、社内でもAIサービスの利用について方針がほしい、という声も上がってきていました。それに応えてAIサービス利用のガイドラインを策定し、リリースを行いました。せっかくですので、どんな内容なのかを共有したいと思います。 全文 基 AIサービスを業務利用する場合は、原則として上長の許可を得ること。 検証目的で、業務に直接関連しない情報(テストデータなど)を入力して試すことは問題ない。 業務情報を利用したい場合は、この後の「業務利用する場合」のガイドラインに沿うこと。 サービス利用前に、データの取り扱いの規約を必ず確認すること。 AIサービスを業務利用する場合 業務情報を用いる場合は、利用規約を確認

    クラスメソッド社内のAIサービス利用のガイドラインを策定しました | DevelopersIO
  • マネージャーセルフ事前オンボーディング – マネージャー正式就任の半年前からやっていたこと | DevelopersIO

    就任自体は半年前から予め聞いていて、前倒しできるマネジメント業務は前室長である大橋からどんどん巻き取っていたので、実質半年前からある程度はマネージャーの業務をやっていました。 マネージャーの業務を担当するのがはじめてということもあり、就任依頼を受けてから今日までやってきたことを整理することで、これから新任でマネージャーになる方の参考になれば幸いです。 なお、部門の中にグループがあり、グループの範囲のマネージャーを経て部門の責任者になるようなケースも多いように思います。私の場合は小規模部門ということもあり、いきなり部門の責任者になるので担当する責務が多めになります。グループマネージャーとの差分としては主に部門の組織運営や、部門方針を経営層や他部門の部長陣と握る部分などですね。

    マネージャーセルフ事前オンボーディング – マネージャー正式就任の半年前からやっていたこと | DevelopersIO
  • AWS re:Invent 2022 英語でのコミュニケーションについて考察してみた #reinvent | DevelopersIO

    こんにちは、ドイツから参加中のyagiです。 私は今回、AWS re:Invent 初参加なのですが、現地での英語コミュニケーションについて、気がついたことがいくつかあったので、備忘録もかねて残しておきたいと思います。 なお私は英語はそんなに得意な方では無く、普段はドイツ語圏であるため、簡単な会話のドイツ語英語で済ませてしまうことも多いです。 もし記載内容に間違いなどお気づきの点があれば、どんどん指摘をいただければ幸いです! 現地でよく聞かれる質問について AWS re:Invent では、朝ごはんやランチ会場、または夜のパーティーなどで、当に様々な海外の方に話しかけていただきます。 参加中の方々は当に紳士で魅力的な方が多く、改めて、AWS re:Invent がいかに素晴らしいイベントであるかを実感しています。 Is anyone / someone sitting here? も

    AWS re:Invent 2022 英語でのコミュニケーションについて考察してみた #reinvent | DevelopersIO
  • スプレッドシートを利用して入社初日にセルフオンボーディングを行った話 | DevelopersIO

    当社は、入社後に2週間かけて、全社共通のセルフオンボーディングを実施しています。この記事では、Googleスプレッドシートを利用して入社初日にセルフオンボーディングを実施した事例を中心に紹介していますので、入社の方への研修やオンボーディングの導入をお考えの方のお役に立てれば嬉しいです。 はじめに こんにちは。クラスメソッドグループの総務を担当しているダニーです。 当社では、入社後に2週間かけて、Googleスプレッドシートを利用して新入社員自身で学習を進めるセルフオンボーディング方式のオリエンを採用しています。 この記事では、実際に当社が実施しているセルフオンボーディングについて、実施方法、改善結果等をご紹介します。 Googleスプレッドシートによるオンボーディング導入の経緯 前回の記事でUdemyBusinessを利用して新入社員自身で学習を進めるオンボーディング方式をご紹介しました。

    スプレッドシートを利用して入社初日にセルフオンボーディングを行った話 | DevelopersIO
  • 個人のキャリア成功、成長実感、成長支援を大切にした週次1on1 | DevelopersIO

    そこで、エンジニアリング統括室で行っている1on1の内容について1例として共有します。少しずつカスタマイズしていますが、ここ半年程度はこのスタンスで1on1を実施しています。特にエンジニアリング統括室のメンバーはもともとはエンジニアであり、分野としては人事領域にあたるエンジニアリング統括室での活動は未知の領域です。手厚い支援は必須と言えます。

    個人のキャリア成功、成長実感、成長支援を大切にした週次1on1 | DevelopersIO
  • [メンバーズ向け]既存のAWSアカウントにセキュアアカウント設定を一部導入してみた(リージョン限定、コスト優先) | DevelopersIO

    クラスメソッドのAWS請求代行サービスでは、 AWSのクラウドサービスを活用したセキュリティリスクの抑制、軽減を実現したAWSアカウントを、セキュアアカウントとして提供しています。 2022年8月時点の 弊社ポータルサイト(メンバーズポータル)を利用した、既存AWSアカウントへのセキュアカウント設定と、 AWSコスト抑制のため、対象リージョンや、利用するAWSサービスの絞り込みを実施する機会がありましたので、紹介させていただきます。 メンバーズポータル設定 メンバーズポータルサイトに管理者権限を持つユーザでログインしました。 AWSアカウント指定 対象AWSアカウントを選択しました メンバーズサービス設定 メンバーズサービス設定 「設定する」 を選択しました セキュリティ設定 「セキュリティ設定を選択しました 共通設定 追加料金なく利用できる共通設定は、すべて有効化しました。 パスワードポ

    [メンバーズ向け]既存のAWSアカウントにセキュアアカウント設定を一部導入してみた(リージョン限定、コスト優先) | DevelopersIO
  • コミュニケーションのバイパスとしての「談話室」メソッド | DevelopersIO

    prismatix事業部の塩谷 (@kwappa) です。 1月の後半からずっと、自分の部署に限定しない1on1を「かっぱ談話室」というタイトルで実施しています。話題はなんでもよくて、ぼくの経験やキャリアをお話ししたり、単に雑談をしたり、ガチなお悩みの相談を受けたりと、いろんな目的で参加してもらっています。 この記事では、部門も話題も限定しない1on1である「談話室」というメソッドと、その効能としての「コミュニケーションのバイパス」についてご紹介します。 「談話室」メソッド 「談話室」は、部門・話題を限定しない誰でも歓迎の1on1です。 やりかた 談話室を希望する人は予定を予約します Google Calendarの「予約枠」機能を使います 30分1枠で、他の予定に重ならない時間帯をあらかじめ予約可能にしておきます Google Meetで談話します 基的には会話をするだけです 話題はど

    コミュニケーションのバイパスとしての「談話室」メソッド | DevelopersIO
  • EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO

    この7月からDev PjMにクラスチェンジしました。何もわからない状態から、いかにしてプロジェクトの状態を把握・コントロールしようとしたか、その試行錯誤の記録です。 4ヶ月前に言ってたことダイジェスト Dev PjMになって最初の頃、こんな話を書いていました。 prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO マネジメントの姿勢 そこで、私は 指揮者(Conductor) として振るまおうと決意しました。 何をしたいのか Devチームを中心として系が回るようにする ことを実現したいと思っています。 もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。 どうしていくのか Devチームもハッピー、みんなもハッピー な状

    EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO
  • 組織開発の意思決定透明化のために ODDR を試すことにしました | DevelopersIO

    こんにちわ。てぃーびーです。 最近システム開発界隈でたまに話題をみかける「ADR」。 ADR は Architectural Decision Records の略で、アーキテクチャーの意思決定を決まったフォーマットで記録し続ける手法です。アーキテクチャーの意思決定後、時間の経過とともに当時のアーキテクチャーを設計した人が異動や退職で不在になり、後任が現在の設計を検討する上で、なぜ現状のアーキテクチャーになっているか確認したい、といったときがこの記録が活用される典型的なケースです。それ以外にも人の記憶は不確かなため、意思決定をした人にとっても記録は便利です。 そういった必要性に関して niku さんの以下の記事が参考になります。 2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した|ヽ(´・肉・`)ノ|no

    組織開発の意思決定透明化のために ODDR を試すことにしました | DevelopersIO
  • グランドルールでミーティングの質と効率を高める | DevelopersIO

    仕事においてミーティングは重要な要素の一つです。意思決定、アイデア出し、ふりかえりなど多様な目的の場があります。

    グランドルールでミーティングの質と効率を高める | DevelopersIO
  • 最近の業務での AWS サーバーレス開発を振り返ってみた | DevelopersIO

    AWS Lambda を使用した Web アプリケーションの開発プロジェクトで、バックエンド・フロントエンド・インフラを一貫して開発をしてきました。 改めてどのように開発をしていたのか、使った技術スタックや各サービスをどのように活用したかを整理したいと思い記事にしました。今後サーバーレス開発を行う際の技術選定の参考にしていただければ幸いです。 前提 Web アプリケーションです。 管理画面用の内部 Web API、外部のサービスと連携するための外部 Web API があります。 処理としてはリソースの CRUD がメインです。 管理画面は SPA で、バックエンドの Web API にリクエストします。 開発メンバーは 4 人ほどで、フロントエンドエンジニア、バックエンドエンジニアといった区分けはしていませんでした。 機能ごとにメンバー全員がバックエンドからフロントエンドまでを一気通貫で実

    最近の業務での AWS サーバーレス開発を振り返ってみた | DevelopersIO
  • [安全なAWSセキュリティ運用ナレッジ2022]セキュアアカウントの使い方 | DevelopersIO

    AWS環境をセキュアにセットアップする方法と、その運用方法を詳細に紹介します。秘伝のタレである具体的な設定も書いてます。みんな真似していいよ! こんにちは、臼田です。 みなさん、安全にAWS使えていますか?(挨拶 今日は全てのAWSユーザーが安全にAWSを活用し、セキュアに運用できるようにナレッジを大量にダンプしたいと思います。 弊社サービスに関連させて書く部分もありますが、基的にどのようなAWS環境でも適用できると思います。 ちょっと長い背景 クラスメソッドでは長いこと様々なAWSを利用するお客様を支援しています。私は特にセキュリティ周りについて支援させていただくことが多く、最近はAWSセキュリティサービスが充実していることから、これらの初期導入や運用設計、あるいはインシデント対応やその後の組織としてのセキュリティ体制づくりなどいろんな関わり方をしてきました。 どのようにセキュリティ

    [安全なAWSセキュリティ運用ナレッジ2022]セキュアアカウントの使い方 | DevelopersIO
  • なぜ私が議事録を書くのか?あなたが議事録を書く理由について解説 | DevelopersIO

    データアナリティクス事業部@札幌の佐藤です。 議事録を書くこと好きですか? 私がまだ入社間もないころによく指示されていた議事録を書くというタスクについて、昔は面白くなく、うまくできない作業で好きではありませんでした。 いまだに好きではありませんが、議事録を書くというタスクの意味についてなんとなく自分の中で腹落ちできていたのがひとつの要因だと思います。 今回は議事録の「書き方」について言及せず、なぜ議事録を自分が書かなきゃいけないのかという側面で明文化していきたいと思います。 あくまで私の経験によるものとなりますので、来のあるべきからそれている可能性や、違うということもあるかと思いますがご了承いただければと思います。 また、当内容は議事録を取るという仕事をされている方を否定している記事ではありません。 あなたがなぜ議事録を取るのか 議事録を取る人というのは往々にして、その会議に参加してい

    なぜ私が議事録を書くのか?あなたが議事録を書く理由について解説 | DevelopersIO
  • AWS CDKの学習方法 ドキュメントや学習コンテンツをまとめてみる | DevelopersIO

    AWS CDK?学習コスト高そう。。」 AWS CDKは、プログラミング言語でインフラを定義できる便利なツールです。 反面、プログラミングに慣れていない人には学習コストが高そうに感じるかもしれません。 AWS CDKを使ったことがない方が学習を進めるのに役立つドキュメントや学習コンテンツをまとめてみました。 以下のような方の、参考になると嬉しいです。 AWS CDK何から始めればいいのかわからない 概要は知っているけど触ったことはない プログラミング言語を使うことにハードルを感じる 入門 とりあえず動かす とりあえず、動かしてみましょう。 CDK入門には「CDK Workshop」が有名ですが、以下の方がボリュームは少ないのでファーストステップにおすすめです。(所要時間 25分) AWS Cloud Development Kit (CDK) の開始方法 | はじめに こちらのガイドでは

    AWS CDKの学習方法 ドキュメントや学習コンテンツをまとめてみる | DevelopersIO
  • デザインの現場で絶対に必要になる基礎知識7選 | DevelopersIO

    こんにちは、アシスタントデザイナーの秋田です! デザイン知識ゼロで入社した私が、一番最初に学んだ現場で使う基礎知識をまとめました。 近年では、未経験でキャリアチェンジしてデザイナーを目指す方も珍しくないかと思います。私もその一人です。デザイン教育を受けていない人にとって、デザインは何から勉強し始めたらいいのか迷ってしまうことがあるかと思います。 この記事は、全て先輩デザイナーからのフィードバックにより得た知識をまとめています。実際に現場で使う知識なのでデザインに興味がある方や、これからデザインの勉強をされる方にとって少しでもヒントになったり、参考になれば幸いです。 1. 「デザイン=見た目を綺麗にすること」ではない 「デザイン」と聞くと、皆さんはどんなことが頭に浮かぶでしょうか?「見た目を綺麗にすること」と思われる方が多いのではないでしょうか。もちろんそれも間違いではありません。しかし、な

    デザインの現場で絶対に必要になる基礎知識7選 | DevelopersIO
  • 1on1 ノウハウの共有 | DevelopersIO

    ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては

    1on1 ノウハウの共有 | DevelopersIO
  • キャリアパスに悩んだときに考えるポイント集 | DevelopersIO

    最近、エンジニアの方のキャリアパス相談に乗る、ということをやっています。 https://meety.net/matches/wjnqyJbQFaaD かなりの引き合いをいただき、社内外含めて 10 名ほどの方とお話しさせていただきました。 また、立場はときどきで変わりましたが、業務としての 1on1 でこういった話しをすることもかなりの回数ありました。 その中で、考えるポイントをあらかじめ伝えることでみなさんが悩む時間を最小化できるのでは、と感じたので、この記事で共有します。 エンジニアだけでなく、どのような職種の方にも応用できる考え方です。 will / can / should を意識する そもそも自分が何をやりたいのかわからない、という相談内容の方も多くいらっしゃいます。その場合はまずここからはじめます。 一言で説明すると、 will は「将来の夢」、 can は「今できること」、

    キャリアパスに悩んだときに考えるポイント集 | DevelopersIO
  • opswitchを開始する

  • 社内コミュニケーションを盛り上げる活動「褒めそやすっ!」について | DevelopersIO

    はじめに きっかけがTwitterで恐縮なんですが、ある日僕が ただひたすらに僕が相手を30分間褒め称え続ける1on1やりたい。 — すもけ@結局は筋肉 (@smokeymonkey) October 27, 2021 と言ったところ、januswelさんが企画してくれました(やぬすさん、ありがとうございます) また、「褒めそやすっ!」の命名者は阿部信介さんです(あべさん、ありがとうございます) とりあえず1ヶ月間やってみたので、こちらの活動について改めて社内外にご紹介したいと思います。 「褒めそやすっ!」について 感じていた課題 一番大きく感じていたのは、全メンバーが完全在宅勤務となったことで「自分の仕事を他のメンバーに見せたり知ってもらうことが出来ない」「他のメンバーの仕事を見たり知ることができない」というものでした。 皆が同じオフィスで働いているときには、例えば総務のメンバーがオフィ

    社内コミュニケーションを盛り上げる活動「褒めそやすっ!」について | DevelopersIO
  • チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました | DevelopersIO

    チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました 事業開発部の塩谷 (@kwappa) です。 クラスメソッドの関連会社であるアノテーション株式会社の研修として依頼を受け、チームと心理的安全性、それに礼節というテーマで話をしてきました。 スライド 概要 ここしばらく重点的に書いたり喋ったりしている、心理的安全性とその土台となる礼節がテーマです。昨年のDevelopers.IO Tokyo 2019でのセッション『3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜』 をベースに、発表時間が少し長くなったので各要素の解説を丁寧にしつつ、全体の流れを整理しています。 また、エンジニアに特化した部分をはがすことも意識しています。チームで仕事をするのはエンジニアに限ったことではないですし、昨年末からOpsチームのスクラムマス

    チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました | DevelopersIO