InfoQ

InfoQ

News

マイブックマーク

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

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

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

ソフトウェア職人マニフェスト:出撃命令

作者 Mark Levison , 翻訳者 平田 守幸 - (株)永和システムマネジメント 投稿日 2009年3月30日

セクション
プロセス/プラクティス
トピック
Agile in the Enterprise ,
アジャイル技術 ,
Architecture ,
Agile
タグ
Agile Manifesto ,
Coding Standards

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

特集コンテンツ一覧

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 のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。