このエントリはMackerel Advent Calendar 2021の3日目の記事です。 最初にお断りしておくと、この話は4年以上前の昔話であり、私は既にMackerelチーム、はてな社から離れています。なので、ここで書くミッション・ビジョン・バリュー(MVV)はあくまで当時のものであり、今は別の形になっているでしょう。ですので、ここで書く話はただの昔話です。現在のMackerelに変に影響を与えたくはないと思っていることを予め書いておきます。 以前MVVの話を友人とした時に興味深く聞いてもらい、ユニークだとも言ってもらえたことがあったので、それらを決める過程の話や、浸透させようとした方法を書いてみるのも誰かの参考になるかもしれないと思い、これを書いています。 プロダクトマネージャー就任とMVV 私はMackerelのプロダクトマネージャーになった最初の頃に、MVVの策定に取り組みまし

スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア

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

前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が

「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流

この記事は、ex-KAYAC Advent Calendar 2018の17日目の記事です。 Songmuです。現在は、はてなと言う会社でチーフエンジニアとしてエンジニア採用等に関わりながら、プロダクトとしてはMackerelというサービスのプロダクトマネージャーを務めています。 カヤックには2011年から2014年まで在籍し、ソーシャルゲーム開発・運用のリードエンジニアを務めていました。主に甲子園シリーズのガラケー向けのタイトル運用が一番長く関わった仕事です。姫騎士と最後の百竜戦争というタイトルに企画から関わり、リリースから初期運用まで携わったのが最後の仕事でした。 カヤックは僕にとっては紆余曲折のキャリアを経て、30歳にしてやっと入った初めてのWeb企業です。複数台構成のWebシステムをスケーラブルにSPOF少なく構築し、それなりのトラフィックをさばきながら開発・運用する経験は初めてで

このエントリーははてなディレクターアドベントカレンダー2016の15日目の記事です。また、このエントリは先日の はてなエンジニアセミナー #7 でお話したことを、書き起こしたものでもあります。 Mackerel というサーバー監視・管理SaaSの開発チームのディレクターを務めている id:Songmu です。はてなのチーフエンジニアも兼務しています。 これまでの経歴としては、中国でITベンチャーの立ち上げに関わったり、その後語学学校で営業兼システム担当、SIer、Web企業でソーシャルゲームのリードエンジニアなどの経験を経て、2年ほど前にはてなに入社しました。 現在兼務している、ディレクターとチーフエンジニアという職位は、一般の企業では両方共課長格くらいで、W課長みたいな社内では珍しい立ち位置です。 Mackerelのディレクターとしては、プロダクトマネージャーとスクラムマスター的なことを

お題「エンジニア立ち居振舞い」 僕の前職のカヤックという会社では「コミュニケーションは取ったもん勝ち」という言葉が一時期よく使われていて、これは実際そのとおりだな、と思う。 僕自身はおおよそ社交的な人間ではないけど、以前から仕事をする上で自分からコミュニケーションを取りに行くことは意識している。意識してるけど、残念ながらできないこともあるのだけど。だから、ちゃんとできているかは定期的に自問している。 「コミュニケーションを取りに行く」とは例えば以下のようなこと。 不明確な点があったら自分からステークホルダーに聞きに行く 仕様を調整しに行く 偉い人に直接掛け合う 新しく入った人に声をかけに行く 話しかけづらいなと思われていそうな時にこちらから話に行く 声をかけることには誰しも勇気がいる。エンジニアは得てして怖がられがちというのもある。だからこそ自分から行くことを心がけている。声をかけたら大体