技術のトレンドと開発テクニックの知見を、無料で公開します！ いかに無駄な努力をせず、効果的にトレンドに沿ったアプリ開発ができるかを研究してきました。 この記事は、定期的にトレンドに沿って更新していこうと思います。 twitterもやってます！ 今後も情報発信しようと思うので、フォローお願いします！ https://twitter.com/joer_sbt 自分が一番知見のある、フロントエンドの分野中心に見解を述べたいと思います。 結論から言うと、 React, Next.js, Typescript, Tailwind, react-query, prettier, Stylelint, auth0, tRPC, Prisma, playwright, vscode, github actions, PostgreSQL, Terraform, Flutter これらの技術スタックが今後ま
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。公開Q&Aには、メドピア株式会社執行役員のCTO福村彰展氏と、Sansan株式会社CTOの藤倉成太氏が登場。会場からの質問に回答します。 技術的負債を返す重要性をどう説明するか 司会者：お待たせしました。Q＆Aなんですけど、最初に、みなさん申し込みいただいたときに質問をいくつかいただいていたと思うので、そのなかで質問が多かったものを私のほうで5つぐらい取り上げさせていただいております。そのあと、会場のみなさんから質問を募集して、ディスカッションのようなかたちで進められれ
日本CTO協会ではオープンな議論を推進するため、GitHub 上で各種提言を公開しております。リポジトリはhttps://github.com/cto-a/policy-proposal 2020-10-09 17:02 追記 本稿は一般社団法人日本CTO協会理事一同による提言です。至らないところが多々あると思います。誤字脱字はもちろん、異論・他の論点・課題などをGitHub上のIssue等オープンな場でご指摘いただけますとありがたいです。これら提言により広範な議論がおこり国民的な関心が高まることを期待しています。 本提言の文責・主体 本提言は下記、日本CTO協会理事一同により作成され提言するものとなります。 CTO協会理事 松岡 剛志 代表理事小野 和俊 理事栗林 健太郎 理事小賀 昌法 理事竹内 真 理事名村 卓 理事広木 大地 理事藤本 真樹 理事藤門 千明 理事松本 勇気 理事
組織の話をしていて、何故、エンジニアの上司はエンジニアである必要があるのか？ CTOはいるがCDOがいない会社は多い。マーケティングという専門職の上司が永遠にマーケティングというわけでもない。もちろんCMOもいるだろうが、CTOに比べて常識化しているわけではない。 CTOがいる企業は増えているが、製造業の歴史的に成功した大企業がCTOがいるわけではない。 ただのエンジニアのワガママやエゴなんじゃないか？と思うことも多々ある。だから、たまに迷いが生じる。もちろん採用市場における業界の常識というのがあるので、それを無碍に無視するわけでもない。 いずれにせよ何故、エンジニアの上司はエンジニアであるべきなのか？ということを言語化できることが重要だ。 ー・ー いろいろ考えた末に、僕が一つたどり着いたものは、 ・いわゆる組織図ツリーは、ビジネスを実現するための組織図である。ビジネスが第一義になるので、
昨年、テスト駆動開発のエバンジェリストである和田卓人(t-wada)さんと共同で、社内で2回のレガシーコード改善ワークショップを開催しました。概要については、以下の記事に詳しく書かれています。 このワークショップの最大の特徴は、実際の製品のソースコードを対象に自動テストの作成やリファクタリングを行うことです。 題材となるコードを探す作業から始めるため、準備には手間がかかりますが、開発チームがレガシーコードに向き合うスキル・マインドを育成するために非常に有効な手法だと感じています。このため、今年も他の製品開発チームを対象に同様のワークショップを計画しています。 この記事では、今後の開催に向けてこれまで運営として取り組んできたことをまとめ、「レガシーコード改善ワークショップの良いところ」と「ワークショップ開催の具体的な流れ」として説明します。 レガシーコード改善ワークショップの良いところ 参加
VPoEの湯前（@yunon_phys）です。3月にカケハシにジョインし、あっという間に4ヶ月。ゼロイチの事業立ち上げに寄与するエンジニアリングチームのマネージャとして、おかげさまで（本当に）楽しい日々を過ごすことができています。 今回は社内外の方々への自己紹介にかえて、エンジニアのキャリアや仕事観について、カケハシ入社前後に考えていたことをまとめてみることにしました。カケハシの技術組織を、どのような方向に成長させていきたいのか。自分自身のミッションにもつながる内容になると思います。エンジニアはもちろんですが、職種を問わずぜひいろいろな方にご一読いただけると嬉しいです。 カケハシの湯前としては、先日開催された日本CTO協会のイベントでもお話ししていますので、あわせてご覧ください。 技術や待遇、職場環境だけじゃない、もっと大事なことさて、「働きたくなる会社」についてです。組織マネジメントにお
IE11 サポート終了の歴史 | blog.jxck.io
Intro IE11 が役目を終えていく流れを記録として残す。特に MS からのアナウンスや、それに準じた各サービスの反応、特に IE サポート終了アナウンスをまとめることで、 IE11 というブラウザがどのように終了していったのかのを記録することを目的とする。 もともとは Google Docs にまとめていたものである。 日付はアナウンスの公開日 サポート終了日ではない サポート終了日も書いておけばよかったけど今からやり直す気力はない、、 赤字 は MS 関連もしくはサポート終了の影響が大きそうなアナウンス Windows における IE11 自体のサポート終了については以下を参照 https://www.atmarkit.co.jp/ait/articles/1503/11/news134.html できればある程度の結論が出るまでこのエントリを更新していきたい 追加リクエスト 本エ
こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ
技術的負債で悩む人たちを救いたい。苦渋を味わったシステム設計から私が逃げ出さない理由 - Findy Engineer Lab
READYFORでアプリケーションアーキテクトを務め、システム設計やリファクタリングについて第一線で発信をする仙塲大也さん。ネット上ではミノ駆動（@MinoDriven）の名前で活動しています。 著書の『良いコード／悪いコードで学ぶ設計入門』は、2022年4月の発売から10カ月で3万部を超え、「ITエンジニア本大賞2023」の技術書部門大賞を受賞しました。 そのプレゼン大会でミノ駆動さんは、「みんなで強くなる」「昔の自分を助けに行く」という思いで本を執筆したと語り、大賞受賞スピーチでは感極まって涙する場面もありました。 エンジニアになった頃は会社の技術的負債に忙殺される日々で、「システム設計」という概念すら知らなかったというミノ駆動さんは、いかにしてリファクタリングのスペシャリストになったのでしょうか。 激動のキャリアと設計への思いについてお聞きしました。 技術的負債を解消するシステム設計
既存の機能から設計を学び、調査力を向上させて、知見を共有しよう - Hatena Developer Blog
はてなブックマークチームの id:itchyny です。 チームのメンバー間で知見を共有することは、とても大事なことです。 特に開発エンジニア同士のコミュニケーションを増やし、お互いに足りていない知見を共有し合うことでチームの生産性を向上することは、プロダクトの成長につながります。 プロダクトの実装や設計の知見を共有するためによく取られる方法として、詳しい人が講義形式で教えるというスタイルがあります。 特に、チームに新しいメンバーが入ったときには、プロダクトの概要やコードのアーキテクチャについて説明することは一般的に行われています。 講義形式で教えるというスタイルはよく行われる方法でありながら、いくつかの課題があると感じています。 まずは説明会に参加するメンバーが、どうしても受け身になってしまいます。 説明された瞬間は分かったような気になっていても、次の週には忘れてしまうことはよくあること
ソフトウェア開発における人的リソースの理想的な配分
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか？ タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
技術開発部の清水です。好きな食べ物は広島風お好み焼きと広島県産牡蠣と広島県産穴子です。 拡張に次ぐ拡張でサービスは便利なものに成長していく一方でソースコードは次第に複雑になっていきます。 そのまま放っておくと積み上げた技術的負債により開発コストが上がっていき、最悪の場合にはサービスの発展を停止させてしまう可能性もあります。 このような理由から、弊社では技術的負債を着実に返済していくべく生産性・技術的負債の可視化をMetabaseで行っています。 可視化する情報元はGithub API、CodeClimateQuality APIの2つのみです。 生産性の可視化 本流ブランチにマージされたPR数（生産数） 本流ブランチにマージされたPRによる意味のある変更行数（生産規模） 本流ブランチにマージされたPRの平均レビュー応答数（生産を助けた人員の労力） 本流ブランチにマージされた「1コミッターあ
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
Clean Architectureを採用したBackend For Frontendの開発とこれまでの所感 - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなLinux DistributionはManjaro Linuxです。 今回はレガシー化が進むLIFULLのメインサービスの開発効率の向上とコードベースの健全性の確保をすべく、Clean Architectureを採用しバックエンドを刷新している取り組みについて紹介させていただきます。 なお、Clean Architecture自体の説明および解説は本記事では行いません。 背景：歴史あるバックエンドの刷新 アプローチ：新たなアーキテクチャと共創 採用したアーキテクチャ・技術 Clean Architectureを採用した理由 TypeScriptを採用した理由 LoopBackを採用した理由 Clean Architectureの実践 レイヤー分け：例の図と新BFFアーキテクチャのレイヤーとのマッピング レイヤー内・レイヤー間：独
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに？ ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ
はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて
Merpay Advent Calendar 2019 の 13 日目は、メルペイフロントエンドチーム の @tanakaworld がお送りします。 メルペイの管理画面は 2019 年 2 月のサービスローンチに先立ち、2018 年 11 月にリリースされました。私は 2018 年 8 月に入社してから一貫して管理画面開発に関わり、様々な機能開発・運用を行ってきました。その中でフロントエンドエンジニアとして関わったいくつかのプロジェクトをピックアップしてご紹介します。 目次 はじめに メルペイのフロントエンドチーム メルペイの社内向け管理画面 プロジェクトの振り返り 審査業務効率化プロジェクト マイクロサービス分割プロジェクト 課題感 分割の方針 分割後のアーキテクチャ Component v2.0 リニューアルプロジェクト 課題感 デザインポリシー 開発フロー 社内向け管理画面で今後注
merpay Tech Talk は、エンジニアたちが集まり、技術的な知見を共有しあうことを目的とした勉強会です。今回は、「全員品質」を目指すメルペイのQAエンジニアたちが日々の取り組みについて話しました。櫻井氏は、Credit Designチームにおける技術解消のための取り組みと、それにより生まれた新しい文化・習慣について発表しました。 「メルペイスマート払い」の開発を担うCredit Design 櫻井みづき氏（以下、櫻井）：メルペイでQAエンジニアをしている櫻井みづきです。今日は「より良いサービスを継続的に届けるための新しい習慣ができるまで」というテーマでお話していきたいと思います。 まず本日のアジェンダです。今日は3つのことを中心にお話しします。今日のテーマを話すのにあたって、Credit Designというチームでの取り組みについて紹介していきたいと考えています。なのでCredi
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
本当にサービスの運用できてますか！？運用監視を学べるAWS Observability Workshopを開催しました！
本当にサービスの運用できてますか！？運用監視を学べるAWS Observability Workshopを開催しました！ 技術本部 サービスリライアビリティグループ（SRG）の柘植（@shotaTsuge）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、サイバーエージェントグループと他複数社向けに特別開催したAWS Observability Workshopの開催レポートになります。本記事を通して、運用とは何なのかを改めて考えるきっかけとなれば幸いです。 Day1 Day1では、「サービスを動かし続けるために何が必要か」というタイトルで、 運用とは何なのか Amazonでの運用例 AWS環境では、どのように運用す
(Image by Pixabay) こんな記事が、しばらく前に我らが盟主タカヤナギ＝サンによって言及されていました。 データサイエンティストになる魅力がなくなってきた理由を４つの理由（ジュニアのポジションが減っている、アナリスト職種で良い、データサイエンスを簡単だと思いすぎ、AutoML出てきた）とともに紹介。 Why Is Data Science Losing Its Charm? by @iamharshitahuja https://t.co/fqRUil9QLr— Shinichi Takayanagi (@_stakaya) 2020年6月8日 Why Is Data Science Losing Its Charm? データ分析業界の中の人という立場から見れば、ここで言われている主張については分からないこともありません。ただ、同意できる部分もあれば同意できない部分もあり、ま
STORES.jp のフロントエンドチームがイイ感じなので紹介する - おいちゃんと呼ばれています
今年の 7月末でリブセンスを退職して、8月からはフリーランスとして STORES.jp / hey という EC のサービスを作っているスタートアップで働いている。2か月半ほど働いてみた感想として、友人にも自信をもってオススメできる企業なので紹介したい。 できるだけ中立的な立場で書く 少し話が逸れるけど、以前 OLTA という企業にカジュアル面談に行ったときに、業務委託として OLTA で働いていた @ffu_ さんが中立的な立場で同席してくれて、とても助かった（発言が信頼できた）のを覚えている。可能な限りそういうスタンスで、友人に伝えるような感じで、良いところもそうでないところも書こうと思う。 あと、できるだけ印象ではなく、こういうことがあったなどのファクトベースで書いていくつもり。 なんか、みんな、ちゃんとしてる（語彙） 僕は正社員5名、業務委託4名、計9名という規模のフロントエンドチ
システム開発に関するお仕事をしていれば、よく耳にするであろう「技術的負債」という言葉。 色々と認識が揃いにくいことや、可燃性があることで有名です。 そこで、認識の揃いにくさの理由、話題が可燃性であることの理由を踏まえた上で、よりよい名前はないだろうかという話につなげたいと思います。 なぜ「技術的負債」の認識はずれやすいか？ 技術的負債は Ward Cunningham が作ったメタファです。 何らかの業務上の利益を得るために一時的に好ましくない設計を 意図的に 選び、それを負債として考えます。 負債には利子があり、それはどんどん膨らんでいくのでいつか返済する必要があります。 こういった内容を開発者ではない経営者などのステークホルダーに伝えるための表現として存在する言葉です。 その上で、さらに議論は進み 意図的ではない 設計上の不備かそうではないかの区別には意味がないのではないか、という説が
フィーチャーチームの導入と新しいエンジニアリングマネジメントでChatworkが挑戦する、一貫したオーナーシップとDevOpsの実現 - はてなニュース
リリースから12年を迎えた「Chatwork」は、国内ビジネスチャットのフロントランナーとして、中小企業を中心に41万社以上の企業・組織に利用されています（2023年6月時点）。DAU（デイリーアクティブユーザー）も100万を超えるため（108.6万、2023年6月時点）、ビジネスタイムには絶えず飛び交う大量のメッセージをサービスとして安定して処理することが求められます。 一方で、長期間の開発によって蓄積した技術的負債等に対応するため、システムのアーキテクチャを見直す時期にもあります。それにあわせて開発組織も、巨大なモノリスに対して案件ごとにプロジェクトを組み直す既存の体制から、職能を横断したチームが自律して開発を推進できるフィーチャーチームへの移行がまさに進行しています。 こうした開発改善の実情と進め方について、本部長として推進する田中佑樹さん、エンジニアとしてフィーチャーチームに所属す
アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~ - Test Automation
はじめに こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity（開発生産性）が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。 私の所属する株式会社カカクコムの食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]！
SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】 | Backlogブログ
Backlog SREチームのmuziです。2018年4月から2019年7月まで、BacklogをJavaからScala / Play Frameworkに移行する大規模なリプレイスプロジェクトに参加していました。 SREとして、このリプレイスにはかなりの困難が伴いました。特にBacklogのサービス安定性は大きな問題でした。 本記事では、こうした問題に対して、SREである私がどういうアプローチを取ったのか、そしてこのプロジェクトで得られた教訓を今後チームや組織全体でどのように活かそうとしているかをご紹介します。 正直言って、泥臭い話だらけの内容です。それでも、技術的負債を抱えたプロジェクトでSREが取れるアプローチの事例の一つとして、読者の参考になれば幸いです。 はじめに ヌーラボでは2015年11月から2019年7月まで、BacklogをJavaからScala / Play Frame
はじめに ※ (2024/03/14 16:33) 「インテグレーションテストの気軽な実行・変更ができない」節にて、データのクリーンアップを teardownで行うよう修正 EC開発-B グループの岡崎と EC開発-A グループの菊川です。2人とも普段は MonotaRO の EC サイトの開発に従事しています。 今回は、昨年11月に開催した、テストとリファクタリングのためのワークショップの中で行ったライブコーディングの準備をするにあたって困ったことについて記載します。 ライブコーディングでは、参加者全員の前で実際のプロダクトのソースコードをリファクタリングする、ということにし、それにあたって研修の運営メンバーでリファクタリングに取り組んでみました。ただ闇雲にリファクタリングするのではなく、研修では参加者に「どのような流れや考え方でリファクタリングをするか」を理解してもらえるように、運営メ
主語が大きすぎるタイトルですが、今の自分の考えをまとめておきたく、記事を投稿します。 もしかしたら、将来は全然真逆のことを考えているかもしれません。 また、ここでの「エンジニア」はシステムエンジニア、とりわけアプリケーションエンジニアを指します。 主語を「エンジニア」にしているのは、僕がエンジニアリングしか知らないだけなので、もしかしたら営業職や事務職でも同じことが言えるかもしれないし、言えないかもしれません。 サマリ 結論から書くと、以下の2点があるので、長時間労働しないほうが良いです。 長時間労働をすると、成果をあげるためにより時間がかかる 長時間労働をすると、将来的なコストを抱える 長く働けば成果が出るのか 汎用的な例を挙げていきましょう。 「用紙を三つ折りにして、封筒に入れてください。」 という仕事があったとします。 誰でもできる簡単なお仕事ですね。 この仕事を1時間やった場合とさ
技術的盆栽 - ぱろすけのブログ
技術的負債 (technical debt) は、ソフトウェア開発の用語で、手早い解決策を選択することで生じた潜在的な手直しのコストを指す。技術的盆栽 (technical bonsai) は、完成した技術を鑑賞し、また完成度の向上のために手直しを加える趣味を指す。技術的負債とは特に関係はない。定義はいま考えた。 「技術的盆栽」という言葉はここが初出ではなく、先行例が存在している（ことを Google が教えてくれた。）「文化的雪かきと技術的盆栽」というエントリで「ちょっとしたこだわりや調整にいくらでも情熱を注ぐことができる」ことが特色であると説明している。これは僕の「技術的盆栽」の解釈とも一致する。 技術的盆栽の道具のひとつとして git があり、そこでは技術的改良の履歴は木構造で管理される。それ自体もまた盆栽性があり、さまざまな枝 (branch) の形の妙などを楽しむことができる。オ
テックカンパニーをテックカンパニーたらしめているものはなにか？技術か、人か、それともチームなのか。 連載「Technology Company Internals」では、テックカンパニーの内側で働くエンジニアに、技術に精通したエキスパートが対面で話を聞き、テックカンパニーとは何か？を探るだけでなく、テックカンパニーを目指す企業の指針となることを目指します。 マネーフォワードのCTOとVPoEに話を聞く 白石: 本日はよろしくお願いします。自己紹介からお願いできますでしょうか？ 中出: 中出 匠哉と申します。マネーフォワードのCTOとして企業経営に関わり、経営にテクノロジー視点を導入していくのが主な役割です。他には技術面での方向性の決定や、エンジニアの人事制度の立案などもやっていますね。あとはサービスがどんどん大規模化していく中でも、技術的負債に優先順位を付けて、体制を作って解消していくのも
エンジニア歴1年の僕がドメイン駆動設計(DDD)を参考にLaravelのプロジェクトをフルリニューアルした話 - Hajimari Tech Blog| 株式会社Hajimari
こんにちは！ はじめまして！ 2020年7月からPIECE事業部でエンジニアをさせてもらっています。 野澤です。 今回、PIECEというサービスのリニューアルを担当させてもらったのでその時のことについて書きたいと思います！ まだ若輩者なので至らない点が多々あると思いますが フルリニューアルってどんな事したんだろう〜？ Hajimariのエンジニアはどんな仕事をしてるんだろう〜？ って思った人はぜひ読んで見てください！ ※ドメイン駆動設計の説明も書いたのですがボリュームが多くなってしまいました… ドメイン駆動設計について概要知りたいという方は是非読んでみてください。 クリーンアーキテクチャの説明やモデリングのやり方などは説明していません。 ご了承ください。 PIECEリファクタリングプロジェクトの概要 PIECEとはどのようなサービスなのか リニューアルの目的 リニューアル施策 ドメイン駆動
マイクロサービス化を目指すなら移行パターンを学ぼう /「モノリスからマイクロサービスへ」を読んだ - kakakakakku blog
2020年12月に出版された「モノリスからマイクロサービスへ」を読んだ．本書はタイトルの通り「マイクロサービス移行」に関連するトピックにフォーカスしている．マイクロサービスを学ぶならこの本！とよく紹介している「マイクロサービスアーキテクチャ」の著者 Sam Newman の続編となる．原著「Monolith To Microservices」は，2019年12月に出版されている． 僕自身は技術講師として「マイクロサービス」に関連した研修を担当していることもあり，本書は絶対に読もう！と楽しみにしていた（原著は読もう読もうと積読していた😇）．今回は本書の翻訳を担当された島田さん (@snoozer05) とレビューを担当されたこまさん(@koma_koma_d) からご連絡をいただき，本書を献本していただいた．本当にありがとうございます！ モノリスからマイクロサービスへ ―モノリスを進化させ
こちらはEngineering Manager Advent Calendar 2023 12日目の記事です。 こんにちは、Isoparametric（Yuki Tamura）といいます。 今回はEMはCTOやVPoEの下位互換ではないということについて書きます。 私は今estieというスタートアップでEMをしております。 前職では不動産テックのCTOをしていて、その前はスマートニュースという会社でEMをしてました。 その前は、ディライトワークス、gumiという会社でCTOだったりしたこともあります。 それが何故またEMをという感じですが、入社の経緯などは、会社のブログの方にありますので興味があれば読んでみてください。 CTOを辞めて各社のCTOや最強のエンジニアが集う梁山泊estieに入社した理由 - estie inside blog では、CTO/VPoEとEMの互換性/再現性につい
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
「Mix Leap Study」はヤフーの独自技術や業界の最先端テクノロジーに触れる勉強会。第59回は「React とその仲間たち」と題して、より実践的にReactを使うための仲間たちにも注目。株式会社Gemcookの藤本卓哉氏が、プロジェクトにGraphQLを採用してみた経験から、いい点、悪い点を語ります。 React + GraphQLで社内の負債を解決した話 藤本卓哉氏：みなさん、こんばんは。ジェムクックの藤本です。『React + GraphQLで社内の負債を解決した話』というタイトルでお話ししたいと思います。よろしくお願いします。 まず簡単にプロフィールです。藤本卓哉と言います。去年（2019年）30歳になって、今年（2020年）31になります。会社の代表兼エンジニアをやっています。会社の代表といったら、経営ガッツリやっているんかなって言われがちなんですけど、僕けっこうエンジニア
今後LIGが制作するWebサイトは、Internet Explorerの対応をやめます。 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、LIGでフロントエンドエンジニアをしているライダーです。 IE対応、やめます。 2007年の創業以来Web制作に携わってきたLIGは、これまで長らく、Internet Explorerを動作環境に含んだWebサイトの制作を提案してまいりましたが、 今後、LIGが制作するWebサイトは、 Internet Explorerの対応を行いません！ ただしInternet Explorerに特別な配慮が必要な場合は、お申し付けください。これまでのノウハウを活かし、Internet Explorer上でも動作するよう制作させていただきます！ もちろんMicrosoft Edgeに関しては、これまで同様に対応を続けますよ！ 今日は、その背景を簡単にお話しさせてください。 IE対応によってできなくなることがある できる・できないに関しては、さまざまな考え方がありますが、ここでは予算やスケジュ
会社がリファクタリングに賛同してくれないたったひとつの理由一定の工数をかけてリファクタリングをやったほうがいいことは（少なくとも筆者の観測範囲では）エンジニアリングのバックグラウンドがない人でもだいたい理解しています。 上司の無理解をあげつらっても仕方ありません。 リファクタリングの実施を渋る真の原因が工期や予算の問題であることはあまりないとおもいます。タイミングの問題である可能性はありますが。 必要であればコストをかけることにも同意してくれます。 「技術的負債は過去のビジネス上の選択によって生じたまさに負債なので、計画的に返済しましょう」っていえば、多くの経営者は理解を示してしてくれるでしょう。 本当に無理解ゆえにリファクタリングをしないのであれば技術的には死んでいる組織なので、エンジニアとして幸せになりたい場合は逃げ出したほうが賢明です。 というわけで、本稿ではそういう組織においてもな
タイトルにあるように、弊社ハウスマートが提供する売買マンション提案アプリ "カウル" がiOS/Android共にFlutterでフルリプレイスしました！ 下記サイトよりダウンロードしてみてください。 本記事では、Flutterを採用したカウルの技術的背景の話を紹介していきます。Flutterに少しでも興味がある方、もしくは将来的にFlutterの採用を検討している方の参考になれれば嬉しいです。 技術周辺の話が中心になりますが、コーディングのtipsなどはなく、振り返りの開発後記の様な内容なので、1つの読み物として読んでみてください。 目次 ・はじめに ・技術的な意思決定とFlutter ・スタートアップ特有の技術負債 ・生産性の向上という狙い ・投資に見合ったリターンとリスク ・検証とキャッチアップ、9週でのリリース ・技術検証 ・1週のキャッチアップ ・9週の開発 ・Flutterの技
ふとしたときに、ぼーっと考える 会社（や評価をする人）は何をもって「このソフトウェアエンジニアはいい」って判断するのがいいんだろうなぁって。むずかしくない？入社前じゃなくて、入社した後のこと。自社ウェブサービスを開発しているソフトウェアエンジニアのこと 特に伝えたいことも答えもなくて頭の中のメモ 分かりやすいならいい その人の開発したものが、バグだらけだとか、そもそも設計ができないとか、そういうのだと分かりやすいからいい。まずは、バグを減らそうねとか、設計ができるようになっていこうね、という話 あと、やってることが周りから見えないとか、コメントとかが攻撃的で一緒に働いてる人が嫌な気持ちになるとか、まぁ、そういうのも「違うよね？」って言えるし、コンピテンシー評価で伝えていけたらよさそう ある程度のモノができている場合は、どうだろう？ もっと早く作ってほしかった！ って考えるかもしれない。確か
マネージャーが把握しておくべき技術的負債を招く5つの論点
Nicolas Carlo ソフトウェアクラフトマンシップに情熱を捧げ、アジャイルプロジェクト管理、フロント/バックエンドの知見もあわせ持つWeb開発者。 この記事は、著者の許可を得て配信しています。 https://understandlegacycode.com/blog/5-arguments-to-make-managers-care-about-technical-debt/ 経営陣はレガシーコードをリファクタリングさせません！ あなたは自分の現在の状況を把握できていますか？すごくイライラする状況にいるのではないでしょうか。 開発者として、すでに問題が出ている点を修正することに興味がないマネージャーはたくさんいます。 新機能、緊急リリース、バグの修正…そのめちゃくちゃになっているコードベースのリファクタリングを先延ばしに言い訳はいくらでもあります 😭 正しいコードのメリットを説
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術のトレンドと開発テクニックの知見を、無料で公開します！ - Qiita
技術的負債の上手な積み上げ方・返し方
デジタル庁の創設に向けた提言 - 一般社団法人 日本CTO協会
何故エンジニアの上司はエンジニアである必要があるのか？｜えふしん
t-wadaさんと学ぶレガシーコード改善ワークショップのつくり方～虎の巻～ - Qiita
今、エンジニアが「働きたくなる会社」ってどんな場所なんだろう｜カケハシ公式note
振り返りで積み上げた開発プラクティス（2020年総まとめ） - BASEプロダクトチームブログ
生産性・技術的負債をMetabaseで可視化した話 - LIFULL Creators Blog
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
"技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita
メルペイの社内向け管理画面を振り返る | メルカリエンジニアリング
チーム内にもあった“ヤバい”空気感 メルペイチームが技術的負債をゼロにするためにやったこと
何故データサイエンスは魅力を失いつつあるのか - 渋谷駅前で働くデータサイエンティストのブログ
技術的負債が紛らわしいので改善対象となる設計不備に名前をつけたい - Tbpgr Blog
効率的にリファクタリングを進めるための下準備教えます - MonotaRO Tech Blog
なぜエンジニアは長時間労働してはいけないのか - あしたからがんばる
Railsを読み、Goを書く。大規模SaaSのマイクロサービス化の（生々しい）実際をマネーフォワードに聞いてきた！
CTOやVPoEと違いEMには再現性がある - 神様なんて信じない僕らのために
ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
「React」とFacebookのWeb API「GraphQL」で技術的負債を取り除く方法
会社がリファクタリングに賛同してくれないたったひとつの理由 - shiodaifuku.io
カウルのアプリをFlutterでリプレイスしました｜yamarkz - Kazuki Yamaguchi
ある程度いいエンジニアでありたいかもしれない - Mitsuyuki.Shiiba