エンジニアの生産性になるとプログラムに限定されているのがちょっとおかしい
よくあるSIビジネスで、そう、ウォーターフォールでシステム開発するやつがあるでしょう？でね、それを請け負う人達が真面目に見積もりをすると、
ここに機能数とか外部インタフェース数とか要件の実現性の難易度とか顧客のITリテラシーとかあるじゃろ？
( ＾ω＾)
⊃□⊂混ぜこぜにして見積もるじゃろ？
( ＾ω＾)
⊃□⊂え？生産性ってコードだけ考慮するの？
((((；ﾟДﾟ))))
⊃))□((⊂
まぁ、だいたいこんな感じですよね？
成果物はなんですか？
何かを考えるとき今いる立ち位置から一歩引いて、俯瞰してモノゴトを全体見ると枝葉末節の隅で迷子にならなくていいのでお勧めです。でね、SIのプロジェクトで良くあるパターンで考えると、だいたいこんな感じですよね。
要件定義
↓
基本設計(外部設計)
↓
詳細設計(内部設計)
↓
(プログラム設計)
↓
製造・構築
↓
単体試験
↓
結合(機能内統合)試験
↓
総合(機能間)試験
↓
(運用試験)
↓
移行
で、それに伴う成果物、deliverableが紐づくものです。なので工程と成果物を並べると下表のようになりますね。もちろん、工程名称も成果物名称も組織の文化で呼び名はさまざまでしょう。
| No | 工程名称 | 成果物 |
| 1 | 要件定義 | 要件定義書 |
| 2 | 基本設計(外部設計) | 基本設計書 |
| 3 | 詳細設計(内部設計) | 詳細設計書・パラメータ仕様書 |
| 4 | (プログラム設計) | プログラム仕様書 |
| 5 | 製造・構築 | プログラム・パラメータ |
| 6 | 単体試験 | 単体試験仕様書 |
| 7 | 結合(機能内統合)試験 | 結合試験仕様書 |
| 8 | 総合(機能間)試験 | 総合試験仕様書 |
| 9 | (運用試験) | 運用試験仕様書 |
| 10 | 移行 | 移行計画 |
で、これらを作るわけですよね、プロジェクトで。さて、SIビジネスで「生産性！生産性！」と声高々に言われる“生産性”はどこを指しているのか。そう、プログラムだけですよね。では、成果物の種別を表に追加してみましょう。
| No | 工程名称 | 成果物 | 工程終了時の成果物種別 |
| 1 | 要件定義 | 要件定義書 | 文書 |
| 2 | 基本設計(外部設計) | 基本設計書 | 文書 |
| 3 | 詳細設計(内部設計) | 詳細設計書・パラメータ仕様書 | 文書 |
| 4 | (プログラム設計) | プログラム仕様書 | 文書 |
| 5 | 製造・構築 | プログラム・パラメータ | プログラム・パラメータ |
| 6 | 単体試験 | 単体試験仕様書 | 文書・単体試験済みプログラム・パラメータ |
| 7 | 結合(機能内統合)試験 | 結合試験仕様書 | 文書・結合試験済みプログラム・パラメータ |
| 8 | 総合(機能間)試験 | 総合試験仕様書 | 文書・総合試験済みプログラム・パラメータ |
| 9 | (運用試験) | 運用試験仕様書 | 文書・運用試験済みプログラム・パラメータ |
| 10 | 移行 | 移行計画 | 文書・本番リリース用プログラム・パラメータ |
はい。生産性でやり玉にあがる(？)のは、プログラムだけですけどね。ほとんどは文書ですよね。その文書の内容は、メインフレームとかWebアプリとかスマホアプリで作成する様式は様々なので子細まで足を延ばしませんが、工程が定義されているなら上の表のどこかにプロジェクトで作成するドキュメントは含まれるわけです。
でちょっともう一度表を見て欲しいのですが、あなたの周りで会話される生産性とは実はプログラムだけじゃないですか？
プロジェクトでの生産性はいろいろ考慮しないとね
プロジェクトのトラブルは過去事例を鑑みるに、製造工程で行き成り「ファイヤー！」と火を噴くものではありません。多くはその前工程で火種が仕込まれているものです。結果的に戦場となる製造工程や試験工程の前の設計工程がアレなわけでそこから導線が引かれていてその先につもり積もった火薬が暴発するわけです。
つまり、プログラムの生産性より設計工程の生産性をなぜ「もっと気にしないの？」と言いたいわけです。見積もりでもプロジェクト計画でも「重点的に押さえないといけないことなんだよ。」ということなんです。でも、みなさん設計書はdisるし、コードの生産性は気にするし。
その上、生産性なんて過去の参考事例の数字だけでしかないのであくまでも参考ですよ。だって、その生産性の実績をはじき出したメンツがそのままスライドしてその今目の前にあるプロジェクトに入ってくるわけじゃないでしょ？
そんなことよりプロジェクトを構成するメンバに必要なスキルとレベルを特定し、それをqualifyするスキルを持つメンツを拉致る方がいいです。それが見積もりなり、プロジェクト計画の観点であることはPMO professional serviceで書き記しているのでお暇なら見てよね、です。
結局、見積もりとかプロジェクト計画とかで欲しい生産性とは、その工程ごとの成果物によるのでプログラムだけの生産性だけ気にしてもしょうがないんです。しょぼいドキュメントをもとにいくら優秀なエンジニアが頑張ってコードを書いてもしょぼさを保管してくれる保証はないです。ある程度のレベルで設計書が書かれていれば、あとは製造工程でコードを書くエンジニアがそれについていければその程度の作業品質は期待できるのです。いや、それはそう思いたい……。
