君はWard Cunninghamを知っているか？（後篇）

Ward Cunninghamは前篇で解説したように、Kent Beckと共にパタン・ランゲージをソフトウェア開発に持ち込み、共同編集環境としてWikiを発明しました。Ward、そしてKentのソフトウェア開発における野心的な試みはまだまだ続きます。

Eiji Ienaga

·

Follow

Published in

時を超えたプログラミングの道

·

10 min read

·

Dec 21, 2016

--

Share

前篇に引き続き、Ward Cunningham（Wardと略） の活動について解説します。前回は、Wikiとパターンについて触れました。今回は、CRCカード、エクストリームプログラミング（XP）、Fit、そして技術的負債について触れます。

Ward CunninghamとKent Beckとの出会い

前編でも触れましたが、ソフトウェア開発の歴史の上で Ward とKent Beck の出会いは大きかったと言ってよいでしょう。

http://wiki.c2.com/?WardAndKent

複数人でカードを使って対話しながら設計する CRCカード

２人は、パターンの他に、Smalltalkの分野でいくつかのライブラリ−を公開し、CRCカードを使った設計アプローチの論文について1989年に公開しました。

CRCカードは、システムが提供するシナリオ実現に必要なオブジェクトやクラスを明らかにするため、クラス-責務-コラボレータをカードに書き出し、カード間のメッセージのやり取りを複数人で対話しながら設計する手法です。

２人がパターンを持ち込んだときと同様にカードを使うことで、技術には明るくないがビジネスに詳しい人も設計行為に参画できるようにセッションを工夫しているのが特徴です。下記の CRCセッションの図を見ると、プログラマやデザイナーのような開発者と、ユーザーやアナリストが同じテーブルに並んでいるのがよくわかります。

後に、Eric Evansは、カードに書き出すアイデアは残っていないものの、ドメイン駆動設計の中で共通の語彙となる「ユビキタス言語」を通じてエンジニア同士だけでなくドメインエキスパートと対話を重ね、ドメインモデルを洗練させ続ける設計行為の大切さを上げています。

Kentが 開発者向けにJUnitをつくる

SmalltakのテスティングフレームワークSUnitは、xUnitの原型でもあり、Kent Beckによって作られました。Kent と Erich Gamma（デザインパターンの著者の１人）は、後にJava用にJUnitを移植し、そのおかげで、多くのプログラマがJUnitを利用するようになりました。xUnitは、多くのプログラミング言語に移植され、多大なインパクトを与えたエンジニア向けのプロダクトと言ってもいいでしょう。

Kentは後に、テストファースト、テスト駆動開発、エクストリームプログラミングを発表します。1999年に書籍で発表したエクストリームプログラミングの個々のプラクティスは、スクラムのコツがまとまったScrumPLoPほど開発のプロセスやプラクティスのパターンとしては明言してません。しかし、XPは、人間性を尊重し、顧客も開発者もソフトウェアづくりに積極的に参画し、適宜フィードバックを得ながら期待と実際のギャップを調整を続け、ボトムアップにピープルもプロセスもプロダクトも漸近的成長を続ける仕組みを特徴としています。これは、建築のパタン・ランゲージの活動の根幹にある原則と類似点が多々あります。詳細は、前回も紹介した書籍「パターン・Wiki・XP」を御覧ください。

近年では、エクストリームプログラミングのプラクティスの１つで紹介された「継続的インテグレーション(CI)」は更に発展を遂げて、継続的デリバリーやDevOpsと形を変えて、頻繁にリリースを繰り返すことで市場の期待とプロダクトの実際のギャップを調整し成長し続けるための、技術的かつ社会的な枠組みとして広がりつつあります。

Wardが複数ロール向けに Fitをつくる

一方、Ward は、 Excelでテストを読み書きし、実行できる「Fit」を公開します。テストを使って、期待と実際のギャップを明確にしてフィードバックを得ることを重視したエクストリームプログラミングですが、xUnitがプログラマ向けのツールなら、Fitは、顧客・テスタ・プログラマなどなど複数のロール向けです。異なるロール同士のコラボレーションの促進を意図した プロダクトがFitで、そのコンセプト説明が私は大好きです。

Great software requires collaboration and communication. Fit is a tool for enhancing collaboration in software development. It’s an invaluable way to collaborate on complicated problems — and get them right — early in development.
（偉大なソフトウェアはコラボレーションとコミュニケーションを必要とします。Fitはソフトウェア開発のコラボレーションを向上させるためのツールです。開発の初期段階において、込み入った問題に向き合い、コラボレーションを「正しく」行うための方法として絶大な価値があります。）

現在、Fitが一般に受け入れられているとは言えませんが、後に Cucumberに代表されるツール、Behavior Driven Development や Specification By Example といった開発の進め方などに大きな影響を与えました。テストや実行可能な仕様の例を使って顧客を含めた複数の役割で共創を実現しようとする考えは、パターンを持ち込んだときと同様でカタチを変えて繰り返し立ち現れています。

技術課題をビジネス層にも分かるように言語化した「技術的負債」

http://wiki.c2.com/?WardExplainsDebtMetaphor

アジャイル界隈でもっとも広まっているメタファの１つがWardが発案した「技術的負債」でしょう。無計画に借金を重ねると、一時的に華やかな生活だったのが、ローン地獄によって指数関数的に借金が膨れ上がり、やがて生活に大きな負担となり返済の目処が立たず大きな痛みを伴います。この生々しい痛みがソフトウェア開発でも似た事象があります。この似た出来事をビジネス側にも分かるように言語化を試みたのが「技術的負債」です。

保守性の低いコードや設計、自動化されていないテストやビルドプロセスなど技術的な課題を積み残すと、後々に事業やサービスの成長の大きな障害物となります。サービスインして順調に会員数などのKPIを伸ばしたものの、エンジニアが疲弊しながら無理して機能修正したら保守が難しい「技術的負債」をふくらませ、やがてユーザの新たな要望に応えるよりも障害対応やバグ対応に追われる日々を迎えます。コアのエンジニアが体調を壊して抜けてしまうと更に事態は悪化します。人を追加しても、ジャングルのようなコードの中身を分かる人がいなく、手を入れれば入れるほど泥沼にハマッてしまいます。

上記の事態に陥らないために予防策や、既にある技術的課題を解消する施策が必要になります。「技術的負債」という言葉は、技術的課題が事業やプロダクトの成長を妨げる技術課題を「ビジネス側」と「エンジニア側」の両者で合意することの大切さを意図しています。

インターネット記事、Slideshare、本を検索すれば「技術的負債」の情報、チームの取り組みを多数発見できるので、一度調べてみることをおすすめします。

余談ですが、「技術的負債」のように、キャッチーで記憶に残り、検索しやすい名前をつけるのはパターンの重要なアクティビティです。

前篇、後篇にわたって、Ward の活動を中心に解説しました。Wiki、パターン、エクストリームプログラミング、CRCカードを使ったオブジェクト指向設計、Fit、技術的負債とWardの影響は多々あります。この記事を通じて、みなさんが行っている普段の開発の活動との地続きを感じとってもらえれば幸いです。