こんにちは。ソーシャル経済メディア「NewsPicks」で検索システムを開発しております崔（ちぇ）です。 この記事は、 NewsPicks Advent Calendar 2023 の23日目の記事になります。 qiita.com 昨日ははぐっさんによる「SwiftUIのKeyframeAnimatorでちょっとしたカードアニメーション 〜猫の手を添えて〜」でした！ はじめに コンテナ流儀: 必要最低限のものだけで運用する Point１）レイヤーは少ないほどいい TIP：ベースイメージを作る Point２）不要なパッケージをインストールしない Point３）いつ再起動してもいいコンテナを作る Point４）独立したアプリケーションにする TIP：複数のプロセスを実行したい場合もある TIP：環境変数を積極的に使う Point５）フォアグラウンドで実行する 終わりに まとめ 感想 告知 はじ

最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから

今度のカンファレンスで以下のようなことを聞かれそうなので、最近の出来事とともに、記憶に刻むためにも書いてみる。あんまり推敲はしてない、だらだらと。 ソフトウェア開発において、ビジネスの人と開発の人とでなんか意識が合わないみたいなことの根源はどこにあるのか? みたいなのが最近少しわかったことがある。(ビジネス / 開発と区分けすること自体がそもそもなんだけど、それ言い出すと考察が進まないので、あえて分ける) ビジネスの人は、そもそもがそのビジネスの実現だったり顧客の問題解決だったりが最初から目的なので、簡単にいえば「早く顧客の問題を解決してビジネスを実現したい」と自然に思っている。これは当たり前。 たとえば自分が自宅にお客さんを招くときには「そのお客さんに快適に過ごして帰ってほしい」と思って、家を掃除したり振る舞う食事の献立を考えたり、食後にするゲームは何にするか、などを考えたりする。動機は

仮説検証サイクルを高速で回す為に、DMMポイントクラブ アプリチームが行っている取り組み | DMM iOS Meetup #2

テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか？テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。

Nobi Hayashi 林信行 @nobi 質問は改めてコンテクストも加えた上で再投稿します。 ただ、ここまででただの私への罵詈雑言以外にもいくつか重要な意見あったので、その辺りはtogetterで（誰かに）まとめてもらいたい... 中心軸（＝問題ツイート）を削除すると引用ツイートとかは探しにくくなっちゃうのかな？ 2023-12-21 10:44:39 Nobi Hayashi 林信行 @nobi 【再投稿：やはりUI設計無視できず、追加しました】 日本の大企業（や官庁）が提供するソフト・サービスは使い勝手が悪く、品質も低いものが少なくない。 最も改善に力をいれるべきはどの問題か？ 1.能力： お金をかけてでも優秀なソフトウェアエンジニアを雇う 2.開発体制の問題： 開発体制を見直す。下請け・孫請けをやめる。しっかりと全体設計や使い勝手のことを考えるデザイナーを中心的役割として取り入れ

めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか？」「なぜこれをやってるんだっけ？」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状

はじめに 仕事に追われる日々から解放され快適に楽しく働くことができる環境を実現するためには、自己管理が重要です。ここでいう「仕事に追われず快適に楽しく働ける状態」とは、自分自身で意思決定を行い、仕事の進行を自らコントロールする能力を身につけることを意味します。 多くのエンジニアは仕事の量や複雑さに圧倒され、自分のペースで仕事を進めることができないという状況に直面しています。しかし、自己管理スキルを身につけることでこれらの課題を乗り越え、より自分起点な働き方が可能になります。 この記事では、よく起きがちな問題とあわせて自己管理を強化するための具体的な方法を示します。 1. 他の人から見て何をやっているかわからない問題 主要なポイント 「あれってどうなってます？」って聞かれていませんか？ これを頻繁に聞かれる場合、確実に何やっているかわからない人だと思われています タスクの状態は、必ず聞かれる

最終更新日: 2024年02月27日(月) 1. ご挨拶 2. 本記事執筆のモチベーション 3. ワークショップを通じて得たフィードバック 3-1. Pains -過去抱えた/現在進行形で抱えている辛み- 3-2. Approaches/Solutions -Pains を解消するために取った方策や導き出した解決策- 3-2-1. えいやで場所を決め打ちしてしまう(e.g., GitHub Wiki + Google docs しか使わない) 3-2-2. 個人的に、2023/12/05時点で〜みたいな書き方を心がけている 3-3. Tips -効果的な手法- 4. オーディエンスからの反響 4-1. 気づきや学び・NEXT ACTIONS 4-2. プレゼンター(@hayat01sh1da)へのフィードバック 4-3. Slack での反応 5. おわりに 1. ご挨拶 初投稿となります

「Developers Meetup 急成長ベンチャーが向き合う『開発生産性』」は、開発組織や事業フェーズの異なる株式会社Another works・株式会社SmartHR・株式会社スタメンの3社が、開発生産性について語り尽くすイベントです。ここで株式会社SmartHRのすがわらまさのり氏が登壇。チーム増加に伴い起きた「認知負荷が高い」状況をどのように解決したかについて紹介します。 チームの増加に伴いできるようになったこと、やりにくくなったこと すがわらまさのり氏：ここから本題ですね。「開発生産性について、上から見るか、下から見るか」ということで、よろしくお願いします。過去に私が登壇したもので似たテーマがいくつかあるので、軽く紹介しておきます。もし気になる方がいれば後で見てください。 前提の共有というところで、先ほどもお話ししたように、私が担当したのは「SmartHR」の基本機能というプロ

この記事はNuco Advent Calendar 2023の9日目の記事です。 はじめに この記事ではDockerで開発環境を行うために理解してほしい概念と実際の開発環境の構築手順について解説を行います。大きく分けて、 ・Dockerの概念理解 ・開発環境の構築 これらの章により構成されています。この記事を読むことで、Dockerファイル、イメージ、コンテナ、Docker compose、compose.ymlを理解できるようになることを目指しています。Dockerに触れてみたい、Dockerの理解があやふやという方は参考にしてみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 Dockerとは まず、Do

PMConf2023: シリコンバレーのプロダクトマネージャー達に見る、 覚悟を決めたPMは何が違うのか？

ブックサンタという企画で、ジュール・ヴェルヌの『十五少年漂流記』を寄付してきました。年末ですね。 スターフェスティバル Advent Calendar 2023 の2日目の記事です。よろしくお願いします。 スターフェスティバルに入社して4年が経とうとしています。昨年まではソフトウェアエンジニアとして開発に従事しておりましたが、今年からはロールが替わって Kitchen Success プロジェクトのプロジェクトリーダーとなりました。経験の枯渇しないことでお馴染みのスタフェスです。大変ありがたいことです。それにしても、プロジェクトリーダーってなんだ。 勢い込んでアドベントカレンダーの枠をいただいたものの、ネタがなにも浮かびません。二年間の休暇でも貰うことができるなら、なにかいい感じのトピックを捻り出せそうなものなんですが。あいにくそんな時間はありません。 だから今回はふりかえり記事のようなも

アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分

どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私

こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー

「ソフトウェア要求　第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。 「私はかつて、過去10年間でベストセラーになった要件エンジニアリングの本を10 冊を読んだことがあります。この1冊には、それらの10冊を合わせたものよりも有益な情報が簡潔に記載されています」-- Mike Cohn ここまで言われたら読むしかない。 Software Requirements Essentials: Core Practices for Successful Business Analysis 作者:Wiegers, Karl,Hokanson, CandaseAddison-Wesley ProfessionalAmazon もくじ もくじ 全体的な感想 ソフトウェア要求　第3版から何が省略されたのか 20のコアプラクティス #1: 解決策を

電気自動車（EV）市場で世界首位を争う中国・比亜迪（BYD）と米Tesla（テスラ）。電池を床下に敷き詰め、モーターやインバーターを一体化した電動アクスルを採用するなど技術的な共通点は多い。一方で、EVの商品力を左右する熱マネジメントシステム（Thermal Management System、TMS）には大きな違いがある。同領域の専門家であるY4ATECの山本祐司氏に、両社のTMSを全3回の連載で比較・分析してもらった。（日経Automotive編集部）

こんにちは、NE会社に勤めますきんじょう(@o0h_)がお送りします。 突然ですが、皆さんは「権限委譲」やっていますか？[1] 「権限委譲」というのが大げさであれば、「自分の持っていた仕事を他の人に任せる」くらいの感覚で、読み替えてみても良いかも知れません。 いかがでしょう？ 業務負荷の集中を避けたり、後進の育成を目的として取り組んでいる人も多そうにも思います。 ただ、実際にやってみると「意外に難しい」とも感じる場面があるのではないでしょうか。 あるいは、「やりたいけどやれていない」という難しさもあるかも知れません。 私はマネージャー業に就いてから、あるいは自分より「若手」の多い職場に所属したことで、色々な場面で「仕事を預ける・任せる・委譲する」という経験をしてきました。 また、上司などの他の人から「仕事を受け取る」側の立場になったことも、もちろんあります。 そんな実践の中で、自分なりに気

はじめに 新卒として、実務に入って3ヶ月目のお話。なぜかテストコードの正式な導入の動きにより、先輩から、「テストコードの規約かいて〜〜〜」と超ラフに言われ、「ん？」となりつつ、作りました。そんな中で、テストコードの作成やお試し実装などをしている時に、みんなこれハマるよな...というものをざっと上げてみます。 ユニットテストにおけるテスト自動化は、システムのテストにおいて最も難易度が高いと言われているそうです。その要因の1つとして、やはり注意すべき点や陥りやすい罠が多いことが挙げられます。この記事では、テストコードの一般的な罠に焦点を当ててみました。 対象の読者 今後、会社にユニットテストを導入しようと考えている人 品質管理をしているエンジニア テストコードに興味があるエンジニア 1. Over-Testing と Under-Testing テストをする上で、テストシナリオとして必要なもの