【現場の振り返り】初めてプロジェクト管理をしてわかったこと(3/4)

2020年2月13日お仕事ノートシステムエンジニア,要件定義

会社でプロジェクト管理を初めて任されました。
プロジェクトを計画したり、管理するのはとても難しいことをー身を持ってしらされました。
ここでは、うまくいかなかった事どうすればよかったのか？について、前向きに振り返りして行きます。

失敗は成功のもと。何事もポジティブに行きますー。

筆者のスペック

Web開発エンジニア。
自社サービスのディレクターの要件(ざっくり)から要件定義したり工数見積したり開発スケジュールを作って数人プログラマーと開発したり、場合によっては実装したりします。
Javaを使ったシステム開発が得意ですが、出向型の会社で色んな企業を転々としてたので、運用や開発以外の領域も割とそつなくこなしている方です。

アウトプットの内容を相手と共有(対策２)

工程ごとのアウトプットを相手と相談する。

工程毎のアウトプットがなぜ大事だと思ったか。というと現場で以下のシチュエーションに遭遇したからです。

「基本設計・詳細設計・単体テストにおいて見積もるのはいいが、何を設計するのか分からないので見積もれない。」

つまりは見積もりの精度を高めるために相手と相談する必要があったからです。
(絶対に他にも意味はあると思いますが、今の現場ではこれが一番必要でした…)

なので、各設計書で何を書く？というところからはじめました。
ここでは全ての工程を書くわけにいかないで、基本設計書で具体的に何をやったかを書きます。

設計書の議論をすると、設計書ってこう書くべきだ！という議論がおおいに飛び交ってしまうことは予想していたため、
いくつか制約事項をつけた上で話し合いをすることにしました。

いくつか制約事項をつけた上で話をすすめたら、シンプルなシーケンス図一つだけでいいんじゃね？
というところに落としどころで決まりました。
また一度フォーマット（粒度）が決まればざっくりなスケジュールは経験者であれば出すことは可能でした。

まとめ

アウトプットとその粒度は書く種類がおおいため、いろんな人と話す必要がありますが、あと工程を進めるためと依頼者とコミュニケーションを進める上では重要な項目だと思います。量が多いですが地道に粘りつよくやっていく必要があると思います。

次は最後の対策3をまとめます。