プロジェクトを大失敗させたくないあなたに

枕

はじめまして

嘘です。実は去年のアドベントカレンダーも書いているのではじめましてではありません。

AFグループのとあるサービスで開発マネージャをやっております。Qiitaのプライベートアカウントは初々しい昔の自分丸出しなので公開できません。よろしくお願いします。

さて、今年が仮にコロナ禍でなかったとしても年末年始は自宅待機＆作業予定だったので、そんな恨み節を込めて今年は書かせていただこうかと思います。

恨み節を書いたところでMAYDAYはやってくるのですが、
どうせ来るなら糧になるよう、ポジティブな記事にしようと書き始めの今の今は思ってます。

P.M.A!!

書きたいこと

P.M.A!!とか書いておきながら早速なんですが、エンジニア経験が長くなってくると

• プロジェクトがスケジュール通りに進まない
• 要求事項と実装が若干違っていた
• 全く意図しない想定外の挙動をしている
• なぜか動いている

など大なり小なりよくあると思います。
その規模が大きくなればなるほど
「このプロジェクト失敗だね」と言われ
ポンッ、と肩に手を置かれる可能性は高まります。

そこで

風邪をひいたり、仕様変更があったり、予定していない状況になった場合でも、最終的にプロジェクトオーナーや依頼主が納得した状態になるようなプロマネtipsを書ければなーと思います。
※プロマネ以外の人でも概念を理解してもらえれば人生tipsになるかと

本編

まずは

1. プロジェクトの失敗ってなんだっけ？

複数日や複数人に渡るプロジェクトでは
プロジェクトの失敗と言うと、ざっくりこんな感じの結果が浮かびます。

    - Q)　リリースしたけどバグだらけ
    - C)　予算以上の開発コストが発生してしまう
    - D)　納期に間に合わない

要は、当初予定していたGOALからズレることです。

2. プロジェクトが失敗するのはなぜ？

誰しもがプロジェクトを失敗したくないと考えているのに、なぜプロジェクトは失敗してしまうのでしょうか。

- プロジェクトの失敗原因の一例
    - スケジューリングがそもそも甘い、無理をしている
        - 雑な見積りで「できる」って言っていませんか？
        - 納品物の種類、提出タイミングは合意されてますか？
        - ドキュメントレビューはちゃんとしてますか？されてますか？
    - 設計が悪い
        - ドキュメントは最後にまとめてコードから逆起こしなんて考えてませんか？
        - 細かい疑問は作りながら解決だ！なんて思ってませんか？
        - 課題管理を行い、複数人で合意までしていますか？
        - ドキュメントレビューはちゃんとしてますか？されてますか？
    - コーディングが悪い
        - 何も考えずに類似ロジックの使い回ししてませんか？
        - 影響範囲は特定できていますか？確認はしていますか？
        - コードレビューはちゃんとしてますか？されてますか？
    - テストが悪い
        - 少し疑問が出ても自分の解釈でOKにしていませんか？
        - エビデンスは取ってますか？
        - ドキュメントレビューはちゃんとしてますか？されてますか？

これらは一例ですが、開発工程毎に違った理由の原因があると思います。
しかも大体、本人はやっているつもり、だったりします。

3. プロジェクトを失敗させないためにはどうしたら良い？

    - レビュー
    - 課題管理
    - エビデンス

↑で書いてしまいましたが、上記のような 複数人による合意 が必要なタスクを真面目にルールに沿って実施する事です。
合意形成をしっかりやれば、少なくとも大きな失敗にはなりません。
本人はやっているつもり、も第三者の目を入れる事で軌道修正されます。

4. ではなぜプロジェクトの大失敗が往々にしてあるのか

簡単です。

    - レビュー
    - 課題管理
    - エビデンス

がおざなりだからです。
もっと細かく言うと、ドキュメントやコーディング時も適宜複数人と認識を合わせる事で、スケジュールや仕様の方向が若干ずれた時に最小限で軌道修正できます。例のアレみたいに。

大げさと思われるかもしれませんが

- 目次
- 大項目

↑を書いたタイミングでまずレビューをしてもらい、合意してもらう事でプロジェクト関係者全員が同じ方向に進んでいる事の確認と、合意がある事でリスクヘッジ、責任分担もできる事になります。

まとめ

趣味や個人でなく、複数人による開発をしていると

- こんな質問して怒られないかな、笑われないかな
- レビューしてもらって指摘されたら落ち込んじゃう
- スケジュールが遅れているなんてお客様に言ったら怒られちゃうかも

こんなはたから見ればどうでも良いことが、本人にはプレッシャーだったりする事があります。
実際、私はありました。今でも全部は払拭できていないと思います。
しかし、社会人としてチーム開発をする以上は個人ではなくチームの結果を最重要項目として考え、
逆にレビューをしてもらう事で自分のミスをチームのミスにヘッジできるという考えをオススメしたいと思います。

以上、聞くは一時の恥聞かぬは一生の恥、でした