Better SoftwareとAgile Westは、Software Quality Engineering (SQE.com) が同時期に開催したカンファレンスだ。2つのカンファレンスは、ソフトウェア開発の現在のベストプラクティスを試したり、共有したりして、従来のアプローチとアジャイルアプローチの共通の土台を見つける機会を提供する。プログラムをちょっと見たところ、Agile WestにはCMMのトピック、Better SoftwareにはXPのトピックがあり、数多くの共通土台があることを示している。今年のカンファレンスは、ラスベガスのシーザーズパレスで開催され、何人かの主要な実践者たち、著者、プレゼンタたちと話し合い、「2010年のプラクティスの現状」を理解する良い機会となった。InfoQは、以下の人たちに話を聞いた。(アルファベット順)
- DevJamのDavid Hussman氏。
- Atlantic Systems GuildのTim Lister氏。「Adrenaline Junkies and Template Zombies」(アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン)、「Waltzing with Bears」(熊とワルツを - リスクを愉しむプロジェクト管理)、「Peopleware」(ピープルウエア - ヤル気こそプロジェクト成功の鍵)の共著者。
- QSM Associates, Inc.のMichael Mah氏。Cutter ConsortiumのBenchmarking Practiceのディレクタ。
- James Martin氏 (ボブおじさん)。Object Mentorの創立者で社長。「Agile Software Development: Principles, Patterns, and Practices」(アジャイルソフトウェア開発の奥義)など数多くの本の著者、編集者。
- AccelinnovaのPollyanna Pixton氏。「Stand Back and Deliver: Accelerating Business Agility」の共著者。
- Rothman Consulting Group, Inc.のJohanna Rothman氏。「Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects」の著者。
- Industrial Logic, Inc.のシニアコーチであるBill Wake氏。「Refactoring in Ruby」の共著者。
- Wirfs-Brock AssociatesのRebecca Wirfs-Brock氏。「Designing Object-Oriented Software」と「Object Design: Roles, Responsibilities, and Collaborations」(オブジェクトデザイン)の2冊のオブジェクト指向設計の主執筆者。
各人に同じ質問をして、回答をまとめた。
1 ) 現在行われているソフトウェア開発プラクティスで「新しく」て「重要な」ものを3つ挙げてください。(「新しい」というのは、新たに注目されている古いプラクティスでもかまいません。)
Michael Mah氏や他の人たちからテスト駆動開発と自動テストが挙げられた。テストに関して新たに強調する点はなく、ソフトウェア「エンジニア」だと主張する人たちにとって、テストは基本的なものであることを示している。リファクタリングは2位であり、1位との差はわずかであった。しかし、多数の回答者が述べたのは、リファクタリングとリファクタリングブラウザは多くの可能性を提供するが、チームがいつも理想的で必要なだけリファクタリングする時間を与えられるのではないと心配していることだ。他のプラクティスとして、順位が高い順に挙げる。継続的統合 (ウォーターフォールプロジェクトであっても)、作業単位とタイムボックスとしてのユーザストーリー、ストーリーマッピング、ウェブ開発において広く使われる複数言語によるプログラミング、インテンショナルプログラミング、オープンスペース環境、ふりかえり、どのようなプロジェクトであってもアジャイルがふさわしいことを認めること。
何人もの回答者が、紹介すべき新しいプラクティスがあると述べた。このプラクティスでは、別のチームによってビジネス分析とプロジェクトを分け、プロジェクトが始まる前に、ユーザストーリーとプロダクトバックログを適当にまとめている。
総合的に業界全体を見て、今日のソフトウェア開発は、1980年に実施された調査結果と本当に異なっているだろうか?
この質問は興味深いパターンを持つ回答を引き出した。ほとんどの人は最初は変化がないといった。Bob Martin氏は次のように述べた。「ものごとは形が違うだけで中身は同じだ。私たちは、まだIFや割り当て、ループなどを使っている。連結や結合はまだ不可欠であり、その時に学んだことは今日も重要である。」
最初の回答は重要な違いはないというものであったが、たいてい「でも、まだ」という言葉が続いた。例えば以下の通りだ。
- 今日、既存の製品を組み合わせ、注文に合わせて使用できるソフトウェアを作ろうとするソフトウェア産業が実際にある。このため2種類のまったく異なるソフトウェアショップができる。インテグレータや大規模な統合された解決策を持つベンダと、一回限りの製作者だ。
- たいていの人たちが信じているのは、アジャイルが数多くの古いアイデアを一緒にもたらし、それらのアイデアを新しい方法で統合し、ソフトウェアに関する考え方に新しい哲学的な基礎を作り出したことだ。これは、創造性、品質、そして、｢ビジネス時に」ビジネスの必要性に対するさらなる責任を強調するものだ。重要で個人的な変化に気付いた回答者もいる。開発者たちは、開発プロセスのオーナーシップを持ち、仕事に対する説明責任や個人的な責任が増している。オーナーシップの結果は、80年代にはタブーと考えられていた「生産のプロトタイプを作る」という考えに関して増えたことだ。
- 私たちが同じようなことをしているのかもしれないという問題点が挙げられたが、私たちはもっと「いやな」問題を扱い、もっとずっと複雑なことを成し遂げようとている。しかしながら、すでに述べられたように、複雑さの中にあるこの変化と、私たちが納品するスピードは、おもしろいほど大きくなり、おそらく「泥の中のボール」に進化した。私たちがまったく違う種類のプラットフォームを持つという事実や、もっとも重要なウェブやパラレルハードウェア、クラウドのリソースなどは1980年代からのものとは違っている。
- Michael Mah氏は次のように述べた。私たちは「おもしろくて新しいこと、相互ネットワーク、分散コラボレーション、ソーシャルネットワーキングなどを作り上げています。そして、これらのことをより速く行っています。残念なことに、同時に不具合は75%増加しました。つまり、私たちはどうしようもないものを速く作り上げているのです。私たちが積み上げた技術的負債は、すぐにでもなんとかしなければなりません。」
1980年にはメインフレームがすべてだった。今日はクラウドがすべてだ。なにか違いはあるだろうか?
構造的には、クラウドは巨大な中央集中型のプラットフォームであり、多数のインテリジェントターミナルに接続されている。この点に関しては、クラウドはメインフレームだ。しかし、ここには重要な違いもある。リソースとして、クラウドは、「自分専用の」同様なリソースよりもいろいろな設定が可能であり、極めて安価だ。クラウドは、また、無制限に設定でき、順応性があり、カスタマイズ可能だ。古いメインフレームはそうではなかった。
クラウドには大きなセキュリティに関する問題と、もっとも慎重に扱うべきデータを「向こうに」置きたいかどうかという懸念がある。クラウドでどのような「破壊的な失敗」が起こるかに関してはほとんど知られていない。そのような失敗の影響は、会社全体、経済全体、または、国の安全にかかわるかもしれないのだ。
クラウドは情報の関係も変えている。「そのデータは家の別のコンピュータにある。」という言い訳はもはや使えない。向こうにそんなに多くの情報を持つことは、意思決定の可能性にも影響し、協調した分散意思決定の新しい時代の先駆けともなるだろう。クラウドには、固定化や大規模な統合アプリケーションのベンダに対して「魂を売り渡す」という非常に現実的な問題とともに、高度な統合という現代のトレンドを加速する可能性がある。
クラウドの周りにある実際の問題のほとんどは、技術的なものではない。空中のメインフレームである結果でもないが、本来はビジネスや社会的なものであり、あちら側で解決されなければならない。
アジャイルが主流だ! これはアジャイルが成功したとか失敗したことを意味するのか?
両方だ。ほとんどは失敗だ。なぜなら、「だれでもやっていて、だれもが違ったやり方でやり、だれもやっていることを理解していない」からだ。ある意味では、アジャイルは成功していた。お金をもうけている人たちや会社もある。「これらのばかばかしいアイデア」が、今日、多少真剣に考えられていて、「ソフトウェア開発の様々な方法」が本当にあることを気付かせてくれる。アジャイルは、また、私たちが様々な問題に取り組むようにさせてくれる。アジャイルは、始める前に解決策を予想する代わりに、解決への道を探るようにさせるのだ。
アジャイルが失敗したポイントには、売り込みすぎたという事実が含まれる。「これがアジャイルで、あれがアジャイルではない」と言う基準はなく、すべてがアジャイルであり得る。Michael Mah氏は、自分の会社やCutterからのデータを引用し、「アジャイルプロジェクト」の3分の1のみ、本当にアジャイルだと述べている。さらに問題なのは、「アジャイルプロジェクト」の残りの3分の2は、従来のプロジェクトよりも欠陥率が高いことだ。これらは明らかにアジャイルの約束を実現していない。Bob Martin氏は以下のように述べている。アジャイルプラクティスがたいてい議論の的になり、「現場で信仰として扱われたり、対立したりしても、主流だからといってニュースの価値がある訳ではありません。」
「道に迷った」アジャイルに関するさらに興味深いコメントのいくつかは、あまりにも多くの支持者たちは本当に何が重要で、何が重要でないのかを認識出来なかったという事実に注目した。「かんばん対スクラムの議論は単に見当違いであり、アジャイルは特別なプラクティスやプラクティスのまとまりではなく1つの概念です。」「アジャイルは学ぶことであり、儀式やプラクティスを覚えることではありません。」
ほとんどの人はアジャイルが深刻なバックラッシュに直面することを予想している。
ソフトウェア開発は専門的職業か? 逆に言えば、ソフトウェア開発者たちは専門家か?
いや、いや! おそらく専門的職業になろうとしているものがあるが、まだ出現していない。確かに、ある種の標準と技術を体現している開発者たちもいて、私たちは専門家として付き合う。間違いなく専門家レベルだと認めて尊敬に値する人たちだ。しかし、残念ながらたいていの人は専門家ではない。
とても興味深いことに、「プロフェッショナリズム」に対する議論はたいてい、マネジメントが専門的職業かどうかに関する議論と同時に起こる。(Harvard Business Reviewの最新号を見てみよう) David Hussman氏が指摘したように、「ソフトウェア開発者は職業とするものが何もない。」 基礎となる信条はない。これは、医者が「危害を及ぼさない」のと一緒だ。専門的基準や倫理もなく、専門的職業の門番として行動する権威もない。ソフトウェア開発は、また、医学や法律のように合意した知識という一貫したものが欠けている。そして、本当の「専門家」は時間をかけて得た経験や学習の状態によって達成するものであり、本や大学の教育によるものではない。
回答者たちで共有したもっとも注目すべき意見は、プロフェッショナリズムに対するたった1つの最大の障壁が、実現できない、不可能だ、倫理に反するなど実践者たちが、ノーと言えないことであった。
多数の認定証を持つことが専門家になることの必要条件か?
「とんでもない。そんなことはない!」「絶対に違う!」「認定証があることと現実に相互関係はない。スクラムマスタには笑ってしまう。(認定料を払っただけだ。) 他のものはたいていナンセンスだ。」ぶしつけで感情的な回答によってすっかり明らかになったのは、認定とプロフェッショナリズムの間に相互関係があるという人は回答者の中にいないことだ。たいていの人は次のように述べた。医者のような本当に専門的なライセンスはあるが、それらのライセンスは医学の実習期間のように長期間の経験によるものである。これらは専門的なグループを定義するのに役立つかも知れないが、それでも問題がある。ソフトウェア開発者が知る必要があることの大半は大学のカリキュラムで減らすことはできない。
ソフトウェアクラフトマンシップの動きは、プロフェッショナリズムに関して重大な影響があるだろうか?
「そうだといいのですが」とBob Martin氏は言った。Martin氏はおそらくソフトウェアクラフトマンシップを持つ、もっとも著名で尊敬に値する一流人のうちの1人だ。「ソフトウェアクラフトマンシップは確かに自覚を促し、正しい道への第一歩になります。私たちがすることに、芸術と科学の両方が必要であることを認めています。」 他の回答者はたいてい期待を持っていたが、とても控えめだった。「もっと大きな変化が必要であり、ソフトウェアクラフトマンシップは正しい方向へのひと押しに過ぎません。」「徒弟制度の必要性を認識することは、この活動のもっとも重要な貢献の1つです。「ソフトウェアクラフトマンシップについてはあまり知りません。XPのプラクティスに何かみっともないことをくっつけてブランドを再生させたようなものです。」「ソフトウェアクラフトマンシップは、かつてしていた事をよりよく準備してもう一度繰り返しているのに過ぎません。年配の技術者たちのような技術や経験のない新しい世代のプログラマたちが生み出したものです。彼らは、「追いつく」方法を探しています。」 おそらく、ソフトウェアクラフトマンシップに関する最大の懸念は、ほとんど完全にプログラマ中心であり、コラボレーション、マネジメント、分析、設計といったずっと幅広い出来事を無視するという事実だ。
ソフトウェア開発者が読むべき3冊の本は?
- Freakonomics (ヤバい経済学)、Steven Levitt、Stephen J. Dubner
- The Checklist Manifesto、Atul Gawanda
- The Black Swan (ブラック・スワン)、Nassim Nicholas Taleb
- Clean Code、Dean Wampler
- Sketching the User Experience、Bill Buxton
- A Pattern Language (パタン・ランゲージ―環境設計の手引)、Christopher Alexander
- Peopleware (ピープルウエア)、Tom DeMarco and Timothy Lister
- Design Patterns (オブジェクト指向における再利用のためのデザインパターン) 、Gamma、Helm、Johnson、Vlissides
- Refactoring (リファクタリング―プログラムの体質改善テクニック)、 Fowler、Beck、Brant、Opdyke
- Structure and Interpretation of Computer Programs (計算機プログラムの構造と解釈)、Abelson、Sussman
- Design of Everyday Things (誰のためのデザイン?―認知科学者のデザイン原論)、Donald A. Norman
- Agile Project Management (アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則)、James A. Highsmith
- Stand Back and Deliver、Pollyanna Pixton
- Orbiting the Giant Hairball、Gordon MacKenzie
- Pattern Hatching、John Vlissides
- Notes on the Synthesis of Form、Christopher Alexander
- Object Design and Designing Object-Oriented Software、Rebecca Wirfs-Brock
- Extreme Programming Explained (XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法)、Kent Beck
- Manage your Project Portfolio、Johanna Rothman
- Flight of the Creative Class (クリエイティブ・クラスの世紀)、Richard Florida
- The Global Brain Awakens、Peter Russell
- Difficult Conversations (言いにくいことをうまく伝える会話術)、Stone、Patton、Heen、Fisher
- Robert Heinlein氏の著書
- Jerry Weinberg氏の著書
- Yourdon氏、Constantine氏、De Marco氏、Jackson氏による伝統的な分析テキスト
ソフトウェア開発者が使いこなすべき2つのツールは?
ホワイトボード、付箋紙/インデックスカードが圧倒的な回答だった。X-Unitテストツールの１つであるリファクタリングブラウザと継続的統合ツールは多くの人が役に立つと感じる唯一のソフトウェアツールだった。また、ソースコントロールツール、コードカバレッジツールをプログラマたちが挙げた。プロセスツールやマネジメントツールは地理的に分散しているチームの場合を除いて、価値がないと思われていた。
コンピュータサイエンス、ソフトウェアエンジニアリング、情報システム修士プログラム等の理学士、理学修士、情報システム修士、博士号取得は雇用条件になるか?
「まぁ、ある程度は」、「学校を出たばかりの人は最高の可能性を持っている。若い数学者のようにね。でも、生活のためにどうやって働くかを知る必要がある。」、一致した回答は、学校で学べることは限られていて、間違った技術を強調することが多い。大学の卒業生は、現実世界の経験と知識が必要であり、徒弟制度や、ときどきは強力なインターンシッププログラムからしか学べない。特にたいていの教育課程にはないチームやプロジェクトの経験、ユーザーとの協力、分析や設計スキル、交渉、そして、ベストプラクティスなどだ。
ソフトウェア開発においてオフショアにできない点はあるか?
ある。コンテキスト、製品の観念、使用分析、ユーザビリティ、文化、ビジネス価値の理解など理解が必要なことだ。ものとして扱えるもののみオフショアにできる。幅広いコミュニケーションが必要なことや、創造性や革新性に頼るものはオフショアにできない。
QCONに加えて、「ぜひとも参加すべき」カンファレンス2つは?
大規模カンファレンスの価値は、急激に衰退している。本当に目立つものはいなくて、たいていはコミュニティの集まりを誤解する。地方で数多くのカンファレンスや集まりがあり、実際にコミュニティ構築に参加できる。そして、そのコミュニティに貢献できる。自分で「自分の仲間」を見つけて、一緒に座る必要がある。QConは、何のカンファレンスか、また誰のためカンファレンスかが分かる数少ないカンファレンスのうちの1つだ。若い世代がネットワークを築き、共有し、協力する多くの機会があるので、カンファレンスの時代は終りを迎えるかもしれない。ただし、Jerry Weinberg氏が始めたAYEカンファレンスのような専門的な、出席者が参加するカンファレンスは残るだろう。
ヨーロッパ、アジア、アメリカのソフトウェア開発のプラクティスは、何か重要な点で異なっているか? お互いに学ぶべき教訓はあるか?
ほとんどの回答者はこの質問に答えるのを避けた。たいていは、他の大陸で取り組んだ深い経験がなかったからだ。みなが同意したのは、私たちが文化を理解し、私たちがすることやそのやり方に文化がどのように影響するか、また私たちがプラクティスを展開する時にどのような影響があるかについて知る必要があることだ。
1980年代に、Smalltalk と C++ の間の「あらゆる言語戦争のもと」が見られた。今日、私たちは、オブジェクト (今回はJava) と機能的言語との衝突が繰り返されるのを見ている。プログラミング言語は本当に問題なのか?
「いいえ、スペイン語を話すから良い本が書けるといっているようなものです。」 一般的な意見は、プログラミング言語はすべてチューリングマシンであり、本質的に同等だ。最終的には問題ではない。しかしながら、様々な言語によって、自分自身をより簡単にはっきりと表現できる。「書く本があるならば」別の言語よりもある1つの言語で書く方が簡単なことが分かるかもしれない。Sapir-Whorf の仮説をちょっと軽くして考えてみよう。異なることを考えることができ、別の言語よりもある1つの言語を仮定して異なるように考えるよう促される。最終的な問題は、「言うべきこと」について考え、概念化する能力だ。これができたら、もっとも率直で簡潔に言える言語を見つけるとよい。