様々なソフトウェア開発を経験してきた視点から、開発、マネジメント、経済などについて書いています。タイトルは、あるレトロゲームからのオマージュ。ツイッターアカウントはこちら。前回の記事で、「仕事が行き詰ったときは、とりあえず先に進めてみる」という対処法を紹介しました。この対処法を開発プロジェクトに当てはめるのは危険!とも書きました。今日の話は、開発プロジェクトにおけるケース。「個々が合理的に正しい行動を取った結果、全体として不合理な結果を招いてしまう」という現象のことです。※もともとは経済学の言葉、というかジョン・メイナード・ケインズの言葉です。開発プロジェクト(特に大規模な)でも、この合成の誤謬は発生します。個々のチームが、自分たちのミッションを効率的に遂行したからといって、プロジェクト全体が効率的に回るとは限りません。自分のチームの効率化が、全体の効率化の妨げになっているケースもあるのです。各チームに「プロジェクト全体の効率化」を義務付けるのも酷です。各チームは「自分たちの業務を遂行する」ことが第一の目的だからです。担当モジュールが完成しなかったよ。(〃'∇'〃)ゝエヘヘなんて通じません!つまり、開発プロジェクト全体の効率化を考えるのは、マネージャの仕事なのです。私は、2つの会社で大規模な開発プロジェクトに携わったことがあります。途中でマネージャのとった行動が大きく違いました。大規模な開発プロジェクトには混乱が付き物です。前述の通り、各チームが効率的に業務を遂行していても混乱は起きます。私が携わったひとつ目のプロジェクトでは、マネージャが2カ月間、プロジェクトを止めました。今のまま、無理やり先に進めても、人員が増強される下流工程で、より混乱が大きくなることが明白だったためです。次のフェーズのための準備、問題の精査・解決などを行いました。下流工程におけるスケジュールの遅延が明らかになっていました。私は、見積りを出し「今の体制・環境では、下流工程でスケジュールの遅延が起きる」と上層部に提言をしました。何も対策は取られず、プロジェクトはそのまま突っ走ってしまいました。現場のエンジニアの能力は高かったように思います。プロジェクトを上手く遂行できたのは、ひとつ目のプロジェクトです。何が明暗を分けたかと言えば、マネージャの判断というわけです。安易に先に進めてしまうと、問題が肥大化してしまうことがあります。開発プロジェクトの品質ゲート開発プロジェクトには、品質ゲートと呼ばれるものがあります。品質ゲートとは、各フェーズ(下図の場合、上流工程と下流工程)の間に設けられているチェックポイントのことです。マネージャは、単に製品品質の検査だけでなく、以下のようなことを行います。放置すると「手に負えない」という状況になってしまうことがあります。目先の効率化ばかり優先して、「目先の面倒な問題解決」を怠ってはいけないわけです。著)より開発体制や開発プロセスを見直す開発プロジェクトでは、基本的に下流工程に行くほど人数が増えます。「受け入れ体制の準備」や「ドキュメントの作成」などを行っておく必要があります。各チームにとっては面倒なルールや規制を設けることも必要になります。ソフトウェア開発においては、「コーディング規約」や「コード修正の手続き」などが該当します。各チームにとっては非効率に思えても、「完全に自由化」するよりは、プロジェクト全体として、長期的によい結果をもたらすことがあります。プロジェクト遂行に必要な生産性を確保するそして最後に、見落とされがちな「生産性の確保」です。生産性を上げるためには投資が必要です。投資の効果が表れるのには、基本的に時間がかかります。開発プロジェクトでは、投資が遅れると、その効果が低くなってしまいます。先のふたつの事例で、明暗が分かれてしまった理由は、まさにこれです。最終的に遅延させずに業務を遂行できたのです。今日のまとめ個人の業務の効率化をプロジェクトに当てはめると、合成の誤謬が発生する。大規模な開発プロジェクトは、安易に先に進めない方がよい。問題解決、環境の準備、生産性向上のための投資を先に行った方がよい。遅延したふたつ目のプロジェクトの製品は、結構売れました(^^;世の中、よい仕事をした人が、必ず報われるとは限りません。不条理は世の常ですね。逆に言えば、「製品が売れた=成功」と捉えるのは危険で、プロジェクト終結後は、事後分析を行い、継続的な改善を行うべきなのです。記事を気に入っていただけた方は、クリックしていただけると励みになります。職業:元ソフトウェアエンジニア自己紹介:東京のゲーム会社でゲームプログラマ。家電メーカーで組み込みエンジニア。今は東京に戻って暮らしています。詳細な自己紹介は、こちら。