クラフトマンシップと裂け目 - Martin Fowler's Bliki (ja)

Daniel Terhorst-Northのソフトウェアクラフトマンシップに関するブログ記事が多くの議論を引き起こしました（興味のある方のために末尾にまとめました）。論点はいろいろとあるのですが、あるテーマに共感したので、私もこの記事を書くことにしました。

その前に、あることに触れておきたいと思います。私は長い間、ソフトウェア開発におけるメタファーの議論は退屈だと感じています。すでにメタファによる問いかけに書いていますが、ソフトウェアが開発がクラフトなのか、アートなのか、トレードなのか、デザートのトッピングなのかといったことには、基本的に一切興味がありません。

私にとって重要なのは、クラフトマンシップのメタファーではなく、この数年で生まれたムーブメントの特徴です。部外者の私から見ると、ソフトウェアクラフトマンシップのコミュニティの主な原動力は、アジャイルムーブメントの変化に対する反動だと思います。初期のアジャイルの代表的なウィルスはエクストリームプログラミングであり、技術的なプラクティスについて多くのことを語っていました。しかし、現在のアジャイルの代表的なウィルスはスクラムとリーンであり、これらはプログラミングにあまり関心がありません。したがって、自分をプログラマだと思っている人たちは、アジャイルの世界ではもはや重要視されていないと感じるようになったのです。

Dan North (aka tastapod)

ソフトウェアクラフトマンシップの世界では、プログラミングが再び中心的な存在になります。ここでは、テスティング、関数型言語の学習や使用の方法、優れた設計の原則などについて議論することができます。そして、マネジメントや分析に関する話題は、衰退するアジャイルコミュニティに任せればいいのです。私にも共感できるところがあります。私は設計＝スタミナ仮説を受け入れています。これは、ソフトウェアをうまく開発したいのであれば、優れた技術プラクティスに注意を払べきというものです。したがって、クラフトマンシップのようなムーブメントは重要です。しかし、技術的な側面ばかり重視するようになると、顧客とのコミュニケーションという同等に重要な側面が軽視される危険性があります。

Kent Beckの言葉で私が大好きなものがあります。それは、顧客との関係と契約を実行するために必要なスキルの間にバランスがある、というものです。彼はアジャイルマニフェストのミーティングでエクストリームプログラミングの主な目的は「ビジネスと開発の分断を修復すること」だと言っていました。この分断は、Danと私が「運命の裂け目」と呼んでいるものであり、ソフトウェア開発における最も重要な問題です。

この裂け目の大きな原因は、プログラマと顧客は異なる生き物であり、コミュニケーションできない（すべきではない）という考えに基づいた組織の習慣にあります。しかし、多くのプログラマは、裂け目が広がることを喜んでいるようです。数年前、私はEric Evansの観察に感銘を受けました。それは、開発者はシニアになればなるほど、技術的な問題にフォーカスする傾向があり、自分たちが働いているドメインを理解しようとしなくなる、というものです。ドメイン駆動設計はそれを変えようとするものなのですが、リポジトリにおけるDIの使い方のような議論に矮小化されがちです。

（私のキャリアも同じ問題に悩まされてきました。ソフトウェア開発の専門家として成長していくと、私の大好きなドメインモデリングに携わることができなくなっていくのです。）

スクラムやリーンが技術的スキルを軽視して問題を悪化させたように、クラフトマンシップが人間関係のスキルを軽視して裂け目を悪化させるのではないかと危惧しています。私が理想とするプログラマは、プログラミングの技術に長けているだけでなく、ソフトウェアが顧客の仕事を成功に導くための方法を見つけるために、専門家とコミュニケーションをとりながらドメインについて学習できるような人物です。 Danの言葉を借りれば、ソフトウェアをプログラマの世界の中心に置くべきではなく、プログラマはソフトウェアが提供する価値にフォーカスすべきなのです。

関連するブログ記事