オンサイト顧客が暗示したもの～プロダクトオーナーとアーキテクトの役割

最近のシステム開発のステークホルダーでは、ユーザと開発者、プロマネという役割だけでは足りない気がする。
キーワードは、XPのオンサイト顧客、Scrumのプロダクトオーナー、ソフトウェアプロダクトラインのアーキテクト。
考えたことをメモ書き。
間違っていたら後で直す。

【参考】
アジャイル実践者インタビュー（2） － ＠IT

【中級】反復開発　現場のノウハウ 第2回 - ITエンジニアのスキル向上ゼミナール：ITpro

マネジメントのスピードが開発のスピードに直結する: プログラマの思索

要件定義の疑問: プログラマの思索

アジャイルの基本原則と価値 (Jeff Sutherland 著)

【1】XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに巻き込んで、開発者がすぐに顧客に要件を確認したり、要件の取捨選択を即判断できるように、共に開発するスタイル。
この開発スタイルは特にパッケージ製品や組込製品のように、マーケット重視のソフトウェア開発ではより重要で、かつ威力を発揮するスタイルだと思う。

しかし、受託開発では、オンサイト顧客は実際はありえず、業務SEという名のメンバーが顧客と開発チームの間を取り持つ時が多い。
つまり、オンサイト顧客を開発チームのそばに置くことが出来ない場合、業務SEがユーザの要望をまとめてシステム要件に落として開発者に伝える役割を担う。
倉貫さんはこの手法を顧客プロキシと呼んでいた。
実際のプロジェクトでは、顧客プロキシと呼ばなくてもそのような役割を担うSEはブリッジSEとして、ユーザ企業へ頻繁に出張して、開発チームとのメッセンジャーになるため、とても負荷が高い。

ScrumがXPよりも優れている点の一つは、プロダクトオーナーと言う役割を明示化したことだと思う。
ユーザと開発チーム(プロマネ、開発者)の間でビジネス要件とシステム要件を結びつける前に、ビジネス要件をまとめて優先順位を付ける人がプロダクトオーナー。
プロダクトオーナーがまさに製品(システム)の機能を決定する権限を持つ。
プロダクトオーナーという役割をユーザ企業の担当者が意識していれば、システムのビジネス的価値を見極めてビジネス要件を作る。
ビジネス要件はまさに要求そのものであり、要求がはっきりしているからこそ、要件(システム要件)へ詳細化することが可能。
プロダクトオーナーがいなければ、ベンダーが作ったRFPをそのまま受け入れて、動かないシステムを作るだけに過ぎない。

多分、XPのオンサイト顧客という言葉で暗示した概念はプロダクトオーナーという言葉ではっきり具体化できると思う。

プロダクトオーナーという役割を認識した上で問題になるのは、プロダクトオーナーという役割を誰が担うのか、ということ。
本来ならばユーザ企業の情報システム部の人達がプロダクトオーナーになるべき。
しかし、開発チームとのやり取りを考えると、開発チームから業務SEを抽出して、その業務SEとユーザ企業の担当者がプロダクトオーナーのチームになるべきではないか、と思う。
そうでなければ、開発チームは要件の重要度や作業の優先度を身近にいるプロダクトオーナーに確認できない。
地理的な距離感が心理的な距離感になってしまうからだ。

【2】プロダクトオーナーとプロマネだけでなく、アーキテクトと言う役割の重要性を主張したのがSWプロダクトラインだと思う。
SWプロダクトラインでは、アーキテクトがユーザ・管理者・開発者の間でお互いの主張や意見を翻訳して調整する役割を担う。

デブサミ2011の鈴木雄介さんのなぜソフトウェアアーキテクトが必要なのか - デブサミ2011の講演でも、アーキテクトがプロマネとプロダクトオーナーの間を取り持つ、アーキテクトがいるからこそプロマネは仕事できる、と話されていた。

なぜソフトウェアアーキテクトが必要なのか - デブサミ2011 from yusuke suzuki

又、以前、SEA関西のSWプロダクトラインの講演でも、アーキテクトは設計する人ではなく調停者であると言う話を聞いて、なるほどを思った時がある。
だから鈴木雄介さんの講演内容はとてもストンと理解できた。

そのボタンを押したら何が起きるのですか？～アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索

実際のシステム開発における上流工程では、要求と要件の違い、要求から要件への詳細化がとても難しい。
結局WF型開発で設計を進めて、実際に作って動かしてみて、初めて要求を設計者が理解したり、要件とシステムのズレを開発チームが認識する時がとても多い。

だから、RUPのような上流工程を繰り返し開発するやり方では、業務SEがプロダクトオーナーかつアーキテクトの役割を持ってチームを組んで、システム全体を薄く設計しながら深堀していくやり方になるのだろうと思う。
そうしなければ、要件定義や外部設計という上流工程の作業を繰り返し開発するのは難しいだろう。

【3】特にクラウドを意識した最近のシステム開発では、アーキテクトの重要性が高まっているという事実もあると思う。
下記の記事を読むと分かりやすい。

新しい未来を見るその先のキャリアへ行く SEE,Go To シー、ゴー、トゥー コンサル記事

以前は、業務知識が強い業務SEがシステム開発のコアメンバーだった。
つまり、業務SEはプロダクトオーナーの役割を担っていたと言える。

しかし、開発経験が無い業務SEでは開発案件を回せなかったり、システムを作った後の運用保守が難しかったりする事例が多くなったという。
だから、業務知識だけでなく開発経験も持っていて、開発チームも回す能力のあるプロジェクトマネージャーのタイプがコアメンバーに代わった。
つまり、スクラムマスターという役割を持つ人が重要視されたと言える。

そして最近は、SNSなどのWebシステムのスケールアップがボトルネックになる時が多くなったので、DBサーバーやWebサーバーのスケールアップに強い人が要求されるようになったらしい。
つまり、この役割はアーキテクトそのものだ。

そういう時代の変遷を見ると、深い業務知識を持つプロダクトオーナー、実際に開発チームを回すことができるプロマネ、DBやサーバーのスケールアップなどのアーキテクチャ設計に強いアーキテクトという3つの役割をこなせる人が必要になってきたみたい。

しかし、実際の現場では、プロダクトオーナーとプロマネ、あるいはプロマネとアーキテクトの二つを兼任するぐらいしかできないだろうと思う。
小規模プロジェクトならまだしも、大規模プロジェクトで3つの役割を兼任していたら、負荷が高すぎてプロジェクトが回らない。
大規模プロジェクトになるほど、プロダクトオーナー・プロマネ・アーキテクトの役割を分化していくようになるのだろうと思う。

実際の開発現場で、プロダクトオーナー・プロマネ・アーキテクトの役割を誰が担っているのか？と言う観点でステークホルダー分析してみると面白かもしれない。
どれかの役割が欠落していたら、そのプロジェクトはどこかの時点でつまずいてしまう可能性が高いように思う。