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

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

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

この記事では、スケジュール管理とミーティングの方法について紹介します。

スケジュール

スケジュールを管理することよりも、プロダクトを作ることが重要です。

スケジュールの管理にかかるコストを徹底的に削減します。

自社開発で「進捗を都度管理、報告する」スケジュール管理は不要だと考えています。

何故ならば、スケジュール通りに開発しても、それがお金になるとは限らないからです。

そのため私は、以下のようなスケジュール管理を行いました。

• 運営側と、タスクの優先度を決める

  • 優先度はコンセプトや開発方針を軸にして決定する

• 優先度が高いものから順に、エンジニアに作業を割り振る

  • この際、割り振ったエンジニアにも優先度を伝える
  • 優先度が同程度のタスクであれば、進め方は任せる
• 月単位で、運営側と優先度の見直しを行う

未来のことなんて誰もわからないので、３ヶ月先までのガントチャートを引くのはムダです。

絶対に変化しますし、ガントチャートを修正することが仕事になってしまいます。

Webサービスの開発において、開発作業の目的はプロダクトを作ることであり、スケジュール通り作業を進めることではありません。

それよりも今何をすべきなのか、に注力するべきです。

ミーティング

人数と時間

ミーティングをするにあたって、とくに気をつけていることは 「必要な人数だけで、最低限の時間で、とにかく決める」 という３点だけです。

まず、定例ミーティングというものは極力無くしましょう。

定例化してしまうと、決まった日に決まった人数が集まります。

最初は人数が少ないかもしれませんが、運営していくにつれて、あの人も必要というのが増えていき、結果的に膨れ上がってしまいます。

ただの報告会であれば、共有のドキュメントに各自報告事項を記載して、あとでSlackなどで共有すれば良いだけです。

目的

ミーティングを始める前に、そのミーティングの目的を明確にすることが大事です。

大事な話があるのか、何かを決めないといけないのか、ミーテイングによって内容はさまざまです。

何が達成されたら終わりなのか、ミーティングを開始する前に伝えましょう。

その目的が達成された時点で、そのミーティングは終了です。

決まるまでダラダラ時間を使うのは良くありません。

ミーティングの枠だけ予定を組んで、なにをするのか事前に何も共有がないのはアンチパターンです。

なにを議論するのか、なにを決めるのかが分かれば、事前に準備することがあるかもしれませんし、準備ができればミーティングの時間を有意義に使うことができます。

まとめ

今回の記事で、プロダクトにフォーカスしたマネジメントの紹介は終了です。

管理よりも手を動かして物を作ることに集中した手法になってると思います。

開発現場を取り巻く環境は様々で、全ての手法を取り入れることは難しいと思いますが、何か一つでもヒントになれば幸いです。