数字で振り返るMercari Engineering Blogの1年間 | メルカリエンジニアリング
こんにちは。メルカリEngineering Officeの@yasu_shiwakuです。この記事は、Mercari Advent Calendar 2022 の2日目の記事です。 本記事では、技術情報の発信をおこなっているMercari Engineering Blogの定常的な計測を実施した経緯と、Engineering Blogを通じたここ1年間のおおまかな技術広報活動について振り返っていきます。 Engineering Blogについて Mercari Engineering Blogとは、メルカリのエンジニア組織が技術情報の発信（技術広報活動）をおこなっているプラットフォームの一つです。 技術情報の発信という文脈では他にもYouTubeチャンネル やDev Twitterなど、開発者向けの情報発信をおこなっているチャンネルはいくつかありますが、2015年に開始したMercari
1 年を通して理解した CTO としての職務｜めもりー
はじめにみなさん，こんにちは。めもりーです。株式会社トラーナで執行役員 CTO になってから 1 年が経過しようとしているので，来年の所作も踏まえて，そろそろ記事にしようかなと思っています。 1年間 CTO としてどうだったか正直，CTO という職務が何をするべきか，常々悩んでいます。 上記の記事のように私の中では CTO の職務というのは "技術資産を常にフル活用できる状態にすること（意訳）" だと定義しました。 もちろん，会社によっては CTO は「技術のプロフェッショナルでテックリードの上に起つ存在である」であったり「ボードメンバーの一人として，経営に携わり技術的な意思決定をする」であったり「課題を洗い出し，技術的にどのように解決できるかのリードをする」といったり，十人十色だと思っています。 その中で，私自身の答えとしては，上記の技術資産の活用であると導きだしているものです。 CTO
ドリコム勤続20年～ベンチャーやお金の話～ | 外道父の匠
という感じで、特別に学歴が高いとか、小さい頃からコンピューターに触れてきたとかなくて、強いて言うなら３歳からゲーマーだったというくらいです。あとわざわざ北海道を出たのは、雪と寒いのが嫌いだからです。 振り返ってみると、入社からたった４ヶ月程度で退学を決心してて狂気ですね。決心した後は、まず社長に相談して、当時のバイト代だと生きていけないので、もう１つバイトしようと思います～って話したら、即断で社員になればいいじゃん。って流れになり、当時は役員とバイトだけだったため、めでたく正社員第一号になりました。 んで親に電話して、やりたいことが見つかったことと、今辞めれば後期の学費かからないよ！とか意味不明な説得したりして、なんとか了承を得ました。友達には全員に勿体ないと言われましたが、逆にこれが正着なんだと俄然やる気でました。 今現在、当時の生き残りは俺と社長だけですが、要所で即断即決できるってのは
技術記事を書かないプログラマへ向けた記事
はじめに 今回の記事では効率的に技術記事を書くための具体的なテクニックは取り扱わない。技術記事を書くことのメリットや技術記事を書く上で重要なマインドセットを中心に徹底解説する。 要旨：プログラマーは積極的に技術記事を書くべき 私たちプログラマーは積極的に技術記事を書くべきだ。TwitterでもQiitaでもこのZennでも構わない。とにかく何でもいいので、自分の学びや気づきを記録してそれを公開する習慣をつけよう。自分で学んで得られた知識や気付き、新しい価値観をまとめる作業は自分にしかできない。 記事を書くべき理由 記事を書くべき理由はざっくり以下の通り。 知識が定着するから 説明する能力が上がるから プログラマーとしての人となり(興味のある技術やプログラミングに対する価値観、説明する能力など)を知られるから それぞれ順番に解説する。 知識が定着するから 知識を定着させるための最高の手段は、
ねばり強く問題に向き合えるかという資質 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 先日、ISUCON12のオンライン予選に三人のチームで参加しました。本戦には進出できませんでしたが、目標の「スコアをゼロでなく、きちんと出せる形で終わること」「楽しむこと」の二つは達成することができました。 久しぶりに一日アプリケーション開発のことだけ考える時間を持てた気がします。自分の場合、普段はどうしても会議やいろいろやらなければならないことが多く、なかなかまとまった時間を取ることができていませんでした。定期的にそうした時間を取れるようにしてみようかな、と思ったりしています。 さて、ISUCON12オンライン予選への参加を通じて、エンジニアの資質としてあらためて「ねばり強さ」というものがあるなと感じました。何か問題が起こったとき、あるいはわからないことに遭遇したときに、一歩一歩解決に向けて考えたり、調べたりしながら手を動かし続けられる能
自チームのエンジニアに System Design Interview をやってみた - pospomeのプログラミング日記
エンジニアのスキルレベルチェックという文脈で System Design Interview が気になっていたので、自チームのエンジニアにやってみた。 System Design Interview とは? どうやって実施したのか? 実際にやってどーだったか? エンジニアとしてのレベル感がそのまま結果として出る傾向にある コミュニケーション能力 得意分野と不得意分野が明確に出る 出題する側も難しい Spannerへの圧倒的な信頼 まとめ System Design Interview とは? ググれば出てくるので説明は割愛します。 どうやって実施したのか? チームメンバーには System Design Interview のことは伏せて、 ミーティング開始時に「System Design Interview をやります」って感じで始めたので、 System Design Intervie
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】 - MonotaRO Tech Blog
はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか？その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても
問題を解決するために必要な習慣 / developer-lifehack
Hamee様 開発合宿 2021年（後半戦）の資料です。 # 参考リンク - https://soudai.hatenablog.com/entry/2020/08/14/101657 - https://soudai.hatenablog.com/entry/2020/10/06/161705 - https://soudai.hatenablog.com/entry/2020/12/31/165940 - https://this.aereal.org/entry/2020/12/18/115317 - https://blog.sushi.money/entry/2020/12/18/133356 - https://twitter.com/pyama86/status/1455842485482057734 - https://www.1101.com/umeda_iwata/20
働きながら3週間で応用情報技術者試験に合格した話 - 下町柚子黄昏記 by @yuzutas0
概要 IPAの応用情報技術者試験（平成26年/秋試験）に合格しました。 仕事をしながら3週間で合格できたので、勉強法など知見を共有します。 平成27年度【春期】【秋期】 応用情報技術者 合格教本 (情報処理技術者試験) 作者: 大滝みや子,岡嶋裕史出版社/メーカー: 技術評論社発売日: 2014/12/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る どのような資格か IPAのサイトでは、対象像を「高度IT人材となるために必要な応用的知識・技能をもち、高度IT人材としての方向性を確立した者」としています。 難易度としては、「ITパスポート」＜「基本情報技術者」＜「応用情報技術者」＜「高度区分」（システムアーキテクトや情報セキュリティスペシャリストなど）という位置付けです。 要するに情報技術に関する幅広い知識を持っていることを証明するための資格試験ということです。
ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide
2021年度リクルート エンジニアコース新人研修の講義資料です
「仕事のコード」を残す際のチェックリスト｜Uchio Kondo
最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記＠2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に
既存の機能から設計を学び、調査力を向上させて、知見を共有しよう - Hatena Developer Blog
はてなブックマークチームの id:itchyny です。 チームのメンバー間で知見を共有することは、とても大事なことです。 特に開発エンジニア同士のコミュニケーションを増やし、お互いに足りていない知見を共有し合うことでチームの生産性を向上することは、プロダクトの成長につながります。 プロダクトの実装や設計の知見を共有するためによく取られる方法として、詳しい人が講義形式で教えるというスタイルがあります。 特に、チームに新しいメンバーが入ったときには、プロダクトの概要やコードのアーキテクチャについて説明することは一般的に行われています。 講義形式で教えるというスタイルはよく行われる方法でありながら、いくつかの課題があると感じています。 まずは説明会に参加するメンバーが、どうしても受け身になってしまいます。 説明された瞬間は分かったような気になっていても、次の週には忘れてしまうことはよくあること
エンジニアのブログ探訪 カテゴリーの記事一覧 - 週刊はてなブログ
「エンジニアのブログ探訪」第7回は、日常生活からハードウェアの話題まで幅広く記事を執筆しているからあげさんにお話を伺いました。からあげさんのブログ継続のモチベーションや情報発信のスタンス、ネットでのつながりで広がったさまざまな可能性などにつ…
新人の方によく展開している有益な情報 - Qiita
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアの個人ブランディングと技術組織
出来るプログラマーやエンジニアの方でも「何をやっているか分からない」「何が分からないか分からない」状態に陥りますか？その時は、どの様にして対処・解決しますか？
noteのフロントエンドApp分割
ハックの学び方、の学び方
