はじめまして！LayerXのカレー担当のN_Taisho（西井）です。 私は、もともと霞ヶ関の役人として、６年ほど地方財政支援、大規模災害の被災地の復旧・復興支援、国際協定交渉等に関わってきました。現在はLayerXに所属しながら、三井物産デジタル・アセットマネジメント株式会社（以下、MDM）にてProduct Managerとしてプロダクト開発に主に携わりつつ、会社立ち上げに係る様々な業務に従事させてもらっています。 このMDMは、「眠れる「銭」を、Activateせよ。」をミッションに、「Operation × Techでどうアセマネ業務をリデザインするか」に取り組んでおりますが、その概要については以前、同じくLayerXに所属しながらMDMにコミットしている丸野が執筆した以下の記事が詳しいところなのでそちらをご一読いただければと思います。 tech.layerx.co.jp 今回は、

Apple's iPhone 16 gets a camera button, Action button and the A18 chip

これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな

「ITエンジニア本大賞 2021」技術書部門大賞を受賞した『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』。この書籍で紹介された技術的負債を返済するアプローチ手法であるリファクタリング、リアーキテクティング、リプレイスを、VOYAGE GROUPではどう実践してきたのか。そして、各システムの技術的負債に対し、どのように立ち向かってきたのか。同社のエンジニアが挑んできた課題や解決策を、実例を交えながら紹介する。 タワーズ・クエスト株式会社 プログラマ・テスト駆動開発者 和田卓人氏（左上）、株式会社fluct プログラマ 須藤洋一氏（右上）、株式会社VOYAGE MARKETING 福田剛広氏（左下）、元株式会社サポーターズ ねこや氏（右下） 技術的負債を返済するための3つのアプローチ まず和田卓人氏は、事業とシステムとの間の乖離から生まれる技術的負債を返済する

単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や