こんにちは、freee会計のプロダクトマネージャー（以下PM）をしております、gokiです。 皆さん、「ドメイン知識」という言葉、聞いたことありますか？ ドメイン知識（英: Domain knowledge）または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。 ドメイン知識 - Wikipedia freee会計での開発現場で例示すると「確定申告のプロダクトを作るには、開発技術だけでなくそもそも確定申告業務の理解というドメイン知識が必要だよね」みたいな使われ方をします。 freeeはスモールビジネスの皆さんのバックオフィス業務を改善するプロダクトを作っているので、このドメイン知識が開発においても必要な場面が多いです。 そこで、今回はドメイン知識が必要な開発をどのように進めるか、というコツをPM目線でご紹介しようと思いま

Twitterを本格運用して4ヶ月、当時目標にしていたフォロワー1万人を達成することができました。個人的にはあんまりフォロワー数にこだわりはなく、あくまで1つのKPIでしたが、狙い通り達成できたことはとても嬉しかったです。 普段こういうツイートはしないのですが今日だけは特別に。去年12月から本格的にTwitter運用を始め当時1500人だったフォロワーが、ついに先ほど「1万人」の大台に乗りました😁別にフォロワー増えたから何かあるわけではないですが、1つの目標を達成できたことが嬉しい。やったことは記事にまとめます！ pic.twitter.com/ImEJydgrbR — Shin Sasaki@PM Club主催者 (@shin_sasaki19) March 8, 2022 そこで今回は、最近私自身がよく聞かれるTwitter運用をするときに考えていること、設計と戦略をまとめてみました

マイクロサービスの矛盾先日、「マイクロサービス？モノリス？SaaSアーキテクチャのPros/Cons | SaaS.tech #1」(youtube)(togetter)というイベントを観ました。これは、マイクロサービスのイベントだったのですが、新規のシステム開発において積極的にマイクロサービス化をすすめる方が少なかったのが意外でした。 マイクロサービスの開発経験のある優秀なエンジニアであっても、まずはモノリスからはじめてプロダクト境界を意識して設計していき、functionベースで切り出せるもの(認証や通知、メール送信、バッチ等)は切り出しつつ、必要であればモジュラーモノリスかマイクロサービス化を慎重に検討するということでした。素晴らしい冷静な判断です。 というのは、ドメインの専門知識がないうちにマイクロサービスの複雑なシステムを設計するのは、多くのソフトウェアプロジェクトが陥りやすいリ

最初期のスタートアップは現場に泥臭く足を運び、「カスタマーマニア」になろう｜ 未来を実装する秘訣 vol.4 2021.05.20 読了時間：約 5 分 This article can be read in 5 minutes スタートアップの中でも特に急成長しているような企業の起業家の共通点として、「顧客（カスタマー）の悩みを顧客以上に知っている」というものがあります。顧客の悩みや課題を多数把握していて、その悩みに対して的確なアドバイスを送れる彼ら彼女らは、顧客のことを何でも知っている「カスタマーマニア」だと言えるでしょう。ではそうした起業家はどのようにして、カスタマーマニアになれたのでしょうか。 これまで私が見聞きしてきた初期のスタートアップの例をまとめると、いくつかの共通点が見えてきます。 INDEX ・顧客の課題にあたりをつけるためにインタビューを100件する ・顧客のペインを直

Microservices Manchester: Serverless Architectures By Rafal GancarzOpenCredo

DXの波で企業はシステムの内製が必要だ、SIは不要。SaaSがSIを代替しつくす等々の話題がよく出ています。果たしてそれは正しいのでしょうか。 私のスタンスとしてSIerに寄っているわけではないのですが、表面的で加熱気味なSIer不要論が出てきており、少々技術屋として口を出したくなりました。技術戦略上、どのような特性を持つのかきちんと考察してみます。 業務システム開発をする当事者のための1つの指針になれば幸いです。 業務システムを開発するにあたっての３形態 3つの開発形態のメリット・デメリット 「内製エンジニアによる開発」は最上級のオプション 「SIerへの委託による開発」は雇用しなくても細かく要件を注文できる代替策 「SaaSソフトウェアの導入」は低コストでスケールメリットを得る選択肢 3つの開発形態はサービスレベルで分類できる 「ソフトウェアの入れやすさ」の４象限 「結合度」と「ミッシ

TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ

はじめに こんにちは、ソウゾウSoftware Engineerの@sue71です。連載：メルカリShops 開発の裏側 Vol.2の13日目を担当させていただきます。 以前メルカリメルカリShopsの技術スタックと、その選定理由でBFFの実装にGraphQLを採用していることをお伝えしました。メルカリShopsをリリースしてから約半年たった今、これまでを振り返ってGraphQLサーバーを実装する上での課題やあらかじめ考えておくと良い項目をまとめてみました。また、本記事ではメルカリShopsでGraphQLの実装としてApolloを採用しているため、Apolloの利用が前提の話もいくつか混在しています。予めご容赦ください。 GraphQLの説明や、メルカリShopsの実装方法に関しては以前こちらの記事で紹介しています。こちらも是非ご覧ください。 パフォーマンス課題 GraphQLは、アプリ

こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスでは有り難いことにサービスが順調に成長しています。今後の成長に対応できるようにするために、継続的な検討課題としてより拡大可能なアーキテクチャの検討を行っています。 拡大成長可能なウェブアプリケーション（のバックエンド）アーキテクチャとしてすぐに挙がるのが「マイクロサービスアーキテクチャ」だと思いますが、マイクロサービスアーキテクチャが一般的に議論されるようになったのが2015年頃からだったと思います。それ以来いろいろと考え続け、従来のモノリシックアーキテクチャ群との間にあるアーキテクチャとイメージがつながってきたのでまとめてみたいと思います。 この記事でそれぞれのバックエンドアーキテクチャを俯瞰的に比較する

ロシアがウクライナに侵攻し、1週間が経過しました。 この戦争の被害が少しでも小さくなるよう心から祈っています。様々な背景や事情があるとは思いますが、力あるものが力づくて奪い取る、そんなことがまかり通る世界になれば、世界秩序は破綻しますし、大国に挟まされる日本も我が事として考えるべきでしょう。「自分の国は自分で守るしかない」という当たり前の現実を突きつけられた気がします。 実際のところ、仕事も手につきづらい状況ですが、僕たちがウクライナに対して、国際社会に対してできること（応援の寄付や人道支援の受け入れなど）を進めながら、日々の仕事に打ち込んでいくしかないでしょうか？ こんな状況ですが、書きかけのテーマがあったので、表題のテーマについて少し考えたいと思います。“成功する新規事業”はどうすれば創れるのか、起業して以来、ずっと考え悩んでいるテーマです。新規事業の分野、規模にも、もちろんよりますが

「モノリスからマイクロサービスへ」サマリ をさらにサマライズしたもの 絵をテキストアートからちょっと整えて、文書もさらに絞った いつでも参照できる自分のためのちょっと細かく書いてある辞書として使う 絵の色は基本的にこう 緑：移行先とか作成・変更するもの 赤：移行元とか問題のあるもの 灰：移行中に必要になるもの イメージ的には GitHub の差分カラー 画像がちょっと大きくて見通しが悪いけど、50 枚数直すのも大変だし、困ったらcmd -して倍率変えて見るか... これはあくまで章にアタリをつけたり一度読んだことを思い出したり、とにかく本を読むためのまとめ h1 と h2 を抽出 1. 必要十分なマイクロサービス デプロイ 凝集度 判断 モノリス 結合 2. 移行を計画する 選択する理由 ふさわしくないケース 定期的にチェックする 3. モノリスを分解する パターン: ストラングラーアプリ

次の問題は、CV駆動開発(CV-driven development)です。自分のCV(Curriculum Vitae、職務経歴書)を見ます。すると、"マイクロサービス"に関する部分が大きく空いていることに気付きます。これでは都合が悪いので、"自社のスタックを再構築して解決しよう"、と考えるのです — 読者の皆さんは、"Holly、それは皮肉が過ぎるよ"、と思うかも知れません。"自分の履歴書の都合でアーキテクチャを決めるやつがどこにいるんだ？" それが実は ... いるのです。 Red Hatは先日、コンテナベース開発を導入したおもな動機に関する調査を行いました。その結果、最も多かったものは"キャリアアップ"でした。"キャリアアップ"は、CV駆動開発の体のよい言い換えに過ぎません。 現在のマイクロサービスは"新正統派"と言ってもいいものですから、経歴書にマイクロサービスが欠けているのは大

Published 2022/02/28 21:19 (JST) Updated 2022/02/28 21:56 (JST) 【モスクワ共同】ロシア国防省は28日、ショイグ国防相がプーチン大統領に対し、ロシア軍の戦略核兵器部隊が戦闘態勢に入ったことを報告したと発表した。

HTTPでファイルをアップロードする時、ネットワークの寸断などによりアップロードが中途半端に終わってしまうことがあります。アップロードが途中まで成功したとしても、一度切断するとそこから再開する方法は標準化されていません。 (PUTリクエスト + Rangeヘッダによる再開をサポートしているシステムもありますが標準化されてはいません。 参考URL) そこで、再開可能なアップロードの仕組みを定義した「Resumable Uploads Protocol」という仕様がIETFに提出されています。この仕様は、Transloadit Ltd, Apple Inc, Cloudflare などの方々の共著になっています。 Resumable Uploads Protocol の概要 「Resumable Uploads Protocol」は、一度中断しても再開可能なアップロード方式を定義しています。

Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ

開発と運用の理想的な関係とはどんな姿か。すでに「DevOps」という言葉は浸透しているものの、理想的な形で実践できているかとなると、話は別だ。現場ではどんな障壁があり、DevとOpsが分断されているのか。打開していくにはどうしたらいいのか。DevOpsという言葉が生まれる前から、その本質を実践してきたAmazonのカルチャーにヒントがありそうだ。AWSジャパン 塚田朗弘氏に聞いた。 今回お話を伺った、アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 塚田朗弘氏 ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」 Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の

宣戦を布告したのは米アマゾン・ウエブ・サービス（AWS）だった。アダム・セリプスキーCEO（最高経営責任者）は2021年11月29日から米ラスベガスで開催したカンファレンス「re:Invent」の基調講演で「メインフレームは高価だ。複雑だ。COBOLのプログラミングを学ぶ人は少なくなっている。顧客の多くはできるだけ早くメインフレームから離れ、クラウドの俊敏性と弾力性を手に入れようとする」と述べ、IBM zの複雑なアプリケーションをAWSに移行するための多くの作業をリファクタリングとリプラットフォームの形で提供する「AWSメインフレーム・モダナイゼーション」を発表した。 この発言から1週間後の12月8日、米IBMはメインフレームzの顧客がオープン・ハイブリッド・アーキテクチャーのもと、アプリケーションやデータ、プロセスのモダナイゼーションを加速できるよう支援する「IBM zアンド・クラウド・

「DeNA TechCon 2021 Winter」は、DeNAを軸に「エンジニアとして企業で働くこと」について、学生に向けて先輩たちが紹介するイベントです。そこでまずはファウンダーの南場智子氏が、「経営者からみたエンジニアキャリア」について話しました。 本当にやりがいのある、充実した彩り豊かなキャリアとは 南場智子氏：みなさん、こんにちは。ファウンダーの南場です。オンライン開催となりちょっと寂しいですけど、「経営者からみたエンジニアキャリア」ということでお話をしたいと思います。 どの業界でも、そしてどの企業でも、もうDXをしないと後れを取るどころじゃなくて退場しなければいけないと、そういう厳しい状況になってきています。ですから、どの会社もエンジニア採用には必死です。そういう時にみなさん、エンジニアということで、おめでとうございます。 先週かな、学研の「高校生のなりたい職業ランキング」の1