「開発組織のマネジメント」のスライド資料が素晴らしい
「開発組織のマネジメント」のスライド資料が素晴らしいのでメモ。
資料の内容を理解したレベルで書く。
【1】問題意識としては、最近15年でWeb開発は従来よりすごく難しくなり、重要度が増している。
付け焼刃で簡単にプロダクトを作れるレベルではなくなった。
その理由はいくつかある。
一つは、開発基盤やシステムがレガシーであるため、ビジネスの変化に追いつけないこと。
2つ目は、企画チーム・開発チーム・運用チームのそれぞれで異なるやり方が根付いており、押し問答の状態になっていること。
サイロ型組織故に、開発組織の行動が局所最適化されてしまい、全体最適になっていない点に問題がある。
本来解決されるべき姿は、レガシー化を防ぐ作業に継続的に取り組むことと、サイロ型組織から自己組織化されたチーム構造へ組織を変化させること。
チームが都合で解散されるようでは、習熟度はいつまで経っても向上しない。
【2】一番の問題は、CTO不在問題。
CTOが本来果たすべき機能が組織に欠けている。
そのために、開発組織全体が全体最適にならない。
【2-1】昔は多分、品質保証部門のような部門が、開発基盤の標準化、開発環境の標準化などを行なっていた。
しかし、標準化作業はすぐに時代に乗り遅れる。
標準化された成果物ないし開発プロセスのバージョンアップや保守作業に多大なコストがかかるから、現場は疲弊する。
また、標準化の作業はトップダウンで現場に押し付けられがち。
現場からボトムアップでプロセス改善する空気を損なう。
【2-2】CTOの役割としては上記の資料でいくつかあげられている。
技術戦略、採用戦略。
アーキテクチャ、プロセスなどの開発プロセスサイクルの監督。
エンジニアの評価制度とモチベーション構築。
技術的な文化を根付かせる。
組織構造の継続的な最適化。
技術的な観点で経営にコミットする。
上記資料の一番最後の言葉が痛烈だ。
「開発組織には、開発組織特有のマネジメント手法(が必要だ)」。
ソフトウェアエンジニアやソフトウェア開発組織のマネジメント手法は、今後も試行錯誤してでも解決すべき課題だろうと思う。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 「開発組織のマネジメント」のスライド資料が素晴らしい(2014.12.21)
- 「アーキテクチャは組織構造に従う」という経験則には2つの意味がある(2014.12.20)
- ドメイン駆動設計の意義~MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築(2013.12.03)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題(2014.08.27)
「プロジェクトマネジメント」カテゴリの記事
- 「開発組織のマネジメント」のスライド資料が素晴らしい(2014.12.21)
- Redmineでリソースヒストグラムを実現するアイデア(2014.06.27)
- Redmineはプロジェクトを横断して使うべきか否かという議論の感想(2014.11.30)
- 「フレームワークで人は動く」の感想~論理フレームワークだけではく人を動かすフレームワークも大事(2014.11.29)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
コメント