はじめに
プロジェクトマネジメントを行うにあたり、PMBOKなどの本を読むと60超の各工程があり、
現場に導入するにしても何から導入すればわからない。
プロジェクトリーダーを行うことが増えた近年、スケジュールがうまくいかなかったり、リリース後に軽微であれバグが発生するなど、案件推進の上で困ることがままありました。
各工程をやる・やらないを曖昧な状態で推進することが原因だと考え、
- 自分の中でこの工程を意識して
- やる・やらないを初めに判断し
- JIRAなどで各タスクのチケットを切ってガントチャートを引く
ということを実施しておりました。
各工程について、個人的な実施基準やその工程で注意するところをまとめたので、ご参考いただけますと幸いです。
各工程について
| 工程 | 説明・実施基準 | 注意するところ |
|:-----------------|:------------------|:-------------------|:-------------------|
| 要件定義 | ディレクターと要件定義段階から行う場合もある。
開発内で別途新規画面を作成するのであれば、要件定義から開始する必要がある。 |この段階から冗長的な処理にならないために、共通API化できる機能はないかを意識しておくと良い。|
| 影響範囲調査 | 影響範囲があるもの、無いものをキックオフ段階で検討しておく ||
| 見積もり | 要件を元にどの程度工数がかかるか見積もりを行う。 | 過信や考慮漏れで見積もり以上のスケジュールになってしまうケースが多いので、ある程度のバッファを設けた見積もりをしておいた方が良い。 |
| 仕様把握・検討 | 必ず開発内で読み合わせをする
→不明点があれば企画とも読み合わせする
数ヶ月規模の大きいものであれば、
開発内の関係者で読み合わせをしてリスクを検討する |仕様漏れは往々にしてあるので、早めにソースと実体を見比べてリスク検討する。
現在の構成で実施可能かどうかを常に意識する|
| 画面・I/F設計 | APIや画面のI/Oの設計を行う ||
| 詳細設計 | 新規実装の際は必ず行う。フローチャート・詳細の処理設計を作成すること |継続的に更新される機能の場合、更新しやすい設計書を書くことを意識する|
| DB設計 | カラム追加・テーブル追加が必要な場合に行う。 |安易に正規化を行うのではなく、実装を意識したDB設計を行う
既存テーブルに新規カラムを変更する時(追加・削除も含む)、サービス側でメンテナンスを行う必要があるか確認する
全角は実際のDATALENGTHと異なるので、想定される最大文字数が実際に入るかINSERTで確認する(日本語1文字(半角含む)は3バイト、複雑な漢字は4バイトある場合がある)
http://ubuntu84.blogspot.com/2013/10/oracle-11g3.html
http://www.tohoho-web.com/wwwkanji.htm|
| 設計レビュー | 画面・DB設計を行なった場合は必ずレビューを行う |仕様と読み合わせて漏れがないか確認する
DB設計はDDLなどに誤字・脱字がないか注意して確認する|
| データ移行 | 仕様変更に伴いデータ移行が必要になる場合がある |パターンの網羅票を作成しておく
→パターン漏れがのちの問い合わせとなる。
関連チームがいる場合は早めに周知する。
本番相当のDBを作成し、事前リハーサルを行うことが望ましい。|
| データ移行手順レビュー | データ移行がある場合は必須で実施する ||
| リリース計画 | リリース手順計画・関係者説明・ガントチャート作成を行う。
以下に起因する障害発生を防止する。
・他部署とのコミュニケーションロス
・エラー・動作不備発生の検知
・リリース失敗するリスク抑制> |関係者には1ヶ月以上前には周知する
事前データ移行、事前リリースができないかを考えておく。|
| リリース計画レビュー | 複数のコンテンツにまたがるリリースの場合、必ずレビューする場を設ける。
リリース計画を行なった場合は必須で実施する。 ||
| 実装 | 実装フェーズ。余裕があればペアプロ・モブプロなどを行う。 |リーダブルコード・コード規約を常に意識した実装を行う。
簡易実装でも動作確認をしてからMRを出す。
→確認しないで漏れているパターンがよくあるため
エラーログを確認してからMRを出す。|
| 実装レビュー | 実装された内容が適切かどうかレビューする。 |レビュアーも最低限の動作確認はする。
リーダブルコード・コード規約を常に意識したレビューを行う。|
| レビュー修正 | | 何も考えずに言われたままレビューを修正をしないようにする。 |
| 単体試験項目書作成 | 画面側の挙動を確認する場合、単体試験項目書は必ず作成する。
ユニットテストを書いている場合は、最低限の動作確認のみで良い。
テストファーストの観点で実装前に事前に作成しておくのも良い。 |プログラムパターンを網羅した単体テストを作成するように意識すること|
| 単体試験項目書レビュー | 単体試験項目書レビューをしていない=バグの原因になりがちなので必ず確認する |プログラムパターンを網羅しているか確認する。|
| ユニットテスト | ロジックパターンをある程度網羅したユニットテストを作成する。
カバレッジは100%を目指すと工数が大きくなるので80%以上を目指すようにする(例外処理などは記載しない等)
実施基準はバッチ・APIの場合は手動でのパターン網羅が大変なのでユニットテストで作成することをおすすめする。 |ユニットテストは画面側の挙動を優先してスケジュール的に間に合わないことが多い傾向にある。余裕を持ってスケジュールを確保しておく。|
| 負荷試験 | ・新規ミドルウェア導入
・リアーキテクチャ
・大量アクセスが想定されるAPI・バッチの作成
がある際は必ず実施する |参照・更新、単体・複数などパターンを意識して負荷試験を行う
既存サービスからどの程度がMAXの負荷か想定しておく
負荷に耐えられなかった時の対策ができる程度の余剰を持ったタイミングで実施する。|
| 性能試験 | ・新規サービス導入
・新規ミドルウェア導入
・リアーキテクチャ
・大量アクセスが想定されるAPI・バッチの作成
・テンプレート・テーブルなどを刷新する大規模な改修
がある際は必ず実施する | 既存機能と比較して品質が落ちていないか確認する。
参照・更新、単体・複数などパターンを意識して負荷試験を行う。
性能が落ちていた時の対策ができる程度の余剰を持ったタイミングで実施する。|
| 結合試験 | フロント側・DB・他サービスとの結合試験を行う。 ||
| ディレクター確認 | ディレクター・マーケティングチーム等に成果物を確認してもらう。 ||
|QA試験|実装規模が10人日以上 + コンシューマが触る画面の場合はQAチームに依頼して品質試験を実施した方が良い。||
|リリース準備|リリースする際のコマンド・SQL実行など手順を事前にまとめておく。|大規模案件は1週間前に怒涛のリリース準備になりがちなので、2週間前くらいからある程度準備しておくと良い。|
|リリース| 対応内容を本番環境にアップする |SQLやコマンド実行はなるべくまとめて簡潔なリリースになるように意識する。|
|ふりかえり|KPTなどでふりかえりを実施する||