ユーザー視点凝集をめぐる冒険 (2) – 継続的なリリースという罠

前回は「どのようにシステムを切るか?」ということについて考えた。

ところで、何故システムを「切る」必要があるのだろうか? それはシステムを作る際に、切り分けたシステムを別々の開発者に割り当てて分業したり、スケジュールに割り当てて完成までのロードマップを作るためである。そしてこのとき、切り分けられたパーツが「ユーザー視点凝集」を満たしていれば、パーツ単体でユーザーの反応を確かめる事が出来る。

タスクを、それぞれ何らかのユーザー価値を生み出す「スモールバッチ(small batch)」に分ける事によって、ウォーターフォール開発のようないわゆる「ラージバッチ(large batch)」なアプローチよりも遥かに早い段階から継続的なフィードバックを得る、というのがアジャイル開発の勘所だった。

インクリメンタル開発(漸増型)とイテレーティブ開発(反復型)

ユーザー視点凝集ごとにシステムを区切る事を「vertical slice(縦方向の分割)」と呼ぶ、というのが前回の話だったが、vertical slice ごとにシステムを作り上げて行く手法は「インクリメンタル(incremental)開発」と呼ばれている。

これはアジャイル以前に開発プロセスの標準的な存在だった RUP(Rational Unified Process)や UP(Unified Process)に含まれていた手法である。これらのプロセスモデルが提唱された90年代後半は、ウォーターフォールを捨ててアジャイルを生み出すまでのちょうど過渡期に当たり、ソフトウェア開発に一発勝負のウォーターフォールは馴染まないという反省から、RUP や UP と言った「繰り返し型」開発プロセスが提唱されるようになった。

インクリメンタル開発は、新規の増分(開発部分)を積み上げていく方法です。この方法は、繰り返しの単位となるN回目、N+1回目で対象となるソフトウェア構造がまったく異なるものや、依存関係のないものに適しており、繰り返しの単位の独立性が保てるので非常に分かりやすいというメリットがあります。もし、N回目、N+1回目の中に、共通するソフトウェア構造が含まれていた場合は、共通部分を別々に開発してしまうことになり、ソフトウェアの保守性に問題が出ます。

この記事の中で紹介されているように、インクリメンタル開発は繰り返し型開発の中の一手法に過ぎない。繰り返し型開発で重要なもう一つの手法は「イテレーティブ(iterative)開発」である。

イテレーティブ開発は、ソフトウェアの全体、あるいは部分について、最初は薄く作り、少しずつ肉付けしていく方法です。この方法は、非常に重要かつ複雑なソフトウェアの個所について、徐々に確認しながら肉付けし、中身を濃くしていけるというメリットがあります。

つまり、イテレーティブ開発は、システムを区切るのではなく、同じユーザー視点凝集(のセット)の完成度を段階的に高めて行く手法だ。

RUP や UP には「ユースケース・ドリブン」と「アーキテクチャ・セントリック」という二大ポリシーがあり、それぞれのポリシーがインクリメンタル開発とイテレーティブ開発に対応している。ユースケース・ドリブンでは、ユースケースという vertical slice ごとに開発を進め、アーキテクチャ・セントリックでは、段階を踏んで全体のアーキテクチャを洗練して行く。この二つのポリシーを組み合わせて、インクリメンタルとイテレーティブのバランスを巧く取りながら開発を進めて行くというのが RUP や UP の要諦である。

考え方としては、今改めて検討しても合理的に思える部分も多いが、CI(Continuous Integration)がまだ一般的でなかった当時、繰り返しのたびにテストをやり直さなければならないという問題や、その他自動化が十分でないためにかかるオーバーヘッドなどを考えると、まだ現実的と言える手法ではなかったのではないかと想像出来る。さらに最も重大だと思われるのは、vertical slice ごとのリリースという考え方がないためにアジャイルのようなフィードバックループを得られず、ユーザー(顧客)視点からはウォーターフォールと何ら変わりのない手法に見えることだ。

「イテレーティブ」の再発見

一つ一つの vertical slice を順番にリリースして、早い段階から「本番」を経験させるのがアジャイルの勘所であると説明したが、このような繰り返しをアジャイルでは「イテレーション」と呼ぶ事が多い。しかし、実際にこの繰り返しが意図するところは「インクリメンタル」な開発である。

アジャイルがインクリメンタル開発にフォーカスしていることを典型的に示すのが、スクラム手法で頻繁に参照される「雪だるまモデル(Snowman model)」だ。

scrum-snowman-model

このように、一つのイテレーション(スクラムでは「スプリント」と呼ぶ)が終わる度に「出荷可能(shippable)」な vertical slice が積み上がって行くイメージである。ユーザーは早い段階で製品に触れて開発者にフィードバックを送る事が可能になり、管理者にとっては、開発のペースが安定して進捗も可視化されるなど、良いこと尽くめのように思える。

しかし、2007年にロンドンで行われた XPDay において、「インクリメンタル開発へのこだわりには大きな落とし穴がある」そう指摘したのが Jeff Patton 氏だった。

Patton氏はインクリメンタルにモナ・リザを描くとしたらどうなるかという例を挙げて、仮にインクリメンタルだけで開発を進めようとすれば、結局は最初の段階で全体像を決めておかなければならず、また全てのパーツを完成させない限り全体像の実物を検証する事も出来ないため、結果的にはウォーターフォールと同じ事になると警告した。

Jeff Patton氏のサイトより
Jeff Patton氏のサイトより

インクリメンタルなプロセスとは対照的に、普通に絵を描く時は以下のようなイテレーティブなプロセスを辿る。

Jeff Patton氏のサイトより
Jeff Patton氏のサイトより

全体像をぼんやりと決めてから徐々に細部を詰めて行く。細部を詰めて行く過程で全体像を調整して行くので、最初に完璧な構想を立てる必要はない。

アジャイル時代になって、インクリメンタル開発がイテレーションと呼ばれるようになり、それまでイテレーションと呼ばれていたコンセプトが抜け落ちてしまったというのが Patton氏の指摘だ。

出荷可能(shippable)とは何か?

インクリメンタル開発の落とし穴は、先ほどの雪だるまモデルで登場した「出荷可能(shippable)」という考え方である。

仮にシステムを vertical slice に分けて開発し、イテレーションの度にリリース出来たとして、それらのパーツの集積が本当に出荷可能だと言えるだろうか?

ほとんどの場合、答えは「ノー」である。

出荷可能の本当の意味は、顧客にとって意味のあるプロダクトである、という当たり前の事実だ。そのプロダクトを使って実際の業務を遂行出来る、あるいはサービスや売り物として成立するなど。そのように考えると、多くのケースで vertical slice はこの水準に相当しないだろう。筆者も何度か経験しているが、 vertical slice に分けて開発したとしても、ある程度全体像が完成してこない限り、顧客、あるいはそれに準ずる役割の人たちは、作りかけの製品には興味を示さなかった。

何故このようなズレが生じるのかと言えば、それはおそらく vertical slice の粒度が開発者視点で決定されているからではないだろうか。顧客に決めてもらうとは言っても、そのフレームワークはそもそも開発者側が考えたものだ。つまり、このときの vertical slice はユーザー視点凝集ではない、ということになる。

元々、開発者視点でシステムを区切る「horizontal slice(横方向の分割)」は好ましくないということで、ユーザー視点であるはずの「vertical slice(縦方向の分割)」を持ち込んだ訳だが、そこでも開発者視点を払拭する事は出来なかったということになる。

インクリメンタルとイテレーティブをミックスする

インクリメンタル開発の落とし穴を避けるためには、アジャイル以前の RUP や UP で提案されていたのと同じように、インクリメンタルとイテレーティブを巧く組み合わせようという話になる(実際には意識せずともそうならざるを得ないが)。そのための手法として、ユーザーストーリーをフィーチャーごとに書くだけでなく、一つのフィーチャーをイテレーティブに発展させるためにストーリーを三枚のカードに分けて書くという方法が提案されている。

この方法によって、一度の開発でフィーチャーを完璧(出荷可能)に仕上げなければならないという、インクリメンタル開発のプレッシャーから解放される。

ユーザー視点凝集をそれぞれ同じ完成度で比較すると粒度がまちまちになってしまい、アジャイルが目指す、ペースを維持した開発を実現することが難しくなってしまう。そこで、ユーザー視点凝集の抽象度(曖昧さ)を調節して、一回のイテレーションに収まるサイズに縮めるというのが、イテレーティブ手法が果たす役割である。

スコープ

アジャイルにおけるインクリメンタル開発の落とし穴と、それを回避するためのインクリメンタル/イテレーティブの組み合わせ、なかなかに説得力のある話ではあるが、一つ重大な点が見過ごされているような気もしなくはない。それはスコープと呼ばれる、全体像の問題である。

イテレーティブの導入によって、詳細な全体像を用意する必要は無くなったかもしれないが、それでも依然として全体像は必要になる。アジャイルやリーンの考え方として出来るだけ多くの意思決定を先送りにするとしても、全体像はある程度決定しておかなければならない。しかし、この全体像がちょっと油断するとチームをウォーターフォールへと引きずり込むアリ地獄のような存在になってしまう。

果たしてこの全体像というのは、どのように決定すれば良いのだろうか?

(続く)

受託開発でアジャイルというのはほとんど語義矛盾ではないだろうか

ここ最近、立て続けにアジャイル絡みの事を書きながらこぼれ落ちた考えをここに書き留めておく。

筆者にとってアジャイルというのは、かなりの程度、個人的な問題だということはまず認めておかなければならない。

個人的だと思う背景には、(自分にとっての)アジャイルというものを、それを知らない人に伝達する事の難しさをつくづく痛感しているからである。

アジャイルはそもそも道具ではない。すでに書いたように、アジャイルというのは価値観であるし、もっと言えば文化だと言っても差し支えないだろう。

人間の集団の中で理屈抜きで共有出来る何らかの価値観があれば、それを文化と呼ぶ。

例えば、一つの組織の中で、ある事が組織の利益になるから同意するというのは、基本的に契約の問題であって文化ではない。つまり、組織にとって利益になるからアジャイルを導入しようという(ベタな)言明はそもそも成り立たない。

アジャイルが結果的に組織にとって利益になるという事は当然あり得るが、利益になるからやるという順番だとそれはもはやアジャイルではない(それが「道具ではない」ということの意味だ)。このようなジレンマが文化というものには必ず付いて回る。

文化を築くのには気が遠くなるほどの時間と幸運が必要になるが壊れるのは一瞬である。特に営利組織の中で働いていて、その利益以外の事で価値観を共有するというのは基本的に至難の業である。

アジャイルはもう終わったという話が度々出てくるが、そのほとんどはハイプ・サイクル絡みの話だった。そもそも無理筋なことをやろうとしていた、というだけのことではないだろうか。

アジャイルはそもそも「無理」から出発した方が良いのだろう。

アジャイルはソフトウェア開発にクリエイションを持ち込もうとしたが、ほとんどの現場ではそんなものを求めていなかった。

日本ではソフトウェア開発の多くが受託開発だと言われている。

受託開発というものがそもそも「アイデアを他者によって実現してもらう」という考えで成り立っている以上、開発側にクリエイション(アイデアをいかに発見するか)が入り込む余地がない。

文化という側面で言えば、人に頼まれて何かをやるという仕事の方式そのものが減点ベースの評価にならざるを得ず、アジャイルとそもそも相容れないと言う事も出来る。

これは受託開発だったらウォーターフォールという選択の問題ではない。人に頼まれて何かをやるときは「交渉」が最重要事案になるというだけだ。

自分達で発見したものを世に問うという仕事に就きたいというのは完全に価値観の問題であって、多くの人にとっては「人に頼まれて何かをやる」のがそもそも仕事の定義であり、その上で生活が成り立っている。社会全体としては価値を生み出していなくても「交渉」によってお金を回す事は出来る(それが持続可能なのかは別にして)。

アジャイル最大の難点は、当たり前だが、そこで価値の発見が保証されているわけではないというところだろうか。以前、スティーヴン・キング氏の自伝「On Writing: A Memoir of the Craft」を紹介したが、それを読めば誰もが小説が書けるわけではないのと同じように。

何が見つかるか分からない状況で旅に出ることをこの上ない喜びと感じるか、そんな博打を打っていたら生活が成り立たないと嘆くか、そこが文化の分かれ道かもしれない。

アジャイルはプログラマーに万能を求める。

アジャイルの問題意識がそもそも役割の分断にあるので、必然的に分断された役割を小さな範囲に集約していくことになる。そこを突き詰めると、それは単にフルスタックエンジニアになるというレベルを超えて、各人が自律したマーケターになることも要求されるようになる。

興味深い事に、これはマーケティング分野の側でも同じような事が言われているようだ。

アジャイルにおいて創造のエンジンを担っているのはプログラマーの側である。その外側にいてアイデアや舵取りの責任を持つ人間の存在はアジャイルにとっては単なる非効率に過ぎない。技術がイノベーションの源泉になっている、あるいはそのような組織を目指しているのなら尚更、外側の人間がアジャイルのエンジンに噛み合って仕事ができるという幻想を捨てなければならない。

しかし、冷静に考えてみよう。こんなことが可能な環境や組織が果たしてどのぐらい存在するだろうか? あるいはそれこそがクリエーションの希少性と呼べるものなのかもしれないが。

ユーザー視点凝集をめぐる冒険 (1) – どのようにシステムを切るか?

凝集性というのは、どのような尺度でプログラムを分けるかという問題だ。凝集度は高い方が良いと言っても、この高い・低いという判断は一筋縄で行くものではない。というのは、どのような尺度を利用するかによって、ある視点からは凝集度が高くなるように見えても、別の視点からは凝集度が低く見えてしまうからである。

以前、連載記事『TDD再考』の中で、凝集性の分類として「論理的凝集」と「機能的凝集」というものがあるということを紹介した。論理的凝集は実装上の特徴でまとまりを作り、機能的凝集は(プログラムの利用者から見た)機能の単位でまとまりを作る。つまり、これらの尺度の違いは、それぞれのまとまりの受益者が異なる事に由来する。前者は開発者の視点であり、後者はユーザーの視点だ。

わざわざ「(プログラムの利用者から見た)機能」と前置きのあるところから分かるように、「機能」という概念がそもそも視点を前提としていることに注意して欲しい。機能というのは受益者がいて初めて成り立つ概念である。機能的凝集がユーザーから見た機能に対応する一方、論理的凝集は開発者から見た機能に対応するという意味では、いずれも「機能的凝集」と呼んでも差し支えないはずなのだ。分けるという行為を実際に根拠づけるのは視点であり、そのように考えると、凝集性の分類でより適切なのは視点による分類ではないだろうかと思う。というわけで、ここでは機能的凝集を「ユーザー視点凝集」、論理的凝集を「開発者視点凝集」と呼んでみる事にしたい。

coherence

プログラムデザインの手法としてレイヤーアーキテクチャが人気なのは、レイヤーが開発者視点凝集、つまりプログラマーから見た凝集性を実現しているからだと言っても良いのかもしれない。データアクセスの処理や、ユーザーからのリクエストを各々のロジックに振り分ける処理など、ユーザーにとってはブラックボックスの中身の話であるが、プログラマーにとっては日常である。

『TDD再考』では、Ruby on Rails 開発者の David Heinemeier Hansson 氏が——先ほど導入した言葉を使って説明すれば——開発者視点凝集よりもユーザー視点凝集を重視すべきだという主張を展開していることを紹介した。TDDのような手法を使ってプログラムをデザインすると、ミクロなレベルではどうしても開発者視点に引っ張られて、結果的にユーザー視点凝集よりも開発者視点凝集を優先してしまうというのがDHH氏によるTDD批判の要点である。

21世紀に入ってからユーザー視点凝集はプログラムデザインおいて極めて重要な地位を占めている。ひょっとしたら最も重要な概念だと言っても間違いではないのかもしれない。それはユーザー視点凝集がアジャイル開発を進める際の単位として想定されているからである。

アジャイル界隈では、ユーザー視点凝集を「vertical slice(縦方向の分割)」と呼んでいる。

この vertical slice についての分かりやすい説明が、最近話題の書籍『SOFT SKILLS』の著者、John Sonmez 氏のサイト「Simple Programmer」にあった。

Sonmez氏は vertical slice を「家を建てる」という例で説明している。

普通に家を建てる時の手順を想像してみよう。まず最初に作らなければならないのは土台である。基礎工事で土台を作り、そこに骨組みを乗せる。その後、骨組みに沿って壁を作り、最後に屋根を乗せる。この最後のステップが完了して初めて実際の家の中身を確認する事が出来るようになる。

このように普通の家屋建築で現れる手順は「horizontal slice(横方向の分割)」に基づいて作業が分かれている。

house-horizontal

この horizontal slice に対して、vertical slice で家を建てるというのは、まず一つの部屋を利用出来るような形で完成させ、その次にまた別の部屋を作るという感じで、人間が実際に利用出来る最小単位ごとに建物を作っていくことに相当する。

house-vertical

部屋ごとに家を建てるのは、建築においてはいささか非現実的なアプローチに見えるが、ソフトウェア開発においては重要な考え方になりつつある。

そもそもソフトウェア開発でも、この家屋建築の例と同じように horizontal slice に基づいた開発が主流だった。それは作業を縦に分割するよりも横に分割する方が遥かに簡単だからである。しかし、horizontal slice は一つ一つのスライスがシステム全体に渡るため、最初に全体の設計図を書かなければならない。更には、一つ一つのスライス(レイヤー)を合体して完成品とする最終段階で想定と異なる事実が判明しても、そこから大幅な変更をするためには大きなコストがかかってしまう。変化の速いソフトウェアの世界では horizontal slice による開発ではなく、vertical slice によって、出来るだけ早い段階で機能の検証を行うべきだというのがアジャイル開発の考え方であった。

A vertical slice from the components of a project
A vertical slice from the components of a project

しかし、この「家を建てる」例での説明は、若干ミスリードな部分もあるかもしれないなと思う。というのは、家の場合は例外なくまず先に設計書があって、それに従って現場の大工さんが家を建てる流れになるが、ソフトウェア開発、あるいはプログラミングは、大工さんの作業というよりも、設計書を作る方に相当するのではないかと思うからである。その意味で、家屋やその他の建築物の設計書を作るプロセスはソフトウェア開発と変わりない試行錯誤があるはずである。

ユーザー視点凝集をめぐる冒険 (2) – 継続的なリリースという罠

#noprojects: もう「プロジェクト」というアプローチでは価値を生み出せない

ちょっと前に InfoQ から「#noprojects」という電子書籍が出ていた。

cover-noprojects-emag

この書籍には、それぞれ別の論者によって書かれた6つの記事が掲載されている。「No projects」というそのタイトルの通り、これまで当たり前のように採用されて来た「プロジェクト」というアプローチは既に有効ではない、というのがこれらの記事に共通する主張である。

一見、過激で論争を呼びそうな主張であるが、内容を仔細に検討してみると、アジャイルというものを追求して行けば自然にこの形に到達するだろうなと腑に落ちる内容だった。アイデアとしては、アジャイルがより多くの領域に援用されるきっかけとなった、リーン、あるいはリーン・スタートアップや、このゆびてくでも紹介したインパクトマッピングなどのアイデアをミックスしてより一般的な形で展開させたものである。

そもそも「プロジェクト」とは何だろうか?

プロジェクトには始まりと終わりがある。プロジェクトはあるタイミングで開始されて、そして終了するタイミングは予め決定されている(実際にその通り終了するかどうかは別にして)。プロジェクトの最大の目的は「プロジェクトを終了させる」ことである。プロジェクトには固定の期間と人員、そしてそれに合わせた固定の予算、そして固定のアウトプットが想定されている。つまり、プロジェクトとは、予算を持ってそれを計画する人の都合に合わせる事を目的にしたアプローチなのである。言って見れば、予算と青写真を入れてボタンを押せば、決まった期日にアウトプットが出てくる魔法の箱である。

そんな魔法の箱は存在しない、そして、たとえ青写真通りのアウトプットが出てきたとしても、その時にはすっかり価値がなくなっている、というのが #noprojects の主張である。

プロジェクトというのは、ウォータフォール型開発の最後の遺産だと言えるかもしれない。これまでその存在があまりにも自明過ぎたためにアジャイルの時代になっても生き延びてきた。しかし、アジャイルでは既に、どの段階でもプロダクトをリリース出来るという継続的デリバリー(Continuous Delivery)が普及しつつあり、そのような現場においてプロジェクトというアプローチは形骸化しつつある。

最初に計画を行い、そしてその通りに物事が進んで、予定の期日にものが出来上がってくるという想定は間違っている、必ず想定外の事象が発生して変更を迫られることになるのだから、予め変更に強い体制を整えておかなければならない、というのがアジャイルの考え方であり、自然に #noprojects に繋がるものであるが、実際には多くの管理者がガントチャートを作りたがるし、物事が想定通り進まないのはどこかに原因があって、それを個別に対処して行けばプロジェクトを元のレールに乗せる事が出来ると信じている。頭の中では変化を想定しなければと思う反面、行動としてはどうしてもウォータフォールの影を引きずってしまう。プロジェクトという形態を取る限り、失敗の原因を計画に求める他なく、故により多くの事を予め想定しておこうという考えから脱する事ができない。

あるいは「変化に対応しよう」というアジャイルのスローガンに問題があるのかもしれない。変化があるかないかで言えば、変化がなく想定通りに進むプロジェクトだってあるだろうと主張する人も出てくる。よって、アジャイルかウォータフォールなのかは適材適所なのだという主張も成り立つ。しかし、本当の問題はそこにはない。ソフトウェア開発が開発の中途で想定外の変化を遂げるのは、その中でより価値のあるものを「発見」しようとするからである。ほら、想定通り物事が進んだじゃないか、そういうことだってあるんだ、と言っても、そのようにして出てきたものには既に価値はない、というのがソフトウェアの世界である。よって、スローガンとしては「発見を主眼におかないソフトウェア開発にはもはや価値を産み出せない」と言った方が良いのかもしれない。

継続性

プロジェクトに代わって、新たなモデルとして提案されているのが「継続的な変更の流れ(Continuous stream of change)」あるいは「流れ作業生産(Flow production)」と呼ばれるものだ。「流れ作業」というと、アジャイルが目の敵にしていたテイラリズムを想像してしまうが、ここでのフォーカスは顧客価値に基づく小さな変更を継続的に行うことにある。リーンの「かんばん」などはこのモデルに近い。

そして、ここでのキーワードは「継続性」である。プロジェクトは基本的に large-batch なアプローチであり、リスクも高いしオーバーヘッドコストも馬鹿にならない。これまではプロダクト(アウトプット)ごとにプロジェクトを組むのが一般的であったが、この方法だと新しいプロダクトを計画する度にチームを編成してプロジェクトを立ち上げなければならない。同じプロダクトでもバージョンアップや改修があるときに別のプロジェクトを立ち上げるのはよく見かける光景だ。#noprojects が提案するのは、アウトプットではなく「成果(Outcome)」にコミットするチームを編成し、その成果を実現するために継続的な変更をリリースしていくモデルである。成果とは、組織にとってどのぐらいの「価値(Value)」があるかという尺度で評価される何らかの「変化(Change)」のことだ。

このようなモデルにおいて、プロジェクトに代わって重要な存在になるのは「チーム」である。チームは結果的な価値にコミットするため、同じチームが複数のプロダクトに関わることは自然なことであり、そこに継続性が生まれる。このようなチームを「価値提供チーム(Value-delivery team)」と呼ぶ。これまでのプロジェクトモデルの問題は、プロジェクトごとにチームが編成・解散されることが多く、せっかく蓄積した知識やノウハウの連続性がそこで失われる事であった。

これまでのプロダクトにフォーカスするプロジェクトベースの開発では、開発者、営業、マーケティング、サポートといった、組織内の機能ごとにチームを分けるのが一般的だった。そして、このように役割で組織が分断されるという問題が、このゆびてくでも繰り返し取り上げてきた、アジャイルやDevOps、インパクトマッピングといった考え方が繰り返し指摘する、現代のソフトウェア開発における最大の障害なのである。チームが価値にコミットするためには、そのために必要な全ての機能をチームの中に備えておかなければならない。これを「機能横断型チーム(Cross-functional team)」と呼び、たとえれば、チームがミニチュアなベンチャー企業となるようなイメージである。実際に、#noprojects の記事の中では、ベンチャーキャピタルの組織内バージョンだと指摘されている。

このような機能横断型チームが、小さなサイクルで実験と学習を繰り返しながら価値を発見しようと継続的な努力を続ける、これが #noprojects が提案するソフトウェア開発のあり方である。

#noprojectsの重要なコンセプト

#noprojects では、その手法を構成する重要な要素として、以下の5つのコンセプトを挙げている:

  • 価値(Value)
  • 成果(Outcome)
  • アクティビティ(Activity)
  • ルール(Principle)
  • 継続的デリバリー(Continuous delivery)

チームは「成果」を生み出すために「ルール」に基づいて「アクティビティ」に従事し、その「成果」は「価値」によって測定される。そして、その継続性とサイクルの短さは「継続的デリバリー」によって担保される。

価値(Value)

価値というのはなかなかに厄介な概念である。ほとんど「主観」と同義だと言っていいぐらいに不確かなものであるし、多くの賢人が指摘しているように、数字に置き換えて理解しようとすると途端に落とし穴にハマる危険性が高くなる。#noprojects では、その不確かさはそもそもビジネスをする際には付き物であり、そこが正確に予測出来るのであればマーケットも簡単に予測可能になるはずだが実際にはそうなっていないと、価値問題に深入りする事は避けている。しかしながら、組織が成功するかどうかのファクターのほとんどはこの価値に関わっていて、仮に #noprojects を実現したとしても、それは単にスタート地点に立っただけに過ぎない。

この価値の問題については、以前「我々は何のためにソフトウェアを開発するのか?」という記事の中でも取り上げた。その中で、Ron Jeffries氏による価値の定義「Value is what you want(価値とはあなたが欲しいもの)」を紹介した。価値を突き詰めれば、経済の問題だと考える人も多いだろうし、あるいは文学の問題だと思う人もいるかもしれない。

#noprojects によれば、一度成果として実現された価値というものは、変更を継続しなければ、時間が経つにつれて減衰していくと言う。これが、プロジェクトモデルに代えて継続的手法を取るべきだという主張の直接的な根拠になっている。

成果(Outcome)

成果とは、具体的なプロダクトやアウトプットではなく、価値によって計測可能な変化の集積である。このように表現するとなかなかイメージを掴みづらいが、記事の中では「アクティブユーザーの獲得」や「スタッフ満足度の向上」などが例として挙げられている。

Agile India 2016 - Leadership Day Summary より
Agile India 2016 – Leadership Day Summary より

この「成果」は、以前ゆびてくで紹介したインパクトマッピングの「ゴール(Why?)」に相当する。つまり、インパクトマッピングを利用すれば、成果を実現するためにはどのようなアクティビティを行えば良いかを考える際の助けになるし、かつチーム内での情報共有においても効果的である。

map

im_example

アクティビティ(Activity)

アクティビティとは、成果を生むための必要な個別のタスクのことである。#noprojects では、個々のアクティビティを事前に評価するための手法として「アクティビティ・キャンバス(Activity canvas)」というものを提案している。以下のように、アクティビティにかかる手間をX軸、実現できる価値をY軸とするキャンバスを用意し、そこに個々のアクティビティをマッピングして行く。

Agile India 2016 - Leadership Day Summary より
Agile India 2016 – Leadership Day Summary より

上のようにアクティビティをマッピングして行くと、どのような順番でアクティビティを実施したら良いかという優先順位が自然に現れてくる。#noprojects に限らず、アジャイルで重要なのは、タスクを「高」「中」「低」のような役に立たない優先順位に分ける事ではなく、実施の順序を決めることである(次に何をやればよいか?)。タスクを順序付けることによって同時並行で処理するタスクの数を減らせば、チーム全体のスループットを向上させることができる。

ルール(Principle)

アクティビティの実施方法は完全に自由というわけではなく、多少をコストをかけてでも若干のルールを作っておくことによって、アクティビティとプロセス全体の親和性、あるいはアウトプットの品質を保つ。アジャイルで言えばプラクティスに相当するが、プログラミング、コミュニケーション、セキュリティ、ブランディングなど、共有するルールはプラクティスよりも多岐に渡る。ルールでチームを縛るというよりも、最低限守らなければならない作法を明確にしておくことによって、その他はメンバーの裁量に任せるという意味合いが強い。

ルールの導入にはコストがかかるため、「MoSCoW」という優先度割当の方法が紹介されている。MoSCoWではルールごとに以下の4つのカテゴリーから選んで優先順位を割り当てる。

  • M (Must have) – 必ず従わなければならない
  • S (Should have) – 正当な理由がない限りは従う
  • C (Could have) – 個人の裁量に任せる
  • W (Won’t have) – 出来るだけ避けるべき

継続的デリバリー(Continuous delivery)

#noprojects のような考え方が提唱されたり、あるいは現実的になってきたのは、インフラ技術の進歩によって継続的なデリバリーが実現出来るようになってきたからだと言っても過言ではないだろう。継続的デリバリーを、アジャイル以後のDevOps時代に生み出された最も重要な技術的達成だと位置付ける人も多く、より具体的で分かりやすい継続的デリバリーという考え方をアジャイルの後継とすべきだという主張も見かけた。

まとめ

以上、#noprojects の考え方を概観してみた。

プロジェクトは計画の別名だと言ってもよく、計画を軸にビジネスを進めると本当に重要な価値の追求よりも計画の履行を優先してしまうことになる。#noprojects の問題意識をひと言で言えば、そんな感じになるだろうか。計画・施行のモデルは、同じようなプロダクトを作り続ける事に意味があった20世紀型のビジネスモデルであり、21世紀の今では発見的な手法に移行しなければ新たな価値を生み出す事は出来ない。その意味で、本来は技術者よりも、経営者やマネジメントがアジャイルや #noprojects のような手法を理解しなければならないはずである。しかしながら、マネジメントの利害を考えると #noprojects が世の中の大勢を占めるトップダウン型の企業に浸透するとは到底思えない。これまでプロジェクトマネジャーが担当していた責任をチームに委任することになり、マネジメントの役割は大きく変わる事になるからである。

ビジョンを曇らせる誘惑: 技術偏重、一貫性

James Hague (@dadgumjames) 氏は、少年時代に一世を風靡した『パックマン』などのゲームに影響を受けてプログラミングを始めた。高校時代にはコンピュータ雑誌の常連投稿者として活躍、大学卒業後もゲームプログラマーとしてSNES(海外版のスーパーファミコン)向けのゲームを開発した。当時はアセンブリ言語で開発していた彼も、次第にマンネリを感じて高級言語を物色し始め、丁度その頃オープンソース化された Erlang で関数型プログラミングの門戸を叩いて今に至る。

パックマン from Wikipedia

そのようなキャリアを持つ彼が、長らくプログラマとして活動する内に気がついた事があると言う。それは、いつの頃からか新しいアプリケーションをデザインする時には、技術的・実装的な見地から逆算的に物事を考えるようになり、ユーザーやプレイヤーの観点から完成品を想定することが少なくなっていたということだった。

技術者は長くその専門領域に棲息するうちに、その領域の尺度だけで物事の良し悪しを判断するようになる。技術者のコミュニティでは、そのような尺度の元に序列付けが行われて、個々の技術者にプレッシャーを与え続ける。その結果として、何のためにそのアプリケーションを開発するのかということは脇に置かれ、パフォーマンスやプログラムデザインのような技術的達成が優先的に考慮されるようになる。

Hague 氏がプログラミングを始めた頃、プログラミングは彼のビジョンを実現するための道具に過ぎなかった。しかしそれが、プログラミング自体にのめり込むにつれて次第に自己目的化してしまった。そのねじれを解消するために、もう一度原点に戻ろうという思いがこの The Recovering Programmer というタイトルに込められている。

前回の記事「TDD再考 (8) – 凝集性(cohesion)とは何なのか?」で紹介した論理的凝集と機能的凝集の対立もこの問題と密接に関係している。アプリケーションの目的から考えれば機能的凝集を目指すべきところでも、油断すれば技術偏重に陥り、論理的凝集を優先してしまうことになる。そしてこの問題は Hague 氏だけでなく、このブログでも紹介してきたように、ビジネスと技術の対立を解消すべく現れたアジャイルムーブメントによってもフォーカスされてきた。特にその流れの中で提案されたドメイン駆動設計(Domain-driven design, DDD)は、機能的凝集に集中するための方法論だと考えると分かりやすいかもしれない。

アジャイルが指摘したのは、機能的凝集は動くターゲットであるということであった。それまでのソフトウェア開発で念頭に置かれていたような静止したゴールは存在しない。継続的に効果を得るためには、ユーザーとのインタラクションを重ねて、ユーザーにとって意味のある「文脈」を構築していかなければならない。

デジタルマーケティングの世界で長年活躍してきた Joanna Lord (@JoannaLord) 氏は、ブランドマーケティングの観点から、一貫性への過剰な執着がブランドの機能的凝集(coherence)を損なう要因になり得ると指摘する。

彼女によれば、ブランドの一貫性とは、裏を返せばそのブランドが変化せず、(環境が変わっても)常に同じ体験を提供し続けるときに実現されるものだと言う。コメント欄で指摘されているように、コカコーラのような長い歴史の中でブランドが確立しているようなケースではその一貫性を維持する理由があるが、現代の状況の中で新しいブランドを構築していかなければならない場合、一貫性より機能的凝集を目指さなければ生き残りは難しい。

一貫性というのは分かりやすい価値であるが故に過剰に追求されやすい。そして、一貫性を保とうとすれば、新しいアイデアを試したり、大胆な変更を行う事に対して臆病になってしまう。その結果としてユーザーにとっての価値、つまり機能的凝集が時間とともに失われてしまうことになる。

フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける

つい最近、たまチームでは Git Flow を利用したブランチ管理に移行したばかりだったので、この記事を見かけた時は一瞬ムムッとなったが、実際に読んでみて、なるほどと思える反面、どのようなブランチ管理を導入するかはそのプロジェクトの性格に依る部分も大きいのではないかと感じた。というわけで、今回はブランチ管理とアジャイルの関係、そしてその理想からはやや距離を取ることになったたまチームの現状についてまとめてみたい。

Git Flow による Integration Feature Branching

以下は、Steve Smith氏によるブランチ管理方法の4分類:

これまでたまチームは、Gitのブランチ管理に関しては何も方針を決めておらず(単純に master に push されたものがステージング・本番、双方へのデプロイ可能なバージョンとしてビルドされる)、結果的に Trunk Based Development という、今回の記事で推薦されている、ブランチを極力作らないシンプルな開発モデルになっていたのだが、後述する事情で以下のような Vincent Driessen氏提案のブランチ管理に移行した。

このブランチモデルについては、Driessen氏による図を見てもらうのが一番分かりやすい。

git-model@2x

基本のブランチとして master と develop の二つを用意し、developが開発用の基本ブランチ、masterが本番用のブランチとなる。開発の基本的なフローは、「フィーチャーの開発」と「リリース」の二つが軸となり、それぞれ、

  • フィーチャー
    • フィーチャーブランチを作って、終わったら develop にマージ
  • リリース
    • リリースブランチを作って、終わったら master と develop の双方にマージ
    • masterにマージしたところで、リリースバージョンのタグを付けておく

これらのフローにまつわる git の操作を簡単にしてくれるのが、git-flow というgitコマンドの拡張である。以下のようなコマンドを打つだけで、ブランチの作成から移動・マージまで全部自動でやってくれる。

$ git flow feature start feature_name
... (code and commit)
$ git flow feature finish feature_name

Smith氏は、この Git Flow によるブランチ管理を Integration Feature Branching と呼び、継続的インテグレーションを実現するためには全くお勧め出来ないとしている。

フィーチャーブランチと継続的インテグレーション

フィーチャーブランチと継続的インテグレーションの関係については、2009年に書かれた Martin Fowler氏の記事でより詳細に説明されている。

今回の InfoQ や Fowler氏の記事で説明されているフィーチャーブランチの問題点を一言で言えば、共有ブランチに対する変更の粒度が大きくなるため、マージの際のトラブルが起こりやすくなる、ということになるだろうか。

フィーチャーブランチのメリットは、共有のブランチに影響を与えることなく個々の機能を独立して開発出来ることである。一つ一つの機能がブランチとして分かれることによって、リリース(マージ)する機能をその場で選択する cherry-picking のような運用が可能になる。しかし、独立しているが故に、個々の機能の間のコミュニケーションが不十分になり、いざ共有ブランチでマージしようとした時に、解決の難しい衝突を引き起こす可能性があるとFowler氏は指摘する。

衝突のリスクは開発者に心理的な影響を及ぼす。例えば、自分のフィーチャーブランチで行った変更が、他人のフィーチャーブランチに対して意図せぬ影響を及ぼすのが怖くなり、大胆なリファクタリングがやりづらくなる。これは一つ一つのフィーチャーブランチが大きくなればなるほど顕著になるだろう。

継続的インテグレーションのそもそもの目的は、プログラム全体を頻繁に結合することによって、結合に関する問題の粒度を小さくしようということであった。つまり、フィーチャーブランチの考え方は、そもそも継続的インテグレーションと相容れないということになる。

インクリメンタルな開発を実現するためのコスト

継続的インテグレーションの理想は、全てのコミットがリリース可能な単位になることである。その理想状態の元では、当然のことながらブランチを分けて開発する必要は無くなる。しかし、そのようなインクリメンタル開発を実現するコストは決して低くない。例えば、一つの機能の開発が一つのコミットで完了することはむしろ稀だろう。一つのコミットで終わらない場合、その中途半端に実装された機能を抱えたシステムをどのようにリリースすれば良いのか? その問題に対処するために提案されているのが FeatureToggleBranchByAbstraction と言ったテクニックである。

上のようなテクニックがあったとしても、全てのコミットをリリース可能にするためには、Steve Smith氏も認めているように、かなりの訓練と経験を必要とする。これは以前の記事でも書いたように、システムをそれぞれ完結した vertical slice 単位で開発しなければならないアジャイルの本質的な難しさである。

たまチームの場合

理想的な継続的インテグレーション、さらにはその到達点である継続的デリバリーを実現するためには、いつでもカジュアルに本番を更新できるような体制と環境を整えておかなければならない。それは技術的な面だけではなく、文化的な面でも高いハードルをクリアしておく必要があり、残念ながらたまチームの場合は、まだそこまでのレベルに達しているとは言い難い。カジュアルに本番を更新出来ない場合、つまり本番更新の頻度が比較的少ない場合、ステージングと本番でビルド(ブランチ)を共有しているといろいろと不便なところが出てくる。例えば、どのビルドが本番に上がっているかが分かりづらくなったり、本番に対する Hotfix がやりづらくなったりする。そういった問題に対処するためにステージングと本番でブランチを分けておいた方が良いのではないかという話になり、Git Flow によるブランチ管理を採用するに至った。

フィーチャーブランチについては、現状だと一つのリポジトリは基本的に一人の開発者が担当していることが多いので、それほどこだわらずに開発者個人の裁量に任せる感じで問題ないように思える。しかし、これが複数人で共同開発するようになった場合は、フィーチャーブランチの扱いには十分気をつけなければならないだろう。

アジャイルがうまくいかないのは何故か?(2015年版)

The GROWS Method™

「アジャイルの失敗」という話は、今となっては特に目新しいものでもない。筆者が記憶している限りで古いものだと、2008年に書かれた James Shore氏の「The Decline and Fall of Agile」という記事がある。

「ソフトウェア開発に銀の弾などない」と、あらゆるIT専門書のイントロダクションに断わりが入れてあるのに、未だに「○○を試したけど効果がない」という苦情が後を絶たないのは何故なのだろうか。

今回のブログ記事「The Failure of Agile」を書いた Andrew Hunt氏は、「達人プログラマー」の共著者であり、「アジャイルソフトウェア開発宣言」の発起人17名の中の一人でもある。彼は、7年前の James Shore氏と同じく、アジャイルがうまく行かないのはアジャイルを正しく実践していないからだと指摘する。

具体的にはこういうことである。初心者がアジャイル開発を始めるに当たっては、何かリファレンスになるような書籍やルールを参照するのが普通である。しかし、ほとんどの初心者はルールに従うという最初の段階から先に進む事ができない。アジャイルは参加者に「変化」を求める。既存のルールに問題があれば、そのルールを変えて、自分たちの状況にあったルールを新たに生み出し、そしてそれを継続的に更新していかなければならない。アジャイルを継続的に行うためには、アジャイルの書籍に書かれている事にこだわっていてはいけない、というねじれを乗り越えて行かなければならない。その上、コミュニティの中には正規のプラクティスを実践しているかどうかに執拗にこだわるアジャイルポリスみたいな人たちがいる(cf. TDDポリス)。ますますアジャイル本来の意図からは遠ざかるわけである。

この状況を打開するため、Hunt氏は「GROWS™」という手法を提案している。GROWSは「GRowing Real-World Oriented Working Systems」の略語にもなっており、これは商標として扱われている。誰でも自由に使えるようにしてその本来の意味を歪められてしまったアジャイルの轍を踏まないように、というのが商標にした理由らしい。

GROWS™の詳細は現段階でまだ明らかにされていないが、基本のステップを「実験」と捉えることや、フィードバックに対するエビデンス(証拠)ベースの判断等、かなりリーン・スタートアップに近い手法なのではないかという印象を受けた。

さて、言葉を占有して解釈を限定させようという方法は、本当に良い方法だろうか? 個人的にはそう思えない。オブジェクト指向やアジャイルという考え方は、本質的には、物事のInsight(見識)を提供してくれるものであって、何らかの手順を踏めばプロジェクトがうまく行くといったような処方箋を与えるものではないと思う。もしそれらの考え方が役に立たなかったのであれば、それは単に受け手側の問題である。自分(の状況)には合わなかったと思って次をあたるべきだ。しかしながら現実には、以前の記事で書いたように、ある考え方が流行るとその周辺をコンサルタントやコンサルティング会社が商機を求めて集まってくる。そこで「○○を使ったらお宅のプロジェクトもうまく行きますよ」という具合に喧伝する。その中でことごとく裏切られた期待が炎上を引き起こし、Andy Hunt氏や James Shore氏のようなコミュニティを代表する人たちが火消しに走らなければならなくなる。この風景はソフトウェア開発産業に限らず、セールスマンが存在する限り、あらゆるところで繰り返されているのだろう。

さらに思うのは、アジャイルのような手法が難しい原因は、ほとんど政治的な問題に収斂するのではないかということである。その内容が誰かに歪められたから正しいアジャイルが実践されなくなったというよりも、従来的な組織の中でアジャイルになるというその事自体が根本的な矛盾を孕んでいるのではないか。アジャイル以後にリーン・スタートアップが出てきたのも、このことに関係しているのかもしれない。そもそもスタートアップのようなラディカルな環境でないとアジャイルというのは成立しないのではないか。