 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| はじめに | ||||||||||
|
これまで開発方法論は、図1に示すような変遷を遂げてきた。ここで冷静に振り返って考えてみよう。はたしてこれらの方法論は「正しかった」のだろうか。  図1．開発方法論の変遷 答えは「Yes」である。 この変遷は時代背景と密接な関係がある。開発するソフトウェアの対象領域が単体アプリケーションから複合化かつ分散され、Webアプリケーションを経て企業規模の情報システムへと範囲が広がっていくにつれ、それに適した方法論が採用されてきたという歴史を持つからだ。 各々の方法論が登場した時点で、それらは「High Cohesion／Low Coupling（注1）」などといったアーキテクチャ原則の観点で正しい進化を遂げているからである。
注1：
High Cohesion：高凝集性、Low Coupling：疎結合性
ではもう一度冷静に振り返って考えてみよう。果たしてこれらの方法論は「正しく理解・適用されてきた」のだろうか。 答えは「No」である。 |
||||||||||
| 開発現場における典型的な「間違い」 | ||||||||||
|
答えが「No」であることは明白だ。マーケットの状況を見れば、うまくいっていないプロジェクトだらけであることが何よりの証拠である。正しく適用できていない代表的な理由としては次のようなものがあげられる。 |
||||||||||
| 1. 目的を見失ったまま方法論を適用している | ||||||||||
|
オブジェクトにしろ、サービスにしろ、それらがどういうときに必要なのかと聞かれて明確に答えられるだろうか。簡単にできるはずのことを、かえって難しくしていないだろうか。 筆者の見る限りこの類の間違いが非常に多いのである。常にもっと簡単にできるのではないかと考えることは、優秀な開発者に共通する思考態度である。 |
||||||||||
| 2. 方法論を適用する目的を見失っている | ||||||||||
|
サービスは何のために必要かと聞かれて明確に答えられるだろうか。 ソフトウェア開発とは、時間も労力もかかる作業である。開発当初はクリアだった目的が、時間とともに希薄になってしまうことも多い。開発工程を通じて定期的に「今やっていることの目的は何か」と自問自答し続けることも重要である。 |
||||||||||
| 3. ステークスホルダごとの観点が分離できていない | ||||||||||
|
今あなたが行っている作業や構築している成果物について、それによって誰が喜ぶのか。 開発に関わるステークスホルダごとに観点（関心）が異なるのは当たり前だが、それらを一旦別々のものとして整理した上で、ステークスホルダ間の整合性をとるのが正しいアプローチである。これも開発を進めるに従って、一体この成果物は誰にとって必要なのかという疑問に答えられない状態に陥ることがある。 |
||||||||||
| 4.作業手順としての開発プロセスの欠如 | ||||||||||
|
「理論はわかるが、どう実践していいのかがわからない」という声をよく聞く。つまり作業手順がわからないのである。サービス指向でシステムを構築する場合、その開発プロセスが明確に理解できているだろうか。お仕着せの開発プロセスに振り回されてはいないだろうか。 ここであげた4つは開発現場で頻繁に見かける間違いである。しかしこれらの間違えを責めるつもりは毛頭ない。むしろこういった間違いは経験の過程において必ず遭遇するからだ。筆者自身も含め誰もが新しい概念に出会ったときは、先程述べたような典型的な間違いを犯すものである。 しかしその間違いから抜け出したときに「本質」が見えてくる。そういうことをずっと繰り返している。次にこれらの問題に対して、筆者が得た経験を踏まえて解決のヒントを述べていこう。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
