和アジャイルの誰時 β2 2章 発注側 経営幹部の心得

2．　発注側　経営幹部の心得

まず発注側がアジャイル組織に変革すべし。　
アジャイル開発のメリットを享受するのは発注側の経営者である。
ソフトウェア開発の現実を知り、日米の格差を知って、
発注側経営者は組織価値観を変革し、制度を適合させ、
PO人材を育成し援護すべし。　

2.1 アジャイル開発は、あなたの望みを実現する手段

■ ソフトウェア開発の競争力を上げるためにアジャイル開発を採用・推進するという意思を表明してください。

　アジャイル開発を推進するために、最初に重要なのは、あなた自身の意思です。

• 情報システム（ソフトウェアサービス）の開発力が自社の競争力の源泉だと思っていますか？

• 米国企業や国内ベンチャー企業等のソフトウェア開発力を脅威に感じており、自社のソフトウェア開発力が低いことに危機感を持っていますか？

　これらに同意できるでしょうか？「Yes」であって、現在ウォーターフォール開発スタイルを採用しているのであれば、アジャイル開発スタイルに変革するべきでしょう。

■ あなた自身の危機感と覚悟を関係する組織の人々に伝え、あなたが変革をリードしていかなければいけません。

■ アジャイル開発においてソフトウェア製造の責任は、お金を出す発注側になります。

■ アジャイル開発の責任者はプロダクト・オーナ（PO）です。

　あなたはPOを育成し、援護しましょう。

　あなた自身の価値観（図2-1）は、以下のいずれでしょうか？

【価値観WF】
 情報システムは金で買うものだ。　誰が作っても良いし安い方が良い。

【価値観AG】
 情報システムは自社が主導しソフトウェア技術者の協力を得て作り上げるものだ。
 情報システムは市場の動向に合わせて継続して変更していくものだ。　

　アジャイル開発を推進するのであれば、 【価値観AG】 に同意できると思いますが、その場合、ソフトウェア製造の責任は自社側になることに注意が必要 です。きっと、この変化に対して、これまで 【価値観WF】 に慣れた組織や担当者からの抵抗があるでしょう。お金を払っておいて自社で製造の責任を負うのでは損をしていると思う人もいるでしょう。しかし、市場競争を含めた大局で見れば競争力の低いソフトウェアをお金と時間をかけて得ることの方が大きな無駄なのです。あなた自身の危機感と覚悟をそれらの組織の人々に伝え、説得し、再教育し、変革をリードしていかなければいけません。

　　　

　　　　図2-１ 社長（経営幹部）の価値観

2.2 組織をアジャイル開発に適合させる

　あなたがアジャイル開発の推進を表明した後、あなたの組織がアジャイル開発を実施できるようになるためには、あなたはいくつかの変革をリードしなければいけません。

■ 価値観が浸透するまで繰り返し提示しましょう。

　アジャイル開発が必要になる背景を、あなたの組織（発注側の関係組織）の人々が理解しなければいけません。

• 情報システムの開発が企業の競争力の源泉です。

• ライバル（米国企業や国内ベンチャー企業等）はアジャイル開発によってその競争力を実現しています。

• ソフトウェアは物買いではなく、自らが優秀な技術者の協力を得て作り上げるものにしなければ、競争力のある真に良いソフトウェアは完成しません。

• アジャイル開発ではソフトウェアの開発責任と仕様コントロール権は発注側にあります。
  　見積り責任も完成責任も発注側にあります。

　これらの現実、時代の変化に応じた価値観の変化を受け入れるには、おそらく抵抗もあるでしょう。あらゆる人に、あなたの意思と価値観を示すことで解決していかなければいけません。

■ 契約種別（準委任契約）を整備しましょう。

　アジャイル開発を発注する場合の契約種別は、請負開発契約では失敗します。準委任契約もしくは派遣契約にて実施すべきと開発組織および契約組織に宣言し、必要なら社内制度を整備しましょう。

• 抵抗例：　見積り競争が無いことで不安になる。
• 抵抗例：　準委任契約自体に抵抗感がある。お金を出して、発注側が責任を持つことに理解が示せない。
• 抵抗例：　未だにソフトウェア開発を建築とのアナロジーで捉えていて、時代の変化に着いていけない。

■ 契約人月単金の基準を見直し、優秀な人材を確保できるように柔軟性を持たせましょう。

　アジャイル開発では、できるだけモチベーションとスキルが高い技術者を確保し、コミュニケーション・コストを下げるために少数精鋭のチーム作りをするのが理想です。

　契約の人月単金を下げる交渉をすれば、技術者の質が下がります。スキルを正しく評価した適切な単金基準を用意しなければいけません。実際に働いてもらいスキル貢献度に応じて金額を調整していける仕組みが最も合理的です。

• 抵抗例：　人月単金を競争で下げることをしないので不安になる。
• 抵抗例：　人月単金の基準を作れないので判断できない。
• 抵抗例：　従来の慣習に従いたい。

■ POに与える責任に応じた権限を与えましょう。【権限・責任バランスの原則】

　アジャイル開発ではPOに開発完成責任が発生します。POには、その責任に見合った権限が与えられるように社内制度を整えましょう。責任だけ大きくて権限が無い開発では失敗は目に見えています。

• 抵抗例：　POの役職が低すぎるから重要な権限は与えられない。
• 抵抗例：　POがまだ若すぎるから重要な権限は与えられない。
• 抵抗例：　その権限をPOに与えると、上位職の役割(存在意味)が無くなるから与えられない。

2.3　PO人材を育成し、援護する

■ PO人材への期待は、一般的に言われるビジネスのリーダシップと同一です。

　PO人材への期待を表明して、POとして活躍できる人材を増やしていきましょう。では、PO人材への期待は何でしょうか？

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

　アジャイル開発の進め方は経営者のビジネス・スタイルに近いものになりますから、ある程度の情報処理スキルを持っていれば、後は、一般的に言われるビジネスのリーダシップの能力と同じになります。詳細は他書籍に譲りますが、たとえば以下のような期待があります。

• 視野が広く現実を見る力がある。（競合状況、ステークホルダ都合、サービスと市場動向、エンドユーザ心理、開発現場の実態と課題など）
• 費用対効果など、ビジネスセンスがあることも重要。
• バランスの良い判断ができる。優先度判断力があり的確。判断理由（ビジョン）を言えることが望ましい。
• 間違った場合にも素直に謝罪し、訂正できる力がある。
• 責任を完遂するために、考え続ける習慣がある。
• 良いソフトウェアを目指すモチベーションがある。
• 難題には自らが先頭で立ち向かう姿勢がある。
• 人格面で信頼されている。
• コミュニケーション力がある。
• メンバを育成する。

　自組織内にPOがいなければどうすれば良いでしょうか？自らの後継者候補をまずはPOにして育てていくことも一つの方法でしょう。

　情報処理スキルとビジネス・リーダシップのどちらか一方を選ぶのであれば、ビジネス・リーダシップを選び、適切な技術面のアドバイザを同伴させます。

　　　

　　　　図2-2 　POはバランスを維持する存在

■ POに対する古い価値観の組織からの抵抗に、あなたが援護しましょう。

　組織が、アジャイル開発に対応できるまでの間、POは組織の各所から様々な抵抗を受けることになります。

• 抵抗例：　新しい価値観とこれまでの社内規定との整合性が取れない。
• 抵抗例：　新しい仕組みを導入するには、これまでとは異なる法制度の適用を学び考えて、新たな規定を作らなければいけないので面倒である。
• 抵抗例：　そもそも新しいことが嫌である。前例がない。

　このような前例主義者や無思考主義者とPOを戦わせてはいけません。時間の無駄です。POは、社内の抵抗と戦うよりも、良いソフトウェア開発に集中してもらうべきです。 情報システムの開発が会社の競争力を左右するのであれば、それらの組織的課題をできるだけPOから切り離し、あなた自身が解消していかなければいけません。再び、あなた自身がその場に立って覚悟と価値観を伝えることからはじめましょう。

■ POの失敗に対する適切なセーフガードを用意しましょう。

　アジャイル開発ではソフトウェア開発の完成責任がPOにあります。そして、ソフトウェア開発は極めて複雑で難しい作業なので、失敗することもあります。一方、ウォーターフォール開発であれば、失敗の責任を受注会社に転嫁することができます。良いソフトウェア開発を作りたいと強く思わなければ、責任の重いアジャイル開発を避け、責任が軽く自分が楽できるウォーターフォール開発を選択することも非難できないでしょう。よって、アジャイル開発をPOが選択していくためには、アジャイル開発が上手く行かなかった場合でも、きちんと救済できる制度が必要なのです。

　ところで先にも述べましたが、POはビジネス・リーダと同様な判断を行います。つまり、ステークホルダの事情の変化、競合企業による新サービスリリースなどの影響をダイレクトに受けるでしょう。それらに起因するビジネス・リーダの方針変更を失敗と呼ぶのでしょうか？アジャイル開発でも一緒です。上手く進まない原因をきちんと分析し、サービスリリース時期の延伸や開発中止などの判断を適切に行わなければいけません。

• 失敗原因例：　ステークホルダの計画を前提に進めていたが、ステークホルダの方針が変わってしまった。予測不能だった。
• 失敗原因例：　競合企業が新たなサービスを開始し、現在開発しているシステムの価値が大きく低下しまった。予測不能だった。
• 失敗原因例：　開発システムの根幹となる技術の困難さが具体的に判明してきた。実際に試して判明した。試すまでわからないことだった。

■ POの失敗に対しては、即応することでリスクを削減しましょう。

　開発の途中で上記のような状況が判明したらその時点でウォーターフォール開発では難しい方針変更を、アジャイル開発では翌日からでもすることが可能なのです。もし、POからのそれらの悪い状況のエスカレーションが無く手遅れとなった場合には、そのPOはアジャイル開発の本当の進め方を理解していないか、社内の情報伝達に問題があった可能性があります。

　開発メンバからPOが信頼されなかった場合など、開発現場のリーダシップに関わる問題には、あなたが適切な救済をしていく必要があります。

■ 「アジャイル開発をやりたい」、と提案してきた担当者を活かしましょう。

　あなたの会社の若手の担当者がアジャイル開発を実施したいと提案してきたとき、あなたはどうすべきでしょうか？若手で情報処理スキルの高い人材にとって、アジャイル開発は普通のソフトウェア開発になっています。大学時代の同期は、他社でアジャイル開発を推進して成果をあげているかもしれません。あなたの会社がまだアジャイル開発を主流にできておらず、先に述べたあなたの覚悟と価値観があるのであれば、そのチャンスを活かして、人材を伸ばし、組織を変革していきましょう。しかし、あなたがアジャイル開発に魅力を感じないのであれば、その人材があなたの会社の将来性を見限ったとしても、その判断は受け入れてあげましょう。どちらがガラパゴスだったのかは時代が決めてくれるはずです。

■ 「アジャイル開発をやりたくない」、と相談してくるPOや担当者もいます。

　アジャイル開発は、ウォーターフォール開発に比べて発注側の組織とPOに大きな負担を求め、責任を負わせます。新しい事もたくさん学ばないといけません。自ら、全体の状況を捉え、都度、最善を考え、責任をもって優先度を判断し続けなければいけません。開発者とはコミュニケーションを丁寧に行って高いモチベーションを維持して開発を続けてもらわなければいけません。発注側の担当者も発注先の開発担当者と対等に議論し開発を進めていかなければいけません。さらに、・・・

　これらが耐えられないと申告するPOや担当者が出たらどうすれば良いでしょうか？ウォーターフォール開発スタイルで実現できていた発注側が楽できるスタイル、決まった作法を繰り返すだけでそれっぽく進められた経験から抜け出すことができない担当者もいるかもしれません。ウォーターフォール開発は全て消える訳ではないでしょう。あなたは適材適所と育成のバランスを考えなければいけません。

2.4 アジャイル開発の不都合を理解する

■ アジャイル開発では動作するソフトウェアが早い段階で見えてきます。しかし、それが商用リリースできるまでには、もっともっと時間がかかります。

　ウォーターフォール開発で納品されたソフトウェアは一定の品質基準を満足していることでしょう。しかし、アジャイル開発では、品質確保より前にPoC（Proof of Concept,概念実証版)としてリリースされ、使い勝手などの検証や試用を実施することになるでしょう。それらのフィードバックを受けながら、その後に品質を高める作業を実施していくことになります。よって、「動いた」と、「商用適用可能」の間には時期的な大きな時間差があります。動いたのを見て、「すぐサービスを開始しろ！」と、間違った指示をしてはいけません。誤解しないように注意しましょう。

■ ウォーターフォール開発の方が適したケースもあります。

　全ての場合にアジャイル開発が向いているとは限りません。案件のタイプがアジャイル開発に合っているか？は考える必要があります。

◆ アジャイル開発価値より他の価値が重要な場合：

• 経営幹部としてアジャイル開発に魅力を感じない場合。
• 他社と競争する必要が無い場合。
• 要求仕様が固まっていて、誰でもいいから安く作ってほしい場合。
• 人命や重要社会基盤であって、早いサービス開始よりも高品質の保障が求められる場合。

◆ 他社に開発保障を求めたい場合　（ただし受注会社が存在する前提）：

• とりあえず予算内・期間内で完成することが重要である場合。
• 自らの完成責任を回避したい場合。
• 金でリスクを回避したい場合。

◆ 準備不足：

• 自社の価値観をアジャイル開発適合に変えることができない場合。
• 開発責任を委ねられるPO人材がいないし、育成もできない場合。

◆ コミュニケーションが上手く行かない場合 （コミュニケーション・ロスが大きく、ドキュメントベースが効率的な場合）：

• ソフトウェア開発規模が大きくチームが10人を超える場合。（適切なチーム分割で回避するケースあり）
• オフショア開発や自社への持ち帰り開発など、別ロケで開発しなければならない場合。（適切なツール使用で回避するケースあり）

■ そもそも「何を作るか」が決まっていない場合には、どんな開発スタイルを採用しても開発は成功しません。

　最終的に、作りたいソフトウェア（ゴールイメージ）が決まっていなければ、開発は失敗します。製造請負契約であれば、たとえ見積り仕様がパワポ１枚であってもその失敗責任は（その仕様で見積りを出した）受注者が負いますが、アジャイル開発の場合には自社で負うことになります。失敗に対して、短絡的に「アジャイル開発は駄目だ」、「ウォーターフォール開発に回帰せよ」と指示する前に、失敗の原因をきちんと分析してください。情報はPOからも集めますが、全ての情報が得られない場合もあります。あなたの情報収集能力と反省も問われるかもしれません。まずは、あなたゴールイメージの具体化に対して、あなた自身がPOにどう協力できていたのかを考えるのも一つの原因追求アプローチです。きれいなPowerPoint資料だけで、上手く動作するソフトウェアは作れません。

2022.5.7 改版に向けて修正中