和アジャイルの誰時 β2 1章 日本におけるアジャイル開発

1．　日本におけるアジャイル開発

1.1 アジャイル開発を、誰が、なぜ、求めるのか？

■ アジャイル開発は発注側の経営幹部が望むソフトウェア開発の競争力を実現します。

　ソフトウェア開発発注側の経営幹部は、情報システム（ソフトウェア開発力）を企業競争力の源泉と思っているでしょうか？ そうであれば、その競争力実現のためアジャイル開発の採用を決定するのは間違いないでしょう。それによって得られるものは、米国企業や国内ベンチャー系企業に対抗できる競争力（開発スピードと変化対応力）です。この競争力をウォーターフォール開発で得ることは困難です。

■ アジャイル開発の開発スピードや変化対応力よりも、開発リスク低減を重視する非競争組織の経営幹部もいます。

　一方、ソフトウェア開発発注側の経営幹部に 市場競争力の向上という価値観 が無い場合や、幹部が発注側の開発リスクを低減することの方が重要だと考える場合には、アジャイル開発の提供する価値は無意味です。これは例えば、公的機関や共通事務部門の一部に見られるかもしれません。

■ 「優先度の高いところから開発し、動くものを作ってユーザの反応を得て改善を続けていく」 という開発スタイルは、経営幹部にとっては普通のビジネス・スタイルと一緒です。

【アジャイル開発の核心】　
１．優先度の高いところから対応し開発していく。
２．動くものを作ってユーザの反応を得て改善を続ける。
３．改善したものも都度、動作する状態を維持する。

■ アジャイル開発では、ソフトウェアは「金で買う」から、「チームで一緒に作って育てる」ものになります。

　インターネット上でグローバルに競争する時代の経営幹部は、当初の計画のまま １年間進めきることなど、考えもしないでしょう。目指すべきゴールに対して、計画はもちつつも、常にライバルや市場の状況を見て、都度、計画を見直し重要度の高いものから手を打ち、市場の反応を見てまた素早く軌道修正をするという進め方をしているはずです。アジャイル開発とは、極論すれば、そのビジネス・スタイルをソフトウェア開発でも実践することです。そのとき、ソフトウェア開発は、単なる「金で買う」ことから、「チームで一緒に作って育てる」ことに変革している に違いありません。駄目ソフトウェアを、時間をかけて安く買っても無駄なのです。素早い変化対応力が大切です。そこにこそ高い価値があるのです。市場の反応を理解してソフトウェア開発の優先度を見直し開発をリードする発注側のキーマンを、プロダクト・オーナ（PO） とアジャイル開発では呼びます。

1.2 皆が認めるべき、ソフトウェア開発の現実

　ソフトウェア開発は工学的に未熟な状態にあります。その中で良いソフトウェアを作るために理解し認めなければならない幾つかの現実があります。

■ ソフトウェアを混乱少なく開発するには、作りたいソフトウェア（ゴール）の明確化が必要です。

【現実1】
 創り出したいソフトウェアの具体的なゴールイメージ（要求仕様）が決まらなければ、
どんな開発手法を使っても期待するソフトウェアは作れません。　

　発注側は、まずはゴールイメージをできるだけ具体化すべきです。具体化しなければ開発者に伝えることさえできません。ゴールイメージを作るまでは開発を開始しないことが懸命です。その場合には開発の前に、検討する期間を設けましょう。

　アジャイル開発ではゴールイメージが決まり開発を開始した後に、外的要因によってゴールイメージが変化することについて、積極的に許容します。しかし、それはゴールイメージが無いまま開発を進めることとは異なります。

【現実1-a】
 ゴールイメージや仕様の途中変更を行えば、開発に必要な期間は延びていきます。　

　ウォーターフォール開発における仕様変更よりはアジャイル開発の方が短期間で対応できることでしょう。ただし、納期が固定で延伸できない場合には、追加した開発作業量以上の作業量をどこかで削らなければソフトウェアは納期までに完成しないでしょう。

■ 良いソフトウェアは高いスキルと高いモチベーションを持つ人によって開発されます。

【現実2】優良ソフトウェア開発原理(GSDP)
 良いソフトウェアは、高いスキルと高いモチベーションを持つ人によって開発されます。

　これを優良ソフトウェア開発原理(GSDP) と呼ぶことにします。これは十分条件ではなく、必要条件です。開発者に高いスキルと高いモチベーションが無いと良いソフトウェアは生まれません。インターネットの普及などと共に情報処理技術はコモディティ化しています。日本においても教育制度の改革の中で高い情報処理スキルを持つ人は徐々に増えていきます。内製も困難ではない時代になってきているでしょう。後は、開発者に高いモチベーションを持ってもらうことが大切なポイントとなります。

【現実2-a】
 アジャイル開発の方が開発者の高いモチベーションを維持しやすく、
 発注側の期待と実情にあった良いソフトウェアが作成できます。　

　アジャイル開発の場合には、ゴールに共感する開発メンバによって開発を進めることも可能です。その時、アジャイル開発はウォーターフォール開発に比べて圧倒的に有利な開発環境を得たことになるでしょう。ただし、そのためには発注側の負担がより多くなる点には覚悟が必要です。

■ ソフトウェアの科学的かつ実用的見積りは困難です。

【現実3】
 科学的で、実用的なソフトウェア見積り方法は存在しません。

　ここで、科学的とは、誰が実施しても期待の見積り精度があるもの、実用的とは、低コスト（数日）で見積り可能なものとします。科学的と実用的の両方を同時に満たす方法は現時点では存在しません。この事実を認めたくない人々も今時点の日本には多数存在すると思います。実際、「これまで、見積りできているではないか？」、「私はパワポ１枚の資料を出しても３日間で見積りをもらって、それで契約して、ちゃんと開発を成功させたぞ！」と、反論する人もいるでしょう。しかし日本の多くの見積りでは KKD法 を使っていると予想します。KKDは英単語の略称ではありません。K（勘）、K（経験）、D（度胸） という和製の日本国内限定用語です。

　ソフトウェアの見積りに精度については、インターネットなど存在せず技術の進歩がそれほど早くなかった1980時代初頭から大きな誤差がでることは示されていました。これは 不確実性コーン とも呼ばれています。詳細は、巻末の補足2に譲ります。

　KKD法の中で、唯一便りになるのが、経験の蓄積の活用です。これまで多くの試みがあります。しかし、インターネットによって技術の進歩が一段と早くなった現代、さらに多様なソフトウェア形態が求められるようになった現代において、過去データの蓄積を使った類推による見積りは益々困難になっています。仕様変更に伴う再見積り時であっても一緒です。

　不確実性を減らす努力を発注者も協力して行い、時間をかければ見積りの精度も高められます。しかし、多くの場合にそれはアジャイル開発そのものよりも、だいぶ非効率なものになるでしょう。ましてや、仕様変更が多発するソフトウェア開発で精度の低い見積りはただの無駄です。合理的でロジカルな国の人々は、KKD法などという意味不明な手法を認めることはなく、アジャイル開発を普及させることになりました。

1.3 ウォーターフォール開発では、なぜダメなのか？

【WF弱点1】
 アジャイル開発に比べ変化対応力が弱いから、完成した時点で古いものになっています。
 競争相手がアジャイル開発の場合には常に遅れ続けることになります。

　ウォーターフォール開発(WF)は工程を区切り、前の工程までをきちんと仕上げてから次の工程に進む開発スタイルです。各工程の成果物をしっかりレビューし品質を確保します。V字モデルに従って成果物とテストとを対応（例：詳細設計書に単体試験を、基本設計書にシステム結合テストを、要求仕様書にシステム総合テスト対応を）させて品質の積み上げと呼ばれる作業を行います。

　一旦、要件FIXや仕様FIXを行うと、その後の工程でそれらを変更することは原則として行いません。逆流しないことからウォーターフォール(滝)なのです。多くの開発は半年～１年以上の期間があるためWebサービス利用者の声を開発に反映するのに時間がかかる（細かく反映することには向かない）という弱点があります。

　なお、ウォーターフォール開発は悪ではありません。今後も消滅はしないと思われます。開発手法の違いはシステム開発に求める価値観の違いに依存するのです。

【WF弱点2】
 見積りが正しくないのに納期固定の完成責任が発生するという本質的な矛盾から、
 開発担当者のモチベーションが低下することがよくあります。
 その場合、良いソフトウェアが作られません。

　ウォーターフォール開発には、もっと大きな問題点があります。それは正しくない見積りに対して、請負開発契約での納期固定で完成責任が発生する本質的な矛盾です。開発プロジェクトがデスマーチ（死の行進）化すると、開発担当者のモチベーションが低下し、そのとき作成されるフトウェアは仕様を満たす最低限のものになります。

　別のケースとして、ウォーターフォール開発を前提としながら仕様のFIXをせずに開発を実施することで、ソフトウェア開発プロジェクトがデスマーチ化することもあります。この場合も同様に、モチベーションが低下した開発担当者によって、最低限のソフトウェアが作成されます。

　これらの課題に正面からウォーターフォール開発で対応するには、高精度の再見積りと機敏な契約変更の実施が必要です。しかし、再見積りについてもKKD法であることは変わりませんし、請負契約文化の中では、変更理由の妥当性を経営幹部に理解してもらうことは困難でしょう。増額や納期延伸も拒否されるかもしれません。柔軟な契約変更という幻想は日本では十分に機能していないと思います。

　3K（きつい、厳しい、帰れない？）の開発現場からは、良いソフトウェアは生まれません。そんなソフトウェアによるサービスでグローバルに他社と対等な競争ができる訳がありません。

1.4 日本の慣習で、なぜアジャイル開発は失敗するのか？

　このように優位性のあるアジャイル開発ですが、日本で実施すると失敗することがあります。それは、なぜでしょうか？

■ 請負開発契約でアジャイル開発を実施すると、良いソフトウェアは作れません。

　開発契約には大きく２種類あります。製造請負契約と準委任契約です。図1-1にその違いを示します。

　　　

　　　　図1-1　製造請負契約と準委任契約

　アジャイル開発では、発注側のPOがいつでも仕様の変更の権利を持ちます。よって、請負開発つまり 金額固定の前提である仕様FIXの合意がありません。 請負開発契約によってアジャイル開発を実施することは、受注側がどんなに精度高く見積っても全く意味の無い見積りでソフトウェア開発を実施することと同じです。これでは契約を超えた特別な調整でも無い限り、良いソフトウェアが作成されることはありません。そんな中で製造されたソフトウェアに対して品質保証（瑕疵担保責任）ができるはずもありません。

■ 日米差を理解せず、米国発のアジャイル開発翻訳本の内容をそのまま日本で実施してしまうと良いソフトウェアは作れません。

　日本と米国のソフトウェア業界には、決して無視できない大きさ差異が存在します。代表的な日本と米国の違いを見つめ直してみましょう。

• 日本で主流のソフトウェア開発は、金額固定・納期固定・仕様固定で完成品を届ける請負開発契約 で、かつ、親和性の高いウォーターフォール開発スタイルで実施している。

• 日本ではソフトウェアは 「金で買う」 という価値観が主流であって、受注側に完成責任があると考えている。会計・契約部門などは、仕様を満足すれば誰が作っても同じものができると思っているから、「できるだけ安く買う」 ことが目標となっている。

• 日本において技術者の流動性は低く、経験とスキルが高い多くの開発者とプログラマはソフトウェア開発会社（SI会社）に囲い込まれている。

• 日本の多くの開発者やプログラマは、コミュニケーションに不得意意識があり、面倒な作業だと思っている。

　　　

　　　　図1-2 日本と米国の開発スタイルの違い

　　　

　　　　図1-3 ソフトウェア製造に対する価値観の争い

　図1-2, 図1-3に示すように日米にはソフトウェア開発の契約制度、ソフトウェア開発に対する価値観、プログラマなど技術者の雇用制度、ソフトウェア技術の成熟度など、重要な差異が存在します。それらの差異を理解せず、米国発の翻訳本の主張を そのまま現在の日本に適用してはいけません。

【警告】
 アジャイルソフトウェア開発宣言中の、『契約交渉よりも顧客との協調を』 の部分は、
 「契約種別など気にせず何でも良い」と言っている訳ではありません。　

　アジャイルソフトウェア開発宣言（巻末の補足1）にある『契約交渉よりも顧客との協調を、』 という文言部分を、あまりにも素朴に受け止めて契約を気にしないことは大変危険です。

　アジャイル開発において、意味のない見積りに時間をかけること、および、それをベースとした契約交渉に時間をかけることは大きな無駄です。しかし、請負開発契約で進めるアジャイル開発は失敗です。請負開発契約でアジャイル開発を実施してはいけません。アジャイル開発で良いソフトウェアを作りたいのであれば準委任契約（技術者スキルと稼動量実績値で支払う契約）もしくは派遣契約を締結してアジャイル開発を実施しなければいけません。

■ 日米の違いを理解し、不足するものを整備・確保してアジャイル開発に望みましょう。

　最初に 発注側組織がアジャイル開発に対応する組織に変革 しなければいけません。そのためには次の3つの視点が重要です。そして 経営幹部が危機感を持って推進 しなければそれらは実現できません。

　【変革観点1】　意思・価値観
　【変革観点2】　責任・制度
　【変革観点3】　PO人材育成

　これらを2章 幹部の心得と、3章 POの心得で具体的に考えていきます。

■ アジャイル開発の推進の動機は、発注側にあります。

　アジャイル開発を日本で進める正しい順序は、以下になります。受注側がアジャイル開発の実施を発注側の協力なしに推進することはあり得ません。

Step1-1　発注側・経営幹部がアジャイル開発を理解し、求め、推進する。
Step1-2　発注側・経営幹部がアジャイル開発可能な組織に変革する。
Step1-3　発注側・POがアジャイル開発を理解し、納得し、主体的に推進する。
Step1-4　受注側・責任者が人材をそろえ準委任契約で受注する。
Step2   発注者は開発チームから信頼された仲間になる。
Step3   受注者全員が日々、全体と優先度を考え行動する。 

2022.5.7 改版に向けて修正中