この記事では、不確実性が多いプロダクト開発において、どのようにアジャイルチームの「合意形成」を行うかについて、経験とノウハウを共有します。 サクッと読みたい方はこちらのスライドもどうぞ。 対象読者 チーム開発をしているすべての方に向けて、例えば次のような課題を抱えてモチベーションが低下してしまったチームを想定しています。 チーム内で意見がまとまらず、合意形成が難しい チーム内の発言が減り、心理的安全性が低下してきた 見積もりの精度が低く、スプリントが始まってから問題が発生してしまう メンバーの向かう方向がバラバラで、プロダクトゴールを見失っている チームの透明性が低く、意思疎通がうまくいっていない 背景 今回参加したプロジェクトでは、0→1開発の概念実証にあたって、アジャイル開発が想定されることから、スクラムチームが形成されました。 しかし、半年ほどでチームの混乱期に突入していくと様々な課

持続可能なプロダクト開発において、技術選定の意思決定は重要な要素です。 この記事では、技術選定の意思決定において一番大切なことと、それを実現するための6つの取り組みを紹介します。 サクッと読みたい方はこちらのスライドもどうぞ。 対象読者 チーム開発で技術選定に携わっている 技術選定の意思決定に悩んでいる プロダクトの持続性を向上させたい はじめに 筆者は、5年以上の長年に渡り運用されているプロダクトでの開発から、0 → 1の立ち上げまで、様々なプロダクト開発に携わってきました。 長年運用されているプロダクトを開発する際には、保守性が低く、どうしてこんな技術選定になっているのか？なぜこのような実装になっているのか？と不満に感じることがありました。しかし、当時の背景や状況を知ることができないため、すでに動いているものが絶対視され、そのままになってしまうことが多かったです。 一方で、新プロジェク

GitHubで CODEOWNERS を設定することで、プルリクエストのレビュアーアサイン自動化や責務の明確化などを行う方法について解説します。 背景 モノリポのリポジトリ運用が始まった際にプルリクエストの運用で次の課題を感じていました。 パッケージごとにメインの担当者が異なるため、レビュアーアサインの過不足が発生 スキーマの変更など、複数のパッケージにまたがる変更がある場合、プルリクエストを確認してほしいレビュアーがとても多く、作成時に毎回手動指定するのが大きな手間 チームに新しいメンバーが加わった際に、オンボーディングが大変 最初はWorking Agreement (チーム内のルール) でカバーしていたのですが、GitHubの機能であるCode Ownersで仕組み化することにしました。 Code Owners とは CODEOWNERS ファイルを使い、リポジトリ中のコードに対して

この記事では、AWS CodeBuildなどのCI/CDでDocker HubのPull rate limitに引っかかるときの対応策として、ベースイメージを取得するリポジトリをAmazon ECR Public Galleryに切り替える方法について紹介します。 背景 AWS CodeBuildを用いてデプロイを行っているのですが、デプロイの度にイメージビルドを行っています。そのため、Docker Hubに存在するベースイメージ(go, node, alpineなど)へのpullが多発し、制限に引っかかることが増えてきました。 具体的には次のようなエラーが発生してデプロイに失敗してしまいます。 TOOMANYREQUESTS: You have reached your pull rate limit. You may increase the limit by authenticati

GitHubにおいてファイルの差分がない状態でプルリクエストを作る方法を解説します。 背景 GitHubを活用した開発において、ファイルの差分がない状態でプルリクエストを作りたい場面が意外と多くあります。 例えば、実装開始前に作成しておくことでモブプロメンバーやレビュアーにプルリクエストを共有したい場合などです。 そんなとき、差分がない状態でプルリクエストを作成する方法を解説します。 課題 しかし、 GitHubにおいては、差分がない状態でプルリクエストを作ることができません。 試しにブランチだけ作ってみたところ、 "There isn’t anything to compare." と表示され、プルリクエストを作成するボタンが表示されません。 解決方法 コミットの差分がない場合にプルリクエストが作成できない仕様になっているため、裏を返せば空コミットが1つでもあればプルリクエストが作成でき

エンジニアにとってメリットだらけのアウトプット。しかし、モチベーションが保てず続かないという大きな課題があります。 この記事では、アウトプットを続けるメリットと、モチベーションを維持するための心構えについて紹介します。 ※ この記事でのアウトプットとは、エンジニアがブログ等を通して技術や考え方を発信することを指しています。 サクッと読みたい方はこちらのスライドもどうぞ。 はじめに こんにちは、おおいし(bicstone) です。突然ですが皆さん、 アウトプットはしていますか？ 私も2022年までは、年に数本の記事を書いている程度でした。色々な理由をつけて、アウトプットができない自分を正当化していました。 アウトプットするようなネタがない アウトプットは利益にならない アウトプットする時間がない アウトプットに価値がないと感じる アウトプットを誰も評価してくれない しかし、私はこの誘惑を乗り

この記事は「めぐろLT Advent Calendar 2023」5日目の記事です。 シェルで表示できる名刺を作ってみたのでご紹介します。また、このライブラリを作るにあたって、実行可能なnpmライブラリの作り方についても触れていきます。 Bash 環境にて実行した様子 対象読者 シェルで表示できる名刺を作ってみたい 実行可能なnpmライブラリを作ってみたい 背景 2023年には、COVID-19の落ち着きもあり、オフラインによるエンジニアイベントが再開されてきました。私も2023年だけで30回以上のオフラインイベントへ参加しました。 オフラインイベントの醍醐味の1つとして、登壇者や参加者などと「社外の横のつながりを作れる」ことが挙げられます。懇親会でSNS交換をされる方も多いのではないでしょうか。 以前はTwitterを使っている方が多く、Twitterのスクリーンネームを交換することで完

この記事では、Approveされてもラベルを付けるまでマージできないようにする方法について解説します。 背景 とあるプロジェクトで、 GitFeatureFlow というフローを採用しています。 このフローでは、mainブランチからトピックブランチを切って開発し、開発が終わったらmainブランチに向けてプルリクエストを作成します。その後、プログラムのレビューをレビュアーに依頼します。しかし、 Approveされてもすぐにマージできません。QAを依頼し、QAが通過してからマージできます。 この運用において1点懸念がありました。それは、Approveされたプルリクエストはワンクリックでマージできてしまうので、QA未完了の機能が誤ってマージされる可能性があることです。 そこで、私はApproveされてもラベルを付けるまでマージできないようにする仕組みを作りました。これにより、QA未完了の機能がマ

Zenn Publicationでのテックブログを投稿をしてみて、執筆者として感じたメリットとデメリットをまとめました。 Zennでテックブログを開設しようか考えている方に、参考になれば幸いです。 勤務先の話が出ますが、すべて個人の見解です。 Zenn Publication とは Zennにおいて、最近Zenn Publicationという新機能が登場しました。 Zenn Publicationとは、Zenn上に複数人で管理するメディアを作ることができる機能です。 Publicationを作成すると、次のようなページが作成されます。Publicationに紐づけた様々なメンバーの記事が集約されています。 Zenn Tech Blog ページのスクリーンショット Zenn Publication のメリット 勤務先でテックブログを投稿する場としてZenn Publicationが採用されて

GatsbyのGraphQLで formatString を用いて時刻を扱うとユーザーのタイムゾーンによっては日時が正しく表示されません。タイムゾーンを扱いながら正しい日付を表示する方法を解説します。 Gatsbyを使用した例を紹介しますが、それ以外のReactフレームワークでも同様の対処方法が使用できます。 (Gatsbyはv5を使用しています) 背景 Gatsby製のポートフォリオサイトの個人ブログでは、作成日時・更新日時を取り扱っていているのですが、タイムゾーンの考慮に苦労しました。 例えば、次のようなスキーマを想定してみます。 type BlogPost { created: DateTime! # "1960-01-01T00:00+00:00" } query Query { allBlogPost: [BlogPost!]! } Gatsby の GraphQL でフォーマッ

チームの投票手法としてファイブフィンガー (Fist to Five) を採用することで、メンバーの心理的安全性を向上させる取り組みについて紹介します。 今回はスクラムを採用しているチームの例で紹介しますが、他のチーム開発手法でも同様に適用可能です。 サクッと読みたい方はこちらのスライドもどうぞ。 背景 皆さんのチームでは、意思を確認するための手法はどのように行っていますか？ 以前は、デイリースクラムで「困っていることがある方いらっしゃいますか」と聞いたり、リファインメントで「このユーザーストーリーについてコメント、意見ある方いらっしゃいますか」と確認していることが多かったです。 しかしこの方法だと、異議があるけど空気を読んで言い出しにくかったり、なんとなく不安だけど皆が大丈夫そうなので言わなくていいやと思ってしまいがちです。 結果的に、質問することに抵抗がない、いつも同じメンバーのみが議