シス開発：注目すべき重要技術 |
XP（Extreme Programming）とは、コーディングとテストを中心に据えた開発手法である。基本的な考え方は、最初から上手に設計できないので、まず作って動かしながら悪い点を見付け、だんだんと改良していこうという姿勢だ。
機能を保ったままソフトの内部構造を改良する「リファクタリング」という方法が基盤を支えている。プログラマー自身がテストを用意し、内部を少し変えるたびに関連テストを全部実施し、変更で生じたバグを素早く発見する。このような一連のテストは、全体を自動化して一気に実行する。おかげで、新しいバグの混入を防ぎながら、内部構造を変更しやすく改良できてしまう。
XPでは、どんな機能を実現すべきか検討するために、プラニング・ゲームという工程を用意している。依頼主側の要望を集め、その中の優先度の高いものから順番に作り、小さな単位でリリースしていく。ここにも、悪かったら次のリリースで直せばよいという思想が貫かれている。
コーディング作業においては、二人１組で１台のマシンを利用する「ペア・プログラミング」方式を採用する。コーディング規約を用意し、それに従ってプログラミングする。作成したプログラムは、個人の成果物ではなく、参加者の共有財産という考え方だ。ペアを入れ替えたりすることで、参加者が持っている情報を共有でき、システムに対する全員の知識や理解が深まる。
開発の段階でも、システムの利用者となる人が、依頼主の側から参加する。作りながら細かな機能を検討するので、問題領域の知識や要望を知っている人が常に必要だからだ。その人が常にいることで、ちょっとした疑問もその場で解決できる。
大まかには、以上のような内容の手法である。プログラミング工程を中心に据えているため、プログラミングが好きなソフト技術者から注目されている。ソフト技術者の中にはプログラミングの好きな人が多いようなので、業界全体としての注目度は高いだろう。
XPの最大の長所は、作っては直す作業を繰り返しながら、最良の結果を求める点にある。最初に全体像から細部まで設計する方法だと、全体像の方は正しくても、細かな部分は正しくないことが良くあるからだ。その可能性が高いので、作り直すような手法を最初から採用している。
作りながら最終形を求める点では、プロトタイピングと通じる部分がある。プロトタイピングと根本的に異なるのは、最初から本番システムを作ろうとしている点だ。それでも、実際に作ってみてほしい内容を探し出すという、プロトタイピングと同様の利点は得られる。
プロトタイピングには、内部構造が汚くなることと、キチンとした仕様書が残らないという２つの欠点が伴う。XPでは、前者に関してリファクタリングで対処できる。後者に関しては、どうやっているのか不明である。リファクタリングの本などを読んだ限りでは、仕様書を重視していないような感じを受けた。
リファクタリングの著者の発言によると、XPに明確な設計の工程がないのは、設計が進化したのだという。今までは前側の工程でまとめて設計していたのを、コーディングに近い部分や同じ部分に移しただけのようだ。つまり、コーディングするプログラマーが設計まで担当するという開発手法である。
以上のような特徴を持つが、もちろん欠点もある。かなり重要な点も含まれるので、代表的な項目だけ順番に挙げていこう。
最初は、リファクタリングで修正できる範囲である。システムの規模が大きいほど、最初に決めた構造が悪いと、後での修正が大変になる。いくらリファクタリングが得意だからといっても、大きな変更が発生したら大変だ。どの程度の変更になるかどうかは、最初の構造設計の良し悪しで決まる。その意味で、システム全体の構造設計は非常に重要だ。とくにデータベースが絡むと、変更における大変さは増す。
システム全体の構造を決める際には、後で別に開発しそうな関連システムとの連携も視野に入れなければならない。この部分だけは、慎重に検討して設計しないと、後での変更が大変になる。大変さの度合いは、システムの規模が大きいほど高まるので、大規模になるほどXPのような手法は適応しにくい。
XPでは、オブジェクト指向技術を最大限に利用する。もし細かな部分の構造を上手に設計してあれば、システム全体の構造が大きく変わったとき、変更の手間を少しは軽減できる。ただし、これはオブジェクト指向技術の特徴であって、XPの特徴とは言えない。
２番目は、途中で変更が発生した場合のデータ移行だ。とくにデータベースを使っていて、項目が分割や合併したり、同じ項目でも定義が変わるときには、データを変換して移行する必要がある。場合によっては、移行ツールを作成しなければならない。これは余計な作業となる。
３番目は、参加者に要求される能力である。設計作業までプログラマーが担当するため、システム設計の様々な能力が求められる。その中には、問題領域に近い設計能力も含まれる。代表的なものは、使いやすさを高めるユーザーインターフェース設計、運用しやすしいシステムに仕上げる運用設計、人間側とコンピュータ側の作業を切り分け、業務に適切な作業の流れを設計する作業工程設計などだ。これらの能力を持たない人が設計すると、使いやすさの低いシステムができあがる。
もっと重要なのが、深い問題解決能力である。システムの利用者が要求する内容は、目先の問題だけを対象としている場合がほとんどだ。それだけを満たすようなシステムでは、良いシステムにならない場合が意外に多い。目先の問題から本当の問題を導き出すだけでなく、コンピュータを利用したときに最適な“問題領域の作業工程”も求めなければならない。また、最低でも５年程度の業界の変化を予測し、それに対応できる機能を組み込む必要もある。開発者が常に一緒にいて、好きなときに変更してくれるのでない限り。
４番目は、システム全体でのテストの難しさである。変更が多発する開発だと、正しい仕様が不明確になりやすい。開発者とは別な人がテストする原則なので、仕様が明確でないとテストできない。この辺を実際にはどうしているのか、まだ不明である。現実には考えると、開発の最終段階で最低限の仕様を書いてもらうしかない。後でシステムを変更する際にも、仕様書は必要になる。
以上の中で、もっとも重要なのは幅広いシステム設計能力である。この辺の話を理解できない人がいると思われるので、少し補足しておこう。
システム設計能力には、問題領域に近い部分から、プログラミングに近い部分まで幅広くある。プログラミングに近い設計能力は、能力を高め続けているプログラマーなら、かなりの高い確率で身に付けている。最近ではオブジェクト指向技術が中心であり、実装レベルのデザインパターン、UML、マルチスレッド処理などは、問題なくこなせるだろう。
しかし、問題領域に近いの設計能力は、残念ながら、身に付けている人が少ない。たとえば、運用設計なら、１日分の入力を確認する機能とか、業務上のエラーを発見するのを支援する機能などが含まれる。こういった機能を追加するのは、ほとんどの作業をコンピュータ化すると、ミスを発見しにくくなるからだ。人間が手作業で行っていれば、金額の明らかな記入ミスなどは、何人もが伝票などを見る過程で発見できた。それと同じ役割を、情報システムにも組み込むべきなのである。
ユーザーインターフェースの設計では、操作しやすいだけでなく、情報を分かりやすく見せる表現術も含まれる。この辺の話は、関連する書籍などを意識して読み続けないと身に付かない。作業工程の設計も同様で、その分野の書籍などを何冊か読み、コンピュータの長所と短所を理解して加味し、システムに適した設計手法を身に付ける。どの設計能力に関しても、こういった努力を一度は通らなければならない。
以上のような設計能力は、出来上がったシステムの質として明らかに現れる。ただし、質の高いシステムを知らない人だと、自分で作成したシステムの質が低いなんて思わない。向上心があって様々な設計技術を知ろうとしない限り、知らないまま作り続けるだろう。しかし実際には、設計者の設計能力の差が大きく出て、出来上がったシステムには明確な差が存在する。利用者の要望を聞いているだけでは作れない部分なので、設計者本人が能力を高めるしかない。
もう１つ、XPに関する意外な盲点は、テスト技術であろう。身の回りのソフト技術者を見ても、テストがキチンとできる人をあまり見かけないからだ。加えて、リファクタリングやXPの解説資料には、テストの上手な方法がほとんど解説していない。一般的な話だけで、ノウハウ部分が含まれていないのだ。あまり言う人はいないが、テストは難しい作業なのである。プログラミングをよく知り、どんな部分でバグが出やすいか知っていないと、効率的なテストは実現できない。そこまで達してなくても、XPを実施するなら、ある程度のテスト技術は必要だ。
このように分析すると、XPを採用した開発では、設計能力の高い人を数多く集めなければならない。実際は、そんな条件を満たす人は非常に少ないので、絶対に無理である。既存の開発手法は、数少ない非常に優秀な設計者に設計を任せ、その能力を最大限に有効利用する面もある。
以上のような話から、XPを用いた開発で、質の高いシステムを構築するのは難しいと分かるだろう。ただし、問題領域に近い設計能力が不要な開発もある。ユーティリティのように、コンピュータ側だけに関係するソフトの開発だ。このような対象なら、XPは大きな効果を上げられる。
XPの欠点が分かれば、長所だけを生かすような使い方が選べる。まず、開発するシステムの規模や複雑さに応じて、どの程度まで事前に設計するかを決める。関連するシステムがあれば、それも一緒に検討しなければならない。システム全体の構造に関係する部分だけは、最初に設計しておくわけだ。この部分では、既存の開発手法の中から良いものを採用する。
全体像の設計では、システムの構造だけでなく、問題領域側をも含めたエラー処理設計などを大まかに検討する。場合によっては、システム全体の構造に関係するからだ。また、業務の流れまで含めて慎重に検討し、後から大きな変更が生じないようにする。当然ながら、もっとも優秀な設計者が担当すべきである。
大まかな設計が終わったら、いくつかのサブシステムに分けられるだろう。その単位で、XPを採用するかどうか、どの順序で開発したらよいかを検討する。XPを採用するサブシステムが決まったら、参加メンバーを選ばなければならない。ある程度の能力が求められるため、誰でも良いというわけにはいかない点が、難しいところだ。
サブシステムの開発に入る前に、標準化しなければならない部分のガイドラインを決めておく。エラーメッセージの出し方、ユーザーインターフェースなどの設計指針だ。この部分に関しては、その分野に詳しい人が設計すべきなので、該当する設計者に任せたほうがよい。もし適任者がいない場合は、短期間だけ外部から来てもらって助言を受ける。組織として長期的に考えると、誰か決めて身に付けたほうがよい。
こうした準備が終われば、対象となるサブシステム単位で、XPを適用して開発を進める。開発している間に、細かな点が設計されるはずだ。その中で、全体の構造に影響を与える点が出たら、できるだけ早目に知らせる。重要な問題なので、早急に解決して、開発中のシステムに反映しなければならない。
サブシステム単位での全体テストは、開発者とは別な人がやるべきだ。この部分は、既存の開発手法と変わりない。そのためにも、サブシステムが開発し終わったら、ある程度の詳しさで仕様を書いてもらう必要がある。それをもとに、本格的なテストを実施する。
以上が、XPの長所を生かしながら欠点を補う、現実的に考えた活用方法である。もちろん、XP自体は採用せず、リファクタリングだけ採用するという方法も選べる。XPは、高い能力の技術者を何人も要求する手法なので、最終的には、組織に属するメンバーの能力などを総合的に検討して、採用を判断しなければならない。あまり堅苦しく考えず、試しに１回だけやってみるのも良いだろう。
ここまでXPの長所も短所も見てきたが、もっとも重要な点が改めて明らかになったと思う。最終的に出来上がるシステムの質は、参加した技術者の設計能力で決まるという点だ。それを高めない限り、良いシステムは構築できない。この部分に関して、XPの採用はあまり貢献しない（他の良い手法と大差がないという意味）。どんな開発手法を採用するかに関係なく、問題領域に近い設計能力を中心に、幅広い能力を身に付けるように努力しよう。
（2000年９月３日）
Extreme Programming |
