書籍「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」が発売された。 まだ読んでいない人がいるなら兎に角オススメなので読んでほしい。 先日も少し話題にした業務委託でお手伝いしている会社、VOYAGE GROUPの主要な各事業を作ってきたエンジニアたちにフォーカスしたインタビュー集だ。 「そーだいさんはVGの人と仲が良いから底上げ評価でしょ？」と思う人がいるかもしれない。 もしあなたがレガシィコードと戦う現場で悩んでいるなら、大小関わらずプロダクトを作り、事業と共に歩む人なら自信を持ってオススメできる。 また今からエンジニアを生業として生きていこうと思っている人たち*1にも自信を持ってオススメできる。 そして、ソフトウェアを軸とした事業を作っていきたい人、関わっているエンジニア以外の人たちもぜひ読んでほしい。 ソフトウェアでサービスを作る際に大事なことが沢山読み
0. 本記事について免責と想定読者本投稿は、浅見個人の意見や信念を多く含む"ポエム"です。必ずしも所属組織を代表する意見ではありません。 また、本記事の想定読者は、データ分析（データ活用）を担当する課に配属された行政職員です。特に専門職採用というわけでもなく、データ分析・モデリングの特別な教育を受けていない読者を想定しています。 あくまで行政職員をイメージしているため、民間企業では適切ではない事例も多いかと思います。ご了承ください。 データ活用の主語についても、あくまで「行政職員」を想定しています。「国民」を主語にしたデータ活用の課題（例えば、神Excel問題や煩雑な紙申請問題など）は本記事ではスコープ外としています。 なお、本記事では「政策」「施策」「事業」について、特に区別を設けず「政策」という言葉で統一しています。 要約1. 最初の一歩 まずメトリクスを定義して、監視する習慣をつけま
負債返済プロジェクトがチームの動き・意識に与えた変化 - CARTA TECH BLOG
こんにちは、こんちゃん(@konchanSS)です。 今回はZucksアドプロダクト事業本部で、2年ほど前からはじまった負債カンバンを作成する動きから 負債返済へのアクションを起こして1年経ったのでそれを振り返ったものです。 負債カンバンとは 負債カンバンとは簡単にいうと、弊事業部にあるさまざまなサービスの負債をまとめたものです。 なぜ始まったかというのはゆっけ(@karahiyo)さんのtech blogを読んでもらえるとよりわかります。 以下、記事から抜粋したものです。 苦手なこと 課題とは認識しつつも対応が進まない、優先順位があがりきらないタスク どこにどんな技術的負債があるか把握しきれていない 気づいたタイミングでの根本的な負債返済の対応は簡単ではない 運用期間が長くなり、当時の最適解が今の最適解と違ってきているものがある 具体的に負債をどのように管理しているかも記事から抜粋したも
はじめに これは Qiita Advent Calendar 2021 D言語カレンダー の 8日目 の記事です。 近年プログラミング言語の1つであるD言語のコミュニティフォーラムで言及されるようになった「精神的摩擦（Mental friction）」という概念について、個人的な考えも交えつつ整理したもの公開しておこうと思います。 ある程度読んでいただくと、以下のような課題に対して改善が図れたり理解が進むのではないかと思います。 プログラミング等で自分の怒りや不満を抑えるポイント、改善に向けた方法論 稀に見るヘイトにあふれた技術記事や日ごろ発生する不満への対処法 プロダクトの価値としてぼやけがちな「心地よさ」の明確化 もちろん話を単純化したうえで予想を多く含むので、怒りや不満の心理を理解したとか言うつもりはまったくありません。全然違うこともあると思います。以下実際のやり取りをまとめたものな
ごあいさつ 記事の対象 記事のモチベーション ジャム当日までの準備 開発PCや実行環境 ノートPCの例 スペックが低い環境の極端な例 マウスを使用する(重要) USBメモリ コントローラ XInput形式のものを持ち込む 年季の入ったコントローラや自作のアーケードコントローラ やってみたいことの妄想 ジャム当日：アイデア出し ワードマップから始める アイデアの大枠が決定した時、UE4のテンプレートが使えそうか考える ToDoリストを作成する ジャム当日：最初にやること バージョン管理システム(VCS)を決める？ VCSを使用せずにUSBメモリを使用する VCSを使用する場合 Content直下にゲームジャム用のフォルダを作成する 各々の名前のフォルダで作業する 外部デバイスや使用したいコードのプラグインがある場合は、C++プロジェクトを作成する UE4Duino：Arduinoとのシリアル
Railsのテンプレートエンジンを、slimやhamlから、erbに戻して乗り換えた話 - ITANDI Engineer Blog
はじめに OHEYAGOの開発をしている田渕です！ Railsのテンプレートエンジンには、デフォルトのerbや、代替のslimやhamlなどがあります。 OHEYAGOではslimを採用していましたが、先日、テンプレートエンジンをslimからデフォルトのerbに変更しました。 細かい理由は後述しますが、OHEYAGOチーム内ではslimが技術的負債になっているという結論が出たからです。 また、自分が以前開発していた別のシステムでも、テンプレートエンジンをhamlからerbに変更したことがあります。 こちらも同様にhamlを負債だと考えたからです。 slimやhamlで開発しにくいという話はたまに聞きますが、実際にslimやhamlを削除するという話はネット上の記事でも殆ど見たことがないため、修正した方法を紹介します！ 技術選定の理由 slimやhamlのメリットとデメリットを考えます。まず
しくじり先生のように学ぶ「NFS+sqliteで苦労した話から学ぶ、問題解決の考え方」という勉強会をやってみました | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 インフラLinux勉強会SQLiteNFS こんにちは、羽山です。 今回は社内で実施した勉強会をほぼそのままブログ記事にしています。 ITエンジニアたるものドキュメントを残したり勉強会を実施したり分かりやすい設計にリファクタリングしたりなど、日々 知見の伝達 を意識していると思います。主要な知見はたいていそれらの方法で満たせるのですが、しかし残念ながら中には画一的な方法では伝えにくいものもあったりします。 ところで伝統芸能や工芸の世界では技術の継承において 背中を見て学ぶ という方法が用いられることがあるようです。 これと似た手法はITエンジニアの世界にもあって、先輩エンジニアとペアプログラミングをすることで文書では伝わりにくい技術や考え方・テクニックを学ぶ
![しくじり先生のように学ぶ「NFS+sqliteで苦労した話から学ぶ、問題解決の考え方」という勉強会をやってみました | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/9477296f61e752f8b6816cb517cdb9166a028f2c/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F10%2Fscience_hakase_shippai_s.png)
ペアプロを極めて最強の開発チームをつくる（1/4）ペアの組み方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: On Pair Programming 原文公開日: 2020/01/15 著者: Birgitta Böckeler -- ドイツのThoughtWorks社で開発とコンサルティングを担当しています。カスタムソフトウェアチームのテックリードとして日々を「コーディングの日」「コーチングの日」「コンサルティングの日」「仕事を楽しく続ける日」に分けています。 著者: Nina Siessegger -- ドイツのハンブルグ出身の開発者/テックリード/コンサルタント。元ThoughtWorks。コーディングの楽しさ以外に、特にソフトウェア開発の人間的な側面にも強い関心を抱き、高品質ソフトウェアは「コミュニケーション」「共同作業」「信頼関係」を重んじるチームによって成し遂げられると強く信じています。 サイト: martinfowler.c
モノリシックなアプリケーションを疎結合にする取り組み - 弁護士ドットコム株式会社 Creators’ blog
こんにちは。弁護士ドットコム クラウドサイン事業本部 Product Engineering 部の須山と申します。CloudSign はサービスを開始してから約 7 年が経過しています。その間数多くの機能追加・拡張を続けている中で技術的な負債を残していくことは、どの企業でもよくある話ではないでしょうか。そんな中 CloudSign では技術的負債を解消することを主な目的としたチームを 2 年程前から結成して、日々改善活動を進めています（それ以外にも、新機能の技術検証や基盤開発も担当しています） 今回はチーム発足時から活動しているモノリシックアプリケーションの分割に関してやってきたことをまとめました。これまでの活動を大きく 3 つの段階に分けて紹介します。 その1. モノリシックなアプリケーションの分割 ローカル環境とそれ以外の環境での差異 アプリケーションを実行環境ごとに分割 アプリケーシ
開発責任者がやるべきことの気づきと"Think Like a CTO" - クラウドワークス エンジニアブログ
1年をふりかえる 年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長の@hihatsです。 本記事はクラウドワークスAdvent Calendar 2023 シリーズ2の25日目の記事です。 今回は、プロダクト開発部として今年取り組んできたことと、その中での気づき、「Think Like a CTO」という書籍の話にも触れていきます。 今年やってきたこと 技術的負債解消への取り組み 昨年のアドベントカレンダーでも書きましたが、2023年も技術的負債の解消に取り組んで参りました。 結果としては、フロントエンドでの注力の割合が大きかった一年でした。詳しくは@okuto_oyamaさんの1日目の記事をご覧ください。 記事にもありますが、Vue.js化をフロントエンドを触る全チームが行える体制に整えることで加速させてい
こんにちは､びしょ～じょです｡ メモリアルなんでなんか書こうかなと思いました｡ プログラミングをはじめて10年目になる プログラミングの旅は、大学に入ってから始まった。入学直前にDxRubyに触れ、forループを使って「hello」を出力しまくったのが、おそらく最初の経験であったと思う。大学時代、学部2年にはLinuxConに参加するなどしていたが、結局は言語系の道に進んだ。本格的にプログラミング言語自体に興味を持ち始めたのは、1年生と2年生の終わり頃にLuaでZコンビネータを書いたときだった。 それ以降、プログラミングとともに歩む日々が続いている。大学在籍中には、様々なプログラムを作成し、友人や先生からの評価も得ていた。また、自身のスキルアップのために、オンラインでの情報収集や書籍を読み漁ることも欠かさなかった。卒業後、初めて入った会社では、これまでの学びを活かし、新しいプロジェクトに取
こんにちは、リファクタリング大好きなミノ駆動です。 2021年4月にREADYFOR株式会社にジョインしました。 概要 本記事は、なぜ私がREADYFORへのジョインを決断したのか、背景理由を記したエントリ記事です。 READYFORはサービス開始から約10年が経過。システムに相当な技術的負債が蓄積しているため、今後スピーディーにサービス拡大するためには負債解消が目下取り組むべき重要課題となっております。その課題解決のために私は誘われたわけですが、リファクタリングが十分に効果を発揮するには、設計技術面以外の様々なハードルを乗り越えなければなりません。 READYFORの組織ビジョン「乳化」が、ハードルを解消し、リファクタリング効果の大きな促進に貢献すると考えたため、ジョインを決断しました。 本記事では、技術的負債やリファクタリングにまつわる一般的な問題構造を解説した上で、READYFORが
正確には「株式会社グロービスにエンジニアとして入社して3ヶ月が経ちました」です。 晴れて試用期間が満了したことと、同日の4月1日に入社して同じチームで働いている @mktakuya が入社エントリを書いたので後に続こうというお気持ちです。 blog.m6a.jp あと、つよつよエンジニアの転職エントリはそこらに転がっているけど、そうではないエンジニアの転職エントリも僕は読みたいなと思ったので自分で書くことにしました。 で、誰？ @shifumin 新卒で地元のジャパニーズトラディショナルローカルガバメント(notエンジニア) -> 小さなWeb系受託開発会社 -> グロービス Railsエンジニア 主にAPIを作ったりデータモデリング周りを触っていた グロービスに入社してReactも触り始めた グロービスという会社 recruiting-tech.globis.co.jp グロービス
はじめに 2020年2月14日に開催されたDevelopers Summit2020に参加してきました。 event.shoeisha.jp テーマ 【14-B-4】プロダクトを10年運用するチームをつくる カテゴリ エンジニア組織 登壇者 粕谷 大輔さん [はてな] @daiksy はてな 2012年入社 KPTとは かすや ぱねえ 天才www Mackerelチームディレクター 認定スクラムマスター Mackerelとは サーバ監視をSaaSで行っている 発表資料 speakerdeck.com 講演メモ 変化し続ける周辺環境とSystem プロダクトを10年安定稼働させる極意とは？ 昔はCloudなんてなかった。基幹システムなどがメイン 当時の格言 動いているシステムはさわるな 10年触らないことが極意？ 今日のセミナーは、完wwww 周辺環境の変化が激しい OSのメジャーアップデー
この記事は トレタ Advent Calendar 2019 12日目*1の記事です。 こんにちは。最近、子供に荷物に買い物かばんにとリアルポーターごっこに腰がつらくなってきた@joy04dです。 前回のAdvent Calendarでこんな事を書いていた自分ですが、その後、今年1月から VP of Engineering の役割を頂いております。まだ1年足らずのひよっこですが、日々頑張ってお仕事しております(=ω=) 今回の記事では、せっかくなのでこの1年の振り返りと知見(あるいはアンチパターン)の共有を兼ねて、つらつらと*2書いてみたいと思います。 どんなことしたか 今年のコンセプトを一言でいうと 個からチームへ になります。 トレタの開発組織では、創業期から 自治 をコンセプトとしており、フラットな組織のなかでエンジニアそれぞれが自身の裁量と責任を持って行動することを大事にしていまし
セキュアで信頼性のあるシステム構築
システムのセキュリティと信頼性は表裏一体です。セキュリティは、プロダクトの品質、パフォーマンス、可用性と密接にかかわるため、スケーラブルなシステムの設計と運用にとって極めて重要です。本書は、GoogleのセキュリティとSREのエキスパートが、根本からセキュアで、スケーラブルかつ信頼性の高いシステムを設計するためのベストプラクティスを紹介します。 既刊書『SRE サイトリライアビリティエンジニアリング』と『サイトリライアビリティワークブック』は、企業がソフトウェアシステムをスムーズに構築、デプロイ、監視、保守するうえで、サービスライフサイクル全体への取り組みが重要な理由とその方法を解説しました。本書では、システムの設計、実装、保守に関する考え方と実践法を解説します。また、ベストプラクティスに取り組むために必要となる組織の文化についても説明します。 本書への推薦の言葉 Royal Hansen
こんにちは、Product Securityチームの@gloriaです。前回は、昨年のAdvent Calendarイベントでセキュリティテストについて記事を書きました。 今回は、メルカリSecurity TeamのSecurity Tech Blogシリーズの一本目として脅威モデリングについて紹介したいと思います。脅威モデリングの基礎、なぜ脅威モデリングがセキュア開発ライフサイクル（SDLC）に必要なのか、メルカリの脅威モデリングプロセスについて説明したいと思います。 脅威モデリングとは？ 脅威モデリングは、システムを分析してセキュリティの脆弱性を洗い出す活動です。つまり、システムやアプリケーションの設計を深く分析し、実装前に先手を打って、起こり得る脆弱性を見つけることです。攻撃者をシステムに一歩も踏ませないので、プロアクティブ・セキュリティの一つの手段だと言われます。 プロアクティブ・
ダブルメンテ状態は、なんとしても避けたかった ーーフルリプレイスに対して、社内で反対はなかったんですか？ 戸井田裕貴氏（以下、戸井田）：土日の48時間を使ってバシッと移行しきるのは、けっこうリスクがあるという雰囲気は出ていましたね。僕は絶対にやりたかったので、そこは話し合いました。 ーーそれをどう説得したのですか。 戸井田：新・旧システムのダブルメンテ状態は、なんとしても避けたかったんですよね。なんでかというと、営業はまずプロダクトを売っているから、両方を理解しなきゃいけないじゃないですか。新・旧で思想や使い勝手がぜんぜん違うし、しかも開発のスピードとかも変わってくるんですよね。こちらは速いけどこちらは遅いみたいな。 そんなことをしたら、営業もCSも辛いと思うんですよ。両方使うお客さんとかが出たら、さらに辛いと思うんです。どちらにしても、両方理解して売っていく状態になる。もう大変だし、開発
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。プレゼンテーション「技術で創る事業成長」に登壇したのは、Sansan株式会社CTOの藤倉成太氏。 Sansanのミッションとプロダクト 藤倉成太氏：よろしくお願いいたします。Sansan株式会社でCTOをしています、藤倉と申します。 自己紹介ですけど、別にあまり深く読んでいただく必要はないかなと思いますので、適当に流してください。 これもちょっと会社のミッションに触れておこうかなと思って用意しただけなんですけど、ちなみにSansanという会社を知っている方ってどれくらい
この記事は個人開発Advent Calendar 2022 1日目の記事です。 2022年6月13日、私が個人開発でリリースしたサービス「テストメーカー」がTwitterで2,000RT、7,600いいね以上の大バズリを記録しました。 「テストメーカー」は穴埋めテストを直感的に作れるツールです。 マウスで穴埋めにしたいテキストを選択して離すと、その部分が穴埋め問題に変わります。 リリース以降、主に全国各地の中学校、高校、大学などの授業で使っていただいたりしながらユーザー数が増えています。 他にも、社会人の方が国家資格を受験するときの受験勉強に使っていただいていることもあります。 ITMediaさんに取材も受けました。 そして、リリースからおよそ1ヶ月が経過した7月に課金機能を実装し、そこから少しずつですが課金してくださるユーザーさんも増え続けています。 本記事では、そんなテストメーカーを支
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「アジャイル開発は世界を変える夢を見るか 」をテーマに株式会社レッドジャーニーの市谷氏が登壇。まずは、チーム・組織の「もやみ」と闇落ちについて話します。 レッドジャーニーの市谷氏 市谷聡啓氏：みなさんこんばんは。金曜日のこんな遅い時間まで、お疲れかと思います。私も疲れていますが、この話をするまで6月が終われないので、よろしくお願いします。 あらためて、市谷と申します。レッドジャーニーという会社を立ち上げて、世の中のDXを進めたい企業に寄り添いながら支援している者です。DXといっても、新しい事業を作ったりプロダクトを作ったり、人材教育など、そこにはいろいろな中身があります。企業の状況や狙いどころに応じて、一緒に取り組んでいます。 今日のテーマであるアジャイル開発は、これととも
おはようございますこんにちはこんばんは。ROUTE06 取締役 CTO の重岡です。 創業 4 年目に突入した今年の 1 月に Tech blog を開設し、四半期を経て、私もようやく記事を執筆することができました。記事のネタを社内のエンジニアに相談したところ、 Q) 私も Tech blog 記事を書こうと思ってるので、どんな内容がよさそうか相談させてください 💭 A) ”マネーフォワード CTO が考えていること”を社外向けに公開しているのは良さそうだなーと思ってました 👀 という有益なアドバイスを頂きまして、真似して実践してみることにしました。 昨年 2022 年 11 月、CTO 就任時に考えていたことは ROUTE06 の取締役 CTO に就任しました の記事にてご紹介させていただきました。 本記事では CTO 就任後、5 ヶ月を経ての振り返りと、今考えてることについてご紹介
ゲームエンジンを自作しながら思ったこと - Qiita
本稿では、私が長く続けている個人でのゲームエンジン開発で得られた知識や経験を紹介します。 嘘ですポエムです。アルコールとか入ってます。 本当はかっこいいこと言ってみんなの役に立つこと書きたかったです。書きたかったけど無理だったよ…。 ひとつのゲームエンジンを作り続けてもう何年も経ちます。その間コンセプトも定められず満足なメジャーリリースもできないままだらだら作り続けてしまったので、あんまり役に立つことは書けなさそう。 とりあえず昨今のゲームエンジンの開発に必要な技術要素と、私が開発している Lumino というゲームエンジンでの代表的な実装例を紹介する、みたいな体で書いてみようと思います。なにか間違ってそうでしたらコメントお願いします。 多分、ちょっとでも役に立つかもしれないのは、「ゲーム作ってたけど気が付いたらゲームエンジン作ってて、ゲームが出来てないけどゲームエンジン公開してみたくなっ
サービス間連携のためのGraphQL APIをClojureで開発している話 - Opt Technologies Magazine
社内共有のマスタデータ基盤としてのGraphQL APIをプログラミング言語Clojureで開発している事例をご紹介します。 あいさつ 新規API開発の背景 現行システムの問題点: 共有データベース 解決策: データベースをラップするサービス 技術選定の経緯 API方式: GraphQL メイン開発言語: Clojure アプリケーションのアーキテクチャ設計 The Clean Architecture コードの全体像 resolver use case entity boundary 主な要素技術 アプリケーション構成の整理とライフサイクル管理: Duct GraphQL APIサーバ: Lacinia + Pedestal 入力バリデーション: malli DBアクセス: clojure.java.jdbc + Honey SQL テストとカバレッジ計測: clojure.test +
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
アジャイル開発における品質の考え方 - Mirai Translate TECH BLOG
こんにちは。プラットフォーム開発部 EMのchikaです。 先月、アジャイル開発におけるQAの考え方 という記事を投稿しました。 miraitranslate-tech.hatenablog.jp 今回は、その中で触れられなかった、品質ってなんだっけ？アジャイル開発では品質って今までと同じ考え方でいいの？ということ考えたときに調べたことなどを紹介しようと思います。 品質って、何ですか？ 品質の定義・分類のモデル ソフトウェア品質特性の８分類（ISO/IEC 25010:2011） 外部品質、内部品質 狩野モデル （参考文献） プロダクト開発のときに品質モデルが教えてくれること 統計的品質管理における品質の代用特性 アジャイル開発における品質の代用特性 品質とスピードはトレードオフなのか？ 品質は保証できるものなのか？ まとめ 参考 We are hiring! 品質って、何ですか？ 「この
成功する実践的モブプログラミング
※Qiitaで書いた記事を移動したものです。なお JTF2020 で発表したときのスライドは https://speakerdeck.com/erukiti/mob-programming-practice です。 モブプログラミング（以下モブプロ）とは、複数人で一つの成果物（プログラムコード）を生み出すという、チーム作業のテクニックです。似たテクニックにペアプログラミングがありますが、モブプロは3人以上（4〜5人を推奨）でやるものであり、また、目的や効果も全く違うものです。 モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するというチーム戦 です。これ最重要なので、あとで何回も登場します！ この記事には「成功する実践的モブプログラミング」というタイトルを付けています。ここでいう成功の定義は、モブプロが実際に効率よく実践できることとします。モブプロに関する記事・情報は「イ
estie VPoEの青木です。 前回の記事では、「ハリネズミを飼おうかと検討しています」と書いたのですが、晴れて生後2ヶ月のハリネズミを家に迎えました。 世話の仕方に苦戦しながら（慣れるまでなかなか針を立てずに持たせてもらえない...）楽しい日々を過ごしています。 データドリブンな意思決定を支援する社内データ分析基盤 - estie inside blog さて、今日は”estie”（オフィス探しプラットフォーム）開発チームの開発手法の歩みについて、これまでの経験を書きます。 まだまだ改善したいことがたくさんあり文章に残すのも恥ずかしいなと感じますが、ここまで開発チームとして、事業にどれだけ高速に貢献するかを考えて試行錯誤してきたそのプロセスが、この記事を読んでいる方の少しでも参考となればと思います。 そもそもestieって何しているの？ estie pro estie 開発したいことが
Merpay Advent Calendar 2019 の８日目は、メルペイ backend payment platform チーム の @knsh14 がお送りします。 はじめに 私はメルペイでお客様の残高を管理しているマイクロサービス(以下Balance Service)の開発を担当しています。 Balance Serviceは次のような定常的に動かしているバッチがあります。 有効期限があるポイントの失効処理 会計データの突合 毎日知りたいデータのレポート Balance Serviceではメルペイリリースに向けて限られたスケジュールの中で開発を進めていました。 サービスとしての実装を優先して開発をしていたため、まずはテストのカバレッジを挙げて動作を担保する方針をとっていました。 結果としてリリースから今まで大きな事故もなく運用できています。 ですが、1日目の記事にもあるように7月か
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。続いては、組織における技術的負債の返済のための現場と意思決定層のアクションについて。前回の記事はこちらから。 技術的負債の現場視点のアクション 原トリ氏（以下、原）：では、ここからは技術的負債の返済inアクションという感じで、まずは現場視点での返済の進め方について、ちょっと見ていきましょう。現場視点の整理が済んだら、次は意思決定層の視点です。 まず一般的に、技術的負債の返済の提案や実行は、現場の立場から行われることが多いです。いわゆるボトムアップと呼ばれるものです。日々開発をして、運用している人たちです。理由は明確で、その技術的負債によって生産性低下の悪影響を直接的にモロに受ける立
サービス運用10年以上の重み、弁護士ドットコムのユニットテスト速度改善 - 弁護士ドットコム株式会社 Creators’ blog
初めまして、弁護士ドットコムでエンジニアをやっている @namizatork です。 第1回目で @komtaki さんが書いた 「弁護士ドットコムサービスのビジネスと共にみるマイクロサービスの進化」 がプチバズりしていたので第2回目となる今回、少し 滑らないか 心配ですが頑張って書きます。 本記事では、サービス開始から10年以上が経過したサービスのユニットテストを改善したという内容をお話しします。 ユニットテスト改善チームの立ち上げ 改善前に必要なことを明確化 キックオフ ユニットテストを並列実行する GitLab parallel 時間の掛かっているユニットテストを特定する 実行方法 テストが遅い原因を特定&解決 (1) 多くのループ処理やスリープ処理を利用している (2) 誤ったsetUpやtearDownの使い方をしている (3) DBに依存しており、アクセスに時間が掛かっている
プロダクト思考で開発が進む「みてね」の今とこれから～みてねの生みの親笠原健治氏、開発マネージャ酒井篤氏が考える、プロダクトとエンジニアリングの素敵な関係 リリースから5年が経ち、800万ユーザを超えた家族向け写真・動画共有アプリ「家族アルバム みてね」。 今回、プロダクトの生みの親でもありプロダクトオーナー、そして、株式会社ミクシィ取締役会長笠原健治氏、みてね開発マネージャ酒井篤氏に、みてねを支えるエンジニアリングについて、開発に関する体制やプロダクトの開発・運用、さらにこれからのみてねのビジョンについて伺いました。 株式会社ミクシィ取締役会長笠原健治氏（左）、みてね開発マネージャ酒井篤氏（右） みてね誕生の背景 ――リリースから5年が経ち、ユーザ数も着実に増えていると聞きます。ここで、改めて、みてね誕生の背景について教えてください。 笠原： 最初のきっかけは自分に子どもが生まれた
品質を測定するとは？ 技術的負債、という言葉を知っていますか？ 技術的負債とは、“何らかの理由により、必ずしも最善とは言えないが、実現が容易な手法を選択した結果生じる、将来の追加コスト” のことです。コード品質の世界にも技術的負債はあります。例を挙げれば、“納期に追われて安易にコードをコピペしちゃう”、とかですね。その場は切り抜けられるかもしれませんが、そのコピペに関連する様々な不具合を将来にわたって負債として引き受けることになります。 さて、この負債。負ってしまったらどうしましょう？ 真面目な方はすぐ返済したくなるかもしれませんが、負債の大きさが許容範囲内であれば、とりあえず利息だけ払って借り続けるという選択もありえます。コード品質の負債も、無理にコードを直して返済しない方がよいことがあります。コードを直すのにも費用がかかるので、開発予算や開発スコープなどと天秤にかけると、そのままにして
こんにちは、プロダクトエンジニアリング部の鈴木です。 私達のチームでは、リファクタDaysの取り組みとして、APIサーバのテストコード（RSpec）のリファクタリングを行いました。 このリファクタリングにより、テストコードの記述量が大幅に削減され、数年間利用してきたAPIコントローラのテストコードを作業時間にして2週間程度で移行できました。 この記事では、どのようにしてチームでRSpecを改善したのか全体像をお伝えします。 APIサーバが抱えるテスト実装の課題 主な改善内容 ディレクトリ構成を整備・統一する テストの雛形を自動生成する モック・スタブ化をVCRで自動化する テストコードの期待値も自動で作る テストコードから実装の振る舞い以外を追い出す チームでの改善の進め方 まとめ APIサーバが抱えるテスト実装の課題 私達のチームが管理しているサービスでは、バックエンド（APIサーバ）が
はじめに みなさんこんにちは、物流業界の価値最大化をミッションに掲げるアセンド株式会社で取締役CTOを務めている丹羽です。 今回はアセンドの Full TypeScript Architecture の選定背景とその構成を紹介します。 アセンドでは社会課題である物流危機の中心にいる運送会社に対し、課題解決の第一歩として業務と経営のデジタル化を実現する All-in-One な運送管理SaaS「ロジックス」を開発しています。アセンドは12月06日にプレスリリースをした通りシリーズAの資金調達し、無事にプロダクトとして PMF (Product Market Fit) を一定達成したと言えます。 ３年前に開発をスタートしたロジックスはフロントエンド、バックエンド、クラウドのIaCに至るすべてを TypeScript で開発することを選択しました。振り返ってみても FullTS でなければ PM
「動けば別に良くない？」という新人エンジニア はい。２年前私ですね。 転職用のポートフォリオである食事管理アプリを完成させた私はダニング＝クルーガー効果によりイキリ散らかし、 その４ヶ月後に大変苦労したのを覚えています。 前回、 良い質問をして自己成長に繋げるためのあれこれ という記事を書きましたが、それに並んで若年エンジニアの悩みの種シリーズです。 ヒーヒー言いながら動くコードは何とか描けるようになってきた。 「けど、どこに何書いていいかわからへん」という悩みは誰もが経験するのではないでしょうか。 コードレビューの際に「その処理はこっちに書きましょうか。」とか言われるけれどなかなか、しっくりこず。 設計について勉強してみるように勧められても、何から手をつけていいのかわからなかったのを覚えています。 何となくやらないといけないのはわかるけど、「何故やどうして」がはっきりしないので, モヤモ
週刊Railsウォッチ（20201208前編）レガシーRailsアプリを引き継ぐときの6つの作業、サーバーレスプロジェクトをRailsに移行ほか｜TechRacho by BPS株式会社
2020.12.08 週刊Railsウォッチ（20201208前編）レガシーRailsアプリを引き継ぐときの6つの作業、サーバーレスプロジェクトをRailsに移行ほか こんにちは、hachi8833です。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙇 今回は、BPS昼の定例勉強会でつっつき会を行いました。 ⚓Rails: 先週の改修（Rails公式ニュースより） 公式の更新情報から見繕いました。 元記事: New Active Record and Action View capabilities, bug fixes and mo
みなさんこんにちは。SmartHRのプロダクトマネージャー @ryopenguinです。 この記事ではプロダクトビジョンをどのように決め、活用しているか、私のチームの実践についてお伝えします。これからプロダクトビジョンを設定する方のヒントになれば幸いです。 なお、この記事は「KPIを追いかけていたらプロダクトビジョンにたどり着いた話」の続編にあたります。前編もご覧いただくとより理解が深まるかと思います。 プロダクトの状況 最初に「従業員サーベイ」の状況について簡単にご説明します。 「従業員サーベイ」は、従業員に対してアンケートを送付し、その結果とSmartHR内に蓄積された従業員情報をかけ合わせて分析できるプロダクトです。立ち上げ当初から急速に売り上げが成長していたのですが、休眠ユーザーが多いという課題がありました。 2021年は休眠ユーザー回復のためにさまざまな施策を実施しました。しかし
【セッションレポート】機械学習の技術的負債を SageMaker Studio で解消 #AWSSummit | DevelopersIO
はじめに AWS Summit Tokyo に参加しました！ 2日目 AWS-30 「機械学習の技術的負債を SageMaker Studio で解消」のセッションレポートを投稿いたします。 セッション視聴 AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。） 登録済みの場合、以下から直接遷移できます。 https://jpsummit.awsevents.com/public/session/view/549 セッション概要 機械学習プロジェクトでは、コーディング作業以外にも対応すべき作業が数多く存在します。 例えば、データの前処理や特徴量抽出から、高スペックな開発環境の運用やデプロイ後の性能監視等々が挙げられます。これらは開発者に技術的負債となって 伸し掛かり、プロジェクトの進捗や難易度に負の影響を齎すことが考えら
この記事は株式会社ビットキー Advent Calendar 2022 25日目の記事です。 VPoEの山本が担当します。 みなさんメリークリスマス！ これは何か 現在私はビットキーにおいて「VPoE」という肩書きで活動しています。創業期のスタートアップである当社において、実質的にエンジニアリングを牽引する立場であり、一般的には「CTO」と呼ばれる責務で行動してきたと今は思っています。 なので今日この場ではあえて「創業期のCTO」として記載します。 私の当社でのこうした活動は5年近くになり、今改めて振り返り、私のような役割の方/これからそのような役割を期待される方に、リアルな実体験とたった一つのアドバイスをお伝えしたいと思います。 対象読者 創業期のCTO = 創業初期の開発チームを牽引する役割の方、あるいはそうなりたい方 なんらかのモノづくりで起業を志されている方 開発行為にこれまであま
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
事業を作る人達の物語が最高だった #voyagebook - そーだいなるらくがき帳
行政職員のためのデータ活用一歩前｜METI-DX 経済産業省DXオフィス
プログラミングにおける精神的摩擦（Mental friction）と向き合い方
ゲームジャムでUnreal Engine 4を使ってみよう - SEGA TECH Blog
すまん､他社行くわ (ボツ案: プログラミングを始めて10年目になるし､新卒で入った会社もやめて転職する)
リファクタリング効果を促進する組織ビジョン「乳化」 - READYFOR Tech Blog
株式会社グロービスに入社しました - しふみんのブログ
【デブサミ2020レポート】プロダクトを10年運用するチームをつくる #devsumiB - 紙一重の積み重ね
トレタ開発組織振り返り 2019年版 - トレタ開発者ブログ
メルカリの脅威モデリングプロセス | メルカリエンジニアリング
ダブルメンテ状態は、Hacobuにとっては“死” 「フルリプレイス」をやり遂げるためにCTOが決断したこと
SansanCTOが語る、事業成長と共に考える技術的負債の“返済計画”
【個人開発】2000RT超えの大バズリ〜初課金まで至った穴埋めテストメーカーを支える技術
可もなく不可もないチーム・組織は“闇落ち”する可能性がある 引き金を引く5つの感覚と、日本の組織が持つ判断基準の問題
ROUTE06 CTOが考えていること（2023年4月） - ROUTE06 Tech Blog
リファクタリングを避けるコードデザイン(Railsを題材として)
estieの開発手法の歩みを赤裸々に語ってみた - estie inside blog
バッチコマンドをテストしやすいようにリファクタリングする | メルカリエンジニアリング
重要なのは経営層の視点と現場の課題をつなぐこと 技術的負債の返済に向けた現場の説明責任
プロダクト思考で開発が進む「みてね」の今とこれから～みてねの生みの親笠原健治氏、開発マネージャ酒井篤氏が考える、プロダクトとエンジニアリングの素敵な関係 | gihyo.jp
どうやってコード品質を測るのか？ ソースコード品質の測定指標とその活用
RSpecの技術的負債をチームで解消した話 - LIFULL Creators Blog
PMF達成の立役者！Full TypeScript Architecture の選定背景と構成
『動けば別に良くない？』と言っていた二年前の自分にシステム設計の話をしてみる - Qiita
プロダクトビジョンを決め、活用するまでの長い道のり - SmartHR Tech Blog
創業期の「CTO」に贈るたった一つのアドバイス - Qiita