モノリスからマイクロサービスへのマイグレーションで学んだ７つの教訓Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
テックリードになって気をつけていること - Qiita
フューチャーアドベントカレンダー2020の24日目です。 はじめに フューチャーに入ってテックリード（社内だとアーキリーダーと呼ぶことも多い）のような役割をし始めて4,5年ほど経過しました。 いくつかの案件を回して自分なりに汎化・パターン化してきた部分も増えてきたので、気を付けていることをまとめました。 テックリードとは エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。 テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である 技術的なプロジェクトの管理者 部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける チーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない 管理やリーダーシッ
【ZOZOTOWNマイクロサービス化】API Gatewayを自社開発したノウハウ大公開！ - ZOZO TECH BLOG
はじめに こんにちは。ECプラットフォーム部のAPI基盤チームに所属している籏野 @gold_kou と申します。普段は、GoでAPI GatewayやID基盤（認証マイクロサービス）の開発をしています。 ZOZOテクノロジーズでは、2020年11月5日にZOZO Technologies Meetup〜ZOZOTOWNシステムリプレイスの裏側〜を開催しました。その中で発表されたAPI Gatewayによるマイクロサービスへのアクセス制御に関して、当日話せなかった内容も含めて、API Gatewayについてこの記事で網羅的にまとめました。 API Gatewayやマイクロサービスに興味ある方、「API Gateway」という言葉は知っているけど中身はよく分からないという方向けの記事なので、読んでいただけると幸いです。 はじめに ZOZOTOWNのリプレイス マイクロサービス化の目的 ストラ
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
アーキテクチャ 【まとめ】 -マイクロサービス、ミニサービス、モジュラーモノリス、モノリシックアーキテクチャを並べて比べてみました- - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスでは有り難いことにサービスが順調に成長しています。今後の成長に対応できるようにするために、継続的な検討課題としてより拡大可能なアーキテクチャの検討を行っています。 拡大成長可能なウェブアプリケーション（のバックエンド）アーキテクチャとしてすぐに挙がるのが「マイクロサービスアーキテクチャ」だと思いますが、マイクロサービスアーキテクチャが一般的に議論されるようになったのが2015年頃からだったと思います。それ以来いろいろと考え続け、従来のモノリシックアーキテクチャ群との間にあるアーキテクチャとイメージがつながってきたのでまとめてみたいと思います。 この記事でそれぞれのバックエンドアーキテクチャを俯瞰的に比較する
DDDとORMのEntityを混同しないための考え方
２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る｜kyuns /キュン 今村雅幸
こんにちは、ZOZOテクノロジーズで執行役員CTOをしている @kyunsです。 本記事はCTOA Advent Calendar2020の 16日目の記事となります。 この記事ではZOZOでの2年半を振り返り、テックカンパニーを目指す中でCTOとしてどのようなことに取組み、結果としてどういう変化が起きたかについて紹介したいと思います。 同じような立場のCTOやこれからエンジニアリング組織を強化していきたい方々の参考に少しでもなればと思います。 自己紹介と背景 私はヤフーに2006年に新卒で入社し、3年働いた後に当時一緒に働いていた金山と一緒にVASILYというスタートアップを創業し、受託アプリ開発や「IQON」というサービスを開発していました。 何度かの資金調達などを経て、最終的に2017年にZOZOへ売却し、ZOZOの完全子会社となりました。その後、2018年の4月には当時のスタートト
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
WEB アプリケーション設計入門 / Introduction to web application design
PHP Conference Japan 2020 トーク前提の資料です。そのため、トークがないと理解が難しいかもしれません。 https://youtu.be/UTKJ-Lgn3aI?t=36 ※冒頭音声が小さいです。マイクを手に持ってから聞こえやすくなると思います。 資料中の ADOP については下記を参照ください。 https://nrslib.com/adop/ # Abstract https://fortee.jp/phpcon-2020/proposal/da5b9d99-e5a6-4f51-adea-1f1c10d99020 # Ref https://github.com/nrslib/scrum-app-sample-php https://github.com/nrslib/repository-support-php # URL Togetter: https://
CTOの頭の中：技術投資を最適化する｜Shin Takeuchi
ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが（地代家賃、ライセンスフィー、PC代など含めるともっと）、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか？今回はこの部分に一石を投じてみたいと思います。 技術投資量を見える化する 投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知る
ちょっとしたシステム変更なのに時間と手間がかかるのはなぜ？｜森崎 修司
ソフトウェア開発の効率化や品質向上を研究しています。そこで感じたことを書いていきます。ITシステムに関するリテラシーが高まるともっとIT化が進むのではないかと思い、書いています。 ITシステムを利用していると改善したいことが出てきます。「こことここは同時に指定したい」「この順番が入れ替わると作業しやすい」といったこと要望を感じることは誰にでもあるのではないでしょうか。ご自身が開発に携わっていれば、変更することもできますが、社内のIT部門が管理していたり、開発会社にお願いしていたりすると、このブログエントリのタイトルのように思うことがあるかもしれません。 「ちょっとした変更なのに、なぜ時間がかかると言うのだろう。本当はそれほど時間がかからないのに、ひょっとして仕事が増えるのがいやなだけで、体よく断っているのではないか」と思ってしまうかもしれません。その可能性はゼロではありませんが、一般には次
時雨堂を支えるビジネスモデル
shiguredo_model.rst 時雨堂を支えるビジネスモデル 更新 2023-12-08 作者 @voluntas バージョン 2023.2 URL https://voluntas.github.io/ タイポなどは Twitter の @voluntas までお願いします。 概要 定期的に更新している 株式会社時雨堂 を作って、 自分が選択したビジネスモデルで充分な利益を上げられるようになったので雑に書き出していく。 時雨堂がどんな会社なのかは 時雨堂コトハジメ を見てほしい。 前提 IT 系零細パッケージメーカー で、ここ最近はパッケージをクラウド版として運用をセットで提供するビジネスも始めている。 主力製品はパッケージソフトウェア製品と、パッケージソフトウェア製品のクラウド版の２つ。 ライセンス契約モデル 時雨堂は自社開発ミドルウェアのライセンス契約モデルで利益を出している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
