【現場の振り返り】初めてプロジェクト管理をしてわかったこと(1/4)
Contents
会社でプロジェクト管理を初めて任されました。
プロジェクトを計画したり、管理するのはとても難しいことをー身を持ってしらされました。
ここでは、うまくいかなかった事どうすればよかったのか？について、前向きに振り返ります。
失敗は成功のもと。何事もポジティブに行きます。
筆者のスペック
Web開発エンジニア。
自社サービスのディレクターの要件(ざっくり)から要件定義したり工数見積したり開発スケジュールを作って数人プログラマーと開発したり、場合によっては実装したりします。
Javaを使ったシステム開発が得意ですが、出向型の会社で色んな企業を転々としてたので、運用や開発以外の領域も割とそつなくこなしている方です。
振り返りに至った背景
以下のような状況が発生し、自分詩人プロジェクトをちゃんと振り返りしようと思いました。
- 自社サービスのプロジェクトの立ち上げに選任された(理由は一番関わった期間が長いため)
- 掛け持ち案件があり１ヶ月以上保留。上司からどうなっているかと言われプロジェクトの立ち上げに着手
- 急遽2週間で要件定義の作成・開発の見積もりを実施。メンバーに迷惑をかけた。
- プロジェクト掛け持ちのためうまく進まず、別担当者へスイッチ。
振り返りしたこと
【振り返り１】「本当の」要件定義をしてない
要件定義の意味を理解していなかった。そのため要件定義をいつまでにできるのか？プロジェクトは進んでいるのかを上司に報告できず、要件定義の内容も答えられなかった。
【振り返り２】要件定義の精度が低いため見積もり出来ない
要件定義の精度が低いため、開発者は何をしたいのかが理解できず困ってしまった。
【振り返り３】曖昧な表現
意外とやりがち。自分も具体的に言うのが苦手なんです・・。
対策したこと
【対策１】要件定義をすることを整理
実は要件定義でやることは結構多いことがわかった。
- 背景と目的(Why)
例：なシステム化する必要があるか？(効率化？売上上げるため？とかという視点)(why) - 体制図(who)
利用者はだれ？どの部署が影響するもの？ - 機能要件(what)
どんな機能を作るの？ - 非機能要件(what)
どのくらい稼働する必要がある？運用は？ - システム構成図(as-isとto-be)(How)
最優的にどうなっていればいいの？ - 画面遷移図(How)
どういう操作して動くシステムなの？ - スケジュール(When)
いつサービスを開始するの？その理由は？
これらの情報をまとめ、全員で意識合わせするための「プロジェクト計画書」だと教えてもらいました。
【対策２】要件定義のアウトプットを明確化
- 対策１で要件定義に書くものや設計書で書くものなどのアウトプットを設定し、
こんな粒度でこういうアウトプットで作って欲しいとお願いするように意識してます。
【対策３】具体的な表現の工夫
- それぞれの書いた内容を掘り下げ、
「いつ、何が、どうなって欲しい？」の結果まで考えて書くように意識する
まとめ
要件定義はシステム全体像をお客様・開発者との意識合わせ
- プロジェクト計画は、「お客様・開発者に5w1hの形で合意を取りプロジェクトを始めるための土台として利用されるもの」だと言ってました。
プロジェクトで何が必要かはその現場ごとで違うため正解はないとは思いますが、
複数の人たちと意識合わせをするための重要な工程だということがわかった。
プロジェクト炎上の原因を防ぐには要件定義を明確にしておくことが大切ですね。