3．　発注側　POの心得

3.1 プロダクトオーナ(PO)の責任と権限を理解し納得する

■ ウォーターフォール開発は、発注者が「受身」でも一応完成します。

　従来のウォーターフォール開発のほとんどは製造請負契約とセットです。あなたが発注仕様書を漏れなく書くことができて、かつ、予算内・期限内で受注してくれる会社が見つかり製造請負開発契約を結べれば、あなたの勝ちです。後はあなたが不在であっても、納期には仕様を（最低限度に）満たす納品物が得られます。仕様が十分に書かれていれば、満足できるソフトウェアの可能性だってあります。仕様解釈のズレの発生を避けるために、丁寧なレビューを実施することはあるとしても、あなたは常に受身で構いませんでした。開発会社から提出された進捗報告を眺め、予定と実績の乖離確認を行い、もし遅延していれば遅延回復策を提案してもらって吟味することだけだったかもしれません。

　　　　図3-1　POはアジャイル開発の中心にいる

■ アジャイル開発はPOが「主体的」でなければ完成しません。

　一方、アジャイル開発では、図3-1のようにPOが中心に位置します。あなたが仕様も実装も 積極的に指揮 していくことになります。それを可能にするために製造請負契約ではなく準委任契約を締結しているのです。あなたの期待に近いものが作れるように指揮できる代償として、発注側のあなたがソフトウェアを完成させる責任を負うのです。あなたの判断が失敗すれば、ソフトウェアは完成しないかもしれません。

■ POがソフトウェア完成の責任を負うことを納得しなければいけません。

　ソフトウェアを完成させる責任は、明確なゴールイメージがあり、話のわかるステークホルダが相手で、質の高い開発メンバを集め、良いチームを作り、適切な期間をかければ、それほど困難ではないかもしれません。しかし、ゴールがはっきりせず、ステークホルダが信頼できず、頭数だけのメンバを集めて、短い納期に間に合わせる開発だったら、誰がやっても失敗するでしょう。POになる前に、成功のための条件をどの程度満たしているか、現在満たされていない条件をどうやって満たしていくか、を責任者の視点で考えるべきでしょう。そして経営幹部に不足する条件を満たすための支援を要求しなければいけません。もし、あなたの価値観がリスクと責任を回避することを優先するなら、POを受諾しない、もしくはアジャイル開発を採用しないのが懸命だと思われます。また、以下の迷いが先行して主体的に行動できない場合にも辞退すべきかもしれません。

タイムリーにステークホルダと調整して優先順位を決めることは面倒なので避けたい。
現場の悩みに付き合って、都度、方針や優先順位について判断していくのは面倒なので避けたい。
たくさんのレビュー依頼を裁くなど、知力・体力に限界を感じる。
あなた自身が開発するもののゴールに納得できない。
開発するものが全くイメージできない。何を開発すればいいのかわからない。

■ 責任の大きさに伴う権限が与えられていない場合、POになるのを止めておきましょう。

　ステークホルダとの調整の実効的な権限や、納品物を検収する実効的な権限などを、自ら持っていることが重要です。権限自体を持っていなくても、権限を持った上司との連携作業で進められるなら大丈夫かもしれません。しかし、たとえば全くステークホルダと調整する権限が無い担当者がPOになる場合には、失敗するリスクは非常に高くなるでしょう。検収権限がない場合には、自らの判断の前に都度、その検収権限者と調整しなければ、責任ある判断ができないでしょう。POになる前に経営幹部に必要な権限は要求するべきです。

■ POはアジャイル開発のSPoFです。

　自らの健康を維持しましょう。POはアジャイル開発の中心です。POが不在になればアジャイル開発が停止するリスクがある SPoF (Single Point of Failure, 単一故障点) です。健康維持には十分注意しなければいけません。

■ 複数名がPOチームを構成することも可能です。ただし、簡単ではありません。

　POが1名だけの体制にはプロジェクトの可用性（継続性）として問題があります。そこで2～3名でPOがチームを組むことが考えられます。しかし、容易ではありません。

　このとき注意すべきは、各PO間での情報のズレ、判断のズレを最小にすることです。複数の船頭が発生すると逆にアジャイル開発は混乱してしまいます。開発メンバにも主体性が生まれなくなります。POチームとして判断基準と優先順位を合わせ、開発メンバから信頼されるようにならなければいけません。

3.2 発注側幹部がアジャイル開発の価値観に納得していない時

　1章で述べたように、アジャイル開発は発注側幹部の意思から始まるのが正しいスタイルです。しかし、不幸にも逆順となることが良くあるでしょう。なぜ、逆順になるのでしょうか。

■ PO自身がアジャイル開発を実施したいと望むのは、開発のスピードアップやコスト低減を求めたときです。

　PO自身がアジャイル開発を望むときとは、どんな時でしょうか？一つは、情報処理スキルが高い人材がアジャイル開発を体験し、そのスピード感が忘れられないときではないでしょうか。もう一つは、ウォーターフォール開発の変更対応の弱さやスピード感の無さ、納品物の費用対効果の悪さ等に失望したときかもしれません。ウォーターフォール開発では受注側が全てのリスクを負うため、見積額はリスク料金を含んだ高いもの、開発期間もリスクを見た長い期間になります。また、当初の仕様で十分語りきれなかった点があると、納品されたソフトウェアと期待とのズレが非常に大きくなるケースもあるのです。自分でチームを作って自ら指揮して作った方が、安く良いものが作れると思うことがアジャイル開発を実施したいと思う強い動機となるでしょう。そのほか、競合社の進め方を知った時ということもあるかもしれません。

■ 社外と競争する必要がない組織であれば、組織の幹部がアジャイル開発のメリットを求めません。

　アジャイル開発の変化への対応のメリットは、インターネット上のサービスで競争するような企業が最大限に享受します。
　しかし、世の中には異なる価値観の組織も多くあります。
　年度内に与えられた予算の中で、確実に買う、ことが重要な場合だってあるはずです。
　そんな組織にアジャイル開発はそもそも適合しません。

■ 社外と競争し情報システムが競争力の源泉となる企業なら、幹部にアジャイル開発という技の知恵を授けましょう。

　システム開発の競争力が上がること、それは幹部にとっても企業の競争力を左右する重要な情報のはずです。幹部がもしアジャイル開発を知らないのであればその手法の情報を提供すべきです。さらに、深く理解してもらい、制度の整備等も合わせて進める権限も含めて理解を得ていきましょう。

■ 企業の幹部が価値を理解できなかったら、競合他社の成功を示して、気づきを待ちましょう。

　インターネット市場でサービス競争する会社の幹部に、競争力を向上させる手法がもし魅力的に響かないのであれば、その会社は真の競争をしていないのかもしれません。もしくは幹部にはもっと優先する他の価値観があるのかもしれません。そんな中で、あなただけが完成責任というリスクを負うか否かは、あなたの自身の判断です。少なくとも、最初から大きなアジャイル開発を実施することは避け、小さな成功を積み重ねて実績を積んでいきましょう。また、契約としては派遣契約を使って技術者を集め、内製するのがわかりやすいでしょう。結果として、類似の他のウォーターフォール開発と比べると良いものが作れるでしょうし、その差をアピールしていくことも良いでしょう。また、競合企業等がアジャイル開発で成功している事例については情報として伝えて行きましょう。あとは、使命感を持って企業を変える努力をするもよし、もっと力を発揮できる環境を探すもよし。幸運を祈るだけです。

3.3 ゴールに対して、価値のある部分をまず動かして全体の目処をつける

■ ゴールを決めるのはPOの責任です。

　アジャイル開発では、開発メンバにゴールを理解してもらって協力してもらわなければいけません。万が一、ゴールをPOが正しく理解できていないのであれば、安易に開発をはじめてはいけません。ゴールを明確にするためには、プログラム開発以外にもっと重要なことがあるかもしれません。一旦、開発が動き始めてしまうと、それだけで周囲を安心させてしまうかもしれません。手段を目的化しては駄目です。何かやっている感じの演出も駄目です。開発の前にゴールを明確化する調査などの営みをしっかり実施しましょう。

■ ゴールまでの計画を見積る責任も、発注側のPOです。

　　アジャイル開発で、ゴールを決め、ゴールに向けての全体スケジュールを計画し、それに必要な体制規模と期間を決めるのもPOです。当然、ウォーターフォール開発と同様に精度高く短時間で見積る方法は存在しません。アジャイル開発において、期間も体制も見積れないのに完成責任を果たす最大の手法は、重要な部分の解決を小さく実施して目処をつけることを最優先する、ということです。解決すべき重要な部分とは例えば以下のようなものです。

プログラムの主要機能の実現方法の目処がついていない。
期待される性能を満足できるか見通しが全く無い。
プログラムの核として利用するパッケージ・ソフトウェア／クラウド機能／OSS（Open Source Software）の理解が十分ではない。
他システムとの連携方法の理解が十分ではない。
期待するユーザインタフェースの実現方法の目処が立っていない。
プログラムの中心となるアルゴリズムの目処が立っていない。
プログラムのアーキテクチャが決まっていない。

　解決すべき重要な部分の見通しが不明な時点で、それを解決せずに見積っても度胸（KKD法のD）で見積ったとしか言いようがありません。最初にその部分の解決に目処をつけましょう。そして、その結果を受けて見積りの精度が向上するかを、チームの皆と議論してみましょう。次に重要な部分があって、そこを解決しなければやはり全体の達成が不透明かもしれません。そのときは、そこを解決していきましょう。重要な部分が明確でない場合には、中核となる機能を短期間で簡易に試作してみましょう。それによって、どこに難しさがあるのかが見えてくるはずです。いくつかの重要な部分について解決の目処が付くと、後はそれらの経験とこれまでのチームメンバの経験を合わせて見積りができるタイミングがいつか訪れるでしょう。そこに、残るリスクに見合った期間を足せば、やっと皆が納得できる見積り計画の完成となります。見積った計画を実行していく中で新たな課題が出てきたら、計画は素早く見直しましょう。

■ 基本設計を模索するための初期プログラムコードは、無理に残さないことを原則としましょう。

　基本設計を明確にするために、一旦、動作するものを組み上げてみることをすることは、ドキュメントを眺め続けて設計の精度を上げるよりも効率的なものになります。

　しかし、注意点があります。基本設計を決める際に作ったプログラムコードは再利用可能でしょうか？使える場合もありますが、無理に使わず捨てるものだと思いましょう。もったいない病、ライン単金病、手段目的化病等に負けてはいけません。現代のシステム開発では、プログラムコードよりも良い設計の方が圧倒的に価値が高いのです。優先度判断ができない姿勢、熟慮せずに二兎を追う姿勢は避けましょう。同様に、基本設計を試行錯誤するプログラムコードにUTを何も考えずに実施する等のバランスの悪さも避けなければいけません。

■ 未確定部分があれば、課題を分離して、仮置きして全体を進めることが重要です。

　アルゴリズムや詳細方式が決まっていない部分があれば、その部分に対して簡素で交換可能なインタフェースを用意して、一旦、最も単純・原始的なアルゴリズム・詳細方式を使うことにして、全体を進めましょう。全体を通すことで、さらに重要な問題が無いかを探っていきましょう。

3.4 動いたら、ステークホルダに見せ、アジャイル開発の価値を活かす

■ 重要な部分が動き始めたら、開発スケジュールを心配する経営幹部やステークホルダに見せましょう。

　重要な部分の見通しが付いて、一発動くシステムにできたら、開発スケジュールを心配する人々にも見せていきましょう。それによってプロジェクトは一旦、計画安定状態 に入ることができます。万が一、ここで当初のプロジェクトの想定期間内に終了しないとわかったとしても、重要な部分については動作したことを示し、残り期間の見積りも度胸だけではないことが示せれば、後は純粋な追加投資対効果の判断だけになります。少し遅れ気味であっても、重要な部分が動くシステムを関係者に見せることによって、皆が現実的なスケジュール感について理解してくれるでしょう。

■ サービスのゴールを決める人々に、早く使ってもらって、大きな意識ズレがないか確認していきましょう。

　この営みがアジャイル開発で最も重要です。アジャイル開発では、動くものを早く見せて／使ってもらって、意識ズレ・解釈ミス等を早期に検出し、対処していくこと（図3-2）が極めて大切です。ウォーターフォール開発との本質的な違いはココにあります。この動作するシステムを見て触ることを通した、エンドユーザ側との早期のそして細やかな仕様あわせが、システムの完成度と満足度を圧倒的に高めていきます。ドキュメントベースの対話かつ初期に一度決めことを守り続ける硬い進め方で製造されたシステムでは決して得られない効果があります。

【WFの仕様あわせ方法】
サービス企画者、サービス発注者、受注側システム開発者が、
ドキュメントを詳細化（要求仕様⇒基本設計⇒詳細設計）しつつ
納品物イメージを合意し、
開発し、完成したシステムを納入直前に使ってもらって、
軽微な修正を実施して、納品する。

【AGの仕様あわせ方法】
サービス企画者・開発責任者（PO）が、
サービス像やユースケースもとにシステムのゴールイメージを開発者に伝え、
早期にその開発イメージのプロトタイプを作成し、
サービス企画者・開発責任者（PO）に見せて使ってもらう。
それらを繰り返し、徐々に期待のものに近づけて、品質も含めて納得した時点で、
エンドユーザによる試用に進み、市場ニーズにあったシステムに育てていく。

　　　　図3-2　ウォーターフォール開発とアジャイル開発のステップ比較　（※ 縦軸・横軸が各図で異なる点に注意）

3.5 その後も「動くものを作る」を忘れずに、改善のサイクルを回す

■ 重要なものから先に実施することをスパイラル開発でも忘れないようにしましょう。

　ステークホルダからの要望も含めて、重要なところから順に改良し拡張していく スパイラル開発 を進めましょう。ステークホルダの要望は全て直ぐに反映するというのではなく、あくまでも重要なものを優先度に従って解決しましょう。
　次回の改善版はどのタイミングで、どこまで改善し、どう見せるか、についてもPOが悩むべきポイントです。リリース予定日とソフトウェアの完成度のバランスを見つつ開発を進めていきましょう。やりすぎると重複するコメントだけが集まってコメント対応に忙殺され、開発が全く進まなくなるケースもあるので注意が必要 です。

■ アジャイル開発とは、動作するプログラムによるコミュニケーションへの変化です。

　アジャイル開発では、「コミュニケーション」が変化します。図3-3にウォーターフォール開発とアジャイル開発でのコミュニケーションの違いを示しました。ドキュメントによって意思疎通をはかり開発を進めたウォーターフォール開発に比べ、アジャイル開発では動作するプログラムを使って意思疎通をはかります。

　　　　図3-3　ウォーターフォール開発とアジャイル開発のコミュニケーション比較

　ドキュメントが不要だという極論は困ります。相談や議論をするのにFace to Face（F2F）が大切です。一方、以下のようなケースのためのドキュメント作成と整備は大切です。

翌日への作業チケットの引継ぎ。（明日、事故であなたが入院するかもしれません）
新しく参入するメンバや将来の機能拡張と維持管理メンバへの引継ぎ。（APIやテストに関するドキュメントなど）

3.6 期待されるのは普通のビジネス・リーダシップ

　POは、ウォーターフォール開発の発注者よりは苦労することになります。しかし、あなたに求められている 「優先度の高いところから先に実施する」 というこの進め方は、情報処理分野に限ったものではなく、現代のビジネス・リーダに求められている普通の考え方です。情報処理技術の理解とビジネス・リーダシップの発揮がPOの役割です。

【アジャイル開発のPO人材】　
 PO能力　＝　ビジネス・リーダシップ　＋　情報処理スキル

　逆に言えば、決められない、伝わらない、信頼できない等、リーダシップに欠けるPOの元でのアジャイル開発は失敗してしまいます。

　なお、リーダシップ論の中には、古典的軍隊をモデルとしたものも存在しますが、それはアジャイル開発で求められるリーダシップではありません。現代では、軍隊さえ現場の主体的な判断を求めるスタイルに変わりつつあります。アジャイル開発必要なのは、共通のゴールに向けてチームメンバに主体性を発揮させることを目指すリーダシップです。（巻末の補足5）

3.7 ウォーターフォール思考・姿勢の注意点

■ 請負開発における発注者経験に基づく姿勢と判断は、アジャイル開発を失敗させる方向に誘導します。

　ウォーターフォール開発であってもアジャイル開発であっても、発注者側が相応の努力をしなければ、期待する良いソフトウェアを作り上げることは難しい作業です。しかし、ウォーターフォール開発の場合には、完成と納品は受注側責任です。発注側はお金を出して買うという姿勢が強く出ると、「予定と実績の乖離確認を行い、もし遅延していれば遅延回復策を提案してもらって吟味する」という単純作業 だけで、ソフトウェア開発を指揮する気分を味わうことも可能でした。万が一、あなたがその世界からアジャイル開発の世界に変わるのであれば、大きな違いを感じるはずです。たとえば、以下を注意しなければいけません。

あなた自身が計画を見積っていますか？
開発メンバ一人ひとりのモチベーションを考えていますか？
Win-Winを志向し、対等なコミュニケーションをしていますか？
ドキュメント完成の前にFace to Face（F2F）で相談していますか？

　ウォーターフォール開発であっても、優秀な発注者はそれなりに実施をしています。しかし、俺様は発注側という姿勢がにじみ出て行くと、成果物としてソフトウェアは劣化していきます。ウォーターフォール開発に慣れた人は、契約種別の違いから来る進め方の違いを再度、理解しましょう。製造請負契約ではありません。極論すれば派遣社員を使った内製開発に近いものだと思うことです。（※ただし、準委任契約と派遣契約の違いにも注意してください。巻末の補足4）

■ アジャイル開発では、工程計画が必要な場合にはPOが責任をもつことになります。

　工程計画の作成責任はPOにあります。もちろん、現場メンバに相談し、進捗状況や今後の見通しを聞くことは可能です。しかし、POであれば、現場の状況とメンバを丁寧に観測して自らのチームの生産性の認識を持つ必要があります。さらに、今後、あなた自身が現場に対してどれくらいの指示（変更）をしていくかを予想して、全体の計画を見積る必要があります。アジャイル開発において現場の開発メンバが今後のあなたの判断、およびその背後にいるステークホルダからの要望等を予測するのは困難です。間違っても、「計画を出せ！」、「出した計画通り進めろ！」といった指示は止めましょう。アジャイル開発では受注側が開発計画をコントロールすることは本質的に無理なのです。たとえ、それが穏やかな言い方であっても伝わるものです。あなた自身がソフトウェア開発を推進し完成させる責任を理解し、計画して、仲間に手伝ってもらいながら成功を目指すという姿勢を示す必要があるのです。

■ 発注先の開発メンバを、仲間だと思って、対等に接しましょう。仲間の積極的な協力があってこそ、ソフトウェアは完成するのです。

　１章で示したソフトウェア開発の現実【優良ソフトウェア開発原理】を理解しましょう。担当者一人ひとりをできるだけ理解し、対等な姿勢でコミュニケーションの質を高め、モチベーションの低下が発生しないように常に配慮しましょう。

■ ウォーターフォール開発では重要だった作法・形式よりも、実態に応じた都度の優先順位の調整が重要になります。

　ドキュメント化してレビューという作法の前に、まずは関係者で集まってF2Fで議論するという姿勢の方が重要です。無駄なドキュメントの作成は避けるべきです。しかし、試験や維持管理等を考えて作るべきドキュメントもあります。全てのドキュメントを否定することはありません。取捨選択が重要です。ドキュメントの代わりに自動リグレッション・テストの整備を考えるべき時もあります。

3.8 コミュニケーションは大切、・・・相談を中心にする

　アジャイル開発スタイルにおいて、コミュニケーションは極めて大切なので、その詳細は次章に改めて示します。しかし、その前提として重要なポイントがあります。

■ 派遣契約では、POが派遣社員に直接作業指示を行うことができます。

　しかし、・・・

■ 準委任契約（および製造請負契約）でPOは受注側開発メンバに直接作業指示をしてはいけません。

　　必ず、受注側の作業管理責任者を通じて作業指示を行うことになります。どうすれば良いでしょうか。良質なPOによるアジャイル開発で、上から目線の指示が発生することはありません。双方からの相談がコミュニケーションの中心スタイルとなります。相談については制限はありませんので、十分に相談した後に、作業管理責任者と合意し作業指示としていきましょう。たとえば、チケット管理システムにおける優先順位をもとに作業を割り当てていく進め方、チケット目標期限を必達期限とはしない進め方（＝実態を優先する進め方）、などについても作業管理責任者と相談し合意していきましょう。いずれにしても、POとして信頼され、良質な関係があり、皆のモチベーションが高く維持できている場合に有効な進め方になります。（巻末の補足4参照）

2022.5.7 改版に向けて修正中