プログラマの思索

スクラムが従来のアジャイル開発に比べて優れている点は、役割のバランスが絶妙なことにあると思う。
また、日本の受託ソフトウェア開発の最大の弱点は、プロダクトオーナー不在が常駐化している事だと思う。
色々考えたことをラフなメモ書き。

【参考】
日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記

ソフトを他人に作らせる日本、自分で作る米国：日経ビジネスオンライン

Twitter / akipii: PMBOKではプロジェクトマネジャが発注者にいることが前提になっている。日本ではIT企業すなわち受注者にPMがいることがほとんどだから、米国の手法を修整して取り入れないとうまくいかない。ソフトを他人に作らせる日本、自分で作る米国 http://business.nikkeibp.co.jp/article/tech/20121010/237890/?P=3&rt=nocnt …

Twitter / akipii: 日本は一括請負契約、欧米はTime&Material契約、つまり時間単価契約。日本の方が赤字プロジェクトになりやすい指摘が面白い。　日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記 http://yoshinorinie.hatenablog.com/entry/2012/11/26/095526 …

【1】Scrumが従来のアジャイル開発に比べて優れている点の一つは、Scrumが定義するソフトウェア開発プロセスでは、プロダクトオーナー(PO)・スクラムマスター(SM)・チームの3つの役割だけで十分である、と明確に定義したことだと思う。
この3つの役割が、Scrumでは絶妙なバランスで成り立っているのだと思う。

プロダクトオーナーは、プロダクトのバックログを決定し、プロダクトのROIに最終責任を持つ人。
彼が、リリースする仕様を決定し、プロダクトの予算や原価管理の責任も持つ。
そして最も重要な特徴の一つは、複数のスクラムチームから成る大規模プロジェクトであっても、プロダクトオーナーは唯一人の人物に限ることだ。
つまり、プロダクトのバックログを決定する責任と権限は唯一人の人物で明確化されている点が画期的。
この点は、認定スクラムマスター研修で衝撃を受けた内容の一つだった。

唯一人のプロダクトオーナーがバックログを決めるので、小規模や大規模なシステムにかかわらず、システムの統一方針はプロダクトオーナーの中では一つにまとまる。
もちろん、大規模システムではプロダクトオーナー一人では忙しすぎるから、機能エリアごとにプロダクトオーナーを補佐するサブPOのような人がいて、それぞれでバックログを管理するが、プロダクトオーナーが各エリアのバックログを集めて最終的に決めるようにすればいいらしい。
POを補佐するプロダクトオーナーのチームが大規模プロジェクトでは必要になることを示唆している。

フィーチャーチーム

Scaling Lean & Agile Development: Feature Teams | Introduction to Feature Teams | InformIT

Coplienの生成的パターン言語では、Patron(パトロン)に当たる人になるだろう。

pattern12 - パトロン

【2】スクラムマスターは、プロダクトオーナー・スクラムマスター・チームの3つから成るスクラムチーム内のコミュニケーションを円滑化させ、課題解決を図る権限を持つ人。
スクラムマスターは、スクラムのプロセスの守護者でもある。
僕のイメージではファシリテーターのような役割を持つ人であり、サーバント・リーダーシップを持つ人とも言える。
Coplienの生成的パターン言語では、FireWall(防火壁)やGateKepper(門番)に当たる人になるだろう。

pattern25 - ゲートキーパー

pattern24 - ファイアーウオール

【3】スクラムがアジャイルな開発チームに必要な役割を3つに明確化したことは画期的だと思う。
PO・SM・チームに期待されている役割が明確なのだ。

逆に、XPで定義されている役割は、XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法(第1版)によれば、プログラマ・ユーザ・テスター・トラッカー・コーチ・コンサルタント・上司の7つがある。
XPエクストリーム・プログラミング入門―変化を受け入れる(第2版)では更に10個以上に増えている。
だから、役割が多すぎるために、組織運営で注意すべき点が多く、それぞれの役割で期待されていることが分かりづらい弱点があると思う。
(個人的には、XPエクストリーム・プログラミング入門は第2版よりも第1版の方が好きだ)

XPではオンサイト顧客のように、ユーザが果たすべき責務がプラクティスの一つとして既にある。
だが、プロダクトオーナーはオンサイト顧客であるだけでなく、予算や原価管理の権限も持ち、システムのROIまで責任を持つから、更に権限が強力だ。
だから、プロダクトオーナーと開発者の関係は、プロダクトオーナーの方が強すぎてそのままではバランスが悪くなってしまいがちになると思う。
でも、そこにスクラムマスターと言うプロダクトオーナーと開発者とは違う第三者的な立場の人がいて、スクラムチーム全体で課題解決していき、スクラムのプロセスを守るような役割が設定されている。

【4】@hatahataさんから、プロジェクトマネージャがシステム提案やシステム要件定義で最初にやることは、MANを持つ人を探すことだ、と聞いて納得した。
MANとは、Money(システムの予算)、Authority(システムの要件や仕様)、N(ニーズ。システムを実際に使う為に欲しい機能が分かること)の3つの権限を持つキーマンを指す。

日本の受託開発では、MANという3つの権限を持つ人がそれぞれに分かれていたりする。
例えば、予算を持つのは経営戦略室のように社長に近い部門で、情報システム部門がユーザ企業の各部門のニーズを集めて集約する役割を持つ場合が多いだろう。
だから、ユーザ企業の情報システム部門は単なる窓口に過ぎず、決定する権限が圧倒的に弱い。

更にマズイことには、ナントカ委員会のような合議体が予算・要件を決定するために、予算・要件・ニーズの各要素が更に複数人に分かれてしまっている場合があることだ。
例えば、1ヶ月に1回開催されるナントカ委員会で、すべての委員が予算や要件を承認しないと、先に進められない状況が出てくる。
日本の組織では、こういうトロい意思決定が意外に多い。
特に公的機関はそのような場合が多いのではないだろうか？

つまり、日本の会社や公的機関の組織構造上、プロダクトオーナーのような強い権限を持つ人物が唯一人ではなく、複数人に分かれてしまっていて、誰が最終的な権限を持つのか不明なのだ。

こうなってしまった理由の一つは、ユーザ企業がSIベンダーにシステムの開発を請負契約で全て丸投げしていることもあるだろう。
あるいは、ユーザ企業の情報システム部門がコストセンターのために権限が弱く、SIベンダーがユーザ企業の情報システム部門と化してしまっていて、ユーザ企業がSIベンダーにシステムの保守だけでなく、システムの提案を通じたビジネスや業務の改善まで期待していることもあるだろう。

すると、ユーザ企業にプロダクトオーナーがいないので、SIでは、プロジェクトマネージャが限定された権限のプロダクトオーナーとスクラムマスターの2つの役割を担うことになる。
プロジェクトマネージャは、開発チームに作業指示を的確に出すこと、ユーザの要件の取りまとめとバックログの決定、開発上出てきた課題解決に至るまで、権限の範囲がとても広い。

つまり、プロジェクトマネージャの権限は開発チームよりもはるかに強力過ぎる。
開発チームとのバランスが取れておらず、一方的になっているのだ。
プロジェクトマネージャは作業量が多すぎて忙しすぎるし、開発チームは受け身になりがちで、なかなか解決されない課題のために、開発が遅延しがち。
そのために、開発チームもプロジェクトマネージャも四苦八苦する時が多いと思う。

【5】スクラムでは、上記のような問題点に対し、ソフトウェア開発には3つの役割だけで十分であり、三者が自分の役割を明確に意識して行動することで、より良いソフトウェアがアジャイルに作れると明確に指摘した。

XPはオンサイト顧客やコミュニケーションという概念を通じて、ソフトウェア開発に必要な諸要素を暗黙的に示唆した。
スクラムはそれをプロダクトオーナーや透明化という概念で明確に定義し、プロセスとして提示したことに意義があると思う。