Posts

昨日は2022 年の仕事の振り返りを行っていましたが、本日は 2023 年にやりたいことを整理しておきます。振り返りでは仕事のことだけを書きましたが、折角なのでプライベート含めて書いてみます。 (仕事) 「エンジニアリング × 組織開発」の能力を高める 仕事の目標としては「素晴らしいプロダクトを作ること」の一言ですが、自身の責務であるリードエンジニアとしての能力を高めることがそれに繋がると考えています。 能力と一言に言っても、以前記事に書いたようにリードの役割は会社ごとに異なりますし、また会社のフェイズや個人の資質によっても行うべきアクションは異なります。 その上で、現在の自身の興味とチームの課題に沿ったものの中で「エンジニアリング × 組織開発」に主軸を置いて「設計、マネジメント、事業理解」の 3 要素を高めていきたいと考えています。 1. 設計 設計、コーディング、レビューなど各実装フェイズにおける仕組み・指針の整備をする これらのプロセスでは統一された仕組みや指針がなく属人化している部分が多く、短期的にも長期的にも開発チームのパフォーマンスに悪影響があります。 今季、よりチームがスケールしていく中でも、仕組みや指針があることで、チームの生産性向上に寄与出来ると考えているので、ここに注力して挑戦していきたいです。 サービス内の技術やドメイン技術に関する広範知識の向上に努める インフラ含め、サービスで使われている開発技術や、決済等のドメイン独自の技術など、まだまだ明るくない部分も多いため、チーム内で議論出来るだけのベースをしっかり築きたいと考えています。 2. マネジメント (対チーム) 開発プロセス・チーム改善ロードマップを元に、各メンバーが興味関心で活躍し、チームを改善できる仕組みづくりをする 前回の記事でも軽く触れましたが、事業のロードマップではなく、開発プロセスやチーム改善のロードマップを作成し、見える化しようと考えているため、ここをしっかり突き詰めていく。 MTG 改革をして、より良いファシリテーションが生まれるようにする リモートワークファシリテーションのまなびでも書きましたが、現状の MTG には課題感も多く、またチームのフェイズとしても、各々が MTG に責務を持つタイミングになってきたと考えているので、チームで MTG のファシリテーションが出来るような仕組みを作っていく。 (対 PJ) 見積もり・スコープ、優先度の設計をチームに浸透させる プランニングポーカーやインセプションデッキなど、アジャイルのツールを少しずつ PJ に導入し始めた 2022 年なので、2023 年は全社の PJ に浸透させ、ツールから得られる一つ一つの体験の質も高めていく。 開発仕様の見える化・簡素化でチームで仕様が把握できるようにする 複雑な仕様の見える化が出来ておらず、QA やレビューや PJ 後のリファクタリングなどで実装者以外のエンジニアが関わる際に仕様把握がネックになっている課題があるので、ここをもっとクリアにできるような仕組みや構造化を行う。 3. 事業理解 事業ドメインの解像度上げる 業務にあわせて UI/UX デザインを変えるのではなく、UX デザインにあわせて UI と業務を一緒にデザインしていく 前回の記事でも上記書いたように、まさにプロダクトのフェイズが変わって、シンプルな機能開発ではなく、プロダクトの本質を突き詰めた開発が必要になってきたので、そのためにも事業ドメインの解像度を上げる。 事業部とエンジニアチームの連携強めていく 事業ドメインの解像度をあげるためにも必要ですし、また機能を実際に適切な運用に落としていくためにも事業部との繋がりはより蜜にしていく必要があるため、ここの連携が出来るように動く。 (個人開発) 個人開発のアプリやっていく！ 仕事以外の個人開発に関しては下記二つを挑戦したいと思っています！ Omoidata をもっと使いやすく、もっと使って貰えるように 自作アプリを 3 年間使い続けてみての記事でも書いた日記アプリをもっと使いやすいアプリにします。...

こんにちは matinana です。 あっというまに今年も残り２日になってしまったので、今年の仕事の振り返りを行おうと思います。 1 月 エンジニア２名、週 2.5 日稼働の業務委託 1 名の計 3 人のエンジニアチームに 2 月から新メンバーが来ることになり、オンボーディングやドキュメントの整理を行っていた一月でした。 サービス自体は 2019 年から始まっていて、社外へのアウトソースをはじめ色んなエンジニアが入れ替わりになって作ってきた大きなサービスですが、結果として暗黙知の多いサービスになっていたためオンボーディングドキュメントや体制を整える必要性に駆られていました。 詳しくはこちらの記事にまとめていますが、オンボーディングを行うことで下記の発見が得られたことは大きな糧になりました。 書いてみて思うことはこれらは「新メンバーのため」ではなく、「チームのため・プロダクトのため」のドキュメントであり、まさしく自分のためになるドキュメントだと感じたということです。 2 月 関わっていたサービスが自社としてはサービス終了することになりました。 こちらのクローズからその後の引き継ぎに関しては、つい最近記事にしたばかりなので割愛します。 全社としての選択の集中の結果になりますが、サービスの業績も少しずつ良い方向に向いていて、新メンバーも迎えたばかりで、まさにこれからというフェイズだったのでチームの精神的にも、個人の負担としてもハードな一ヶ月だったと記憶しています。 3 月 2 月にサービスクローズが決まりましたが、自社として 2 年近く運用が必要な状況でしたので、エンジニアコストや運用コストがかからなくなるような仕組み作り・実装を行っていました。 詳しくは 2 月の項目に記載の記事を読んで頂ければと思いますが、限られた時間の中で優先順位を整理して、変動する複雑な内部環境の中で意思決定を行っていく業務はとても良い経験になりました。 終了するサービスにはリードエンジニアとして関わってきましたが、自身としても 4 月からは別サービスにジョインする想定だったので、月末までに運用が 2 年無事に務められるだけの対応を完了しなければならずでした。 これらが無事に終わって「やりきった！」というときに、プロジェクトオーナーからかけて頂けた言葉は今でも大切にしています。 4 月 今も関わっている社内の新しいサービスに関わりはじめたのが 4 月からでした。 「お疲れ様」の意味も込めて一週間有給を頂いていたのですが、「別サービスでリードエンジニアだった自分が、成果出すまでに時間をかけるのはかっこ悪いよな…」と思って、その一週間で新しく関わるサービスのキャッチアップをしていました。笑 元ユニコーン企業で PdM をしていた前サービスの PdM が、新サービスジョイン時にやるべきことは？という問いに「兎に角色んなものの匂いを嗅ぎまわる」と言っていたこともあり、業務から離れてサービス全体像を嗅ぎ回っていました。 業務を始めるとこういった時間は中々取れなくなるので、この一週間はとても貴重だったと今振り返っても想います。 5 月 入って一月経ち、チーム全体で話す文化や実装の指針がもう少しあった方が良いと動き回った一ヶ月でした。 開発共有 MTG という隔週で個々人の課題やチームの改善ポイントを話す場を作ったのと、spec ディスカッション会というテストコードに関してチームで話す場を作ったりしていました。 どんなに素晴らしい施策だとしても、チームへの導入プロセスやコミュニケーションを疎かにすると成果は伴ってこないため、ここは凄く気をつけながら進めていた気がします。 6 月 個々人のチームへの貢献をどう増やすか？みたいなことを考えていた一ヶ月でした。 また同時にチームへの貢献を引き出すためにも、個々人の負担や属人化をどう減らせるかを考えたりもしていました。 やったこととしては、5 月の spec ディスカッション会を経て、チームにテストコードの指針を作るため、スタイルガイドの輪読会など行っていました。 テストコード関連の話はこの過去記事にスライドをまとめています。 あとは開発共有 MTG や普段の朝会などで意見をより吸い上げしやすくするためにゲーム大会（ボンバーマン大会）なども企画して、チームのコミュニケーション活性化を狙ったりしてました。...

サービスクローズ、それはプロダクト開発に携わる者には決して無視できない可能性の一つ。 ですが、その内容が語られることはあまり多くないと感じています。 私はこの 3 年で 2 つのサービスクローズに関わりました。 一つは完全なサービスクローズ。 もう一つは自社でのサービス提供は終了で、新しい会社で新サービスとして生まれ変わる引き継ぎを行ったケース。 この記事では、その時にあったことと、そこから得た学びをまとめることで、サービスクローズに直面することになるかもしれない貴方の負担や悲しみが少しでも減らせる一助に出来ればと思っています。 1. サービスが終わると伝えられるとき 1 つ目のサービス終了は、渋谷の stream にあるレストランで伝えられました。 関わっているすべての職種を含めて 6 人の小さなサービス。 業務時間中に週 5 で稼働していた 4 人が「ちょっと外出られる？」と急遽集められて、プロダクトオーナーから終了を伝えられました。 2 つ目のサービス終了はプロダクトオーナーとの 1on1 の中で。 自社でのサービスは終了だけれど、なんとかしてサービスを残したいと思っている旨も伝えていただきました。 サービスクローズに直面するという経験。 多く経験するものではありません。 当然これらを受け止めることは困難なことです。 まなび 悲しみと辛さがくるタイミングは人それぞれ異なっていることを認めよう クローズの話があったのち、「クローズを伝えたときに泣いた人もいる」という話を聞きました。 自分は二回ともその場は冷静に受け止めていたのですが、後々じわじわと悲しみが押し寄せてきました。 最初に「悲しい・辛い」と伝えられた人は、その後もそれを吐露しやすくなりますが、人によってそれが溢れてくるタイミングは異なるものです。 クローズが決まると、期限内にやるべきことも沢山生まれ、チームの余裕や明るさも当然のように失われがちになります。それによってチームの空気は重くなり、益々自身で悲しみと辛さを背負ってしまうことになります。 「最初に泣かなかったから自分には泣く資格がない」なんてことはないです。 サービスクローズというハードシングスに向き合うために、悲しみや辛さが出来てたときにチームメンバーと分かち合いましょう。 それらの感情をチームに共有することは、どの局面においてもネガティブなものではありません。愛です。 2. サービスが終わると伝えられたあと サービスが終わると伝えられたあとは、クローズに向けた動きが始まります。 しかし、貴方がクローズを知るのと、同僚がクローズを知るのは同じタイミングではない可能性があります。 それは、どんな理由でのクローズにせよ、会社全体に不安が広がらないようにクローズの公開には丁寧なコミュニケーションが必要になるからです。 一方、サービスに関わる人には、その丁寧なプロセスをも超越して早く伝えることが重要な場合があります。 結果、貴方と同僚は違うタイミングでそれを知ることになります。それは同僚だけではなく、社外の親友や家族なども同じかもしれません。 「自分が今一番不安に思っていること」を話したい人に話せない。 「自分が今やっていること」を社内の人に話せない。 これはとても苦しいことの一つです。 まなび 苦しみを誇りに思おう どうしてもそれを隠すことが苦しい場合は、勿論チームに相談をして隠さずにいられるように努めることが良いと思います。 ただ、今振り返ると、他の人よりも先に自分が知れているという状況は、幸福な事だと捉えることも出来ます。 それだけの権利と、その権利を掴むまでの責務を担ってきたからこそ、貴方は早くそれを知れています。 知るタイミングに差があるのは、誰かを苦しめるためではなく、会社全体を守るためです。 知っている者同士で協力をして、今出来ることを着実にこなしましょう。 3. クローズへと動き出すとき サービスクローズがチーム全体や、全社に伝わり、実際にクローズに向けた動きが始まる頃。 目の前の仕事だけでなく、他の人のその先を見据えた動きが目につくこともあります。 今のサービスをなんとか違う形で続けてコミットし続けようと思っている人 サービス終了後は自社の違うサービスで働こうと思っている人 転職を考える人 色んなパターンの動きや話が出てくることがあります。 それに際して「貴方はどうするの？」とふらっと聞かれることもあります。 目の前のクローズ対応でアップアップなのに、その先のことを聞かれても…と困惑するかもしれません。 また、本当は違う選択を取りたいのに、目の前のチームメンバーへの配慮で意図しない同意や共感を行ってしまうかもしれません。 まなび 自分の想いを大切にすればよい 二つのサービス終了を通して、プロダクトオーナーは「貴方が選びたいことを選ぶのが一番だよ」と終始言い続けてくれました。...

前回の記事のラストに「良い PR に含まれるもの」として「適切な粒度のコミット」を記載しました。 適切な粒度のコミット…言葉にすると「そりゃ大切だよね！」となりますが、実際は適切な粒度のコミットを作るのは難しいですよねｗ 今回は「どうやって適切な粒度のコミットを作るのか？」ではなく、「自分はどれくらい適切な粒度のコミットが出来ているのだろう？」を振り返るために改めて自分のコミットログを見直して反省する回を開いてみようと思います…！！笑 (その前に…!) 接頭辞 自分はコミットメッセージには Angular.js/DEVELOPERS.md に記載がある下記の接頭辞を使っているので、事前に書いておきます！ ### Type Must be one of the following: - feat: A new feature - fix: A bug fix - docs: Documentation only changes - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - refactor: A code change that neither fixes a bug nor adds a feature - perf: A code change that improves performance - test: Adding missing or correcting existing tests - chore: Changes to the build process or auxiliary tools and libraries such as documentation generation 接頭辞をつけることの利点は「コミットの内容がわかりやすくなる」という利点だけでなく、「機能を接頭辞の type 単位で切り分けるようになる」という効能もあります。...

良い PR と、良くない PR が世の中にはあると思いますが、それを切り分けるものは「コード自体の品質」や「どういうスコープで切り分けているか」など、複数の要素が合わさって判断されていると考えます。 今日は「良い PR」の構成要素の一つ、コードやスコープではなく、「PR 自身の中身」がどうあると良い PR になるのだろうということを考えてみます。 良い PR とは？ コードは理解しやすくなければいけない。 リーダブルコード - 名著、リーダブルコードで書かれているように、良いコードとは理解しやすいコードです。 それはコードというものは自身が書く時間よりも、他者に読まれる時間の方が長いから必然ではあります。 PR も同様だと考えています。他者にとって理解しやすい内容が網羅されている PR こそ良い PR だと考えています。 これは PR がコードと同じく下記の特性を持っているからです。 長期に渡って読まれる なにか既存の実装を変更しようと思った際に、「ここの背景ってどうなっているんだろう？」と当時のチケットや slack を探しても、見つけるのが難しい場合があります。 ですが、PR であればコードから blame で一瞬で拾えます。 自分も今でも数年前の PR を読むことはザラにありますが、PR にコード以外の情報がないとコードをしっかり読む必要があり、色んなコストが発生してしまいます。 多くの人に読まれる PR を読む対象は目の前のレビュアーだけではありません。 レビューする人が決まっていて、「この人なら詳しいから省略しても良い」は多くのケースで当てはまりません。 レビュー時点ではレビュアーがドメインの知識を持っているため詳細が省略可能であっても、未来の時点で他の人が参照する場合はそうだとは限らないからです。 上記のような特性がある以上、コードに気を使うエンジニアがコードを取りまとめる PR に気を使わないのは本末転倒です。 では、どんな PR だと理解されやすい PR になるでしょうか？ 次項で自分が「あると良いなぁ」と思っている構成要素を上げてみようと思います！ 具体的な PR の構成要素 （その前に）対象の PR の性質 PR の情報をどこまで詳細に書くのかは、下記のような情報によって異なります。 機能のサービスレベル PR で扱うスコープの大きさ レビューからマージまでの優先度・緊急度 レビュー相手の PR で取り扱う実装や仕様への理解度 ここでは、障害対応などでなく、ある程度スケジュールに余裕があり、粒度も極端に小さくなく、レビュアーもランダムな方にレビューする場合の PR の場合とします。...