小野和俊ソフトウェアをつくりあげるために、どのようなテクノロジーを用い、どのようなアーキテクチャでシステムを構成するのかを決めていくことはとても大切なことです。それと同じくらい大切なこととして、「どのように開発するか」という開発のスタイルをデザインしていくことを忘れてはいけません。ここでいう開発のスタイルとは、例えばエクストリーム・プログラミングで示されている、ペア・プログラミングやテスト・ファーストのようなプラクティスなどのことです。テクノロジーやアーキテクチャにどのようなものを選択するかによって、ソフトウェアがユーザーにもたらす体験が変化し、ソフトウェアの開発に要する作業の内容も大きく変わってきます。開発スタイルの選択によって変化するのは、要求が変化することへの対応の柔軟性やバグの発生確率、職場の雰囲気、参加メンバーの納得感などです。開発スタイルのデザインには、原則は存在しますが、絶対にこうしなければならない、という類の規則は存在しません。特定の顧客向けに開発するシステムで、顧客のイメージがある程度固まっているようなプロジェクトでは、テスト・ファーストは絶大な威力を発揮するでしょう。自分たちでウェブのサービスを新規に立ち上げようと考えていて、イメージがほとんど固まっていない状態からっくりながら考えていく、というプロジェクトでは、テスト・ファーストを採用してしまうと、作成したテストの多くが無駄になってしまうこともあるでしょう。同じ開発プロジェクトの中でも、フェーズによって採用すべき開発スタイルが常に同じものになるとは限りません。選択するテクノロジーによって、開発スタイルのデザインが変わってくる場合もあります。使い慣れていないメンバーが多いテクノロジーを採用する場合には、初期の段階でのペア・プログラミングは、教育的な意味でも大きな効果を期待できます。一方で、メンバー全員がすで、に習熟している技術を選択する場合には、ペア・プログラミングではなく、個々に開発を進めて、コミット・レビューの際に互いのコードを確認する、というスタイルの方が効率が良いこともあります。アーキテクトには、プロジェクトがどのような特性を持ったメンバーで構成され、どのような開発スタイルで進んでいくのかを意識しながらアーキテクチャを設計してことが期待されます。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。