一括請負という契約形態のままアジャイル化するのは危ない
何年か前に、顧客（と元請けの営業）だけがアジャイルに盛り上がった結果盛大に火を噴いて関係者が闇に消えた開発に関わったことがある。立場上そのままは書けないし、適宜フェイクも混ぜていくが、バッドノウハウの一例として紹介するとともに、ウォーターフォールからの脱却という意味でのアジャイルについて書いておきたい。
前提
契約はSI型一括請負、全外注。且つ、アジャイル。
闇アジャイル化の経緯
- 営業がアジャイルを売り込みたかったという背景があり、「だいたいこれぐらい」で契約が成立（仕様がないのに見積もりだけはあった）
- その時点で、元請け企業の偉い人たちがこの案件を切り捨てた（応援要請も突っぱねるよう根回しがあった）（まあしかし偉い人はさすがである、経営的な観点では正しい）
- 全外注は予想されうる責任回避のための手段として決定された（選択権もなかった）
- 顧客は仕様を決めなくてもなんとかなるのがアジャイルだと思っていた
- 仕様、つまり何を作るかも明確にならないうちから、「アジャイルだから動くものを早く出せ」と
- 顧客の気が突然変わり、「UIデザインまで発注した覚えはないから外注しろ」と言われる
- この現場特有の問題として、デザインの外注先が「このような仕様はユーザビリティが低いためデザインなどできない」「顧客に会うまでは作業開始できない」などというクリエイティビティを発揮
- 顧客が「これは研究開発なので既存の技術じゃないやつ欲しい」と言い出す
- やむなく新技術を取り入れるも、前例がない上に調査は難航
- もしもウォーターフォールだったら実装に入っていないといけないフェーズでまだUIすら仕様が決まらない
- 顧客がデザイナーの意識の高さに激怒しクレームを出し始める
- 仕様を決めながら試験をする、という、開発費が底をついたあたりから逆説的にどうしようもなくアジャイル化（＝細切れのイテレーション化）する
- 元請け社内の各部門からあらゆることがフォーマットに則っていないことを責められる
- 最終的に生産されたコードは見積もりの10倍を超える
この案件が巻き込まれた事象はこれ以外にもあるが、「アジャイル」に関連すると思われる部分のみ簡単に記載した。ちなみに這々の体で「動くもの」を顧客に見せたら「それで？」と言われたエピソードなどもある。
闇アジャイル化しないために
悲劇は批判のためにあるのではない、そこから何かを学ぶためにある。
もしもアジャイル、というより、旧来のウォーターフォールからの脱却を望み、それが各企業の業績向上に繋がると信じるのであれば、せめて顧客にもアジャイルソフトウェア開発宣言くらいは理解しておいてもらうべきだと思う。偉そうな言い方だが、「顧客への教育」まで含め、請負側が行なってもいいと思う。
ただし、現状のSI型企業の多くは、「一括請負」そしてアウトソーシングによって利益を出す仕組みでまわっているため、アジャイルがその仕組みの中で、あるいは仕組みを変えるコストをかけた上で、企業にどのような貢献をもたらすか今一度考えてみる必要がある。アジャイル化することのメリット、デメリットを、請負側が十分に理解・実践できないなら、少なくとも軽い気持ちで飛びつくべきではない。
私は個人的には、つまり一介の開発者としては、アジャイルの考え方に賛同するものであるが、企業にどれだけのコストをかけさせ、どれだけ得るものがあるのかは、一概に言えたものではないと思っている。これを無理に遂行すると、企業体質や理念にまで影響を及ぼす、複雑な課題にぶち当たる可能性がある。
また、契約はウォーターフォールのまま、開発側だけにアジャイルのエッセンスを取り入れる方法もないではないと考えている。たとえばテスト駆動はありえる。仕様が決まっており、実現すべき機能が明確になった時点で、テストを作ることは可能であろう。テストコードを設計フェーズのドキュメントとして採用することなどを考えているし、これは実践しつつある。CIもありえる、というよりビルド環境の整備は開発技法を超えて注意深く検討されるべきものであると思う。リファクタリングの重要性にしても同様。他にも有効活用できる手法は多くある。
契約形態を変えることは、こと日本企業においては多くの犠牲を伴い、また多くの年月がかかるだろうと思う。その年月をじっと待つより、あくまでもウォーターフォールに擬態しながら、部分的にアジャイルを実践していくことが現実的な戦い方ではないだろうか。
なお、誤解されがちだが、ウォーターフォール型開発は、その学問的な定義の上で、「工程戻りを禁じている」わけではない。前提となるのは、「前工程が誤っていないものとして進める」ことである。両者は異なるし、前者のように見えるとしたらそれは元請け側の慣習や慣例によるものだ。（ソフトウェア以外のエンジニアリングにおいては、前者が採用されることももちろんある）
自分の実践として、仕様＝何を作るか、は動かさないまでも、設計フェーズより先は必要に応じて動かす、という方針を意識して作業している。今は設計と実装、試験（少なくとも一社または一チーム内で完結する試験）のフェーズにはほとんど明確な壁（工程間の区切り）を設けていない。これにより生じる管理側の溝は、開発経験を踏まえ管理側のレイヤーで処理するようにしている。
今のところこのやり方は、プログラミング指向の開発者がいてくれる場合には歓迎されるが、そうでない場合は嫌がられることもある。けっこう両極端である。ただ、これにより大きな問題は出ていない。なるべく責任≒負債を自社にとどめたくないソフトウェアベンダ（下請け企業）においては、たとえどれほど理不尽でも従来の型通り進めたいとのコメントを聞いたことがある。
ついでにある種の極論になるが、もしも開発者が設計以降のフェーズで顧客要望が実現不可能だと判断したなら、仕様を改めることも視野に入れたほうがいいと個人的には考えている。プログラミング経験者が感覚的にでも「不可能」だと考えるような機能は、危ない綱渡りをしてまで実装する必要がないことが往々にして多いと思うので。つまり、ライト、ついてますか？
IPAの調査報告書も読んでおくといいかも
とくに概要報告書の「付録：インタビュー結果」が興味深い。
デンマーク：顧客やプロジェクトのオーナーの参加は、プロジェクトの前提条件となっている。従来型では、事前の「要求フェーズ」と最後の「文句出しフェーズ」の２回の参加だったのが、顧客負荷がプロジェクト全体にわたって平均的に分散され、私の経験では、参画のトータル時間は少なくなった。（p.61）
「顧客の参画はアジャイル型開発の必須要件である」とある。しかし仕様を決めたくないどころか、仕様を考えたくないような顧客には、要求もなにもない。そういう、なにを開発するべきか顧客にすら分かっていないケースが実は少なくなかったりする。もしそういう顧客から仕事を請けたいのであれば、先に「仕様を決めてあげる」必要があるし、決まった仕様で開発をスタートしたほうが効率的だろうと思う。
日本に普及しにくい理由についての参考意見(2)
まず、根が深い理由は、日本の商習慣にあります。
1.請負型開発の商習慣。委任型が少ない。
2.多段式の開発習慣。少なくはなってきていますがまだまだ。
（p.64）
3と4もあったがここでは省略。
日本型の一括請負の契約形態の中では、まず計画の立案と仕事／責任の分担の明確化を行うことになり、ウォーターフォールじゃないとコントロールできないのではないか。さらに階層が深く硬直した取引関係の中で、プロジェクト全体の構成員の中で 上下関係がはっきりしすぎており、これもアジャイルから遠ざけている原因。（p.65）
アジャイル開発（全部ではなく、短期的なイテレーションの考え方）と受託は相性がよろしくないのではないかという感想を今のところ持っている。実際問題アジャイルで利益を上げることができるかと問われると、ちょっと答えに窮する。（しかし経営的な観点でも根拠がなければ組織を変えることは難しい）
一方、自社開発や研究開発といった、「契約を介さない」開発においては、きっと成功率は高いだろう。米国で成功している事例も多くは自社内での開発だという。
いずれにせよ、こうして組織や経営面からソフトウェア開発を俯瞰することを、芸術的なまでに能力の高いプログラマは忌避するかもしれないし、こうしたことにまったく興味を持たないかもしれない。けれど私は思う。我々の大好きな、美しく整然としたコードは、しかしそれだけでは単なる情報の羅列に過ぎない。その価値を証明するために、価値というものの定量的な単位の一種である価格、つまり商業的な側面に着目することは、そう遠回りではないと思う。それならば、プログラマとしては平々凡々な私が組織や経営を学んだほうが、全体的に効率がいい。デスマになる契約を許してはいけないし、出せる手札は多いほうが個人的に好ましい。
