手法とは？/ ディック
[ 542] ユーザビリティ評価手法
[引用サイト] http://www.usability.gr.jp/whatis/evaluation_method.html
|
ユービリティ評価手法は定量的手法と定性的手法に大きく分けることができます。定量的手法は複数のインターフェースを比較する場合に用いられます。定性的手法は、個々のインターフェースの具体的な問題点を発見するために用いられます。ユーザインターフェース開発プロセスでは、問題点の発見と改善を重視するので、定性的手法を多く用います。代表的な定性的手法としては「ヒューリスティック評価法」「ユーザテスト」が挙げられます。 複数のプロトタイプを作成して、その中から１つを選択する場合や、インターフェースを再設計した効果測定を行う場合には定量的手法を用います。定量的評価を行うには多くの被験者を必要とします。そのため、ヤコブ・ニールセンは「定量的ユーザビリティ調査の実施には、定性的調査の約4倍の費用がかかる」ので、限られた資源を有効に利用するためには定性的調査を行うべきであるとしています。 なお、ウェブサイトのユーザビリティについては、インターネットが持つ双方向性を活かして、アンケート調査法やアクセスログ解析でユーザビリティを評価する手法が開発されています。しかし、これらの手法では主観的な評価や、ページ遷移データしか取得できないので、問題が起きた原因を特定できません。あくまで、ユーザテスト等の定性的手法を補完する手法です。 WAMMIでは5つの尺度でウェブサイトのユーザビリティを測定し、その5つの尺度にウェイトを付けて総合ユーザビリティを算出します。 具体的な質問紙や尺度の計算ロジックは非公開なので、WAMMIを使った評価を行うには開発元に調査・分析を依頼することになります。 WAMMIは英語をはじめ、フランス語、ドイツ語、イタリア語、スウェーデン語など主なヨーロッパ言語に対応していますが、まだ日本語には翻訳されていません。 ウェブユーザビリティに関する21項目の5段階評価質問を行い、その21項目の質問から生成される7つの評価因子でウェブサイトのユーザビリティを評価します。 ウェブユーザビリティ評価スケールとインターネットサーベイを組み合わせると、効率的な調査が行えます。WUSを使った調査手順は以下の通りです。 ヒューリスティックとは「経験則」という意味です。ユーザビリティエンジニアやユーザインターフェースデザイナが、既知の経験則に照らし合わせてインターフェースを評価し、ユーザビリティ問題を明らかにする評価手法です。 被験者を必要としないので、短期間で実施できます。また初期のプロトタイプや、場合によっては仕様書レベルでも評価が行えるので、インターフェース開発の多くの場面で活用できます。 複数の評価者が個別に、ユーザインターフェースを評価し、問題点をリストアップする。（評価者は3名から5名が標準的。） ユーザテストとは、被験者がタスク（課題）を実行する過程を観察し、被験者の行動、発話からユーザインターフェース上の問題点を発見する評価手法です。ユーザビリティテストとも言います。 マジックミラーで仕切られ、防音を施された専用室です。マジックミラーを通して被験者の行動や発言を観察することができます。また、被験者の行動や発言を撮影・記録するためのビデオ設備も完備しています。なお、ウェブユーザビリティのテストでは、インターネット接続環境も必要となります。 テストに協力してくれる被験者データベースです。ユーザテストでは、想定ユーザと同じ属性（性・年代・パソコン習熟度など）を持った被験者に協力してもらわなければなりません。適切な被験者を抽出するには、かなりの数のモニターを管理する必要があります。 ユーザビリティ・エンジニアはテストを設計し、インタビューを行い、データを分析します。ユーザビリティ・エンジニアは単にユーザテストを担当するだけでなく、他の技術者やデザイナと協力して、ユーザインターフェースの改良にあたります。 正規のユーザテストではなく、簡易型のユーザテストでも、おおよその問題点は発見できます。ユーザビリティ・ラボの代わりに会議室を、モニターの代わりに知人や同僚を、ユーザビリティ・エンジニアの代わりに開発チームメンバーを用いれば、コストを大幅に削減できます。 |
[ 543] 新しいソフトウエア開発手法
[引用サイト] http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html
|
過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 (訳注:翻訳にあたり、著者より提供された参考文献(WEBサイト)リストを元に参考文献一覧を追加し、本文中にその一覧との相互リンクを埋めこんでいます。キーワード自体のリンクは原文と同じ英語サイトへのリンク、その前の*は参考文献一覧の該当項目へのリンクになっています。一部の項目では、そこから訳書や日本語に翻訳されたサイトを参照できます。) ソフトウエアの開発は「書いては直し」という言葉がピッタリなドロドロの仕事になりがちだ。ソフトウエアは無計画に書かれ、そのデザインは近視眼的な決定をつぎはぎしたようなものが多い。小さなシステムならば、そういうやり方でもなんとかなるがシステムが大規模になればなるほど、新しい機能を追加することがどんどん難しくなる。そういうシステムで見られる典型的な徴候は、「完成」したはずのシステムを異様に長時間テストしている、という状況だ。そのような長時間のテストによりスケジュールは大混乱となってしまう。なぜならば、テストやデバッグがスケジュールできないからだ。 我々はこういうやり方で長い間なんとかやってきたが、一方で別のやり方も昔から知っている。「開発手法」というやつだ。開発手法は、ソフトウエア開発のプロセスに規律を押しつけることで、開発がもうちょっと予測可能で効率的に進むことを目標としている。そして、他の分野におけるエンジニアリングの開発手法から発想されたもので、事前にプロセスを計画することに異常にこだわる。 それで、これはちょっとやりすぎだろうということで、ここ数年、一群の新しい開発手法が生まれてきた。まだ名前がついてないが、昔の「重量級」のものと区別して「ライトな」開発手法と呼ばれている。昔の「重量級」開発手法が官僚的だとボロクソに言ってた人は、みんなこの流れが結構気にいってるみたいだ。「ライトな」開発手法は、「手続きゼロ」と「手続きだらけ」のちょうどいい妥協点を探る試みで、最も効果を生むちょうどいいくらいの手続きを提供しようとしている。 その努力の結果、「ライトな」開発手法では重量級のものと全然違う所にポイントを置くこととなった。一番ビックリすることは、ドキュメントにこだわらないことだ。というか、各フェーズのドキュメントの量は少い方がエラいんだ、みたいなことを強調する。じゃ、何が大事かって言ったら、コードだ。ソースコードこそが最も重要なドキュメントの構成要素だ、と言うのだ。 でも「ライトな」開発手法ってのはこれだけだと言われると、私はちょっと違うと思う。ドキュメントを書かないっていうのは単なる徴候であって、もっと根本の違いに目を向けるべきだと言いたい。 「重量級の」開発手法は、長期間にわたってかなり細かい所まで全部予定表に書こうとする。ものごとが変化しないうちは、そのやり方がうまくいく。つまり、そういう開発手法は変化に抵抗する性質を内在している。「ライトな」開発手法は、逆に変化は大歓迎だ。状況に適応するプロセスであろうとするし、変化というものを糧にして生きてる。自分自身を変化させることだって平気だ。 人間がもともと持ってる特性に逆らうのはやめよう、それにのっかっていこう、と声に出して言う。さらに、ソフトウエアの開発ってやり方によってはめちゃ楽しいことかも、なんてね。 これから、その違いを詳しく見て行こう。適応的かつ人間中心の開発プロセスとはどんなものか、その長所と短所、そして、開発者としてであれ顧客(エンドユーザ)としてであれ、採用すべき価値のあるものかどうか、そういうことがわかるように説明していくつもりだ。 これまでの開発手法は、建築関係や機械工学から知恵を借りてきている。そっち方面では、モノを作る前に計画をたてることが絶対条件だ。そして設計者は、作るためには何が必要で、どう組み合わせるかを細かく指定した設計図を何枚も書く。橋にかかる負荷をどう処理するかというような、設計上の選択肢は設計図を書く時点で決定できる。そして、設計図は全く別のグループ、別の会社に手渡され、彼らが実際にモノを作ることになる。モノ作りは、ちゃんと設計図にのっとってやることになっている。実際には、モノ作りをする人たちも問題に直面するだろうが、たいていほんのちょっとしたことだ。 設計図を見ればどういう部品を使って、どういうふうに組み合わすのかすぐわかるので、設計図をもとにして、モノ作りのプランを細い所までたてることができる。そのプランを見れば、なすべき作業や作業同士の前後関係もちゃんとわかる。だから、スケジュールも予算も事前に確定しやすい。また、作業をする人がどう動けばいいのかもプランにきちんと書いてある。そういうわけで、モノ作りには熟練の技は必要であっても頭を使う必要はない。 だから、次の2つは根本的に違う作業工程なのだ。予見することが難しく創造的な人がやんなきゃだめなデザインと、予見することがずっと簡単なモノ作りだ。そしてデザインが終わればモノ作りの計画をたてることができる。計画があれば、実際のモノ作りを終りまで見とおすことも簡単だ。また、建築ではモノ作りはデザインよりずっとたくさんの費用と時間を必要とする。 それで、多くの開発手法は(建築をみならって)こういう方向に持っていこうとする：「あまりスキルのない人でもちゃんと動けるような、仕様書があればいいのだ」そのためには「デザイン」と「モノ作り」を分割する必要がある。目標は、「モノ作り」が単純作業になるような「デザイン」であり、そういう「デザイン」のための開発手法が必要とされている、ということだ。 で、こういう発想から何が産まれただろうか？「それがUMLのような設計書の役割だろう」って言う人もたくさんいるだろう。確かに、難しい所・・・設計上の決定がUMLの上で全部できちゃうとしたら、建築屋さんみたいに「モノ作り」のプランをたてて設計書をコーダーに渡して、後は知らん顔したってかまわない。 だけどここでちょっと考えてほしい。あなたは、本当に何も考えないですぐにコードが書けるような設計書ってものを見たことがあるかな？ある？それじゃ、その設計書を書くのとコードを書くのとで、どっちが時間がかかった？同じくらいの時間がかかったんじゃ、こういうアプローチをとる意味がないような気がするんだけど、どうかな？ ということを考えていると問題は次のようになる。まず、黙ってプログラマーに渡してハイ終わり、と言えるようなUMLなどの設計書を書くことがどれだけ難しいかということ。そういう設計書はみためかっこいいんだけど、いざプログラムに落とそうとするとボロボロで使えない、ということが問題なのだ。建築屋さんは、現場で何年も揉まれたちゃんとしたモデルを持っていて、それで仕事をする。しかも、連中のする「デザイン」のキーポイント、例えば力学的な検討とかは数学的な解析になじみやすい。それに引きかえ、我々がUMLのような図に対してできるチェックと言えば、せいぜいピアレビューくらいのものだ。ピアレビューだって役にたつことは役にたつが、エラーを見落してしまって、コーディングやテストになってから問題が露見するということもよくある。ちゃんとした設計者でも(一応、自分もそのつもりなんだけど)、設計書を実際のソフトウエアに落としてみて驚くこともよくある。 もうひとつのポイントは費用の割合だ。橋をかけるような仕事では、「デザイン」のコストはせいぜい全体の1割だ。一方、ソフトウエア開発では、コーディングの占める時間はずっとずっと少ない。*McConnellによると、大規模プロジェクトでは、コーディングと単体テストにかかるのは15%だけだそうだ。つまり、橋の場合とほとんど逆の結果となる。全てのテスト工程を「モノ作り」の方に入れても、「デザイン」は依然として半分を占めている。だから、他の分野のエンジニアリングにおける「デザイン」の役割と、ソフトウエアのそれを比較するのはどこかおかしいのではないか？という疑問がわいてくる。 Jack Reevesは、これと同じようなことを考えているうちに「実はソースコードが設計書で、(建築でいう)モノ作りに相当するのは、コンパイラーとリンカーを動かしてる時間だけじゃないだろうか」とか*言いはじめた。確かにそうだ。「モノ作り」というからには、完全に自動化できる作業じゃないとおかしい。 創造的なプロセスは、簡単には計画できない、これを事前に計画するという目標を設定してはいけない。不可能だ 伝統的なエンジニアリングをソフトにたとえることには注意すべきだ。両者は全く違う活動で、全く違うプロセスを必要とする 私は問題のあるプロジェクトに突っこまれたことがたくさんあるが、どこでも必ず耳にする言葉がある。開発者たちは私の所に来て「このプロジェクトの問題点は要求仕様がコロコロ変わることなんだ」と言う。それはあたりまえのことであって、みんなが揃ってそのことを何かとんでもないことのように言うのが、私には一番不思議だ。ビジネスに関わるソフトウエアを開発するなら、要求仕様が変わるってことは、ノルマくらいに考えるべきだ。問題は、それにどう対応するかだろう。 ひとつの考え方は、要求仕様が変わることを要求分析がヘボだからだとみなすことだ。要求分析の背後には、こんな考え方がある。開発に入る前に、要求の全体像を文書化して顧客のハンコをもらって、ハンコをもらった限りはちょっとやそっとで変更を許さないように、その手続きを決める。 このやり方の問題点は、要求の中にある選択肢を理解するのが難しいということだ。開発する側の組織が要求分析の時にコストに関する情報を提供しないと、これはより難しくなる。例えば、車にサンルーフをつけようとして、それが1000円なのか100万円なのかセールスマン自身がわかってなかったら、決断しようたって無理だ。あなたは、これと同じような状況で立往生することになるだろう。 見積もりが難しい理由はいろいろある。ひとつには、ソフトウエアの開発が「デザイン」であるからだ。「デザイン」だから、プランをたて費用を見積もるのは難しい。また、基本的な素材がすぐに変化していくこともある。さらに、個人に依存していることも理由のひとつだ。個人を予見したり数量化することが難しい。 ソフトウエアが目に見えないものであることも考慮する必要がある。ソフトウエアの機能がどのような価値を持っているかは、実際に触ってみるまでわからない。本当に価値ある機能を見ぬくためには、早期の開発バージョンを使用してみるしかない。 こういうわけで、人々が要求仕様を決定できないという皮肉が生まれる。結局、みんなソフトウエアがソフトであってほしいのだ。要求仕様は変化するものだ?・・・甘い、甘い。要求仕様は変化するべきなのだ。顧客に要求仕様を決定させるにはエネルギーがいる。特に、顧客がソフトウエア開発をかじっているとたちが悪い。だって、ソフトウエアをいじるのは簡単だってことがバレバレだから。 それにね。もし、そういうゴタゴタをなんとかやりくりして、正確で固定した要求仕様書を手に入れられたとしても、あなたには悲惨な運命が待っている。現在では、経済やビジネス自体が流動的で、そのためにソフトウエアの価値も凄い勢いで変化してしまう。完璧な要求仕様書があったとしても、それは半年とはもたない。顧客が仕様を固定させたとしても、顧客をとりまくビジネスの世界がそんな悠長なことを許してくれない。さらにビジネスの世界に起こる変化は、誰にも予知できない。「予測した」と言いはる奴もいるが、そういう連中が株で大儲けしたって話は聞かないなあ。 そして、ソフトウエアの開発は全て要求仕様に依存している。きちっと固定した要求仕様が書けないとしたら、事前に計画をたてるっていうのは、不可能だと思う。 私は予測がどういう状況でも絶対に不可能だとは言ってないよ。実際、そういう環境でソフトウエアが開発されたケースもある。NASAのスペースシャトルのソフトを作ったチームなんかは典型的な例だ。ただ、そういうのはおおげさな儀式と途方もない時間とたくさんの人間を必要とする。もちろん「凍結した要求仕様書」もね。だけど、普通ビジネスで使うソフトウエアはこういうふうにはいかない。全く違うプロセスを必要とする。 一番危いのは、できるはずがないのに予見可能なプロセスに従おうとすることだ。だいたい、何かの開発手法にハマちゃってる奴はその開発手法がピッタリ来るケースと、そうでないケースを見わけることができないんだよね。ってゆうか、その開発手法が誰にでも通じるものだと思いたがってて、それが適用可能な領域とそうでない領域を区別する必要も感じてない。そういう連中が、開発手法を間違った環境で使おうとしてハマっちゃうのさ。典型的な間違いが「予測(計画)を前提とした開発手法を予測不可能な状況で使ってしまう」こと。 まあ、そういう連中の気持ちもわからないでもない。私だって、いろんなことが予測可能だったらすごく気持ちいいと思う。しかし、できない予言をできると思いこんじゃうと、プランを必要以上に早いタイミングで作っちゃうことになる。しかも、そのプランがダメになった時に、お手あげになっちゃってドツボに陥る。プランは現実とだんだんと遊離していく。最初のうちは大丈夫大丈夫と言ってられるだろうが、いずれ、そうは言えなってプランを捨てることになる。たいていそれには痛みが伴う。 だから、もし予測が不可能な状況にいたら、予測を前提とした開発手法は絶対に使ってはいけない。使ったらひどい目にあうだろう。無理して使っても、プロジェクトをコントロールしたり顧客とやりとりするモデルはほとんど使えないと言うことだ。ものごとが予測可能だったら何もかもうまくいく。それだけに、そうでないという現実を受けいれるのは難しい。「問題」というものはえてしてそうだけど、「問題」の一番問題なことは「問題」が存在していることを認識することだ。 予測可能性を手離したらと言って、必ず制御不能の混沌が待ってるということじゃない。ただ、予測不可能性とうまくやってけそうなプロセスを必要とするということだ。「適用的」っていうのは、実はそういうことなんだ。 では、この予測不可能な世界に住む我々自身をどうやってコントロールしたらいいだろうか？最も重要だが困難なことは、正確に自分たちの住む世界のことを知ることだ。我々には、現在の状況がどうなのかを、そのつど繰り返し正確に報告してくれる正直なフィードバックメカニズムが必要なのだ。 このフィードバックのための鍵は繰り返し型開発手法だ。これは別に目新しい考えではない。繰り返し型開発手法はいろいろな名前をつけられているが、前からある・・・インクリメンタル、進化的、ステージ型、スパイラルなどなど。繰り返し型開発手法の鍵は、最終的なシステムの別バージョン(機能は限られるが実際に動くもの)を何度も作り出すことだ。別バージョンは、機能的には不足があってもいいが最終成果物に対する要求には忠実にできてないといけない。そして、完全に統合化されていて本番システムと同じように注意深くテストされているべきだ。 ポイントは、テストされ統合されたシステムによって、プロジェクトに「現実」の重みをそそぎこみ、現実から遊離しないようにすることは不可能だ、ということである。ドキュメントには全ての種類の欠陥を隠すことができる。テストされていないコードにはたくさんの欠陥が残ってしまう。 しかし一旦、人々が実際にシステムの前にすわって、それに触れてみれば欠陥は一目瞭然、現実のものとなる。バグであれ、間違った要求であれ。 繰り返し型開発手法は、予見可能なプロセスに適用しても意味がある。しかし、変化する仕様を扱う適応的なプロセスにおいてこそ欠くことのできないものである。そして、長期計画は流動的で、はっきりした工程があるのは繰り返し一回分の短期計画だけ、というスタイルのプランニングを導く。さらに、繰り返しのたびにしっかりとした基礎を築き、それが次回のための基盤となるのだ。 繰り返しの長さはどれくらいがいいのか、ということは重要な検討項目である。人によって答は違う。XPは1週間から3週間、SCRUMは1ヶ月、クリスタルはもっと長い。ただ、全体的にはなるべく短くした方がいいと言う者が多いようだ。短くするほど、フィードバックの間隔も短くなり自分の位置を確認できる機会も多くなる。 この類の適応的プロセスは顧客との関係も、普通考えるのと違うやり方を要求する(顧客と開発者が違う会社の場合は特に)。普通、ソフトウエア開発のために外注を頼むとしたら、料金を固定して契約することを望むだろう。開発者に必要なことを伝え、入札させて選択する。そしたら、ソフトウエアを開発する責任はその会社のものになる。 固定料金で契約しようとしたら、確定した仕様が必要となり予見できるプロセスも必要となる。適応的プロセスや未確定の仕様があるならば、固定料金といういつもの概念では仕事にならない。固定料金モデルを適応的プロセスにあてはめようとすると、苦痛に満ちた爆発が待っている。やっかいなことは、開発者の会社と全く同じく顧客側の会社もダメージを受けることだ。なんだかんだ言って、ビジネス上の必要がなければソフトを発注することもない。そのソフトができなければ、顧客のビジネスも苦しむ。支払いのあるなしにかかわらず、それは損失なのだ。実際は、払うはずだった金額よりその損失額の方が大きい。だって、ソフトに開発費用がそれが産みだすビジネス上の価値より大きいわけはないからね。 だから、予測可能を前提としたプロセスが使えっこないとわかってるのに、固定料金の契約にサインすると言うことは、お互いに危い橋を渡ることになる。つまり、顧客の側もやり方を変えなくちゃいけないと言うことだ。 適応的プロセスでは、顧客はソフトウエア開発をもうちょっときめ細かくコントロールする必要がある。繰り返しのたびに、毎回、顧客は進捗をチェックしてソフトウエア開発を方向づけなくてはいけない。必然的に、顧客と開発者の関係は密になる。本当のビジネス上の提携関係になる。そういう深い関係を必要としない顧客もいるし、必要としない開発者もいる。しかし、適応的プロセスをうまく機能させようとしたら、これは絶対に必要なことだ。 顧客にとってそれで何が嬉しいかと言うと、打てば響くようなソフトウエア開発ができることだ。余分なものは何もないが本当に使えるシステムがすぐに手に入る。とりあえず使ってみれば文句も出てくるしビジネスも変化していくだろう。その流れにそって、システムを修正していけばいいのだ。 適応的プロセスを実施することは簡単なことではない。特に、開発者のチームがとても効率的に動かないとまず駄目だろう。個人個人も質が高くなくては駄目だし、みんなが力を合わせる方法も効率的でないとうまくいかない。適応的プロセスはデキる奴が必要だが、どういうわけかデキる連中はそういうスタイルが好きなんだ。 これまでの開発手法が結局何をしたいのかと言うと、人間を交換可能な歯車にすることだ。そういうプロセスでは、人間は種類ごとに分類された資源として扱われる。「アナリスト1丁、コーダー4丁、テスター3丁、マネージャー1丁」みたいな感じで。連中が欲しいのはひとりの人間でなく、単なる役割なんだ。誰が来るかはどうでもいい、人数を揃えればいい。プランに関係するのは人数だけだから、それがわかればいいんだ。 こういうやり方をしてたら「本当にソフト開発に関わる人間は交換可能なパーツなんだろうか？」という疑問が浮かんでくる。「ライト」な開発手法で最も大事なことは、そういう考え方を断固として拒否することなんだ。 「人間中心のソフトウエア開発」のことを、Cockburn みたいにズバズバ言う奴は他にいないが、ソフトウエアについてモノを考える人で、人間優先ということをテーマにしている人はけっこういる。だが、人間という概念をプロジェクト成功のための一次的要因とするなんてことには、これまでの開発手法は大反対してきた。それが問題なんだ。 このことが、強力なフィードバック効果を産んでしまう。もし、あなたが開発者が交換可能な部品であることを期待したとする。そしたら、チームは個々の人間で構成されていることを忘れてしまう。みんなやる気をなくし、生産性も落ちる。そして、デキる奴はみんな逃げ出してしまい、最後にあなたは期待どおりのもの・・・交換可能な部品を発見することになる。 人間が最初だと決めることはちょっとした決断であり、決断力がなかったらそれを通すことはできない。開発者とは人月だという概念は、ビジネスの中に深くしみこんでいる。なんたって、*フレデリック・テイラーの科学的管理アプローチ以来のことだからね。工場を経営するなら、テイラー信者のやりかたも意味がある。しかし、とても創造的でプロフェッショナルな仕事、ソフトウエア開発は当然そうだと思うが、についてはそうは言えない。(実際には、あっちの方でも今はあまり流行らないみたいだけど) テイラー信者の中心的な概念とは、現場で仕事をしてる連中にはどうやったら仕事がうまく運ぶかわからない、という考え方だ。工場では、これが成り立つ理由がいくつかあるだろう。ひとつには工場労働者の中には知的で創造的な人があまりいないからだ。また、管理者だけいい給料をもらって労働者の取り分が少いことから、両者の間に緊張があることも理由のひとつだろう。 ソフトウエア開発では事情が違うってことが、だんだんと見えてきた。だんだんと、明晰で能力のある人たちがソフトウエア開発に、その輝きと大きな報酬に魅力を感じて飛び込んできている。(かくゆう私もその2つに魅せられて電子回路のエンジニアリングから転向したクチだ)ストックオプションみたいなシステムでさらに多くのプログラマが呼び寄せられている (このことには世代的な影響があるかもしれない。より多くの頭のいい人がソフトウエア業界に来るようになったというのは、ここ10年くらいのことだよね。私にはそんな気がするけど。もしそうなら、コンピュータビジネスに「若さに対するカルト的崇拝」があるのもうなずける話だ。ほかのカルト的崇拝と同様に、ひとつぶくらいの真実が、そこに無くてはならないからだ。) もしできる人を雇って逃がさないようにしたいなら、連中は目端がきくプロフェッショナルだということを肝に命じておくべきだ。技術的な仕事をどうやって運営するかの決断は、彼ら自身にさせるのが一番いい。管理部みたいな部署でやり方を決めるテイラー流の概念は、その管理部の人間が現場よりどうすれば仕事がはかどるかわかってる場合にしか使えない。ヤル気マンマンで切れる人間が仕事をする時は、話が違うんだ。 人間指向と言っても流儀はいろいろある。流儀によって効果が違うし、なかには全く逆のことを言っている場合もある。 重要な鍵となる要素としては、プロセスを自分から取り入れていくのはOKだけど、押し付けられるのはゴメンだよ、ってことだ。まあ、そういうことが好きなおエライさんもよくいるけどね。上が押し付けるから、下の者はムキになって逆らうんだ。ましてや、おエライさんのために実際に開発する時間がなくなったりすれば、なおさらだ。プロセスを受けいれるということは、ある意味自由を失うことだ。それだからこそ、チーム全員が納得してそれに全面的にのっかってくれないとマズいんだよ。 だから、適応的なプロセスに従うという選択ができるのは開発者自身だけだ、という興味深い結論が得られる。これは、守るべき規則がたくさんあるXPで顕著である。クリスタルは、規則は少い方がいいという大目標のために、この点については効果的な補足項目を用意している。 もうひとつのポイントは、開発者が全ての技術的決定を行うかどうかだ。XPはこの点では徹底していて、プランニングプロセスでは、仕事にどのくらいの時間がかかるかの見積もりをするのは、絶対に開発者だと言いきっている。 管理職の立場にいる人にとっては、そういうふうに技術者にまかせるのは、かなり大きな変革だ。そういうやり方は、プロジェクトのリーダーシップにおいて開発者と管理者が同等の地位を占め、責任を分かちあうことを必要とする。同等と言ってることに注意してほしい。それでも管理者には役割があるが、開発者の方に専門知識があることを認識しなくてはダメだ。 このことの重要な理由は、この産業の技術革新のスピードだ。数年かそこらで技術的な知識は時代遅れになる。他のどの産業より、技術的なスキルの半減期が短い。現役の技術者も、もし管理職になったらすぐに自分のスキルがひからびてしまうことを認識しなくてはならない。元技術者なら、自分のスキルはもはや存在しないも同然で、現役の開発者を信頼して彼らに頼るしか道はないのだ。 しかし、技術者が全てのプロセスを実施することはできない。業務上の必要に対するガイダンスが必要だ。このことから、適応的プロセスの重要な側面が導かれる・・・開発者は業務の専門家と密に接触を保つこと。 だから、ビジネスの役割は普通のプロジェクトより大きくなる。「ライトな」開発手法で運営するチームは、コミュニケーションが粗では存在できない。継続的に業務の専門家にアクセスする必要がある。それは、管理者のレベルで扱えばいいというレベルではない。全ての開発者の目の前に存在してないとダメだ。開発者は、彼ら自身の仕事については有能だしプロフェッショナルだが、別の仕事のプロフェッショナルと一緒に仕事をする必要がある。 もちろん、こうなる理由は適応的開発の性質のためだ。適応的開発では、物事が素早く変化するというのが根本的な前提なので、その変化を知らせるべき人と常に一緒にいる必要がある。 一生懸命やった仕事が無駄になってしまうことを、開発者は何より不満に感じる。だから、業務の専門家が必要だ。そして、その人は常に開発者の側にいなくてはいけないし、開発者が信じるに足るだけのそれなりの人でなくてはいけない。 ここまで私は、顧客の要求がたびたび変化するという観点から適応性について説明してきた。しかし、もうひとつの観点がある・・・プロセス自身の適応性だ。適応的プロセスを使って開始したプロジェクトは、1年後に全く同じプロセスを使用しているとは限らない。チームが彼ら自身のためにもっとうまいやり方を発見し、プロセスを合わせていくということがたびたびあるだろう。 自己適応性の最初のパートは、定期的にプロセス自身をレビューすることだ。普通は、これは繰り返しのたびに行う。繰り返しが一回終わったら、次の質問を自分自身にしてみるといいだろう。 この質問が、次回の繰り返しのプロセスをどう変えるかのアイディアをもたらすだろう。このようにして、最初は問題だらけのプロセスがだんだんと改良されていく。そして、それを使うチームにピッタリのものになっていく。 もし、自己適応性がプロジェクトの内部で起こるとしたら、組織をまたいで注目されてもいい。自己適応性を深めるために、プロジェクトの大きなマイルストーンでは、もう少し本格的なレビューをすることをお勧めする。Norm Kerthが、そういうプロジェクトをふりかえるためのセッションのやり方の概説しているので、それに従えばいいだろう。そういう回顧は、ちょっと場所を変えて訓練されたファシリテーターを呼んで2〜3日かけて行なった方がいい。それは、プロジェクトのメンバーだけでなく、組織全体に参考になるものを提供するだろう。 自己適応性の究極の形では、もはや会社共通の開発手法は必要としなくなる。そのかわりに、それぞれのチームが自分のやり方を選ぶ。それどころか、積極的にそのやり方をプロジェクトに合わせて調整していくのだ。本に書いてあることや他のプロジェクトの経験は、基本とヒントを提供するが、開発者たちは、自分の責任でそういうものをどんどん改変していってもかまわない。 こういう自己適応性という概念は、ASDとクリスタルによく出てくる。XPはルールがキチキチなので、そういうことが許されてないように見える。 「ライトな」という名前に値する開発手法はいくつかある。どれにも共通の特徴がたくさんあるが、はっきりとした違いもある。この短いサーベイでは、全ての特徴をあげることはできないが、少くともあなたが探す場所を見つける助けにはなるだろう。 XPは4つの価値から始まる・・・コミュニケーション、フィードバック、単純さ、そして勇気だ。次にXPプロジェクトが従うべき、12のプラクティスが続く。多くのプラクティスは、歳月を経て試練に耐えてきたテクニックだが、ほとんどの計画的プロセスを含め、多くの人からは忘れ去れてしまっていた。XPは単にそれを復活させただけではない。XPはひとつの全体性へとそれをつむぎあわせ、強化した。 XPはテストを非常に重視する。私はまずそこに注目したのだが、この点でXPは急所をとらえてると思う。テストに言及しない開発手法はないけど、テストはどうでもいいような扱いになっていることが多い。ところが、XPではテストこそが開発の基礎である。全てのプログラマーは、実際に稼働するコードを書くのと同時にテストのコードも書く。そのテストコードは、継続的なビルドのプロセスに統合化されて、さらなる開発のための確かな基盤となる。 この基盤の上にXPは漸進的な設計プロセスを構築する。そのプロセスは、素朴な原型システムを繰り返しのたびに「リファクタリング」していくことに依存している。設計は今回のするべきことだけに集中し、先々必要となる要望などは一切考慮しない。 *Alistair Cockburn は、90年代初頭にIBMから開発手法について書くように命じられてから、開発手法にかかわっている。だが、彼のアプローチはちょっとかわっている。普通だったら、自分の経験から物事をどうやるべきかを理論化するのだが、彼は、インタビューに応じてくれるプロジェクトを探しまわって彼らのやり方を聞き、彼自身の経験を補完しているのだ。そして、その結果得たものがあれば、自分の見解を変えることも恐れない。そういう所が、私は気にいっている。 Alistair はまた、繰り返しの最後のレビューに重点を置いており、プロセスが自分自身を改良していくよう勇気づけている。繰り返し型開発は、問題を見つけやすくして修正を可能にするためにこそ存在理由がある、と彼は主張している。だから、人々が自分のやってることを把握して、開発を続けながらそのやり方を調整することに重点を置くわけだ。 この見出しには驚いただろう。どう言おうが、オープンソースはソフトウエア自身の特性であって、開発プロセスの特性ではない。しかしながら、オープンソースコミュニティの連中は、確かにひとつの流儀を持っている。そして、その流儀の大部分は、ソースがオープンだろうとクローズだろうと適用できるものだ。特に、彼らの開発方法はチームのメンバーが地理的に離れていることを考えにいれている。ほとんどの適応的開発手法は、チームのメンバーが同じ場所で仕事をすることを強調しているので、これは重要なことだ。 ほとんどのオープンソースプロジェクトには1人以上のメンテナンス担当者がいる。メンテナンス担当者だけが、ソースコードの変更をリポジトリにコミットすることを許されている。しかし、それ以外の人もコードに変更を加えることがある。重要な違いは、他の連中はメンテナンス担当者に変更を送り、メンテナンス担当者はレビューしてから変更を適用することだ。通常、この変更は作業が簡単になるようにパッチファイルを利用して行なう。メンテナンス担当者は、このように多くのパッチを調整して、そのソフトウエアの設計上の均質性を保つことに責任を負っている。 プロジェクトごとにメンテナンス担当者の役割は違っている。プロジェクト全体をひとりで担当する者もいるし、モジュールに分割してモジュールごとに担当者を置く場合もある。当番制の場合もあるし、同じコードに複数の担当者を置く場合もある。なかには、以上のどれかを組合せているケースもある。ほとんどのオープンソースの人はパートタイムだ。だから、そういうチームがフルタイムのプロジェクトをうまくこなすことにも注目すべきだろう。 オープンソースの開発の特質として、デバッグをとても多くの人が同時並行的に行なうことがあげられる。デバッグにはたくさんの人が参加する。彼らはバグを見つけるとメンテナンス担当者にパッチを送る。これは、バグはたいてい発見するまでに時間を要するものだから、メンテナンス担当者以外の人にはよい役割だろう。また、高度な設計能力がない人もデバッグには容易に参加できる。 彼は最近の本では、新しい開発手法の適応的な特質に注目している。そして、複雑な適応的システムから産みだされたアイディアを適用することを強調している。(これは、カオス理論として知られている)それは、XPのように詳細なプラクティスは提供しないが、なぜ適応的な開発が必要かに関する基本的な土台とマネージメントの深い階層がもたらすものを提供する。 SCRUMはオブジェクト指向のサークルの中ではそれなりに知られていた。とは言え、正直に言うと私はその歴史や由来についてはそれほど詳しく知らない。これもまた、同じ問題に注目している。すなわち、決まりきった繰りかえしのプロセスは、決まりきった繰りかえしの問題に決まりきった繰りかえしの連中が決まりきった繰りかえしの環境で使う場合しか、使えないということ。 SCRUMは(スプリント：短距離走と呼ぶ)30日間の繰りかえしにプロジェクトを分割する。スプリントを始める前に、そのスプリントで必要とされる機能を定義して、それを開発チームに手渡す。ポイントは、スプリントの間は要求をいじらないことだ。 しかし、これはスプリントの間、管理が不要になるということじゃない。毎日、チームは(15分間の)短いミーティングを行なう。ここでチームは次の日に何をするかをおさらいする。また、その日に何が完了したかをリポートするので、管理者はプロジェクトの現在位置について毎日知ることができる。 SCRUMの文献は、主にプランニングとトラッキングのプロセスを繰り返すことに集中している。多くの点で、「ライトな」開発手法に通じるものがあるし、XPのコーディングのプラクティクストと両立するだろう。 開発者はクラス所有者とチーフプログラマの二種類に分けられる。チーフプログラマは最も経験の深い開発者がなる。彼らには構築すべき機能が割当てられる。しかし、彼らは一人でそれを構築するわけではない。チーフプログラマーは、その機能を実現することに関わるクラスを特定し、そのクラスの所有者を集めてチームを作る。チーフプログラマーは、調停者として設計者として家庭教師としてふるまい、クラス所有者がほとんどのコーディングを行なう。 「ライトな」手法についての論文や討論は他にもたくさんある。それらは完全な手法にはなっていないが、この成長する分野についての洞察をもたらしてくれる。 誰もが「ライトな」手法でハッピーになるわけじゃない。この道を行くつもりなら、心にとめておいた方がいいことがいくつかある。私自身は、これらの新しい手法は広く適応可能だし、もっともっとたくさんの人が使うべきだと思っているけどね。 現代の環境では、もっと使われている手法と言えば「コードを書いてそれから直す」だろう。そういう混沌と比較すれば、規律を導入することは何にせよ役に立つだろう。だが、いきなり「重量級」で行くより「ライトな」アプローチにした方がギャップは小さい。ライトな手法のよさは「軽さ」なんだ。プロセスが全くない所へプロセスを持ち込むとしたら、単純なプロセスの方が従いやすい。 新しい手法の最も重大な限界は、どれだけ多人数のチームが扱えるかと言うことだ。クリスタルは50人くらいのチームで使用されている。それ以上の規模になると、どうやったら適応的なアプローチが使えるか、そもそもそういう方法がなりたつのか、ということに関するデータはほとんど存在しない。 この記事で言っておきたいことがひとつある。要求仕様が確実でなく流動的な時は適応的手法がいいよ、と言うことだ。確実な仕様を手にできないなら、設計を確実にして計画どおりに進めることは期待できない。そういう場合なら、適応的プロセスは、居心地は悪いにしても効率的であるとは言えるだろう。一番の障害になるのは顧客だろう。私の見方では、仕様が変化していくのに予見的なプロセスに従うことは、開発者も往生するが顧客の方も同じなんだけどね。 みんな気がついてると思うが、50人以上だったら伝統的に予見的プロセスがいいし、仕様が変化しそうなら適応的プロセスがいいと私は言った。じゃ、50人以上で仕様も変化するならどっちにしたらいいだろうか？さすがの私もこれには答えられないので、誰か他の人に聞いてみてくれ。ただ私に言えることは(もうわかってるだろうが)「それはとてつもなく困難だ」と言うことだけだ。 そして、もし適応的手法をとるなら、開発者を信頼してものごとを決める場に呼んでやんないとダメだよ。その信頼が無いと適応的手法は成り立たない。だから、開発者の質が低くやる気がないとお嘆きのあなたは、予見的アプローチを使った方がいいだろう。 どれも新しい手法であり、私はちょっとしたガイドしか提供できないが、私が選ぶとしたら、ポイントはふたつ。その1・・・チームの人数、その2・・・どれだけ厳しい規律に従う用意があるかどうか。 12人以下でみんな乗り気になってるなら、間違いなくXPがいい。とことんやらなきゃだめということではない。XPのアプローチを部分的に適応してもいいことがたくさんあるだろう。キーとなるのは完全自動化単体テストだ。それさえちゃんとやるつもりならば、技術的な基盤がしっかりしている。もし、それ(単体テストの自動化)を手ぬきするつもりだったら、XPの他のことはとてもできないと私は予想する。 そうは言ったけど、実は今私は40人のチームと仕事をしてるんだけど、このチームは多くのXPプラクティスを実施していて、ほとんどのフルセットのXPと言ってもいいくらいだ。だから、チーム全体でしっかりとした決断ができるならば、この限界点にこだわる必要はないかもしれない。 最後に最も大事なことを言っておこう。始める時に「なんとか」というプロセスを開始したとしよう。その「なんとか」はほんとうの意味ではあなたの仕事のプロセスではないんだ。プロセスをチェックして自分の環境に合わせていじることが一番重要なことだ。プロジェクトが完了する時点では、そのプロセスは「あなたの」プロセスになってるはずだ。その時には「なんとか」っていう名前はおまけみたいなものさ。 これは、成長するWEB論文であり、私はいじりたくなったらすぐいじるつもりであることを覚えておいてほしい。大きく変更した時はそれを記録するけど、小さな修正はコメントなしでやってしまうつもり。 |
ディックのサイトです。
