Menu. Currently selected: Standardize code review across your organization Organizations can now apply Copilot code review to all pull requests, including those from contributors without a Copilot license. Usage is billed seamlessly to the organization as premium requests, without requiring license management. This gives enterprises and open source maintainers greater coverage and confidence with

はじめに Luupに所属している、ぐりもお（@gr1m0h）です。 2025年7月、私が所属していたInfra/SREチームとQAチームが統合し、新たにQualityチームが発足しました。この体制変更は、品質保証とサイト信頼性エンジニアリングを統合的に捉える試みであり、従来の組織サイロを超えた挑戦だと考えています。 本記事では、SREチームのメンバーとしての視点から、私の考えを整理してお伝えします。QAとSREをどのように統合するか、そしてSREのプラクティスを用いて品質と信頼性を一貫して確保していくかについて説明したいと思います。 なお、本記事では以下の用語を次のように定義しています。 品質（Quality）: 機能要件が正しく実装され、ユーザーの期待を満たしている状態 信頼性（Reliability）: システムが継続的に安定して動作し、非機能要件を満たしている状態 Productio

1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。 本記事では、 SEのAさん デザイナーのBさん の二人が画面デザインをする過程を比べながら、その思考の違いを整理してみます。 3.SEのAさんの

はじめにITベンダーの皆様、申し訳ありません。 この数ヶ月、何社もの「進捗どうですか?」というメールに対して、「社内で検討中」と返信して進めておりませんでした。 御社の素晴らしいSaaSの導入を止めていた犯人は、私です。 言い訳をすると、今日は、いろいろな仕事に追われていた。 朝からDXのプロジェクトの進捗を見て、関係者に催促して、今度の対応事項をパワポに書いて。 それから、WindowsXPのような見た目の社内システムで、交通費の精算。エクセルをプリントして印鑑を押して、領収書をのりで貼り付けて、経理まで提出。一発で承認が降りる人は、部署内でも少ない その後、懇親会のメールの作成。ccの順番は部署順か役職順か。日程調整は、エクセルでは失礼ではないか。 そんな生産性とは無縁のことに頭を悩ませながら、時間が過ぎる。 この状態で、御社からのメールを開く。 「先日ご提案した件、ご検討状況はいかが

はじめに みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。 HIDS(host-based intrusion detection system)という概念をご存知ですか? 個々のサーバー内部でファイルの内容や設定変更を監視するセキュリティシステムです。 ネットワーク全体を監視するNIDS(network-based intrusion detection system)とは異なり、特定のホスト内の変化に焦点を当てたものです。 今回はLinuxベースのサーバ内で使用できるHIDSサービスである「AIDE」を用いて実際に動作検証を行い勉強しながらイメージを掴みたいと思います。 AIDEとは AIDE（Advanced Intrusion Detection Environment）は、Linuxで使用可能なオープンソースなファイル整合性監視ツールです。システムファイルの改ざ

Devin話題ですよね！弊社でもつい先日から契約開始しました！ 既に社内でガンガン利用されてる他社様での事例を拝見していると、難しいタスクになると中々うまくいかないようなお話も耳にしつつ、その会社独自で活用パターンを見つけられてるように感じました。 なので、活用パターンを丁寧に調べてからチームに渡すのではなく、クイックに展開した上で社内メンバーにDevinを活用してもらって、会社独自の利用パターンを探るのが良いなという考えに至りました。 早く使ってもらいたいと思いつつ、導入しました！使ってください！だと使い方のハードルがあったり、セキュリティやコスト面での懸念があったので、最低限担保したいことを整理した上で社内向けにクイックスタートガイドを作ってみました！ CTOである自分自身が決裁者としてなぜDevinを導入したのかという背景や、活用して行く上でのステップについて社内用に整理したものをア

順番は見つけた順なので適当です🙇 また、速報的に集めただけなので雑ですみません🙇 （運営から動画が近々公開されると思いますのでその繋ぎに） 掲載希望、削除希望あればお知らせください！ https://twitter.com/go_go_pdm 発表資料

先日、9月末の株主総会にて、4年半勤めたスターフェスティバルの取締役CTOを任期満了で退任し、3度目のCTOキャリアを終えました。 (直接ご挨拶できていない方もたくさんいるのですが… この場を借りてご報告させていただきます… スタフェスCTOとして大変お世話になりました。引き続きよろしくお願いします。) n回目、みたいな話に関しては、別に多い方が良いみたいなことではないので(むしろ1つの会社でCTOをやり続けている先輩などは、めちゃくちゃ尊敬している)、それ自体がどうって話ではないのだけれど、昨年 P2BCTO の LT で話した通り、様々なタイプの組織でCTOを経験をすることによって得られるものや自分自身に積み上がるものを実感したので、今日時点での自分の考えをアウトプットしておくことにしました。 なお、ver.2015 はコレで、まあ、あれから10年弱たったところ、という感じなのですが、

2024/11/11〜12 に行われた JPAAWG 7th General Meeting で発表した資料です https://meetings.jpaawg.org/

@__asachi__です。 普段はプロダクトマネージャーとかデザインとかをやっています。 最近、会社・事業のインフラコストをどう評価するかという話に社内でなって、実際各企業どんなもんなんだろうなと気になり、IR資料から頑張って漁ってきました。 せっかく色々と見たので、気になった事例等含めて書いていこうかなと思います。 (追記)：そもそも詳細な可視化&どう最適化していくかは難しいなと思ったので、そのあたりを支援するFinOpsツールをさっと作ってみました。https://clacos.dev/ TL;DR 上場企業のインフラコストを調べた 規模・業態問わずで30社くらいのデータを発掘できた 集計対象のうち最も費用が高かったのはゲーム会社アカツキ約11-12億/年 次点はツイキャス運営のモイ 約5.8億/年 「メメントモリ」が流行ったため、BANK OF INNOVATINが直近四半期でサー

2023-11-02 JaSST'23 Kyushu 招待講演 https://www.jasst.jp/symposium/jasst23kyushu.html 実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。

はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた

近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って

The language resources on this page can help you develop localized versions of applications that integrate with Microsoft products. By using the same terminology and style that Microsoft uses, your customers will find it easier to get started with your applications when used with Microsoft products. Terminology Microsoft Terminology can be used to ensure that terminology in your localized versions

GitHub ActionsではGITHUB_TOKENで権限が足りない場合、PAT（Personal Access Tokens）がよく使われます。しかしPATより優れた選択肢があります。それがGitHub Appsトークンです。本記事ではGitHub Appsトークンの実装方法をゼロから学びます。目標はPATの完全駆逐です。 本記事で学べること PATとGitHub Appsトークンの違い GitHub Appsの作成・インストール方法 GitHub ActionsでGitHub Appsトークンを払い出す方法 本番運用で考慮すべきセキュリティとトレードオフ イントロダクション GITHUB_TOKENはGitHub Actionsのワークフロー開始時に自動生成され、終了時に自動削除されるトークンです。GITHUB_TOKENで済むなら、これがベストです。何も悩む必要はありません。問題

Regional Scrum Gathering Tokyo 2017

はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発