InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

プラグマティックが止まらない ――「現実駆動開発」のススメ

作者 Gavin Terrill , 翻訳者 木下 史彦 - (株)永和システムマネジメント 投稿日 2008年3月13日

セクション
プロセス/プラクティス,
設計/アーキテクチャ
トピック
Delivering Value ,
アジャイル技術 ,
Agile ,
Architecture

ソフトウェアアーキテクトであるGustavo Duarte氏(source)が、物理学者Richard Feynman氏によるスペースシャトル・チャレンジャーの爆発事故に関する調査結果について、優れたソフトウェアの工学的側面との関連を論じたところ(source)、そのことが物議をかもした(source)

    • エンジニアリングはマネジメントと協力しないと機能しない。
    • 前払いの大規模な設計をするのは愚かだ。
    • ソフトウェアは他の工学分野とたくさんの共通点がある。
    •  信頼できるシステムを構築するには、「最高の品質を、という姿勢」でなされた厳しいテストとインクリメンタルでボトムアップのエンジニアリングが必要である。

続けて書いた記事で、Gustavo氏は「現実駆動開発(source)」の考えを紹介して、経験的証拠の考え方について詳しく述べている。

行動と実験は、経験論の基礎です。経験に重きを置く会社では、市場調査に苦しむ代わりに、インターンを雇って、ひと夏の間に製品を開発します(source)。経験を軽視する会社では、43人もの大の大人が1年もかかって、電源オフボタンの設計を計画します(source)

この考え方(進化論から出てきた考え方)は、適者生存の考え方を取り入れている。要するに、なにか試してみて、うまくいったらば残し、そうでなければ捨て去る。Gustavo氏はこう説明する。

よいソフトウェア開発プロセスは実験を最大限に活用し、現実からのフィードバックに磨きをかけるべきです。これが現実駆動開発の意図するところです。そして、ソフトウェアにとってもっとも重要な現実とはユーザ体験と技術的な品質です。しかし一方で、主な実験はソフトウェアとコードを動作させることです。これは「形式モデル(笑)」ではありません。ソフトウェア開発について私が好んで使う単なる例え話です。私は、「現実駆動」という名前を気に入っています。なぜなら、現実について話すときは、ユーザーのことが頭に浮かぶからです。 

このアイデアはアジャイルの中心的な主張や技術のうちいくつかと相通じるところがある。しかしながら、Gustavo氏は(ありがたいことに)新しい方法論を主張しているわけではない。

具体的な現実駆動の方法論というのはありません。アジャイルの原則(source)にはこれらの考えと非常に多くの共通点があります(もちろんアジャイルの原則に影響を受けています)。しかし大切なのは細かい違いです。私は好んで、(状況にあわせて選りすぐった技術でいっぱいの)ツールボックスという観点からソフトウェア工学について考えます。実験を最大限に活用するためのプロセスツールは繰り返し開発(source)、実行可能なアーキテクチャ、継続的インテグレーション、およびユニットテストを含んでいます。

gustavo氏のやり方はユーザと品質に重きを置いている。

このモデルに基づくと、私たちが関心のある2つの現実は、ユーザ体験(ソフトウェアの実用性を含む)と技術的な品質です。ユーザ体験はアジャイルかウォータフォールかに関係なく、軽視されがちです。

Gustavo氏はボトムアップのやり方を改良する話で締めくくります。

  1. 分析よりも実験を好んでください(両者ともそれぞれにいいところがあるのは分かっています)。
  2. 実験を最大限に活用してください。できるだけ早い時期に、手早く、お金をかけずに、大まかに作ってみるのです。ここで分析が役に立ちます。
  3. 精力的に実験してください。
  4. 現実(ユーザ体験と技術的な品質)を評価することについて賢く前向きであってください
  5. フィードバックに反応してください。そして、現実によって駆動してください。
原文はこちらです:http://www.infoq.com/news/2008/02/realitydrivendevelopment

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。