DevLOVE「Change The Future 僕らの開発がアジャイルであるために」へ行ってきた

Event

水曜の夜、DevLOVE「Change The Future 僕らの開発がアジャイルであるために」へ行ってきました。内容は、XP祭り関西2010で行われた倉貫さんと木下さんの講演の再演です。

じつは申し込みをしないまま満員になってしまったのですが、急遽キャンセルされた方からTwitterで声をかけていただき、無事参加することができました。ありがとうございました。

というわけで、レポートと感想をメモしておきます。

# 事例紹介と質疑応答は、Webでどこまで再現してよいか分からないため、詳細を割愛しています。

XPの10年を振り返る（倉貫義人さん）

ご本人が、XP祭り関西2010での発表資料を公開してくださっています。

XPとの出会い

倉貫さんが学生時代に働いていたベンチャー企業では、社員は皆プログラミングが好きで、生き生きと仕事をしていた。一方、就職したSIerでは、プログラミングを楽しんでいない人たちに囲まれて仕事をしていた。また、働き始めてすぐに、デスマーチに放り込まれた。わずか一兵卒の技術力で、火を吹いた大型のプロジェクトを立て直すことはむずかしい。技術だけでは解決できない現実に直面して、どうすればよいかを考え始めた。

そんな頃にXPと出会った。元々オブジェクト指向の技術をしていた人たちが、開発プロセスを検討して、生み出したのがXPである。「技術だけでは解決できない」という倉貫さん自身の状況と、それがぴたりとはまり、開発方法論を学び始めた。

2002年、初めての本格的なXPのプロジェクト――「守」

この時、XPの本は、マネジメントやチームビルディングのための教科書だった。問題にぶつかった時は、「Kent Beckならどうするだろう」と考えて、白本を読み直した。教科書的にXPをやろうとした。

このプロジェクトは成功し、倉貫さんは、事例発表や記事の執筆などをした。

2003年、牛尾さんの事例発表に衝撃を受ける

XP祭り2003で、牛尾さんの事例発表を聴き、倉貫さんは衝撃を受けられた。当時NECに所属されていた牛尾さんが発表した事例は、倉貫さんの事例を規模や内容の面で超えていた。また、発表スタイルにも独特の個性があり、衝撃的だった。

それまで倉貫さん自身は、事例発表が特に好きでもなく柄でもないと思っていたが、牛尾さんの発表を聴いたことをきっかけに、もっとやりたいと思うようになった。・・・なお、こういう出会いがあるからコミュニティには参加してみるとよい、というのも、今回のメッセージの1つとのこと。

2004年〜2005年夏、独自のプロセスを作って適用したプロジェクト――「破」

このプロジェクトでは、自分たちなりのプロセスを作成して、実践した。プログラマは楽しく開発していたし、ソフトウェア開発の面では上手くいったが、プロジェクトとしては上手くいかなかった。

この時は、実装のフェーズのみをアジャイルで行い、その前後の要件定義と検収などはウォーターフォールで行った。その結果、開発全体は、要件定義で決めた機能だけを実装するという、およそアジャイルとはいえない状態になった。ある機能の優先度が途中で下がって、不要になったとしても、要件定義で決めたものは必ず実装した。また、より優先度が高いと思われる機能が浮上しても、顧客から追加料金が出ないようであれば、実装しなかった。

しかし、顧客には、発注側の立場や責任があるため、変化に対応して機能を追加削除したり、追加料金を出したりできないことは、仕方がなかった。発注担当者は、決まったお金の範囲で、必要な機能を作ることを上司から求められているため、リスクを負うことはできない。

また、パートナー企業の人と共同で開発していたため、契約形態によっては、仕事のやり方まで口出しすることはできなかった。たとえば、TDDやペアプログラミングを指示することはできない。また、請負ではなく派遣契約に切り替えて、共同で作業してみても、上手くいかなかった。エンジニアにとってよかれと思って取った施策が、人によってはかならずしも喜んで受け入れられるものではなかったためだ。

この経験を通して、倉貫さんは、受託開発でのアジャイルに疑問を持つようになった。

2006年新年、ディフェンシブな開発

この時期、倉貫さんは上の記事を書いた。

受託開発をコップと水に喩えると、次のようになる。コップの容量が、発注金額である。SIerは、水である開発コストをなるべく抑え、水より上の部分、つまり、儲けを増やそうとする。水がコップを溢れたら、赤字案件になり、負けである。だから、SIerは、なるべく計画通りに開発し、生産性を上げようと努める。しかし、生産性があがるとは工数が減ることであり、人月が減ると売上が減ってしまう。倉貫さんの上の記事は、このSIerのビジネス構造にこそ問題があるという提言である。

SIerのビジネスが、構造上、守りに入らざるをえないのであれば、残された道は、お客さん側のエンジニアになるか、サービス提供者になるかしかない。

2005年11月、社内SNSの開発プロジェクト

情報システム部の管理職として、社内SNSを開発した。予算管理を自分で行い、内製でシステムを開発したところ、このプロジェクトは成功した。この時、内製開発するためのスキルと、自分たちでリスクをとる覚悟が必要とされた。

2007年、社内SNSのOSS化、SaaS化――「離」

プロジェクト解散の危機に際し、社内で開発したシステムをOSS化することと、それをSaaS形式で提供することについて、倉貫さんは、時間をかけて社内調整をやり通した。その結果、社内SNS――SKIPはOSS化され、クラウド型のサービスとして提供されるようになる。

  • Point of Sales：製造業型のビジネス
    • 構築に時間がかかり、買った時点が最高品質で、古くなったらリプレイスするというモデル
    • 従来の受託開発が近い。
  • Point of Use：サービス業型のビジネス
    • 構築の時間が短く、利用中が最高品質であるというモデル
    • 変化に対応するアジャイル開発が近い。

上の2つは、どちらが良い、悪いの話ではない。ビジネスにはそれぞれ違いがあり、開発手法を画一的に当てはめてはならない。ビジネスに沿った開発をすることがアジャイルである。手法ありきではなく、ビジネスありきで開発しよう、というのが、今回のメッセージとのこと。

なお、アジャイルは保守性を大事にしており、クラウドビジネスとアジャイル開発は相性が良い、というのが、倉貫さんの現在の見解である。

1999年〜2009年、購入して減価償却していくモデルからの脱却

10年前にサービス業型の開発を行う上で制約だったものが、制約でなくなりつつある。

ソフトウェアは、プロプライエタリから、オープンソースになり、ハードウェアは、自前で調達するものから、使いたい分だけ使うクラウドへ移行しつつある。

このような状況の下で、今後はサービス型の受託開発が出てくるかもしれない。

守破離のお話
  • 守：周りの変化を受け入れる。――勇気をだす
  • 破：自ら変化しようとする。――疑問に思う
  • 離：周りの変化のきっかけを作る。――情熱をもつ

倉貫さんにとって、XPの10年は、守破離を実践した10年だった。

アジャイルアンチパターン（木下史彦さん）

ご本人が、当日の発表資料を公開してくださっています。

アジャイルは今どこに位置するか

木下さんの感覚では、この10年でイノベーターに行き渡ったが、キャズムはまだ超えていない。これまでは、感度の高い人が興味を持って取り組んでいるだけだったが、最近、大企業や経営者層もアジャイルに関心を寄せている。

James Shore氏の「アジャイルの衰退と凋落」の記事には、名目だけになったアジャイルが衰退していくと書かれた。以前は、アジャイルを導入することや技術的課題が問題とされていたが、現在は、人と人との問題にボトルネックが推移している。

というわけで、今回の発表は、アジャイル開発に実際に取り組む人たちがよく陥る6つの問題と、その対策について。

XP、6つのアンチパターン
  1. 仲良くなりすぎる問題
  2. 過剰な透明性
  3. 頻繁な再計画
  4. 正直さのはきちがい
  5. 受け入れられないスコープ調整
  6. 進みすぎる問題
  • 1. 仲良くなりすぎる問題
    • この問題は、たとえば、チームのふりかえりがマンネリ化してくるような現れ方をする。「部屋が寒い」や「お菓子が足りない」といった問題は出されるものの、「お客さんとうまくいっていない」というような本質的な問題を誰も言い出さない。
    • この問題は、集団思考、斉一性への圧力などが、原因として考えられる。XPは協調を重んじるが、それが歪むと、このように重要な問題が隠されてしまう。
    • 解決法は、やはり誠実に、勇気を出して、真実を述べること。具体的な方法として、たとえば、ふりかえりにチームの外の人を加える仕組みを作る。
  • 2. 過剰な透明性
    • この問題は、たとえば、顧客から信用を得ていないために、計画や見積もり、実装する機能、優先順位などを細かく見せねばならず、それについて突っ込まれ、回答しなければならない、という形で現れる。
    • 最初は信用されないのは仕方がないが、マイクロマネジメントがいつまでも続くのは、脇が甘い。細かな報告を求められるのは、成果を出せていないため。
    • 解決するには、仕事の成果を上げる。つまり、コミットメントを果たすことで、このような状況を排していく。
  • 3. 頻繁な再計画
    • イテレーションが終わるごとに再計画ができてしまう。これをいいことに、計画をずるずると延ばすのは、木下さんいわく「信頼をなくす簡単な方法」
    • コミットメントを果たせないときは、顧客への説明責任を果たし、ふりかえりを行い、もし技術的な問題で上手くいかなかったのであれば、技術的卓越を追及することを、忘れてはならない。
  • 4. 正直さの履き違い
    • この問題は、書籍『アドレナリンジャンキー』に出てくる「ジャーナリスト」のこと。計画や設計どおりに開発が上手くいっていない時、顧客に対して上手くいっていないことだけを報告し、ではどうするのかという検討や説明をせずに投げっぱなしにするという問題である。
    • これでは、顧客の不安をただ煽るだけになってしまう。
    • 解決するには、落としどころを考えて話すことと、何か話すにも気を利かせることが必要である。
  • 5. 受け入れられないスコープ調整
    • 開発が予定どおり進まない時は、スコープを変更せよとアジャイルの教科書ではいうが、実際にはなかなか難しく、できないことが多いという問題がある。一度コミットメントした機能を減らすと、顧客の利益を害することになるためだ。
    • しかし、生身の人間と相対して、スコープを変更する話をしなければならない。
    • 相手の声を聴き、立場を推し量ることが重要。また、同じことを伝えるにしても、どう伝えるかに気を配る。関西の表現でいうところの「うまいこという」のが大事。
  • 6. 進みすぎる問題
    • アジャイルでは、チームにプログラマ3名と顧客2名が、良い比率とされている。これが、プログラマ10名に顧客1名の状況だと、顧客から要求を出してもらうことが追いつかない問題や、顧客に問い合わせをしてもなかなか答えが返ってこない問題が起きる。
    • 顧客側の人数が少なくて手が回らないときには、プログラマがその役割を超えて、顧客を支援できるようになっていく必要がある。役割という壁を壊す。
XPの次の10年とは

アジャイルは難しい。スクラムもXPも、フレームワークであり、その中で解決できない人と人の問題が難しい。Kent Beckが「social change」といったように、XPは、人と人とのつながりのあり方を変えていくものである。これからの10年がどうなっていくのかを考えたい。

感想

ビジネスに寄り添う開発とは何かを考えていきたい

冒頭に書いたとおり、今回のDevLOVEには、直前まで申し込みをしていませんでした。理由は、アジャイルで開発をしているのでもなく、アジャイルを適用することを目指しているのでもない自分が、何を求めて参加したらよいか分からなかったからです。今回はテーマ的にスルーかな、なんなら設営だけ手伝おうかな、と思っていました。

でも、開催前夜にpapandaさんのつぶやきを見て、最近興味があるど真ん中のテーマだと気づき、しまったと思いました。

4.7の #devlove ではビジネスに寄り添っていくようなソフトウェア開発をやっていくために大切なこととはなんだろうね、という会話が出来るといいなと。いっそ、タイトルにアジャイルという言葉は使わない方が良かったかもしれない。

Twitter / papanda - 1:41 AM Apr 7th

あぶない、あぶない。参加できてよかった。

SIerの受託開発には、開発手法としてウォーターフォールしか選択肢にない案件があります。案件の規模が大きかったり、お客さんが堅い業界だったりすると、基本そうだと思います。例えば、金融業向けの大型案件は、その典型ですよね。その中で、ビジネスに寄り添ったシステム開発を行い、しかも開発者が生き生きと仕事をするためには、個々の開発者は何をして、どうなればよいのか。今、そのことが、とても気になっています。

倉貫さんコップと水を使った受託開発の喩えは、非常に分かりやすくて、SIerのビジネスに絶望できます。というのはまあ冗談ですが、複雑な気持ちになりました。詰んでるなあと感じます。でも、自分は、「発注側のエンジニアになる」のでもなく、「サービス提供者になる」のでもなく、SIerとして何ができるかを知り、実践したいです。

そのためには、「システム開発を通してどうありたいか」という像が必要です。フレームワークとしてXPを使うにしても、別のものを選ぶにしても、何を目指すのかがはっきりしていなければ、適切な選択ができません。DevLOVE2009から4ヶ月が経ち、月について語る必要性が、やっと腑に落ちた感じです。

月に辿り着くには、開発方法論や開発ツールなどをボトムアップに学ぶことも、ソフトウェア開発でどうありたいかをトップダウンに考えることも、両方必要なのに、自分は後者にかなり無頓着でした。それに気づいただけでも、今回参加して良かったです。

残された制約は解決できるか？

詰んでる感想ばかりなのもアレなので。

倉貫さんのお話の中で、「制約だったものが制約でなくなってきた」というくだりが、とても面白く、興奮しました。残された制約は何だろう。契約？ 見積もり？ スキル差？ 分散開発？ …などと考えていたら、「ディフェンシブな開発」の記事に、一部書いてありました。

ディフェンシブにならざるを得ないということを考えると、今のSI業界の抱えている矛盾や構造が全てつながってくる。契約の問題もしかり、工数計算の問題もしかり、会計基準の問題もしかり。

ディフェンシブな開発 〜 SIビジネスの致命的欠陥 - kuranukiの日記（移転しました）→ http://kuranuki.sonicgarden.jp

これらの制約は、技術の進歩や制度の改善によって、取り払われるのでしょうか。人月見積もりの問題は、パフォーマンスベース契約によって、どう変わるのか？ 共有スペースで作業できないという分散開発の問題は、十分に発達したコラボレーションツールによって、擬似的な同席という解決を図れるだろうか？ などと考えて、わくわくしました。

ソフトウェア開発でこうありたいという姿と、それを妨げている制約について、今後もっと考えていこうと決めました。

倉貫さん、木下さん、オラクルさん、参加された皆さん、ありがとうございました。