0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

開発チームのリーダーとしてと必要なこと

Last updated at Posted at 2025-03-30

まだ決まりではないが、開発リーダーにしてもらえそうなので、リーダーとして何が必要なのか、特にAgile開発とAPI開発の現場で必要な要素を調べてみました。例にNetflixを使うことが多いですが、私はNetflixの関係者ではなく、単に例としてわかりやすいプラットフォームをあげているだけなのでご注意ください。

リーダーとして必要なものはなにか?

Agile開発のリーダーに必要なもの

  • 柔軟な計画力: 状況に応じて計画や優先順位を柔軟に変更できる力。
  • チームの自律性の尊重: メンバーが自主的に動ける環境づくりを促進。
  • 短いサイクルでのフィードバック: 定期的なレビューや振り返りを行い、早期に改善を繰り返す。
  • スクラムマスター的な役割: 障害を取り除き、円滑に進めるためにチームをサポートする力。

API開発のリーダーに必要なもの

  • API設計の知識: RESTfulなAPIやOpenAPIなど設計手法を理解していること。
  • 仕様調整力: 他のチームやサービス利用者との仕様調整を円滑に進めるスキル。
  • 品質管理能力: APIのパフォーマンス、セキュリティ、安定性を意識し、テストを徹底する姿勢。
  • ドキュメント作成の推進: 明確でわかりやすいドキュメントを整備・管理する力。

共通して必要なもの

  • コミュニケーション力: チーム内外の関係者と効果的に意思疎通するスキル。
  • 問題解決能力: 発生した問題を迅速かつ的確に対処する。
  • 技術理解力: チームメンバーの業務を理解し、支援できるレベルの技術的知識。

その他

私の好きな漫画に出てきた「(リーダーは)部下の嘘を見破ること(も必要)」も大切かもしれません。それがおべっかであれ、悪意のある嘘であれ、部下の嘘を見破ることはリーダーとして大切です。

Agile開発リーダーとしての役割(詳細)

1. プロダクトバックログの整理・管理

POと連携し、要求事項を整理し、開発タスク化。
機能の優先度を調整し、明確化。

2. スプリント計画と進捗管理(スケジュール管理)

各スプリント(例:2週間)でのタスク割り当てを行い、チームの進捗を日々確認し、スケジュールを管理。
スケジュール遅延があれば迅速に調整し、タスクを再割り当てするなどして対処。

3. フィードバックと改善

各スプリント後にレビュー・振り返りを実施し、改善点を明確化。
次スプリントに反映させる改善案を具体的にチームと共有。

API開発リーダーとしての役割(詳細)

1. APIの設計・仕様調整

後払いAPI(例:POST /api/payments/postpaid)の仕様策定。
関連チームとの連携・調整を密に行い、仕様の合意を図る。

2. API品質の維持とテストの推進(QAテスト調整)

APIの単体テスト、統合テストの計画を策定。
QAチームと連携し、テストスケジュールを調整し、バグや不具合の早期発見と修正を進める。

3. APIドキュメント作成

OpenAPIなどを使ったAPIドキュメントの作成・管理。
社内外の関係者が理解しやすい状態に保つ。

共通で行うリーダーの役割(詳細)

1. 全体スケジュールの調整・管理

開発期間、QAテスト期間、リリース予定日を含めた全体スケジュールを管理。
関係チーム(開発、QA、ビジネス部門)との連携を行い、スケジュール変更時は即座に調整し、共有する。

2. QAテストの調整・推進

QAチームと連携し、QAテストの実施タイミングやテスト項目を明確化。
バグの重要度を判断し、開発チームに迅速にフィードバック。

3. コミュニケーションとリスク管理

進捗遅延や品質問題を迅速にキャッチし、関係者間での調整を円滑に進める。
チーム間の円滑なコミュニケーションを促進し、問題発生時の早期解決を図る。

4. 技術サポートとメンバー育成

技術的な支援を通じてチームをサポートし、メンバーのスキルアップを図る。

アジャイル開発のスクラムでの役割

アジャイル開発のスクラムには「リーダー」はいません。それゆえスクラムマスターが一番近い役割ではないかと思います。うちの会社はまだスクラム開発がちゃんと取り入れられてないので、開発のリーダーとして役割とアジャイル開発でのスクラムマスターとしての役割をうまく折衷する必要があるのかもしれません。

スクラム開発の主な役割と責務

① プロダクトオーナー(PO)

プロダクトの『方向性』を決める人。
どんな機能を作るか決める(プロダクトバックログを管理)
作る機能の優先順位を決定する
ビジネス価値を考え、ユーザーの要望を反映する

例)
「Netflixに後払い機能を作りたい。料金計算は視聴時間に基づいて行う。今後、視聴した分だけ支払いたいというユーザーが増えると考え、この機能を最優先にしたい。」

② スクラムマスター

チームが『円滑に作業』できるよう支援する人。
スクラムのルールをチームが正しく実践できるように支援
チームの問題や障害を取り除くサポートを行う
チームのコミュニケーションを促進し、問題解決を支援

例)
「後払い機能の開発で困ったことがないか毎日の朝会で確認し、課題があればすぐに解決できるようにサポート。」

③ 開発チーム(Development Team)

実際に『開発を行う』チーム。
機能の設計・開発・テストを行う
自律的にタスクを管理し、責任を持って作業を進める
品質の高い製品をリリースするために協力する

例)
「視聴時間から後払い金額を計算するためのAPIを設計し、実装する。品質を維持し、スプリント内に完成させる。」

※ その他の重要な関係者(正式なスクラムの役割外)

④ ステークホルダー(関係者)

プロジェクトに『利害関係がある人』。
経営層やマーケティングなど、プロジェクトに関係する人々
意見や要求をPOに伝え、製品の方向性に影響を与える

例)
「マーケティング担当が、後払いユーザー向けのキャンペーンを企画したいので、そういった対応が可能かPOに要望を出す。」

⑤ QAチーム(品質保証)

作られた製品が『正しく動作するかを検証する』チーム。
作成された機能のテストを行い、バグや問題を発見・報告
開発チームと協力して製品品質を改善する

例)
「視聴履歴が正しく課金に反映されるか、様々なパターンを想定してテストを実施する。」

試しにスケジュールを組んでみる

Netflixに『視聴した分だけ後払い(Pay as you go)』機能を追加するプロジェクトを、
2025年1月1日スタートとして、仮のスケジュールを組んでみます。
Netflixは誰でも知っている映画やドラマを見るプラットフォームですが、ここにPay as you goの後払い機能をつける場合、どういう役割が求められるのかを考えてみましょう(あくまで練習としての仮定であって、Netflixが実際にそういうこ予定があるわけではないのでご注意ください)

Netflixの「Pay as you go」(後払い課金)機能を追加する具体例に、スケジュール管理とQAテスト調整を含めた開発リーダーの役割を整理します。

■ 全体スケジュール(仮想例)

開発期間:約3ヶ月(1月〜3月)
リリース日:3月31日(仮)

【日次(Daily)でやること】

※平日毎日実施する内容(毎朝約15〜20分程度)

【月次(Monthly)でやること】

※1月〜3月の月末に実施すること(半日〜1日程度)

【スケジュールイメージ(具体的な例)】

1月

  • 1月1日:プロジェクト開始
  • 1月初旬:仕様調整・開発着手
  • 毎日:デイリースクラム

1月31日

  • スプリントレビュー(機能デモ)
  • スプリントレトロスペクティブ(振り返り)
  • 翌月スプリント計画(2月のタスク整理)
  • QAテスト調整(テスト項目・スケジュール確定)

2月

  • 毎日:デイリースクラム
  • 開発・QAテスト開始(API実装とテスト)

2月28日

  • スプリントレビュー(API実装状況デモ)
  • スプリントレトロスペクティブ
  • 翌月スプリント計画(3月のタスク整理)
  • QAテスト計画の見直し・再調整(バグ修正期間確保)

3月

  • 毎日:デイリースクラム
  • 開発・QAテスト(バグ修正・品質向上)
  • 3月中旬〜後半:最終テスト・修正
  • 3月31日:後払い機能リリース
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?