双方の義務と権利
山田は、スクラムマスターとして、すでに大小数多くの現場を渡り歩いてきたという。
「アジャイル開発におけるプロジェクトマネジメントのあり方は、従来方式と大きく異なります。プロジェクトマネージャーの役割は、これまでのように指示・指導する役割ではありません。現場が目標に向かう助けをすることです」
前田は素早くメモを取っていた。佐々木と加藤はじっと耳を傾けている。
「イメージとしては、現場の設計者・プログラマーに奉仕する姿です。プロジェクトの主役は誰かというと、ビジネスの担い手である業務現場の人間です。彼ら、彼女らをサポートするのがプロジェクトマネージャーです。組織の中には人と人の間の上下関係がつきものです。こうした組織内におけるバランスの偏り、バイアスが多くの場合、ネガティブに作用します。これを除去することが重要です。そこで、プロジェクトマネージャーが上役と対等な関係を構築したり、現場の主役に余計な干渉が入ることを除去したりすること、役割として担います」
「具体的にはどうすればいいのですか？」と佐々木が尋ねると、
「仕事を依頼する発注者と、情報システムを開発する構築者の役割を明確にします」
「ただ、前回のプロジェクトでも、発注者は業務部門の人間で、彼ら、彼女らが要求を語り、構築者が実装を行う、という役割分担はある程度、明確だったように思います」
「それでは、今回のプロジェクトでは、さらにそこへ、双方の権利と義務を明文化していきましょう。佐々木さん、発注者の義務とは何だと思いますか？」
佐々木は、娘や遠藤との会話を思い出しつつ、考えた。
「要求を明確にし、可視化することですか？」
「その通りです。では次に、前田さんに伺います。発注者の権利とはなんだと思いますか？」
「うーん、正直わかりません」
山田は続けた。
「発注者の権利とは、要求をいつでも変更することができる、というものです。アジャイル開発では、要求の変更はいついかなる時でも受け入れます。変化を味方につける。それがアジャイルの精神なんです」
話を聞いていた加藤が質問した。
「山田さんの仰ることは、理屈としてはわかります。でも、発注者側の要求が間断なく生じて、事態が収拾しなくなってしまうのではないかと心配です」
佐々木も続けた。
「前回のプロジェクトでも、『仕様確定』して、契約押印（サインオフ）しました。ただ、それが業務部門から反故にされ、細かな業務機能の要求が絶えず噴き出しました。もはや、情報システム課では、抑え切れませんでした」
「佐々木さんだけの責任ではありません。私たち日比谷ソフトウェアも、適切にサポートできていませんでした」と、前田は付け加えた。
山田は、指摘した。
「つまり、状況の変化をコントロールすることができなかったんですね。アジャイルではそうした状況をコントロールするために、受注側または構築者も、発注者の権利に対する強いカードを持っています。それは、納期を決める権利を構築者が有する、ということです」
前田は、なるほどと思った。
「仕様変更の要求がいくらあっても、納期は構築者側が決められるわけですね」
「そうです。これは、とても自然なことなのです。何かを依頼する人間がいて、それを実現する側がいるとします。依頼内容に応じて、実現する側が納期を決める。これはいかなる取引においても認められるべき基本的な考え方です」
加藤は、眉間にしわを寄せながら呟いた。
「ただ、今までSIを長年やってきた経験でいうと、納期をこちらで決定することは力関係から見て難しかったんですが。そんなにうまく行くものでしょうか」
山田は、加藤を見た。
「それは、小口化しているからできることなんです。アジャイルで重要なのが小口化だということは、皆さん、もうご存知のようですね」。３人は頷いた。
「従来のウォーターフォール方式では、要件定義で半年、基本設計3カ月・・・というようなペース配分で行われてきたはずです。そして、プロジェクトの終了は、2年後とか。このやり方では、途中で仕様変更の要望が生じてもあらかじめ決められた納期を簡単に調整することはできません。たとえ、わずかな仕様変更でも、です。止むを得ず、その変更を吸収するべくベンダー側が無理して頑張るか、その要望をユーザー側が諦めるかのどちらかしか選択肢はありませんでした。これでは結果として、双方が満足するプロダクトは生まれません」と山田は言った。
「それに対してアジャイルでは、小口化したストーリーを、1カ月というスプリントの中で実施するので、開発する対象も小さく、時間も短いのでコントロールすることができる、というわけですね」と前田は身を乗り出した。
「そうです。もちろんスプリントに入るための両者の間での事前準備の期間は必要です。その準備を行った上で、１カ月というスプリントの期間中は、仕様変更の要求があってもいいのです。その要求に対して、納期を決める権利を持つ構築者側は『その機能を盛り込むとスプリント内にスケジュールが収まらない』と主張することができます。そこで発注者側が検討し、『当初予定していた機能を取り下げるので、追加したい当該機能を優先してほしい』と自らの権利を行使しつつ、両者がさらに交渉を進めるというやり方なのです」
「この場合、取り下げられた当初の機能はどこに行くのですか」と加藤が尋ねた。
「バックログに戻ります。バックログは、ストーリーの入れ物です。開発単位であるストーリーに優先順位をつけ、リスト化した器です。バックログに記載されたストーリーのうち優先順位の低いものは、次のスプリントで実施してもいいですし、もっと後で実施しても差し支えありません。あくまでバックログは優先順位に従って処理されます。こうすると常に優先順位の高いものが初めに出来上がるというわけです」
「優先順位は常に見直されるわけか」と、佐々木は顎を手でさすりながら言った。
「その通りです、佐々木さん。発注者の持つもう一つの義務が、まさにそれです。優先順位を付けること」と山田は答えた。
「一度、ここまでの話をまとめましょう。発注者の義務は、要件を語ること・優先順位を付けることです。権利は要求を変更することです。一方、構築者側の義務は、要求通りに作り上げること。権利は納期を決めること。このようなスキームの中で、アジャイル開発は変化を味方につけるんです」。
前田は得心したというように言った。
「これで発注者側と構築者側が対等な関係になるわけですね」
「そのとおりです。世の中、概して発注者側の立場が上だったり、お金を出す側だったりして、強い力を有していることが多いですね。そのような上意下達の関係で仕事を受けると、支配者と奴隷のような関係になってしまいます。対等なパートナシップを実現するために、アジャイル開発ではこのような権利と義務を規定しているのです」
「この権利と義務のスキームを徹底し、対等なパートナシップを実現する。これがサーヴァント・リーダーシップのひとつなんですね」と佐々木はしみじみと言った。
