はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ

初めに 僕は4年ほどスクラムを採用した組織づくりを行ってきました。 最近「スクラムの内容は理解したけど、結局スクラムがなんなのかがわからない」という話をされることがちょこちょこあるので、記事としてまとめることにしました。 スクラムとは スクラムとは、アジャイル開発を実現するためのフレームワーク、プラクティスの一種です。 スクラムガイドには、以下のように定義されています。 スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。 スクラムガイド より引用 スクラムでは、スクラムマスターやプロダクトオーナーなど、いくつかのロールをもうけ、ロールごとにチームとしての開発を進めていきます。 また、スプリントの単位で以下のようなイベントを実施していきます。 スプリントプランニング デイリースクラム ミッドタームレビュー

この記事は何 チーム開発をしている方、特にスクラムなどを採用している場合はスプリントごとに振り返りをしていることが多いのではないでしょうか？ 振り返りはチームとしての学びを最大化させていく上で非常に重要なものですが、振り返りに加えて「向き直り」をしていくことも非常に重要です。 この記事では向き直りについて紹介していきます。 振り返りとは 向き直りの紹介をする前に、振り返りについて紹介します。 振り返りはみなさんご存知の通り、プロジェクトやスプリントなど、一定の期間ごとに取り組んだことに対しての良かったところ、改善点などを洗い出しながら、次回以降のアクションの改善に活かしていくためのプロセスです。 この振り返りを行うことで、イテレーティブに改善を行なっていくことができ、チームとしての動きの質を高めていくことが可能です。 向き直りとは 振り返りがプロジェクトやスプリントなどの比較的短い期間での

初めに ソフトウェア開発には「モデリング」と「ユースケース実装」という二つのプロセスが存在します。 この二つのプロセスについて最近説明をすることが多いため、記事としてまとめてみました。 アプリケーションとは アプリケーションとは、特定の目的を達成するために設計されたソフトウェアです。 アプリケーションは正味プログラムさえできれば開発することは可能ですが、今日紹介する「モデリング」と「ユースケース実装」 という大きく二つのプロセス/アーキテクチャを採用して作られることが大半です。 アプリケーション開発においてよく使われるような以下のようなアーキテクチャは全てこの「モデリング」「ユースケース実装」 考え方を基に作られています。 レイヤードアーキテクチャ MVC クリーンアーキテクチャ オニオンアーキテクチャ モデリングとは モデリングとは、アプリケーションで扱う概念（ドメイン）を定義、実装して

この記事は何 僕はプロダクトマネジメントもやっている都合上、Issueを作成することが多いです。 Issueを作成する上で僕が普段気をつけている「Why」を書くことについて紹介します。 Issueとはそもそも何か Issueとは、ソフトウェア開発における問題点や改善すべき箇所を指し示すための報告書です。 これは、開発者が問題を理解し、適切な対策を立てるための重要な情報源となります。 Issueには僕はいつも以下のような情報を含めるようにしています。 Why（今回の主題） なぜこれに取り組むのか What 具体的な仕様 TODO 実装すべき機能や修正点 Whyをなぜ書くのか 前項のように、僕はIssueにはまずWhyを書きます。特にWhyは丁寧に書くことが多いです。 Whyを丁寧に書く理由は、「Issueに取り組む理由は不変なため」です。 開発現場ではよく起こることだと思いますが、ユーザーに

この記事は何 以前Qiitaで以下のようなスクラムに関しての記事を投稿しました。 これらの記事では「チームとしてゴールを達成するため」のTipsについて紹介してきました。 しかし、そもそもスプリントゴールがなんなのかを理解していないと、これらのTipsを実践することは難しいです。 この記事ではスプリントゴールとはどういうもので、どのように設定すると良いかを説明します。 スプリントゴールのよくある勘違い スクラムを実施しているチームの中で、たまに「ゴールは特に設定していない」という方がいらっしゃいます。 ゴールを設定しない理由は以下のとおりです。 このスプリントでやりたいことはスプリントバックログとして残してあるからゴールを設定する必要がない 結局スプリントゴールを設定しても、やることが「スプリントバックログを空にする」になってしまうから これらの主張は一見正しいように見えますが、スプリント

この記事は何 僕はかれこれスクラムを3年以上色々な組織でやっています。 最初はうまくスクラムを活用できていなかったのですが、最近はある程度スクラムというものの理解も経験則含めて上がってきたなと感じています。 この記事では、スクラムに取り組むに当たってとりあえずここはおさえておいた方が良いなと感じているところを知見として紹介します。 スクラムがしっくりこない 突然ですが皆さん、スクラムいい感じに回っていますか？ 「毎回のスプリントをやるごとにチームがうまく回るようになってるぜ！」みたいな方はこの記事はお役に立たないかもしれません。 「一応スプリントは回してるけど結局これってこれってなんのためにやってるかよくわからない...」みたいな感覚がある方は、読んでいただけると何か気づきがるかもしれません。 アジャイルないしスクラムという概念を知っている方は増えてきていると思いますが、その一方で「スクラ

これは何 新人プログラマ応援イベントの参加記事です。 gitにはreflogというコマンドがあります。このコマンドを学んでおくとやらかしちゃった時も大体なんとかなるので記事にします。 git reflogってなに？ git reflogとは、Gitで操作履歴を見ることができるコマンドです。 例えば branch1にチェックアウト branch1でbranch1.txtを作成し、コミットを作る masterにチェックアウト をすると、以下のようなreflogになります。 $ git reflog 4a4125a (HEAD -> master) HEAD@{0}: checkout: moving from branch1 to master 826a9dc (branch1) HEAD@{1}: commit: Create branch1.txt 4a4125a (HEAD -> mas

これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase

これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな