Pete McBreen氏は2001年に『Software Craftsmanship:The New Imperative(リンク)』（邦訳：『ソフトウェア職人気質 ― 人を育て、システム開発を成功へと導くための重要キーワード』）を書いた。昨年、Bob Martinおじさんは『Clean Code: A Handbook of Agile Software Craftsmanship(リンク)』を書いた。そして彼はAgile2008の基調講演の中で、アジャイルマニフェストに「クズなコードを書かずにソフトウェア 職人気質を持つこと」を追加して修正することを提案した。
2008年の12月に、シカゴで会合が開催され、ソフトウェア職人マニフェスト(リンク)の草案が生まれた。
ソフトウェア職人を希求する我々は、自ら実践し、そして周囲の人が技術を習得するのを支援することによって、プロとしてのソフトウェア開発のレベルを上げていく。
- ソフトウェアが動作するだけでなく、ソフトウェアをよりよく作ることも重視する。
- 変化に対応するだけでなく、確実に価値を加えることも重視する。
- 個人とその相互作用だけでなく、プロフェッショナルたちのコミュニティも重視する。
- 顧客との共同作業だけでなく、生産的なパートナーシップも重視する。
すなわち、左側に書かれていることを求めるためには、右側に書かれているものが不可欠だと分かった。
© 2009年、文末の署名者。この宣言は、この注記も含めて全文であれば、任意の形式で自由に引用してよい。
Corey Haines氏にとって、このマニフェストを書く重要な理由は、暗がりに光を当てることである (リンク)。
私にとって、1つの重大な目標があります。それは後進者や入門レベルの開発者に、自分で意識できるゴールを提供することです。私は以下のような人たちの数に驚いています。a)私が信じているような技術を使えば成功するということを信じていない人 b)この職人の原則に注目している企業があることを知らない人。
より大きな声をあげて、マニフェストを公表して、原則を確立するために実践的なアイデアを多く集めて、私たちは、新しい開発者にとっての光をつくろうとしています。
Micah Martin氏がマニフェストの作成に参加したのは、ソフトウェア職人の定義に関する(リンク)多くの異なる見解を集めたかったためである。
マニフェスト策定グループのメンバーは鍵となる2つの質問に答えた:「クズなコードの問題を解決するのにどう役立つのか？」「ただ単にコードを大量に生み出すだけの開発者が職人になりたいと思えるモチベーションは何か？」
- それはただ仕事をやっつけで終わらせようとするのか、正しく仕事を進めようとするかによって区別される。
”Paul Pagel氏はその質問が何を言わんとしているのかについて回答した(リンク)。「ソフトウェア開発の敷居を上げることによって、私たちは、開発の標準レベルというものをいまよりも高く設定しようとしています。(マニフェストは)また、原則に加えて、開発者がソフトウェア職人の原則に従うためのロードマップを示すのです」
Micah Martin氏は答えた(リンク):「今日の時点で、マニフェスト上に1500以上の署名があります。1500人もの人が「クズなコード」と戦っています。今「クズなコード」と戦っている彼らは、戦いにおいて孤独でないことを知っています。このマニフェストの存在が「クズなコード」から職人への道をサポートしているのです」
Rik Dryfoos氏が述べた(リンク)。
エンジニアリングマネージャーとして、幅広い意味の「職人の価値」に名前をつけてくれたマニフェストを気に入りました。それは私たちが積極的に促進する価値(そしてプラクティス)や私たちが会社内で育てようとしているものだったからです。マニフェストは、チームに加わることに興味を持っている入門者や、より経験を積んだ開発者へ、私たちの期待を明確にする方法として役立ちます。雇用という名の選択プロセスをサポートします。この職人マニフェストは対話を生み出してくれます。そうした対話を生み出すのに、いままで私たちは苦労していました。
Corey Haines氏は、マニフェストが「コードを大量生産する開発者 (リンク)」に向けられたものではないと考えている。
これは私にとって大きな質問ですが、答えは単純です:仕事をこなすだけの人たちがやる気になることはありません。また、率直に言って、やる気にさせようとするべきではありません。
この種の人たちにとって、外部からモチベーションをあげようとすることが役立たないと私は確信しています。彼らはやり方が既に確立しています。彼らは新しいものを試みません。それは困難なことだし、学習している間は彼らの仕事に負の影響を与えるからです。
私には、このマニフェストを伝えたいと思っている2種類の人がいます:できる限りベストのソフトウェア開発のキャリアを始めたいと思っている新しい開発者;そして、既に熟達しているが、機会があればよりよいソフトウェアを書く方法を習得する機会に飛び付くような人。この人たちだけです。
Mike Bria氏は、ある場合には、私たちが数年もの間失っていたものを見つけなければならないのではないかと考えた(リンク)。かつては存在したが、この数年にわたって打ち砕かれた希望か喜び。彼は、その希望を再燃させる方法を見つけるべきだと提案している。
Heinrich Breedt氏は懐疑的で(リンク)、コードを大量に作り出す開発者は昨日と同じ方法で仕事をすることを望んでいるのではないかと考えている。テストケースを書くことであったり、リファクタリングなどのような新しいものは、特別の負担が増えるように見えてしまうからだ。
Dave Hoover氏は、マニフェスト策定がまだ進行中であることを指摘した。価値は定義された。しかし、アジャイルマニフェストに照らして考えると、原則を支援する細かいプラクティスはこれから加えられるところだ。
最後に、Dave Rooney氏は、プロフェッショナルであろうと努力することの中で(リンク)、私たちは作品に無駄な手を加えてしまうことになるという考えを述べている。恐らく、私たちは自分たちを職業人だと考えてやっていくべきだと思う。Dave氏は、航空整備士(AME)であった義父の経験を参考に以下のように述べている。
ポイントは恐らく、私たちの仕事が、AMEのような職業人的な仕事とあまり変わらないということです。彼らが持っている質に対するコミットはBob Martin氏のクリーンコードリストバンドの概念（訳注：Bob Martin氏が提唱している、きれいなコードを書くことを意識するために持っておくリストバンドのこと）となんら変わりありません。航空整備士(AME)のようなものとして私たち自身を見つめることで、技術としての古いソフトウェア開発を超えて、職業へと向かうことができるかもしれません。
InfoQ上の以前の記事:職人的技能 - 5番目のアジャイルManifestoの価値?(参考記事)、職人気質と職業倫理(参考記事・英語)(Bob Martinおじさんによるプレゼンテーション)、ソフトウェア職人気質を促進する企業のあり方 (参考記事・英語)(Scott Dillman氏によるプレゼンテーション)。
原文はこちらです：http://www.infoq.com/news/2009/03/software_craftsmanship