ソフトウェア開発はオーバーヘッドが大きい
ソフトウェア開発に従事して思うことは、色んな意味のオーバーヘッドが多いこと。
顧客の要望を聞いてから、設計してプログラムへ実装するのに結構時間がかかる。
顧客の要望を聞いた日から、実際に顧客がシステムを確認するまでに、かなり時間がかかる。
設計者と開発者、開発者とテスト担当者の間では、システムの理解度、業務の理解度に距離感があり、その差を埋めるためのコミュニケーションはかなりのオーバーヘッドが生じている。
実際、朝会やふりかえりはそのための時間なのだが、それ以外でもレビューなど、色んなコストがかかっている。
そして、「人月の神話―狼人間を撃つ銀の弾はない」の話のように、人を注ぎ込むほど、実は開発速度は上がらないという矛盾がある。
また、昨今のような短納期の開発では、開発者の出入りが激しく、チームビルディングが非常に難しくなっている。
ソフトウェア開発は、技術力のある人にすごく依存している。
ソフトウェア開発は製造業のように、リソースを注入すれば、生産性が劇的にアップするわけではない。
むしろ、破壊的イノベーションを奨励して、そのイノベーションから生じる技術革新の方がはるかに生産性が高くなる。
ソフトウェアはすごく繊細だ。
他の産業よりも、コミュニケーションコストがはるかに高いのではないか?
レビューやソースインスペクションだけでなく、ペア設計、ペアプログラミング、本番リリースをペア作業など、一緒に作業することは実は重要だ。
理由は、欠陥の防止だけでなく、システムの設計思想を共有しやすくするためにあるからだ。
二人による共同作業でコストがかかることを恐れてはいけない。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ(2026.10.01)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
「プロジェクトファシリテーション」カテゴリの記事
- ふりかえり手法にジョハリの窓を使って自己開示と他者フィードバックを得る(2026.09.27)
- 組織変革の鍵を「聞く」体験から探る(2026.06.14)
- PM理論で読み解く日本人リーダーの弱点(2026.05.12)
- astahでPJ管理もプロセス設計もアイデア発想も全て表現したい(2025.10.25)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)


コメント