You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
【Teams障害時のワークアラウンド】Azure Communication Service を使って9クリックでグループ通話アプリをデプロイしてみたMicrosoftAzureTeamsAzureCommunicationServices はじめに 本日のTeams 障害でみなさんお仕事への影響はいかがでしたか？数時間ながらこういう障害はTwitterが盛り上がりますね。 私はちょうどフォーカスしていたタイミングだったのであまり影響はなかったですが、そんな中でりなたむ 💉✖︎3⃣ || Microsoft MVP さんが、こんなつぶやきを。 一般「なにぃ！？ #Teams が落ちた！？12時からの××社との打ち合わせどうするんだーワタワタ」 弊社「あ、Teams落ちたのかー じゃあ #Azure の Communication Services つかって 簡易的な Web会議室作っちゃ
初めましての方ははじめまして、武本源五郎丸です。普段はアバター向けの服や小物を作っています。 先日このようなツイートを投稿しました。 え～この度夫がサキュバスになるという実績を解除しました これからもどうぞよろしくお願い致します。(夫がサキュバスになるって何？？？？？？？？？？？？) #サキュバス酒場 pic.twitter.com/x0FX37fBoX — 武本源五郎丸 (@tkmt_spitter) April 19, 2022 いや基本的に書いてある通りなんですけどそれにしたって意味わかんないですね。夫がサキュバスになるって何？ まあ人生の伴侶がこのような姿になるまでわりと色々あったので書き記してみようと思います。 ぶっちゃけほとんど家庭内での揉め事のまとめです。 いうて全て過ぎた話ではあるので過度に重く受け止めないよう・・・そんなこともあったんだなぁくらいで見てもらえると幸いです。
こんにちはnasaちゃんです。 コードレビューの記事を見かけたので僕がコードレビュー時に考えていること、行っていることを書いてみようと思いました。 この記事ではレビューを受ける側、行なう側それぞれの話がありましたが、ここではレビューを行なう側のことを書いていきます。(洗い出してみるとすべてがレビューコメントに関するものでした。) Whyを書く コードの変更をリクエストする際になぜ変更したほうが良いのかを書くようにしています。 レビュイーが変更を取り込むか判断する材料になるのでちゃんとなぜこっちのコードのほうが望ましいのかを書くようにしています。あと、言語化することで自分の理解も深まるので良いですね。 このとき、レビュー中のコードを批判しないことを心がけています。 「今のコードは〇〇というデメリットがあるので変えたほうが良い」と伝えるよりも「このような書き方をすることで〇〇がよくなると思いま
ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては
私が新卒で配属されたのは営業でした。 ただ、初対面の人と話すのが苦手という典型的な人見知りだったため、コミュニケーション力で勝負する営業や、それに類する職種では生き残れないと思いました。デザイナーという職業に転職したのは、「自分の腕で勝負する仕事に就いた方がいい」という私なりの生存戦略だったわけです。 しかし、デザイナーになって、余程の天才でない限り、腕（＝専門スキル）だけではやっていけないことに気が付きました。 コミュニケーション力に関してはもしかしたら営業と同レベルで必要かもしれません。デザイナーとして本当に良い仕事がしたければ、デザインに関する専門スキルだけにフォーカスせず、仕事の中でカバーする領域をもっと拡げるべきだと思うようになりました。 デザイナーがカバーすべき3つのデザイン領域 私が考えるデザイナーがカバーすべきデザイン領域とは、図にすると以下のようなものです。 それぞれにつ
誰向けの記事？ EM（Engineering Manager）の方に向けた記事です。 ただ、一般的な評価者全般にあてはまる内容を書いているので、評価を行う方なら誰でも参考にできると思います。 評価をする側ではないけど、どんな気持ちで自分のマネージャーが評価しているのか知りたい！といったエンジニアの方にも楽しんでいただけるかもしれません。 要約 メルカリエンジニア組織で、評価の負荷を削減しつつ、品質をあげるために、「Continuous Feedback」という仕組みを導入しました。 Continuous Feedbackは、通常よりも高い頻度でフィードバックを行うことで、負荷分散や、フィードバックサイクルの高速化などをはかる手法です。 導入した結果、評価に対する満足度や、評価を自身の成長に使えてると感じるようになったメンバーがとても増えました。現在では多くのEMの方が、評価に利用してくれて
この記事は Tech KAYAC Advent Calendar 2021の5日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。昨年のアドベントカレンダーでは、6年続いているサービスのPerlのバージョンを5.16から5.30にアップデートさせようとしたときの話を書かせてもらってりしていました。 最近は、絶滅危惧種Perlエンジニアのために、#Perlから逃げるなというハッシュタグを流行らせたいなーと思っています。 愛されキャラとは ところで皆さんの身の回りには、愛されキャラと呼ばれるような人はいるでしょうか？仕事場や学校など、身近に愛されキャラがいると、場の空気がとても良くなりますよね。そんな愛されキャラとはどんな特徴を持っているのでしょうか？ 雑にググってみると、例えば以下のような特徴を持っていることがわかります。 人に優しい 素直 寛容 たまに天然 弊
経営の重要なツールである予算につき私見を書いてみる。 世に予算を「正確に策定する」議論は多く見受けられるものの、なぜ予算を建てるかに対してストレートに述べたものはあまり見ない。 「なぜ」がなければ「どのように」は導けない。 予算とは経営からのメッセージ予算は、スタッフの行動を促すための仕様書 CEOは、これを肝に銘ずるべき。 「見通し」で予算数値を作る人は経営していないと宣言しているのと同じ。 一方、単なる気合を書いてしまう人も、メクラ運転になるのでハタ迷惑。 仕様書は以下の二つの機能を持つ。 ① 経営の方向をメッセージとして打ち出す 予算は言語表現であると割り切る。 ・大幅増益としたい場合 会社や置かれているステージによって「大幅」を表現する数値は異なり（30％増、倍増等）、スタッフの感覚と一致しなければ効果は半減する。 ・次年度以降の飛躍のため、あえて踏み固めることを伝える場合 前年度
2021-10-122021 年度新卒エンジニア研修についてこんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要今年の新卒研修の最終ゴールは、「メドレーのエンジニアとして、Our Essentials(※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではな
こんにちは！スマートキャンプ ソフトウェアエンジニアの中川です。 リモートワーク全盛の昨今ですが、みなさんはチームのコミュニケーションをどうされていますか？ 弊社のBOXIL開発チームはこのたびメインのコミュニケーションツールをDiscordからGatherに移しましたので、今回の記事ではそのなかで得られた知見やコツなどをご紹介できればと思います！ 前提・リモートワークにおけるコミュニケーションの二大方針について Discordによる同期的なコミュニケーションで起きた課題 Gatherとは Gatherによって起きたポジティブな効果 カジュアルな雑談の創出 ほどよいプライベート空間の確保 オフィスの視覚的な再現 全体 執務室エリア キャンプスペース（広間的なエリアやなんとなく集まる場） 会議室エリア 1on1エリア Gatherに足りてないこと・期待したいこと 提供されていない機能は補完で
お疲れさまです。インフラチームの山口です。 新型コロナウィルスの影響下でのリモートワークに伴い最近社内でいくつかのVPNアプライアンスのPoCを実施したのでその際に考えたことや振り返ってこうしておくべきだったという内容を戒めとして各フェーズに沿ってエッセイとして記載します。 なお、現在進行系で数種の製品のPoC中のため、「何か特定の製品を使ってうまくいった」や「弊社はこうしている」などの情報は何もない、私が感じたチラシの裏的なレポートになります。 要は、技術的に新規性のあることはない内容ですが、同じような問題意識を持ってる人間に届けばいいなといった感じの文章になります(文章でもなんでも刺さる人にだけ刺さればいいというポリシーなので、そういった感じです)。 本稿の構成を以下に記載します。 まず、筆者の経歴および、前提条件を説明します。 次に、製品選定や実際のPoC準備から実施までに考えたこと
※注意 Slackを電話と同等の同期ツールとして扱ってはいけません。 Slackのビデオ通話機能は同期ツールですが、通常のチャットは非同期ツールです。 また、SlackをTeams,Zoom等の同期ツールの補助的なものとして扱ってはいけません。 では、原文を引用して確認していきます。 👉 「Teams/Zoom、Slack、メールを用途で分けていますか？」 引用（＋翻訳） Strong tie (強い絆) / Weak tie (弱い絆) Two people connected by a strong tie can often transfer information more easily (as they are more likely to share a common perspective), to trust one another, to cooperate with
n @_sh0he1 - ビデオ通話・対面などの同期コミュニケーションが減り、チャット・メールなど情報量が少ない非同期コミュニケーションが増えた - グループ内にリモートに転向した同僚がいると、オフィスに残った同僚でも同様の変化が見られた（！） (2/n) n @_sh0he1 結論：リモート化は組織内のサイロ化を進める、質と量で劣る非同期コミュニケーションの増加を招き、労働者のアウトプットに長期的に影響する恐れがある。また、ハイブリッド型勤務でも”全員出勤日・リモート日”を設けるなど工夫しないとリモートの悪影響を受けることがわかった。 リンク Nature Human Behaviour The effects of remote work on collaboration among information workers - Nature Human Behaviour Using
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
こんにちは。BASEの藤川です。 緊急事態宣言も続く状況下で、当社もリモートワーク（Work From Home）中心の仕事の進め方をしています。ネット系企業は、幸いにしてVPN、Slack、GitHubやドキュメント管理ツール、その他仕事に必要なSaaSやZOOMがオンライン化しているため仕事の作業そのものは、それほど違和感なく自宅からでもできているのではないかと思います。 でも、仕事というのは作業だけで済むものではありません。業績を上げるための作業を生み出す活動を始めとする考えるタイミングであったり、不確実なものを埋めていくためにお互い議論するタイミングなど、曖昧なプロセスの先に、決定をして作業の的を絞り込んでいくプロセスが不可欠で、ここで複数人のチームワークが不可欠です。 今、一緒に仕事をしている仲間においては、コロナ以前から社内で人間関係を構築済みの人と、コロナ禍においてリモートだ
AWS テクニカルサポートを 5 年経験して アノテーションの荒川です。 クラスメソッドメンバーズをご契約いただいているお客様のテクニカルサポート業務を始めて、早 5 年が経過しました。 私が対応したチケット件数をざっくりと調べたところ、本日時点で 1685 件でした。 最近は私がチケット対応する機会は減りまして、チケット対応メンバーの教育（新入社員から各チームへ所属するまでの育成）やチケット相談に使う時間がメインです。 その中で、今まで何となくこうやって対応すると上手くいくと感じていた暗黙知をメモ書きしていたので、今回ブログとして公開します。 回答者側で意識したいこと 技術的なお問い合わせに関するガイドラインを参考にする AWS サポートのガイドラインは、一般的なカスタマーサポートでも使えます。 一文を短くし、適宜改行を挿入する 例: 一行にぎっしり × お客様環境をお調べしたところ、E
スマートキャンプのプロダクトマネージャーの郷田です。 皆さんは普段の業務で、以下のように感じる場面はありませんか？ - 「同じチームで働くあの人と、いつもなんだか認識がずれてるかもと感じる」 - 「一通り会議はやったものの、なんだかいまいち話しきれてないようなモヤモヤがある」 - 「あの人にはもっと注力してもらいたいことがあるのに、なかなかそこまでやってもらえない」 こういった場面に遭遇したときには、リーンコーヒーを実施されることをおすすめします！ この記事では、チームのMTGで活用してみていただきたい「リーンコーヒー」を紹介します。 リーンコーヒー（Lean Coffee）とは？ リーンコーヒーの進め方 準備するもの その１：トピック出しと優先順位の決定（5分~15分） その２：トピックのディスカッション（10分〜45分） 初めてのリーンコーヒーでのハマりどころ 継続するかの判断をせずに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
