非同期開発体制を支えるドキュメント文化 / YAPC::Hiroshima 2024git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo
「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法【Sansan西場正浩】 レバテックラボ（レバテックLAB）
「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法【Sansan西場正浩】 2024年1月16日 Sansan株式会社 執行役員 VPoE/VPoP 西場 正浩 大学院で数理ファイナンスの博士号を取得後、大手銀行で数理モデルの開発に従事。その後医療系IT企業でエンジニアやプロダクトマネジャー、事業責任者、採用人事などを幅広く務める。2021年にSansan株式会社へ入社。技術本部研究開発部でマネジメント業務に当たり、現在はVPoEとしてエンジニア組織の整備と強化を、さらにVPoPとして、営業DXのためのSaaS「Sansan」のグロースを担う。 X（@m_nishiba） note 多数のビッグプロダクトがローンチから10周年を迎える昨今、技術的負債は多くの開発チームにおいて巨大な課題となっています。積み重なった負債の影響で開発生産性が下がり、返済しようにもリ
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。 さて本題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。本記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。 hackerslab.aktsk.jp ずばりEMを無くして良かったのか これはマクロに見ると明確に良かったと思って
マネージャーの調整力に左右されていた、開発の優先順位 大規模スクラム導入で目指す、組織・チームのありたい姿
「【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれから」で話されたのは、LeSSの導入における背景と工夫。Retty株式会社、株式会社アカツキゲームス、atama plus株式会社が導入の背景と知見を語りました。Retty社・マネージャーの池田氏は、LeSSの導入における同社の取り組みについて発表しました。 Retty社・マネージャー池田直弥氏 池田直弥氏（以下、池田）：トップバッターで緊張していますが、RettyのLeSSの取り組みについてお話しします。 先ほどもご紹介いただきました、Retty株式会社のマネージャーを務めている池田と申します。2021年のちょうど今頃から2022年9月までスクラムマスターをやっていました。2022年10月から新しくマネージャーになったので、「マネージャーです」と名乗るのにまったく慣れていません（笑）。 最初
仕事の基本は関係性の構築から - 私がベトナムメンバーとうまく協働できるようになった秘密 - - Retty Tech Blog
この記事は Retty Advent Calendar 2022 12日目の記事です。 adventar.org Rettyで飲食店向けプロダクトのエンジニアリング部門マネージャーをしている遠藤です。 近年オフショア開発を活用する企業やサービスが増えていますがRettyでも取り入れています。 昨年突如オフショア開発チームとの窓口を任されることになり、右も左も分からない状態の私が四半期ごとの社内表彰式で賞をとるまでに至った苦悩と工夫を紹介していこうと思います。 海外にいるエンジニアチームとうまく仕事を進める方法の参考になれば幸いです。 受発注関係にならずいかに協働できるか 私にオフショア開発チームとの窓口依頼が来たとき、Rettyではすでにオフショア開発を始めた後でした。 海外のアプリ向けと国内の新規事業で取り組んでおり、依頼は当時私が担当していたビジネス側の開発にオフショア開発を取り入れよ
Webサービスの開発チームが担うべき攻めと守りという２つの役割 - BASEプロダクトチームブログ
この記事は2022 BASEアドベントカレンダー1日目の記事です。 こんにちは！開発担当役員のえふしんです。絶賛、来季の組織構造の設計中なので、何を考えながら組織図を検討しているか？ということを書いてみたいと思います！ 組織検討の基本としては、サービスの拡大、組織の拡大に対して仕事のやりやすさ、スピード感を如何に実現しながら事業を伸ばしていくか？というテーマで組織を考えていきます。 組織構造は各社各様のものがあると思いますが、多くの会社さんではビジネスのトップラインを伸ばすチームを主体に、今ある課題をこなしていくチーム構成であることが多いことでしょう。 また、ビジネスの守りを支えるチームもあります。守りの裏返しは攻めと言いますか、何かを守り抜くことで、売上や利益の下支えを行う課題解決については経営課題として上がるため、それ専用のチームが作られたりします。 我々で言うと、決済機能の保守がそれ
webエンジニアの「業務委託単価表」が公開 - Digital Shift Times（デジタル シフト タイムズ） その変革に勇気と希望を
Resource株式会社は、3,000の実績データをもとにwebエンジニアの業務委託単価表を公開したと発表した。 現在の単価が適正単価なのか、次の単価レンジに行くにはどうすれば良いか、開発発注プラットフォーム「ISSUE」の実績を使い調査したとのことだ。 2022年11月ではISSUE上に1,800人以上のユーザーデータと2,000以上の単価診断結果があるという。またISSUEではクラウドソーシング形式で企業とマッチングすることにより、報酬を獲得することができる。その際の契約時給単価を今回の相場作成の参考にしているとのことだ。 ・1,000〜2,000円 インターン・アルバイトレベル。プログラミングを始めたての学生や勉強中の人が対象になる。実務経験としては0〜1年ほどの人が当てはまる。プログラミングの概念を学んでいる段階なので、外部APIなどの公式ドキュメントを理解するのが難しい場合もある
LeSSのルールとヒントが学べる「大規模スクラム Large-Scale Scrum(LeSS)」 の本を読んだ - はんなりと、ゆるやかに
参考：Overview - Large Scale Scrum (LeSS) スクラムをスケールさせる方法を知るため大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法を読みました。 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 発売日: 2019/01/30メディア: 単行本（ソフトカバー） アジャイルをスケールさせるフレームワークはいくつかあってLeSSはその内のひとつです。他にはScaled Agile Framework、Scrum@Scale、Nexusあたりが有名だと思います。 LeSSはスクラムを出来るだけそのまま大規模にしたフレームワークです。5秒でLeSSを説明するなら「スクラムの開発チームが複数になってそれ以外はスクラムのまま」です。なのでプロダクトバック
サーバーサイドエンジニアがフロントエンドに挑戦して最高の経験になった話 - BASEプロダクトチームブログ
⛰ はじめに こんにちは。Owners Marketing所属の 若菜 です。 今回は、普段サーバーサイドエンジニアとしてプロダクト開発に従事している私が、BASEのフロントエンド開発に携わった経験をお話しさせていただきます。 結論、 付加価値がいくつもあった非常に良い経験であった と言えます。 BASEでの働き方や開発組織の雰囲気を少しでも伝えることができましたら幸いです！ 🙋♂️そもそもなぜフロントエンド領域を担当することになったのか 私の所属するOwners Marketingでは、新規ショップオーナーの方によりよくBASEを使ってもらえるための機能改善や、 もっとたくさんの人にBASEを使ってもらえるようにするための機能提供に取り組んでいます。 先日、「オーナーズコミュニティ BASE Street へSSOログインできるようにする」というリリースを行いました。 BASE St
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダイジェスト
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
エンジニア不足が加速する日本｜現状と原因、対処法をくわしく解説 - GALK（ガルク）
「日本のエンジニアは不足しているというけれど本当？ その原因は？」 「わが社でもエンジニアが不足していて困っている、何かよい解決法はないか？」 いまこの記事を読んでいる方は、そのような疑問や悩みを持っているのではないでしょうか？ 「エンジニア不足というのはウソだ」と主張する向きもありますが、実際にデータを見ると確実にエンジニアは不足しています。 2018年時点の調査で22万人、このままいけば最悪の場合は2030年時点で79万人が不足すると予想されているのです。 原因として考えられるのは以下のようなことです。 ・IT市場が急成長している ・技術革新のスピードが速い ・エンジニアの高齢化が進んでいる ・IT業界の労働環境がよくない そして、この解決のために企業がとれる対策としては、以下が挙げられます。 ・エンジニアの待遇を改善する ・社内で人材を育成する ・海外人材を活用する そこでこの記事で
SREのすすめ：アプリケーションエンジニアとプロダクションエンジニアの架け橋になろう
前回の記事はこちら 上の記事で、ご指摘をいただきました。曰く、「問題意識は伝わったが、なぜSRE (Site Reliability Engineer）になったのかという繋がりが理解しにくかった」 読み返してみて、その通りだと思いました 🤦 なので、今日はちょっとそこを深堀りしてみたいと思います。 組織が成長するにつれて、「API設計者」と「API利用者」でデベロッパーのピラミッド構造ができるという話をしました。 つくる人と使う人 今日はもう少し視野を広げてみます。 今自分が見ている地形図 なぜ、直接コア要素の設計側に行けないのか がむしゃらに設計者にまわろうと思ってもパイは少ないです。現在勤めている会社にも Ruby/Railsのコミッターチームや、MySQLの独自実装を行うチームがあります。少数精鋭のチームで、それぞれ何かしら業績があった上で、チームに加わっているイメージです。 AP
エンジニアが LayerX へ人事として入社しました｜serima
昨日から LayerX に人事として入社した serima です！ いままで 10 年ほどサーバサイド・インフラを中心にソフトウェアエンジニアや Engineering Manager として活動してきたので、個人的には割と大きなジョブチェンジかなと思っています。 LayerX では、まずはソフトウェアエンジニアの採用活動に軸足を置きますが、事業成長に必要なことはなんでもやりたいと思っています！ 自己紹介と転職のきっかけかなりサマリですが、高専卒 → 大学編入＆中退 → 位置情報系サービスで学生起業 → ソーシャルゲーム開発・運用 → エンタメコンテンツ、メディアの開発・運用とキャリアを積んできました。 「積んできました」というと聞こえはいいかもしれませんが、改めて振り返ると「球拾いをしてきた人生だった」感があります。 小学生の頃にサッカーをやっていましたが、好んでディフェンダーになりたが
オファー面談時にミッションレターというものをお渡ししている話｜itosho
本記事はコネヒト Advent Calendar 2021の25日目のエントリーになります。 はじめにメリークリスマス🎄 コネヒトという会社でCTOをやっている@itoshoです。 僕がCTOになってから注力していることのひとつにエンジニア採用があります。幸い、ここ数年でエンジニア組織は倍近くの大きさ（12人前後から24人前後の規模）になりました。 採用活動はこれまで様々な試行錯誤を重ねてきたのですが、その中でも今日は特に評判が良いオファー面談時に内定者の方へお渡ししている「ミッションレター」というものを紹介してみたいと思います。 前提このエントリーを読んでくれた方の中で、今後コネヒトの選考受けてくださる方がいるかもしれないので、念のため補足しておきます。 このあと、オファー面談やミッションレターと呼ばれるものの説明を行いますが、あくまで2021年12月時点での内容になります。また、職種
SIerで10年を過ごした基盤エンジニアが感じるSaaS開発組織との文化の違い - エス・エム・エス エンジニア テックブログ
2021年4月にエス・エム・エスに入社した阿部です。現在は介護事業者向け経営支援サービス「カイポケ」の障害福祉サービス事業所向けの機能開発を行っています。まだ入社して半年ではありますが、私がなぜ転職という道を選んだのか、入社して感じた前職との違い、などをお伝えしたいと思います。 現在転職を考えておられる方、エス・エム・エスに興味を持っていただいている方のご参考になれば幸甚です。 転職の契機と企業選択の理由 ここではまず、私がなぜ転職をしたのか、その理由をお話したいと思います。 私は、前職は新卒で日本を代表する大手電機メーカーへ入社し、主に鉄道・上下水・発送電などの社会インフラや、製鐵所、化学プラントなどの制御システムで使用される基盤ソフトウェアの開発を行ってきました。 思えば長いものです。10年というキャリアの中で様々な業務をこなしてきたことで、新卒の頃と比べて自分なりに大きく成長できたと
ドキュメントが更新されない問題 - Konifar's ZATSU
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
【前編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが2015年よりエンジニア組織の内製化に取り組んできたプロセスとそこで得られた反省と学びについてを共有したく、50人超のエンジニア組織で技術責任者を務める田辺に内製化の全貌を聞きました。 1. 簡
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
