マネジメントと言っても、色々なタイプのリーダーがいて、その数だけやり方も違います。

また、実際に作るもの、求められているものによっても手法は変えるべきだと思います。

今回は、私が新規プロダクトの開発リーダーを任された時に実践した手法を、回数を分けて説明しようと思います。

この記事では、実際の開発作業に関してやるべきこと、やるべきではないことを紹介します。

開発環境

重要なのは 「ツールはなるべく少なくする」 ということです。

使用するツールが多くなると、その分ツール間の行き来が多くなり、開発効率が下がります。

自分たちのチームでは何が必要なのか、しっかりと議論して使うツールを決めましょう。

あれをやりたいからこのツールを使おう。これを効率化したいからこのツールを使おう。といった風にツールを増やしてしまうと、最終的に使うツールが増えていって全体の効率が下がるケースをよくみます。

ツールを増やす前に、本当にそれが必要なのか。実はそれはやらなくていいことなのではないか？といった議論を先にするべきです。

IssueとPullrequest

テンプレートを用意して、内容の属人化を防ぎましょう。

なにが、どうなって、どうなったら解決なのか、きちんと明記できるようなテンプレートを用意するべきです。

Issue、Pullrequestの作成やコメントなどは、Slackへ通知すると良いでしょう。

バグ

ゼロにする考えは捨てる

バグをゼロにする考えは最初から捨てましょう。

バグが出たらすぐに気づいて修正してデプロイする体制を整えることに注力したほうが良いと考えます。

検知

バグが出てるけど気づかずに放置して、結果的に機会損失が膨れ上がる。という状態が一番良くないと考えています。

バグが出たらすぐに検知して、開発者に通知する。と言った体制を整えましょう。

スクリプトエラーなどを検知するツールを導入しましょう。

修正

検知ができれば、あとは原因を特定して修正してデプロイするだけです。

修正で重要なのは、同じ箇所、同じ原因で再度エラーが起きないようにすることです。

今回発生したエラーをデプロイ前に検知できるようなテストコードを追加しましょう。

進め方

スモールスタート

最初から完全なものを作ることは無理だと割り切りましょう。

スモールスタートを原則に、小さいものからコツコツと作っていくことをオススメします。

小さい単位で実装していくと、必然的にPullrequestも小さい単位となり、レビュワーの負担が下がり、レビュー自体のクオリティも上がる傾向にあります。

失敗

ある程度の失敗、不具合は許容しましょう。

失敗を恐れ、完璧な状態を目指すことより、完成させることの方が重要です。

失敗してはいけない箇所、許容できる箇所は都度メンバーと共有し、認識を合わせておくことをオススメします。

失敗を許容するとは言っていますが、同じ失敗を繰り返すことは良しとはしません。

失敗から学びを見つけ、同じ失敗を繰り返さないように、メンバーと議論をしましょう。

このような理由でその対応はダメだったことがわかりました。と前向きに議論ができるようなチームを目指しましょう。

心理的安全性

チーム開発を進める上で、心理的安全性が最も重要な要素だと考えています。

誰かが失敗をした、バグを出した、などの場合、 人を責めるのではなく、実際に発生した出来事に対してフォーカスするべき です。

このような場合に人を責めてしまうと、チーム全体が失敗を隠すようになり、失敗を恐れチャレンジや学習を行わなくなってしまいます。

失敗を責めあうのではなく、どう解決するかを議論するようにしましょう。