より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標 - Qiita
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ～、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの？という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか？それをまとめてみましたので、ご覧ください
メタバースの技術限界の解説 - Qiita
これらの試算から、1人あたりのトラッキングによる通信量はおおよそ16.88kbpsから112.50kbpsと考えられます。 スター型ネットワークの場合 ここでメタバースでスター型のネットワークを採用することを考えます。 どのような構成かというと、クライアントがトラッキングデータをサーバーへ送信します。各クライアントへのトラッキングデータの送信はサーバーが行います。 こうした構成を行う場合、全てのクライアントのデータがサーバーを介し、各クライアントへ流れ込みます。そのため、通信速度は下り速度がボトルネックとなります。ここでは人口75%ラインの88Mbpsを上限として考えます。 先ほどの1人当たりのトラッキングに関わる通信量から算出すると、スター型の場合、801～5,340人が通信の限界になります。 フルメッシュ型ネットワークの場合 一方で、サーバーを介しないクライアント同士が直接つながるフル
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
ZOZO開発組織の2021年の振り返りと現状
株式会社ZOZO 技術本部 本部長の @sonots です。この記事は ZOZOのAdvent Calendar 2021のカレンダー1の最終回（25日目）です。 2021年度、ZOZOにとっても、私にとっても大きな変化が2つありました。1つ目が2021年3月に前CTOの今村が退任し、私が全社技術戦略を策定する役割とZOZOTOWNリプレイスプロジェクト責任者を引き継いだこと、2つ目が2021年10月にZOZOとZOZOテクノロジーズの組織が再編され、私も含む開発部門がZOZOに併合されたことです。 この記事ではその変化の中で私と組織がこの一年取り組んできたものをいくつか取り上げたいと思います。 全社技術戦略策定 2021年4月にCTO的な役割を引き継いで、個人的に一番変わったのは経営陣（当時はZOZOテクノロジーズ）との対話が増えたことだと思います。私の考えているCTOの役割と、経営陣の
食べログの大規模なエンジニア組織を段階的に改善していく取り組み - Qiita
こんにちは、食べログシステム本部長の京和です。 昨年のアドベントカレンダーでは 「食べログの大規模なレガシーシステムを段階的に改善していく取り組み」 と言う記事で技術的な取り組みを中心に紹介しました。 今年のアドベントカレンダーでは、食べログのエンジニア組織を段階的に改善していく取り組みについてご紹介します。 食べログの組織構造 食べログの組織はシステム、営業、ビジネスと言った機能ごとに組織が分かれる、いわゆる機能別組織の組織構造を採用しています。 2021年12月現在の食べログの組織は、公式な組織図としては上記の機能別組織を維持しながら、内部ではマトリクス型組織の要素を一部に導入したハイブリッドな組織形態となっています。 今も試行錯誤中の段階ではありますが、現在に至るまでの変遷を、 システム部門を機能別組織として最適化する マトリクス型組織によるクロスファンクショナルチームの導入 「冒険
エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。 マネジメントを始めて悩んだこと 約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー（以下、EM）としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。 そんな中で常に「自分がマネージャーとしてきち
スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
ゆめみのiOSエンジニア研修を公開します！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私たち株式会社ゆめみでは、2020年から新卒者向けiOS研修カリキュラムを作成し運用してきました。 この研修をOSSで公開いたします！ 研修の内容 この研修には1〜14の課題が用意されており、 順番にクリアしながら天気予報アプリを開発していきます。 研修期間は個人のレベルによって異なりますが目安としては1ヶ月ほどと定めています。 研修に必要なもの インターネット環境 課題を参照するためにインターネット環境が必要です 開発環境 (Mac, Xcode) 実際にiOSアプリを開発していくので、Xcodeなどの環境は一通り必要になります 1名
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが
Google Apps Script (GAS) で Slack 連携を実装する前に知っておくとよい 5 つのこと - Qiita
Slack 連携、特にちょっとした通知を Google Apps Script (GAS) からやりたいというユースケースは非常によく聞かれます。本格的なアプリケーション動作環境などを用意することなく Google Workspace (旧 G Suite) のアカウントだけでちょっとした自動化をできるので、重宝しますよね。 ちなみに GAS の正式名称は「Google App Script」ではなく「Google Apps Script」です。たまに誤記を見かけます... Slack 連携で知っておくとよい 5 つのこと さて、本題です。 Slack アプリを Google Apps Script (GAS) で実装する場合、特にインタラクティブな機能の利用において知っておくべき制約があります。この記事では、以下の 5 つの留意点について解説します。ログの有効化など Slack アプリ開
Slack社はSlackをどう使っているのか - Slack利用ガイドラインの話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GitLab社のGitLab Handbookと徹底した文書化、組織的なオープンネス（？）を先日調べたのだが、じゃあ同じように見える化、透明性をアピールしているツールが何か？と考えた際ににSlackがあると思っている。SlackといえばDM禁止！オープンな職場が良し！風通し良し！なやつである。 しかしそれを実際会社で根付かせようとした時に、Slackの使い方を説くだけでは足りなくて、むしろ皆の意識改革みたいなものが必要だな～とひしひし感じさせられる。オープンな会社が良いかクローズドが良いか、「チームの風通しは良いほうが良いのか？」 世の
技術的なハマりパターンを分類・オサレに命名し、パターン毎に解決策(エンジニアのググり方・質問の仕方)を明示してみた - Qiita
※ 2021年1月22日(金)更新 2021-01-22 10:55 @zeatan さんからの編集リクエストを受け付けました。: not reflect(ed)について ・ "-" について ※ 2021年1月23日(土)更新 2021-01-23 13:25 Googleability を高める Cheat Sheet に語彙を追加しました。 : custom ・ pass について ※ 2021年1月24日(日)更新 2021-01-24 19:36 Googleability を高める Cheat Sheet に語彙を追加しました。 : not smooth について ※ 2021年1月25日(月)更新 2021-01-25 11:32 Googleability を高める Cheat Sheet に語彙を追加しました。 : bad performance について きっかけ 今朝
ふりかえりを拡張する「ふりかえりカタログ」 - Qiita
New!!（2024.1.11） 本記事の内容をよりブラッシュアップし、さらに使いやすくなった「ふりかえりカタログ（コミュニティ版）」をリリースしています。 今後はそちらをご利用ください。 ふりかえりカタログ（コミュニティ版） はじめに あなたのふりかえりを拡張するふりかえりカタログを公開いたします！ ふりかえりカタログは、ふりかえりの手法（現在）71個とその特徴を網羅したカタログです。下記画像はイメージです。 pdfはBoothで無料DLできます。 DLはコチラ => ふりかえりカタログ（Booth版） スライドはSpeakerDeckから参照できます。 DLはコチラ => ふりかえりカタログ（SpeakerDeck版） ふりかえりカタログとは ふりかえりの様々な手法をまとめたカタログです。 ふりかえりの各手法を「手法名」「手法を使う場面」「手法のイメージ」「出典」「進め方」「いいところ
Anaconda パッケージリポジトリが「大規模な」組織では有償となっていた - Qiita
2024年3月末にライセンスが全面的に改訂されました。 以前とは異なり、教育機関はカリキュラムベースのコースの使用のみに限定される場合には免除されるという条件が明記されました（Educational Entities will be exempt from the paid license requirement, provided that the use of the Anaconda Offering(s) is solely limited to being used for a curriculum-based course.）。 つまり、教育機関で研究目的の利用時は200人以上の組織であれば有償ということがはっきりしたことになります。 以前も「教育活動に関連して使用する場合（use by a student or employee of an educational insti
機械学習エンジニア弁護士が解説するAIと権利の話 - Qiita
みなさん、こんにちは。 こちらは「ABEJAアドベントカレンダー2020」の23日目の記事です。 はじめに 私は、弁護士として法律事務所に所属しつつ、ABEJAで法務のサポートなどをしています。 また、JDLAのE資格を取得したので、機械学習エンジニアを名乗って少しだけエンジニア的な活動をしたりもしています。 仕事柄、AIと法律の話をすることが多いのですが、その際に私がよく質問されるのが、 ① 所有権とか著作権とか特許権とか、権利がいろいろあってAIとの関係で何が問題になるかよくわからない ② データの利用が法的にOK／NGってどういう観点から検討してるのかよくわからない ③ AI開発の委託・受託のときのモデルの権利問題がよくわからない といったものです。 そこで今日は、この3つの問題をできるだけわかりやすく、一気に解説してしまおう！という記事を書きました。 経産省の「AI・データの利用に
テックリードになって気をつけていること - Qiita
フューチャーアドベントカレンダー2020の24日目です。 はじめに フューチャーに入ってテックリード（社内だとアーキリーダーと呼ぶことも多い）のような役割をし始めて4,5年ほど経過しました。 いくつかの案件を回して自分なりに汎化・パターン化してきた部分も増えてきたので、気を付けていることをまとめました。 テックリードとは エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。 テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である 技術的なプロジェクトの管理者 部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける チーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない 管理やリーダーシッ
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。
ライセンスをつけないとどうなるの？ - Qiita
GitHub上でプログラムを公開するとき、 どのライセンスを使えばいいのかわからない どうやってライセンスを設定すればいいのかわからない ライセンスというもの自体が難しそうでよくわからない などの理由で、ライセンスを設定しないままになっていることはないでしょうか？ この記事では、個人の開発者によるプログラムにライセンスが設定されていなかった場合にどのようなことが起きるのか、という観点からスタートして、ライセンスについての理解を深めていこうと思います。1 注意1: この記事の執筆者は法律に関する専門家ではありません。法律やライセンスに関する言及や解釈は不正確である可能性があります。実際の問題に対しては専門家による助言を受けてください。 注意2: この記事の内容は執筆者個人の見解であり、所属企業・部門の見解を代表するものではありません。 ライセンスがないということ プログラムのソースコードは、
MLOpsの各社の定義まとめ - Qiita
CI: 継続的インテグレーション CD: 継続的デリバリー CT: 継続的トレーニング CM: 継続的監視 2.2 Facebook Facebookのエンジニアブログを検索しましたが、ヒットしませんでした。 FBLearnerでMLOpsを実践しているものの、定義を書いているわけではなさそうです。 2.3 Intel Intelのwebサイト内にてMLOpsで検索しましたが、SeldonのCTOの紹介と求人票以外はヒットしませんでした。 https://www.intel.com/content/www/us/en/search.html?ws=text#q=MLOps&t=All プロセッサを作るのがメインの会社だから、無くても仕方ないですね。 2.4 Microsoft 2.4.1 Microsoftの定義 MLOps:Azure Machine Learning を使用したモデル管
Terraform職人再入門2020 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2020 の11日目の記事です。 3年ほど前に、「Terraform職人入門」という記事を書きました↓ Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる この記事は多くの人に読んでいただきましたが、当時のTerraformのバージョンはv0.11で、2019年5月にリリースされたv0.12以降のHCL2にも対応しておらず、またその後の周辺のエコシステムの変化などもあり、情報がずいぶん古くなってしまった感は否めません。また当時紹介した解決方法よりも、今ならよりよい解決策を知っているものもあります。未だに過去の記事にLGTMをもらうたびに、うれしさ半分と同時に、なんとなく心苦しい気持ち半分でした。 というわけで、「Terraform職人再入門2020」と題して、当時から差分のあった箇所を中心に、運用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
