忍者ブログ

東からの放浪者

様々なソフトウェア開発を経験してきた視点から、開発、マネジメント、経済などについて書いています。
タイトルは、あるレトロゲームからのオマージュ。

ツイッターアカウントはこちら。

開発プロジェクトが行き詰ったときの対処法

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

開発プロジェクトが行き詰ったときの対処法

前回の記事で、「仕事が行き詰ったときは、とりあえず先に進めてみる」
という対処法を紹介しました。

しかし、この対処法を開発プロジェクトに当てはめるのは危険!
とも書きました。

今日の話は、開発プロジェクトにおけるケース。

合成の誤謬(ごびゅう)

度々この言葉を使っていますが、合成の誤謬とは、
「個々が合理的に正しい行動を取った結果、全体として不合理な結果を招いてしまう」
という現象のことです。

※もともとは経済学の言葉、というかジョン・メイナード・ケインズの言葉です。

開発プロジェクトにおける合成の誤謬

開発プロジェクト(特に大規模な)でも、この合成の誤謬は発生します。

個々のチームが、自分たちのミッションを効率的に遂行したからといって、
プロジェクト全体が効率的に回るとは限りません。
自分のチームの効率化が、全体の効率化の妨げになっているケースもあるのです。

しかし、各チームに「プロジェクト全体の効率化」を義務付けるのも酷です。
なぜなら、各チームは「自分たちの業務を遂行する」ことが第一の目的だからです。

プロジェクト全体のことを考えていたら、
担当モジュールが完成しなかったよ。(〃'∇'〃)ゝエヘヘ

なんて通じません!
つまり、開発プロジェクト全体の効率化を考えるのは、マネージャの仕事なのです。

2つの開発プロジェクトの事例

私は、2つの会社で大規模な開発プロジェクトに携わったことがあります。

どちらも似たような規模、開発期間、開発者数のプロジェクトだったのですが、
途中でマネージャのとった行動が大きく違いました。

ひとつ目の事例

大規模な開発プロジェクトには混乱が付き物です。
前述の通り、各チームが効率的に業務を遂行していても混乱は起きます。

私が携わったひとつ目のプロジェクトでは、
マネージャが2カ月間、プロジェクトを止めました。

今のまま、無理やり先に進めても、人員が増強される下流工程で、
より混乱が大きくなることが明白だったためです。

その間、開発者はほとんど実装作業を行わず、
次のフェーズのための準備問題の精査・解決などを行いました。

ふたつ目の事例

ふたつ目のプロジェクトでは、上流工程の時点で、
下流工程におけるスケジュールの遅延が明らかになっていました。

私は、見積りを出し「今の体制・環境では、下流工程でスケジュールの遅延が起きる」
と上層部に提言をしました。

しかし、何も対策は取られず、プロジェクトはそのまま突っ走ってしまいました。

・・・結果どうなったか?
ひとつ目のプロジェクトは、最終的には遅延せず、
ふたつ目のプロジェクトは、最終的に遅延しました( ´_ゝ`)

個人的な感想になりますが、ふたつ目の事例の方が、
現場のエンジニアの能力は高かったように思います。

しかし、プロジェクトを上手く遂行できたのは、ひとつ目のプロジェクトです。
何が明暗を分けたかと言えば、マネージャの判断というわけです。

開発プロジェクトが行き詰ったとき

個人の作業とは違い、大勢の人たちが相互依存しながら進めていく開発プロジェクトは、
安易に先に進めてしまうと、問題が肥大化してしまうことがあります。

開発プロジェクトの品質ゲート

開発プロジェクトには、品質ゲートと呼ばれるものがあります。

品質ゲートとは、各フェーズ(下図の場合、上流工程と下流工程)の間に設けられている
チェックポイントのことです。

プロジェクトの品質ゲート

マネージャは、単に製品品質の検査だけでなく、以下のようなことを行います。

問題を先送りせず、対策を取る

大規模な開発プロジェクトでは、「大したことない」と思っていた問題でも、
放置すると「手に負えない」という状況になってしまうことがあります。

目先の効率化ばかり優先して、「目先の面倒な問題解決」を怠ってはいけないわけです。

ラピッド デベロップメント 図4-4
ラピッドデベロップメント-効率的な開発を目指して』(Steve McConnell 著)より

開発体制や開発プロセスを見直す

開発プロジェクトでは、基本的に下流工程に行くほど人数が増えます。
「受け入れ体制の準備」「ドキュメントの作成」などを行っておく必要があります。

また、各チームにとっては面倒なルールや規制を設けることも必要になります。
ソフトウェア開発においては、「コーディング規約」や「コード修正の手続き」などが
該当します。

各チームにとっては非効率に思えても、「完全に自由化」するよりは、
プロジェクト全体として、長期的によい結果をもたらすことがあります。

プロジェクト遂行に必要な生産性を確保する

そして最後に、見落とされがちな「生産性の確保」です。

開発における生産性の誤解」の記事等で書きましたが、
生産性を上げるためには投資が必要です。

開発初期から始める投資

投資の効果が表れるのには、基本的に時間がかかります。
そして開発プロジェクトでは、投資が遅れると、その効果が低くなってしまいます。

開発プロジェクトにおける投資

先のふたつの事例で、明暗が分かれてしまった理由は、まさにこれです。

プロジェクトを止めてでも、問題解決、環境の準備、
そして生産性向上のための投資を行ったプロジェクトの方が、
最終的に遅延させずに業務を遂行できたのです。

今日のまとめ

  • 個人の業務の効率化をプロジェクトに当てはめると、合成の誤謬が発生する。
  • 特に大規模な開発プロジェクトは、安易に先に進めない方がよい。
  • 問題解決、環境の準備、生産性向上のための投資を先に行った方がよい。

それで、2つの事例のプロジェクトの製品は、どうなったの?(*'-')

実は、遅延しなかったひとつ目のプロジェクトの製品は全く売れず、
遅延したふたつ目のプロジェクトの製品は、結構売れました(^^;

世の中、よい仕事をした人が、必ず報われるとは限りません。
不条理は世の常ですね。。。

逆に言えば、「製品が売れた=成功」と捉えるのは危険で、
プロジェクト終結後は、事後分析を行い、継続的な改善を行うべきなのです。
記事を気に入っていただけた方は、クリックしていただけると励みになります。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓


PR

コメント

プロフィール

HN:
なかば
性別:
男性
職業:
元ソフトウェアエンジニア
自己紹介:
東京のゲーム会社でゲームプログラマ。
家電メーカーで組み込みエンジニア。
その後、京都に移動して観光を楽しみながら
製品開発、業務改善、QA管理などを経験。
今は東京に戻って暮らしています。

詳細な自己紹介は、こちら

ブログ紹介

管理人(なかば)の個人ブログです。

もともと、以前の職場で投稿していた社内ブログの延長で書き始めました。
エンジニア仲間に向けた雑な口調はそのままにしていますが、その辺は気にせず読んでもらえると嬉しいです(*'-')

諸事情により更新を停止していますが、生きています。そのうち再開する予定です。

カレンダー

02 2024/03 04
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31