開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない） 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する

自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D

日本のみならず、海外でも孤独の問題が深刻化している。地域コミュニティが減少し、交流の多くが対面からオンラインへと移行した現代では、高齢者にみられるレベルの孤独感を訴える若者が増えているのだ。 最新の研究では、孤独感は年齢に合わせて「Uの字カーブ」を描くことが明らかになっている。“最も注意すべき年齢”と、その対策とは……？ 社交力も筋力のように衰える 2024年5月、学術誌「サイコロジカル・サイエンス」に掲載された研究では、孤独感はU字型の曲線を描くと報告されている。 自己評価による孤独感は、若年期から中年期に近づくにつれて減少する傾向にある。だが、60歳を過ぎると孤独を感じる割合がふたたび上昇し、80歳になるころには特に顕著になることがわかったのだ。 中年期の人々は、同僚や配偶者、子供や地域コミュニティの人たちと交流する機会が多いため、ほかの年齢層よりも社会的なつながりを感じやすく、人間関

性格診断、才能発掘、強みに目覚めよう。というような、自分自身を深く知るためのコンテンツをよく見かける。 説明文には「自分について不思議なくらい正確な説明が手に入ります」とか「あなたの才能はダイヤモンドの原石だから、磨いて輝かせよう」というようなことが書かれていて、自分の仕事ぶりやキャリアに不安があるときは、つい頼ってしまいたくなる。 自分自身もまだ知らない「本当の自分」に出会いたいという欲望がある。 自分の才能を知って、もっと自分に合う仕事を見つけたい。強みを活かして、自分らしく活躍したい。性格のタイプと相性を理解して、人付き合いを円滑にしたい。コンテンツはそういう欲望に応える。 人それぞれには得手不得手や、向き不向きがあるのだろうし、営業に向いている人と、デザイナーに向いている人が異なっているということは、直観的にも正しいように思える。 しかし、「本当の自分」という不確かなものに、どこま

絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の

はじめにある人間に「死にたさ」が上がってきたときに、それを打ち払う便利な思想を自分の人生経験から編み出したので、それを紹介したいと思う。 これは自分はリアルでたくさん言っているのだがなかなか言うべき機会も少なく、普及しないので増田にも書いておく。 いってみよう！ 仮に10億円あっても死ぬかテストこれはもっとも重要なテストだ。80%程度はこれで解決する。 「仮に10億円あってもまだ死にたいか？」と自らに問うてみて、直感的に出てきたその答えについて分析する手法だ。 「死にたさ」が上がっているときは「そんな夢みたいな荒唐無稽な話を聞かせてくれるな」などと言い出す人が多いが、それはすなわち「それが叶うなら生きてもいい」という証である。 ほとんどの問題はこれに帰着する。金があっても死のうとする場合は衝動的なものか、金持ちの道楽のようなものである。 「もし10億円あるなら死なない」という答えになった場

1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

面談してたら、プロジェクトがバタバタしつつも、１日中コード書いてるときが楽しかったのを思い出した。 人としゃべる能力は鍛えられていないので、人としゃべってても手応えないのだけど、コンピュータとやりとりしてると手応えある瞬間があって、そう比べると、コンピュータと向き合う仕事は簡単に感じる。 動いてるか、動いてないか、という瞬間を自分の手で確認できるのが、良い気持ちなのかもしれない。 ドミノ倒しを並べていって、期待通りに倒れるか、意外と倒れないか調べる、という行為に近くて、、ピタゴラスイッチやってるだけでお金をもらえてる、みたいな状況。 あるいは、ソフトウェアと対面する限りは、チームメンバーが思うように仕事してくれないんだよ〜トホホ、みたいなことがなくて、コンピュータは動くようにしか動かないよ、という、自由度のなさが、考えることを減らせる一因になってるのかもしれない。

先達エンジニアに学ぶ 思考の現在地 Online Conference の発表資料です https://findy-code.io/events/v7KebEabaBDzh?fr=event_20240416

先達エンジニアに学ぶ 思考の現在地 Online Conference https://findy.connpass.com/event/313119/

今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し

コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。 だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。 保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029) 却下と批判的立場 そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。 つまりレビュア

https://hachiojipm.connpass.com/event/304403/ の発表資料です

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6

デブサミ2024の発表資料です 16-A-1 Flight of a Decade:10年間の旅路と再会 庄司 嘉織[Launchable] https://event.shoeisha.jp/devsumi/20240215/timetable#day02

はじめに この記事について 以下の記事を読んでわりと「うんうんわかるわかる」と思いながら読みましたが、50歳に至るまでの間にもうひとつ別の景色も見えてきていたので、そのあたりを一度言語化してみようという試みです。 note.com フルスタックとは 上記記事へのブコメには「フルスタック」と書きましたが、自分としてはあまりフルスタックと名乗りたくない、という気持ちはありまして、普段は「ウェブアプリケーションエンジニア」と自称しています。 ただ、今回は、元の記事に合わせるために本記事における「フルスタック」の定義を定めておきます。 以下の領域の技術を理解し使える インフラ アプリケーションが動作するサーバや協調するミドルウェア バックエンド サーバーサイドのアプリケーションに用いる言語やライブラリ フロントエンド クライアントサイドのアプリケーションに用いる言語やライブラリ すべてを理解してい

株式会社オープンエイト、PMグループの辻です。 ここでは、プロダクトマネージャーとして働いています。ということで・・・ プロダクトマネージャーのしごと 少し前に話題になった本、皆さんも読みましたか？ この本は、これまでのプロダクトマネジメント関連の書籍と比べて、リアルな現場の目線に近いカタチで書かれており、参考になった以上に、とても勇気をもらえる１冊でした。 これまでのプロダクトマネジメント関連の本 どちらかと言うと教科書的なものが多い 参考にはなるが、自社や自分の置かれた環境で上手く実践まで持っていくのが難しい そんな印象を抱かれている方も多いのではないでしょうか？ これまでのプロダクトマネジメント関連の本。たとえば、コレ。 これはこれで、オススメです。 この本の特徴・効能 一方で「プロダクトマネージャーのしごと」を読むと、 世界的に著名なプロダクトマネージャーであっても、自分と同じよう

リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする

権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい