受託(WF)開発を成功させる考え方

# この記事を書いた理由
 - なんだかんだ毎年火消し対応させられるので、何が毎回問題になっているか整理した結果、失敗事例の反対を定義してみたくなった。

---
# 考え方
- プロジェクトの成功は、契約・要件定義でほぼ決まっている

- 遅延が発生し始めると、本来のコストに対して3倍以上かけないと取り戻せない

- WFにおいてフェーズ毎の同時並行は基本NG

- `人・物・金` <<<<< `時間` の確保をとにかく優先し、意識して発注元と交渉し続けること

- プロジェクトが上手く行っているかの指針

## プロジェクトの成功は、契約・要件定義でほぼ決まっている
### 契約
#### 基本方針
 - 発注元と対等な交渉ができる状態で契約をすること
    - ほとんどの受託開発は、納期・予算が決まってスタートしている
        - しかし、システム開発のほとんどは予期せぬ追加対応が発生してくる
        - 住宅で例えるなら、以下の事例くらい不明瞭な段階でいつも契約を結んでいる(気がする)
            - １階建なのか３階建なのか不明
            - 木造なのか鉄筋なのか不明
            - どのくらいの敷地なのか不明
            - どの場所に建てたいのか不明
            - 部屋数・トイレ・風呂・キッチン・和洋室の数も不明
    - 重要なのは、フェーズ毎の遅延をした場合に、納期を後ろ倒しに出来る状態を確保すること
        - 遅延の主な理由は、お客様都合の、契約・要件定義で遅延することがほとんど
            - 契約: 印鑑押すのが遅いなど
            - 要件定義: お客様に決めてもらう要件がなかなか決まらない

#### 理想と現実 
 - 理想
    - 発注: 私たちでは作れないからお願いしている
    - 受注: お金を頂いて開発させてもらっている
 - 現実(失敗)
    - 発注: 作らせてやっている(他にも依頼するところはある)
    - 受注: 競合他社に取られないように受ける

### 要件定義
#### 基本方針
 - このフェーズが一番重要でもあるので、しっかりと時間を確保すること
 - 発注側が本当に実現したいことのヒアリングを入念に行い、後工程で手戻りが発生しないように考慮すること
    - しっかりと発注側と合意をとっておくこと
        - 実装が終わった段階で、こうではなかったという話にならないようにすること
        - なんとなくこれでいいでしょ的な状態にしないこと
 - 発注側都合で遅延した場合には、その旨をしっかり伝えること
    - 交渉のカードとしてストックするのでもよい
    - 常に伝えることで、発注側にも納期があることの意識付けを行う

#### 理想と現実 
 - 理想
    - しっかりと時間を取って、3回くらいリテイクするつもりで行う
    - 発注元に起因する遅延は、常に伝える
        - 要件定義が終わったタイミングで納期の後ろ倒しまで交渉するのもあり
    - この段階では不確実なものも多いので、不確実な要素が強いものはしっかりと双方の認識を合わせておく
 - 現実(失敗)
    - なんとなくヒアリング・要件定義
    - 遅延しても、後工程でなんとか吸収できるでしょ

---
## 遅延が発生し始めると、本来のコストに対して3倍以上かけないと取り戻せない
 - 前工程の問題は、後工程でスノーボールする

### 基本方針
 - そのフェーズで必要なことはやっておくこと
    - 後工程を考え、今の工程を行う意識(`手戻り防止`)
    - 少し先の後工程を考え、後工程で必要な準備を事前に始めること(`遅延リスク軽減`)
        - 人員の確保
        - 環境の整備

### 遅延の主な要因
 - 要件定義遅延
 - 人員不足
 - 期間不足
 - 実装力不足
 - 準備不足

### よくある遅延事例
 - 後工程で増員してスケジュールを吸収すればいいという思考(`管理者`)
 - 発注側が期待していたものではなかった(`要件`)
 - 後から発生する追加要望(`要件`)
 - 要件漏れ・考慮漏れなど(`要件・設計`)
 - 仕様の整合性不備(`設計`)
 - リリースまで見据えた環境構築(`開発`)
 - リファクタリングしてない・できてない(`開発`)
 - 共通モジュールを用意していない・できてない(`開発`)


---
## WFにおいてフェーズ毎の同時並行は基本NG
### 基本方針
 - WFの基本はフェーズ毎に確実に正しいものを定義して積み上げていくこと
    - 手戻りは基本許さない(はず)

### よくある失敗事例
 - スケジュール押してるし、こっちは設計終わってるので、先に実装しましょう
    - そもそもスケジュール遅延してることの問題解決になっていない
    - 人員に余裕があるなど、体制が整っているならやってもいい
        - ただし開発環境が整っているなどの前提であるので、後工程の準備ができてないならやってはいけない
    - これをやりはじめると、以下のようなリスクをかかえる
        - 管理の複雑度/コスト増
        - 前工程が終わっていない機能を影響を受け、後工程に進んでしまっている機能の追加修正が発生する可能性
            - 追加発生した再見積もり/再修正のコスト増
        - 要件定義でも書いた、発注側都合の遅延に気づきづらくなる
        - 人員が整っていない場合、前工程の品質ダウンによるバグ発生率UP

---
## `人・物・金` <<<<< `時間` の確保をとにかく優先し、意識して発注元と交渉し続けること
### 基本方針
 - スケジュール遅延を `人員の追加` でカバーするという発想を捨てる
 - スケジュール遅延を `時間の延長` でカバーするという発想を持つ
 - `時間` を確保するために、 `人・物・金` を投入する

### よくある失敗事例
 - 納期の延長を交渉できないPM
 - 決定を先送りにする管理者
 - 後工程で人員追加してカバーしましょう
 - 管理が煩雑、ツール使いづらい
 - MTG問題
    - 数が多い
    - 参加者が多い
    - 時間内で終わらない
    - 資料作成
    - 資料の事前共有・把握がない
    - 印刷
 - 開発端末のスペックが悪い(追加ディスプレイがない)


---
## プロジェクトが上手く行っているかの指針
### 基本方針
 - 勤務状況
    - 黄色信号: メンバーの３割以上が、常に残業し続けている
    - 赤信号: 土日出勤まで発生している
 - メンバー各員の状況把握具合
    - 黄色信号: 言われたことだけやっていて、状況について何もしらない
    - 赤信号: 目先のタスク消化しか頭に入っていない

### よくある失敗事例
 - 少し遅れてるし残業して対処します
    - 残業で対処したことによる、品質低下・考慮漏れ
    - 残業しているメンバーがいることによる同調圧力
    - 謎に残業メンバーが評価される

---
## 最後に
 - 見返す度に整理能力が甘いと思いました。駄文失礼。
 - 私はPMが大変なのを知っているので、基本やりません。
    - 大体が雇われPMなので、 `人・物・金・時間` の管理・交渉をPMの判断でやることができないためです。
 - こんなの理想で現実は無理だ。という内容を含んでいますが、意識付けが重要なので書くことにしました。
    - 理想と現実のギャップをどれだけ埋めることが出来るかが、私たちの仕事。
 - 受託開発のほとんどはオーダーメイド(`不確実なもの`)で作るのに、WF(`不確実なものがほぼない前提の工程`)で進めるので失敗している気がする。
    - 上手く行っている `受託/WF` を見たことがないので、上手く行っている事例が知りたいです。（切実
 - いつもQiitaにはお世話になってます。