 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||
|
||||||||||||||||||||
| 急がば回れ | ||||||||||||||||||||
|
例えば業務分析や要求定義が終わった後、設計フェーズとして開発側が画面案を顧客側担当者に提示している段階があるとします。顧客側システム部の担当者から業務の中での細部ではなく、その時点で掌握していないひとまとまりの業務について説明を受けるという場面を目にすることがあります。 この例は業務分析完了前の段階であるといえるでしょう。なぜならば、本来すべての業務を考慮した上で画面単位の要求を決定し、その画面内の項目を明確にしているのでなければならないはずだからです。「画面の1つ1つが、その設計である理由は、つきつめれば、システム化対象のみならず、顧客業務のすべてである」ということです。 ですから、この例は、少しずつ判明する要件に対応しながら、試行錯誤で画面設計を行っていることになります。終わったはずの画面設計の前提条件が後からどんどん崩れてしまうことによって変更となりやすく、設計そのものや顧客側とのコミュニケーションも、プログラマの作業も大きく混乱し、プロジェクトは極めて低い効率で進むことになってしまうわけです。 筆者も常にできるとは言い切れませんが、顧客の誰よりも顧客業務全体を詳細に押さえていて、何か問題が発生したとしても代替案の2つや3つはすかさず提案できるレベルを目指す必要があるでしょう。 まさに「急がば回れ」で、開発側が顧客業務をシッカリと理解していることはあらゆる面で効力を発揮し、すべてがスムーズに進められるようになってきます。これは普段直接業務に携わっていない顧客側担当者にとっても大切なことです。 また業務システム開発での活動のほとんどは、結局「プログラマが実装」するという行動に行き着きます。ある意味、「何もかもコーディングをするためにやっている」のです。システム全体の負荷や同時に実現しなければならない様々な事柄などと照らし合わせた上で、本当に「実装」「具現化」できるものなのかを少しでも早く確認しなければなりません。 「具現化」できない内容のまま設計を進めてしまい、後になってバランスの取れない実装を強いる、あるいは大幅な再設計になるという結果を引き起こすわけにはいきません。 |
||||||||||||||||||||
| 顧客業務理解は顧客からの協力が必要 | ||||||||||||||||||||
|
アジャイルで「ペア・プログラミング」という言葉がありますが、スペックパターン開発プロセスでは「ペア・デザイニング」とでもいうような考え方を業務システム開発の最初の段階から行っていくことを提案しています。 実装を具体的に行うプログラマの代表者（インプリメント・リーダー）には、コミュニケーションを円滑に行うための画面イメージ作成のほか、常に具現化に向けての検証や最も効率の高い実装方法などの提案もしてもらいます。そうすることで、顧客側に開発のプロフェッショナルとして、確実でよりよい具現化の形を提案することもしやすくなるのです。 逆に考えれば、顧客業務理解のための協力を顧客側から得られないと、いくら開発側に優秀な人がいても、よいシステムを実現することは難しくなってしまいます。次回は顧客側の理解と協力を得るために顧客側担当者との初顔合わせにさかのぼって、プロジェクトマネージャー・仕様策定者としてどのようにプロジェクトを進めていくかということや「スペックパターン」についてのさらに詳細な解説をしていきたいと思います。 |
||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
