アジャイルからはじめる社会変革

執筆 :　2011/07/12

掲載誌

Ultimate Agile Stories - Iteration 1

モノローグ

大学は文系だったが、ゼミでVT100端末でCやShellやAwkのプログラミングの真似事をしてから、「プログラミングって面白い。何かを作るのに、ハードを扱わなくてもいいんだ」ということに気づいて業界を決めた。Perl4のキャメルブックを小脇に抱えて、会社訪問をしたものだ。まぁ大して真面目に勉強していたわけでもなく、自己表現が得意なわけでもなく、バブル後のせいもあって、夏まで就職活動していたことは覚えている。学生の頃は、プログラマーでもハッカーでもない文系学生。本当に、そこら辺によくいる、ちょっと思い込みの激しい社会人一年生、それが僕だった。

そして1995年に会社に就職した。新人教育で学んだのはCOBOLだった。宣言がやたら多いなぁという印象しかなかった。その後でCを使ったプログラミング研修が始まった。自分は「スクリーンエディターつくります」と言ったら、先輩に「無理無理、やめておけ」と突っこまれた記憶がある。結局ローカル掲示板みたいなアプリを作っていたっけ。

そんなこんなで、約5年務めたけど、5年目の年末付けで退職してフリーランスプログラマーになった。退職理由は「もっとインターネットに関わって、技術的に進んだ開発の仕事がしたい」という、まぁよくありがちな若気の至りからだった。ただ、そんな独立のきっかけは、退職直前に1年ほど携わっていたプロジェクトだった。

そのプロジェクトは、当時飛ぶ鳥を落す勢いだった今は亡きITベンチャー企業のEコマース構築プロジェクトだった。そこではCGIをCで書いていた。CGIをPerlで書いたことはあったけれど、Cで書くのは始めて。そしてそこでは、ユースケースを使って業務を分析し、クラス図とシーケンス図を使って設計したフレームワークを構築していた。オブジェクト指向については、勉強してはいたけれど、所詮「クラスを使っています」レベルを抜けてはいなかった。その当時の自分には、設計からオブジェクト指向を使っていること自体が刺激的だった。そして、インターネット上で動くアプリケーションを作ることに対してもわくわくした。チーフのエンジニアの方を中心にスキルの高い方が多く、いろいろ教えてもらいながら仕事をしていた。キツいけれども、楽しいプロジェクトだった。

はた、と自社に戻ってみる。回りは相変わらず、VBクラサバシステムばかり。技術的に突っ込んだ話をできる人も少ない。 このままでよいのだろうか？ もし、このときに外部の勉強会などに目を向けたら、また結果は違ったのかもしれない。でもその時は、その選択肢は自分の中にはなかった。部長に話し、説得され続けたが、結局会社を退職した。

この転機の例で示したのは、それまでの自分の知らない世界を知ることで、自分に変化が起きる。自分が変わり回りの風景が一変し、自分との関係が変わる。Kent Beckが話していた、 自分が変化の起点となる体験だったということだ。ただ、若かりし自分は、自分の変化の結果、回りに影響を伝播させるのではなく、自分がいる場所ではないと判断して、変化の波を断ち切ってしまったのだけれども。 ¹

アジャイルとの出会い

僕が最初にeXtreme Programming(XP)に出会ったのは、2000年のruby-listのメーリングリストだった。

ruby-list:24246: eXtreme Programming の略です。日本語だと「究極のプログラミング」（笑）
Smalltalk界でKent Beck が開発して、アメリカで大ブームになっているオブジェクト指向系の開発方法論です。
＃Kent Beckの本の日本語訳は10月頃に出版される予定です。

10人程度までのチーム用で、仕様変更の多い、短納期の開発には驚異的な効果を
あげます。この手法は「コーディングの前に自動テストを書く」ので、その
Ruby用のテスティングフレームワークとしてRubyUnitがあります。また、２人で
一台の端末でコーディングするペアプログラミングやコードの所有権の全員共有な
どにも特徴があります。

このメールに出会って、僕の人生は変わったと言っても過言ではないのかもしれない。もっともRubyを使っていたから、という点では、Rubyのおかげと言えるかもしれない。すぐさま平鍋さんの主催していたXP-jpに入り、長瀬さんが発起人をしていた日本XPユーザー会(XPJUG)を起ち上げスタッフに参加して、コミュニティを起ち上げ運営していきながら、様々なことを学んだ。

その後、xUnitについての書下し本を執筆したり、最初のScrum本の翻訳に関わったりした。フリーランスという立場もあり、自分の好きなようにコミュニティ活動をしていた。ある時、平鍋さんに「永和システムマネジメントの東京支社を作るから来ない？」と声を掛けられた。その時は断わっていたのだけど、なんとなくフリーランスでやることの行き詰まりは感じていた。

フリーランス時代の終りの頃、2002年から2003年にかけて、某大手SIerの連結会計システム製品の開発に関わったことがあった。中規模(20人)のJavaとVBのプロジェクトだったが、当然のように単体テストは書いてない、OO設計もしてない、レガシーコードのプロジェクトだった。まずは単体テストをJUnitで書くこと、それをチェックインした後に、必ず結合サーバーでビルドをしてから主導で自分の担当分のテストを実行して結果を確認する、というルールを提案し、少しずつテストを書いてもらうようにしていた。そのために、当時はまだバージョン2.0だったEclipseを使うことも提案し、テストの実行や、リファクタリング機能なども、皆に少しずつ教えながら、進めていった。新しく来た人も、当然のようにテストを書きはじめてくれて、一応そこのプロジェクトの文化になっていたのかなと思う。思えば派遣でポッと入ってきた僕の言うことを聞いて、いろいろやらせてくれたのも凄いことだと思う。

手動CIの実行に、待ち行列ができるので、ファミレスの順番待ちのように、Excelシートに名前を書いて予約するなんてことをあるメンバーがやりはじめた。いつしかその名前の横に、その時の一言コメントを書くようになっていった。それぞれの、その時の想いが記録されていった。実はそのリストを印刷したものを、未だに部屋のどこかに残していたりする。

この時も、終電とか、タクシー帰りとかよくしていたし、自転車で通勤することにして夜3時で帰るとかハードなプロジェクトだった。でも、その事で心が折れたりすることはなかった。なぜかと言うと、チームとして仕事をしているのが楽しかったからじゃないかと思う。そのプロジェクトを抜けた後に、また一人仕事をしていたのだが、それが辛くて、自分の今望むことが「チームで仕事をする」という欲求だと気づいた時に「同じ会社の仲間と仕事をする」ために、平鍋さんにお願いをして福井本社に行き、当時の社長の小山さんにお会いして、僕より一足先に入社していた天野勝さんと福井市内のお寺を回りながら夢を語り、そして永和システムマネジメントに入社した。ツールや技術にしか興味のなかった自分が、チームというものに興味を持ちはじめた。 ひとつ外の世界が広がった。

アジャイルの成長を考える

さて、ここまでの、どうでもいい自分史を紐解いたのは、ノスタルジーにひたるためではなく、何か新しい変化が自分の中で起きたケースとその行動の例を示すことが目的だった。言い換るならば、新しい外の世界を知った時に、その世界に飛び込む、あるいはその世界をも巻き込むことだ。

僕はアジャイルの価値体系は、長いソフトウェア工学の歴史の延長線上として、外の世界を知って、その世界に飛び込む、巻き込むことの繰り返しにより築きあげられてきたのではないか、という仮説を持っている。DevLOVE 2009 Fusionで話した、僕のAgileという言葉の裏側の意味が、どんどん拡張されてきたのと同じように。

つまりこうだ。開発者として、よいソフトウェアを作るために、「ソフトウェアそのものの構造」にだけ着目しているのでは足りないことに気づいた、そこで、そこに至るプロセスに着目する。またある人は、よいソフトウェアとは顧客に価値を与えることで測れると気づいて顧客を巻き込むことにした。またある人は、一度で上手くいかないのであれば、小さく繰替えすことで対応しようと気づいた。全部作る前提で進めるとうまくいかない、そこで顧客にとっての優先順位を付けて、その順番に作ることで価値の提供に重点を置こうとした。ソフトウェアの作り手同士のコミュニケーションが大事だが、単に集まるだけじゃうまくいかない、そこでチームとしてうまく機能するためにファシリテーションのテクニックを導入してみよう。顧客を直接巻き込むのはなかなか難しい、では顧客役を立てて代理人としての権限を持たせるようにしよう。そもそも仕事を細かくして人に割り振るだけじゃうまくいかない、そこでチームとしてコミットメントだけにして、チーム内で動的に役割分担しながら進めることにしよう。どうも最後に自動テストを書くのは億劫だ、では常に先に自動テストを書いて実行していくようにしよう。などなど。

それぞれは、その場の課題に対しての、解決策をとっているが、その範囲は拡張していっている。「よいソフトウェアを作りたい」という想いを突き詰めていくと、どんどん技術領域の外の世界に広がってきてしまったのではないだろうか。人に関する部分、チームに関する部分、コミュニケーションに関する部分、ビジネスに関する部分、最近ではユーザーエクスペリエンスのデザインに関する部分なども加わってきている。アジャイルが、他の領域をそのスコープに含め拡張していく様は、アジャイル以前から多くのエンジニアたちが、様々な試行を積み重ねている歴史そのものでもあるのだろう。

試しに、XPの白本をお持ちの方は、巻末の参考文献を見てほしい。ソフトウェア工学に関しての領域はもちろん、そこに留まらない様々なジャンルの書籍へのリファレンスとコメントが掲載されている。つまり、ある領域だけではなくてさまざまな領域についての知識が重要になってきた証拠なのだと考えている。ここで言う「さまざま」とは、ソフトウェア開発の周辺にあるすべての領域だ。わかりやすい例がリーンなどで言及されている製造業であるし、パタン・ランゲージなどで参考にしている建築やまちづくりの世界だ。そして専門性に加えて、総合性が重要ということだ。 XXX工学が、バラバラに使われているのではなくて、様々領域の専門知識を、全体(ここで言うと顧客の要求からソフトウェアを通じて価値を得る、それを継続する)を俯瞰した上で、流れるように、分断されることなく、有効に機能させるということだ。専門家が単に集まって、それぞれが分断されていては、残念ながらうまくいかないことが多い。「俺はこの仕事しかやらないから、お前はそっちやれ」、「いやいや、それは俺の仕事じゃない」と綱引きする内はまだいい。互いにグレーゾーンを見て見ない振りをするようだとうまくいかない。大事なのはそれぞれが交わりあいながら、一つのチームとして機能することだ。

そして、僕は作る人だけでなく、使う人や関わる人、作る対象のシステムそのもの、それらの関係性を含めて全体性と呼びたい。そして全体性を継続的に高めていくことが、アジャイルな考え方と行動だと認識している。

3.11を通じて

さて、ここでちょっと話を変えて、3.11についての話をしてみたい。僕は愛媛在住なので、まったく地震に関しての影響は受けなかった。とはいえ両親の実家が岩手県で、親戚が気仙沼付近で被災した。幸運にも命だけは無事だったが職場を失ったそうだ。実家や弟夫婦、そして多くの知人友人は今でも多く東京に住んでいるから、東京方面の様子も気になる。

特にあの頃問題になったのが、原発への対応の遅さだ。政府と東電と原子力保安委員会の、ちぐはぐした対応、安全基準を引き上げ、避難警告も出さず、情報を隠し続け、ほとぼりが覚めたら「実はXXXだった」と言う。海外向けの情報公開サイトの方が、国内向けよりも詳しい情報を公開していた東電のサイト。TV局は、すべて震災特集にしていて不安を煽っている。そのTVを見ていたら、親も子供も精神的におかしくなっていた。

この頃の僕は、心底から関係各社がチームとして一つになって、一なる目的、たちはだかる課題に立ち向かう、というアジャイルチームの振る舞いを願っていた。しかし残念ながら、それが実現されることはなかった。隠蔽、恫喝、疑念、責任の擦りつけ合い、僕らが、「悪い見本」とするプロジェクト運営そのものだった。人によっては「マネジメントがなってない」、「指揮官が悪い」なんて意見もあった。まぁその通りだろう。チームとして機能してなかったね。

3/15のTweetでこんなことをつぶやいていた。 > まず、今は何を大事にして、どんな問題に立ち向かって、どういう結果にしたいのかを、 マスコミと政府と東電で話しあって、優先順位をつけて、上から対処してほしい。

でも、まだ当時の方が今よりもマシだったかもしれない。なぜならば緊急事態だったから。今は表面上の緊急事態は過ぎた。しかし被災地には数千万トンの瓦礫が未だに放置されていて、未だ復興の見通しは立たない。相変らず原発は収束しておらず、日々少しずつ放射性物質が拡散していっている。しかし、その影響が、どこで、いつ頃、どのようになるかなんて、誰にもわからない。そんな世界に僕らは生きざるを得なくなった。そして放射性廃棄物の問題もある。10万年とも100万年とも言われる後にまで、地中に放置しておくしかない廃棄物。僕らアジャイリストが、避けねばならない技術負債の究極だ。言語すら通じるかわからない、未来の子孫にこのような技術負債を残して、今をどうやって生きると言うのだろうか？

ここで、「首相が悪い、政府が悪い、東電が悪い、経済界が悪い」と責任の所在を追求するのもいいが、大事なのは、現状を観て、それに対して責任の追求ではなく、問題の解決にフォーカスして、行動して結果を出すことじゃないだろうか。

さて、この文章は「アジャイル同人誌」なので、これ以上、震災と原発ネタについてはここで辞めておく。自分の気づきとして書いておきたいことは、ただひとつ。

こんな透明性のない社会で日々の生活を送り、いつまた震災や原発で同じような被害が起きるリスクを放置しながら、想像もつかない未来にまで技術負債を残したままでいいのか？

これは僕らのよく知ったプロジェクトでの状況に置き換えて考えてみるとわかりやすい。

こんなバグや技術負債を抱えていて、表面上はスケジュール通りの進行をしていて、結合の時にビックバンになるリスク、次の機能追加の時に明らかに困難になる状況を放置しておいていいのか？と。

僕らは、実際のプロジェクトでこんな状況に出くわしたら、どうするだろうか？ もちろん一人じゃなにもできないかもしれない。でも少なくとも自分の作るモジュールだけはテスト書こうとか、リーダーに相談してみたり、自分のできることをするのではないかな。顧客に正直に状況と将来的なリスクを伝えてスケジュールの再考を促す、なんて人もいるかもしれない。それでも結局、全体を変えることはできないかもしれないけど、アジャイルに共感を覚える人は、その場に居合せたら、きっと何かの行動をするのだろうと僕は考えている。

隣りの席の「もう何をしたって無駄だよ。とりあえず淡々と与えられた仕事をやり過そうよ」と囁く同僚、「そんなこと言ってみろ、うちの会社が出禁になってしまうかもしれないだろ！ここは大人になって淡々と隠しながら進めるぞ。」と諭してくる上司。こんな人がいたら、あなたはどう感じますか？ どの発言も、立場としては間違っていない。でも、それぞれの立場で、正しいことをしても、全体としてはよくならない、というのが、今回の震災における政府や東電やマスコミの対応だし、変化を好まない同僚や上司の対応だ。

ここで伝えたいことは、次のようになる。

今回の震災をきっかけに、僕らが経験したこと、知ってしまった事実を評論しただけで放置してしまって忘れてしまっていいのか？

ではどうすれば？

わかったよ、では、じゃぁ、どうすればいいの？ この問いに対する、誰にも当てはまる明確な回答を、残念ながら僕は持っていない。だけど、僕が今考えていることを書こうと思う。

僕らが、「アジャイルな開発を使って顧客に価値を提供したい」と考える時、あるいは「自分が信じる新しい何かを会社に広めたい」と思う時、何を最初に考えますか？ いや、もっと小さいことでもいいかもしれない。例えば、「あなたのチームでチケット管理システムを導入したいと考える時には、最初に何を考えますか？」でもいい。当たり前だけど、「皆が、その変化を受け入れた結果、どのような嬉しい世界になるか」を具体的に想い描くんじゃないかな。

同じように、ビジネスを越えて社会に対して「この閉塞感に溢れた社会に対して、どんなありたい未来を想い描きますか？」、「どんなモノ、コトを子供や孫に残したいですか？」 、「あなたが想い描く、ありたい100年後の日本はどのようになっていますか？」、「地球全体として、ありたい姿はどのようなものでしょうか？」を考えてみたらいかがだろうか。その上で、今の自分にできること探し、選択し、行動に移すのだと思う。

大事なのは、正確に予測することではなく、まずは向かいたい方向を狙い定めて、後は、その方向を向いて走りながら修正し続けること。アジャイリストなら誰でも知っている。方向が変れば、そっちを向いてまた走ればいい。その方向に向かって走るためには、できることを自分の頭で考えて、精一杯やるだけだ。それ以外にない。 ありたい未来を想い描くにあたって、参考になるかもしれない指標があるのでご紹介しておく。それが GNH (Global National Happiness、国民総幸福量) 5 だ。GDP(国民総生産)という経済指標の代替として、ブータンが用いはじめた新しい指標だ。生産と呼ばれる単一のモノサシではなく、 基本的な生活(living standard)、文化の多様性(cultural diversity)、精神的幸福・精神衛生(emotional well being)、健康(health)、教育・教養(education)、時間の使い方(time use)、環境(eco-system)、地域共同体の活力(community vitality)、良い統治(good governance)といった複数の指標による総合的な幸福度を測ろうというものだ。もちろん、これとは異なるモノサシもあるだろう。重要なのは経済的価値だけをモノサシとして使うのは、限界があるということだ。ちなみに日本は、GDPではなくこのGNHで測ったところ、かなり低い値が出たとの研究成果がでている。

例えば、このGNHを参考にして将来を考えてみてはどうだろうか。経済という単一指標では測れない、全体性を認識し、そこから、自分が今何をしたらよいのかを導きだせはしないだろうか。

「そんな大きなこと、わかるわけないし、わかりたくもない」という人もいるだろう。では、「自分の会社」、「自分の業界」といった今着目している世界の更に外側の世界を想像してみることはできないだろうか？ より外側の世界に意識を移してから、改めて今の自分の周辺の世界を観ることで、なにをすべきかが見えてくることがあるのではないだろうか。アジャイルにしてもそうだ。もし「作り手」という世界で滞っていたら思いもつかないことが、「使い手」との世界を見据えることで、生まれてきたのではないだろうか。

おわりに

歴史を紐解くと「何かが変わる」場合には、革命や改革のように短期間に大きく変わる変化と、徐々に変わっていって、気づいたら大きく変化していたという漸進的な変化の二通りがある。僕らの業界における、アジャイルの広がりかたは、前者ではなく後者ではないかと感じている。少なくとも、世界的には、この10年ほどで、ゆるやかに着実に変ってきた気がしている。これを「アジャイルも所詮開発技術のひとつに過ぎない。だからハイプ曲線を描いて今が啓蒙活動期なのだ。」と呼ぶ人もいるかもしれないけどね。

僕らが、ソフトウェアではない何かを変えていきたい時にでも、アプローチとしてのアジャイルは検討に値するのではないかな。そしてアジャイルを広めようと苦心している人にとっては、その経験も生かされるはずだ。… 人を巻き込む、ビジョンを共有する、価値を明確にする、近いゴールを決めて皆で走り抜ける、ちょっと立ち止まってふりかえる、目標も計画も少しずつ変えていきながら、前に進んでいく。先を見ながら今に注力する。オープンに話しあう、人を信頼する、協調する、行動で変化を作りだす。

実は、クリストファー・アレグザンダーが提唱している、パタン・ランゲージを使った建築プロセスも、まったく同じように、町や建築物を、漸進的に作りあげていくプロセスだ。でも一つ、アジャイルと違う部分がある。それは、そこを使う人、住んでいる住民自らが主体的になって、何を作りたいかだけでなく、パタン・ランゲージを使って設計原理を自分達で考えていくのだ。できれば施行の部分も自分達で。そう、変化の主体は それを必要とする人でありそれを作りだす人なんだ。

もし社会を変えたい、変って欲しいと願うのならば、変化の主体は自分であるべきだ。まず自分が変わり、できることから小さくはじめることで、僕らがアジャイルで現場を変えたいと思ったように、世の中も少しずつ変っていくのではないだろうか。それが僕の考えるアジャイルからはじめる社会変革だ。

最後にまちづくりや、サステナビリティの文脈で、よく使われるフレーズを紹介しておく。

Think globally, Act locally.

「グローバルで考え、ローカルで行動する。」ここのグローバル、ローカルは、その人によって変わるかもしれない。単なる場所だけではなく、時間軸での遠い将来と、直近、という軸でも捉えることができるだろう。より外側の広い視点を育てつつ、「今、ここ」に注力することが、誰にでもできる、最上の行動だと信じている。

エピローグ

えっ？「じゃぁ、お前は何をするのか？」って？ そうだなぁ…まずは、自分で野菜を作って、東北に震災復興ボランティアに行きつつ、地元のまちづくりに参加することからはじめようかな。あ、もちろん地元での技術勉強会やコミュニティ作りもね。

[関連する記事]