SIerから事業会社のエンジニアに転職後、SREチームのリーダーになって1年経過※したので、個人的なふりかえりのためにやったことを言語化し整理します。 ※ 本当は7月で1年なので先月書きたかったけど、7月は評価と目標設定に加えて障害対応などが重なりめちゃくちゃ忙しかった。。。 筆者の略歴SIerで10年半、インフラ主軸で大企業向けクライアントワーク＆技術支援 2021/10〜、NewsPicksのSREチームメンバーとして参画 2022/7〜、同チームリーダーになり、現在に至る SREチームの業務Googleが提唱した サイト信頼性エンジニアリング（SRE）がチーム名の由来です。SREはサービスの安定運用と変化への対応のバランスをとるためのプラクティス(技術的実践)なので、このプラクティスを遂行することがチームの業務と完全に一致するかというとそうではありません。 とはいえ、それを体現するチ

Overview of GitLab’s meeting best practices, which create efficient, transparent, documentation-based meetings On this page, we’re detailing how to create efficient, transparent, documentation-based meetings leveraging GitLab’s proven principles. This style of meeting increases cohesion, discipline, and transparency regardless of the work environment. GitLab meeting best practices “No agenda, no a

まとめ 良い進捗報告とは、自分が行っている作業やプロジェクトを順調に進めるのに役立つ手助けが得られやすい報告である 教員にとって良い進捗報告 学生が行っている作業やプロジェクトが自分の研究のプロジェクトの一部であったり、研究室で取り組んでいるプロジェクトの場合とそうでない場合では教員にとって作業の進捗の意味がある程度変わる。前者の場合は、自分のプロジェクトの一環なので、作業やプロジェクトの進捗がそのまま自分のプロジェクトの進捗に反映されるので、より真剣に、場合によっては過剰に干渉して進捗状況を制御しようとする可能性がある。後者の場合は、学生が順調に卒業／修了できるかどうかが興味の焦点になるので、学生が援助を求めてきたならば援助しようという程度の干渉の可能性がある。ここいらへんは指導教員の性格による。 どちらの場合にしても、教員が知りたいのは「どこまで進んでいるか」と「援助は求められていない

若手メンバーのスキルアップのための相談に乗っていると, うまい設計ができるようになる, 仕様の整理やメリット・デメリットの判断がうまくなる, あるいは技術の引き出しを増やすにはどうしたらよいか, という話がよく挙がる. この手の話題にいつも同じようなアドバイスをしていると気づいたので, 説明を楽にするために書き下しておく. ソフトウェア開発の話だけど, もしかしたら一般的な仕事のやり方の話だと思っても成立するかもしれない. 文脈 ソフトウェア開発のプロジェクトを進めるとき, 少人数の精鋭だけで開発するなら極論するとカウボーイコーディングでも成立するかもしれない. そうでなければ, たとえばスクラムのように, なんらか段取りをチームでマネジメントし, 不確実性を下げるためにどういう方法でアプローチするか検討し, 仕様を固めて細かいタスクに分解するプロセス(以降ざっくり「ソリューションを定める

ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス

先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス

EngineeringHow to write the perfect pull requestAs a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we've found it useful to remind ourselves what we aim for when… As a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we’ve found it useful to remind ourselves what we aim for when we communicate. We re

まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

まとめ 日報・週報を書くこと自体の意義は「自分が目的達成に向けて進んでいるのかどうか？」「目的達成に向けて進んでいるとしたらどこにいるのか？」を確認できることだと思う。これが確認できない日報や週報は自分にとって意味が無い。 はじめに えんじにあのたまご：研究報告についての考えで良い進捗報告のやり方を褒めていただいた。うれしい。なので研究報告について何か手助けできないか考えてみる。 自分の研究や作業を進めるために他人から良いコメントをもらうという観点は良い進捗報告のやり方で書いた。また、他人が気づきやすいように自分の努力を可視化するという観点は研究室でのアピールの仕方で書いた。なので、このエントリーでは、日報や週報を書くこと自体が自分にとって役立つという観点で何をどう書けば良いのかを考えてみる。 伝統と先輩を利用する 分野やテーマによって書くべきことは異なるので、まずは自分の分野および所属研

たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く

ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して