建築とアジリティ vol.2 『サグラダファミリア』はアジャイル建築か。
前回の建築とアジリティ vol.1では、ソフトウェア業界では当たり前の概念となりつつある『アジャイル』を建築の世界にも応用することで、設計業務の在り方がガラッと変わると同時に、建築そのものの幅もさらに広がるのではないか、と述べた。
今回は、アジャイル原則を建築に取り入れることで体系化される『アジャイル設計』の可能性をさらに考察し、ひとつのスキームとして構築していく上でも、根源にあるアジャイル開発そのものについて、理解を深めていきたいと思う。
◆ アジャイルを理解する。
アジャイルについての理解を深める第一歩はまず、すでに20年以上前に、ソルトレイクシティのソフトウェア開発者の集団によって発表されたアジャイル開発宣言、ならびに、その背後にある12の原則について知ることである。
1. アジャイル開発宣言
2001年。
ソフトウェア開発業界が大規模化し、プロジェクトがますます長期化していくなかで、企業の論理やプロセスと反りが合わないと不満を抱いていたソフトウェア開発者17名が集結した。
そこで提言されたのが、以下に述べる「アジャイル開発宣言」である。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
① INDIVIDUALS and INTERACTIONS over processes and tools
プロセスやツールよりも、個人と対話を。
② WORKING SOFTWARE over documentation.
包括的なドキュメントよりも、動くソフトウェアを。
③ CUSTOMER COLLABORATION over contract negotiation.
契約交渉よりも、顧客との協調を。
④ RESPONDING TO CHANGE over following a plan.
計画に従うことよりも、変化への対応を。
2. アジャイル宣言の背後にある原則
このマニフェストの後には、彼らがソフトウェア開発において重要だと考える12の原則（開発姿勢）のついての文書が付随している。
① 顧客満足を最優先し、ソフトウェアを迅速・継続的に提供する。
②開発後期であっても変更を歓迎し、クライアントの競争力を高める。
③ 動くソフトウェアをできるだけ短い間隔でリリースする。
④ 営業と開発は、プロジェクト内で日々一緒に働くべきである。
⑤ 意欲のある人を集め、良い環境を提供し、最後まで支援する。
⑥ フェイス・トゥ・フェイスで話をし、情報を伝える。
⑦ 動くソフトウェアこそが進捗の尺度である。
⑧ 一定のペースを継続的に維持できる、持続可能な開発プロセスを。
⑨ 技術的卓越性と優れた設計に対する注意を怠らず、機敏に対応。
⑩ ムダなく作るシンプルさが開発の本質である。
⑪ 最良のアーキテクチャは、自己組織的なチームから生まれる。
⑫ チームの効率を定期的に振り返り、やり方を調整する。
本質的な価値を実現するためのスキーム
これらは、従来のウォーターフォール型開発とはだいぶ性質の異なる考え方である。例えば、「開発後期でも変更を歓迎せよ」の原則は、ウォーターフォール型では間違いなく嫌がられる。さらには「動くソフトウェアこそが進捗の尺度」と言ったはいいが、従来のシステム開発においては、要件定義書・詳細設計書・運用マニュアルなどのドキュメントを作成・提出するのは当たり前に踏まれるプロセスであり、仕事が進捗しているというアリバイのひとつでもある。
「アジャイル」は、ソフトウェア開発者が、付加価値のない無駄な作業を減らし、本質的な価値を実現するためのタイムラインを短縮する働き方・サービスのデリバリー方法・マインドセットの提示である。従来の開発プロジェクトが抱える課題に対するソリューションではないことは、きちんと理解しておく必要がある。
◆ アジャイル原則を実現するための土台
特にITの世界では、アジャイルという言葉を知らない人の方が少ないかもしれない。しかし、実際にアジャイルを実践的にデイリープラクティスとして取り入れられている企業は多くない。「アジャイル開発」が理論の域を超えるためには、アジャイルを従来のプロセスの延長として捉えるのではなく、チームの組み方から契約の在り方までの考え方を改め、アジャイル原則を実現するための土台をつくる必要がある。
ここでは、アジャイルを実践レベルにまで落とし込むための、作業管理の代表的なフレームワークである「スクラム開発」を紹介する。
1. スプリント
「スクラム開発」とは、ラグビーのスクラムから由来しており、チームで効率よくプロジェクトを円滑に進めていくためのフレームワークのことを言う。透明性・検査・適応・短期の学習サイクルに基づいて構成され、アジャイル開発の最も重要な特徴である柔軟性や高い自由度を担保しながら計画を進め、確実にバリューをデリバリーすることを可能にする。
このスクラム開発の基準となる考え方が、スプリント。
日本語では「短距離走」を意味するスプリントは、スクラム開発においては、細切れで開発を行うことを意味する。
設計→開発→テスト→改善の1サイクルを1スプリントとし、この単位を繰り返して継続的に開発を行っていく。
2. チームの編成
スクラムを行うチームは、それぞれが単独で生み出したいバリューを定義し、スプリントの計画を立て、各スプリントで設計・開発・テスト・改善を行いながら、通常10日から2週間で設定されたタイムスボックスごとに、バリューをデリバリーする。これを可能にするチームの条件としては：
クロスファンクショナル（機能横断的）であり、チーム単独でバリューを生み出せること。
マネジメントから権限が譲渡されており、自己組織的であること。
の2つがまず挙げられる。
アジャイルチームは、5人～11人程度のメンバーで編成するが、それぞれのチームにはスクラム・マスターとプロダクト・オーナーという2つの専門的な役割が必ず存在する。
① スクラム・マスター
アジャイルチームのセルフマネジメントのコーチングを行う、メンター的位置づけ。各スプリントで実現したいバリューに最大限集中できるように、メンバーの悩みや問題に目を向けながら、進捗を阻害する要因を取り除きやすくすることで支援する。
②プロダクト・オーナー
チームの舵取り。基本的に口出しはせずも、ビジョンやロードマップについての助言を行い、クライアントの立場からメンバーの質問に答え、プロジェクトの意義を明確に提示する。
3. ツール
実際にスプリントのサイクルを繰り返しながらスクラム開発を行っていく際に、どのようなツールが用いられているのか。
① ユーザー・ストーリー
各スプリントごとにデリバーすべきバリューを示すツールの一つ。
基本的には「○○にとして、○○を達成したい。それは、○○だからだ」というテンプレートに沿って作成される。ユーザーストーリは、以下のINVEST原則に従うと書きやすい。
Independent：ストーリーとして独立している。
Negotiable：交渉が行える内容となっている。
Valuable：価値を見出すことができる。
Estimable：見積を取ることが可能である。
Small：小さくまとまっている。
Testable：顧客がテスト（確認）できる。
ちょうどよいユーザーストーリーの大きさは、だいたいマックス２週間で終わるものにすること。２週間以上かかる場合は、それをさらに細分化していく必要がある。
② バックログ
全体のロードマップや目標に照らし合わせて、プロダクト・オーナーがユーザーストーリーを優先順位をつけてリスト化したものが、プロダクト・バックログ。これをもとに、スプリント期間分を抜き出したチームのタスクリスト的役割を担うのが、スプリント・バックログ。
4. 儀式
それぞれのスプリントサイクルにて、以下のようなイベントを行うのも重要である。
① スプリント・プランニング
各スプリントの冒頭にて、今スプリントにおいて、どのようなバリューを届けることができるのか、また、バリューを届けるために必要な作業をどのように成し遂げるかを決定するプロセス。
つまり、スプリント・プランニング段階では、全体ロードマップや目標を照らし合わせながら、優先順位・リソース・期間などを考慮したうえで、プロダクト・バックログからユーザーストーリーを厳選し、実際に行っていく作業項目を決定する。ここで最も重要なのは、今のチームで実装可能であり、期間内に確実にバリュー届けられるような作業量を精密に見積もること。
この見積り方にも、コツがある。
通常の開発においては、経験豊富なリーダー的立ち位置のメンバー一人の主観でその他メンバーの作業量が見積られるケースが多い。これでは、例えば、リーダーが10日でできると見積もった作業をあるメンバーが20日かかってしまった場合の二人の心理はこんな感じだろうか。
リーダー「実装が遅すぎるのでは…？」
担当エンジニア「見積にそもそも無理があるのでは…？」
このようなチームメンバー間の認識のズレを浮き彫りにし、期間内に確実にデリバーできる作業量の見積りの精度を上げるツールが、見積りポーカー。
具体的なやり方は割愛するが、見積ポーカーは簡単にいうと、ユーザーストーリーにそれぞれ対して、チームメンバー全員が、難易度の点数であるストーリーポイントを割り当て、その差異の理由などについて話し合いながら、チーム全体で作業量を見積るプロセスである。興味深いことに、スプリントの回を重ねれば重ねるほど、この見積りの精度が飛躍的に上がる。
② デイリー・スタンドアップ
デイリー・スタンドアップ（DSU）とは、各アジャイルチームのメンバー（開発者）、プロダクト・オーナー、スクラム・マスターが毎日行う最大15分のミーティングである。
- 昨日は何に取り組んだか？
- 今日は何に取り組むのか？
- 障害となっている課題は何か？
の3点についてメンバー全員が1人ずつ、毎日発表することで、進捗を妨げている要因を明確化し、その改善を試みることが主な目的である。
③ スプリント・レトロ
スプリントの最後に、チームとしてうまくいった項目や今後の改善が必要な項目を特定・整理し、課題点を次のスプリントにおいてどのように改善していけるかを計画するプロセス。
◆ サグラダファミリアは、アジャイル建築か。
さて、ここまでアジャイル開発の基本的なことをツラツラと書いてきたが、ここでひとつ疑問が浮かぶ。
アジャイルという概念を建築のなかで最も体現していると言われているアントニオ・ガウディのサグラダファミリアは、実際のところアジャイル建築なのだろうか？
ガウディは、サグラダファミリアの設計図をほとんど残さず亡くなったが、「建物の各部分ごとに聖書の場面・登場人物を割り当て、建物全体で聖書の物語を表現する」という明確なコンセプトを提示していた。このコンセプトを実現するために、多くの建築家・職人・彫刻家たちが今日もなお、分業して作業を進めている。
通常であれば、この大規模な建築を設計図なしに建てるなど考えられないが、プロジェクトメンバー一人ひとりが、「聖書」という根源にある物語を理解し、自ら思考錯誤しながら形にしていくことで、一つの建築物としての価値を作り出している。
例えば、
最終完成イメージを示す設計図書は存在しない。
明確なコンセプトに基づいて、各メンバーがある程度の自立性をもって作業を進めている。
建物が完成する前から一般客にオープンしている。
といった性格を考えると、サグラダファミリアは確かにアジャイルっぽいともいえる。
アジャイル建築がモニュメントの域を超えるためには。
しかし、サグラダファミリアはあくまでもモニュメントである。
クライアントやチームメンバーとのコミュニケーションの重要性や、対応すべき変化の定義も、時代の変化が激しく、ステークホルダーも多い現代における建築設計で必要とされるアジャイル設計手法のケースとは、だいぶ質が異なる。
ゆえに、アジャイル設計がモニュメント建築の域を超えるためにも、ここからさらに一歩踏み入れる必要があり、ここまでで述べてきたアジャイル開発の基本を深く理解し、建築設計プロセスへと落とし込み、アジャイル設計を体系化していきたいと思う。
そもそも、従来のソフトウエア開発手法であるウォーターフォール型は、建築の工程をもとに落とし込まれたスキームである。
だったら、アジャイルが製造業からソフトウェアの標準プラクティスまでに昇華したように、今度は、建築がソフトウエア界隈の「当たり前」をパクれば良いのではないだろうか。