組織のプロジェクトマネジメント能力よりも組織内のロールを重視した開発へ

最近の開発スタイルの流れとして、組織のプロジェクトマネジメント能力よりも組織内のロールを重視した開発スタイルがあるように思える。
ラフなメモ書き。

【元ネタ】
開発の背景｜総合プロジェクト管理ツール SI Object Browser PM

CMMI とは：梅田弘之のプロジェクトマネジメント講座：【第２章】CMMIを意識しよう

[ThinkIT] 第3回：CMMI導入がもたらす光と影 ? 日本の文化にあったプロセス改善 (1/3)

スクラムの新しさ: プログラマの思索

従来のウォーターフォール型開発では、組織のプロジェクトマネジメント能力を重視するスタイル。
PMBOKやCMMIがまさにそう。

PMBOKでは、かつて様々なマネージャが経験した暗黙知を全て形式知として体系化することで、プロジェクトマネジメントの知識とプロセスを標準化した。
さらに、QCDというゴールに向けて、進捗管理や品質管理のような典型的なプロセス管理だけでなく、要員の管理のような人的資源管理、要件の範囲を確定させるスコープ管理、機材や外注や契約など調達管理もプロセスの範疇に入れて、管理対象とした。

CMMIは、組織のプロセスの成熟度モデルを導入することで、組織のプロジェクトマネジメント能力を評価する技法を導入した。
日本の製造業の流れを受けつぐソフトウェア開発スタイルを追いかけるならば、最終的にはCMMIに行き着くのではないか。

一時期、日本の経済産業省がCMMIの日本版を作り、発注企業の要件の一つにしようとする試みがあった。
しかし、結局実現されていない。
あれだけCMMIを注目していた時期があったのに、CMMIレベル5の認定を受けている日本の企業は、かなり少ないらしい。
おそらく、中国やインドのソフトウェア企業よりも数が少ないのではないか。

CMMIモデルについて。CMMIレベル５の認定を受けている日本の企業はどこでしょうか... - Yahoo!知恵袋

ウォーターフォール型開発では、開発プロセスを重視し、開発者の属人性を廃し、手続きの標準化に注力する。
しかし、そのやり方は、製造業に向いていても、ソフトウェア開発に向いているとは言えない。

ドキュメントや開発手順を標準化しても、IT技術の進化についていけずに、その標準化したフォーマットそのもんが陳腐化してしまう。
どの開発・運用保守案件でも、どの人でもアサインできるようにしたいが、業務知識やアーキテクチャ設計、フレームワーク、インフラなどの技術が特有であるために、結局、特定のメンバーに依存してしまい、プロジェクトからメンバーを剥がせない。
誰でも担当できるような案件は、単価が安すぎて、逆に旨みがない。

むしろ、メンバー全員がプロジェクトマネジメント能力を持つように研修で教育して、メンバーの意識やスキルを向上するような雰囲気を作ると、自然に、メンバーが役割分担を自ら調整するようになる。

10年以上前のソフトウェア開発では、ロールが多すぎ。
論理的な業務データを扱うDA(データ管理者)、物理的なDBサーバーの保守担当者(DBA)、Webサーバの保守担当者、フレームワーク設計者、そして、たくさんの実装メンバー。
その周囲に、各チームリーダー、リーダーを束ねるプロジェクトマネージャ、そして、重役ないし取締役、など、数多くのロールが必要だった。
もちろん、顧客側にも、情報システム部門、本来のユーザである業務部門、そして稟議を承認する経営者などもいる。

XPの白本「XPエクストリーム・プログラミング入門―変化を受け入れる」を読んでも、ソフトウェア開発に必要なロールが１０種類以上出てくる。
ウォーターフォール型開発なら、そのロールはもっと増える。

しかし、それらのロールは、IT技術の発展によって、どんどん消滅したり、統合されていった。
クラウド技術のおかげで、DB・Webサーバなどのインフラ担当は、開発者が担当できる。
業務知識を持つデータ管理者、アーキテクチャ設計者も、優れたフレームワークがオープンソースで普及している今は、上級のプログラマで十分に担当できる。

一方、アジャイル開発では組織内のロールを重視した開発スタイルなので、ウォーターフォール型開発とは全く違う。
スクラムでは、もっと過激に、アジャイルなチームは３種類のロールしか必要ない、と言い切っている。
ロールが少ない方が開発はしやすい。
プロジェクトマネージャが得意とする「調整」という名の無駄な政治力を発揮する必要もない。
チーム内の風通しも良くなる。
マネージャの大好きな言葉「見える化」も、ロールの種類が少ない分、簡単に実現できる。
スクラムの言う「透明化」は、ロールの種類の少なさからも発生する。

必要なのは、３種類のロール(チーム・スクラムマスター・プロダクトオーナー)が一体化したスクラムチームで邁進するだけだ。
優れたプログラミング技術を持つ人達が集まって、スクラムチームを形成できれば、政治力の行使という無駄な労力がない分、速く開発できる。
スクラムの逸話でよく話題となる「ニワトリとブタ」は、その文脈で捉えると、より実感できると思う。
外部のステークホルダーによる政治的干渉は、ソフトウェア開発を邪魔するだけの無駄なものなのだ。

なのに、特に日本のシステム開発は、上司の顔を立てるために稟議が多かったり、ナントカ会議という合議制で誰も責任を追わない体制が幅を利かせている。
肝心のシステム開発そのものを阻害する組織的な壁が日本では特に多いと思う。

最近のソフトウェア開発プロセスの歴史を考えると、数多くのロールがIT技術の進化によってどんどん淘汰されたり統合されることで、ロールの種類が少なくなり、チームの透明性を高めていく方向に進化しているように思える。
「組織パターン」を読んでいると、改めてそう思う。