Mutation Testingを活用して テスト品質を考える /introduction to mutation testing
先日発表された「株式会社日本カストディ銀行 ガバナンス検証第三者委員会の調査・検証報告書」に考えさせられた。 ・調査・検証報告書 https://www.custody.jp/news/pdf/news_cbj/20240419_report1.pdf ・調査・検証報告書(要約版) https://www.custody.jp/news/pdf/news_cbj/20240419_report2.pdf 要約版だけ見ても理解できるだろう。 ガバナンス機能が欠落していた、と一言で言えば簡単だが、これらの件は誰が止めることができたのだろうか。 社内で自浄作用を働かせるとして、役員レベルで「こうしなさい」と内部監査人含め現場に命令が飛んだら、何も言えなくなるんじゃないかな。 内部監査人の指摘は役員レベル以上の重みを持つのなら発言ができるが、それこそ権限がおかしいことになる。内部監査の結果を役員が
はじめに こんにちは。SmartHR プロダクトマネージャーの山根(@sayama)です。 この記事は 「SmartHRのプロダクトマネージャー全員でブログ書く2024」 への参加記事です。 25人が持ち回りで毎週記事を投稿します。ぜひご覧ください! 今回は自分がなぜSmartHRに入社したのか、その気持ちの変遷を振り返ってみようと思います。 自分の市場価値ってなに? SmartHRに入社するまでは、製造業での機械設計を経て、技術者向け情報管理システムの構築以降、自然言語系AIの黎明期からプロジェクトマネージャー・プロダクトマネージャーを経験してきました。業務DXのためのシステム導入や既存プロダクトへのAI機能の付加価値を考えたり、それをグローバルに展開するのも非常に刺激的で、ワクワクしながら推進してきたことをよく覚えています。 キャリアの変遷 改めて自分のキャリアを振り返ると、客観的には
今年7月1日、現場DXプラットフォーム『カミナシ』の開発及び提供を行う株式会社カミナシの執行役員CTOに、元Amazon Web Services 原 トリ氏が就任。テクノロジーカンパニーへと舵を切った同社に迫るべく、CTO原氏への取材を敢行しました。当記事では、SaaSビジネスの拡大を見据えた組織設計、技術負債やセキュリティなどの組織課題に対する同社の取り組みを紹介します。また、同社でエンジニアリングマネージャーを務める宮本氏にも加わっていただき、CTOの採用背景やCTO設置後の様子も伺うことができました。 ERPパッケージベンダーR&Dチームにてソフトウェアエンジニアとして設計・開発に従事。その後クラウドを前提としたSI+MSP企業での設計・開発・運用業務を経験し、2018年Amazon Web Services入社。AWSコンテナサービスを中心とした技術領域における顧客への技術支援や
当社は、「こころに贅沢させよう」をコンセプトに、ラグジュアリーホテル、高級旅館の予約サイト『一休.com』や厳選されたレストランの予約サービス『一休レストラン』を運営するほか、ギフトチケットの販売サービスなどを展開しています。 2000年より開始した同サービスは、2021年10月時点の会員数が1,300万人を突破するまでに成長。こころに贅沢な時間を世に増やすことを目指してます。 幼少期、ゲーム目当てに始めたプログラミング。大学生になると、職業としてその道を志すようになった。
ここ2年ほど、全国に点在する経営者や経営幹部と出会い、話を聞く機会を増やしている。月平均3~4名くらいのペースで、企業規模は数十名から数百名前半くらいの中小・中堅企業が多い。 地域/業種/業界/規模はバラバラながら、共通する話題もある。中でも表題の「40~50代社員の老害化」はよく耳にするテーマである。 個人的には、「老害」という言葉を安易に用いるのは好きではない。なぜなら、自分に都合が悪い年配者をすべてそこにカテゴライズし、全否定できる言葉だからである。実際には老害とは反対の「若害」といえる現象も存在するように思う。それも含めて、物事は「誰が言ったか」ではなく「何を言ったか」で冷静に客観的に見なければいけない。 その前提があった上で、比較的若い経営者や経営幹部の話を聞くと、「それは確かに老害という言葉で表現するしかないかもしれない」と思うことはある。 老害社員とは こうした話題で出てくる
技術力によってファッション業界のインフラになることを目指すZOZO。現在は、経営戦略である「MORE FASHION × FASHION TECH ~ ワクワクできる『似合う』を届ける ~」の具現化やファッションEC「ZOZOTOWN」のリプレイスなどに注力している。 具体的にどのような取り組みをしているのか。2023年6月、ZOZO 執行役員 兼 CTO(Chief Technology Officer:最高技術責任者)に就任した瀬尾直利氏への取材を通し、“MORE FASHION × FASHION TECH”の現在地を探った。 瀬尾直利氏(ZOZO 執行役員 兼 CTO):ディー・エヌ・エーなどを経て、19年1月ZOZOテクノロジーズに入社。ZOZOに再編後、22年4月に技術部門トップのVPoEに就任。23年6月から現職。技術本部やブランドソリューション開発本部、情報セキュリティ・I
これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職(テックリードだったり、デザインリードだったりそういうやつ)につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの
claude.iconこれらのツイートは、先端的な開発プロジェクトにおいて「ガチでやる気パーソン(GYP)」の存在が非常に重要だという点で一致しています。
こんにちは、@chaspyです。プロダクト開発部の部長をしています。 スタディサプリ小中高の開発組織では、Engineering Manager (以降 EM と記す) という役割があります。*1 その役割は、エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド を引用させてもらうと、People Management + Technology Management を主に担ってもらっています。*2 ありがたいことに、ここ数年で新たに EM にチャレンジしてもらえる機会が増えました。本稿ではそんな EM の活躍をサポートするオンボーディングの仕組みについて説明します。 メンバーのオンボーディングとの違い 任用直後にグレード設定という重要な仕事がある (主に人事の内容は)秘匿された情報が多く、引き継ぎの重要性が高い 新任 EM を迎える絶対数が(相対的に)少ない EM
Datadog社の事例紹介セミナーで発表してきました。重要なのは監視機能ではなくて……という話 KODANSHAtech エンジニアの堤です。 去る2024年3月8日に、Datadog社の事例紹介セミナーに弊社の長尾と天重が登壇し、KODANSHAtechでのDatadog導入事例を紹介させていただきました。 監視&分析サービスであるDatadog、導入したのは、講談社の美容・コスメ誌であるVOCE (https://i-voce.jp/) WEBサイトです。 発表資料はこちら↓ この資料をパラパラとめくっていただくと分かると思うんですが、Datadogの話、あんまり出てきてません!! 何しに行ったの? まあ聞いて下さい。だいたい以下のような話をしてきました。 分断を乗り越える。分断って何? 「コンウェイの法則」というのをご存知でしょうか? システム(広義に定義)を設計するあらゆる組織は、
はじめに こんにちは! STORES 株式会社 リテール本部でエンジニアリングマネージャー( EM ) をしています、藤井( daitasu )です。 STORES はいま、会社全体が400名を超える規模であり、エンジニア部門だけでも100名以上の人数が在籍しており、ここ数年で組織として非常にスケールをしている会社になります。 従業員数の推移 こうしたスケール中の組織の中では、組織体制の変更も時としてあり、EM として新しい開発チームに後からJOINする、ということも度々あります。 新しくできたチーム、または、既に醸成しているチームに EM としてJOINする、というのはプロジェクトやカルチャー、メンバーステータスなど把握しないといけないことが山程あります。 こうした情報を早期に吸い上げておくことは、プロジェクトの進行としても、チームメンバーとのコミュニケーションの上でも、円滑に進めていく
はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象
この記事は スターフェスティバル スターフェスティバル Advent Calendar 2023の6日目の記事です。 (風邪を引いていたら書くタイミングを逃してしまい今に至ってます) 5日目はzakiさんから「OpenAI APIのJSON ModeとFunction Callingの精度比較」でした。7日目はkogaさんから「monorepoのリポジトリにRelease Drafterを導入して複数のタグを管理する[NestJSプロジェクトを例に]」です! と、いうわけでタイトルが全てみたいなことを書いていきますが、要するに何が言いたいかというと「今、スタフェスがEM全員がプレイヤーとしても振る舞う開発組織」を実践しているが、割とうまくいっているという実感があります。 なので、この記事では、 エンジニアリングマネージャー(EM)を、マネージャー専業ではなくプレイングマネージャーで構築する
はじめに 最近、チームってどんな構成にするのがいいんだろうか?と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか? チーム間のコミュニケーション(インタラクション)をどう設計するか? 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか? チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、1つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(中編) アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク(Dmytro Yarmak)氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
本エントリはカケハシ Advent Calendar 2023 Part 2の 25 日目の記事です。ぜひ Part1 と合わせて見て頂けたらと思います。 本日はMusubi AI在庫管理プロダクト開発チームでエンジニアリングマネージャーをしている僕が、開発ディレクターとして入社した当時に進めた組織変更への取り組みについて、現状の組織の状態も踏まえて振り返ってみようと思います。 組織変更の方針 入社した当時、Musubi AI在庫管理はフロントエンドチームとバックエンドチームに分かれて活動していました。 同じプロダクトを開発しているにもかかわらず、それぞれのチームは別々に活動している状態で同じ開発テーマも異なる時期に開発していることもありました。 それをフロントエンド、バックエンド混合のフィーチャーチーム化するというのが組織変更の方針でした。 組織変更の背景 実は組織変更の方向性は僕が入社
この記事は リクルート ICT統括室 Advent Calendar 2023 18日目の記事です。 こんにちは、ICT統括室の別府(@tky_bpp)です。この記事は、社内の情報流通を社内プロダクト起点で改善しようとしている取り組みの紹介です。 具体的には「社内・社外に分散している情報」を集約することで「各従業員がこれまでどのような仕事をしてきたのか」を可視化しようとしている取り組みです。その中でも、主にプロセス、工夫した点について書いています。そのため、特定の技術スタック、ツールの紹介といった技術的な内容にはあまり触れません。 同じような課題に取り組んでいる方にとって、少しでも参考になれば幸いです。 はじめに 私は現在、リクルートの社内で利用されている従業員検索システムのプロダクトマネージャーをしています。 このシステムには、従業員毎の個人ページがあり、連絡先や所属部署、使用しているパ
こんにちは、モノタロウのUIUXグループの澤井です。 主にサービス開発や商品開発のためのリサーチ・体験設計、これらのための仕組みづくり・運用に携わっています。 この記事では、チームにポジティブなコミュニケーションを増やすために、メンバー同士の自己開示のためのツールとしてスキルマップを利用したこと、利用にあたって工夫したことについてお話していきます。 目次 スキルマップってどんなツール? スキルマップを利用しようと思った背景 スキルマップの利用にあたって工夫したこと スキルマップを利用してどうだったか おわりに スキルマップってどんなツール? そもそもスキルマップはどんなものかといいますと、縦軸と横軸を中心で交差させて分けた4つのセグメントにスキルをマッピングして傾向や状態を可視化するものです。自己紹介や自己分析に使ったり、目的によって様々に利用できる便利なツールです。 詳しくは、宇野さんの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く