スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog
今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し
手を動かさないマネージャーを試している - id:onk のはてなブログ
2 月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください！— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
期待値をチューニングする - id:onk のはてなブログ
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営，運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking（建物・土地などの） caretaking〈英〉（学校などの公共施設の） charge conduct（業務などの） control custody（大事な物の） d
初めてのスクラムをやってみての反省点 - ドワンゴ教育サービス開発者ブログ
はじめに こんにちは、lenです。 現在自分はバックエンドセクションのメンバーとともにある改善プロジェクトに参画しております。 そのプロジェクトでは、スクラムを用いてプロジェクトを進めていますが、初めてのスクラムだったので困ったことや反省点についてお話していきます。 スクラムについて スクラムをするにあたり、弊社のエンジニア研修での課題図書でもある SCRUM BOOT CAMP THE BOOK(翔泳社) をあらためて読み直しました。 そこでは、スクラムとは以下の特徴があると述べられています。 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化します。 スクラムでは固定の短い時間に区切って作業を進めます。 現在の状況や問題点を常に明らかにします。 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題はないか
[レポート]ニコニコでのクラウド活用、その意思決定とアーキテクチャ #AWSSummit #CUS-36 | DevelopersIO
アジェンダ ニコニコの開発組織のふりかえり クラウド活用のテーマ設定 組織のビジョンが大事 現状のアーキテクチャのご紹介 経緯を踏まえたもの 推進活動 技術解決以外にも紹介する ニコニコの開発組織のふりかえり ニコニコの開発 = 大規模オンプレミス環境 ドワンゴのスコープでは教育事業ではAWSを使っていたがニコニコではオンプレミスばかりだった 多くは今でもオンプレミスで稼働している しかしオンプレミス環境としてはかなり整備されていると感じる オンプレミスの社内マネージドサービスがあることは大きなメリット インフラチームに申請すると構築されて、運用の設計も施されてSlack通知とかも完備していた 調達購買もインフラがやってアプリチームは開発に集中できていた しかし、社内マネージドサービスの範囲でも収まらない要件が増えてきた AWSなど別のインフラを利用する場合には選定からやらないといけなくて
![[レポート]ニコニコでのクラウド活用、その意思決定とアーキテクチャ #AWSSummit #CUS-36 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/512354a3cd4a8ad18df5d98d26423785c2b82fc1/height=288;version=1;width=512/https%3A%2F%2Fd1tlzifd8jdoy4.cloudfront.net%2Fwp-content%2Fuploads%2F2023%2F04%2Fbnr_AWS_smt_tokyo2023_1200x630_SR.png)
若手エンジニアに伝えたい設計の三つのノウハウ | Offers Tech Blog
はじめに こんにちは。 プロダクト開発組織・人材を対象に、開発パフォーマンス・生産性の最大化インフラ Offers MGR と副業転職プラットフォーム Offersを運営する株式会社 overflow のエンジニアの藤井です。 みなさま、実装の前にきちんと設計のドキュメントを作成していますでしょうか？ 昔、私が働いていた大手 SIer の現場では、 ・・・といったように、じつに事細かな設計工程が組まれておりました。 しかし事業会社の開発組織で、このような工程を採用している現場は稀でしょう。 特にスタートアップの、ごく少人数でビルド＆スクラップを繰り返す製品のローンチ段階では、"<b>実装こそ仕様！ ドキュメントなどない！</b>"というストロングスタイルが必要だったりします。 そのため、その後もドキュメントを残す文化が根付きづらい、という話もよく聞きます。 (その点、弊社はドキュメンテーシ
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18
600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw イベントURL https://forkwell.connpass.com/event/269125/ データ指向アプリケーションデザイン https://www.oreilly.co.jp/books/9784873118703/
GitHub - evilmartians/mono: Free and open-source monospaced font from Evil Martians
Martian Mono is a monospaced version of the Martian Grotesk font for code style design. It inherits Grotesk’s brutal and eye-catching aesthetics as well as all of its benefits—metrics equilibrium, readability and intelligibility, and convenience for web developers and designers who believe in a systematic approach to design. 👉 Get your Martian Grotesk free trial on Gumroad or buy it on MyFonts to
GitHub - hashicorp-forge/hermes: A document management system
Sign up for a Google Workspace account. Create a Google Cloud project. Enable the following APIs for Google Workspace APIs Admin SDK API Google Docs API Google Drive API Gmail API People API Also, to enable searching for users, the Google Workspace domain admin needs to enable external directory sharing. See more details: https://support.google.com/a/answer/6343701 Select Directory Setting >Sharin
Introducing Hermes, An Open Source Document Management System
TerraformInfrastructure as code provisioning
開発者ブログ運営2年目の取り組み - ドワンゴ教育サービス開発者ブログ
この開発者ブログの運営体制を作ってから2年が経ちました。 2年目には開発者ブログの運営・執筆体制を固めるような施策をいくつか実施しました。 それら施策と、2年目に得られた成果について紹介します。 1年目の取り組みは以前の記事で紹介しています。 基礎的な運営体制は1年目に確立していますので、興味のある方はそちらもご確認ください。 2年目の取り組み 記事の公開予定カレンダー CI環境の整備 「技術ブログ」から「開発者ブログ」に用語を統一 PVなど数値の取得 成果 執筆者の拡大、記事の増加 ストック記事の活用 We are hiring! 2年目の取り組み 2年目には以下のような施策を実施しました。 執筆者の拡大や、それに伴う編集体制を整備しました。 記事の公開予定カレンダー CI環境の整備 「技術ブログ」から「開発者ブログ」に用語を統一 PVなど数値の取得 記事の公開予定カレンダー 記事の公開
目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021
https://fortee.jp/phperkaigi-2021/proposal/42ce8b07-6972-42bb-a2ac-96af7249cfa4 あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。 いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。 そして、上記を補完するためにしばしばドキュメントが書かれます。 私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。 私はこれを「Documentation as Code」と呼んでいま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pulumi - Infrastructure as Code in any Programming Language
Git研修【MIXI 23新卒技術研修】
エンジニアリングマネージャーの理想と現実
GitHub Actionsと"仲良くなる"ための練習方法
Rustで作るテトリス風ゲーム入門
Rust の嬉しさをより多くの日本語話者に知ってもらうためには、スタンフォードで強く敷かれている educational benefit の概念を Rust コミュニティが抱くことが大事なのではないか、という私見
デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developers
