はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕

長永健介（@kyanny）と申します。現在はGitHubで働いています。10年前、「いつかここで働きたい」と夢見た会社です。 私は子供の頃から「考えること」が好きでした。難しいこともくだらないことも、真面目に考えて自分なりの意見をまとめる癖がありました。成長するにつれて私の思考様式は洗練され、Webとブログに出会ったことで「書く」という手段に昇華されました。書くことで考えていることを言語化し、言語化した自分の考えを読みながらさらに考えを深める ── この活動を繰り返すことで、起こりうる問題に備えたり、問題を多角的に見つめて活路を見出してきました。 とりわけキャリアの選択において「(思考|志向)を言語化する」習慣が大いに役立ちました。この記事では私のキャリアにおけるいくつかの選択と、その時々で考えていたことについて紹介します。 望んでなかった「けものみち」を変えた日記の言葉 Shut the

こんにちは。ソウゾウの Software Engineer (CTO) の @suguru です。連載：「メルカリShops」プレオープンまでの開発の裏側の1日目を担当させていただきます。 7月末にメルカリShopsという新しいサービスが公開されました。メルカリShops は、2021年1月にメルカリのグループ会社として設立したソウゾウが新たに立ち上げたサービスです。 この記事では、メルカリShops を作るにあたり、どういった技術、アーキテクチャを選定したのか、その背景と意思決定をまとめて共有したいと思います。 monorepo まず最初にプロジェクトをスタートしたときに、サービスのリポジトリを作るのですが、迷わず monorepo による構成を選択しました。monorepo は、システムを構成する複数のコンポーネントの独立性を保ちつつ、全ての構成を1つのリポジトリで管理する手法です。今

Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。 マネジメントを始めて悩んだこと 約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー（以下、EM）としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。 そんな中で常に「自分がマネージャーとしてきちんとできているのかが分からない」という不安を持っていました。また、どんなスキルをつけて、どうなれたら正解なのかというイメージが見つからず悩んでいました。 ある時、先輩との1on1で、「（メンバーとの1on1やメンバーの育成を）どうしてそれをやるのか」と問われ

Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す

はじめに デザインパターンって常識っぽいからちゃんと学んでおかないとと思いつつ、いまいちよく分からないままな人って意外と多いんじゃないかと思い、絶版になってることもありまとめてみることに。2章は基本的なRubyの文法の解説なので省略。 変なところあったら教えてくださいね。 対象 デザインパターンを避けてきた人 Ruby以外が不得意で、巷に多く出回っているJavaなどのデザインパターンの本が読みたくても読めない、もしくは読むのが面倒な人 Rubyによるデザインパターン買いそびれた人 Rubyによるデザインパターンとは ラス・オルセン 著、ピアソン・エデュケーション（2009） GoFによる23のデザインパターンのうち著者が特に有益だと考える14パターン ＋ Ruby独自の3パターンの解説が書かれている。 実際にデザインパターンが使われている例として、RubyやRailsの内部のコードが出てく

r7kamuraと言います。2020年9月頃からANDPADの開発に参画しています。 2021年2月、ANDPADで利用しているWebアプリケーションフレームワーク Ruby on Rails (以下Rails) のバージョンを5.2から6.0にアップグレードしました。今後アップグレードを行う方が同様の作業を行えるよう、今回の変更に伴い必要となった作業について、あらためて言語化してこの記事で共有できればと思います。 全体の流れ 大まかに分けると、今回は次のような手順で作業を進めていきました。 Rails 5.2系の最新のバージョンに上げる Rails 6.0版のブランチを用意してテストを通す Rails 5.2と6.0に両対応したコードに変更する Rails 6.0で検証を進める Rails 6.0に本番環境を切り替える Rails 5.2向けの対応を取り除く Gemのバージョン変更 Ra

Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり

浄土真宗の僧侶です。初めて書き込みます。 不慣れなため、先ほど書いた文章がすべて消えてしまい心折れかけましたが、やはり大事なことなので、増田さんに伝わればと願って改めて書き直します。 お祖父様のことをお悔やみ申し上げるとともに、今回このような形で、増田さんやお母様が悲しまれる結果になってしまったこと、痛惜に堪えません。 結論から言わせていただくと、リモート葬儀それ自体に否はありません。そんなもので台無しになるのが仏の教えならば、仏法は2500年も受け継がれたりなどしません。 私から言わせれば、死者を軽んじ、葬儀を台無しにしているのは、ご親族の方だと思います。 葬儀とは「弔(とむら)い」であります。弔いとは元来、「訪(とぶら)い」という字を用いました。これは遠近様々な場所から死者の元へと人々が訪れる様子を意味していますが、決してそれだけではありません。 死者に出会うということは、まだ生きてい

はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も

どうも、 株式会社Progate で SoftwareEngineer チームのマネージャーをしています @satetsu888 です。本記事は Progate AdventCalendar 2020 10日目です。 普段仕事ではエンジニア組織のことやプロダクトの技術戦略的なことを考えたり、ミーティングしたり採用活動したりタスクをお願いして回ったりなどを担当していますが、今日はそういうのとはなんの関係もないただの日常の話を書こうと思います。 ことの始まり 我が家では子どもの朝ごはんとして週に2,3回くらいの頻度でポケモンパンを買っています。 先日(2020/09/18 ~ 11/24) ポケモンパンについてるポイントを5点集めるとポケモンシールホルダーの抽選に1回応募できるキャンペーンがありました。（キャンペーン自体はすでに終了しています） いつも通りのペースでパンを買ってると何回か挑戦で

オープンソースのCI/CDツールとして広く知られているJenkinsを開発した川口耕介（@kohsukekawa）さんが新たに友人と立ち上げたLaunchable（ローンチャブル）は、データサイエンスの技術を利用したテスト自動化のプラットフォームを提供すると表明しており、開発プロセスの改善をさらに推し進めるスタートアップとして注目されています。 このLaunchableにプリンシパル・ソフトウエア・エンジニアとして参画したのが、庄司嘉織（@yoshiori）さん。ソフトウェア開発者のキャリアを25歳でスタートし、Javaエンジニアとしてさまざまな経験を積む傍ら、若手エンジニアによるjava-jaというコミュニティも取りまとめてきました。 未経験のRubyにチャレンジしようと転職したクックパッドでエンジニアリングマネージャーや人事部長まで務めるなど、複数の領域で多様なキャリアを歩んできた庄司

結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア

Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5

単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理

こんにちは。コネクト支援チームの@tignyaxです。 みなさま、夏はどう過ごされたでしょうか？ 私は、夏が好きなのに今年は夏らしいことが出来なくて寂しいなぁとなっています。。。 さて、今年2020年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2020年のエンジニア新人研修について 基本的には2019年と同じ形*1での実施となりました。 最初の1週間で必修講義をしたあと、新人の皆さんには2週間ずつ3チームを体験してもらいました。 チーム体験のコンセプトは、新人に「興味のあるチームで実際に業務を体験し、配属希望を決める参考になった。」と言ってもらうことです。 各チーム体験では座学や研修を中心にするのではなく、業務体験が中心です。 チーム体験を通して、配属先を検討する材料にしたり、いろんなチーム/人/業務を知ってもらえる機会となります。 必修講義 誰に: 開発/

私はコンサルタントだった時、上司から 「コンサルタントは意思決定するな」と口を酸っぱくして言われた。 「特に人事。人事に関しては、意見表明もできる限り避けること」 とまで言われた。 例えば、「ウチの取締役、どう思う？」など、人の印象について聞いてくる経営者は少なくない。 確かに、結構怖い質問だ。 その一言が、どのように波及するかわからないのだから。 それに対しては 「社長のお考えを聞きたく」と言い、はぐらかせ、というのだ。 要するに、リスクヘッジである。 「それでも、意見を求められたら、どうしますか？」と質問すると、 「それを言える立場ではないと言いなさい」と指導された。 ＊ しかし後日、一人の経営者に意見を求められた時のこと。 社長は「あいつのパフォーマンスについて、どう思う。」と私に尋ねた。 あー、答えちゃいけないやつだ、と思い、「社長のお考えを聞きたく」というと、 「意見を求められた

皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

まだ駆け出しの頃に私が働いていた会社で、会議やミーティングで「開口一番見当違いのことを言う人」がいました。 その人のことを、仮にYさんと呼びます。 Yさんはベテランのエンジニアで、その時点で既に枯れていたある技術について、極めて深い知見を持った人でした。 一方新しい技術についてはそれ程知識がなく、ご自分でも「技術知識をアップデートするのが大変」というようなことをちょくちょくお話されていました。 気さくで良く笑う方で、若手にも気軽に話しかけられていました。 私も何回か缶コーヒーをおごってもらったことがあります。 Yさんを慕っている人も多い一方、「あの人距離が近すぎて苦手」という人もそこそこの数いた記憶があります。 人見知り多かったんですよ、その会社。パーソナルスペース激広の人がやたらたくさんいました。 で、当時の私には、Yさんについて一つ「不思議だなー」と思っていたことがありまして。 何かし

speakerdeck.com 去年の10月にAWS DevDayに招待いただいて話した資料を今更公開します。 現状のシステムを説明するとともに、僕が入社後取り組んだ細かい取り組みについての内容になっています。現状の規模の雰囲気を掴んでもらうために最初の方は製品や会社説明っぽくなっていますがご容赦ください。 Nature Remoは所謂IoTサービスで、システムの裏側が気になる人も多いんじゃないかと思いますが、実は結構オーソドックスなWebシステムで動いています。メインは、Amazon ECS上で動くGoのWebシステムで、IoTデバイスであるNature Remoの通信もWeb Socketが用いられています。 IoTの世界ではありますが、実は普通のWeb技術が使われているのが面白いポイントです。 エンジニア積極採用中です! Natureではこのシステムをより良くしてくれる「普通の」We