はてなブックマーク

ハードワークと長時間労働は違う。ハードワークの結果、長時間労働してしまうこともあるだろう。ただ、長時間労働は非効率だし、常態化しているのであれば見直した方が良い。当人達が満足しており、成果が出ていれば何でも良いのは確かだ。ただ、長時間労働を盲信するのは、改善の精神やストイックさに欠ける。 あなたの苦労はあなたにだけ価値がある 人間には、獲得した何かが同じであっても、自分の苦労が大きいほど価値があると錯覚してしまう特性がある。例えば以下のような現象だ。 ポケットマネーでパッと買った物よりも、頑張って貯金して買ったモノが大事に思える ちょっと試したらできたことよりも、習練を重ねて出来るようになったスキルの方が思い入れを持てる 大人が戯れに買った趣味の楽器より、子供が我慢して貯金して買った楽器の方が思い入れを持って練習に励めたり、苦労してリフティングができるようになった子の方が、その後飽きずにサ

良いチームが価値を生み出すのか、価値を生むのが良いチームなのかという鶏卵的な話がある。どちらを優先するかは組織のスタンスによると思っていた。私としては、つい内向きになりがちな性格なのでチームに向き過ぎないように元々気をつけていたが、今は「間違いなく価値が先」だと考えるようになった。 遠くて変化に時間がかかり、不確実性の高い外への価値創出から目を背け、身近で変化を起こしやすい目先のチームだけで安易に自己完結することは簡単だ。そのようなエコーチェンバーの中で内集団贔屓のバイアスを高めてしまうと、簡単に停滞し、澱み、腐敗し、カルト化する。そして、価値創出のサイクルが途絶えてしまう。 「価値とは誰かにとっての幸福である」 企業の目的は利潤追求だと言われがちだが、そうではない。企業の目的は価値創出である。その価値創出を継続する為に合理性が必要なのだ。合理性の中でも今の資本主義経済においては経済合理性

「そろそろ5分経ちそうだけど、デモまで始めちゃって大丈夫なのか…？」 ハラハラしながら息を飲む聴衆。デモを完走して発表を終えたら大拍手でガッツポーズ。間に合わず、無情にも銅鑼が打ち鳴らされて発表が中断になり、名残惜しそうに壇上を去る発表者にもナイストライの拍手が贈られる。Lightning Talk (LT) とはそういうものだ。 切られてしまった発表に対して聴衆も「続きを見たかったのにー」と思い、その後の懇親会などで話しかけて答え合わせするのもLTの醍醐味だ。 LTは5分 LTが5分なのは間違いない。それはコミュニティから生まれてきた、言ってしまえばそういうルールのゲーム名なのだから。だからLTを企画するならば5分にするのが筋だし、10分にしてしまったら単なるショートトークだ。 シニアな人達がそういう原理主義的に聞こえる主張をするから、怖く感じられ「5分できちんと発表を終わらせられないと

少し前にエンジニア採用に携わっていた頃は、XのDMなどでスカウトを送っていた。丁寧に文面を考えていたので、一通に大体15~30分かかっていた。それもあって、スカウト返信率は70%を超えていた。そういう僕のスカウト文を見て「これはAIでは書けない文章だ」と誉めてくれる同僚もいた。 実際、僕はスカウト文を作るときに最近の生成AIは使っていなかった。ただ、生成AIでスカウト文をいい感じに書いてもらうことも全然できるだろう。やっている人もいるだろうし、それは全く否定しない。単に、僕の個人的なポリシーとして、文章を書くときには「まだ」生成AIを使わないようにしているというだけだ。 別に、未来永劫使いたくないという話ではない。今はこの新しい道具を自分に馴染ませていくフェーズなのだ。実際、文章を書く以外のリサーチや、ちょっとしたコードや画像の生成に生成AIを使うことはもはや日常になった。 それでもなお、

この記事はジンジニアアドベントカレンダー2024 25日目の記事です。 人事選考で安易に使われがちで、避けたほうが良い判断軸の項目に「コミュニケーション能力」や「地頭」があることが良く知られています(要出展)。ここではなぜコミュニケーション能力を問わないほうが良いかについて論じます。 コミュニケーション能力4象限 コミュニケーション能力を同質か多様か、能動か受動かという2つの軸で以下の4象限に分けてみます。 コミュニケーションスキル4象限 内訳をざっと細分化すると以下のようになるでしょうか。 同質な人に共感する シンパシー 共感力 親和性 同質な人に共感してもらう 共鳴力 信頼構築力 受容力 多様な人を理解する エンパシー 寛容力 異文化理解力 多様な人に理解してもらう 説明能力 発信力 橋渡し能力 一言でコミュニケーション能力といってもこのように様々な要素が含まれており、個々人の認識のズ

エンジニア大好き「推測するな、計測せよ」。これは、Plan 9, UTF-8やGoの作者としても知られる、Rob Pike氏の Rob Pikes's 5 Rules of ProgrammingのRule 3.に由来すると認識している。以下に原文を引用する。 Rule 3. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rob Pike's 5 Rules of Programming 訳すと以下のようになる。 「計測せよ。計測するまでチューニングをするな、そしてそこが支配的じゃないならチューニングするな。」 要は「チューニングする前に計測せよ」という主張で「推測」と言う言葉は出てこない。なの

tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ

エンジニアに限らず、BlogやTwitter、OSS、登壇など、対外発信力がキャリアにおける強力な付加価値になることは知られるようになりました。 英語力がそうであるように、発信力は必ずしも必須スキルではありません。英語ができなくても活躍しているエンジニアはいくらでもいます。同時に英語がそうであるように発信力が有力な付加価値をもたらすスキルであることは事実です。 私自身、発信力が強みになっている分バイアスがあるので、あまりそのスキルの価値を過大評価して他人に押し付けるようなことはしたくありません。それに、エンジニアだったら発信力などではなく、純粋な技術力で評価されたいよな、という青臭い気持ちもまだどこかにあります。 ですから、全員が発信すべきだとは考えません。ただ、対外発信に興味を持っている人は後押しはしたいし、そういう人が増えてほしいとは強く思っています。なぜならば、それが単純に楽しいから

私がWeb業界に入ったのは、ハッカーに対する憧れからです。その原体験を大事にしたいという気持ちを今でも強く持っています。 もう20年近く前になりますが、Web2.0の時代、私は傍観者でした。世界ではGoogleを筆頭として、日本でも、はてな社などが、エンジニアドリブンで個性的なサービスを生み出していました。他にもmiyagawaさんなど、個人で世界的に使われるようなOSSを開発している人もいました。書籍「ハッカーと画家」で描かれるような、ハッカーが個人技で大企業を出し抜く痛快さがありました。 そのように、WebサービスにせよOSSにせよ、同年代のハッカーが自分の技術でイノベーションを起こし、世の中に影響を及ぼしていることに羨望の眼差しを向けていたのです。 サブカル的な空気感も好ましく思っていました。西海岸のコンピュータ文化はヒッピーカルチャーの影響を受けていたのは間違いないでしょう。当時の

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

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

タイトルのようなエントリを社内に向けて書いたので、手直しして社外に放流するものである。 社内で情報共有フローやガイドライン整備などを進めている。ルールは少ないに越したことはないので「ルール作り」にはしたくなくて、考え方やガイドラインみたいなところに留めて、文化や共通言語を醸成していきたいとも考えている。 これは、今後組織が大きくなる上で、「スピードを落とさないため」に必要だと考えている。新しく入ってきた人が立ち上がりを早くパフォーマンスを発揮してもらえるようにしたい。 オンボーディングの整備は大事で、それもやっていかないといけない。でも今のフェーズではどうしても未整備の部分も多い。そういう荒地を楽しんで走破できる自走力があって、自分で決めて整備もできて、組織と一緒に成長してくれる人を採用していきたい。なので「自走しやすい環境」を整えたい。そのために必要だと考えている点が以下の3点です。 デ

私たちは、スタートアップの実践、あるいはスタートアップに関わる活動を通じて、より良い突破口を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。 組織よりもプロダクトを 成熟よりも成長を 分析よりも行動を スマートさよりも泥臭さを 冗長性よりもユニークさを 真面目さよりも面白さを 価値とする。すなわち、左記の事柄に価値があることを認めながらも、私たちは右記の事柄に、より価値をおく。 このマニフェストについて 主語が大きい! おわかりかと思いますが、これは「アジャイルソフトウェア開発宣言」のオマージュです。ほかにも、「やっていき宣言」などありますね。 先日、スタートアップのCTOになりましたが、僕自身まだまだ覚悟が足りないことを重々自覚しているので、自分を叱咤するためにも書き出してみた。採用を含め、今後組織を成長させていく中で、果たしてスタートアップとはどういうものなのか、

前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでに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のディレクターとしては、プロダクトマネージャーとスクラムマスター的なことを

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