はじめに 私はスタートアップを中心にWebエンジニアをしながら、アジャイルの展開をしています。いろいろな会社のいろいろなチームでアジャイルの展開をしてきました。今所属しているHITOTSU社ではVPoEやVPoTをやらせて頂きながら、開発エンジニアやスクラム寄りのアジャイルコーチをしています。 大体どのチームでも同じような話をさせて頂きまして、スクラムを始めるチームやスクラムが上手く回っていないチームに対して、アジャイルの価値観やマインドを理解せずに盲目的にスクラムイベントなどを実践するのは止めようという話をします。 まずアジャイルってなんだっけ 基本的にはアジャイルソフトウェア開発宣言(アジャイルマニフェスト)やアジャイルソフトウェアの12の原則）に則っていればアジャイルと言えます。 アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/m
本日は人生の数ある選択肢のなかから、こちらのブログを読むという行動を選んでくださいまして、まことにありがとうございます。 はじめに プログラミングの世界には多くの指針や原則が存在します。Chris Zimmerman氏の「The Rules of Programming」（邦題：ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール）は、不変の知恵を凝縮した一冊です。これらの原則は、多くの開発現場で活用できる有益な内容となっていると思いました。 The Rules of Programming: How to Write Better Code (English Edition) 作者:Zimmerman, ChrisO'Reilly MediaAmazon 本書は、大ヒットゲーム『Ghost of Tsushima』などで知られるゲーム制作スタジオ、Sucker Pun
こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。 新しいチームにジョインするのって、ドキドキしますよね。新しい環境、新しい人々、そして新しい課題。それぞれのチームが直面している問題は異なりますが、スクラムマスターとして私たちが共有する目標は一つです。それは、チームの有効性を最大化し、素晴らしいプロダクトを生み出すこと。 私は今年の1月にマネーフォワードにジョインし、今のチームでスクラムマスターとして働くことになりました。事前に聞いていたチームの情報は以下の通りです。 プロダクトマネージャー、UI/UXデザイナー、複数のバックエンド/フロントエンド/QAエンジニアから成る 従来のプロジェクトの進め方に課題感があり、4ヶ月前からスクラムを実践中 ここで一つの質問です。もし、あなたがスクラムマスターとして新しいチームにジョインしたとしたら、最初に何をしますか？この
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は（使い古されたネタではありますが）モノレポ化についてお話ししたいと思います。 おさらい：モノレポ（mono repo）とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ（poly repo）と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること
はじめにこんにちは！株式会社mikanでデザイナーをしているayataki（@ag_ayakan）です。 主に英語アプリ「mikan」の体験設計やUIデザインの作成を行なっています。 カジュアル面談などで話す際に、「mikanのデザイナーさんてどんなことをやってるんでしょうか？」という質問をよくいただくようになりました。 社外への発信が少ないこともあり、イメージを持ってもらいづらい状況にあるのではないかなと感じています。 そこで今日は、mikanのデザイナーとして働くわたしの1週間のスケジュールについてご紹介します！実際にあった直近のスケジュールを具体例に出していきます。 mikanのデザイナーに少しでも興味のある方に、具体的なイメージを持ってもらえたら幸いです🍊 それでは行ってみましょう！ [前提] 仕事の環境ほぼリモートワーク mikanのメンバーは基本的にフルリモートワークで働いて
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
VP of Engineeringのid:Songmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023、最終日の記事です。 ヘンリーは今年、本丸の病院向け電子カルテ・レセコンシステムのサービスを開始し、順調に事業が立ち上がっています。早くも業界でもユニークなポジションを獲得し、注目度も上がっています。 そんな中アクセルを踏む決断をし、来年は組織として100人採用に踏み切ることになりました。 ビジネスを勝ち切るためのアクセルを踏むフェーズにおいて、自分がVPoEとして採用や組織開発に主体的にチャレンジできる立場にいることは喜ばしいことです。その中で自分が考えていることを書き出していきます。 公器を志向すること 「面白法人でありながら上場することに意味と面白さがある」 2011年頃、当時私が所属していたカヤック社で代表の柳澤さんが度々こう言っていました。カヤック
はじめに この記事は、AEON Advent Calendar 2023の21日目です🎉 イオンスマートテクノロジー株式会社（通称AST）のCTO室TechLeadチームの@t0doroki_takaです。弊社ではSREチームの発信に勢いがありますが、アプリケーションレイヤーよりの話題も積極的に発信していければと思います。 自分の敗戦の振り返り 以前、大規模ECシステムのリプレース案件に関わった時(そして敗戦したとき)の振り返りです。 今回取り上げるケーススタディは、システム全体(連係するシステム含む)としては段階的移行ではありましたが、主ターゲットとなるシステムは、全EC機能を包括する大規模なシステムで、それをフルスクラッチでリプレースするものでした。 巨大なモノリス構造であったため、マイクロサービスアーキテクチャに移行することで、サービス提供のアジリティを確保することが目的の一つでし
ご挨拶 本記事はリンクアンドモチベーション Advent Calendar 2023の6日目です。 こんにちは、市原と申します。 開発をしていて見通しが立たないことって多いですよね。 今までやったことのある開発をすることの方が少なくて、大体は初めてのこと、初めてのメンバー、初めてのシチュエーションだと思います。 ある種の不確実性を抱えた仕事がほとんどではないでしょうか。 そんな見通しが立たない状況を偉大にも日々開拓してきた先人がいます。 ギャルです。 ギャルはいつの世も変化を当然のように受け入れ、適応し、さらに大きな変化を生み出してきました。 その上ギャルは楽しそうです。 プロジェクト乗り越えるためにギャルマインドを憑依させればうまくいくんじゃね？と思っちゃったので、 日常のプロジェクトで使えるギャルマインド3選を紹介していきます🫰👗✨ ※この記事は筆者のイマジナリーギャルに基づいて書
みなさんこんにちは。@ryuzeeです。 スクラムに限らず開発プロセスそのものは目的を達成するための手段に過ぎないので、定義されたプロセスやプラクティスを単に守れば良いというわけではありません。 根底にある価値観や原則を理解することが重要です。 とはいえ、自分たちのプロセスが定義されたもの、一般的なものとどれだけ違うかを知ることは、改善のキッカケにもなります。 今回、スクラムチームが、自分たちの仕事のやり方を改善する際に参考にできるような、セルフアセスメントのチェックリストを作ったので共有します。 現時点では単なる試作品なので、ご利用は自己責任でお願いします（この記事に限らず当サイトの記事を参考にする場合も同様です）。 使えそうなら適宜更新していく予定です。 観点はスクラムの主要要素（3-5-3）にしています。フィードバックなどがありましたら、@ryuzeeまでお知らせください。 使い方使
結成たぶん10年くらいのチーム白金動物園（mirakui, sorah, rosylilly）として ISUCON 13 に参加してきました。ここ数年はなんだかんだ運営側であることが多かったので、いち選手としては随分久しぶりな気がします。 結果は694チーム中18位で、最終スコアは 103,838 でした。 ISUCON13 受賞チームおよび全チームスコア : ISUCON公式Blog 優勝経験のあるチームとしては満足のいく結果ではありませんが、Rubyを使ったチームの中では一番スコアが高かったようです。 上位30チームに限定すると以下となりました Go 29組 96.7% Ruby 1組 3.3% ISUCON13 利用言語比率 : ISUCON公式Blog この1組が我々です。 あとLINEヤフー社が提供してくださった会場に入場した順では僕が1位を取りました。 ISUCON
社内のプロダクトマネージャーやイノベーターに向けて話した内容です。 価値の探索に適したチームとその作り方について話しました。 口頭でフォローした内容も多いですが、スライドが参考になると嬉しいです
チームトポロジーという本が言いたいことをざっくり知る。 特に、4つのチームタイプ、3つのインタラクションモードについて知り、今後のチーム間コミュニケーションに活かす。
This is a translated article. You can access the original here: Mob Programming – A Whole Team Approach by Woody Zuill モブプログラミング-チーム全体のアプローチ by Woody Zuill Translated by Yasunobu Kawaguchi, Ikuo Suyama and Ken Matsumoto 1. はじめに モブプログラミングとは、チーム全体が同じものを、同じ時間に、同じ空間で、同じコンピュータで作業するソフトウェア開発のアプローチです。これはペアプログラミング[PAIR]に似ています。ペアプログラミングは、2人の人が同じコンピュータの前に座り、同時に同じコードを共同作業するというものです。モブプログラミングでは、1台のコンピュータを使ってコード
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 皆さんは「No Measurement, No Improvement」という言葉をご存じでしょうか。これは「測れないものは改善できない」という意味で、熱力学者であるウィリアム・トムソン博士の言葉とされています。 下図はGoogle社のDORA（DevOps Research and Assessment）を参考にして作成しました。開発スピードとサービスの品質を改善するためには計測が必要です。計測のための4つの指標を紹介します。 四つの指標で計測し、開発スピードとサービスの品質を改善 開発スピードの分析に利用する指標は、1つ目が「Change Lead Time（開発が始まってから本番にデプロイされるまでの時間）」、2つ目が「De
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
